يعني إيه Data-Intensive؟
معظم الأبلكيشنز النهارده مش مشكلتها إن الـ CPU مش ملحق. المشكلة في الداتا نفسها: حجمها، تعقيدها، وسرعة تغيّرها. ده اللي بنسميه data-intensive.
والأبلكيشن العادي بيتبني من طوب بتتكرر:
الكتاب بيركز على ٣ هموم: Reliability يشتغل صح رغم الأعطال، Scalability يستحمل الحمل لما يزيد، Maintainability الناس تقدر تشتغل عليه بسهولة.
الاعتمادية: Fault مش Failure
السيستم يفضل شغال صح حتى لما الحاجات تبوظ. يعمل اللي المستخدم متوقعه، يستحمل غلطاته، وأداؤه مقبول.
جزء واحد خرج عن المواصفات: هارد مات، سيرفر وقع. الهدف إنك تبني سيستم fault-tolerant: مش هتمنع الأعطال، بس تمنعها تتحول لانهيار.
السيستم كله بطّل يقدّم الخدمة للمستخدم. ده اللي المستخدم بيحس بيه.
| النوع | شكله | بنتعامل معاه إزاي |
|---|---|---|
| Hardware | هاردات بتموت، رام، كهربا. عشوائي ومش مرتبط ببعض | Redundancy: RAID، باور مزدوج. وفي الكلاود السوفتوير يستحمل إن ماكينة تختفي |
| Software | باج واحد يوقع كل السيرفرات مرة واحدة، أو process ياكل الرام، أو cascading failure | افترض الأسوأ، اعزل الـ processes، خلّي العملية تقع وتقوم، وراقب الـ invariants |
| Human | أخطاء الـ configuration من أكبر أسباب الأعطال | APIs تصعّب الغلط، sandbox، تيست، rollback سريع، ونشر تدريجي |
فيه شركات بتعطّل حاجات عمدًا عشان تتأكد إن الحماية شغالة، زي Chaos Monkey.
القابلية للتوسع
“السيستم ده scalable” جملة فاضية. السؤال الصح: لو الحمل زاد بالطريقة الفلانية، إيه خياراتنا؟
أولًا وصف الحمل (load parameters): requests في الثانية، نسبة القراءة للكتابة، عدد الأونلاين، cache hit rate. أحيانًا المتوسط هو المهم، وأحيانًا الحالات المتطرفة.
ثانيًا وصف الأداء. الخدمات الأونلاين يهمها الـ response time. الـ batch يهمه الـ throughput.
الـ response time هو اللي العميل شايفه (خدمة + شبكة + طوابير). الـ latency هو الوقت اللي الريكوست قاعد مستني فيه يتخدم. والـ response time مش رقم واحد، ده توزيع، وفيه outliers بسبب GC أو باكت ضاع.
ماكينة أقوى. بسيط، بس غالي ومحدود.
ماكينات صغيرة كتير، shared-nothing. أرخص، بس بيدخل تعقيد الأنظمة الموزعة.
الـ stateless services سهل تتوزع. الداتابيز stateful توزيعها صعب، فلفترة طويلة النصيحة كانت: سيبها على ماكينة واحدة لحد ما تتزنق. ومفيش magic scaling sauce: ١٠٠ ألف ريكوست كل واحد ١KB سيستم غير ٣ ريكوستات في الدقيقة كل واحد ٢GB، حتى لو الـ throughput متقارب.
سهولة الصيانة
أغلب تكلفة السوفتوير في صيانته مش في كتابته.
| المبدأ | يعني إيه | عمليًا |
|---|---|---|
| Operability | فريق التشغيل يشغّله بسهولة | مونيتورينج، أوتوميشن، سلوك متوقع |
| Simplicity | مهندس جديد يفهم السيستم | شيل الـ accidental complexity. أقوى سلاح abstraction كويس |
| Evolvability | سهل يتغير لما المتطلبات تتغير | refactor على مستوى الـ data systems كلها |