HighLoad++ موسكو 2018، قاعة المؤتمرات. 9 نوفمبر، الساعة 15:00
الملخصات والعرض:
يوري ناسرتدينوف (فكونتاكتي): سيتحدث التقرير عن تجربة تنفيذ ClickHouse في شركتنا - لماذا نحتاج إليه، وكم البيانات التي نخزنها، وكيف نكتبها، وما إلى ذلك.
مواد إضافية:
يوري نصردينوف: - أهلاً بكم! اسمي يوري ناسرتدينوف، كما تم تقديمي بالفعل. أنا أعمل في فكونتاكتي. سأتحدث عن كيفية إدراج البيانات في ClickHouse من أسطول خوادمنا (عشرات الآلاف).
ما هي السجلات ولماذا جمعها؟
ما سنخبرك به: ما فعلناه، ولماذا احتجنا إلى "ClickHouse"، على التوالي، ولماذا اخترناه، ونوع الأداء الذي يمكنك الحصول عليه تقريبًا دون تكوين أي شيء خصيصًا. سأخبركم المزيد عن الجداول العازلة، وعن المشاكل التي واجهناها معهم وعن حلولنا التي طورناها من المصادر المفتوحة - KittenHouse وLighthouse.
لماذا نحتاج إلى القيام بأي شيء على الإطلاق (كل شيء على ما يرام دائمًا في فكونتاكتي، أليس كذلك؟). أردنا جمع سجلات تصحيح الأخطاء (وكان هناك مئات التيرابايت من البيانات)، وربما يكون حساب الإحصائيات أكثر ملاءمة بطريقة أو بأخرى؛ ولدينا أسطول مكون من عشرات الآلاف من الخوادم التي يجب تنفيذ كل هذا منها.
لماذا قررنا؟ ربما كانت لدينا حلول لتخزين السجلات. هنا – يوجد مثل هذا "Backend VK" العام. أوصي بشدة بالاشتراك فيه.
ما هي السجلات؟ هذا محرك يقوم بإرجاع صفائف فارغة. المحركات في VK هي ما يسميه الآخرون الخدمات الصغيرة. وهنا ملصق مبتسم (الكثير من الإعجابات). كيف ذلك؟ حسنًا، استمع أكثر!
ما الذي يمكن استخدامه لتخزين السجلات؟ ومن المستحيل عدم ذكر هادوب. ثم، على سبيل المثال، Rsyslog (تخزين هذه السجلات في الملفات). عقار إل إس دي. من يعرف ما هو LSD؟ لا، ليس هذا LSD. تخزين الملفات، على التوالي، أيضا. حسنًا، يعد ClickHouse خيارًا غريبًا.
Clickhouse والمنافسون: المتطلبات والفرص
ماذا نريد؟ نريد التأكد من أنه لا داعي للقلق كثيرًا بشأن العملية، بحيث تعمل خارج الصندوق، ويفضل أن يكون ذلك مع الحد الأدنى من التكوين. نريد أن نكتب كثيرًا، ونكتب بسرعة. ونحن نريد الاحتفاظ بها لجميع أنواع الأشهر والسنوات، أي لفترة طويلة. قد نرغب في فهم بعض المشاكل التي جاؤوا بها إلينا وقالوا: "هناك شيء لا يعمل هنا،" وكان ذلك قبل 3 أشهر)، ونريد أن نكون قادرين على رؤية ما حدث قبل 3 أشهر " ضغط البيانات – من الواضح لماذا يعتبر ميزة إضافية – لأنه يقلل من مقدار المساحة التي تشغلها.
ولدينا مثل هذا المطلب المثير للاهتمام: نكتب أحيانًا مخرجات بعض الأوامر (على سبيل المثال، السجلات)، ويمكن أن يكون حجمها أكثر من 4 كيلو بايت بسهولة تامة. وإذا كان هذا الشيء يعمل عبر UDP، فلن يحتاج إلى إنفاقه... لن يكون هناك أي "نفقات عامة" للاتصال، وسيكون ذلك بمثابة ميزة إضافية لعدد كبير من الخوادم.
دعونا نرى ما يقدمه لنا المصدر المفتوح. أولاً، لدينا محرك السجلات - وهذا هو محركنا؛ من حيث المبدأ، يمكنه فعل كل شيء، حتى أنه يمكنه كتابة سطور طويلة. حسنًا، إنها لا تضغط البيانات بشفافية - يمكننا ضغط الأعمدة الكبيرة بأنفسنا إذا أردنا... نحن، بالطبع، لا نريد ذلك (إن أمكن). المشكلة الوحيدة هي أنه لا يستطيع أن يتخلى إلا عما يناسب ذاكرته؛ لقراءة الباقي، تحتاج إلى الحصول على binlog الخاص بهذا المحرك، وبالتالي، يستغرق الأمر وقتًا طويلاً.
ما هي الخيارات الأخرى هناك؟ على سبيل المثال، "هادوب". سهولة التشغيل... من يعتقد أن Hadup سهل الإعداد؟ وبطبيعة الحال، لا توجد مشاكل مع التسجيل. عند القراءة، هناك أسئلة في بعض الأحيان. من حيث المبدأ، أود أن أقول ربما لا، وخاصة بالنسبة للسجلات. التخزين طويل المدى - بالطبع، نعم، ضغط البيانات - نعم، سلاسل طويلة - من الواضح أنه يمكنك التسجيل. لكن التسجيل من عدد كبير من الخوادم... لا يزال يتعين عليك القيام بشيء بنفسك!
سجل النظام. في الواقع، استخدمناه كخيار احتياطي حتى نتمكن من قراءته دون تفريغ السجل، لكنه لا يستطيع كتابة أسطر طويلة؛ من حيث المبدأ، لا يمكنه كتابة أكثر من 4 كيلو بايت. عليك أن تقوم بضغط البيانات بنفس الطريقة بنفسك. القراءة سوف تأتي من الملفات.
ثم هناك تطور "بادوشكا" لعقار إل إس دي. بشكل أساسي هو نفس "Rsyslog": فهو يدعم سلاسل طويلة، لكنه لا يمكنه العمل عبر UDP، وفي الواقع، لهذا السبب، لسوء الحظ، هناك حاجة إلى إعادة كتابة الكثير من الأشياء هناك. يحتاج LSD إلى إعادة تصميمه ليتمكن من التسجيل من عشرات الآلاف من الخوادم.
و هنا! الخيار المضحك هو ElasticSearch. كيف اقول؟ إنه جيد في القراءة، أي أنه يقرأ بسرعة، ولكن ليس جيدًا في الكتابة. أولاً، إذا قام بضغط البيانات، فهو ضعيف جداً. على الأرجح، يتطلب البحث الكامل هياكل بيانات أكبر من الحجم الأصلي. من الصعب تشغيلها وغالباً ما تنشأ مشاكل معها. ومرة أخرى، التسجيل بالمرونة - علينا أن نفعل كل شيء بأنفسنا.
يعد ClickHouse هنا خيارًا مثاليًا بالطبع. الشيء الوحيد هو أن التسجيل من عشرات الآلاف من الخوادم يمثل مشكلة. ولكن على الأقل هناك مشكلة واحدة، يمكننا أن نحاول حلها بطريقة أو بأخرى. وبقية التقرير يدور حول هذه المشكلة. ما نوع الأداء الذي يمكن أن تتوقعه من ClickHouse؟
كيف سنقوم بإدخاله؟ MergeTree
من منكم لم يسمع أو يعرف عن "ClickHouse"؟ أريد أن أخبرك، أليس كذلك؟ سريع جدا. الإدراج هناك - 1-2 جيجابت في الثانية، رشقات نارية تصل إلى 10 جيجابت في الثانية يمكنها بالفعل تحمل هذا التكوين - هناك اثنان من Xeons 6 النواة (أي ليس حتى الأقوى)، 256 جيجا بايت من ذاكرة الوصول العشوائي، 20 تيرابايت في RAID (لم يتم تكوين أحد، الإعدادات الافتراضية). ربما كان Alexey Milovidov، مطور ClickHouse، جالسًا هناك يبكي لأننا لم نقم بتكوين أي شيء (كل شيء سار على هذا النحو بالنسبة لنا). وبناء على ذلك، يمكن الحصول على سرعة مسح تبلغ، على سبيل المثال، حوالي 6 مليارات سطر في الثانية إذا تم ضغط البيانات بشكل جيد. إذا كنت تحب % على سلسلة نصية - 100 مليون سطر في الثانية، فهذا يبدو سريعًا جدًا.
كيف سنقوم بإدخاله؟ حسنًا، أنت تعلم أن VK يستخدم لغة PHP. سوف نقوم بإدراج كل عامل PHP عبر HTTP في "ClickHouse"، في جدول MergeTree لكل سجل. من يرى مشكلة في هذا المخطط؟ لسبب ما، لم يرفع الجميع أيديهم. دعني أخبرك.
أولا، هناك الكثير من الخوادم - وبالتالي، سيكون هناك الكثير من الاتصالات (سيئة). ومن الأفضل بعد ذلك إدراج البيانات في MergeTree بمعدل لا يزيد عن مرة واحدة في الثانية. ومن يعرف لماذا؟ حسنا حسنا. سأخبرك المزيد عن هذا. سؤال آخر مثير للاهتمام هو أننا لا نقوم بالتحليلات، ولا نحتاج إلى إثراء البيانات، ولا نحتاج إلى خوادم وسيطة، ونريد إدراجها مباشرة في "ClickHouse" (ويفضل - كلما كان ذلك أفضل، كلما كان ذلك أفضل).
وبناء على ذلك، كيف يتم الإدراج في MergeTree؟ لماذا من الأفضل إدخاله مرة واحدة في الثانية أو أقل في كثير من الأحيان؟ الحقيقة هي أن "ClickHouse" هي قاعدة بيانات عمودية وتقوم بفرز البيانات بترتيب تصاعدي للمفتاح الأساسي، وعندما تقوم بعملية إدراج، يتم إنشاء عدد من الملفات يساوي على الأقل عدد الأعمدة التي يتم فرز البيانات فيها بترتيب تصاعدي للمفتاح الأساسي (يتم إنشاء دليل منفصل، مجموعة من الملفات الموجودة على القرص لكل إدراج). ثم يأتي الإدراج التالي، وفي الخلفية يتم دمجها في "أقسام" أكبر. نظرًا لأنه تم فرز البيانات، فمن الممكن "دمج" ملفين مفروزين دون استهلاك الكثير من الذاكرة.
ولكن، كما قد تتخيل، إذا كتبت 10 ملفات لكل إدراج، فسوف ينتهي ClickHouse (أو الخادم الخاص بك) بسرعة، لذلك يوصى بالإدراج على دفعات كبيرة. وبناءً على ذلك، لم نطلق المخطط الأول في الإنتاج مطلقًا. أطلقنا واحدًا على الفور، والذي يحتوي هنا رقم 2 على:
تخيل هنا أن هناك حوالي ألف خادم أطلقنا عليه، هناك PHP فقط. وعلى كل خادم يوجد وكيلنا المحلي، والذي أطلقنا عليه اسم "Kittenhouse"، والذي يحتفظ باتصال واحد مع "ClickHouse" ويقوم بإدخال البيانات كل بضع ثوانٍ. يقوم بإدراج البيانات ليس في MergeTree، ولكن في جدول مخزن مؤقت، والذي يعمل على وجه التحديد على تجنب الإدراج مباشرة في MergeTree على الفور.
العمل مع الجداول العازلة
ما هو؟ الجداول المؤقتة هي جزء من الذاكرة مقسمة (أي يمكن إدراجها فيها بشكل متكرر). وهي تتكون من عدة قطع، وكل قطعة تعمل كمخزن مؤقت مستقل، ويتم مسحها بشكل مستقل (إذا كان لديك العديد من القطع في المخزن المؤقت، فسيكون هناك العديد من الإدخالات في الثانية). من الممكن القراءة من هذه الجداول - ثم تقرأ اتحاد محتويات المخزن المؤقت والجدول الأصلي، ولكن في هذه اللحظة يتم حظر الكتابة، لذا من الأفضل عدم القراءة من هناك. وتظهر الجداول العازلة QPS جيدة جدًا، أي ما يصل إلى 3 آلاف QPS لن تواجه أي مشاكل على الإطلاق عند الإدراج. من الواضح أنه إذا فقد الخادم الطاقة، فمن الممكن أن يتم فقدان البيانات، لأنه تم تخزينها في الذاكرة فقط.
في الوقت نفسه، فإن المخطط مع المخزن المؤقت يعقد ALTER، لأنك تحتاج أولا إلى إسقاط جدول المخزن المؤقت القديم مع المخطط القديم (لن تختفي البيانات في أي مكان، لأنه سيتم مسحها قبل حذف الجدول). ثم تقوم "بتعديل" الجدول الذي تحتاجه وإنشاء الجدول المؤقت مرة أخرى. وفقًا لذلك، على الرغم من عدم وجود جدول عازل، فإن بياناتك لن تتدفق إلى أي مكان، ولكن يمكنك الاحتفاظ بها على القرص محليًا على الأقل.
ما هو كيتنهاوس وكيف يعمل؟
ما هو كيتن هاوس؟ هذا وكيل. تخمين ما اللغة؟ لقد جمعت المواضيع الأكثر إثارة للاهتمام في تقريري - "Clickhouse"، اذهب، ربما سأتذكر شيئًا آخر. نعم، هذا مكتوب بلغة Go، لأنني لا أعرف حقًا كيفية الكتابة بلغة C، ولا أريد ذلك.
وبناءً على ذلك، فإنه يحافظ على الاتصال بكل خادم ويمكنه الكتابة إلى الذاكرة. على سبيل المثال، إذا كتبنا سجلات الأخطاء إلى Clickhouse، إذا لم يكن لدى Clickhouse الوقت لإدراج البيانات (بعد كل شيء، إذا تمت كتابة الكثير)، فإننا لا نضخم الذاكرة - فنحن ببساطة نتخلص من الباقي. لأنه إذا كتبنا عدة جيجابت في الثانية من الأخطاء، فمن المحتمل أن نتمكن من التخلص من بعضها. كيتنهاوس يمكنها أن تفعل هذا. بالإضافة إلى ذلك، يمكنه إجراء تسليم موثوق، أي الكتابة إلى القرص على الجهاز المحلي ومرة واحدة في كل مرة (هناك، مرة كل ثانيتين) يحاول تسليم البيانات من هذا الملف. وفي البداية استخدمنا تنسيق القيم العادي - وليس بعض التنسيق الثنائي، وهو تنسيق نص (كما هو الحال في SQL العادي).
ولكن بعد ذلك حدث هذا. استخدمنا تسليمًا موثوقًا، وكتبنا السجلات، ثم قررنا (كانت مجموعة اختبار مشروطة)... تم طرحها لعدة ساعات وإعادتها مرة أخرى، وبدأ الإدراج من ألف خادم - اتضح أن Clickhouse لا يزال لديه "مؤشر الترابط عند الاتصال" - وفقًا لذلك، في ألف اتصال، يؤدي الإدراج النشط إلى متوسط تحميل على الخادم يبلغ حوالي ألف ونصف. والمثير للدهشة أن الخادم قبل الطلبات، ولكن تم إدراج البيانات بعد مرور بعض الوقت؛ ولكن كان من الصعب جدًا على الخادم أن يخدمها.
أضف نجينكس
مثل هذا الحل لنموذج الخيط لكل اتصال هو nginx. لقد قمنا بتثبيت nginx أمام Clickhouse، وفي نفس الوقت قمنا بإعداد موازنة لنسختين متماثلتين (زادت سرعة الإدراج لدينا بمقدار 2 مرات، على الرغم من أنه ليس حقيقة أن هذا هو الحال) وقمنا بتحديد عدد الاتصالات بـ Clickhouse، إلى المنبع، وبالتالي أكثر من 50 اتصالاً، يبدو أنه لا فائدة من الإدراج.
ثم أدركنا أن هذا المخطط له عيوب بشكل عام، لأن لدينا nginx واحد فقط هنا. وفقا لذلك، إذا تعطل هذا Nginx، على الرغم من وجود النسخ المتماثلة، فإننا نفقد البيانات أو، على الأقل، لا نكتب في أي مكان. لهذا السبب قمنا بعمل موازنة التحميل الخاصة بنا. لقد أدركنا أيضًا أن "Clickhouse" لا يزال مناسبًا للسجلات، وبدأ "الشيطان" أيضًا في كتابة سجلاته في "Clickhouse" - وهو أمر مريح جدًا بصراحة. ما زلنا نستخدمها لـ "شياطين" أخرى.
ثم اكتشفنا هذه المشكلة المثيرة للاهتمام: إذا كنت تستخدم طريقة غير قياسية للإدراج في وضع SQL، فإنها تفرض محلل SQL كاملًا يستند إلى AST، وهو بطيء جدًا. وبناءً على ذلك، أضفنا الإعدادات لضمان عدم حدوث ذلك أبدًا. لقد قمنا بموازنة التحميل، والفحوصات الصحية، بحيث إذا مات أحد الأشخاص، فإننا نترك البيانات. لدينا الآن عدد كبير جدًا من الجداول التي نحتاجها للحصول على مجموعات Clickhouse مختلفة. وبدأنا أيضًا بالتفكير في استخدامات أخرى - على سبيل المثال، أردنا كتابة سجلات من وحدات nginx، لكنهم لا يعرفون كيفية التواصل باستخدام RPC الخاص بنا. حسنًا، أود أن أعلمهم كيفية الإرسال بطريقة أو بأخرى على الأقل - على سبيل المثال، استقبال الأحداث على المضيف المحلي عبر UDP ثم إعادة توجيهها إلى Clickhouse.
على بعد خطوة من الحل
بدأ المخطط النهائي يبدو هكذا (الإصدار الرابع من هذا المخطط): يوجد nginx على كل خادم أمام Clickhouse (على نفس الخادم) ويقوم ببساطة بطلبات الوكلاء إلى المضيف المحلي مع حد لعدد الاتصالات قدره 50 قِطَع. وكان هذا المخطط ناجحًا بالفعل، وكان كل شيء جيدًا معه.
لقد عشنا هكذا لمدة شهر تقريبًا. كان الجميع سعداء، وأضافوا الجداول، وأضافوا، وأضافوا... بشكل عام، اتضح أن الطريقة التي أضفنا بها الجداول المؤقتة لم تكن مثالية للغاية (دعنا نضع الأمر على هذا النحو). لقد قمنا بعمل 16 قطعة في كل طاولة وفاصل زمني للوميض لبضع ثوان؛ كان لدينا 20 جدولًا وكان كل جدول يتلقى 8 إدراجات في الثانية - وعند هذه النقطة بدأت "Clickhouse"... بدأت السجلات في التباطؤ. لم يقتصر الأمر على عدم المرور فحسب... افتراضيًا، كان لدى nginx شيء مثير للاهتمام، وهو أنه إذا انتهت الاتصالات عند المنبع، فإنه ببساطة يعيد "502" إلى جميع الطلبات الجديدة.
وهنا لدينا (لقد ألقيت نظرة على السجلات الموجودة في Clickhouse نفسها) فشل حوالي نصف بالمائة من الطلبات. وفقا لذلك، كان استخدام القرص مرتفعا، وكان هناك الكثير من عمليات الدمج. حسنا، ماذا فعلت؟ وبطبيعة الحال، لم أزعج نفسي بمعرفة سبب انتهاء الاتصال والمنبع بالضبط.
استبدال nginx بالوكيل العكسي
قررت أننا بحاجة إلى إدارة هذا الأمر بأنفسنا، ولسنا بحاجة إلى ترك الأمر لـ nginx - nginx لا يعرف الجداول الموجودة في Clickhouse، واستبدلت nginx بالوكيل العكسي، والذي كتبته بنفسي أيضًا.
ماذا يفعل؟ إنه يعمل بناءً على مكتبة fasthttp "goshnoy"، أي بسرعة تقارب سرعة nginx. عذرًا، إيجور، إذا كنت حاضرًا هنا (ملاحظة: إيجور سيسويف هو مبرمج روسي قام بإنشاء خادم الويب nginx). يمكنه فهم نوع الاستعلامات - INSERT أو SELECT - وفقًا لذلك، فإنه يحتفظ بمجموعات اتصال مختلفة لأنواع مختلفة من الاستعلامات.
وبناء على ذلك، حتى لو لم يكن لدينا الوقت لإكمال طلبات الإدراج، فإن "الاختيارات" ستمر، والعكس صحيح. ويقوم بتجميع البيانات في جداول عازلة - مع مخزن مؤقت صغير: إذا كانت هناك أية أخطاء، وأخطاء في بناء الجملة، وما إلى ذلك - بحيث لا تؤثر بشكل كبير على بقية البيانات، لأنه عندما نقوم ببساطة بإدراجها في الجداول المخزنة، فإننا كانت تحتوي على "bachi" صغيرة، وكل الأخطاء النحوية أثرت فقط على هذه القطعة الصغيرة؛ وهنا سوف تؤثر بالفعل على مخزن مؤقت كبير. الحجم الصغير هو 1 ميغا بايت، أي أنه ليس صغيرًا جدًا.
يؤدي إدخال المزامنة واستبدال nginx بشكل أساسي إلى نفس الشيء الذي فعله nginx من قبل - لا تحتاج إلى تغيير "Kittenhouse" المحلي لهذا الغرض. وبما أنه يستخدم fasthttp، فهو سريع جدًا - يمكنك تقديم أكثر من 100 ألف طلب في الثانية لإدخالات فردية من خلال وكيل عكسي. من الناحية النظرية، يمكنك إدراج سطر واحد في كل مرة في الوكيل العكسي لـ kittenhouse، لكننا لا نفعل ذلك بالطبع.
بدأ المخطط يبدو كما يلي: "Kittenhouse"، يقوم الوكيل العكسي بتجميع العديد من الطلبات في الجداول، وفي المقابل، تقوم الجداول المؤقتة بإدراجها في الجداول الرئيسية.
القاتل هو حل مؤقت، والهريرة هي حل دائم
هذه مشكلة مثيرة للاهتمام... هل استخدم أحدكم fasthttp؟ من استخدم fasthttp مع طلبات POST؟ ربما لم يكن من المفترض فعل ذلك، لأنه يقوم بتخزين نص الطلب بشكل افتراضي، وتم ضبط حجم المخزن المؤقت لدينا على 16 ميغابايت. توقف الإدراج في مرحلة ما، وبدأت أجزاء بحجم 16 ميجا بايت في الوصول من عشرات الآلاف من الخوادم، وتم تخزينها جميعًا مؤقتًا في الذاكرة قبل إرسالها إلى Clickhouse. وفقًا لذلك، نفدت الذاكرة، وجاء قاتل نفاد الذاكرة وقتل الوكيل العكسي (أو "Clickhouse"، الذي يمكنه نظريًا "أكل" أكثر من الوكيل العكسي). وتكررت الدورة نفسها. ليست مشكلة ممتعة للغاية. على الرغم من أننا عثرنا على هذا فقط بعد عدة أشهر من العملية.
ما الذي فعلته؟ مرة أخرى، لا أحب حقًا أن أفهم ما حدث بالضبط. أعتقد أنه من الواضح جدًا أنه لا يجب تخزينها مؤقتًا في الذاكرة. لم أتمكن من تصحيح fasthttp، على الرغم من أنني حاولت. لكنني وجدت طريقة للقيام بذلك بحيث لا تكون هناك حاجة لتصحيح أي شيء، وتوصلت إلى طريقتي الخاصة في HTTP - أسميتها KITTEN. حسنًا، هذا منطقي - "VK"، "Kitten"... ماذا أيضًا؟..
إذا وصل طلب إلى الخادم باستخدام طريقة Kitten، فيجب أن يستجيب الخادم بـ "meow" - بشكل منطقي. إذا استجاب لذلك، فهو يعتبر أنه يفهم هذا البروتوكول، ثم أعترض الاتصال (Fasthttp لديه مثل هذه الطريقة)، وينتقل الاتصال إلى الوضع "الخام". لماذا أحتاجه؟ أريد التحكم في كيفية حدوث القراءة من اتصالات TCP. يحتوي TCP على خاصية رائعة: إذا لم يقرأ أحد من الجانب الآخر، فستبدأ الكتابة في الانتظار، ولا يتم إنفاق الذاكرة بشكل خاص على هذا.
وهكذا أقرأ من حوالي 50 عميلاً في المرة الواحدة (من خمسين لأن الخمسين يجب أن تكون كافية بالتأكيد، حتى لو كان المعدل يأتي من DC آخر)... انخفض الاستهلاك مع هذا النهج 20 مرة على الأقل، لكنني بصراحة ، لم أتمكن من قياس الوقت بالضبط، لأنه لا معنى له بالفعل (لقد وصل بالفعل إلى مستوى الخطأ). البروتوكول ثنائي، أي أنه يحتوي على اسم الجدول وبياناته؛ لا توجد رؤوس http، لذلك لم أستخدم مقبس الويب (لست بحاجة إلى التواصل مع المتصفحات - لقد قمت بإنشاء بروتوكول يناسب احتياجاتنا). وأصبح كل شيء على ما يرام معه.
الجدول العازل حزين
لقد صادفنا مؤخرًا ميزة أخرى مثيرة للاهتمام وهي الجداول المؤقتة. وهذه المشكلة بالفعل أكثر إيلاما من غيرها. لنتخيل هذا الموقف: أنت تستخدم Clickhouse بنشاط بالفعل، ولديك العشرات من خوادم Clickhouse، ولديك بعض الطلبات التي تستغرق وقتًا طويلاً جدًا لقراءتها (على سبيل المثال، أكثر من 60 ثانية)؛ وتأتي وتفعل Alter في هذه اللحظة... في هذه الأثناء، لن يتم تضمين "التحديدات" التي بدأت قبل "Alter" في هذا الجدول، ولن يبدأ "Alter" - ربما بعض ميزات كيفية عمل "Clickhouse" في هذا المكان. ربما هذا يمكن أن تكون ثابتة؟ أم أنه مستحيل؟
بشكل عام، من الواضح أن هذه ليست مشكلة كبيرة في الواقع، ولكن مع الجداول العازلة تصبح أكثر إيلاما. لأنه، على سبيل المثال، إذا انتهت مهلة "Alter" الخاصة بك (وقد تنتهي مهلة "Alter" على مضيف آخر - ليس على مضيفك، ولكن على نسخة متماثلة، على سبيل المثال)، إذن... لقد قمت بحذف الجدول المؤقت، "Alter" الخاص بك ( أو مضيف آخر) انتهت المهلة. ثم حدث خطأ "التغيير") - لا تزال بحاجة إلى التأكد من استمرار كتابة البيانات: تقوم بإنشاء الجداول المؤقتة مرة أخرى (وفقًا لنفس مخطط الجدول الأصلي)، ثم يمر "التغيير" وينتهي بعد كل شيء، ويبدأ المخزن المؤقت للجدول في الاختلاف في المخطط عن الأصل. اعتمادًا على ما كان عليه "التغيير"، قد لا ينتقل الإدخال بعد الآن إلى هذا الجدول المؤقت - وهذا أمر محزن للغاية.
توجد أيضًا مثل هذه العلامة (ربما لاحظها شخص ما) - تسمى query_thread_log في الإصدارات الجديدة من Clickhouse. بشكل افتراضي، في بعض الإصدارات كان هناك واحد. هنا قمنا بتجميع 840 مليون سجل في شهرين (100 جيجابايت). ويرجع ذلك إلى حقيقة أن هناك "إدراجات" مكتوبة (ربما الآن، بالمناسبة، لم تتم كتابتها). كما أخبرتك، "إدراجاتنا" صغيرة - كان لدينا الكثير من "الإدراجات" في الجداول المؤقتة. من الواضح أن هذا معطل - أنا فقط أخبرك بما رأيته على خادمنا. لماذا؟ هذه حجة أخرى ضد استخدام الجداول العازلة! سبوتي حزين جدا.
من كان يعلم أن اسم هذا الرجل كان سبوتي؟ رفع موظفو VK أيديهم. نعم.
حول خطط "KitttenHouse"
عادة لا تتم مشاركة الخطط، أليس كذلك؟ وفجأة لن تتمكن من الوفاء بها ولن تبدو جيدًا في عيون الآخرين. لكنني سأتحمل المخاطرة! نريد أن نفعل ما يلي: يبدو لي أن الجداول العازلة لا تزال عكازًا ونحتاج إلى تخزين الإدخال بأنفسنا. لكننا ما زلنا لا نريد تخزينه مؤقتًا على القرص، لذلك سنقوم بتخزين الإدخال مؤقتًا في الذاكرة.
وفقًا لذلك، عند إجراء "إدراج"، لن يكون متزامنًا بعد الآن - سيعمل بالفعل كجدول مؤقت، وسيتم إدراجه في الجدول الأصلي (حسنًا، في وقت لاحق) والإبلاغ عبر قناة منفصلة عن الإدخالات التي مرت وأيها ليس لديه.
لماذا لا يمكنني ترك الإدراج المتزامن؟ إنه أكثر ملاءمة. الحقيقة هي أنه إذا قمت بإدراج 10 آلاف مضيف، فكل شيء على ما يرام - سوف تحصل على القليل من كل مضيف، تقوم بإدخاله هناك مرة واحدة في الثانية، كل شيء على ما يرام. لكنني أرغب في أن يعمل هذا المخطط، على سبيل المثال، من جهازين، بحيث يمكنك التنزيل بسرعة عالية - ربما لا تحصل على الحد الأقصى من Clickhouse، ولكن تكتب ما لا يقل عن 100 ميغابايت في الثانية من جهاز واحد عبر وكيل عكسي - هذا المخطط يجب أن يتوسع إلى كميات كبيرة وصغيرة، لذلك لا يمكننا الانتظار ثانية لكل إدخال، لذلك يجب أن يكون غير متزامن. وبنفس الطريقة، يجب أن تأتي التأكيدات غير المتزامنة بعد اكتمال عملية الإدراج. وسوف نعرف ما إذا كان قد مرت أم لا.
الشيء الأكثر أهمية هو أننا في هذا المخطط نعرف على وجه اليقين ما إذا كان الإدراج قد حدث أم لا. تخيل هذا الموقف: لديك جدول مخزن مؤقت، وكتبت شيئًا فيه، وبعد ذلك، على سبيل المثال، انتقل الجدول إلى وضع القراءة فقط وحاولت مسح المخزن المؤقت. أين ستذهب البيانات؟ سيبقون في المنطقة العازلة. لكن لا يمكننا التأكد من ذلك - ماذا لو كان هناك خطأ آخر، بسبب عدم بقاء البيانات في المخزن المؤقت... (عناوين Alexey Milovidov، Yandex، ClickHouse Developer) أم أنها ستبقى؟ دائماً؟ يقنعنا أليكسي أن كل شيء سيكون على ما يرام. ليس لدينا أي سبب لعدم تصديقه. ولكن لا يزال: إذا لم نستخدم الجداول العازلة، فلن تكون هناك أي مشاكل معهم. يعد إنشاء جداول مضاعفة أمرًا غير مريح أيضًا، على الرغم من عدم وجود مشكلات كبيرة من حيث المبدأ. هذه هي الخطة.
دعونا نتحدث عن القراءة
الآن دعونا نتحدث عن القراءة. لقد كتبنا أيضًا أداتنا الخاصة هنا. يبدو، حسنًا، لماذا تكتب آلتك الخاصة هنا؟.. ومن استخدم Tabix؟ بطريقة ما، قليل من الناس رفعوا أيديهم... ومن هو الراضي عن أداء تابيكس؟ حسنًا، نحن لسنا سعداء به، وهو ليس مناسبًا جدًا لعرض البيانات. إنه أمر جيد بالنسبة للتحليلات، ولكن من الواضح أنه لم يتم تحسينه فقط للعرض. لذلك كتبت واجهتي الخاصة.
إنه بسيط جدًا - يمكنه قراءة البيانات فقط. إنه لا يعرف كيفية عرض الرسومات، ولا يعرف كيفية القيام بأي شيء. ولكنها يمكن أن تظهر ما نحتاج إليه: على سبيل المثال، عدد الصفوف الموجودة في الجدول، وكم المساحة التي تشغلها (دون تقسيمها إلى أعمدة)، أي أن الواجهة الأساسية للغاية هي ما نحتاج إليه.
وهو يبدو مشابهًا جدًا لـ Sequel Pro، ولكنه مصنوع فقط على Twitter’s Bootstrap، والإصدار الثاني. تسأل: "يوري، لماذا في الإصدار الثاني؟" ما العام؟ 2018؟ بشكل عام، لقد قمت بذلك منذ وقت طويل لـ "Muscle" (MySQL) وقمت للتو بتغيير سطرين في الاستعلامات هناك، وبدأ العمل لـ "Clickhouse"، والذي أشكره بشكل خاص! لأن المحلل اللغوي يشبه إلى حد كبير المحلل "العضلي"، والاستعلامات متشابهة جدًا - مريحة للغاية، خاصة في البداية.
حسنًا، يمكنه تصفية الجداول، ويمكنه إظهار بنية الجدول ومحتوياته، ويسمح لك بالفرز والتصفية حسب الأعمدة، وإظهار الاستعلام الذي أدى إلى النتيجة، والصفوف المتأثرة (كم عددها نتيجة لذلك)، أي الأشياء الأساسية لعرض البيانات. سريع جدًا.
هناك أيضا محرر. لقد حاولت بصراحة سرقة المحرر بأكمله من Tabix، لكنني لم أستطع. ولكن بطريقة ما يعمل. من حيث المبدأ، هذا كل شيء.
"Clickhouse" مناسب للأوكار
أريد أن أخبرك أن Clickhouse، على الرغم من كل المشاكل الموضحة، مناسب جدًا للسجلات. والأهم من ذلك أنه يحل مشكلتنا - فهو سريع جدًا ويسمح لك بتصفية السجلات حسب الأعمدة. من حيث المبدأ، لم يكن أداء الجداول العازلة جيدًا، ولكن عادةً لا أحد يعرف السبب... ربما الآن تعرف بشكل أفضل أين ستواجه المشاكل.
برنامج التعاون الفني؟ بشكل عام، في VK، من المعتاد استخدام UDP. وعندما استخدمت TCP... بالطبع، لم يخبرني أحد: "يوري، ما الذي تتحدث عنه! " لا يمكنك ذلك، فأنت بحاجة إلى UDP." اتضح أن TCP ليس مخيفًا جدًا. الشيء الوحيد هو أنه إذا كان لديك عشرات الآلاف من المركبات النشطة التي تكتبها، فأنت بحاجة إلى تحضيرها بعناية أكبر؛ ولكن من الممكن، وسهل جدا.
لقد وعدت بنشر "Kittenhouse" و"Lighthouse" على HighLoad Siberia إذا اشترك الجميع في "VK backend" العامة لدينا... وكما تعلم، لم يشترك الجميع... بالطبع، لن أطلب منك الاشتراك في قناتنا عام. لا يزال هناك الكثير منكم، وقد يتعرض شخص ما للإهانة، ولكن مع ذلك، يرجى الاشتراك (وهنا لا بد لي من جعل عيون مثل عيون القطة). هذا . شكراً جزيلاً! جيثب هو لنا . مع Clickhouse شعرك سوف يكون ناعم وحريري.
مشرف: - الأصدقاء، الآن للأسئلة. مباشرة بعد أن نقدم لك شهادة التقدير وتقريرك عن نظام VHS.
يوري نصردينوف (المشار إليه فيما يلي بـ YN): – كيف تمكنت من تسجيل تقريري على VHS إذا كان قد انتهى للتو؟
مشرف: – أنت أيضًا لا تستطيع أن تحدد بشكل كامل كيفية عمل “Clickhouse” أم لا! أيها الأصدقاء، 5 دقائق للأسئلة!
الأسئلة
سؤال من الجمهور (يشار إليه فيما يلي بـ س): - مساء الخير. شكرا جزيلا على التقرير. لدي سؤالان. سأبدأ بشيء تافه: هل يؤثر عدد حروف t في اسم "Kittenhouse" في المخططات (3، 4، 7...) على رضا القطط؟
YN: - كمية ماذا؟
З: - حرف ر. هناك ثلاث ر، في مكان ما حوالي ثلاث ر.
YN: - لم أصلحه؟ حسنا، بالطبع يفعل! هذه منتجات مختلفة - لقد كنت أخدعك طوال هذا الوقت. حسنًا، أنا أمزح - لا يهم. اه، هنا! لا، هو نفس الشيء، لقد ارتكبت خطأ مطبعي.
З: - شكرًا لك. السؤال الثاني خطير. بقدر ما أفهم، في Clickhouse، تعيش الجداول العازلة حصريا في الذاكرة، ولا يتم تخزينها مؤقتا على القرص، وبالتالي، ليست ثابتة.
YN: - نعم.
З: - وفي الوقت نفسه، يقوم عميلك بالتخزين المؤقت على القرص، مما يعني ضمنًا بعض الضمان لتسليم هذه السجلات نفسها. ولكن هذا ليس مضمونًا بأي حال من الأحوال في Clickhouse. اشرح كيف يتم الضمان، بسبب ماذا؟.. وإليكم هذه الآلية بمزيد من التفصيل
YN: – نعم، من الناحية النظرية لا توجد تناقضات هنا، لأنه عندما يسقط Clickhouse، يمكنك في الواقع اكتشافه بمليون طريقة مختلفة. إذا تعطل Clickhouse (إذا انتهى بشكل غير صحيح)، فيمكنك، بشكل عام، إرجاع القليل من السجل الخاص بك الذي قمت بتدوينه والبدء من اللحظة التي كان فيها كل شيء على ما يرام تمامًا. لنفترض أنك قمت بالترجيع لمدة دقيقة، أي أنه من المفترض أنك قمت بمسح كل شيء في دقيقة واحدة.
З: – أي أن “كيتنهاوس” يحافظ على النافذة لفترة أطول، وفي حالة السقوط يستطيع التعرف عليها وإرجاعها؟
YN: - ولكن هذا من الناحية النظرية. من الناحية العملية، نحن لا نفعل ذلك، والتسليم الموثوق به يكون من صفر إلى ما لا نهاية. ولكن في المتوسط واحد. نحن مقتنعون بأنه إذا تعطل Clickhouse لسبب ما أو "تم إعادة تشغيل" الخوادم، فسنخسر قليلاً. وفي جميع الحالات الأخرى، لن يحدث شيء.
З: - مرحبًا. منذ البداية بدا لي أنك ستستخدم بالفعل UDP منذ بداية التقرير. لديك http، كل ذلك... ومعظم المشاكل التي وصفتها، كما أفهمها، كان سببها هذا الحل بالذات...
YN: – ماذا نستخدم TCP؟
З: - في الأساس نعم.
YN: - لا.
З: - لقد واجهت مشكلات مع fasthttp، كما واجهت مشاكل مع الاتصال. إذا كنت قد استخدمت UDP للتو، فستوفر على نفسك بعض الوقت. حسنًا، قد تكون هناك مشكلات في الرسائل الطويلة أو أي شيء آخر...
YN: - بماذا؟
З: - مع الرسائل الطويلة، لأنها قد لا تتناسب مع MTU، شيء آخر... حسنًا، قد تكون هناك مشاكل خاصة بهم. السؤال هو: لماذا لا UDP؟
YN: - أعتقد أن المؤلفين الذين طوروا TCP/IP هم أكثر ذكاءً مني ويعرفون أفضل مني كيفية إجراء تسلسل للحزم (بحيث يتم إرسالها)، وفي الوقت نفسه ضبط نافذة الإرسال، وعدم التحميل الزائد على الشبكة، وإبداء الرأي حول ما لا تتم قراءته، ولا يتم الاعتماد على الجانب الآخر... كل هذه المشكلات، في رأيي، ستكون موجودة في UDP، فقط سأضطر إلى كتابة تعليمات برمجية أكثر مما كتبت بالفعل من أجل تنفيذ نفس الشيء بنفسي وعلى الأرجح سيئة. أنا لا أحب الكتابة بلغة C، ناهيك عن ذلك...
З: - مريحة فقط! تم الإرسال بشكل جيد ولا تنتظر أي شيء - فهو غير متزامن تمامًا. جاء إشعار بأن كل شيء على ما يرام - وهذا يعني أنه وصل؛ إذا لم يأتي فهذا يعني أنه سيء.
YN: – أحتاج إلى كليهما – أحتاج إلى أن أكون قادرًا على الإرسال مع ضمان التسليم وبدون ضمان التسليم. هذان سيناريوهان مختلفان. أحتاج إلى عدم فقدان بعض السجلات أو عدم فقدانها في حدود المعقول.
З: – لن أضيع الوقت. هذا يحتاج إلى مناقشة أكثر. شكرًا لك.
مشرف: - من لديه أسئلة - يديه إلى السماء!
З: - مرحبا، أنا ساشا. في مكان ما في منتصف التقرير، ظهر شعور بأنه بالإضافة إلى TCP، من الممكن استخدام الحل الجاهز - نوع من كافكا.
YN: - حسنًا... أخبرتك أنني لا أريد استخدام خوادم وسيطة، لأنه... في كافكا، اتضح أن لدينا عشرة آلاف مضيف؛ في الواقع، لدينا المزيد - عشرات الآلاف من المضيفين. قد يكون من المؤلم أيضًا التعامل مع كافكا دون أي وكلاء. بالإضافة إلى ذلك، والأهم من ذلك، أنه لا يزال يوفر "زمن الوصول"، فهو يوفر مضيفين إضافيين تحتاج إلى الحصول عليهما. لكنني لا أريد الحصول عليهم - أريد...
З: "لكن في النهاية اتضح الأمر بهذه الطريقة على أي حال."
YN: – لا، لا يوجد مضيفين! كل هذا يعمل على مضيفي Clickhouse.
З: - حسنًا، و"كيتنهاوس"، وهو العكس - أين يعيش؟
YN: - على مضيف Clickhouse، لا يكتب أي شيء على القرص.
З: - لنفترض.
مشرف: - هل أنت راض؟ هل يمكننا أن نعطيك راتبا؟
З: - نعم يمكنك ذلك. في الواقع، هناك الكثير من العكازات للحصول على نفس الشيء، والآن - الإجابة السابقة حول موضوع TCP تتعارض، في رأيي، هذا الوضع. يبدو الأمر وكأن كل شيء كان من الممكن القيام به على ركبتي في وقت أقل بكثير.
YN: - وأيضًا لماذا لم أرغب في استخدام كافكا، لأنه كان هناك الكثير من الشكاوى في دردشة Clickhouse Telegram، على سبيل المثال، فقدان الرسائل من كافكا. ليس من كافكا نفسه، ولكن من تكامل كافكا وكليكهاوس؛ أو أن شيئًا ما لم يتصل هناك. بشكل تقريبي، سيكون من الضروري كتابة عميل لكافكا بعد ذلك. لا أعتقد أنه يمكن أن يكون هناك حل أبسط أو أكثر موثوقية.
З: - أخبرني، لماذا لم تجرب أي طوابير أو أي حافلة مشتركة؟ بما أنك تقول أنه مع عدم التزامن يمكنك إرسال السجلات نفسها من خلال قائمة الانتظار وتلقي الاستجابة بشكل غير متزامن من خلال قائمة الانتظار؟
YN: – يرجى اقتراح ما هي قوائم الانتظار التي يمكن استخدامها؟
З: – أي، حتى من دون ضمان أنها في النظام. نوع من Redis، RMQ ...
YN: – لدي شعور بأن Redis على الأرجح لن يكون قادرًا على سحب مثل هذا الحجم من الإدراج حتى على مضيف واحد (بمعنى العديد من الخوادم) الذي يسحب Clickhouse. لا يمكنني دعم هذا بأي دليل (لم أقم بقياسه)، ولكن يبدو لي أن Redis ليس الحل الأفضل هنا. من حيث المبدأ، يمكن اعتبار هذا النظام بمثابة قائمة انتظار رسائل مرتجلة، ولكنه مصمم فقط لـ "Clickhouse"
مشرف: - يوري، شكرا جزيلا لك. أقترح إنهاء الأسئلة والأجوبة هنا وأقول لمن طرح السؤال سنعطي الكتاب له.
YN: - أود أن أعطي كتابًا لأول شخص يطرح سؤالاً.
مشرف: - رائع! عظيم! خلاب! شكرًا جزيلاً!
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com