Yesterday, the team at FoundationDB announced that they are open sourcing the FoundationDB Document Layer, a document-oriented database. It extends the core functionality of the FoundationDB key-value store which stores all the persistent data. FoundationDB, a distributed database has been designed to handle large volumes of structured data across the clusters of commodity servers. It organizes the data in ordered key-value store format.
The FoundationDB Document Layer is a stateless microserver which is backed by the scalable and transactional features of FoundationDB. It is released under an Apache v2 license. The Document layer improves the usage of document database with the help of MongoDB API. It allows the use of the MongoDB API through existing MongoDB® client bindings.
The Document Layer also implements a subset of the MongoDB API (v 3.0.0), which mainly focuses on CRUD (Create, Read, Update Delete) operations, indexes, and transactions. The FoundationDB Document Layer works with all official MongoDBdrivers.
The Document Layer does not rely on a fixed shard key for distributing data. The data partitioning and rebalancing is managed by the key-value store, automatically. This feature has been inherited from FoundationDB which provides robust horizontal scalability and avoids client-level complexity.
Document Layer’s instances are stateless and are configured only with the FoundationDB cluster, where the data gets stored. This stateless design of the Document Layer indicates that the instances of Document Layer can be kept behind a load balancer. So, queries can get easily handled from any client and for any document.
The write operations on the Document Layer execute with full isolation and atomicity by default. This consistency makes it easier to correctly implement the applications that handle more than one simultaneous request.
The Document Layer makes use of the concurrency of Key-Value Store which doesn’t let write operations to put locks on the database. In case of two operations concurrently attempting to modify the same field of the same document, one of them will fail. The client will again retry the failed operation. Most of the operations automatically get retried for a configurable number of times.
Many database commands, including the commands related to sharding and replication have been removed as they are not applicable for the Document Layer.
FoundationDB Document Layer comes with Multikey compound indexes which allows the document to have array values for more than one of the indexed fields.
The Document Layer is compatible with the MongoDB protocol as simple applications leveraging MongoDB can have a lift-and-shift migration to the Document Layer. In order to connect the application to the Document Layer, one has to use any existing MongoDB client.
Instead of logging all the operations that take more than a certain amount of time, the Document Layer logs all operations that perform full collection scans on non-system collections.
The Document Layer supports custom projections of query results but it does not support the projection operators. The literal projection documents are used instead. It also does not support the $text or $where query operators.
If the indexed field on a document contains an array, then all the indexes allow multiple entries for that document.
The FoundationDB Document Layer does not support MongoDB authentication, auditing, role-based access control, or transport encryption.
The sort parameter has been disabled in Document Layer.
It doesn’t support the $position modifier to the $push operator. In Document Layer, the $sort modifier to the $push operator is only available if the $each modifier and the $slice modifier both have been used.
The Document Layer comes with listDatabases which will always return a size of 1000000 bytes for a database that contains any data.
In Document Layer, a query document of two or more nested $elemMatch predicates may behave differently.
Users are excited about this update but many are confused as to how would they shift from MongoDB as licensing could be an issue. Also, it still doesn’t support a list of features like the aggregation framework, indexes etc which could cause trouble to the users. Another concern is its -incompatibility with other API’s example DynamoDB.
Another downfall is that it follows the layered approach which consumes more bandwidth unless the transaction is read-only. Few users are still having the bitter feeling of 2015 when FoundationDB was acquired by Apple. And they don’t trust the company since then. It would be interesting to see what happens in the next release.
To know more about this news, check out the official post by FoundationDB.
Introducing TigerGraph Cloud: A database as a service in the Cloud with AI and Machine Learning support
Introducing EuclidesDB, a multi-model machine learning feature database
ScyllaDB announces Scylla 3.0, a NoSQL database surpassing Apache Cassandra in features