Aria هو إطار المراسلة الداخلي للشركة ونظامها المستضاف، ويعالج عدة تيرابايتات من البيانات يوميًا. يشترك العملاء في Aria لتلقي تدفق حي من الرسائل. ومع النمو السريع للاستخدام، اضطر فريق Aria إلى إعادة هيكلة النظام لمواكبة تزايد حجم البيانات والإنتاجية. في هذا الصيف، ركّز المتدرب Theodor Totev على حالة استخدام محددة: جعل قراءة مجموعة فرعية فقط من الرسائل أقل تكلفة للعملاء. وقد أدى عمله باستخدام الفهرسة وتقسيم الأشجار إلى انخفاض بنسبة 30% في استهلاك المعالج على أحمال الإنتاج، مع الحفاظ على المستوى العالي من الدقة الذي يتطلبه نظام بهذه الأهمية.
عندما يسلّم Aria الرسائل عبر TCP، فإنه يحتفظ بالرسائل الحديثة، والمعروفة باسم طرف التدفق، في مخزن حلقي داخل الذاكرة. ويمكن للعملاء المتأخرين طلب الرسائل الحديثة من هذا المخزن للّحاق بالتدفق، وتُسمى هذه العملية استعادة الطرف. التحدي هو أن Aria يخزّن تدفق الرسائل بالكامل، بينما لا يحتاج العملاء غالبًا إلا إلى جزء صغير منه. يقوم Aria بتصفية التدفق حسب الموضوع، ويمكن للعملاء الاشتراك في موضوعات فردية أو في أشجار موضوعات كاملة. كان النهج الأصلي مرورًا خطيًا بسيطًا على التدفق، وهو غير فعّال خوارزميًا لكنه سريع بفضل ملاءمته لذاكرة التخزين المؤقت للمعالج. ومع تزايد عدد العملاء الذين يستعيدون الطرف، بلغت بعض الخوادم 100% من استخدام المعالج، مما أدى إلى خروج العملاء من الطرف وعجزهم عن اللحاق.
تم استبعاد إنشاء فهرس لكل موضوع، إذ قد تحتوي مثيلات Aria على ما يقارب مليون موضوع. وبدلاً من ذلك، أنشأ Theodor فهرسًا لكل قسم موضوعات، وهو مجموعة تضم جميع الموضوعات التي تشترك في البادئة نفسها المكونة من مقطعين. يسجّل فهرس كل قسم مواقع رسائله في التدفق. وعندما يطلب عميل رسائل، ينفّذ Aria دمجًا متعدد الاتجاهات للفهارس ذات الصلة باستخدام كومة دنيا، فيعيد بناء التدفق المرتب للأقسام المطلوبة فقط.
كان القياس المرجعي محوريًا في هذا العمل. فقد بنى Theodor أداة تحليل أداء لاختبار متغيرات مثل عدد أقسام الموضوعات ودرجة التداخل وعدد القرّاء. وكشف تحليل الأداء للتطبيق الأولي أن الكومة الدنيا كانت أكبر عنق زجاجة.
المصدر: Hacker News · لخّصه HeadlinesBriefing