An alternative way to ElasticSearch

How-tos

all

Index Engine

This article is for those who have dealt with the complexity of Elasticsearch or any other indexing machines and are looking for an easier way to index the existing database without additional effort.


**Why this post?**

 
The amount of data increases every day. As a result, the search in the databases becomes longer and longer. Conventional data structures must be realigned in order to be able to access information more quickly. There are already database systems like Elasticsearch that can do this. However, such systems also have disadvantages.

The most noticeable major drawbacks are:**Who will benefit from this post?**

 
This information is useful for any programmer who wants to integrate an index database into his existing system in a simple way without additional effort. **The basic idea behind Indexing-machines**
 
We will use this simple Table to demonstrate what an Index-machine does Tablename: object ```
 
UID TITLE DESCRIPTION 4711 Rudyard Kipling If you can keep your head when all about you … 4712 John Magee I have slipped the surly bonds of Earth and danced the skies on laugher-silvered wings … 4713 Wiliam Wordsworth Ten thousand saw I at a glance, Tossing their heads in sprightly dance… ```
 
 
With this request we can find very specific texts in this single table:

```But what if we want to find ‚%head%‘ in all tables of our database? We have to write a code to do this job for us. This is inefficent and will work very slowy. The idea behind Elasticsearch and other indexing tables is – so far I understood – to break the strings in single tokens. That means in a very easy way that we have to transform the horicontal order of the table into a vertical order.

```
 
Tablename: ncp_index

UID TABLENAME FIELDNAME ID TOKEN1011 object Description 4712 have
1012 object Description 4712 slipped
…
 
```


We can tokenize any field of any table of our database into the table ncp_index. Now we can find with a single query very fast any (tokenized) word in our hole database.Every field is stored in a system table and has a unique id. let us call it field_id
Every content of a field has a lot of same words. These words should be stored only once in a separat words-table.

 
Our ncp_index table looks now so: ```
 
UID FIELD_ID ID TOKEN_ID
1001 123 4711 1
1002 123 4711 22 you
3 can
…
 
```


**Some basic examples****Conclusion**

 
These are my basic observations on this subject. These are the first steps to a search-engine that can index existing tables so that informations can be found quickly. **Thanks to**
 
Translated with www.DeepL.com/Translator Elasticsearch: https://www.elastic.co/blog/a-practical-introduction-to-elasticsearch **Github**
 
https://github.com/Necip8/ncp_search I hope this information helps you to build your own super search engine!