كيف تُصدّر مجموعة بيانات ضخمة دون التأثير على النظام الحيّ؟

Question

IT Interview Practice · Accepted Answer

**اقرأ من replica أو لقطة (snapshot) (لا من الـ primary أبداً)، ورقّم بترقيم المفتاح (keyset pagination) بدل `OFFSET`، واضبط معدّل القراءة، ودفّق النتائج مباشرة إلى تخزين الكائنات.** الهدف تصدير 500 مليون صفّ دون إمساك أقفال طويلة، أو ذروة CPU على الـ primary، أو تفجير الذاكرة.

## خطّ أنابيب التصدير

```text
  Primary DB ──async replication──▶ Read replica / snapshot
                                          │  (isolated from live traffic)
                                          ▼
                                   Export worker
                              keyset page: WHERE id > :last
                                          │  throttle (sleep / rate limit)
                                          ▼
                                   Stream (batches)
                                          │
                                          ▼
                                   S3 / GCS  (NDJSON / Parquet)
```

## لماذا كل جزء

- **Read replica أو لقطة.** وجّه المهمّة إلى تابع (follower) كي لا تنافس القراءات الثقيلة كتابات الإنتاج على الـ primary. **اللقطة** تعطي عرضاً ثابتاً لنقطة زمنية كي يكون التصدير متّسقاً حتى مع استمرار تغيّر البيانات الحيّة.
- **ترقيم المفتاح لا `OFFSET`.** `OFFSET 10000000` يجعل قاعدة البيانات تمسح وترمي 10 ملايين صفّ في كل صفحة — بتعقيد O(n²) عبر التصدير. keyset يتذكّر آخر مفتاح ويُنفّذ `WHERE id > :last ORDER BY id LIMIT 5000`، الذي يركب الفهرس بتعقيد O(1) لكل صفحة.
- **الضبط (Throttle).** نَم بين الدفعات أو حُدّ الصفوف/ثانية كي لا يُشبَع الـ replica ويبقى تأخّر النسخ محدوداً.
- **دفّق إلى مخزن الكائنات.** اكتب كل دفعة إلى S3/GCS بصيغة NDJSON أو Parquet؛ لا تحمّل مجموعة النتائج كلها في الذاكرة أبداً. استخدم مؤشّراً (cursor/server-side cursor) كي يدفّق المشغّل (driver) الصفوف.

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

يتحقّق المُحاور مما إذا كنت تحمي النظام الحيّ. تسمية **replica** أساسية؛ وإشارة الأقدمية هي **keyset فوق OFFSET** (والقدرة على شرح فخّ O(n²)) مع **الضغط العكسي/الضبط** و**الاتساق** عبر لقطة. فخّ شائع: `SELECT *` واحد في معاملة واحدة — يُبقي عرض قراءة مفتوحاً لساعات، ويُنفّخ قاعدة البيانات (لا يستطيع vacuum في Postgres تنظيف الصفوف التي لا تزال اللقطة الطويلة تراها)، ويخزّن كل شيء في الذاكرة.

**المقايضات:** قد يتأخّر الـ replica، فيعكس التصدير لحظة قديمة قليلاً — عادةً لا بأس للتحليلات، لكن ليس للتسوية المالية التي تحتاج بيانات دقيقة-الآن. keyset يحتاج مفتاح فرز ثابتاً وفريداً ومُفهرَساً؛ وهو محرج لترتيبات فرز اعتباطية. حين يكون الجدول هائلاً وتملك طبقة التخزين، أداة أصلية (`pg_dump`، تصدير لقطة إلى S3، `COPY`) غالباً تتفوّق على الترقيم اليدوي.

خطّ أنابيب التصدير

لماذا كل جزء

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

أسئلة ذات صلة