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.
Key Features
No sharding
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.
Easy scaling
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.
Safe defaults
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.
Improvements
No locking for conflicting writes
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.
Irrelevant commands removed
Many database commands, including the commands related to sharding and replication have been removed as they are not applicable for the Document Layer.
Multikey compound indexes
FoundationDB Document Layer comes with Multikey compound indexes which allows the document to have array values for more than one of the indexed fields.
MongoDB API Compatible
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.
Saves time
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.
Custom projections
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.
Non-multikey indexes
If the indexed field on a document contains an array, then all the indexes allow multiple entries for that document.
Auth/auth
The FoundationDB Document Layer does not support MongoDB authentication, auditing, role-based access control, or transport encryption.
sort parameter
The sort parameter has been disabled in Document Layer.
$push and $pull operators
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.
listDatabases command
The Document Layer comes with listDatabases which will always return a size of 1000000 bytes for a database that contains any data.
Nested $elemMatch predicates
In Document Layer, a query document of two or more nested $elemMatch predicates may behave differently.
Future scope
- Currently, the Document Layer doesn’t allow the insertion or updation of a document which generates more than 1000 updates to a single index. In the future release, this limit might get configurable.
- The format of the information returned by the $explain operation is still not final but it may possibly get changed without prior warning in a future version.
- The Document Layer doesn’t support sessions yet so it could be expected in the future release.
- Future releases may emulate the Oplog for migration of the applications that directly examine it.
- The Document Layer does not support the deprecated BSON binary format or the MongoDB internal timestamp type.
- The Document Layer does not implement any geospatial query operators yet, they might be expected in a future release.
- Support for tailable cursors or capped collections could be expected soon.
- Currently, there is no support for the indexes which contains the entries for documents having indexed field which might get introduced soon.
- The FoundationDB Document Layer does not support the indexes which contains the entries for documents having indexed field. This feature might get implemented in the future.
- Currently there are no indexes, no data typing, and no query engine in Document Layer, which would be expected soon.
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.
Read Next
Introducing EuclidesDB, a multi-model machine learning feature database
ScyllaDB announces Scylla 3.0, a NoSQL database surpassing Apache Cassandra in features