Evaluation criteria for nosql databases
Download as DOCX, PDF•1 like•1,421 views
The document provides evaluation criteria for NoSQL databases, focusing on data models, query models, consistency models, APIs, and community support. It outlines key data models, including document, graph, and key-value/column models, each with unique structures and querying capabilities. Additionally, it discusses the implications of consistency models and the importance of having robust APIs and support, especially as companies invest heavily in core technologies.
Evaluation criteria for nosql databases
- 1. Evaluation Criteria for NoSQL databases Evaluation Criteria for NoSQL databases By Ebenezer Daniel As technology and needs evolve and the need for scalable and high availability solutions increase there is a need to evaluate new databases. The lack of clarity in the market makes in difficult for IT stakeholders to understand the differences between the solutions available and the choice to make. The key areas to consider while evaluating NoSql databases are data model, query model, consistency model, APIs, support and community strength. 1 Data Model The different categories of data models available are Document Model, Graph Model, and the Key Value and column Model. The core structure of data models in NoSql databases differ from relational databases and fall into one of these categories. 1.1 Document Model In the document model JSON like structure documents, which is a well known format among developers. These can be aligned to objects in any object oriented programming. So each document is effectively an object. In a document database the schema is dynamic ie: each document can contain different fields. Rather than spreading the data across multiple columns and tables they are grouped together into a document. So the need for complex joins does not exist. Fields can also be added dynamically during development. Data can be queried based on any field within the database. These databases are general purpose and can be used with any object oriented programming language. The documents can be mapped to data objects within the development environment and hence quite suitable for the coding patterns being used.
- 2. Page 2 Databases available are – MongoDB, CouchDB, MarkLogic. 1.2 Graph Model Graph Databases use graph like structures with nodes and properties to represent data. Data is modelled as a network of relations between specific elements. The graph model takes more effort than a database model to understand and put into practice, but is quite useful in applications that require relationships between entities to be defined, such as social apps. Databases available are – Neo4J, Hypergraph. 1.3 Key Value and Column Models In this structure every item is stored as an attribute name or key, with its value. The value can be queried with the help of the key. It does not enforce a set scheme across the key values and so can represent unstructured data. In Column Models the data is stored in multidimensional sorted maps. Each record can vary in number of columns and columns can be nested within each other. Data is retrieved using the primary key for each column family. These are highly scalable and optimized for performance but used for a narrow set of applications that query data only with single key values. Databases available are – Big Table, MemcacheDB. 2 Query Model The biggest difference between NoSQL databases lies in the ability to query data efficiently. While some applications may need a very basic query model others may need more complex queries. For example an application that stores patient information may also lookup for doctors, lab tests, reports, procedures, visit details etc. It is also common for applications to update records with one or multiple fields. To satisfy these requirements the database may need to query on secondary indexes. 2.1 Document Databases Document databases provide the ability to query within any field within a document. Some of them provide multiple indexing options such as primary index, compound
- 3. Page 3 Newsletter Title index, unique indexes etc. Some of these databases provide the capability to analyse data. Multiple rows can be updated using single statements, rather than making round trips. 2.2 Graph Databases These systems provide a rich query model where simple and complex relationships can be interogated to make direct and indirect references to data. Relationship type analysis tends to be very efficient in these systems. 2.3 Key Value and Column Databases These systems provide the ability to retrieve and update data based only on a primary key. For querying on other values, users are encouraged to maintain their own indexes. Some products provide limited support for secondary indexes, but with several caveats. To perform an update in these systems, two round trips may be necessary: first find the record, then update it. In these systems, the update may be implemented as a complete rewrite of the record whether a few bytes have changed or the entire record. 3 Consistency Model NoSQL systems typically maintain multiple copies of the data for availability and scalability purposes.In these architectures, there different guarantees regarding the consistency of the data across copies.NoSQL systems tend to be consistent or eventually consistent. With a consistent system, writes by the application are immediately visible in subsequent queries. With an eventually consistent system writes are not immediately visible. As an example, when reflecting inventory levels for products in a product catalog, with a consistent system each query will see the current inventory as inventory levels are updated by the application, whereas with an eventually consistent system the inventory levels may not be accurate for a query at a given time, but will eventually become accurate.For this reason application code tends to be somewhat different for eventually consistent systems - rather than updating the inventory by taking the current
- 4. Page 4 inventory and subtracting one, for example, developers are encouraged to issue idempotent queries that explicitly set the inventory level. Consistent Systems Each application has different requirements for data consistency. For many applications, it is imperative that the data be consistent at all times. As development teams have worked under a model of consistency with relational databases for decades, this approach is more natural and familiar. In other cases,eventual consistency is an acceptable trade-off for the flexibility it allows in the system’s availability Document databases and graph databases can be consistent or eventually consistent. Eventually Consistent Systems With eventually consistent systems, there is a period of time in which all copies of the data are not synchronized. This may be acceptable for read-only applications and data stores that do not change often, like historical archives. By the same token, it may also be appropriate for high-write use cases in which the database is capturing information like logs, which will only be read at a later point in time. Key-value and wide column stores are typically eventually consistent. Eventually consistent systems must be able to accommodate conflicting updates in individual records.Because writes can be applied to any copy of the data,it is possible and not uncommon for writes to conflict with one another. 4 APIs There is no standard for interfacing with NoSQL systems. Each system presents different designs and capabilities for application development teams. The maturity of the API can have major implications for the time and cost required to develop and maintain the underlying NoSQL system. 4.1 Idiomatic Drivers There are a number of popular programming languages, and each provides different paradigms for working with data and services. Idiomatic drivers are created by development teams that are experts in the given language and that know how
- 5. Page 5 Newsletter Title programmers prefer to work within that language. This approach can also benefit from its ability to leverage specific features in a programming language that might provide efficiencies for accessing and processing data. For programmers, idiomatic drivers are easier to learn and use, and they reduce the onboarding time for teams to begin working with the underlying system.For example,idiomatic drivers provide direct interfaces to set and get documents or fields within documents.With other types of interfaces it may be necessary to retrieve and parse entire documents and navigate to specific values in order to set or get a field. MongoDB supports idiomatic drivers in over a dozen languages: Java, .NET, Ruby, Node.js, Perl, Python, PHP, C, C++, Erlang, Javascript, Haskell and Scala. Other drivers are supported by the community. 4.2 Restful APIs Some systems provide RESTful interfaces. This approach has the appeal of simplicity and familiarity, but it relies on the inherent latencies associated with HTTP. It also shifts the burden of building an interface to the developers; and this interface is likely to be inconsistent with the rest of their programming interfaces. Similarly, some systems provide a Thrift interface, a very low level paradigm that shifts the burden to developers to develop more abstract interfaces within their applications. 5 Commercial Support and Community Strength Choosing a database is a major investment. Once an application has been built on a given database, it is costly and challenging to migrate it to a different database. Companies usually invest in a small number of core technologies so they can develop expertise, integrations and best practices that can be amortized across many projects. NoSQL systems are relatively new, and while there are many options in the market, a small number of products will stand the test of time. Data Model Key–value Stores Performance high Scalability high Flexibility Complexity high none Functionality variable (none)
- 6. Page 6 29th December Data Model Performance Scalability Column Store high high Document Store high Graph Database Flexibility Complexity moderate Functionality low minimal variable (high) high low variable (low) variable variable high high graph theory Relational Database variable variable low moderate relational algebra. A caption describes the picture or graphic. Please see Great Articles on page 4