TL ؛ DR: قبل أربع سنوات ، تركت Google مع فكرة عن أداة جديدة لمراقبة الخوادم. كانت الفكرة هي الجمع بين الوظائف المعزولة عادةً وهي جمع السجلات وتحليلها وجمع المقاييس والتنبيهات ولوحة القيادة في خدمة واحدة. أحد المبادئ - يجب أن تكون الخدمة سريعة حقًا ، مما يوفر للتطبيقات وظيفة سهلة وتفاعلية وممتعة. يتطلب ذلك معالجة مجموعات البيانات من عدة غيغا بايت في الثانية تقسيم ، دون تجاوز الميزانية. غالبًا ما تكون الأدوات الحالية للعمل مع السجلات بطيئة وغير متقنة ، لذا واجهنا مهمة جيدة: تطوير أداة بشكل صحيح لمنح المستخدمين أحاسيس جديدة من العمل.

توضح هذه المقالة كيف قمنا في Scalyr بحل هذه المشكلة من خلال تطبيق أساليب المدرسة القديمة والقوة الغاشمة والقضاء على الطبقات الزائدة وتجنب هياكل البيانات المعقدة. يمكنك تطبيق هذه الدروس على المهام الهندسية الخاصة بك.

قوة المدرسة القديمة

يبدأ تحليل السجل عادة بالبحث: ابحث عن كل الرسائل المطابقة لقالب معين. في Scalyr ، هذه هي عشرات أو مئات غيغا بايت من سجلات من العديد من الخوادم. تتضمن الأساليب الحديثة ، كقاعدة عامة ، بناء بعض بنية البيانات المعقدة المحسنة للبحث. بالطبع ، رأيت هذا على Google ، حيث يجيدون مثل هذه الأشياء. لكننا استقرنا على نهج أكثر صرامة: المسح الخطي للسجلات. وقد نجحت - نحن نقدم واجهة مع البحث بترتيب من حجم أسرع من المنافسين (انظر الرسوم المتحركة في النهاية).

الفكرة الأساسية هي أن المعالجات الحديثة سريعة للغاية في عمليات بسيطة ومباشرة. يتم تجاهل هذا بسهولة في الأنظمة المعقدة متعددة الطبقات التي تعتمد على سرعة الإدخال / الإخراج وعمليات الشبكة ، وهذه الأنظمة شائعة جدًا اليوم. وبالتالي ، قمنا بتطوير تصميم يقلل من عدد الطبقات والقمامة الزائدة. مع وجود عدة معالجات وخوادم بالتوازي ، تصل سرعة البحث إلى 1 تيرابايت في الثانية.

النتائج الرئيسية لهذا المقال:

• البحث الخام هو نهج قابل للتطبيق لحل المشاكل الحقيقية على نطاق واسع.
  
• القوة الغاشمة هي تقنية التصميم ، وليس التحرر من العمل. مثل أي تقنية ، فهي مناسبة لبعض المشاكل أكثر من غيرها ، ويمكن تنفيذها بشكل سيء أو جيد.
  
• القوة الغاشمة جيدة بشكل خاص للأداء المستقر .
  
• الاستخدام الفعال للقوة الغاشمة يتطلب تحسين الكود واستخدام الموارد الكافية في الوقت المناسب. إنه مناسب إذا كانت الخوادم الخاصة بك تحت أعباء عمل ثقيلة من غير المستخدمين وتبقى عمليات المستخدم أولوية.
  
• يعتمد الأداء على تصميم النظام بالكامل ، وليس فقط على خوارزمية الحلقة الداخلية.

(توضح هذه المقالة كيفية البحث عن البيانات في الذاكرة. في معظم الحالات ، عندما يبحث المستخدم عن سجلات ، قامت خوادم Scalyr بتخزينها مؤقتًا بالفعل. في المقالة التالية ، نناقش البحث عن طريق سجلات غير مخزنة مؤقتًا. نفس المبادئ تنطبق: رمز فعال ، طريقة القوة الغاشمة مع حساب كبير الموارد).

