Polyglot persistence: what is it and why does it matter?

Polyglot persistence is a way of storing data. It’s an approach that acknowledges that often there is no one size fits all solution to data storage. From the types of data you’re trying to store to your application architecture, polyglot persistence is a hybrid solution to data management.

Think of polyglot programming. If polyglot programming is about using a variety of languages according to the context in which your working, polyglot persistence is applying that principle to database architecture.

For example, storing transactional data in Hadoop files is possible, but makes little sense. On the other hand, processing petabytes of Internet logs using a Relational Database Management System (RDBMS) would also be ill-advised. These tools were designed to tackle specific types of tasks; even though they can be co-opted to solve other problems, the cost of adapting the tools to do so would be enormous. It is a virtual equivalent of trying to fit a square peg in a round hole.

Polyglot persistence: an example

For example, consider a company that sells musical instruments and accessories online (and in a network of shops). At a high-level, there are a number of problems that a company needs to solve to be successful:

• Attract customers to its stores (both virtual and physical).
• Present them with relevant products (you would not try to sell a drum kit to a pianist, would you?!).
• Once they decide to buy, process the payment and organize shipping.

To solve these problems a company might choose from a number of available technologies that were designed to solve these problems:

• Store all the products in a document-based database such as MongoDB, Cassandra, DynamoDB, or DocumentDB. There are multiple advantages of document databases: flexible schema, sharding (breaking bigger databases into a set of smaller, more manageable ones), high availability, and replication, among others.
• Model the recommendations using a graph-based database (such as Neo4j, Tinkerpop/Gremlin, or GraphFrames for Spark): such databases reflect the factual and abstract relationships between customers and their preferences. Mining such a graph is invaluable and can produce a more tailored offering for a customer.
• For searching, a company might use a search-tailored solution such as Apache Solr or ElasticSearch. Such a solution provides fast, indexed text searching capabilities.
• Once a product is sold, the transaction normally has a well-structured schema (such as product name, price, and so on.) To store such data (and later process and report on it) relational databases are best suited.

With polyglot persistence, a company always chooses the right tool for the right job instead of trying to coerce a single technology into solving all of its problems.

Read next:

How to optimize Hbase for the Cloud [Tutorial]

The trouble with Smart Contracts

Indexing, Replicating, and Sharding in MongoDB [Tutorial]