Very nice, and congratulations. Reading the "Data Modeling" documentation brings to mind some similarities with the MUMPS storage model (Intersystems Caché / GlobalsDB / GT.M).. is this a correct observation? Thanks.
Absolutely. Good eye.
A NoSQL Database with ACID Transactions
31–40 of 57 posts
Re: A NoSQL Database with ACID Transactions
#32I like the emphasis on transactions. However, the fact that it doesn't support transactions longer than 5s and puts the onus on the client to enforce is kind of a turn-off. How is the client supposed to know how long the server will take for a given operation at a random load?
Our performance page (http://foundationdb.com/performance/) shows how we've worked very hard to provide predictable and low latencies, even at saturating workloads [1] (on the order of 1ms for a read and 10ms for a commit). This means that transactions with 50 serial reads are still going to complete in two orders of magnitude less time than the maximum transaction duration (and futures make it easy to parallelize most reads). This is more than enough for client operations -- regardless of your database, you usually don't want to have a user wait for 5s, hold a lock for 5s, or be subject to conflicts for 5s.
[1] Under saturating load, FoundationDB will queue transactions before assigning them a read version (starting the 5 second window), so that latencies within the transaction stay low. This explicit queuing also makes it easy to prioritize transactions, so you can mix latency-sensitive and saturating batch workloads safely.
Re: A NoSQL Database with ACID Transactions
#33"APIs for C, Python, Ruby, Node.js, and Java"
And where is PHP?
Re: A NoSQL Database with ACID Transactions
#34Earlier quoted context omitted.
FoundationDB founder here. Flow sounds crazy. What hubris to think that you need a new programming language for your project? Three years later: Best decision we ever made. We knew this was going to be a long project so we invested heavily in tools at the beginning. The first two weeks of FoundationDB were building this new programming language to give us the speed of C++ with high level tools for actor-model concurr…
How does the Python program know what the random Flow code is supposed to do?
Hmm, that's the tricky bit to explain in a quick post. It has an independent code interpreter that works on the internal representation of the fuzzed code. The output of that internal representation in fed through the Flow compiler (then C++). There is basically a "check([random number])" statement on every other line of code which should be reached in a known order. We compare the check log of the fuzz tester's interpreter to the check log of the compiled code.
Re: A NoSQL Database with ACID Transactions
#35Earlier quoted context omitted.
FoundationDB founder here. Flow sounds crazy. What hubris to think that you need a new programming language for your project? Three years later: Best decision we ever made. We knew this was going to be a long project so we invested heavily in tools at the beginning. The first two weeks of FoundationDB were building this new programming language to give us the speed of C++ with high level tools for actor-model concurr…
How does the Python program know what the random Flow code is supposed to do?
I guess that the Python program generates some sort of internal AST that is either trivial or at least easier to interpret than the fuzz code (enhanced C++, blah...) generated from the AST.
Re: A NoSQL Database with ACID Transactions
#36"APIs for C, Python, Ruby, Node.js, and Java" And where is PHP?
PHP and .NET are the clear front-runners when we asked this question on our community site, so while I can't commit to any specific timeline, it's safe to say we'll be adding them soon.
Re: A NoSQL Database with ACID Transactions
#37could not have been more disappointed
Re: A NoSQL Database with ACID Transactions
#38I like the emphasis on transactions. However, the fact that it doesn't support transactions longer than 5s and puts the onus on the client to enforce is kind of a turn-off. How is the client supposed to know how long the server will take for a given operation at a random load?
Our performance page ( http://foundationdb.com/performance/ ) shows how we've worked very hard to provide predictable and low latencies, even at saturating workloads [1] (on the order of 1ms for a read and 10ms for a commit). This means that transactions with 50 serial reads are still going to complete in two orders of magnitude less time than the maximum transaction duration (and futures make it easy to parallelize…
Thanks for the quick answer. Regarding long transactions, it depends on what you are doing. Say you want to change your schema, you won't be able to do this in a single transaction (something which, eg, Postgres lets you do).
Re: A NoSQL Database with ACID Transactions
#39Any plans on releasing an SQL-layer to allow querying FoundationDB using normal SQL? Would be nice with both SQL and ACID in the same database.
No plans, but that would be nice. Others like Clustrix and NuoDB are more directly targeting the distributed SQL database market. Often we describe FoundationDB's core to people as more of a "storage substrate" than a database. It is possible to build an efficient SQL database as a layer on top of that substrate. For example, SQLite4 is choosing a transactional ordered key-value abstraction for its internal storage engine (which exactly matches FoundationDB's API). Of course, a SQL database is a big project involving a lot more than just a storage engine!
Re: A NoSQL Database with ACID Transactions
#40RavenDB is also ACID I beleive? The foundation site makes it sound like they are the only one.
FoundationDB founder here. We think that it's awesome that RavenDB also supports multi-node ACID transactions. However, on page 9 of https://s3.amazonaws.com/daily-builds/RavenDBMythology-11.pd... they warn against relying on this capability: "RavenDB supports multi document (and multi node) transactions, but even so, it isn’t recommended for common use, because of the potential for issues when using distributed tran…
That remark seems a bit unfair. That document is two years old, from long before version 1.0. RavenDB is now at version 2.0. It was also built with transaction support from the start. The default setting for TransactionMode is Safe (http://ravendb.net/docs/server/administration/configuration) so most users will use that, if there were any issues with it that would certainly be known by now.