Elasticsearch ও full-text search: inverted index কীভাবে কাজ করে
LIKE দিয়ে টেক্সট খোঁজা ধীর। Elasticsearch দ্রুত, ranked সার্চের জন্য inverted index বানায়। এটি কীভাবে কাজ করে ও কোথায় মানায়, জানুন।
WHERE body LIKE '%payment%'-এর মতো query প্রতিটি row স্ক্যান করে এবং ফলাফলের ক্রম দিতে পারে না। Elasticsearch (Apache Lucene-এর ওপর তৈরি) full-text search-এর জন্যই বানানো।
Inverted index
"ডকুমেন্ট, তারপর শব্দ"-এর বদলে এটি রাখে "শব্দ, তারপর ডকুমেন্ট":
| শব্দ | ডকুমেন্ট |
|---|---|
| payment | 3, 8, 21 |
| refund | 8, 40 |
| delay | 3, 40 |
"payment refund" খুঁজতে দুটি শব্দের তালিকা বের করে মিলিয়ে নেয়। লক্ষ লক্ষ ডকুমেন্টেও এটি দ্রুত।
Analysis
Index করার আগে টেক্সট analyzer দিয়ে যায়: শব্দে ভাঙা, ছোট হাতের করা, সাধারণ শব্দ বাদ, এবং শব্দকে মূলে আনা ("running" থেকে "run")। Query-তেও একই ধাপ চলে, তাই "Refunds" মিলে যায় "refund"-এর সাথে।
Relevance
ফলাফল score দিয়ে সাজানো হয়, সাধারণত BM25, যা দেখে একটি শব্দ ডকুমেন্টে কতবার আছে, সব ডকুমেন্টে কতটা বিরল এবং ডকুমেন্টের দৈর্ঘ্য। ফিল্ডে boost দেওয়া যায়, যেমন title-এর মিল body-র চেয়ে বেশি গুরুত্ব পাবে।
শুরু থেকেই distributed
একটি index ভাগ হয় shard-এ, node-দের মধ্যে ছড়ায়, আর প্রতিটি shard-এর replica থাকতে পারে। সার্চ সব shard-এ সমান্তরালে চলে এবং ফল মেলানো হয়। Write অল্প refresh-এর (ডিফল্টে প্রায় এক সেকেন্ড) পর সার্চযোগ্য হয়, তাই এটি near real-time, তাৎক্ষণিক নয়।
সাধারণ ব্যবহার
সাইট সার্চ, log search (ELK/Elastic stack), autocomplete, filter ও faceted navigation, এবং টেক্সট analytics।
যা এটি নয়
- এটি আপনার primary database নয়। মূল সত্য relational বা অন্য store-এ রাখুন, আর data Elasticsearch-এ sync করুন।
- একাধিক ডকুমেন্টের transaction নেই।
- Mapping ভুল ও অতিরিক্ত shard সত্যিই কষ্ট দেয়, তাই আগে পরিকল্পনা করুন।
ছোট সাইটে আলাদা cluster যোগ করার আগে PostgreSQL বা SQLite-এর বিল্ট-ইন সার্চই যথেষ্ট হতে পারে।
মূল কথা: টেক্সট সার্চ ও ranking-এর জন্য inverted-index ইঞ্জিন নিন, মূল database-কে সত্যের উৎস রাখুন, আর index sync-এ রাখুন।
System Design সিরিজ, পর্ব ২ (building block): 4 নম্বর (মোট 14)। আগের লেখা: RabbitMQ: exchange, queue ও routing.
