So, as I understand it ...
Apple has outsourced development of FoundationDB and expects the outsourcers to work for free.
Apple has open-sourced FoundationDB, a distributed ACID-compliant NoSQL datastore, three years after acquiring the company that developed the technology. At the time, developers who used the database voiced resentment that Apple had taken a useful tool off the market and left companies using the software without support. For …
I get that it's a "distributed ACID-compliant NoSQL datastore". But aren't there a million of those already?
For someone who doesn't keep up with the latest web-scale trends, what makes this great compared to, say, Mongo or Couch?
"I get that it's a "distributed ACID-compliant NoSQL datastore". But aren't there a million of those already?"
There are several products that almost do this, but none of them quite do what FoundationDB does. Plenty of the NoSQL stores can give strong transactional guarantees, but they all compromise in one way another.
The big differentiator here is multi-row transactions. The closest technologies to FoundationDB are HBase (BigTable) and Cassandra (Dynamo). Neither of these technologies allow you to safely operate across multiple rows. Less similar (i.e. not pure-KV) technologies like Mongo are getting there, but are still pretty far off. Cockroach is almost there with the transactional story, but its pure-SQL nature makes it unsuitable for a lot of the use cases that Foundation would target.
For those of us that work in this particular area, FoundationDB is an extremely compelling prospect. It has a reputation of being absolutely rock solid and high performing. As mentioned, the multi-row transactions are not to be sniffed at. The only drawback for Foundation right now is that NoSQL is a mature market, and Foundation is starting from scratch. No Spark integration, no management tooling and no SQL overlay make it a hard sell for all but the most technologically capable, regardless of how technically awesome it is as a product.
"The only drawback for Foundation right now is that NoSQL is a mature market, and Foundation is starting from scratch".
^ Exactly this; Apple should have open sourced the project not long after it was actually acquired.
On a side note, the standard of decision making and quality control at Apple appears to have declined coincident with the loss of Steve Jobs.
Multi-row transactions are a big deal? SQL has only had this for what, 40 years? Personally, I am sick of having this NoSQL crap forced into projects that have no business using it by people who don't know what they are doing and who apparently only care about padding their resume or putting on a show.
"SQL has only had this for what, 40 years?"
Right, but SQL engines don't do 10MOPS on thirty grand's worth of kit, or scale to arbitrarily large limits, nor can they store arbitrary data on demand. This does all of that. In return you trade away the richness of SQL the language, the guarantees provided by the SQL schema and the nice-to-haves we're furnished with by the traditional RDBMSs..
If it helps you can think of it as a distributed cache rather than a database. This would be wrong, of course, because it can do so much more than that, but it might help.
"How is a single row transaction even considered a transaction?"
Because these are, generally speaking, columnar datastores. As in your one row doesn't exist in a single place. Or even a single file. Or even in a single machine. Or even, as in the case of Cockroach, in a single datacentre. They're generally row-centric MVCC within columnar data files of some variety (usually column family-based). This means you get strict transactionality on a single row for free, but doing multi-row transactions is *hard*. This applies to all sharded, multi-master datastores.
If they had open sourced this immediately, it would have stood a chance.
As it is, they've given CockroachDB a 3 year head start (as well as commercial offerings like FaunaDB).
Aside: to build the thing you need both Mono *and* Java. That combination should put off 90% of open sourcers at a stroke :-)
Until now, Apple has made extensive use of SQLite in both MacOS X (e.g. time machine is built on it) and iOS (it is a standard datastore API made available to all apps).
I am curious as to Apple's internal roadmap on this, and whether they see FoundationDB as more capable and will eventually replace SQLite, or if each DBMS will continue to have its own niche within Apple products.
> whether they see FoundationDB as more capable and will eventually replace SQLite
Two completely different use cases.
SQLite is for single-device, local storage only. Your database is stored in a single file on your filesystem, and it provides no remote network access.
FoundationDB is for massive databases, accessed over the network, replicated for resilience and automatically sharded for scale, spread over multiple racks or multiple data centres. A single-node FoundationDB instance is fairly pointless, except as something to develop against. It gives a much lower-level API than SQLite, just a key-value store.
Biting the hand that feeds IT © 1998–2021