NoSQL Consultancy and Support
Most NoSQL systems fit in the Availability and Partition Tolerance categories. The category Consistency is slightly different for NoSQL: instead of consistency, it offers eventual consistency.
Database systems that are viewed as consistent usually adhere to the ACID-principle: Atomicity, Consistency, Isolation, Durability. Eventually consistent database systems are based on the BASE-principle:
- Basically Available: the system is available 24/7
- Soft State: it is unnecessary for the system to be consistent at all times; not all nodes within a cluster contain the same data at every moment
- Eventually Consistent: even though the system or the cluster is not consistent at all times, eventual consistency of the system or cluster is a guarantee.
Within software development, the expected performance criteria determine the choice of a data store: the estimated system load, the maximum and average numbers of simultaneous users, the supposed data volumes, and the duration of the period during which data has to be available. A second step is the analysis of the nature and usage of the data and the functionality of the application: do the users only consult the data or do they report it, as well? Are there any transactions? Are the data being processed online?
The selection of a NoSQL database depends on different factors that are not necessarily related to scalability:
- The relationship between read and write actions: some systems are more suitable for write actions, others for read actions
- The complexity of the data model
- What is demanded of the infrastructure: some NoSQL systems require additional control servers to configurate modes for high availability and replication
- Whether a temporary catching layer is sufficient, or a full persistency layer is necessary
- What types of data are being stored: documents, unstructured data, hierarchical data, or data that can be modelized using graph theory elements or XML
The number of NoSQL products is increasing, which can make it difficult to base a choice solely on pre-formulated demands. There are compatible solutions with sometimes very subtle differences. All details deserve careful consideration – from the API and availability of support to the characteristics of the community. NoSQL data stores can be categorised as follows:
These databases allow for efficient data storage. Compared to more advanced databases they are very limited, because they only offer one way to access the data (value). Other ways require external management, for instance via Lucene or an index that is being managed by the application.
Examples: Riak, Redis, Memcached
These databases are also known as record-oriented databases, which are databases that consist of tables or wide-column stores. The concept of BigTable became popular because of Google’s BigTable implementation. Just like relational databases, a BigTable database consists of multiple tables, each of which contains a set of rows that can be called upon. Every row consists of a series of values that can be considered columns.
Examples: Azure Tafels, HBase, Cassandra
Document databases are also known as document-oriented databases. They were developed for optimal storage of and access to documents, as opposed to a structure of rows or records. Document databases have no schemas.
Examples: CouchDB, MongoDB, Terrastore
Within these databases, data is stored in graph-like structures, instead of linear lists or key/value-pairs. They are especially suitable for social networks and offer a natural model for the relationships between users.
Examples: Neo4j, BrightstarDB, GraphBase
OptimaData can help you in determining which NoSQL version or hybrid solution is most fitting to your situation.