Multi-Model Architecture

A Multi Model Database Ripe for Building Microservices

Databases are commonly classified by the data model they conform to. A hierarchical database would structure and approach hierarchies of data elements, a relational database would handle related data tables, a document database would handle collections of documents, and so on.

Various database models excel in different ways. Querying relations between members of a complex social network for example, can be easy and effective using a graph database, but unrealistically complicated and slow using a relational database.

Considering the abundance of tempting database services in existence then, there’s a challenge we’d be wise to address: How do we harness this diversity to our advantage? Take for instance a company that wants a document store for its orders, ACID reliability for its accounting, distributed-counters for web analytics, and would also like to provide Data subscribers with recommendations gained using graph queries.

Deploying multiple data stores to provide this set of services is likely to become a costly, complex, delicately-balanced endeavor, susceptible to the vulnerabilities of each and requiring tailored integration for them all.

An ideal solution would be deploying not several stores, but a single multi-model system that provides all services. A multi-model database is exactly that, providing a set of services that in the past could be provided only by multiple specialized databases.

There are many advantages in having a single endpoint for your document store, graph queries, distributed counters and all other database services.

  • The initial integration is significantly simpler and more cost effective when a single solution is installed rather than a set of applications with different dialects, GUIs, interrelated behaviors and other differences and characteristics.
  • Ongoing maintenance, and the introduction of new versions and features, are also less costly and much easier to implement for a single database.
  • The reduction in immediate expenses is followed by reduced operational expenditure, giving you another push toward ever-growing ROI.
  • The enormous reduction in overall complexity is expressed in increased agility.
  • The same trustworthy contacts are available to support all services.
  • The learning curve of developers building services is focused and minimized, saving them and their employers much effort and time.

Counters: A RavenDB counter is a Conflict-free Replicated Data Type (CRDT). Multiple clients can modify the same counter concurrently with no conflict or data loss. Counters are kept outside the documents that own them, so updating a counter’s value doesn’t modify the document the counter belongs to. This way counter operations do not trigger document replication and remain cheap regardless of how many counters you have and how often their values are updated.

Revisions: By enabling the revisions feature, your system administrator can make RavenDB log changes made to your documents. This gives you a built-in audit trail ready for use when needed, and the ability to reconstruct documents to their previous versions. You can also use revisions to follow changes made in the database using subscriptions. This can be very useful for regression analysis, applying business rules and seeing how the data changes over time.

A Multi Model Database that Gives You ROI that Compounds Year after Year

RavenDB lets you become an information octopus, while only having to learn and maintain one system. But your gain over time goes well beyond the initial investment in a single system rather than in many, as this layout continues to encourage developer productivity and prevent unnecessary expenses year after year throughout the life of your project.