تخزين واستعلام سجلّ المعاملات لمئات الملايين من الحسابات

Question

IT Interview Practice · Accepted Answer

**جزّئ دفتر الأستاذ (ledger) حسب الحساب والوقت، وأبقِ البيانات الحديثة ساخنة والقديمة باردة، وعامِل الصفوف كدفتر أستاذ ثابت للإلحاق فقط (append-only immutable) — كي يكون سجلّ حساب واحد شريحة صغيرة مُفهرَسة، لا مسح مليارات الصفوف.** نمط الوصول دائماً "حساب واحد، نطاق تواريخ"، فجزّئ كي تطابقه.

## البنية المعمارية

```text
Write ─▶ Ledger table (append-only, immutable)
          partition by (account_hash, month)
              │
     ┌────────┴─────────┐
  HOT tier            COLD tier
  last 3 mo           older
  Postgres/SSD        S3/Parquet, Glacier
     │                    │
  index-seek        keyset paginate ──▶ API (account+range)
```

## كيفية العمل

- **جزّئ حسب الحساب + الوقت.** هشّم معرّف الحساب إلى N دلواً، ثم جزّئ نطاقياً حسب الشهر. استعلام لحساب/شهر واحد يصيب جزءاً واحداً بالضبط — تُقلّم قاعدة البيانات البقية. هذا يحدّ كل قراءة بغضّ النظر عن الحجم الكلّي.
- **دفتر أستاذ ثابت (Immutable).** لا `UPDATE` معاملة أبداً؛ التصحيحات صفوف عكسية جديدة. هذا يعطي أثر تدقيق، ونسخاً آمناً، ويتيح التخزين المؤقت بقوّة (الصفوف لا تتغيّر أبداً).
- **التدرّج الساخن/البارد (Hot/cold tiering).** أبقِ آخر نحو 3 أشهر على SSD/Postgres سريع لقراءات منخفضة الزمن؛ ودحرج الأجزاء الأقدم إلى **S3/Parquet** (يُستعلَم عبر Athena/Trino) أو Glacier. 95% من الاستعلامات تصيب البيانات الحديثة، فمعظم التخزين يمكن أن يكون رخيصاً.
- **ترقيم بالمفتاح (Keyset pagination).** رقّم بـ `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — لا `OFFSET`. الـ offset يمسح ويرمي الصفوف المتخطّاة؛ أما keyset فيبحث في الفهرس مباشرة، بتعقيد O(1) لكل صفحة.

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

يتحرّى المُحاور **اختيار مفتاح التجزئة** و**الترقيم**. الإجابات الجيدة تقول "جزّئ حسب الحساب"؛ والرائعة تشرح **لماذا يتفوّق keyset على OFFSET** في الصفحات العميقة، ولماذا **دفتر الأستاذ ثابت** (قابلية التدقيق، لا تنافس أقفال)، وكيف يقلّل **التدرّج** التكلفة. فخّ: جدول عملاق واحد بفهرس مركّب — يعمل حتى لا يعود الفهرس يتّسع في RAM فتصبح كل قراءة مقيّدة بالقرص.

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

- **مفتاح التجزئة يصعب تغييره.** اختر الحساب+الوقت مسبقاً؛ إعادة تجزئة مئات الملايين من الصفوف لاحقاً مشروع هجرة.
- **الاستعلامات العابرة للحسابات تعاني.** "إجمالي الحجم عبر كل الحسابات" ينتشر الآن عبر الأجزاء — ادفع تلك إلى تجميع OLAP بدلاً منها.
- **القراءات الباردة بطيئة.** جلب كشف عمره 3 سنوات من Glacier يستغرق دقائق؛ اضبط توقّعات المستخدم أو سخّن مسبقاً عند الطلب.
- **الأجزاء الساخنة.** حساب ضخم (whale) أو الشهر الحالي قد يكون نقطة ساخنة؛ جزّئه فرعياً أو خزّنه في الكاش.
- **متى لا:** ملايين الصفوف (لا مئات الملايين) تتّسع في جدول Postgres مُفهرَس واحد — لا تبنِ تدرّجاً لن تحتاجه. الجأ إلى هذا عند النطاق الذي يتوقّف فيه فهرس جدول واحد عن الاتّساع في الذاكرة.

البنية المعمارية

كيفية العمل

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

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

أسئلة ذات صلة