طريقة القوة الغاشمة

تقليديًا ، يتم البحث في مجموعة بيانات كبيرة باستخدام فهرس الكلمات الأساسية. كما هو مطبق على سجلات الخادم ، فهذا يعني البحث عن كل كلمة فريدة في السجل. لكل كلمة ، تحتاج إلى تقديم قائمة بجميع الادراج. هذا يجعل من السهل العثور على جميع الرسائل باستخدام هذه الكلمة ، على سبيل المثال ، "خطأ" أو "فايرفوكس" أو "معاملة_16851951" - انظر فقط في الفهرس.

لقد استخدمت هذا النهج على جوجل وأنها عملت بشكل جيد. لكن في Scalyr ، ننظر في سجلات البايتة بايت.

لماذا؟ من وجهة نظر الخوارزمية المجردة ، تعتبر فهارس الكلمات الرئيسية أكثر فاعلية من البحث الخام. ومع ذلك ، نحن لا نبيع الخوارزميات ؛ نبيع الأداء. والأداء ليس فقط الخوارزميات ، ولكن أيضا هندسة النظم. يجب مراعاة كل شيء: كمية البيانات ، ونوع البحث ، والأجهزة المتاحة وسياق البرنامج. قررنا أنه بالنسبة لمشكلتنا الخاصة ، فإن خيارًا مثل "grep" أفضل من الفهرس.

فهارس كبيرة ، ولكن لديهم قيود. كلمة واحدة من السهل العثور عليها. لكن العثور على رسائل بكلمات قليلة ، مثل "googlebot" و "404" ، هو بالفعل أكثر تعقيدًا. يتطلب البحث عن عبارات مثل "استثناء غير معلوم" فهرسًا أكثر تعقيدًا لا يسجل فقط جميع الرسائل بهذه الكلمة ، ولكن أيضًا الموقع المحدد للكلمة.

الصعوبة الحقيقية تأتي عندما لا تبحث عن كلمات. افترض أنك تريد معرفة مقدار حركة المرور التي تأتي من برامج الروبوت. الفكر الأول هو البحث في سجلات كلمة "بوت". لذلك ستجد بعض برامج التتبع: Googlebot و Bingbot والعديد غيرها. لكن هنا كلمة "بوت" ليست كلمة ، ولكنها جزء منها. إذا بحثنا عن "bot" في الفهرس ، فلن نعثر على رسائل بكلمة "Googlebot". إذا قمت بفحص كل كلمة في الفهرس ثم قمت بفحص الفهرس بحثًا عن الكلمات الأساسية الموجودة ، فسيتباطأ البحث إلى حد كبير. نتيجة لذلك ، لا تسمح بعض برامج العمل باستخدام السجلات بالبحث في أجزاء من كلمة أو (في أحسن الأحوال) تسمح باستخدام بناء جملة خاص مع أداء أقل. نريد تجنب هذا.

مشكلة أخرى هي علامات الترقيم. تريد أن تجد جميع الطلبات من 50.168.29.7 ؟ ماذا عن تصحيح الأخطاء التي تحتوي على [error] ؟ الفهارس عادةً تخطي علامات الترقيم.

أخيرًا ، يحب المهندسون أدوات قوية ، وأحيانًا لا يمكن حل المشكلة إلا بتعبير منتظم. فهرس الكلمات الرئيسية ليس مناسبًا جدًا لهذا الغرض.

بالإضافة إلى ذلك ، فهارس معقدة . يجب إضافة كل رسالة إلى عدة قوائم كلمات رئيسية. يجب دائمًا الاحتفاظ بهذه القوائم بتنسيق سهل البحث. يجب ترجمة الاستعلامات التي تحتوي على عبارات أو أجزاء الكلمات أو التعبيرات العادية إلى عمليات مع قوائم متعددة ، والنتائج الممسوحة ضوئيًا ودمجها للحصول على مجموعة نتائج. في سياق خدمة متعددة المستخدمين على نطاق واسع ، يخلق هذا التعقيد مشاكل في الأداء غير مرئية عند تحليل الخوارزميات.

