على الرغم من حقيقة أن هناك الآن الكثير من البيانات في كل مكان تقريبًا ، إلا أن قواعد البيانات التحليلية لا تزال غريبة تمامًا. هم معروفون بشكل سيئ وقدرة أسوأ على استخدامها بفعالية. يستمر الكثيرون في "أكل الصبار" باستخدام MySQL أو PostgreSQL ، المصممين لسيناريوهات أخرى ، أو يعانون من NoSQL ، أو يدفعون مبالغ زائدة مقابل الحلول التجارية. يغير ClickHouse قواعد اللعبة ويقلل بشكل كبير من عتبة الدخول إلى عالم DBMS التحليلي.
تقرير من BackEnd Conf 2018 ويتم نشره بإذن من المتحدث.
من أنا ولماذا أتحدث عن ClickHouse؟ أنا مدير تطوير في LifeStreet ، والذي يستخدم ClickHouse. أيضًا ، أنا مؤسس Altinity. إنه شريك Yandex الذي يروج لـ ClickHouse ويساعد Yandex على جعل ClickHouse أكثر نجاحًا. جاهز أيضًا لمشاركة المعرفة حول ClickHouse.
وأنا لست شقيق بيتيا زايتسيف. كثيرا ما يسألني عن هذا. لا ، نحن لسنا إخوة.
"يعلم الجميع" أن ClickHouse:
- سريع جدا،
- مريح جدا
- تستخدم في ياندكس.
لا يُعرف سوى القليل عن الشركات وكيفية استخدامها.
سأخبرك لماذا وأين وكيف يتم استخدام ClickHouse ، باستثناء Yandex.
سأخبرك كيف يتم حل المهام المحددة بمساعدة ClickHouse في الشركات المختلفة ، وما هي أدوات ClickHouse التي يمكنك استخدامها لمهامك ، وكيف تم استخدامها في شركات مختلفة.
التقطت ثلاثة أمثلة تعرض ClickHouse من زوايا مختلفة. أعتقد أنه سيكون ممتعًا.
السؤال الأول هو: "لماذا نحتاج إلى ClickHouse؟". يبدو أنه سؤال واضح إلى حد ما ، لكن هناك أكثر من إجابة واحدة عليه.
- الجواب الأول هو الأداء. ClickHouse سريع جدا. التحليلات على ClickHouse سريعة جدًا أيضًا. يمكن استخدامه غالبًا عندما يكون شيء آخر بطيئًا جدًا أو سيئًا للغاية.
- الجواب الثاني هو التكلفة. وقبل كل شيء ، تكلفة التوسع. على سبيل المثال ، Vertica هي قاعدة بيانات رائعة للغاية. إنه يعمل بشكل جيد للغاية إذا لم يكن لديك الكثير من تيرابايت من البيانات. ولكن عندما يتعلق الأمر بمئات تيرابايت أو بيتابايت ، فإن تكلفة الترخيص والدعم تذهب إلى مبلغ كبير إلى حد ما. وهي باهظة الثمن. و ClickHouse مجاني.
- الإجابة الثالثة هي تكلفة التشغيل. هذا نهج مختلف قليلا. RedShift هو تناظرية رائعة. في RedShift ، يمكنك اتخاذ قرار بسرعة كبيرة. ستعمل بشكل جيد ، لكن في نفس الوقت ، كل ساعة ، كل يوم ، وكل شهر ، ستدفع لأمازون غاليًا جدًا ، لأن هذه خدمة باهظة الثمن إلى حد كبير. Google BigQuery أيضًا. إذا استخدمها شخص ما ، فهو يعلم أنه يمكنك تشغيل عدة طلبات والحصول على فاتورة بمئات الدولارات فجأة.
ClickHouse ليس لديه هذه المشاكل.
أين يتم استخدام ClickHouse الآن؟ بالإضافة إلى Yandex ، يتم استخدام ClickHouse في مجموعة من الشركات والشركات المختلفة.
- بادئ ذي بدء ، هذه تحليلات تطبيق الويب ، أي أنها حالة استخدام جاءت من Yandex.
- تستخدم العديد من شركات AdTech ClickHouse.
- العديد من الشركات التي تحتاج إلى تحليل سجلات المعاملات من مصادر مختلفة.
- تستخدم العديد من الشركات ClickHouse لمراقبة سجلات الأمان. يقومون بتحميلها على ClickHouse ، وإعداد التقارير ، والحصول على النتائج التي يحتاجون إليها.
- بدأت الشركات في استخدامه في التحليل المالي ، أي أن الشركات الكبيرة تدريجيًا تقترب أيضًا من ClickHouse.
- توهج السحاب. إذا قام شخص ما بمتابعة ClickHouse ، فمن المحتمل أن يكون قد سمع باسم هذه الشركة. هذا هو أحد المساهمين الأساسيين من المجتمع. ولديهم تثبيت ClickHouse خطير للغاية. على سبيل المثال ، صنعوا محرك كافكا لـ ClickHouse.
- بدأت شركات الاتصالات في استخدام. تستخدم العديد من الشركات ClickHouse إما كدليل على المفهوم أو قيد الإنتاج بالفعل.
- تستخدم شركة واحدة ClickHouse لمراقبة عمليات الإنتاج. يقومون باختبار الدوائر الدقيقة ، وشطب مجموعة من المعلمات ، وهناك حوالي 2 خاصية. ثم يقومون بتحليل ما إذا كانت اللعبة جيدة أم سيئة.
- تحليلات Blockchain. هناك شركة روسية مثل Bloxy.info. هذا تحليل لشبكة الإيثيريوم. لقد فعلوا هذا أيضًا على ClickHouse.
والحجم لا يهم. هناك العديد من الشركات التي تستخدم خادمًا صغيرًا واحدًا. وهو يسمح لهم بحل مشاكلهم. وحتى المزيد من الشركات تستخدم مجموعات كبيرة من العديد من الخوادم أو العشرات من الخوادم.
وإذا نظرت إلى السجلات ، فحينئذٍ:
- Yandex: أكثر من 500 خادم ، يقومون بتخزين 25 مليار سجل يوميًا هناك.
- LifeStreet: 60 خادمًا ، ما يقرب من 75 مليار سجل يوميًا. هناك عدد أقل من الخوادم وسجلات أكثر من Yandex.
- CloudFlare: 36 خادمًا ، يوفرون 200 مليار سجل يوميًا. لديهم عدد أقل من الخوادم ويخزنون المزيد من البيانات.
- بلومبيرج: 102 خادمًا ، حوالي تريليون إدخال يوميًا. صاحب السجل.
من الناحية الجغرافية ، هذا أيضًا كثير. تُظهر هذه الخريطة هنا خريطة حرارية لمكان استخدام ClickHouse في العالم. تبرز هنا روسيا والصين وأمريكا بوضوح. هناك عدد قليل من الدول الأوروبية. وهناك 4 مجموعات.
هذا تحليل مقارن ، لا داعي للبحث عن الأرقام المطلقة. هذا تحليل للزوار الذين قرأوا مواد باللغة الإنجليزية على موقع Altinity ، لأنه لا يوجد أشخاص يتحدثون الروسية هناك. وروسيا وأوكرانيا وبيلاروسيا ، أي الجزء الناطق بالروسية من المجتمع ، هؤلاء هم أكثر المستخدمين عددًا. ثم تأتي الولايات المتحدة وكندا. الصين تلحق بالركب إلى حد كبير. لم تكن هناك الصين تقريبًا قبل ستة أشهر ، والآن تجاوزت الصين أوروبا بالفعل وتستمر في النمو. أوروبا القديمة أيضًا ليست بعيدة عن الركب ، والرائدة في استخدام ClickHouse هي ، بشكل غريب بما فيه الكفاية ، فرنسا.
لماذا أقول كل هذا؟ لإثبات أن ClickHouse أصبح حلاً قياسيًا لتحليل البيانات الضخمة ويستخدم بالفعل في الكثير من الأماكن. إذا كنت تستخدمه ، فأنت في الاتجاه الصحيح. إذا كنت لا تستخدمه بعد ، فلا داعي للخوف من تركك بمفردك ولن يساعدك أحد ، لأن الكثيرين يفعلون ذلك بالفعل.
هذه أمثلة على استخدام ClickHouse الحقيقي في العديد من الشركات.
- المثال الأول هو شبكة إعلانات: الترحيل من Vertica إلى ClickHouse. وأعرف عددًا قليلاً من الشركات التي انتقلت من Vertica أو هي في طور التحول.
- المثال الثاني هو تخزين المعاملات على ClickHouse. هذا مثال مبني على Antipatterns. كل شيء لا ينبغي القيام به في ClickHouse بناءً على نصيحة المطورين يتم هنا. وقد تم القيام به بشكل فعال لدرجة أنه يعمل. وهو يعمل بشكل أفضل بكثير من حل المعاملات النموذجي.
- المثال الثالث هو الحوسبة الموزعة على ClickHouse. كان هناك سؤال حول كيفية دمج ClickHouse في نظام Hadoop البيئي. سأعرض مثالاً على كيفية قيام شركة بشيء مشابه لخريطة تقليل الحاوية على ClickHouse ، وتتبع توطين البيانات ، وما إلى ذلك ، لحساب مهمة غير تافهة للغاية.
- LifeStreet هي شركة Ad Tech لديها كل التقنيات التي تأتي مع شبكة إعلانية.
- تعمل في تحسين الإعلانات وعروض الأسعار الآلية.
- الكثير من البيانات: حوالي 10 مليارات حدث في اليوم. في نفس الوقت ، يمكن تقسيم الأحداث هناك إلى عدة أحداث فرعية.
- هناك العديد من عملاء هذه البيانات ، وهؤلاء ليسوا أشخاصًا فحسب ، بل هم أكثر من ذلك بكثير - فهذه خوارزميات متنوعة تشارك في العطاءات الآلية.
لقد قطعت الشركة طريقًا طويلًا وشائكًا. وتحدثت عن ذلك على HighLoad. أولاً ، انتقل LifeStreet من MySQL (مع توقف قصير في Oracle) إلى Vertica. ويمكنك أن تجد قصة عنها.
وكان كل شيء جيدًا جدًا ، ولكن سرعان ما أصبح واضحًا أن البيانات تنمو وأن Vertica باهظة الثمن. لذلك ، تم البحث عن بدائل مختلفة. بعضها مدرج هنا. وفي الواقع ، قمنا بإثبات المفهوم أو في بعض الأحيان اختبار الأداء لجميع قواعد البيانات تقريبًا التي كانت متاحة في السوق من العام الثالث عشر إلى العام السادس عشر وكانت مناسبة تقريبًا من حيث الوظيفة. وتحدثت أيضًا عن بعضها على HighLoad.
كانت المهمة هي الهجرة من Vertica في المقام الأول ، لأن البيانات نمت. ونما بشكل كبير على مر السنين. ثم ذهبوا على الرف ، ولكن مع ذلك. وتوقعًا لهذا النمو ، ومتطلبات العمل لكمية البيانات التي يجب إجراء نوع من التحليلات عليها ، كان من الواضح أن البيتابايت ستتم مناقشته قريبًا. والدفع مقابل البيتابايت باهظ الثمن بالفعل ، لذلك كنا نبحث عن بديل إلى أين نذهب.
الى اين اذهب؟ ولفترة طويلة لم يكن واضحًا على الإطلاق إلى أين نذهب ، لأنه من ناحية هناك قواعد بيانات تجارية ، يبدو أنها تعمل بشكل جيد. يعمل البعض مثل Vertica تقريبًا ، والبعض الآخر أسوأ. لكنها كلها باهظة الثمن ، ولا يمكن العثور على شيء أرخص وأفضل.
من ناحية أخرى ، هناك حلول مفتوحة المصدر ، وهي ليست كثيرة جدًا ، أي للتحليلات ، يمكن عدها على الأصابع. وهي مجانية أو رخيصة ، لكنها بطيئة. وغالبًا ما يفتقرون إلى الوظائف الضرورية والمفيدة.
ولم يكن هناك ما يجمع بين الخير الموجود في قواعد البيانات التجارية وكل ما هو مجاني مفتوح المصدر.
لم يكن هناك شيء حتى قام Yandex ، بشكل غير متوقع ، بسحب ClickHouse ، مثل الساحر من قبعة ، مثل الأرنب. وكان قرارًا غير متوقع ، فهم ما زالوا يطرحون السؤال: "لماذا؟" ، لكن مع ذلك.
وعلى الفور في صيف عام 2016 ، بدأنا في إلقاء نظرة على ماهية ClickHouse. واتضح أنه في بعض الأحيان يمكن أن يكون أسرع من Vertica. اختبرنا سيناريوهات مختلفة على طلبات مختلفة. وإذا استخدم الاستعلام جدولًا واحدًا فقط ، أي بدون أي صلات (انضمام) ، فإن ClickHouse كان أسرع بمرتين من Vertica.
لم أكن كسولًا جدًا ونظرت إلى اختبارات Yandex في ذلك اليوم. إنه نفس الشيء هناك: ClickHouse أسرع بمرتين من Vertica ، لذلك غالبًا ما يتحدثون عنها.
ولكن إذا كانت هناك عمليات ضم في الاستعلامات ، فسيظهر كل شيء بشكل لا لبس فيه. ويمكن أن يكون ClickHouse بطيئًا مرتين مثل Vertica. وإذا صححت الطلب قليلاً وأعدت كتابته ، فسيكونان متساويين تقريبًا. ليس سيئًا. و مجاني.
وبعد تلقي نتائج الاختبار ، والنظر إليها من زوايا مختلفة ، انتقل LifeStreet إلى ClickHouse.
هذه هي السنة السادسة عشر ، أذكرك. كان الأمر أشبه بمزحة عن الفئران التي تبكي وتخدش نفسها ، لكنها استمرت في أكل الصبار. وهذا تم وصفه بالتفصيل ، يوجد فيديو حول هذا ، إلخ.
لذلك لن أتحدث عنها بالتفصيل ، بل سأتحدث فقط عن النتائج وبعض الأشياء الشيقة التي لم أتحدث عنها في ذلك الوقت.
النتائج هي:
- هجرة ناجحة وأكثر من عام النظام يعمل بالفعل في الإنتاج.
- زادت الإنتاجية والمرونة. من بين 10 مليارات سجل يمكننا تخزينها يوميًا ولفترة قصيرة ، تخزن LifeStreet الآن 75 مليار سجل يوميًا ويمكنها القيام بذلك لمدة 3 أشهر أو أكثر. إذا عدت عند الذروة ، فهذا يصل إلى مليون حدث في الثانية. يصل أكثر من مليون استعلام SQL يوميًا إلى هذا النظام ، معظمها من روبوتات مختلفة.
- على الرغم من حقيقة أنه تم استخدام المزيد من الخوادم في ClickHouse مقارنةً بـ Vertica ، إلا أنها تم توفيرها أيضًا على الأجهزة ، لأنه تم استخدام أقراص SAS باهظة الثمن في Vertica. استخدم ClickHouse SATA. و لماذا؟ لأنه في إدراج Vertica متزامن. وتتطلب المزامنة ألا تبطئ الأقراص كثيرًا ، وأيضًا ألا تبطئ الشبكة كثيرًا ، أي أنها عملية مكلفة إلى حد ما. وفي ClickHouse إدراج غير متزامن. علاوة على ذلك ، يمكنك دائمًا كتابة كل شيء محليًا ، ولا توجد تكاليف إضافية لذلك ، لذلك يمكن إدراج البيانات في ClickHouse بشكل أسرع بكثير من Vertika ، حتى على محركات الأقراص الأبطأ. والقراءة هي نفسها تقريبا. القراءة على SATA ، إذا كانت في RAID ، فهذا كله سريع بما فيه الكفاية.
- لا يقتصر على الترخيص ، أي 3 بيتابايت من البيانات في 60 خادمًا (20 خادمًا نسخة متماثلة واحدة) و 6 تريليون سجل في الحقائق والتجميعات. لا شيء من هذا القبيل يمكن توفيره في Vertica.
أنتقل الآن إلى الأمور العملية في هذا المثال.
- الأول هو مخطط فعال. يعتمد الكثير على المخطط.
- والثاني هو الجيل الفعال لـ SQL.
استعلام OLAP النموذجي هو تحديد. تنتقل بعض الأعمدة إلى المجموعة حسب ، وتذهب بعض الأعمدة إلى وظائف التجميع. هناك حيث يمكن تمثيله كشريحة من مكعب. يمكن اعتبار المجموعة بأكملها بمثابة إسقاط. وهذا هو سبب تسميته بتحليل البيانات متعدد المتغيرات.
وغالبًا ما يتم نمذجة هذا في شكل مخطط نجمي ، عندما تكون هناك حقيقة وخصائص مركزية لهذه الحقيقة على طول الجانبين ، على طول الأشعة.
وفيما يتعلق بالتصميم المادي ، وكيف يتناسب مع الطاولة ، فعادة ما يقومون بتمثيل طبيعي. يمكنك إلغاء التنسيق ، لكنها مكلفة على القرص وليست فعالة جدًا في الاستعلامات. لذلك ، فإنها عادةً ما تقوم بعمل تمثيل عادي ، أي جدول حقائق والعديد من جداول الأبعاد.
لكنها لا تعمل بشكل جيد في ClickHouse. هناك سببان:
- الأول هو أن ClickHouse ليس لديه صلات جيدة جدًا ، أي أن هناك صلات ، لكنها سيئة. بينما سيئة.
- والثاني أن الجداول لم يتم تحديثها. عادة في هذه الصفائح ، التي تدور حول الدائرة النجمية ، يجب تغيير شيء ما. على سبيل المثال ، اسم العميل واسم الشركة وما إلى ذلك. وهو لا يعمل.
وهناك طريقة للخروج من ذلك في ClickHouse. حتى اثنين:
- الأول هو استخدام القواميس. القواميس الخارجية هي التي تساعد 99٪ في حل مشكلة المخطط النجمي بالتحديثات وما إلى ذلك.
- والثاني هو استخدام المصفوفات. تساعد المصفوفات أيضًا في التخلص من الصلات ومشاكل التطبيع.
- لا يلزم الانضمام.
- قابل للترقية. منذ مارس 2018 ، ظهرت فرصة غير موثقة (لن تجد هذا في الوثائق) لتحديث القواميس جزئيًا ، أي تلك الإدخالات التي تغيرت. عمليا ، إنها مثل الطاولة.
- دائمًا في الذاكرة ، لذا فإن الانضمام إلى القاموس يعمل بشكل أسرع مما لو كان جدولًا موجودًا على القرص وليس حقيقة أنه موجود في ذاكرة التخزين المؤقت ، على الأرجح ليس كذلك.
- لست بحاجة إلى الانضمام أيضًا.
- هذا تمثيل مضغوط من 1 إلى متعدد.
- وفي رأيي ، المصفوفات مصنوعة للمهوسين. هذه هي وظائف لامدا وما إلى ذلك.
هذا ليس للكلمات الحمراء. هذه وظيفة قوية للغاية تتيح لك القيام بالعديد من الأشياء بطريقة بسيطة للغاية وأنيقة.
أمثلة نموذجية تساعد في حل المصفوفات. هذه الأمثلة بسيطة وواضحة بما فيه الكفاية:
- البحث عن طريق الكلمات. إذا كان لديك علامات تصنيف هناك وترغب في العثور على بعض المنشورات عن طريق الهاشتاج.
- البحث عن طريق أزواج مفتاح القيمة. هناك أيضًا بعض السمات ذات القيمة.
- تخزين قوائم المفاتيح التي تحتاج إلى ترجمتها إلى شيء آخر.
يمكن حل كل هذه المهام بدون مصفوفات. يمكن وضع العلامات في سطر ما وتحديدها بتعبير عادي أو في جدول منفصل ، ولكن بعد ذلك عليك القيام بالصلات.
وفي ClickHouse ، لا تحتاج إلى فعل أي شيء ، يكفي وصف مصفوفة السلسلة لعلامات التصنيف أو إنشاء بنية متداخلة لأنظمة القيمة الرئيسية.
قد لا تكون البنية المتداخلة هي أفضل اسم. هذه صفيفتان لهما جزء مشترك في الاسم وبعض الخصائص ذات الصلة.
ومن السهل جدًا البحث عن طريق العلامات. لديك وظيفة has، والذي يتحقق من احتواء المصفوفة على عنصر. الجميع ، وجدوا جميع الإدخالات التي تتعلق بمؤتمرنا.
البحث عن طريق subid أكثر تعقيدًا بعض الشيء. نحتاج أولاً إلى إيجاد فهرس المفتاح ، ثم نأخذ العنصر بهذا الفهرس ونتحقق من أن هذه القيمة هي ما نحتاجه. ومع ذلك ، فهي بسيطة للغاية وصغيرة الحجم.
التعبير النمطي الذي ترغب في كتابته إذا احتفظت بكل شيء في سطر واحد ، فسيكون ، أولاً ، أخرقًا. وثانيًا ، عملت لفترة أطول بكثير من مصفوفتين.
مثال آخر. لديك مصفوفة حيث تقوم بتخزين المعرف. ويمكنك ترجمتها إلى أسماء. وظيفة arrayMap. هذه دالة لامدا نموذجية. يمكنك تمرير تعبيرات لامدا هناك. وتقوم بسحب قيمة الاسم لكل معرّف من القاموس.
يمكن أن يتم البحث بنفس الطريقة. يتم تمرير وظيفة المسند التي تتحقق من تطابق العناصر.
هذه الأشياء تبسط الدائرة بشكل كبير وتحل مجموعة من المشاكل.
لكن المشكلة التالية التي نواجهها ، والتي أود أن أذكرها ، هي الاستعلامات الفعالة.
- لا يحتوي ClickHouse على مخطط استعلام. بالطبع لا.
- ومع ذلك ، لا تزال الاستفسارات المعقدة بحاجة إلى التخطيط. في أي حالات؟
- إذا كان هناك العديد من الصلات في الاستعلام ، فإنك تقوم بلفها في تحديدات فرعية. والترتيب الذي يتم تنفيذها به مهم.
- والثاني - إذا تم توزيع الطلب. لأنه في الاستعلام الموزع ، يتم توزيع التحديد الفرعي الداخلي فقط ، ويتم تمرير كل شيء آخر إلى خادم واحد قمت بالاتصال به وتنفيذه هناك. لذلك ، إذا قمت بتوزيع استعلامات مع العديد من الصلات (الانضمام) ، فأنت بحاجة إلى اختيار الترتيب.
وحتى في الحالات الأبسط ، من الضروري أحيانًا القيام بعمل المجدول وإعادة كتابة الاستفسارات قليلاً.
هنا مثال. على الجانب الأيسر يوجد استعلام يعرض أعلى 5 دول. ويستغرق 2,5 ثانية ، في رأيي. وعلى الجانب الأيمن ، نفس الاستعلام ، ولكن تمت إعادة كتابته قليلاً. بدلاً من التجميع حسب السلسلة ، بدأنا في التجميع حسب المفتاح (int). وهو أسرع. ثم قمنا بتوصيل قاموس بالنتيجة. بدلاً من 2,5 ثانية ، يستغرق الطلب 1,5 ثانية. هذا جيد.
مثال مشابه مع إعادة كتابة المرشحات. هنا طلب لروسيا. يعمل لمدة 5 ثوان. إذا أعدنا كتابته بطريقة تجعلنا نقارن مرة أخرى ليس سلسلة ، ولكن الأرقام مع مجموعة من تلك المفاتيح التي تتعلق بروسيا ، فسيكون ذلك أسرع بكثير.
هناك العديد من هذه الحيل. وتسمح لك بتسريع الاستعلامات التي تعتقد أنها تعمل بسرعة بالفعل ، أو على العكس من ذلك ، تعمل ببطء. يمكن صنعها بشكل أسرع.
- أقصى قدر من العمل في الوضع الموزع.
- الفرز حسب الأنواع الدنيا ، كما فعلت بواسطة ints.
- إذا كان هناك أي صلات (انضمام) أو قواميس ، فمن الأفضل القيام بها كملاذ أخير ، عندما يكون لديك بالفعل بيانات مجمعة جزئيًا على الأقل ، فسيتم استدعاء عملية الانضمام أو استدعاء القاموس مرات أقل وستكون أسرع .
- استبدال المرشحات.
هناك تقنيات أخرى ، وليست تلك التي أظهرتها فقط. ويمكنهم جميعًا في بعض الأحيان تسريع تنفيذ الاستعلامات بشكل كبير.
دعنا ننتقل إلى المثال التالي. الشركة X من الولايات المتحدة الأمريكية. ماذا تفعل هي؟
كانت هناك مهمة:
- ربط المعاملات الإعلانية دون اتصال بالإنترنت.
- نمذجة نماذج الربط المختلفة.
ما هو السيناريو؟
زائر عادي يزور الموقع ، على سبيل المثال ، 20 مرة شهريًا من إعلانات مختلفة ، أو تمامًا مثل هذا يأتي أحيانًا بدون أي إعلانات ، لأنه يتذكر هذا الموقع. ينظر إلى بعض المنتجات ، ويضعها في السلة ، ويخرجها من السلة. وفي النهاية ، هناك شيء ما يشتري.
أسئلة معقولة: "من الذي يجب أن يدفع مقابل الإعلان ، إذا لزم الأمر؟" و "ما الدعاية التي أثرت فيه إن وجدت؟". هذا هو ، لماذا اشترى وكيف جعل الناس مثل هذا الشخص يشترون أيضًا؟
من أجل حل هذه المشكلة ، تحتاج إلى ربط الأحداث التي تحدث على موقع الويب بالطريقة الصحيحة ، أي بطريقة أو بأخرى بناء اتصال بينها. ثم يتم إرسالها للتحليل إلى DWH. واستنادًا إلى هذا التحليل ، قم ببناء نماذج لمن وما الإعلانات التي سيتم عرضها.
معاملة الإعلان هي مجموعة من أحداث المستخدم ذات الصلة التي تبدأ من عرض إعلان ، ثم يحدث شيء ما ، ثم ربما عملية شراء ، ومن ثم قد تكون هناك عمليات شراء ضمن عملية شراء. على سبيل المثال ، إذا كان هذا تطبيقًا للهاتف المحمول أو لعبة محمولة ، فعادةً ما يتم تثبيت التطبيق مجانًا ، وإذا تم إجراء شيء هناك ، فقد تكون الأموال مطلوبة لهذا الغرض. وكلما زاد الإنفاق على التطبيق ، زادت قيمته. لكن لهذا تحتاج إلى توصيل كل شيء.
هناك العديد من النماذج الملزمة.
الأكثر شيوعًا هي:
- التفاعل الأخير ، حيث يكون التفاعل إما نقرة أو مرة ظهور.
- التفاعل الأول ، أي أول ما جلب شخصًا إلى الموقع.
- تركيبة خطية - كلها متساوية.
- توهين.
- وما إلى ذلك وهلم جرا.
وكيف تم كل هذا في المقام الأول؟ كان هناك وقت التشغيل وكاساندرا. تم استخدام Cassandra كمخزن للمعاملات ، أي تم تخزين جميع المعاملات ذات الصلة فيه. وعندما يأتي حدث ما في وقت التشغيل ، على سبيل المثال ، عرض صفحة ما أو شيء آخر ، تم تقديم طلب إلى كاساندرا - هل يوجد مثل هذا الشخص أم لا. ثم تم الحصول على المعاملات المتعلقة بها. وتم الاتصال.
وإذا كان من حسن الحظ أن الطلب يحتوي على معرّف معاملة ، فسيكون ذلك سهلاً. لكن في العادة لا يحالفنا الحظ. لذلك ، كان من الضروري العثور على آخر معاملة أو معاملة بنقرة أخيرة ، وما إلى ذلك.
وكان كل شيء يعمل بشكل جيد للغاية طالما كان الربط حتى النقرة الأخيرة. لأنه يوجد ، على سبيل المثال ، 10 ملايين نقرة في اليوم ، 300 مليون نقرة شهريًا ، إذا حددنا نافذة لمدة شهر. وبما أنه في Cassandra يجب أن يكون كل شيء في الذاكرة من أجل العمل بسرعة ، لأن وقت التشغيل يحتاج إلى الاستجابة بسرعة ، فقد استغرق الأمر حوالي 10-15 خادمًا.
وعندما أرادوا ربط معاملة ما بالشاشة ، اتضح على الفور أنها ليست ممتعة للغاية. و لماذا؟ يمكن ملاحظة أنه يجب تخزين 30 مرة أكثر من الأحداث. وبناءً عليه ، فأنت بحاجة إلى خوادم أكثر بـ 30 مرة. واتضح أن هذا نوع من الشكل الفلكي. للاحتفاظ بما يصل إلى 500 خادم من أجل إجراء الربط ، على الرغم من حقيقة أن هناك عددًا أقل بكثير من الخوادم في وقت التشغيل ، فهذا يعد نوعًا من الأرقام الخاطئة. وبدأوا يفكرون فيما يجب عليهم فعله.
وذهبنا إلى ClickHouse. وكيف يتم القيام بذلك على ClickHouse؟ للوهلة الأولى ، يبدو أن هذه مجموعة من الأنماط المضادة.
- تنمو المعاملة ، ونقوم بربط المزيد والمزيد من الأحداث بها ، أي أنها قابلة للتغيير ، ولا يعمل ClickHouse جيدًا مع الكائنات القابلة للتغيير.
- عندما يأتي زائر إلينا ، نحتاج إلى سحب معاملاته عن طريق المفتاح ، من خلال معرف زيارته. هذا أيضًا استعلام نقطي ، فهم لا يفعلون ذلك في ClickHouse. عادةً ما يكون لدى ClickHouse عمليات مسح… كبيرة ، ولكن هنا نحتاج إلى الحصول على بعض السجلات. أيضا مضاد.
- بالإضافة إلى ذلك ، كانت المعاملة بصيغة json ، لكنهم لم يرغبوا في إعادة كتابتها ، لذلك أرادوا تخزين json بطريقة غير منظمة ، وإذا لزم الأمر ، سحب شيئًا منها. وهذا أيضًا مضاد.
هذا هو ، مجموعة من antipatterns.
ولكن مع ذلك اتضح أن هذا النظام يعمل بشكل جيد للغاية.
ما تم إنجازه؟ ظهر ClickHouse ، حيث تم إلقاء السجلات ، مقسمة إلى سجلات. ظهرت خدمة منسوبة تلقت السجلات من ClickHouse. بعد ذلك ، بالنسبة لكل إدخال ، من خلال معرف الزيارة ، تلقيت معاملات ربما لم تتم معالجتها بعد بالإضافة إلى لقطات ، أي المعاملات المتصلة بالفعل ، أي نتيجة العمل السابق. لقد صنعت بالفعل منطقًا منهم ، واخترت المعاملة الصحيحة ، وربطت الأحداث الجديدة. تم تسجيله مرة أخرى. عاد السجل إلى ClickHouse ، أي أنه نظام دوري باستمرار. وإلى جانب ذلك ، ذهبت إلى DWH لتحليلها هناك.
كان في هذا الشكل أنه لم يعمل بشكل جيد. ولتسهيل الأمر على ClickHouse ، عندما كان هناك طلب من خلال معرف الزيارة ، قاموا بتجميع هذه الطلبات في مجموعات من 1،000 إلى 2،000 معرّف زيارة وسحبوا جميع المعاملات لـ 1،000-2،000 شخص. وبعد ذلك نجح كل شيء.
إذا نظرت داخل ClickHouse ، فهناك 3 طاولات رئيسية فقط تخدم كل هذا.
الجدول الأول الذي يتم فيه تحميل السجلات ، ويتم تحميل السجلات تقريبًا بدون معالجة.
الجدول الثاني. من خلال وجهة النظر الفعلية ، من هذه السجلات ، تم قضم الأحداث التي لم تُنسب بعد ، أي الأحداث غير ذات الصلة. ومن خلال العرض الفعلي ، تم سحب المعاملات من هذه السجلات لإنشاء لقطة سريعة. أي أن عرضًا ملموسًا خاصًا بنى لقطة ، أي آخر حالة تراكمية للمعاملة.
هذا هو النص المكتوب بلغة SQL. أود التعليق على بعض الأشياء المهمة فيه.
أول شيء مهم هو القدرة على سحب الأعمدة والحقول من json في ClickHouse. أي أن ClickHouse لديها بعض الطرق للعمل مع json. هم بدائيون جدا جدا.
تسمح لك visitParamExtractInt باستخراج السمات من json ، أي أعمال النتيجة الأولى. وبهذه الطريقة يمكنك سحب معرف المعاملة أو زيارة معرف. هذا الوقت.
ثانيًا ، يتم استخدام حقل ملموس صعب هنا. ماذا يعني ذلك؟ هذا يعني أنه لا يمكنك إدراجه في الجدول ، أي أنه غير مدرج ، يتم حسابه وتخزينه عند الإدراج. عند اللصق ، يقوم ClickHouse بالعمل نيابة عنك. وما تحتاجه لاحقًا تم سحبه بالفعل من json.
في هذه الحالة ، يكون العرض الفعلي للصفوف الأولية. والجدول الأول الذي يحتوي على سجلات خام تقريبًا تم استخدامه للتو. وماذا يفعل؟ أولاً ، يغير الفرز ، أي أن الفرز الآن يتم حسب معرف الزيارة ، لأننا نحتاج إلى سحب معاملته بسرعة لشخص معين.
الشيء الثاني المهم هو index_granularity. إذا رأيت MergeTree ، فعادة ما يكون 8 بشكل افتراضي index_granularity. ما هذا؟ هذه هي معلمة الفهرس النثرية. في ClickHouse ، يكون الفهرس متناثرًا ، ولا يقوم أبدًا بفهرسة كل إدخال. يقوم بذلك كل 192. وهذا أمر جيد عندما يلزم حساب الكثير من البيانات ، ولكنه سيء عندما يكون قليلاً ، لأن هناك عبء كبير. وإذا قللنا من دقة الفهرس ، فسنقلل من الحمل. لا يمكن اختزالها إلى واحدة ، لأنه قد لا تكون هناك ذاكرة كافية. يتم تخزين الفهرس دائمًا في الذاكرة.
يستخدم Snapshot أيضًا بعض ميزات ClickHouse الأخرى المثيرة للاهتمام.
أولاً ، إنها AggregatingMergeTree. و AggregatingMergeTree مخازن argMax ، أي هذه هي حالة المعاملة المقابلة لآخر طابع زمني. يتم إنشاء المعاملات في كل وقت لزائر معين. وفي الحالة الأخيرة لهذه المعاملة ، أضفنا حدثًا ولدينا حالة جديدة. لقد ضربت ClickHouse مرة أخرى. ومن خلال argMax في هذه الرؤية المجسدة ، يمكننا دائمًا الحصول على الحالة الحالية.
- يتم "فصل" الربط عن وقت التشغيل.
- يتم تخزين ومعالجة ما يصل إلى 3 مليارات معاملة شهريًا. هذا ترتيب من حيث الحجم أكبر مما كان عليه في كاساندرا ، أي في نظام معاملات نموذجي.
- مجموعة خوادم ClickHouse 2 × 5. 5 خوادم ولكل خادم نسخة طبق الأصل. هذا أقل مما كان عليه في Cassandra من أجل إحالة تستند إلى النقرات ، وهنا لدينا أساس انطباع. أي ، بدلاً من زيادة عدد الخوادم بمقدار 30 مرة ، تمكنوا من تقليلها.
والمثال الأخير هو الشركة المالية Y ، التي حللت ارتباط التغيرات في أسعار الأسهم.
وكانت المهمة:
- هناك ما يقرب من 5 سهم.
- يُعرف اقتباسات كل 100 مللي ثانية.
- تم تجميع البيانات على مدى 10 سنوات. على ما يبدو ، بالنسبة لبعض الشركات أكثر ، لبعض الشركات أقل.
- يوجد ما يقرب من 100 مليار صف في المجموع.
وكان من الضروري حساب ارتباط التغييرات.
هنا اثنين من الأسهم وأسعارها. إذا صعد أحدهما وصعد الآخر ، فهذا ارتباط إيجابي ، أي أن أحدهما يرتفع والآخر يرتفع. إذا صعد أحدهما لأعلى ، كما في نهاية الرسم البياني ، والآخر انخفض ، فهذا ارتباط سلبي ، أي عندما يرتفع أحدهما ، ينخفض الآخر.
بتحليل هذه التغييرات المتبادلة ، يمكن للمرء أن يضع تنبؤات في السوق المالية.
لكن المهمة صعبة. ما الذي يتم عمله من أجل هذا؟ لدينا 100 مليار سجل لها: الوقت ، والمخزون ، والسعر. نحتاج إلى حساب أول 100 مليار ضعف الفرق الجاري من خوارزمية السعر. RunningDifference هي وظيفة في ClickHouse تحسب بشكل تسلسلي الفرق بين سلسلتين.
وبعد ذلك تحتاج إلى حساب الارتباط ، ويجب حساب الارتباط لكل زوج. بالنسبة لـ 5 سهم ، تكون الأزواج 000 مليون. وهذا كثير ، بمعنى أنه من الضروري حساب دالة الارتباط هذه 12,5 مرة.
وإذا نسي شخص ما ، فإن ͞x و y هو كش ملك. توقع أخذ العينات. وهذا يعني أنه من الضروري ليس فقط حساب الجذور والمجاميع ، ولكن أيضًا حساب واحد آخر داخل هذه المبالغ. يجب إجراء مجموعة من العمليات الحسابية 12,5 مليون مرة ، وحتى مجمعة حسب الساعات. لدينا أيضًا الكثير من الساعات. وعليك القيام بذلك في 60 ثانية. إنها مزحة - إنها فكاهة.
كان من الضروري أن يكون لديك وقت على الأقل بطريقة ما ، لأن كل هذا كان يعمل ببطء شديد جدًا قبل أن يأتي ClickHouse.
لقد حاولوا حسابه على Hadoop ، على Spark ، على Greenplum. وكل هذا كان بطيئًا جدًا أو مكلفًا. أي أنه كان من الممكن إجراء حساب بطريقة أو بأخرى ، ولكن بعد ذلك كان مكلفًا.
ثم جاء ClickHouse وتحسنت الأمور كثيرًا.
أذكرك بأن لدينا مشكلة في منطقة البيانات ، لأنه لا يمكن توطين الارتباطات. لا يمكننا وضع بعض البيانات على خادم واحد ، وبعضها على خادم آخر والحساب ، يجب أن يكون لدينا جميع البيانات في كل مكان.
ماذا فعلوا؟ في البداية ، يتم ترجمة البيانات. يقوم كل خادم بتخزين البيانات حول تسعير مجموعة معينة من المشاركات. ولا تتداخل. لذلك ، من الممكن حساب السجل والعودة بشكل متوازي ومستقل ، كل هذا يحدث حتى الآن بشكل متوازي وموزع.
ثم قررنا تقليل هذه البيانات ، مع عدم فقد التعبير. قلل من استخدام المصفوفات ، أي لكل فترة زمنية ، قم بعمل مجموعة من الأسهم ومجموعة من الأسعار. لذلك ، فإنها تشغل مساحة بيانات أقل بكثير. وهم أسهل قليلاً في العمل معهم. هذه عمليات متوازية تقريبًا ، أي أننا نقرأ جزئيًا بالتوازي ثم نكتب إلى الخادم.
بعد ذلك ، يمكن تكراره. الحرف "r" يعني أننا قمنا بتكرار هذه البيانات. أي ، لدينا نفس البيانات على جميع الخوادم الثلاثة - هذه هي المصفوفات.
وبعد ذلك باستخدام برنامج نصي خاص من هذه المجموعة المكونة من 12,5 مليون ارتباط يجب حسابه ، يمكنك عمل حزم. أي 2 مهمة مع 500 زوج من الارتباطات. ويتم حساب هذه المهمة على خادم ClickHouse محدد. لديه كل البيانات ، لأن البيانات هي نفسها ويمكنه حسابها بالتسلسل.
مرة أخرى ، هذا ما يبدو عليه. أولاً ، لدينا جميع البيانات في هذا الهيكل: الوقت ، الأسهم ، السعر. ثم قمنا بحساب logReturn ، أي بيانات من نفس الهيكل ، ولكن بدلاً من السعر لدينا بالفعل logReturn. ثم أعيد بناؤها ، أي حصلنا على الوقت والمصفوفة الجماعية للأسهم والأسعار. مقطعة. وبعد ذلك ، أنشأنا مجموعة من المهام وقمنا بإدخالها إلى ClickHouse حتى يتم احتسابها. ويعمل.
في إثبات المفهوم ، كانت المهمة مهمة فرعية ، أي تم أخذ بيانات أقل. وثلاثة خوادم فقط.
المرحلتان الأوليان: احتساب Log_return والالتفاف في المصفوفات استغرق حوالي ساعة.
وحساب الارتباط حوالي 50 ساعة. لكن 50 ساعة ليست كافية ، لأنهم اعتادوا العمل لأسابيع. كان نجاحا كبيرا. وإذا عدت ، فسيتم حساب كل شيء في هذه المجموعة 70 مرة في الثانية.
لكن الشيء الأكثر أهمية هو أن هذا النظام عمليًا خالي من الاختناقات ، أي أنه يتوسع بشكل خطي تقريبًا. وقاموا بفحصها. تم توسيعه بنجاح.
- المخطط الصحيح هو نصف المعركة. والمخطط الصحيح هو استخدام جميع تقنيات ClickHouse الضرورية.
- جمع / تجميعأشجار MergeTrees هي تقنيات تسمح لك بتجميع لقطة حالة أو اعتبارها حالة خاصة. وهو يبسط الكثير من الأشياء بشكل كبير.
- تتيح لك المشاهدات المادية تجاوز حد الفهرس الواحد. ربما لم أقل ذلك بوضوح شديد ، ولكن عندما قمنا بتحميل السجلات ، كانت السجلات الأولية موجودة في الجدول بفهرس واحد ، وكانت سجلات السمات موجودة في الجدول ، أي البيانات نفسها ، تمت تصفيتها فقط ، لكن الفهرس كان آحرون. يبدو أنها نفس البيانات ، ولكن الفرز مختلف. وتتيح لك المشاهدات المادية ، إذا كنت بحاجة إليها ، تجاوز قيود ClickHouse هذه.
- تقليل دقة الفهرس للاستعلامات النقطية.
- وتوزيع البيانات بذكاء ، حاول توطين البيانات داخل الخادم قدر الإمكان. وحاول التأكد من أن الطلبات تستخدم الأقلمة أيضًا قدر الإمكان.
وتلخيصًا لهذا الخطاب القصير ، يمكننا القول إن ClickHouse قد احتلت الآن بقوة أراضي كل من قواعد البيانات التجارية وقواعد البيانات مفتوحة المصدر ، أي بالتحديد للتحليلات. إنه يتناسب تمامًا مع هذا المشهد. والأكثر من ذلك ، أنه يبدأ ببطء في مزاحمة الآخرين ، لأنه عندما يكون لديك ClickHouse ، فأنت لا تحتاج إلى InfiniDB. قد لا تكون هناك حاجة إلى Vertika قريبًا إذا قدموا دعمًا عاديًا لـ SQL. يتمتع!
-شكرا على التقرير! مثير جدا! هل كانت هناك مقارنات مع Apache Phoenix؟
لا ، لم أسمع أحدا يقارن. نحاول نحن و Yandex تتبع جميع مقارنات ClickHouse مع قواعد البيانات المختلفة. لأنه إذا تبين فجأة أن شيئًا ما أسرع من ClickHouse ، فلن تتمكن Lesha Milovidov من النوم ليلاً وتبدأ في تسريعها بسرعة. لم اسمع بمثل هذه المقارنة.
-
(أليكسي ميلوفيدوف) أباتشي فينيكس هو محرك SQL مدعوم من Hbase. Hbase هو أساسًا لسيناريو العمل ذي القيمة الرئيسية. هناك ، في كل سطر ، يمكن أن يكون هناك عدد عشوائي من الأعمدة بأسماء عشوائية. يمكن قول هذا عن أنظمة مثل Hbase و Cassandra. والاستعلامات التحليلية الثقيلة على وجه التحديد لن تعمل بشكل طبيعي بالنسبة لهم. أو قد تعتقد أنها تعمل بشكل جيد إذا لم تكن لديك أي خبرة مع ClickHouse.
-
شكرا
-
مساء الخير أنا مهتم بالفعل بهذا الموضوع ، لأن لدي نظام تحليلي فرعي. ولكن عندما ألقي نظرة على ClickHouse ، أشعر أن ClickHouse مناسب تمامًا لتحليل الأحداث ، وقابل للتغيير. وإذا كنت بحاجة إلى تحليل الكثير من بيانات العمل باستخدام مجموعة من الجداول الكبيرة ، فإن ClickHouse ، حسب فهمي ، ليست مناسبة جدًا بالنسبة لي؟ خاصة إذا تغيروا. فهل هذا صحيح أم أن هناك أمثلة تدحض ذلك؟
-
هذا صحيح. وهذا ينطبق على معظم قواعد البيانات التحليلية المتخصصة. تم تصميمها لحقيقة وجود واحد أو أكثر من الجداول الكبيرة القابلة للتغيير ، وللكثير من الجداول الصغيرة التي تتغير ببطء. أي أن ClickHouse ليس مثل Oracle ، حيث يمكنك وضع كل شيء وإنشاء بعض الاستعلامات المعقدة للغاية. من أجل استخدام ClickHouse بشكل فعال ، تحتاج إلى إنشاء مخطط بطريقة تعمل بشكل جيد في ClickHouse. وهذا يعني ، تجنب التطبيع المفرط ، واستخدام القواميس ، ومحاولة إنشاء عدد أقل من الروابط الطويلة. وإذا تم إنشاء المخطط بهذه الطريقة ، فيمكن حل مهام الأعمال المماثلة على ClickHouse بشكل أكثر كفاءة من قاعدة البيانات العلائقية التقليدية.
-
شكرا على التقرير! لدي سؤال حول آخر حالة مالية. كان لديهم تحليلات. كان من الضروري مقارنة كيفية صعودهم وهبوطهم. وأنا أفهم أنك أنشأت النظام خصيصًا لهذه التحليلات؟ إذا احتاجوا غدًا ، على سبيل المثال ، إلى تقرير آخر حول هذه البيانات ، فهل يحتاجون إلى إعادة إنشاء المخطط وتحميل البيانات؟ هذا هو ، للقيام بنوع من المعالجة المسبقة للحصول على الطلب؟
بالطبع ، هذا هو استخدام ClickHouse لمهمة محددة للغاية. يمكن حلها بشكل أكثر تقليدية داخل Hadoop. بالنسبة إلى Hadoop ، هذه مهمة مثالية. لكن في Hadoop يكون بطيئًا جدًا. وهدفي هو إثبات أن ClickHouse يمكنه حل المهام التي عادة ما يتم حلها بوسائل مختلفة تمامًا ، ولكن في نفس الوقت تفعل ذلك بشكل أكثر كفاءة. هذا مصمم لمهمة محددة. من الواضح أنه إذا كانت هناك مشكلة في شيء مشابه ، فيمكن حلها بطريقة مماثلة.
انها واضحة. قلت أنه تمت معالجة 50 ساعة. هل هي من البداية ، متى قمت بتحميل البيانات أو حصلت على النتائج؟
نعم نعم.
حسنا شكرا جزيلا.
هذا على كتلة خادم 3.
تحيات! شكرا على التقرير! كل شيء ممتع للغاية. لن أسأل قليلاً عن الوظيفة ، ولكن عن استخدام ClickHouse من حيث الاستقرار. هذا هو ، هل لديك أي شيء ، هل كان عليك استعادة؟ كيف يتصرف ClickHouse في هذه الحالة؟ وهل حدث أن لديك نسخة طبق الأصل أيضًا؟ على سبيل المثال ، واجهنا مشكلة مع ClickHouse عندما لا يزال خارج حدوده ويسقط.
بالطبع ، لا توجد أنظمة مثالية. ولدى ClickHouse أيضًا مشاكله الخاصة. لكن هل سمعت عن عدم عمل Yandex.Metrica لفترة طويلة؟ على الاغلب لا. لقد كان يعمل بشكل موثوق منذ 2012-2013 على ClickHouse. أستطيع أن أقول نفس الشيء عن تجربتي. لم يكن لدينا فشل كامل. يمكن أن تحدث بعض الأشياء الجزئية ، لكنها لم تكن ذات أهمية كافية للتأثير بشكل خطير على العمل. لم يحدث قط. ClickHouse موثوق تمامًا ولا يتعطل بشكل عشوائي. لا داعي للقلق بشأن ذلك. إنه ليس شيئًا خامًا. وقد تم إثبات ذلك من قبل العديد من الشركات.
مرحبًا! قلت أنك بحاجة إلى التفكير في مخطط البيانات على الفور. ماذا لو حدث؟ بياناتي تتدفق وتتدفق. مرت ستة أشهر ، وأنا أفهم أنه من المستحيل العيش على هذا النحو ، أحتاج إلى إعادة تحميل البيانات والقيام بشيء ما معهم.
هذا يعتمد بالطبع على نظامك. هناك عدة طرق للقيام بذلك دون توقف تقريبًا. على سبيل المثال ، يمكنك إنشاء "طريقة عرض محسوسة" لإنشاء بنية بيانات مختلفة إذا كان من الممكن تعيينها بشكل فريد. أي ، إذا كان يسمح بالتعيين باستخدام ClickHouse ، أي استخراج بعض الأشياء ، وتغيير المفتاح الأساسي ، وتغيير التقسيم ، ثم يمكنك إنشاء عرض محسوس. استبدل بياناتك القديمة هناك ، وستتم كتابة بيانات جديدة تلقائيًا. وبعد ذلك فقط قم بالتبديل إلى استخدام العرض المادي ، ثم قم بتبديل السجل واقتل الجدول القديم. هذه بشكل عام طريقة بدون توقف.
شكرا لك.
المصدر: www.habr.com