Tutorial Series: Data Modeling and Relationships in Elasticsearch
Handling relationships between entities is not as obvious as it is with a dedicated relational store. The golden rule of a relational database, i.e., normalise your data, does not apply to Elasticsearch. This tutorial series will walk through Handling Relationships, Nested Objects, and Parent-Child Relationship to discuss the pros and cons of each of the available approaches.
Complex relational databases can lead to tortuous SQL queries and slow responses from the web application. If you’re trying to return a long list of objects that are built up from five, ten or even seventeen related tables your response times can be unacceptably slow.
Such problems are encountered regularly in large and complex data modeling applications. We have found that using Elasticsearch along with some conventions for denormalising complex objects can make it easy to generate sufficiently speedy responses, even when they are returning lots of rows.
One of the key principles behind Elasticsearch is to allow you to make the most out of your data. Historically, search was a read-only enterprise where a search engine was loaded with data from a single source. As the usage grows and Elasticsearch becomes more central to your application, it happens that data needs to be updated by multiple components.
Multiple components lead to concurrency and concurrency leads to conflicts. Elasticsearch’s versioning system is there to help cope with those conflicts.
We discussed about Data Denormalization in our previous post Denormalization and Concurrency Issues in Elasticsearch and had emulated a filesystem with directory trees in Elasticsearch, much like a filesystem on Linux: the root of the directory is /, and each directory can contain files and subdirectories. The problem comes when we want to allow more than one person to rename files or directories at the same time. We shall be discussing about Concurrency issues and various kinds of locking in Elasticsearch in this post.