{"id":468,"date":"2014-12-07T20:30:05","date_gmt":"2014-12-07T20:30:05","guid":{"rendered":"http:\/\/adriangrigoras.com\/blog\/?p=468"},"modified":"2015-02-07T20:31:53","modified_gmt":"2015-02-07T20:31:53","slug":"35-cases-choosing-nosql-database","status":"publish","type":"post","link":"https:\/\/adriangrigoras.com\/blog\/35-cases-choosing-nosql-database\/","title":{"rendered":"35+ Use Cases For Choosing Your Next NoSQL Database"},"content":{"rendered":"<h2>What Are Your Options?<\/h2>\n<p>First, let&#8217;s cover what are the various data models. These have been adapted from <a href=\"http:\/\/blogs.neotechnology.com\/emil\/2009\/11\/nosql-scaling-to-size-and-scaling-to-complexity.html\">Emil Eifrem<\/a>and <a href=\"http:\/\/nosql-database.org\/\">NoSQL databases<\/a>.<\/p>\n<p><strong>Document Databases<\/strong><\/p>\n<ul>\n<li>Lineage: Inspired by Lotus Notes.<\/li>\n<li>Data model: Collections of documents, which contain key-value collections.<\/li>\n<li>Example: CouchDB, MongoDB<\/li>\n<li>Good at: Natural data modeling. Programmer friendly. Rapid development. Web friendly,\u00a0CRUD.<\/li>\n<\/ul>\n<div><\/div>\n<div><\/div>\n<div><\/div>\n<div><strong>Graph Databases<\/strong><\/div>\n<div>\n<ul>\n<li>Lineage: Euler and graph theory.<\/li>\n<li>Data model: Nodes &amp; relationships, both which can hold key-value pairs<\/li>\n<li>Example: AllegroGraph, InfoGrid, Neo4j<\/li>\n<li>Good at: \u00a0Rock complicated graph problems. Fast.<\/li>\n<\/ul>\n<\/div>\n<div><\/div>\n<div><\/div>\n<div><\/div>\n<div><strong>Relational Databases<\/strong><\/div>\n<div>\n<ul>\n<li>Lineage:\u00a0E. F. Codd in\u00a0<a href=\"http:\/\/www.seas.upenn.edu\/~zives\/03f\/cis550\/codd.pdf\">A Relational Model of Data for Large Shared Data Banks<\/a><\/li>\n<li>Data Model:\u00a0a set of relations<\/li>\n<li>Example: VoltDB, \u00a0Clustrix, MySQL<\/li>\n<li>Good at: High performing, scalable OLTP. SQL access. Materialized views. Transactions matter. Programmer friendly transactions.<\/li>\n<\/ul>\n<\/div>\n<p><strong>Object Oriented Databases<\/strong><\/p>\n<ul>\n<li>Lineage: Graph Database Research<\/li>\n<li>Data Model: Objects<\/li>\n<li>Example: Objectivity, Gemstone<\/li>\n<li>Good at: complex object models, fast key-value access, key-function access, and graph database functionality.<\/li>\n<\/ul>\n<p><strong>Key-Value Stores<\/strong><\/p>\n<ul>\n<li>Lineage: Amazon&#8217;s\u00a0<a href=\"http:\/\/www.allthingsdistributed.com\/2007\/10\/amazons_dynamo.html\">Dynamo paper<\/a>\u00a0and\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/Distributed_hash_table\">Distributed HashTables<\/a>.<\/li>\n<li>Data model: A global collection of KV pairs.<\/li>\n<li>Example: Membase, Riak<\/li>\n<li>Good at: Handles size well. Processing a constant stream of small reads and writes. Fast. Programmer friendly.<\/li>\n<\/ul>\n<div><\/div>\n<div><\/div>\n<div><\/div>\n<div><strong>BigTable Clones\u00a0<\/strong><\/div>\n<div>\n<ul>\n<li>Lineage: Google&#8217;s\u00a0<a href=\"http:\/\/labs.google.com\/papers\/bigtable.html\">BigTable paper<\/a>.<\/li>\n<li>Data model: Column family, i.e. a tabular model where each row at least in theory can have an individual configuration of columns.<\/li>\n<li>Example: HBase, Hypertable, Cassandra<\/li>\n<li>Good at: Handles size well. Stream massive write loads. High availability. Multiple-data centers. MapReduce.<\/li>\n<\/ul>\n<\/div>\n<div><\/div>\n<div><\/div>\n<div><\/div>\n<div><strong>Data Structure Servers<\/strong><\/div>\n<div>\n<ul>\n<li>Lineage: ?<\/li>\n<li>Example: Redis<\/li>\n<li>Data model: Operations over dictionaries, lists, sets and string values.<\/li>\n<li>Good at: Quirky stuff you never thought of using a database for before.<\/li>\n<\/ul>\n<\/div>\n<div><\/div>\n<div><\/div>\n<div><\/div>\n<div><strong>Grid Databases<\/strong><\/div>\n<div>\n<ul>\n<li>Lineage: Data Grid and Tuple Space research.<\/li>\n<li>Data Model: Space Based Architecture<\/li>\n<li>Example: GigaSpaces, Coherence<\/li>\n<li>Good at: High performance and scalable transaction processing.<\/li>\n<\/ul>\n<\/div>\n<h2>What Should Your Application Use?<\/h2>\n<ul>\n<li>Key point is to rethink how your application could work differently in terms of the different data models and the different products. Right data model for the right problem. Right product for the right problem.<\/li>\n<li>To see what models might help your application take a look at\u00a0<a href=\"http:\/\/highscalability.com\/blog\/2010\/12\/6\/what-the-heck-are-you-actually-using-nosql-for.html\">What The Heck Are You Actually Using NoSQL For?<\/a>\u00a0In this article I tried to pull together a lot of unconventional use cases of the different qualities and features developers have used in building systems.<\/li>\n<li>Match what you need to do with these use cases. From there you can backtrack to the products you may\u00a0want to include in your architecture. NoSQL, SQL, it doesn&#8217;t matter.<\/li>\n<li>Look at Data Model + Product Features + Your Situation.\u00a0Products have such different feature sets it&#8217;s almost impossible to recommend by pure data model alone.<\/li>\n<li>Which option is best is determined by your priorities.<\/li>\n<\/ul>\n<h2>\u00a0If Your Application Needs&#8230;<\/h2>\n<ul>\n<li><strong>complex transactions<\/strong> because you can&#8217;t afford to lose data or if you would like a simple transaction programming model then look at a Relational or Grid database.\n<ul>\n<li>Example: an inventory system that might want full ACID. I was very unhappy when I bought a product and they said later they were out of stock. I did not want a compensated transaction. I wanted my item!<\/li>\n<\/ul>\n<\/li>\n<li><strong>to scale<\/strong> then NoSQL or SQL can work. Look for systems that support scale-out, partitioning, live addition and removal of machines, load balancing, automatic sharding and rebalancing, and fault tolerance.<\/li>\n<li>to <strong>always<\/strong> be able to <strong>write<\/strong> to a database because you need high availability then look at Bigtable Clones which feature eventual consistency.<\/li>\n<li>to handle lots of <strong>small continuous reads and writes<\/strong>, that may be volatile, then look at Document or Key-value or databases offering fast in-memory access. Also consider SSD.<\/li>\n<li>to implement <strong>social network operations<\/strong> then you first may want a Graph database or second, a database like Riak that supports relationships. An in- memory\u00a0relational\u00a0database with simple SQL joins might suffice for small data sets. Redis&#8217;\u00a0set and list operations could work too.<\/li>\n<\/ul>\n<h2>If Your Application Needs&#8230;<\/h2>\n<ul>\n<li>to operate over a <strong>wide variety <\/strong>of<strong> access patterns<\/strong> and <strong>data types<\/strong> then look at a Document database, they generally are flexible and perform well.<\/li>\n<li>powerful <strong>offline reporting<\/strong> with <strong>large datasets<\/strong> then look at Hadoop first and second, products that support MapReduce. Supporting MapReduce isn&#8217;t the same as being good at it.<\/li>\n<li>to <strong>span multiple data-centers<\/strong> then look at Bigtable Clones and other products that offer a distributed option that can handle the long\u00a0latencies\u00a0and are partition tolerant.<\/li>\n<li>to build <strong>CRUD<\/strong> apps then look at a Document database, they make it easy to access complex data without joins.<\/li>\n<li>built-in <strong>search<\/strong> then look at Riak.<\/li>\n<li>to operate on <strong>data structures<\/strong> like lists, sets, queues, publish-subscribe\u00a0then look at Redis. Useful for distributed locking, capped logs, and a lot more.<\/li>\n<li><strong>programmer friendliness<\/strong> in the form of programmer friendly data types like JSON, HTTP, REST, Javascript then first look at Document databases and then Key-value Databases.<\/li>\n<\/ul>\n<h2>If Your Application Needs&#8230;<\/h2>\n<ul>\n<li><strong>transactions<\/strong> combined with <strong>materialized views<\/strong> for <strong>real-time<\/strong> data feeds then look at VoltDB. Great for data-rollups and time windowing.<\/li>\n<li><strong>enterprise level support<\/strong> and <strong>SLAs<\/strong> then look for a product that makes a point of catering to that market. Membase is an example.<\/li>\n<li>to log <strong>continuous streams<\/strong> of data that may have no consistency\u00a0guarantees\u00a0necessary at all then look at Bigtable Clones because they generally work on distributed file systems that can handle a lot of writes.<\/li>\n<li>to be as <strong>simple as possible<\/strong> to operate then look for a hosted or PaaS solution because they will do all the work for you.<\/li>\n<li>to be sold to <strong>enterprise customers<\/strong> then consider a Relational Database because they are used to relational technology.<\/li>\n<li>to<strong> dynamically<\/strong> build <strong>r<\/strong><strong>elationships<\/strong> between objects that have <strong>dynamic properties<\/strong> then consider a Graph Database because often they will not require a schema and models can be built incrementally through programming.<\/li>\n<li>to support <strong>large media<\/strong> then look storage services like S3. NoSQL systems tend not to handle large BLOBS, though MongoDB has a file service.<\/li>\n<\/ul>\n<h2>If Your Application Needs&#8230;<\/h2>\n<ul>\n<li>to <strong>bulk upload<\/strong> lots of data quickly and efficiently then look for a product supports that scenario. Most will not because they don&#8217;t support bulk operations.<\/li>\n<li>an <strong>easier upgrade path<\/strong> then use a fluid schema system like a Document Database or a Key-value Database because it supports optional fields, adding fields, and field deletions without the need to build an entire schema migration framework.<\/li>\n<li>to implement <strong>integrity constraints<\/strong> then pick a database that support SQL DDL, implement them in stored procedures, or implement them in application code.<\/li>\n<li>a very deep join depth the use a Graph Database because they support blisteringly fast navigation between entities.<\/li>\n<li>to move <strong>behavior close to the data<\/strong> so the data doesn&#8217;t have to be moved over the network then look at stored\u00a0procedures\u00a0of one kind or another. These can be found in Relational, Grid, Document, and even Key-value databases.<\/li>\n<\/ul>\n<h2>If Your Application Needs&#8230;<\/h2>\n<ul>\n<li>to <strong>cache or store BLOB data<\/strong> then look at a Key-value store. Caching can for bits of web pages, or to save complex objects that were expensive to join in a relational database, to reduce latency, and so on.<\/li>\n<li>a <strong>proven track record<\/strong> like not corrupting data and just generally working then pick an established product and when you hit scaling (or other issues) use on of the common workarounds (scale-up, tuning, memcached, sharding, denormalization, etc).<\/li>\n<li><strong>fluid data types<\/strong> because your data isn&#8217;t tabular in nature, or requires a flexible number of columns, or has a complex structure, or varies by user (or whatever), then look at Document, Key-value, and Bigtable Clone databases. Each has a lot of flexibility in their data types.<\/li>\n<li>other business units to <strong>run quick relational queries<\/strong> so you don&#8217;t have to reimplement everything then use a database that supports SQL.<\/li>\n<li>to operate in the cloud and automatically take full advantage of cloud features then we may not be there yet.<\/li>\n<\/ul>\n<h2>If Your Application Needs&#8230;<\/h2>\n<ul>\n<li>support for <strong>secondary indexes<\/strong> so you can look up data by different keys then look at relational databases and Cassandra&#8217;s new secondary index support.<\/li>\n<li>creates an <strong>ever-growing set of data<\/strong>\u00a0(really BigData) that rarely gets accessed then look at Bigtable Clone which will spread the data over a distributed file system.<\/li>\n<li>to <strong>integrate with other services<\/strong> then check if the database provides some sort of write-behind\u00a0syncing feature so you can capture database changes and feed them into other systems to ensure consistency.<\/li>\n<li><strong>fault tolerance<\/strong> check how durable writes are in the face power failures, partitions, and other failure scenarios.<\/li>\n<li>to <strong>push<\/strong> the <strong>technological<\/strong> envelope in a direction nobody seems to be going then build it yourself because that&#8217;s what it takes to be great sometimes.<\/li>\n<li>to work on a <strong>mobile platform<\/strong> then look at CouchDB\/<a href=\"http:\/\/www.couchbase.com\/products-and-services\/mobile-couchbase\">Mobile couchbase<\/a>.<\/li>\n<\/ul>\n<h2>Which Is Better?<\/h2>\n<ul>\n<li>Moving for a 25% improvement is probably not a reason to go NoSQL.<\/li>\n<li>Benchmark relevancy depends on the use case. Does it match your situation(s)?<\/li>\n<li>Are you a startup that needs to release a product as soon as possible and you are playing around with ideas? Both SQL and NoSQL can make an argument.<\/li>\n<li>Performance may be equal on one box, but what happens when you need N?<\/li>\n<li>Everything has problems, if you look at Amazon forums it&#8217;s EBS is slow, or my instances won&#8217;t reply, etc. For GAE it&#8217;s the datastore is slow or X. Every product which people are using will have problems. Are you OK with the problems of the system you&#8217;ve selected?<\/li>\n<\/ul>\n<p>Source:\u00a0highscalability.com<\/p>\n","protected":false},"excerpt":{"rendered":"<p>What Are Your Options? First, let&#8217;s cover what are the various data models. These have been adapted from Emil Eifremand NoSQL databases. Document Databases Lineage: Inspired by Lotus Notes. Data model: Collections of documents, which contain key-value collections. Example: CouchDB, MongoDB Good at: Natural data modeling. Programmer friendly. Rapid development. Web friendly,\u00a0CRUD. Graph Databases Lineage:\u2026 <span class=\"read-more\"><a href=\"https:\/\/adriangrigoras.com\/blog\/35-cases-choosing-nosql-database\/\">Read More &raquo;<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[30],"tags":[],"class_list":["post-468","post","type-post","status-publish","format-standard","hentry","category-architecture"],"_links":{"self":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/468","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/comments?post=468"}],"version-history":[{"count":2,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/468\/revisions"}],"predecessor-version":[{"id":470,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/468\/revisions\/470"}],"wp:attachment":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/media?parent=468"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/categories?post=468"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/tags?post=468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}