تشغل فهارس الكلمات الرئيسية أيضًا مساحة كبيرة ، والتخزين عنصر التكلفة الرئيسي في نظام إدارة السجل.

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

القوة الغاشمة تعمل إذا كان لديك مشكلة القوة الغاشمة (والكثير من القوة)

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

في البداية ، كان لرمز البحث حلقة داخلية كبيرة إلى حد ما. نقوم بتخزين الرسائل على صفحات 4K. تحتوي كل صفحة على بعض الرسائل (في UTF-8) وبيانات التعريف لكل رسالة. البيانات الأولية هي بنية يتم فيها ترميز طول القيمة ومعرف الرسالة الداخلية والحقول الأخرى. تبدو حلقة البحث كما يلي:



هذا خيار مبسط مقارنة بالرمز الفعلي. ولكن حتى هنا يمكنك رؤية العديد من مواضع الكائنات ونسخ البيانات والمكالمات الوظيفية. يعمل JVM على تحسين استدعاءات الوظائف وتخصيص كائنات سريعة الزوال ، لذلك كان هذا الرمز أفضل مما كنا نستحقه. أثناء الاختبار ، استخدمه العملاء بنجاح كبير. لكن في النهاية انتقلنا إلى مستوى جديد.

(قد تسأل عن سبب تخزين الرسائل في هذا التنسيق مع 4K صفحات ، نصوص وبيانات تعريف ، بدلاً من العمل مباشرة مع السجلات. هناك العديد من الأسباب التي تجعل محرك Scalyr الداخلي يشبه قاعدة بيانات موزعة أكثر من غالبًا ما يتم الجمع بين البحث عن الملفات النصية وعوامل تصفية أنماط DBMS في الحقول بعد تحليل السجل. يمكننا البحث في العديد من الآلاف من السجلات في نفس الوقت ، كما أن الملفات النصية البسيطة ليست مناسبة لعنصر تحكمنا في المعاملات وتكرارها وتوزيعها annymi).

في البداية ، بدا أن هذا الرمز لم يكن مناسبًا جدًا للتحسين وفقًا لطريقة القوة الغاشمة. "الوظيفة الحقيقية" في String.indexOf() لم تهيمن حتى على ملف تعريف وحدة المعالجة المركزية. وهذا يعني أن تحسين هذه الطريقة فقط لن يحقق تأثيرًا كبيرًا.

حدث أن قمنا بتخزين البيانات الوصفية في بداية كل صفحة ، معبأة نص كل الرسائل في UTF-8 في الطرف الآخر. الاستفادة من هذا ، نحن إعادة كتابة حلقة البحث في جميع أنحاء الصفحة في وقت واحد:



يعمل هذا الإصدار مباشرة على طريقة عرض raw byte[] ويبحث عن كل الرسائل مرة واحدة على صفحة 4K بأكملها.

هذا هو أسهل بكثير لتحقيق القوة الغاشمة. يتم استدعاء دورة البحث الداخلية في وقت واحد لكامل صفحة 4K ، وليس بشكل منفصل لكل رسالة. لا يوجد نسخ البيانات ، لا اختيار الكائنات. يتم استدعاء العمليات الأكثر تعقيدًا مع البيانات الوصفية فقط بنتيجة إيجابية ، وليس لكل رسالة. وبالتالي ، تخلصنا من الكثير من الأطنان ، ويتركز باقي التحميل في دورة بحث داخلية صغيرة ، وهي مناسبة تمامًا لمزيد من التحسين.

تعتمد خوارزمية البحث الفعلية الخاصة بنا على فكرة رائعة ليونيد Volnitsky . إنه مشابه لخوارزمية Boyer-Moore مع تخطي طول سلسلة البحث في كل خطوة. الفرق الرئيسي هو أنه يتحقق من وحدتي بايت في كل مرة لتقليل التطابقات الخاطئة.

