NoSQL databases Voldemort db


NoSQL databases make reference to database management systems (DBMS) that change from RDBMS in some way. NoSQL databases avoid join procedures and normally level out horizontally.

Here are a few of the features of NoSQL datbases.


  • Elastic scaling: NoSQL directories size out horizontally. Usually we can add low-cost commodity servers and size NoSQL directories.
  • Big data: NoSQL databases are normally designed to deal with huge unstructured data. Social Networking sites such as Facebook, Linkedin use NoSQL systems for their operation.
  • Less DBA requirement: NoSQL directories require less disturbance from databases administrator. With designs such as read-repair, data circulation and replication there is less administrative activity still left for the DBA.
  • Flexible data models: NoSQL systems such as MongoDB is document-based database. It does not have any natural schema requirement. Thus the schema of the data can transform on the take flight.

However there are a few difficulties of NoSQL, that ought to be kept in mind.


  • Maturity: NoSQL directories have recently began attaining momentum. There are not many experts who know these systems in and out and most of the databases are not mature.
  • Support: NoSQL databases are largely open-source and built with the aid of community effort. Therefore they may lack quick support, customer care, etc.
  • Administration: NoSQL directories installation require good complex skills. The maintenance of these systems is also tiresome.
  • Expertise: A couple of few NoSQL designers and the majority of them are still in the training phase.


NoSQL implementations can be classified by their types of implementation.

Here are different categories along with an implementation.

  • Document store : MongoDB
  • Graph : Neo4j
  • Key-value store : Voldemort
  • Wide-column : Cassandra

Voldemort Introduction

Voldemort is a allocated key-value storage space system.

It's various characteristics are
  • Automatic replication of data over multiple machines.
  • Automatic partitioning of data, so each server consists of only a subset of the full total data
  • Transparent handling of server failing
  • Pluggable serialization support
  • Versioning of data what to maximize data integrity
  • No central point of failure as each node is self-employed of other nodes.
  • Pluggable data location strategies support for things such as circulation across data centers that are very good geographically.

Voldemort is utilized at Linkedin.


For availability and high-performance reasons, only trivial key-value data gain access to is allowed. The queries which were supported are

* value = storeClient. get(key)

* storeClient. put(key, value)

* storeClient. delete(key)

Both tips and beliefs can be simple or sophisticated items like lists, maps. The keys and values are then serialized.

Though the query format means that there may be no complicated query filter systems, no international key constraints, no causes and that joins must maintain done in code, there are several advantages like
  • Easy distribution across cluster
  • Ready-made caching layer
  • Predictable performance as only questions listed above are possible
  • For keeping the services loosely coupled, we have to do database-joins in code anyways.
  • For performance, anyways serialized format is necessary.
  • Clean separation of reasoning and storage.

Architecture of the System

Logical Architecture of the System

As we can easily see the logical architecture of the system is a split architecture. Each coating perform its singular process such as serialization, failover or getting together with the underlying storage space engine. For instance, in serialization covering the system manages the work of translating items to byte arrays. That's suppose I've a key, value set to be stored in the Voldemort 'store'. And suppose key is string and valu