HighLoad ++ موسكو 2018 ، قاعة المؤتمرات. 9 نوفمبر ، 15:00
الملخصات والعرض التقديمي:
http://www.highload.ru/moscow/2018/abstracts/4066يوري ناسريتدينوف (فكونتاكتي): سوف يخبرنا التقرير عن تجربة تطبيق ClickHouse في شركتنا - لماذا نحتاج إليها ، وكم نحن نخزن البيانات ، وكيف نكتبها وما إلى ذلك.
موارد إضافية:
استخدام Clickhouse كبديل لـ ELK و Big Query و TimescaleDB يوري Nasretdinov: - مرحباً بالجميع! اسمي يوري Nasretdinov ، لأنها قدمت لي بالفعل. أنا أعمل في فكونتاكتي. سأتحدث عن كيفية إدراج البيانات في "ClickHouse" من أسطولنا من الخوادم (عشرات الآلاف).
ما هي سجلات ولماذا جمعها؟
ما الذي سنتحدث عنه: ماذا فعلنا ، ولماذا احتجنا إلى "ClickHouse" ، على التوالي - لماذا اخترناه ، ونوع الأداء الذي يمكنك الحصول عليه تقريبًا دون تكوين أي شيء على وجه التحديد. سوف أخبركم أكثر عن الجداول العازلة ، وعن المشكلات التي واجهناها ، وعن الحلول التي طورناها من المصادر المفتوحة - KittenHouse و Lighthouse.
لماذا كنا بحاجة إلى القيام بأي شيء على الإطلاق (على فكونتاكتي كل شيء على ما يرام دائما ، أليس كذلك؟). لقد أردنا تجميع سجلات تصحيح الأخطاء (وكان هناك مئات تيرابايت من البيانات هناك) ، وربما ، بطريقة أو بأخرى ، من الملائم قراءة الإحصاءات ؛ ولدينا عشرات الآلاف من الخوادم التي يحتاج كل هذا إلى القيام بها.
لماذا قررنا؟ ربما كان لدينا حلول لتخزين السجلات. هنا - هناك مثل "Backend VK" العام. أنا أوصي الاشتراك في ذلك.
ما هي سجلات؟ هذا هو محرك إرجاع صفيفات فارغة. محركات "VK" هي ما يسميها الآخرون بالخدمات الميكروية. ومثل هذا الملصق يبتسم (الكثير من الإعجابات). كيف ذلك؟ حسنا ، اسمع على
ما يمكن استخدامه لتخزين السجلات بشكل عام؟ من المستحيل أن نذكر خضر. ثم ، على سبيل المثال ، Rsyslog (التخزين في ملفات هذه السجلات). LSD. من يدري ما هو LSD؟ لا ، ليس هذا LSD. يتم تخزين الملفات ، على التوالي ، أيضا. حسنًا ، ClickHouse هو إصدار غريب من نوع ما.
Clickhouse والمنافسين: المتطلبات والفرص
ماذا نريد؟ نريد أننا لم نكن بحاجة إلى أخذ حمام بخار خاص مع العملية ، بحيث يعمل خارج الصندوق بشكل مفضل ، مع الحد الأدنى من الإعداد. نريد أن نكتب الكثير والكتابة بسرعة. ونريد الاحتفاظ بها طوال الأشهر والسنوات ، أي لفترة طويلة. قالوا: "قد نرغب في حل مشكلة ما التي أتوا بها إلينا ،" - لا يعمل شيء من أجلنا هنا ، - كان هذا منذ 3 أشهر) ، ونريد أن نكون قادرين على رؤيته قبل 3 أشهر ". ضغط البيانات - من المفهوم لماذا سيكون زائد - لأنه يتم تقليل مساحة المساحة المشغولة.
ولدينا مثل هذا المطلب المثير للاهتمام: نكتب أحيانًا إخراج بعض الأوامر (على سبيل المثال ، السجلات) ، ويمكن أن يكون أكثر من 4 كيلو بايت بهدوء تام. وإذا كان هذا الشيء يعمل على UDP ، فلن يحتاج إلى إنفاق ... لن يكون له أي "حمل" للاتصال ، وبالنسبة لعدد كبير من الخوادم ، ستكون هذه ميزة إضافية.
دعونا نرى ما يقدمه المصدر المفتوح لنا. أولاً ، لدينا محرك سجلات - هذا هو محركنا ؛ إنه يعرف كل شيء بشكل أساسي ، حتى الخطوط الطويلة يمكنها الكتابة. حسنًا ، لا يتم ضغط البيانات بشفافية - يمكننا ضغط الأعمدة الكبيرة بأنفسنا إذا أردنا ... نحن ، بالطبع ، لا نريد (إن أمكن). المشكلة الوحيدة هي أنه لا يستطيع سوى التخلي عما يوضع في ذاكرته ؛ بقية ، من أجل القراءة ، تحتاج إلى الحصول على binlog لهذا المحرك ، وبالتالي يستغرق الأمر بعض الوقت.
ما هي الخيارات الأخرى؟ على سبيل المثال ، خادوب. سهولة الاستخدام ... من يعتقد أن Hadoup سهل التكوين؟ مع التسجيل ، بالطبع ، لا توجد مشاكل. مع القراءة ، تنشأ أسئلة في بعض الأحيان. من حيث المبدأ ، أود أن أقول أن على الأرجح لا ، وخاصة بالنسبة للسجلات. التخزين طويل الأجل - بالطبع ، نعم ، ضغط البيانات - نعم ، الخطوط الطويلة - من الواضح أنه يمكنك الكتابة. ولكن للتسجيل من عدد كبير من الخوادم ... على أي حال ، يجب أن نفعل شيئًا بأنفسنا!
Rsyslog. في الواقع ، استخدمناها كخلفية احتياطية ، بحيث يكون من الممكن قراءة binlog دون تفريغ ، لكن لا يمكن الكتابة في طوابير طويلة ، من حيث المبدأ ، لا يمكن أن تكتب أكثر من 4 كيلو بايت. يجب أن يتم ضغط البيانات بنفس الطريقة. القراءة سوف تذهب من الملفات.
ثم هناك تطور "سيء" لـ LSD. نفس الشيء هو نفسه "Rsyslog" بشكل أساسي: إنه يدعم الخطوط الطويلة ، لكنه لا يعرف كيفية استخدام UDP ، وفي الواقع ، لهذا ، للأسف ، هناك الكثير من الأشياء لإعادة كتابتها هناك. يجب إعادة إنشاء LSD حتى تتمكن من التسجيل من عشرات الآلاف من الخوادم.
أوه هنا! خيار مضحك هو ElasticSearch. حسنا ، كيف أقول؟ كل شيء على ما يرام مع القراءة ، أي أنه يقرأ بسرعة ، ولكن ليس جيدًا مع الكتابة. أولاً ، إذا كان يضغط البيانات ، فهو ضعيف جدًا. على الأرجح ، يتطلب البحث الكامل إنشاءات بيانات أكثر حجمًا من وحدة التخزين الأصلية. من الصعب استغلالها ، فغالبًا ما تنشأ مشاكل معها. ومرة أخرى ، إدخال في "مرنة" - يجب علينا جميعًا أن نفعل ذلك بأنفسنا.
هنا ClickHouse - الخيار المثالي ، بالطبع. الشيء الوحيد هو أن التسجيل من عشرات الآلاف من الخوادم يمثل مشكلة. لكنها واحدة على الأقل ، يمكننا محاولة حلها بطريقة أو بأخرى. وبقية التقرير حول هذه المشكلة. ما الأداء الكلي من ClickHouse الذي يمكن أن تتوقعه؟
كيف سنضمّن؟ MergeTree
كم منكم لم يسمع عن ClickHouse ، لا أعرف؟ تحتاج أن أقول ، ليس من الضروري؟ سريع جدا يحتوي الملحق على 1-2 غيغا بايت في الثانية ، والرشقات التي تصل إلى 10 غيغا بايت في الثانية يمكن أن تصمد أمام هذا التكوين فعليًا - فهناك زيون ثنائي النواة (أي ، حتى دونهما أقوى) ، و 256 غيغا بايت من ذاكرة الوصول العشوائي ، و 20 تيرابايت لكل RAID (لم يتم تكوين أحد ، الإعدادات الافتراضية). أليكسي ميلوفيدوف ، مطور 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 ، لأنك تحتاج أولاً إلى إسقاط جدول المخزن المؤقت القديم مع المخطط القديم (لن يتم فقد البيانات في نفس الوقت ، لأنه سيتم مسحها قبل حذف الجدول). ثم يمكنك "تغيير" الجدول الذي تحتاجه وإنشاء جدول المخزن المؤقت مرة أخرى. وفقًا لذلك ، على الرغم من عدم وجود جدول مؤقت ، فإن بياناتك لا تتدفق في أي مكان ، ولكن يمكنك حتى على القرص محليًا.
ما هو Kittenhouse وكيف يعمل؟
ما هو KittenHouse؟ هذا وكيل. تخمين ما اللغة؟ لقد جمعت أكثر الموضوعات إثارة في تقريري - هذا هو "Clickhouse" ، اذهب ، ربما أتذكر شيئًا آخر. نعم ، هو مكتوب في Go ، لأنني لا أعرف حقًا كيفية الكتابة باللغة C ، لا أريد ذلك.
وفقا لذلك ، فإنه يحتفظ اتصال مع كل خادم ، يمكن الكتابة إلى الذاكرة. على سبيل المثال ، إذا كتبنا سجلات الأخطاء في "Clickhouse" ، فإذا لم يكن "Clickhouse" لديه الوقت لإدراج البيانات (بعد كل شيء ، إذا كان الكثير منها مكتوبًا) ، فإننا لا نتضخم من الذاكرة - فنحن ببساطة نطرد الباقي. لأنه إذا كتبنا عدة غيغا بايت في الثانية الواحدة من الأخطاء ، فمن المحتمل ، ربما ، يمكننا إلقاء بعضها. Kittenhouse يعرف كيف. بالإضافة إلى ذلك ، فهو يعرف كيفية التسليم بشكل موثوق ، أي أنه يكتب على قرص على الجهاز المحلي ومرة واحدة كل فترة (هناك ، مرة واحدة في بضع ثوان) يحاول تسليم البيانات من هذا الملف. وفي البداية استخدمنا تنسيق القيم المعتاد - وليس بعض التنسيقات الثنائية ، تنسيق النص (كما في SQL المعتاد).
ولكن بعد ذلك حدث هذا. استخدمنا التسليم الموثوق ، وكتب السجلات ، ثم قررنا (كانت مجموعة اختبار مشروطة) ... لقد أخرجوها لبضع ساعات ورفعوها مرة أخرى ، وبدأ الإدراج من آلاف الخوادم - اتضح أن Klickhouse لا يزال لديه "خيط على اتصال "- وفقًا لذلك ، في آلاف الاتصالات ، يؤدي الإدراج النشط إلى معدل تحميل على الخادم يبلغ حوالي واحد ونصف الألف. من المثير للدهشة أن الخادم قبل الطلبات ، لكن تم إدراج هذه البيانات بعد مرور بعض الوقت ؛ ولكن كان من الصعب للغاية على الخادم خدمتها ...
أضف nginx
مثل هذا الحل لمؤشر الترابط لكل نموذج اتصال هو nginx. وضعنا nginx أمام Clickhouse ، وفي نفس الوقت قمنا بتعيين التوازن على نسختين متماثلتين (قمنا بزيادة سرعة الإدراج بمقدار 2 مرات ، على الرغم من عدم كونها كذلك) وحصر عدد الاتصالات بـ Clickhouse ، وعلى المنبع ، وبالتالي ، مما كانت عليه في 50 مركبة ، يبدو أنه لا معنى لإدراجها.
ثم أدركنا أن هذا المخطط بشكل عام له عيوب ، لأن لدينا nginx واحد هنا. وفقًا لذلك ، إذا كان nginx يوضع ، على الرغم من وجود النسخ المتماثلة ، فإننا نفقد البيانات أو ، على الأقل ، لا نكتب في أي مكان. لذلك ، فعلنا لدينا موازنة الحمل. لقد أدركنا أيضًا أن "Clickhouse" لا يزال مناسبًا للسجلات ، وأن "الشيطان" بدأ أيضًا في كتابة سجلاته في "Clickhouse" أيضًا - ملائم جدًا ، لنكون صادقين. ما زلنا نستخدمها في "الشياطين" الأخرى.
ثم اكتشفوا مثل هذه المشكلة المثيرة للاهتمام: إذا كنت تستخدم طريقة غير قياسية تمامًا للإدراج في وضع SQL ، فيجب فرض محلل متكامل يستند إلى AST SQL ، وهو أمر بطيء نوعًا ما. وفقًا لذلك ، أضفنا الإعدادات حتى لا يحدث هذا أبدًا. لقد حققنا موازنة تحميل ، وفحوصات صحية ، بحيث إذا مات أحد ، فإننا لا نزال نترك البيانات. لقد حصلنا على الجداول الكافية حتى نحتاج إلى مجموعات "Clickhouse" مختلفة. وبدأنا التفكير في استخدامات أخرى - على سبيل المثال ، أردنا كتابة سجلات من وحدات nginx ، ولا يمكنهم التواصل باستخدام RPC الخاص بنا. حسنًا ، أرغب في تعليمهم بطريقة ما كيفية الإرسال - على سبيل المثال ، عبر UDP لاستقبال الأحداث على المضيف المحلي ثم إرسالها إلى "Clickhouse".
خطوة واحدة من القرار
بدأ المخطط النهائي في الظهور بهذا الشكل (الإصدار الرابع من هذا المخطط): على كل خادم أمام Clickhouse يوجد nginx (على نفس الخادم ، علاوة على ذلك) يقوم بإرسال طلبات إلى المضيف المحلي بحد أقصى لعدد اتصالات 50 قطعة. والآن هذا المخطط كان يعمل بالفعل ، كان جيدًا جدًا.
عشنا مثل هذا لمدة شهر تقريبا. كان الجميع سعداء ، مضيفا الجداول ، مضيفا ، مضيفا ... بشكل عام ، اتضح أن الطريقة التي أضفنا بها الجداول المؤقتة لم تكن مثالية (دعنا نقول ذلك). لقد صنعنا 16 قطعة في كل طاولة وفاصل زمني لبضع ثوان ؛ كان لدينا 20 طاولة و 8 إدخالات في الثانية الواحدة ذهبت إلى كل جدول - وفي تلك اللحظة بدأ "Clickhouse" ... بدأت السجلات فارغة. لم يتم تمريرها ... كان لدى Nginx شيء مثير للاهتمام بشكل افتراضي بحيث إذا كانت الاتصالات قد انتهت عند المنبع ، فذلك يعني أن "502" يعطي جميع الطلبات الجديدة.
وهنا علينا (نظرت للتو إلى السجلات الموجودة في "Clickhouse" التي نظرت إليها) في مكان ما يفشل فيه حوالي نصف بالمائة من الطلبات. وفقا لذلك ، كان استخدام القرص عالية ، وكان هناك العديد من عمليات الدمج. حسنا ، ماذا فعلت؟ بطبيعة الحال ، لم أبدأ في فهم سبب انتهاء الاتصال والتنقيب.
استبدال nginx مع الوكيل العكسي
قررت أننا نحتاج إلى إدارة هذا الأمر بأنفسنا ، وعدم إعطائه إلى nginx - لا يعرف nginx الجداول الموجودة في "Clickhouse" ، واستبدل nginx ببروكسي عكسي ، وهذا ما كتبته أيضًا.
ماذا يفعل؟ إنه يعمل على أساس مكتبة fasthttp "goosh" ، أي بسرعة تقريبًا بنفس سرعة nginx. عذرًا ، إيجور ، إذا كنت هنا (ملاحظة: إيجور سيسوف هو مبرمج روسي أنشأ خادم الويب nginx). يمكنه فهم أي نوع من الاستعلامات - INSERT أو SELECT - على التوالي ، يحتفظ بتجمعات اتصال مختلفة لأنواع مختلفة من الاستعلامات.
وفقًا لذلك ، حتى لو لم يكن لدينا وقت لإكمال الطلبات ، فإن "التحديدات" سوف تمر ، والعكس صحيح. ويقوم بتجميع البيانات في جداول عازلة - مع وجود مخزن مؤقت صغير: إذا كان هناك أي أخطاء وأخطاء بناء جملة وما إلى ذلك - بحيث أثرت قليلاً على بقية البيانات ، لأنه عندما يتم إدراجنا ببساطة في الجداول العازلة ، كان لدينا صغير " bachi "، وجميع أخطاء أخطاء بناء الجملة أثرت فقط على هذه القطعة الصغيرة ؛ وهنا سوف تؤثر بالفعل على المخزن المؤقت الكبير. صغير هو 1 ميغا بايت ، وهذا ليس صغيرا جدا.
لا يؤدي إدخال مزامنة واستبدال nginx بشكل أساسي إلى نفس الشيء الذي فعله nginx من قبل - Kittenhouse لا يحتاج إلى تغيير محلي لهذا الغرض. ونظرًا لأنه يستخدم fasthttp ، فهو سريع جدًا - يمكنك تقديم أكثر من 100 ألف طلب في الثانية من الإدخالات الفردية من خلال الوكلاء العكسيين. من الناحية النظرية ، يمكنك إدراج سطر واحد في الوكيل العكسي kittenhouse ، لكننا بالتأكيد لا نفعل ذلك.
بدأ المخطط على النحو التالي: Kittenhouse ، وهو وكيل عكسي يقوم بتجميع العديد من الطلبات في الجداول ، وبالتالي تقوم الجداول المؤقتة بإدراجها في الجداول الرئيسية.
القاتل - حل مؤقت ، هريرة - دائم
كانت هناك مشكلة مثيرة للاهتمام ... هل استخدم أحدكم fasthttp؟ الذين استخدموا fasthttp مع طلبات POST؟ ربما ، لم يكن الأمر يستحق ذلك في الواقع ، لأنه يقوم بتخزين نص الطلب بشكل افتراضي ، وقمنا بتعيين حجم المخزن المؤقت البالغ 16 ميغابايت. توقف الإدخال في الوقت المناسب في مرحلة ما ، ومن بين عشرات الآلاف من الخوادم ، بدأت مجموعات بحجم 16 ميجابايت في الظهور ، وتم تخزينها جميعًا في الذاكرة قبل تسليمها إلى Clickhouse. تبعا لذلك ، نفدت الذاكرة ، وجاء قاتل Out-Of-Memory ، وقتل الوكيل العكسي (أو "Clickhouse" ، والذي يمكن نظريا "أن يأكل" أكثر من الوكيل العكسي). تكررت الدورة. ليست مشكلة جميلة جدا على الرغم من أننا واجهنا هذا إلا بعد بضعة أشهر من العملية.
ماذا فعلت؟ مرة أخرى ، لا أحب حقًا فهم ما حدث بالضبط. يبدو لي واضحًا جدًا أنه لا توجد حاجة للتخزين المؤقت في الذاكرة. لم أستطع تصحيح fasthttp ، على الرغم من أنني حاولت. لكنني وجدت طريقة لجعلها لا تحتاج إلى تصحيح أي شيء ، وتوصلت إلى طريقة خاصة بي في HTTP - والتي يطلق عليها KITTEN. حسنًا ، هذا منطقي - "VK" ، "Kitten" ... كيف غير ذلك؟ ..
إذا وصل طلب إلى الخادم باستخدام طريقة Kitten ، فيجب أن يجيب الخادم على "مواء" - بشكل منطقي. إذا أجاب على هذا ، فيُعتقد أنه يفهم هذا البروتوكول ، ثم اعترض الاتصال (توجد مثل هذه الطريقة في fasthttp) ، وينتقل الاتصال إلى الوضع "الخام". لماذا أحتاج هذا؟ أريد التحكم في كيفية حدوث القراءة من اتصالات TCP. يتمتع TCP بخاصية رائعة: إذا لم يقرأ أحد من هذا الجانب ، فسيبدأ السجل في الانتظار ، ولا تنفق الذاكرة بشكل خاص على هذا.
وهكذا قرأت في مكان ما من 50 عميلًا في وقت واحد (من خمسين لأنه من المؤكد أن يكون الخمسون كافيًا ، حتى لو كان مصدره تيار مستمر آخر) ... انخفض الاستهلاك مع هذا النهج 20 مرة على الأقل ، لكنني بصراحة ، لم أستطع قياس مقدار ذلك بالضبط ، لأنه لا معنى له بالفعل (لقد أصبح بالفعل على مستوى الخطأ). البروتوكول ثنائي ، أي أن هناك اسم جدول وبيانات ؛ لا توجد رؤوس http ، لذلك لم أستخدم مقبس ويب (لست بحاجة للتواصل مع المتصفحات - لقد صنعت بروتوكولًا يناسب احتياجاتنا). ومعه كان كل شيء على ما يرام.
الجدول العازلة أمر محزن
في الآونة الأخيرة ، واجهنا ميزة أخرى مثيرة للاهتمام من الجداول العازلة. وهذه المشكلة هي بالفعل أكثر إيلاما بكثير من بقية. : «», «», , (, 60 ); Alter … «», «», , «» – , - , «» . ? ?
, , , . , , , «» ( – , , ), … , «» ( - «» ) – , - : ( , ), «» , - , . , «», – .
(, ) – «» query_thread_log. , - . 840 (100 ). , (, , , ) «» (inserts). , «» – «» . , – , . لماذا؟ , ! .
, ? «». .
«KitttenHouse»
, ? . ! : , , - . , .
, «», – , (, - ) , , – .
? . , , 10 , – -, , . , , , , – , «», 100 - – , , , . , . , .
, , . : , - , , , read only . ? . – - , - … ( , «», ClickHouse) ? ? , . . : , . , . .
. . , - ?.. «»? - … «»? , , . , . , .
– . , . , : , , ( ), – , .
Sequel Pro, «», . : «, -?» ? 2018-? , «» (MySQL) , «», ! «», – , .
, , , , , , , , affected rows ( ), . .
. «», . - - . .
«»
, «», , . , , – . , … , , .
TCP? , «» UDP. TCP… , , : «, ! , UDP». , TCP . , , – - ; , .
«» «» HighLoad Siberia, « »… , … , , . - , - , – , ( , , ).
. ! Github
. «» .
: – , . , VHS.
( – ): – VHS, ?
: – , «» – ! , 5 !
سؤال من الجمهور (من الآن فصاعدا - ح): - مساء الخير. شكرا جزيلا على التقرير لدي سؤالان. سأبدأ بحرف تافه: هل يؤثر عدد الأحرف t باسم "Kittenhouse" على المخططات (3 ، 4 ، 7 ...) على رضا القطط؟
UN: - كمية ماذا؟
Z: - الحروف ر. هناك ثلاثة ر ، في مكان ما ثلاثة ر.
UN: - هل قمت بالفعل بتصحيح هذا؟ حسنا بالطبع يفعل! هذه منتجات مختلفة - لقد كذبت عليك طوال هذا الوقت. حسنًا ، أنا أمزح - إنه ليس كذلك. اه ، هنا! لا ، هذا هو نفس الشيء ، لقد أغلقت.
Z: - شكرا لك. السؤال الثاني خطير. بقدر ما أفهم ، في "Clickhouse" ، تعيش الجداول العازلة بشكل حصري في الذاكرة ، ولا يتم تخزينها مؤقتًا على القرص ، وبالتالي فهي ليست ثابتة.
الأمم المتحدة: - نعم.
Z: - وفي الوقت نفسه ، يتم تنفيذ التخزين المؤقت على القرص الخاص بك على العميل ، مما يعني بعض الضمان لتسليم هذه السجلات نفسها. لكن في Clickhouse ، هذا غير مضمون. اشرح كيف يتم تنفيذ الضمان ، بسبب ماذا؟ .. هذه الآلية أكثر تفصيلاً
الأمم المتحدة: - نعم ، من الناحية النظرية ، لا توجد تناقضات ، لأنه يمكنك اكتشاف مليون طريقة مختلفة في الواقع عند سقوط "Clickhouse". إذا تعطل "Clickhouse" (إذا لم يكتمل بشكل صحيح) ، فيمكنك ، تقريبًا ، إرجاع سجلك الذي كتبته قليلاً والبدء من اللحظة التي يكون فيها كل شيء على ما يرام. دعنا نرجعها قبل دقيقة ، أي ، يعتقد أنها تومض كل شيء في دقيقة واحدة.
Z: - وهذا هو ، Kittenhouse يحتفظ النافذة لفترة أطول وفي حالة سقوط يمكن التعرف عليها والاسترخاء؟
الأمم المتحدة: - ولكن هذا من الناحية النظرية. في الممارسة العملية ، نحن لا نفعل ذلك ، والتسليم الموثوق به من الصفر إلى الأوقات اللانهاية. ولكن في المتوسط واحد. نحن مقتنعون بأنه في حالة تعطل "Clickhouse" لسبب ما أو "إعادة تشغيل" الخوادم ، فإننا نفقد قليلاً. في جميع الحالات الأخرى ، لن يحدث شيء.
Z: - مرحبا. منذ البداية ، بدا لي أنك ستستخدم UDP بالفعل من بداية التقرير. لديك http ، كل ذلك ... ومعظم المشاكل التي وصفتها ، كما أفهمها ، سببها هذا الحل المحدد ...
UN: - ماذا نستخدم TCP؟
Z: - في الواقع ، نعم.
الامم المتحدة: - رقم
Z: - كان مع fasthttp أن لديك مشاكل ، مع الاتصال كان لديك مشاكل. إذا كنت تستخدم UDP للتو ، فستوفر عليك الوقت. حسنًا ، ستكون هناك مشاكل في الرسائل الطويلة أو أي شيء آخر ...
الأمم المتحدة: - مع ماذا؟
Z: - مع الرسائل الطويلة ، لأنها قد لا تنسجم مع MTU ، شيء آخر ... حسنًا ، قد تنشأ مشاكلك. والسؤال هو: لماذا ليس UDP؟
UN: - أعتقد أن المؤلفين الذين طوروا TCP / IP أكثر ذكاءً مني ويعرفون كيفية إجراء تسلسل للرزم بشكل أفضل (حتى يذهبون) ، وفي نفس الوقت ضبط نافذة الإرسال ، وعدم زيادة التحميل على الشبكة ، وتقديم ملاحظات حول ما يقرأ ، وليس العد من الجانب الآخر ... كل هذه المشاكل ، في رأيي ، ستكون أيضا في UDP ، فقط سأضطر إلى كتابة كود أكثر مما كتبت بالفعل من أجل تنفيذ نفس الشيء بنفسي وعلى الأرجح سيكون سيئًا. أنا لا أحب الكتابة في C ، وليس مثل هناك ...
Z: - مريحة فقط! أرسلت حسنا ولا تتوقع أي شيء - لديك بشكل غير متزامن تماما. عاد إشعار بأن كل شيء على ما يرام - وهذا يعني أنه قد حان ؛ لم يأت - وهذا يعني سيئة.
UN: - أحتاج إلى كل من هذا والآخر - أحتاج إلى أن أكون قادرًا على إرسال كليهما مع ضمان التسليم ، ودون ضمان التسليم. هذان سيناريوهان مختلفان. بعض السجلات التي لا أحتاج إلى فقدانها أو عدم فقدها في حدود المعقول.
Z: - لن آخذ الوقت. هذا يجب أن يناقش لفترة أطول. شكرا لك
المذيع: - من لديه أسئلة - أقلام في السماء!
Z: - مرحبا ، أنا ساشا. في مكان ما في منتصف التقرير ، كان هناك شعور بأنه من الممكن ، بالإضافة إلى برنامج التعاون الفني ، استخدام حل جاهز - نوع من "كافكا".
الأمم المتحدة: "حسنًا ... أخبرتك أنني لا أريد استخدام خوادم وسيطة ، لأن ... إلى كافكا - اتضح أن لدينا عشرة آلاف مضيف ؛ في الواقع ، لدينا أكثر - عشرات الآلاف من المضيفين. مع Kafka ، دون أي وكلاء ، يمكن أن يضر أيضًا. بالإضافة إلى ذلك ، الأهم من ذلك ، أنه لا يزال يعطي "الكمون" ، ويعطي المضيفين الإضافية التي تحتاج إليها. وأنا لا أريد أن يكون لهم - أريد ...
Z: - ولكن في النهاية اتضح على أي حال.
الأمم المتحدة: - لا ، لا يوجد مضيفون! كل شيء يعمل على المضيفين Clickhouse.
Z: - ولكن ماذا عن Kittenhouse ، العكس هو - أين يعيش؟
UN: - في مضيف Klickhouse ، لا يكتب أي شيء على القرص.
Z: - حسنا ، دعنا نقول.
المذيع: - يرضيك؟ هل يمكننا إعطاء راتب؟
Z: - نعم ، نعم. في الواقع ، هناك الكثير من العكازات من أجل الحصول على نفس الشيء ، والآن - الجواب السابق على موضوع يناقض TCP ، في رأيي ، هذا الموقف. يبدو أنك تستطيع أن تفعل كل شيء على ركبتك في وقت أقل بكثير.
الأمم المتحدة: - ولماذا لا أرغب في استخدام "كافكا" ، لأنه كان هناك الكثير من الشكاوى في برقية "Clickhouse" في Telegram والتي ، على سبيل المثال ، فقدت رسائل من "Kafka". ليس من كافكا نفسها ، ولكن في دمج كافكا وكليكهاوس ؛ أو شيء لم يتصل هناك. بمعنى تقريبي ، سيكون من الضروري إذن أن يكتب العميل لكافكا في ذلك الوقت. لا أعتقد أنه سيتم الحصول على حل أبسط وأكثر موثوقية.
Z: - أخبرني ، لماذا لم تجرب بعض الخطوط أو بعض الحافلات المشتركة؟ نظرًا لأنك تقول أنه كان من الممكن معك بشكل غير متزامن أن تقود عبر قائمة الانتظار السجلات نفسها وأيضًا أن تحصل بشكل غير متزامن من خلال قائمة الانتظار استجابة؟
UN: - يرجى اقتراح أي قوائم الانتظار يمكن استخدامها؟
Z: - أي ، حتى دون ضمان أنهم يسيرون في النظام. أي Redis ، RMQ ...
UN: - لدي شعور بأن Redis على الأرجح لن يتمكن من سحب وحدة تخزين الإدخال هذه حتى على مضيف واحد (بمعنى العديد من الخوادم) التي تسحب Clickhouse. لا يمكنني تأكيد ذلك بأي دليل (لم أقم بتقييمه) ، لكن يبدو لي أن Redis ليس هو الحل الأفضل هنا. من حيث المبدأ ، يمكنك اعتبار هذا النظام بمثابة قائمة انتظار رسائل مرتجلة ، ولكن هذا مخصص فقط لـ "Clickhouse"
المذيع: - يوري ، شكرا جزيلا لك. أقترح إنهاء الأسئلة والأجوبة حول هذا الموضوع وأقول أي من الأشخاص الذين طرحوا السؤال سوف يقدم لنا كتابًا.
الأمم المتحدة: - أود أن أقدم كتابًا لأول شخص طرح سؤالًا.
المذيع: - عظيم! ! ممتاز عظيم! شكرا جزيلا
قليلا من الإعلان :)
شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المواد المثيرة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك
VPS المستندة إلى مجموعة النظراء للمطورين من 4.99 دولار ، وهو
تمثيلي فريد من الخوادم على مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps من 19 $ أو كيفية تقسيم الخادم؟ (تتوفر خيارات مع RAID1 و RAID10 ، ما يصل إلى 24 مركزًا وما يصل إلى 40 جيجابايت من ذاكرة DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ فقط لدينا
2 من Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6 جيجا هرتز 14 جيجا بايت 64 جيجا بايت DDR4 4 × 960 جيجا بايت SSD 1 جيجابت في الثانية 100 TV من 199 دولار في هولندا! Dell R420 - 2x E5-2430 سعة 2 جيجا هرتز 6 جيجا بايت 128 جيجا بايت ذاكرة DDR3 2x960GB SSD بسرعة 1 جيجابت في الثانية 100 تيرابايت - من 99 دولارًا! اقرأ عن
كيفية بناء البنية التحتية فئة باستخدام خوادم V4 R730xd E5-2650d تكلف 9000 يورو عن بنس واحد؟