يتطلب تطبيقنا إنشاء جدول بحث 64 كيلو بايت لكل عملية بحث ، ولكن هذا هراء مقارنةً بجيجابايت من البيانات التي نبحث عنها. الحلقة الداخلية يعالج عدة غيغابايت في الثانية على لب واحد. في الممارسة العملية ، يبلغ الأداء المستقر حوالي 1.25 غيغابايت في الثانية على كل جوهر ، وهناك إمكانية للتحسين. يمكنك التخلص من بعض الحملات الخارجية خارج الحلقة الداخلية ، ونخطط لتجربة الحلقة الداخلية في C بدلاً من Java.

تطبيق القوة

ناقشنا أن عمليات البحث عن السجلات يمكن تنفيذها "تقريبًا" ، ولكن ما مقدار "القوة" التي لدينا؟ كثير

1 الأساسية : عند استخدامها بشكل صحيح ، واحدة أساسية للمعالج الحديث قوية جدا في حد ذاته.

8 مراكز: نحن نعمل حاليًا على خوادم SSD من Amazon hi1.4xlarge و i2.4xlarge ، ولكل منها 8 مراكز (16 سلسلة). كما ذكر أعلاه ، عادة ما تكون هذه الألبومات مشغولة بعمليات الخلفية. عندما يقوم المستخدم بإجراء عملية بحث ، يتم إيقاف عمليات الخلفية مؤقتًا ، مما يؤدي إلى تحرير جميع المراكز الثمانية للبحث. عادةً ما يكتمل البحث في جزء من الثانية ، وبعد ذلك يستأنف العمل في الخلفية (يضمن برنامج التحكم أن مجموعة كبيرة من طلبات البحث لن تتداخل مع أعمال الخلفية المهمة).

16 مركزًا : من أجل الموثوقية ، نقوم بتنظيم الخوادم في مجموعات رئيسية / تابعة. كل سيد لديه خادم SSD واحد ومرؤوس EBS واحد. إذا تعطل الخادم الرئيسي ، فإن الخادم الموجود على SSD سيحل محله على الفور. في كل الأوقات تقريبًا ، تعمل ميزة الاستعصاء والرقيق على ما يرام ، لذلك يمكن البحث في كل كتلة بيانات على خادمين مختلفين (يحتوي خادم EBS التابع للرقيق على معالج ضعيف ، لذلك لا نعتبره). نقسم المهمة بينهما ، بحيث يكون لدينا ما مجموعه 16 النوى المتاحة.

العديد من النوى : في المستقبل القريب ، سنقوم بتوزيع البيانات بين الخوادم بحيث يشاركون جميعًا في معالجة كل طلب غير تافه. كل نواة ستعمل. [ملاحظة: نفذنا الخطة وزدنا سرعة البحث إلى 1 تيرابايت / ثانية ، انظر الملاحظة في نهاية المقال ].

البساطة توفر الموثوقية

ميزة أخرى للقوة الغاشمة هي أدائها المستقر نسبيا. كقاعدة عامة ، لا يكون البحث حساسًا للغاية لتفاصيل المهمة ومجموعة البيانات (أعتقد أن هذا هو السبب في أنه يطلق عليه "غير مهذب").

أحيانًا ما ينتج عن فهرس الكلمات الرئيسية نتائج سريعة بشكل لا يصدق ، لكن في حالات أخرى لا ينتج عنه. افترض أن لديك 50 غيغابايت من السجلات التي يحدث فيها المصطلح "customer_5987235982" ثلاث مرات بالضبط. البحث في هذا المصطلح يحسب ثلاثة مواقع مباشرة من الفهرس وينتهي على الفور. ولكن يمكن إجراء بحث معقد أحرف البدل مسح الآلاف من الكلمات الأساسية ويستغرق الكثير من الوقت.

