أسس التوسّع
حسابات على ظرف الورقة
سؤال «هل تتحمل قاعدة بيانات واحدة هذا الحمل؟» ليس إحساساً — إنه حساب. بخمسة أرقام محفوظة ووصفة واحدة، تستطيع الإجابة عنه على منديل ورقي في دقيقتين.
معظم المهندسين يخمنون. يطالبون بعنقود من الخوادم لأن الحمل «يبدو كبيراً»، أو يذعرون من زيارات يستطيع لابتوب واحد خدمتها. التقدير يستبدل الإحساس برقم — والرقم يمكن التحقق منه.
- قوى الاثنين للبيانات: KB ≈ ألف بايت، MB ≈ مليون، GB ≈ مليار، TB ≈ تريليون. هذا التقريب كافٍ لأي نقاش تصميم.
- حدس زمن الاستجابة: القراءة من الذاكرة أسرع بنحو 100× من القراءة من SSD، وSSD أسرع بنحو 100× من رحلة شبكة ذهاباً وإياباً عبر البلاد. فكّر بمراتب القِوى، لا بالأرقام الدقيقة.
- اليوم الواحد = 86,400 ثانية ≈ 100,000 ثانية. هذا التقريب لأعلى يجعل كل عملية قسمة في هذا الدرس تافهة السهولة.
- الوصول إلى الـCPU cache: ~1 ns. هذه وحدتك — كل ما عدها يُقاس بالنسبة إليها.
- القراءة من RAM: ~100 ns — أبطأ بنحو 100× من الـcache. ومع ذلك تبقى شبه مجانية مقارنة بأي شيء تحتها.
- قراءة عشوائية من SSD: ~100 µs — أبطأ بنحو 1,000× من RAM. لهذا إصابة الـcache والاستعلام من قاعدة البيانات ليسا الشيء نفسه.
- البحث (seek) على قرص ميكانيكي: ~1 ms — أبطأ بنحو 10× من SSD. الـI/O العشوائي على HDD هو الفخ؛ أما التسلسلي فلا بأس به.
- رحلة ذهاب وإياب داخل مركز بيانات واحد: ~0.5 ms. رخيصة بما يكفي للتخاطب — لكن ليس آلاف المرات في الطلب الواحد.
- رحلة ذهاب وإياب عبر القارات: ~150 ms — نحو 300× قفزة داخل المركز نفسه. هذه فيزياء لا هندسة؛ لا يختصرها إلا CDN.
- متوسط QPS = عدد المستخدمين النشطين يومياً × عدد العمليات لكل مستخدم ÷ 86,400. هذا هو عدد الطلبات في الثانية التي يجب أن يخدمها نظامك في يوم عادي.
- ذروة QPS ≈ ضعف المتوسط. ساعات الغداء والمساء والإطلاقات تكثّف الزيارات — صمّم للذروة، لا للمتوسط.
- التخزين اليومي = عدد عمليات الكتابة × حجم السجل الواحد. اضرب الناتج في عدد أيام الاحتفاظ لتحصل على التخزين الكلي.
لنفترض 10 ملايين مستخدم يومياً، كل منهم يرسل 30 رسالة في اليوم. الرسائل في اليوم = 10M × 30 = 300 مليون. متوسط QPS = 300 مليون ÷ 86,400 ≈ 3,500 رسالة في الثانية؛ والذروة ≈ 7,000. والآن التخزين: 300 مليون رسالة × 50 بايت بيانات وصفية لكل رسالة ≈ 15 GB في اليوم. احتفظ بكل شيء 5 سنوات: 15 GB × 365 × 5 ≈ 27 TB. كل رقم هنا ناتج من ضربة أو قسمة واحدة — لا سحر في الموضوع.
لنفترض 10 ملايين مستخدم يومياً، كل منهم يرفع صورتين في اليوم بحجم ~2 MB للصورة. الرفع في اليوم = 10M × 2 = 20 مليون صورة. التخزين الوارد = 20 مليون × 2 MB = 40 مليون MB ≈ 40 TB بيانات جديدة كل يوم — و40 TB × 365 ≈ 15 PB في السنة، قبل النسخ المكررة. سعة الكتابة = 40 TB ÷ 86,400 ثانية ≈ 460 MB/s، ولنقل ~500 MB/s في المتوسط — ونحو 1 GB/s في الذروة. القراءات نحو 10 أضعاف الكتابات: 10 × 500 MB/s ≈ 5 GB/s تُقدَّم في المتوسط. هنا التخزين هو ما يوجع، لا QPS — وسعة النقل هي ما تدفع فاتورته للسحابة.
لا أحد يريد الرقم الصحيح — الكل يريد أن يراك تستنتج. سواء كانت الإجابة 3,500 أو 5,000 QPS لا يغيّر شيئاً؛ لكن كونها 3,500 أو 350,000 يغيّر التصميم كله. مرتبة القِوى هي المهمة، أما الدقة فلا.
حساب ذهني سريع: مليونا مستخدم يومياً، كل منهم يفتح 10 صفحات — ما متوسط QPS وما الذروة؟ (2M × 10 = 20 مليون طلباً في اليوم؛ 20 مليون ÷ 86,400 ≈ 230 QPS في المتوسط، و≈ 460 في الذروة — خادم متواضع واحد يكفي.)
التقدير وصفة وليس موهبة: المستخدمون × العمليات ÷ الثواني لحساب QPS، والكتابات × الحجم × الأيام لحساب التخزين، والذروة ضعف المتوسط. قرّب بجرأة — أنت تختار معمارية، لا تقدّم إقراراً ضريبياً.
اختر نظاماً واحداً تعمل عليه اليوم. قدّر متوسط QPS وذروته ونمو التخزين الشهري في صفحة واحدة. غالباً ستكتشف أنه أصغر بكثير أو أكبر بكثير مما يفترض الجميع — وكلتا النتيجتين مفيدة.
أسس التوسّع