In previous tutorials, we discussed how to use Elasticsearch native clients in Rust, Java, and Python among others. Today, we’re going to cover Node.js, - a popular JavaScript server-side solution based on event-driven architecture efficient for development of fast servers, I/O heavy applications, and real-time applications (RTAs). Node.js ecosystem is one of the fastest growing and it is now possible to interact with the Elasticsearch API using a Node.js client.

When we are indexing data, the task is rarely as simple as each document existing in isolation. Sometimes, we are better off denormalizing all data into the child documents. For example, if we were modeling blog posts, adding an author field to blog could be a sensible choice; even if in the database, the authoritative datasource, the data is split into separate authors and blogs table. It’s simple and one can easily construct queries on both attributes of the blogs and the author’s name.

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.

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.

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.

Elasticsearch is a different kind of beast, especially if you come from the world of SQL. It comes with many benefits: performance, scale, near real-time search, and analytics across massive amounts of data.

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., normalize 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.