RavenDB at a Glance

Rethinking the database

When most people talk of a database, they mean a relational database. Relational databases have been the foundation of enterprise application for the past 30 years. First defined in June 1970 by Edgar Codd of IBM’s San Jose Research Laboratory, relational databases store data in now familiar tables made up of rows and columns.

Relational databases worked well when systems were serving hundreds or even thousands of users, but the Internet has changed all of that. The number of users and volume of data is growing exponentially. A variety of social applications have proved that applications can quickly attract millions of users. Relational databases were never built to handle this level of concurrent access.

Architecture changes. While data is still king, how we architect our data-dependent systems has changed signi cantly over the past few decades. In many systems, the database acted as the integration point for different parts of the application. This required the data to be stored in a uniform way since the database was acting as a form of API. The following diagram shows the architectural transitions:

With the move to Service Oriented Architectures (SOA), how data is stored for a given component has become less important. The application interfaces with the service, not the database. The application has a dependency on the service contract, not on the database schema. This shift has opened up the possibilities to store data based on the needs of the service.

RavenDB as Document type database for .NET Document databases are made up of semi-structure and schema free data structures known as documents. In this case, the term document is not speaking of a PDF or Word document. Rather, it refers to a rich data structure that can represent related data from the simple to the complex. In document databases, documents are usually represented in JavaScript Object Notation (JSON). A document can contain any number of elds of any length. Fields can also contain multiple pieces of data. Each document is independent and contains all of the data elements required by the entity. The following is an example of a simple document:

{
	Name: "Joko Widodo",
	BornIn: "Surakarta, Indonesia",
	Spouse: "Iriana"
}

And the following is an example of a more complex document:

{
	Name: "Joko Widodo",
	BornIn: "Surakarta, Indonesia",
	YearBorn: "1961",
	Children: [
	{ Name: "Gibran Rakabuming", YearBorn: "1988" },
	{ Name: "Kahiyang Ayu", YearBorn: "1991" },
	{ Name: "Kaesang Pangarep", YearBorn: "1994" }
	]
}

Since documents are JSON-based, the impedance mismatch that exists between the object-oriented and relational database worlds is gone. An object graph is simply serialized into JSON for storage. Now, the complexity of the entity has a small impact on the performance. Entire object graphs can be read and written in one database operation. There is no need to perform a series of select statements or create complex stored procedures to read the related objects.

JSON documents also add exibility due to their schema free design. This allows for evolving systems without forcing the existing data to be restructured. The schema free nature simplifies data structure evolution and customization. However, care must be given to the evolving data structure. If the evolution is a breaking change, documents must be migrated or additional intelligence needs to be built into the application.

To be continued..