Genres of databases

Don’t ask: Can I use this database to store this data ?

Ask: Should I use this database to store this data?

It’s important to remember that most of the data problems you’ll face could be solved by most or all of the databases in this book, not to mention other databases. The question is less about whether a given database style could be shoehorned to model your data and more about whether it’s the best fit for your problem space, your usage patterns, and your available resources. You’ll learn the art of divining whether a database is intrinsically useful to you.

• Relational Databases

  • Relational database management systems are set-theory-based systems implemented as two-dimensional tables with rows and columns

  • Data values are typed and may be numeric, strings, dates, uninterpreted blobs, or other types

  • Tables can join and morph into new, more complex tables because of their mathematical basis in relational (set) theory

  • examples: MySQL, H2, HSQLDB, SQLite, PostgreSQL

• Key-Value

  • A KV store pairs keys to values in much the same way that a map (or hashtable) would in any popular programming language.

  • Because the KV moniker demands so little, databases of this type can be incredibly performant in a number of scenarios but generally won’t be helpful when you have complex query and aggregation needs

  • examples: memcached, memcachedb, membase, Voldemort, Redis, Riak

• Columnar

  • data from a given column is stored together.

  • adding columns is quite cheap and is done on a row-by-row basis.

  • Each row can have a different set of columns, or none at all, allowing tables to remain sparse without incurring a storage cost for null values.

  • With respect to structure, columnar is about midway between rela- tional and key-value.

  • examples: HBase, Cassandra, Hypertable.

• Document

  • Different document databases take different approaches with respect to indexing, ad hoc querying, replication, consistency, and other design decisions. Choosing wisely between them requires understanding these differences and how they impact your particular use cases.

  • examples: MongoDB, CouchDB

• Graph

  • graph databases excel at dealing with highly interconnected data.

  • A graph database consists of nodes and relationships between nodes.

  • Both nodes and relationships can have properties (as key-value pairs) that store data.

  • The real strength of graph databases is traversing through the nodes by following relationships.

• Polyglot

  • In real world, databases of one type are often used alongside databases of other types.

  • It’s still common to find a lone relational database, but over time it is becoming popular to use several databases together, leveraging their strengths to create an ecosystem that is more powerful, capable, and robust than the sum of its parts. This practice is known as polyglot persistence.