كيف تبني بحثاً نصّياً كاملاً (full-text search) على أكثر من 100 مليون سجلّ؟

Question

IT Interview Practice · Accepted Answer

استخدم محرّك بحث مخصّصاً — **Elasticsearch/OpenSearch مبنياً على فهرس مقلوب (inverted index)** — يُغذّى من قاعدة بيانات المصدر عبر **CDC**، وجزّئ الفهرس للتوسّع. قاعدة بياناتك الأساسية (Postgres/MySQL) لا يمكنها بحثاً نصّياً مرتّباً بالصلة (relevance-ranked) عبر مئات ملايين الصفوف؛ فـ `LIKE '%term%'` يمسح كل صفّ. محرّك البحث يقلب المسألة.

```text
Source DB ─▶ CDC (Debezium) ─▶ Kafka ─▶ Indexer ─▶ Elasticsearch/OpenSearch
(Postgres)   (change stream)                        ├─ Shard 0 (inverted index) + replicas
                                                     ├─ Shard 1
Query ─▶ Coordinator ─▶ scatter to shards ─▶ gather ─┴─ Shard N ── ranked by BM25
```

## الفهرس المقلوب — لماذا هو سريع

الفهرس العادي يربط صفّاً ← قيماً. أما **الفهرس المقلوب** فيربط *مصطلحاً ← قائمة المستندات التي تحتويه*. البحث عن "database scaling" يبحث عن قائمتَي إحالة (posting lists) قصيرتين ويتقاطعهما — بتعقيد O(المستندات المطابِقة) لا O(كل المستندات). هذا ما يجعل بحثاً في أقل من 100 مللي ثانية عبر أكثر من 100 مليون مستند ممكناً. يُحلَّل النص أولاً: يُقسَّم إلى رموز (tokenized)، ويُحوَّل إلى أحرف صغيرة، ويُجذَّر (stemmed) ("running" ← "run")، وتُسقَط الكلمات التوقّفية (stopwords) — كي تطابق الاستعلامات الصيغ المختلفة.

## الاستيعاب عبر CDC

لا تكتب كتابة مزدوجة (التطبيق يكتب في قاعدة البيانات *و* ES) — فالفشل يتركهما غير متّسقين. بدلاً من ذلك، تدفّق التغييرات بـ**التقاط تغيّر البيانات (Change Data Capture)**: يتتبّع **Debezium** سجل الكتابة المسبقة (write-ahead log) لقاعدة البيانات، وينشر تغييرات الصفوف إلى **Kafka**، ويطبّقها مُفهرِس (indexer) على Elasticsearch. هذا يُبقي البحث **متّسقاً نهائياً (eventually consistent)** مع المصدر وينجو من تعطّل ES (تُعاد الأحداث من Kafka).

## التجزئة والصلة

يُقسَّم الفهرس إلى **أجزاء (shards)** (كلٌّ فهرس Lucene قائم بذاته)، موزّعة عبر العُقد؛ و**الـ replicas** تضيف throughput قراءة وHA. الاستعلام يتشتّت إلى كل الأجزاء، كلٌّ يُعيد أفضل k عناصر، ويدمجها المنسّق. الصلة تستخدم **BM25** افتراضياً — تكرار المصطلح × تكرار المستند المقلوب (inverse document frequency) — قابلاً للضبط بالتعزيزات والمرادفات وأوزان الحقول.

## منظور المقابلة

يتحقّق المُحاورون مما إذا كنت (1) تلجأ إلى الأداة الصحيحة بدل `LIKE`، (2) تعرف *كيف* يعمل الفهرس المقلوب، (3) تحلّ **مشكلة المزامنة** دون كتابات مزدوجة. الجيد: "استخدم Elasticsearch." الرائع: تسمّي CDC/Debezium للاستيعاب، وBM25 للترتيب، وتقبل الاتساق النهائي كمقايضة للتوسّع.

**فخّ شائع:** معاملة Elasticsearch كمصدر للحقيقة. إنه فهرس مشتقّ — ليس معمّراً/معاملاتياً كقاعدة بياناتك. أعِد بناءه من المصدر عند الحاجة.

## المقايضات وأنماط الأعطال

- **الاتساق النهائي:** يتأخّر البحث عن الكتابات بزمن استجابة خطّ أنابيب CDC (عادةً أقل من ثانية).
- **ألم إعادة الفهرسة:** تغييرات الخريطة (mapping)/المحلّل تحتاج إعادة فهرسة كاملة — استخدم الأسماء المستعارة (aliases) للتبديل دون توقّف.
- **الترقيم العميق (Deep pagination):** الصفحة 10,000 مكلفة (scatter-gather) — استخدم `search_after` لا `from/size`.
- **جزء ساخن / انحراف:** توزيع مستندات غير متساوٍ؛ اختر مفتاح توجيه جيداً وأجزاءً كافية مسبقاً (فهي ثابتة عند الإنشاء).
- **ضبط الصلة مستمرّ:** إعدادات BM25 الافتراضية نادراً ما تطابق نيّة العمل — توقّع التكرار.

الفهرس المقلوب — لماذا هو سريع

الاستيعاب عبر CDC

التجزئة والصلة

منظور المقابلة

المقايضات وأنماط الأعطال

أسئلة ذات صلة