When dealing with one of our projects (LookSMI media monitoring platform) we have to handle the huge volume of data – and its quantity is constantly growing. At the same time, we must run quick searches with smart rules. To make this work, the whole index should be placed into RAM.
LookSMI Case: Using Shards for the News Portal
It is obvious that when millions of records are being added to the index regularly, RAM size would never be enough. Eventually, you will have to divide index into several parts in order to run search on several machines simultaneously.
LookSMI is dealing with the news, which means that the portal is heavily working with the new records while almost not using the older ones. LookSMI utilizes Solr as a full-text search engine. To ensure fast search within recent records, we decided to shard LookSMI's index.
Sharding is a type of database partitioning that separates very large databases the into smaller and faster, parts called data shards. The word shard itself means a 'small part of a whole'. Technically, sharding means horizontal partitioning but in practice, the term is often used to refer to any database partitioning that is meant to make a very large database more manageable and easier to search through.
Accordingly, we partitioned LookSMI's search index into shards where each shard corresponds with one month. A limited number of shards are set to be active concurrently – just a few last months. Thus, all data a user needs is housed in RAM.
Whenever there is a need, older shards can be activated to accomplish necessary request – and then deactivated. Moreover, when filtering the search by predefined date, we can engage just a part of active shards so that the search is performed only on those servers where the data for the specified period is located.
Steb-by-step Guide to Arranging Solr Sharding
There are several ways to arrange sharding in Solr. The easiest one is to divide index into a few cores. Hence, when carrying out a search query, Solr should be commanded to perform search throughout several cores simultaneously.
First, you should create cores with the identical structure. This can be easily done with the help of cores’ pattern.
For starters, copy configuration files into the configsets folder:
cp sorl/data//conf solr/data/configsets/conf
Then specify the folder’s name when creating the core:
mkdir solr/data/configsets/
cp solr/data/configsets/conf solr/data/configsets//confWe have automated the process of creating the cores so that new cores are proactively set up every month:
http:///solr/admin/cores?action=CREATE&name=&instanceDir=path/to/instance&configSet=path/to/instance/`When the cores are created, revise the code so that data would be added to a specific core while performing a concurrent search over the other cores:
http:///solr/select?q=*:*&shards=http:///solr/,http:///solr/`Then, revise the code so that data would be recorded to a corresponding core:
Cores can be located on different servers. Furthermore, they can be arranged not only by time periods but also by categories.
Don’t be afraid to create multiple cores as resource overheads under these conditions are quite small. On the other hand, sharding makes database systems smoothly scalable and helps to deal with the problem of slower response times for growing indexes.
Subscribe for the news and updates
One of our ongoing projects, Neptyne, introduces an Excel-like grid written in React. We used a library to apply virtual scroll to it, but we stumbled upon a problem with fixed rows and columns inside the grid. Here I would like to describe this problem, how it occurs, and how we handled it.
Django ORM is a very abstract and flexible API. But if you do not know exactly how it works, you will likely end up with slow and heavy views, if you have not already. So, this article provides practical solutions to N+1 and high loading time issues. For clarity, I will create a simple view that demonstrates common ORM query problems and shows frequently used practices.
Protection of WEB App is of paramount importance and it should be afforded the same level of security as the intellectual rights or private property. I'm going to cover how to protect your web app.
There is such a term as Remote Procedure Call (RPC). In other words, by using this technology, programs can call functions on remote computers. There are many ways to implement RPC.
For any project there may be a need to use a database full-text search. We expect high speed and relevant results from this search. When we face such problem, we usually think about Solr, ElasticSearch, Sphinx, AWS CloudSearch, etc. But in this article we will talk about PostgreSQL. Starting from version 8.3, a full-text search support in PostgreSQL is available. Let's look at how it is implemented in the DBMS itself.
Everybody knows about permalink, but it's usually used only in get_absolute_url. I prefer to use it for all related model urls.class Event(models.Model):# ...@models.permalinkdef edit_url(self):return ('event_edit', (self.pk, ))And then in template:<a href="{{ event.edit_url }}">Редактировать событие</a>