من ناحية أخرى ، يتم إجراء عمليات البحث عن القوة الغاشمة لأي استعلام بنفس السرعة أو أقل. البحث عن الكلمات الطويلة أفضل ، ولكن حتى البحث عن شخصية واحدة يكون سريعًا بدرجة كافية.

إن بساطة طريقة القوة الغاشمة تعني أن إنتاجيتها قريبة من الحد الأقصى النظري. هناك خيارات أقل للحمل الزائد غير المتوقع للقرص ، وصراع القفل ، ومطاردات المؤشر ، وآلاف الأسباب الأخرى للفشل. لقد نظرت للتو إلى الطلبات التي قدمها مستخدمو Scalyr في الأسبوع الماضي على خادمنا المزدحم. كان هناك 14000 طلب. بالضبط ثمانية منهم استغرق أكثر من ثانية واحدة ؛ تم تنفيذ 99٪ خلال 111 مللي ثانية (إذا لم تستخدم أدوات تحليل السجل ، صدقوني: هذا سريع ).

أداء مستقر وموثوق به مهم لراحة استخدام الخدمة. إذا تباطأ بشكل دوري ، فسيرى المستخدمون أنه غير موثوق به ويحجمون عن استخدامه.

سجل البحث في العمل

وإليك بعض الرسوم المتحركة التي تظهر Scalyr يبحث في العمل. لدينا حساب تجريبي حيث نستورد كل حدث في كل مستودع جيثب العام. في هذا العرض التوضيحي ، أدرس بيانات الأسبوع: حوالي 600 ميغابايت من السجلات الأولية.

تم تسجيل الفيديو مباشرة ، دون إعداد خاص ، على سطح المكتب (حوالي 5000 كيلومتر من الخادم). يرجع الأداء الذي ستراه إلى حد كبير إلى تحسين عميل الويب ، فضلاً عن الواجهة الخلفية السريعة والموثوقة. كلما توقفت مؤقتًا بدون مؤشر "التحميل" ، أوقفه مؤقتًا حتى تتمكن من قراءة ما سأقوم بالنقر فوقه.

في الختام

عند معالجة كميات كبيرة من البيانات ، من المهم اختيار خوارزمية جيدة ، ولكن كلمة "جيدة" لا تعني "الهوى". فكر في الطريقة التي ستعمل بها الشفرة في الممارسة العملية. بعض العوامل التي يمكن أن تكون ذات أهمية كبيرة في العالم الحقيقي تخرج عن التحليل النظري للخوارزميات. تعد الخوارزميات الأكثر بساطة أسهل وأكثر استقرارًا في المواقف الحدودية.

فكر أيضًا في السياق الذي سيتم فيه تنفيذ التعليمات البرمجية. في حالتنا ، نحتاج إلى خوادم قوية بما يكفي لإدارة مهام الخلفية. نادرًا ما يبدأ المستخدمون عملية بحث ، لذلك يمكننا استعارة مجموعة كاملة من الخوادم لفترة قصيرة ضرورية لإكمال كل بحث.

باستخدام القوة الغاشمة ، قمنا بتنفيذ بحث سريع وموثوق ومرن على مجموعة من السجلات. نأمل أن تكون هذه الأفكار مفيدة لمشاريعك.

تحرير: تم تغيير العنوان والنص من "البحث بسرعة 20 جيجابايت في الثانية" إلى "البحث بمعدل 1 تيرابايت في الثانية" ليعكس الزيادة في الأداء خلال السنوات القليلة الماضية. ترجع هذه الزيادة في السرعة في المقام الأول إلى التغير في نوع وعدد خوادم EC2 التي نرفعها اليوم لخدمة قاعدة العملاء المتزايدة. في المستقبل القريب ، من المتوقع أن توفر التغييرات زيادة حادة أخرى في كفاءة العمل ، ونحن نتطلع إلى فرصة للتحدث عنها.