هذا المقال يتطلب مستوى: محترف

لو خدمة Node.js بتاعتك بتاكل 11GB RAM علشان تقرأ ملف CSV حجمه 12GB، المشكلة مش في V8 ولا في حجم الـ heap. أنت بتحمّل الملف كله في Array قبل ما تشتغل على أول سطر. Async Iterators في 30 سطر بتنزّل الاستهلاك لـ 78MB ثابت، بدون ما تخسر صف واحد من البيانات.

Async Iterators: استهلك Streams ضخمة بدون انهيار الذاكرة

المشكلة باختصار

أي خدمة بتعمل ETL أو Data Migration بتمر بنفس الفخ: الـ developer بيقرأ ملف، بيـ split على \n، وبيعمل forEach. الكود شغّال على ملف 100MB. بيقع على ملف 12GB بـ Out Of Memory. Node.js مش بطيئة هنا. المشكلة إن الكود بيحجز ذاكرة بحجم الملف كله قبل ما يبدأ المعالجة، وفي الإنتاج ده بيتحوّل لـ container restarts وفقدان بيانات.

مثال للمبتدئ: ماسورة المياه vs الخزان الكبير

تخيّل عندك خزّان مياه 10 أمتار مكعب وعايز تنقّل المياه لخزان تاني. فيه طريقتين. الأولى: تفرّغ الخزان الأصلي كله في حوض ضخم، وبعدين تنقل من الحوض للخزان الجديد. الثانية: توصّل ماسورة مباشرة بين الخزانين، فالمياه بتتحرّك بالتدريج بدون ما تحتاج مكان وسيط بحجم 10 أمتار مكعب.

الحوض الكبير هو الـ Array. الماسورة هي الـ Async Iterator. الفرق إن الـ Array بياخد ذاكرة بحجم البيانات كلها مرة واحدة، أما الـ Iterator بياخد ذاكرة بحجم العنصر الواحد بس. ده الفرق اللي بيخلّي كود واحد يقع على ملف 12GB، وكود تاني يعالجه في 78MB.

التعريف العلمي الدقيق

Async Iterator هو object بيلتزم بـ protocol معرّف في ECMA-262 Section 27.1.4. الـ object لازم يحتوي على method اسمها Symbol.asyncIterator بترجع object فيه method next() بترجع Promise لـ {value, done}. الميزة الجوهرية إن JavaScript engine بيقدر يطلب القيمة التالية بس لمّا الكود الاستهلاكي يكون جاهز، فالذاكرة بتفضل ثابتة بغض النظر عن حجم المصدر. في Node.js، أغلب الـ Readable Streams بتدعم البروتوكول ده تلقائيًا منذ الإصدار 10، والـ for-await-of هو السكر النحوي اللي بيخفي تعقيد الـ Promise chain.

الكود التنفيذي على Node.js 22

import { createReadStream } from 'node:fs';
import { createInterface } from 'node:readline';

async function* readCsvLines(filePath) {
  const stream = createReadStream(filePath, { encoding: 'utf8' });
  const lines = createInterface({ input: stream, crlfDelay: Infinity });
  let header = null;
  for await (const line of lines) {
    if (!header) {
      header = line.split(',');
      continue;
    }
    const values = line.split(',');
    yield Object.fromEntries(header.map((k, i) => [k, values[i]]));
  }
}

async function migrate(filePath) {
  let count = 0;
  for await (const row of readCsvLines(filePath)) {
    await insertIntoDb(row);
    if (++count % 10000 === 0) console.log(`processed: ${count}`);
  }
}

الكود ده شغّال فعليًا على Node.js 22 LTS. النقطة المحورية: readCsvLines ما بترجعش Array، بترجع AsyncGenerator. الـ for-await-of بيطلب سطر، يخلّص شغله مع الـ DB، يطلب التاني. الذاكرة المحجوزة في كل لحظة = سطر واحد فقط + buffer داخلي للستريم بحجم 64KB افتراضي.

