ravendb: All content tagged as ravendb in NoSQL databases and polyglot persistence
This will be a project written for the sole purpose of demonstrating how to use RavenDB and how to write testable code against RavenDB – this will be demonstrated by utilising some basic TDD principles in order to drive the code surrounding the RavenDB infrastructure and usage.
Unfortunately there’s no easy way to navigate these posts, so here are links to them in order:
- ☞ part 1: introduction
- ☞ part 2: setup
- ☞ part 3: application lifecycle
- ☞ part 4: tracking documents
- ☞ part 5: structure
- ☞ part 6: entities, repositories, and commands
- ☞ part 7: user registration
Additionally you have a ☞ debate about RavenDB documents and entities.
But before using this as a reference material there are a couple of corrections needed:
They have some special characteristics that make them kick some serious SQL.
- Objects can be stored as documents: The relational database impedance mismatch is gone. Just serialize the object model to a document and go.
- Documents can be complex: Entire object models can be read & written at once. No need to perform a series of insert statements or create complex stored procs.
- Documents are independent: Improves performance and decreases concurrency side effects
- Open Formats: Documents are described using JSON or XML or derivatives. Clean & self-describing.
- Schema free: Strict schemas are great, until they change. Schema free gives flexibility for evolving system without forcing the existing data to be restructured.
- Built-in Versioning: Most document databases support versioning of documents with the flip of a switch.
- Judging by the growing number of document database mapping tools, I’m not sure impedance mismatch is really gone (related to 1st point above)
- Using embedded format is not always the best solution for mapping relationships and other more complex data structures. (related to 2nd and 3rd points above)
- Versioning is an extra-feature that is not fundamental to document databases. MongoDB and CouchDB do not support it by default, but there are different solutions available
Related to the matrix comparison:
- Versioning is not supported by either MongoDB and CouchDB. MVCC should not be confused for document versioning
- Sharding: CouchDB doesn’t support sharding out of teh box. There are different solutions for scaling CouchDB, using Cloudant Dynamo-like scaling solution for CouchDB, or even running CouchDB with a Riak backend
- Replication: both MongoDB and CouchDB support master/master and master/slave
- Security: check firstly the NoSQL databases and security post and decide for yourself and the “basic” level is enough for your app
Original title and link for this post: Document Databases Compared: CouchDB, MongoDB, RavenDB (published on the NoSQL blog: myNoSQL)
Interesting to note that some VoltDB don’ts from the paper ☞ Do’s and Don’ts (pdf) are validating some major assumptions in the NoSQL space:
Don’t create tables with very large rows (that is, lots of columns or large VARCHAR columns). Several smaller tables with a common partitioning key are better.
Basically both wide-column stores (i.e. Cassandra, HBase, Hypertable) with their column-families and document databases (i.e. CouchDB, MongoDB, RavenDB, Terrastore) with their schema-less approach are addressing this issue.
- Don’t use ad hoc SQL queries as part of a production application.
Firstly this points to the mindset change required by the NoSQL space when doing data modeling: think about data access patterns.
Secondly, it pretty much validates CouchDB and RavenDB approaches of having queries defined upfront making their reads extremely fast.
So, I couldn’t stop asking myself is there a need for a (new) document query language?
To be able to answer this question, I thought I should firstly review what are the existing solutions/approaches.
- MongoDB allows dynamic and pretty complex queries, but it is using a custom query API.
- RavenDB, the latest addition to the document database space, has chosen the route of Linq for defining indexes.
- Terrastore supports predicate (XPath currently) and range queries offering a mapreduce-like solution. You can read more about these in the Terrastore 0.5.0 article
- Last, but not least, XML databases are using XPath for querying.
Simply put, it looks like each solution comes with its own approach. While it will probably make sense to create a unified query language for document databases, I see only two possible solutions:
- either make all document databases sign up to use this query language (note: this might be quite difficult)
- or provide it through a framework that works will all of the existing document stores (note: this might not be possible)
But do not create a new query language in a framework that works only with a single document store.
The major benefit of using a document database comes from the fact that while it has all the benefits of a key/value store, you aren’t limited to just querying by key.
One of the main advantages of data transparency (as opposed to opaque data) is that the engine will be able to perform additional work without having to translate the data into an intermediary or a format that it understands. Querying by non primary key is such an example. The various document stores provide different implementation flavors depending on index creation time, index update strategy, etc. Oren goes on and covers the query behavior for CouchDB, Raven and MongoDB:
Note that in both CouchDB and Raven’s cases, indexes do not affect write speed, since in both cases this is done at a background task.
MongoDB, on the other hand, allows ad-hoc querying, and relies on indexes defined on the document values to help it achieve reasonable performance when the data size grows large enough. MongoDB’s indexes behave in much the same way RDBMS indexes behave, that is, they are updated as part or the insert process, so large number of indexes is going to affect write performance.
Another good resource explaining the differences between MongoDB and CouchDB queries is Rick Osbourne’s ☞ article.
This is not to say that some of this functionality cannot be achieved with pure key-value stores, but these seem to be focused mainly on single/multi key lookups and most probably you’ll have to build this additional layer by yourself.
Lately I’ve been hearing about a couple of newcomers in the NoSQL space so here is your chance to find out about them and why not provide other readers with some additional feedback about each of them:
According to the ☞ project homepage:
- Data is partitioned and replicated over multiple servers.
- Extreme single node performance; comparable with memcached.
- Both read and write performance got improved as servers added.
- Servers can be added without stopping the system.
- Servers can be added without modifying any configuration files.
- The system does not stop even if one or two servers crashed.
- The system does not stop to recover crashed servers.
- Automatic rebalancing support with a consistency control algorithm.
- Safe CAS operation support.
- memcached protocol support.
Raven DB ☞
Raven DB is a dual licensed document database for the .NET platform with a RESTful API.
According to the ☞ project homepage:
- Scalable infrastructure: Raven builds on top of existing, proven and scalable infrastructure
- Simple Windows configuration: Raven is simple to setup and run on windows as either a service or IIS7 website
- Transactional: Raven support System.Transaction with ACID transactions. If you put data in it, that data is going to stay there
- Map/Reduce: Easily define map/reduce indexes with Linq queries
- .NET Client API: Raven comes with a fully functional .NET client API which implements Unit of Work and much more
- RESTful: Raven is built around a RESTful API
According to the ☞ project homepage, OrientDB is a
scalable Document based DBMS that uses the features of the Graph Databases to handle links. It’s the basic engine of all the Orient products. It can work in schema-less mode, schema-full or a mix of both. Supports advanced features, such as indexing, fluent and SQL-like queries. It handles natively JSON and XML documents.
The OrientKV is a:
Key/Value Server based on the Document Database technology and accessible as embedded repository via Java APIs or via HTTP using a RESTful API. Orient K/V uses a new algorithm called RB+Tree, derived from the Red-Black Tree and from the B+Tree. Orient Key/Value server can run in high availability mode using a cluster of multiple nodes partitioned.
Have you tried any of these?
According to the GitHub page, Pincaster is a persistent NoSQL database to store geographic data and key/value pairs, with a HTTP/JSON interface. Unfortunately there’s almost no documentation about the project so I don’t think there’s anything else I could add for now.
Update: hint received from @fs111