Polyglot persistence is an enterprise storage term used to describe choosing different data storage/data stores technologies to support the various data types and their storage needs. Polyglot persistence is essentially the idea that an application can use more than one core database (DB)/storage technology.
Polyglot persistence suggests that database engineers/architects first figure out how they want to manipulate data and then choose the database technology that best fits their needs. This approach is used to solve data storage efficiency issues, simplify operations and eliminate fragmentation.
Polyglot persistence uses the same ideas as polyglot programming, which is the practice of writing applications using a mix of languages in order to take full advantage of the fact that various languages are suitable for solving different problems.
Polyglot is defined as someone who can speak and write in several languages. In data storage, the term persistence means that data survives after the process with which it was created has ended. In other words, data is stored in non-volatile storage.
An enterprise should ask several questions before it makes the decision to implement polyglot persistence. Some of these specific questions include:
- How will the enterprise be trained to work with the new system?
- Is there an expert available who can help get the system up and running?
- Can this expert mentor the rest of the staff?
- Who can provide support and repairs should a problem occur?
Once satisfactory answers have been found for each of these questions, polyglot persistence can be implemented to help an enterprise begin to make the move away from relational databases and towards a mixture of data sources.
How to use polyglot persistence
Unfortunately, polyglot persistence cannot be downloaded; it must be designed for the specific data architecture used by an enterprise. However, it has the flexibility to be used with SQL, NoSQL or hybrid database systems.
Various factors should be taken into consideration when deciding to move to a polyglot persistence storage system. For example, if big data is used in the promotion of a business or product, then changes will have to be made to the system to support this practice. The most ideal environment is one where only one persistence technology exists; however, this is not suitable for big data problem solving. Another database will need to be introduced along with other supporting technologies in order to sustain the new implementation. Whether or not it is necessary to support ACID compliance versus BASE compliance -- basic availability, soft-state and eventual consistency -- should also be considered.
The most important factor to understand is the data flow within the organization. An easy way to do this is to establish an owner for each piece of data in the system. Introducing this detail at the overall system architecture level will allow developers to see which owner is able to modify their corresponding piece of data as well as how this data will be distributed in the system, thus making the work on each of the different pieces of data more feasible.
Once the data flow is recognized and defined, the decision of placing the data in a table or a document model must be made. This decision depends on the programmer's preference as well as the specifics of the current problem. However, the decision between a table or document model is reversible and will have a local, not a global, impact.
Several solutions are available to automate polyglot persistence, such as CloudBoost.io. CloudBoost.io provides a simple application program interface (API) that can be used to store and query the data. It also uses artificial intelligence (AI) to automatically store the data into the appropriate areas of the database.
Data storage types
Polyglot persistence uses data storage types such as:
Polyglot persistence strengths and weaknesses
Some strengths of polyglot persistence include:
- Simplifies operations
- Eliminates fragmentation
- Creates faster response time
- Improves efficiency
- Scales extremely well
- Allows database engineers/architects to decide where data is stored
Weaknesses of polyglot persistence include:
- Must be designed from the ground up based on the specific data architecture of an enterprise -- there are no out of the box solutions
- Database engineers/architects must choose where to store data
- Database interactions become more complicated
- New data stores mean increased complexity and a need for more training
- Maintenance and repairs take longer
- Database integration increases operational and engineering expenses
Example of polyglot persistence
An e-commerce store is a good example of where an organization might apply polyglot persistence. An online store uses many types of data for the shopping cart alone -- such as transactional, session, inventory, completed orders and customer profiles.
In the past, enterprises might use a single database engine to handle the data required for an e-commerce application. Doing so would require extensive data conversion to format the different data types for a single, relational database.
Polyglot persistence suggests that the shopping cart (and related e-commerce) data be divided into databases that are best suited for each data type.