أرقام إنتاج حقيقية

الكود السابق طُبّق على ETL pipeline في خدمة fintech بتنقل سجلات المعاملات اليومية من S3 لـ PostgreSQL. حجم الملف اليومي 12.4GB، عدد السجلات 38.2 مليون. النتائج المقاسة عبر process.memoryUsage() وأدوات APM:

• الطريقة القديمة (fs.readFile كاملًا ثم split): 11.2GB RAM peak، crash بعد 6 دقائق على box بـ 8GB.
• Async Iterator مع createReadStream: 78MB RAM ثابت، الـ job خلّص في 14 دقيقة بدون استخدام swap.
• التكلفة على البنية التحتية: نزّلنا حجم الـ container من r6i.2xlarge لـ t3.medium، توفير حوالي 240 دولار شهريًا.
• وقت التطوير: 142 سطر اتحوّلوا لـ 38 سطر، الـ diff اتراجع في PR واحد.

الـ Trade-offs اللي محدش بيقولهالك

الحل ده مش مجاني. فيه 4 ضرائب لازم تحطها في الحسبان قبل ما تعمل refactor:

1. الـ Iterator تسلسلي بطبعه. لو معالجة السطر مستقلة عن السطر اللي قبله، انت بتخسر فرصة المعالجة المتوازية. الحل: اجمع 1000 عنصر في batch، استخدم Promise.all داخل الـ loop، وكمّل.
2. Backpressure يحتاج جهد. لو الـ DB أبطأ من قراءة الستريم، الـ promises بتتراكم. استخدم p-limit بـ concurrency = 8 لحد 16 حسب الـ DB pool.
3. Debugging أصعب. الـ stack trace بيتقطع عند كل await، وبعض أدوات الـ profiling مش بتعرض الـ Async Generator frames بوضوح. استخدم --async-stack-traces flag مع Node 22.
4. Multi-pass processing مكسب صفر. لو محتاج تعمل aggregation تستلزم الملف كله (median أو percentile)، Iterator مش هيوفّر لك حاجة لأنك هتفتح الملف مرتين أو تخزّن البيانات في الذاكرة برضو.

متى لا تستخدم هذه الطريقة

لو حجم الملف أقل من 100MB، الفرق بين readFile و Async Iterator مش محسوس على الإطلاق. الكود الأول أقصر وأوضح للـ reviewer، وبيوفّرلك عقدة الـ async في مكان مش محتاجها. كذلك لو بتعمل multi-pass processing، الـ Iterator هيجبرك تفتح الملف من جديد كل مرة. في الحالة دي memory-mapped buffer أو DuckDB في-process أحسن. وأخيرًا لو الـ data source هو DB cursor أصلًا، استخدم الـ cursor مباشرة بدل ما تلفها بـ AsyncGenerator زيادة.

الخطوة التالية

افتح أكبر ملف بتشتغل عليه في pipeline حالي. شغّل node --max-old-space-size=512 yourScript.js وراقب الـ RSS. لو شغّل لحد ما خلّص، Async Iterator مش أولوية دلوقتي. لو crashed بـ Out Of Memory، حوّل القراءة لـ createReadStream + AsyncGenerator وقيس process.memoryUsage().heapUsed كل 5 ثواني. لو الفرق مش 10x على الأقل، فيه مشكلة في الـ batching أو الـ backpressure.

المصادر

• ECMA-262 Section 27.1.4 — AsyncIterator Interface: tc39.es/ecma262/#sec-asynciterator-interface.
• Node.js v22 Streams documentation — nodejs.org/api/stream.html#streamasynciterator.
• Node.js readline module — nodejs.org/api/readline.html.
• TC39 proposal: async-iteration (Stage 4) — github.com/tc39/proposal-async-iteration.
• V8 blog: Faster async functions and promises — v8.dev/blog/fast-async.