Guide to NoSQL (part 2)

<<part1

 

4      Key-Value databases

Key-value stores are schema-less, where the data is usually consisting of a string which represents the key and the actual data which is considered to be the value. The data is usually a primitive of an object that is being marshaled by the programming language. Binding between the key and the value replaces the need for fixed data model and makes the requirement for properly formatted data less strict.

 

The most common cases for key-value store usage are caching mechanisms, temporary storage for some computation processing (like hash-maps) and queue based applications.

 

The following several examples of key-value databases:

  1. Redis - an open source, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.
  2. Memcahed/Membase - an open source distributed, key-value database management system optimized for storing data behind interactive web applications.
  3. Voldemort – an open source fault tolerant distributed key-value storage system which supports distribution across data centers that are geographically far apart.
  4. Amazon DynamoDB - a highly available, proprietary key-value structured storage system or a distributed data store. It has properties of both databases and distributed hash tables (DHTs). It is not directly exposed as a web service, but is used to power parts of other Amazon Web Services such as Amazon S3.
  5. RaptorDB - an open source embedded nosql persisted dictionary using b+tree or MurMur hash indexing.
  6. RethinkDB – memcached compatible persistent store designed for solid-state discs and multicore systems.
  7. LevelDB - a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.
  8. Kyoto Tycoon – a persistent lightweight cache server.

5      Document-oriented DB

The principles of object-oriented design reflect that information is naturally organized in trees or graphs and not in tables. The best method found to close this gap is ORM (object-relational mapping). ORM layer is responsible for translations of object-oriented design to logical/physical ERD (entity relational diagram). It’s also responsible for generating SQL queries for different DB providers (take care of SQL dialects). Unfortunately, there are many cases when ORM can’t close the gap, such as bulk operations, complex data processing, etc. In addition, multiple joins are a serious barrier of understandable and maintainable business logic. In all these cases there is a need to break the object-oriented design and use alternative techniques.

 

The document-oriented store can store the hierarchical documents without a predefined data model (schema-less approach). Schema-less store also fits the DevOps approach, which is much harder to achieve with standard RDBMS systems. So, if you have a frequently changing data model you should consider using document-oriented databases.

 

Below are several examples of document-oriented databases:

 

  1. MongoDB - a scalable, high-performance, open source NoSQL database with JSON-style documents and dynamic schemas
  2. CouchDB - a database that uses JSON for documents, JavaScript for MapReduce queries, and regular HTTP for an API
  3. RavenDB – a transactional, open-source Document Database written in .NET, offering a flexible data model
  4. Clusterpoint - a high-performance document-oriented NoSQL DBMS platform software combining XML/JSON database, clustering and rich enterprise SEARCH features
  5. SisoDb - a document-oriented DB-provider for SQL-Server written in C#. It lets you store object graphs of POCOs without having to configure any mappings

 

The impressive MongoDB community and the buzz around this solution speaks for itself, so I want to reveal one interesting fact of CouchDB – adding web server to the database solution allowed the creation of immersive applications. CouchApps are JavaScript and HTML5 applications served directly from the database (skipping the middle tier). Since CouchDB is accessed using a RESTful HTTP API and stores documents as JSON objects, it is easy to work with CouchDB directly from an HTML5/JavaScript web application.

  6      Object-oriented DB

The reasonable question to ask here is why do we need to stop at document-oriented store, instead of going directly to the object-oriented DB (ODBMS)?

 

To understand the difference, let’s see how a JSON-like document is different from Object Definition Language (ODL) (from MongoDB blog):

  • Objects have methods, predefined schema, and inheritance hierarchies. These are not present in a document database; code is not part of the database
  • While some relationships between documents may exist, pointers between documents are de-emphasized
  • The document store does not persist “graphs” of objects — it is not a graph database.
  • In the document store there is an explicit declaration of indexes on specific fields for the collection. This is not always possible in object stores.
  • Object-oriented models are usually better bound to a specific environment. If you use exclusively Java, for example, you have a lot of choices. But if your environment is hybrid (Java, COBOL, C++, etc.) there is no common denominator.

 

Below are several examples of document oriented databases:

 

  1. Db4o - is an embeddable open source object database for Java and .NET developers. It is developed, commercially licensed, and supported by Versant.
  2. NeoDatis - a very simple Object Database that currently runs on Java, .Net, Google Android, Groovy and Scala.
  3. Objectivity/DB - a commercial object database produced by Objectivity, Inc. It allows applications to make standard C++, Java, Python or Smalltalk objects persistent without having to convert the data objects into the rows and columns used by a relational database management system (RDBMS). Objectivity/DB supports the most popular object-oriented languages plus SQL/ODBC and XML.
  4. ObjectStore - a commercial object database produced an object database for Java and C++ applications that can cache data to deliver performance.
  5. Starcounter - a memory centric, ACID compliant, transactional database, optimized for modern CPUs with .NET object API. It is reliable since transactions are secured on disk, and it supports replication and full checkpoint recovery.
  6. Perst - An open source, object-oriented embedded database for Java and C#.

 

part 3>>

Tags: big data| nosql
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation