با وجود این واقعیت که اکنون تقریباً در همه جا داده های زیادی وجود دارد، پایگاه های داده های تحلیلی هنوز کاملاً عجیب و غریب هستند. آنها کمتر شناخته شده هستند و حتی بدتر می توانند از آنها به طور موثر استفاده کنند. بسیاری به خوردن کاکتوس با MySQL یا PostgreSQL که برای سناریوهای دیگر طراحی شده‌اند، از NoSQL رنج می‌برند یا برای راه‌حل‌های تجاری بیش از حد پرداخت می‌کنند، ادامه می‌دهند. کلیک هاوس قوانین بازی را تغییر می دهد و آستانه ورود به دنیای DBMS های تحلیلی را به میزان قابل توجهی کاهش می دهد.
گزارش از BackEnd Conf 2018 و با اجازه گوینده منتشر شده است.
من کی هستم و چرا درباره ClickHouse صحبت می کنم؟ من یک مدیر توسعه در LifeStreet هستم که از ClickHouse استفاده می کند. همچنین، من بنیانگذار Altinity هستم. این یک شریک Yandex است که ClickHouse را تبلیغ می کند و به Yandex کمک می کند تا ClickHouse را موفق تر کند. همچنین آماده به اشتراک گذاشتن دانش در مورد ClickHouse.
و من برادر پتیا زایتسف نیستم. اغلب در این مورد از من سوال می شود. نه ما برادر نیستیم
"همه می دانند" که ClickHouse:
- خیلی سریع،
- بسیار راحت
- در Yandex استفاده می شود.
کمی کمتر شناخته شده است که در کدام شرکت ها و چگونه استفاده می شود.
من به شما خواهم گفت که چرا، کجا و چگونه از 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 ویژگی وجود دارد. و بعد خوب یا بد بودن بازی را تجزیه و تحلیل می کنند.
- تجزیه و تحلیل بلاک چین یک شرکت روسی به عنوان Bloxy.info وجود دارد. این تحلیل شبکه اتریوم است. آنها همچنین این کار را در ClickHouse انجام دادند.
و اندازه آن مهم نیست. شرکت های زیادی وجود دارند که از یک سرور کوچک استفاده می کنند. و به آنها اجازه می دهد تا مشکلاتشان را حل کنند. و حتی شرکت های بیشتری از خوشه های بزرگی از بسیاری از سرورها یا ده ها سرور استفاده می کنند.
و اگر به سوابق نگاه کنید، پس:
- Yandex: بیش از 500 سرور، آنها روزانه 25 میلیارد رکورد را در آنجا ذخیره می کنند.
- LifeStreet: 60 سرور، تقریباً 75 میلیارد رکورد در روز. سرورهای کمتر، رکوردهای بیشتری نسبت به Yandex وجود دارد.
- CloudFlare: 36 سرور، آنها 200 میلیارد رکورد در روز ذخیره می کنند. آنها حتی سرورهای کمتری دارند و داده های بیشتری را ذخیره می کنند.
- بلومبرگ: 102 سرور، حدود یک تریلیون ورودی در روز. دارنده رکورد.
از نظر جغرافیایی نیز این مقدار زیاد است. این نقشه در اینجا یک نقشه حرارتی از محل استفاده از ClickHouse در جهان را نشان می دهد. روسیه، چین، آمریکا به وضوح در اینجا برجسته هستند. کشورهای اروپایی کم هستند. و 4 خوشه وجود دارد.
این یک تحلیل مقایسه ای است، نیازی به جستجوی ارقام مطلق نیست. این تجزیه و تحلیل بازدیدکنندگانی است که مطالب انگلیسی زبان را در وب سایت Altinity می خوانند، زیرا هیچ روسی زبانی در آنجا وجود ندارد. و روسیه، اوکراین، بلاروس، یعنی بخش روسی زبان جامعه، اینها بیشترین کاربران هستند. سپس ایالات متحده و کانادا می آیند. چین خیلی عقب افتاده است. شش ماه پیش تقریباً چینی وجود نداشت، اکنون چین از اروپا پیشی گرفته و به رشد خود ادامه می دهد. اروپای قدیم نیز فاصله چندانی با آن ندارد و پیشرو در استفاده از ClickHouse به طرز عجیبی فرانسه است.
چرا این همه را می گویم؟ برای نشان دادن اینکه ClickHouse در حال تبدیل شدن به یک راه حل استاندارد برای تجزیه و تحلیل داده های بزرگ است و در حال حاضر در بسیاری از مکان ها استفاده می شود. اگر از آن استفاده کنید، در روند درستی هستید. اگر هنوز از آن استفاده نمی کنید، نمی توانید بترسید که تنها بمانید و هیچ کس به شما کمک نکند، زیرا بسیاری در حال حاضر این کار را انجام می دهند.
اینها نمونه هایی از استفاده واقعی از ClickHouse در چندین شرکت است.
- اولین مثال یک شبکه تبلیغاتی است: مهاجرت از Vertica به ClickHouse. و من چند شرکت را می شناسم که از Vertica جابجا شده اند یا در حال انتقال هستند.
- مثال دوم ذخیره سازی تراکنشی در ClickHouse است. این نمونه ای است که بر اساس آنتی الگوها ساخته شده است. هر کاری که نباید در ClickHouse به توصیه توسعه دهندگان انجام شود، در اینجا انجام می شود. و آنقدر موثر انجام شده که کار می کند. و بسیار بهتر از راه حل معاملاتی معمولی کار می کند.
- مثال سوم، محاسبات توزیع شده در ClickHouse است. یک سوال در مورد چگونگی ادغام ClickHouse در اکوسیستم Hadoop وجود داشت. من مثالی را نشان خواهم داد که چگونه یک شرکت کاری مشابه یک کانتینر کاهش نقشه در ClickHouse، پیگیری محلی‌سازی داده‌ها و غیره را برای محاسبه یک کار بسیار غیر ضروری انجام داد.
- LifeStreet یک شرکت Ad Tech است که تمام فناوری های موجود در شبکه تبلیغاتی را در اختیار دارد.
- او در بهینه سازی تبلیغات، مناقصه برنامه ای مشغول است.
- داده های زیاد: حدود 10 میلیارد رویداد در روز. در عین حال، رویدادها را می توان به چندین رویداد فرعی تقسیم کرد.
- مشتریان زیادی از این داده ها وجود دارد، و اینها نه تنها افراد، بلکه بیشتر هستند - اینها الگوریتم های مختلفی هستند که در مناقصه برنامه ای درگیر هستند.
این شرکت مسیری طولانی و پرخار را طی کرده است. و من در HighLoad در مورد آن صحبت کردم. ابتدا LifeStreet از MySQL (با یک توقف کوتاه در Oracle) به Vertica منتقل شد. و شما می توانید یک داستان در مورد آن پیدا کنید.
و همه چیز بسیار خوب بود، اما به سرعت مشخص شد که داده ها در حال رشد هستند و Vertica گران است. از این رو، به دنبال جایگزین های مختلف بود. برخی از آنها در اینجا ذکر شده است. و در واقع، تقریباً همه پایگاه‌های داده‌ای که از سال سیزدهم تا شانزدهم در بازار موجود بودند و از نظر عملکرد تقریباً مناسب بودند، اثبات مفهوم یا گاهی آزمایش عملکرد انجام دادیم. و همچنین در مورد برخی از آنها در HighLoad صحبت کردم.
وظیفه در وهله اول مهاجرت از Vertica بود، زیرا داده ها رشد کردند. و در طول سالها به طور تصاعدی رشد کردند. سپس آنها به قفسه رفتند، اما با این وجود. و با پیش‌بینی این رشد، نیازمندی‌های کسب‌وکار برای مقدار داده‌هایی که باید بر اساس آن نوعی تجزیه و تحلیل انجام شود، مشخص بود که پتابایت‌ها به زودی مورد بحث قرار خواهند گرفت. و پرداخت برای پتابایت در حال حاضر بسیار گران است، بنابراین ما به دنبال جایگزینی بودیم که کجا برویم.
کجا برویم؟ و برای مدت طولانی اصلاً مشخص نبود کجا باید رفت ، زیرا از یک طرف پایگاه های داده تجاری وجود دارد ، به نظر می رسد که به خوبی کار می کنند. برخی تقریباً به خوبی Vertica کار می کنند، برخی بدتر. اما همه آنها گران هستند، هیچ چیز ارزان تر و بهتری پیدا نمی شود.
از سوی دیگر، راه حل های متن باز وجود دارد که تعداد آنها زیاد نیست، یعنی برای تجزیه و تحلیل، می توان آنها را روی انگشتان حساب کرد. و آنها رایگان یا ارزان هستند، اما کند هستند. و اغلب فاقد عملکرد لازم و مفید هستند.
و هیچ چیز برای ترکیب خوبی که در پایگاه های داده تجاری و همه رایگان هایی که در منبع باز هستند وجود نداشت.
هیچ چیز وجود نداشت تا اینکه به طور غیرمنتظره ای، Yandex ClickHouse را مانند یک شعبده باز از کلاه، مانند یک خرگوش بیرون کشید. و این یک تصمیم غیرمنتظره بود، آنها هنوز این سوال را می پرسند: "چرا؟"، اما با این وجود.
و بلافاصله در تابستان 2016، شروع کردیم به بررسی اینکه ClickHouse چیست. و معلوم شد که گاهی اوقات می تواند سریعتر از Vertica باشد. ما سناریوهای مختلف را بر روی درخواست های مختلف آزمایش کردیم. و اگر پرس و جو فقط از یک جدول استفاده می کرد، یعنی بدون هیچ گونه اتصال (join)، آنگاه ClickHouse دو برابر سریعتر از Vertica بود.
من خیلی تنبل نبودم و روز گذشته به تست های Yandex نگاه کردم. اینجا هم همینطور است: ClickHouse دو برابر سریعتر از Vertica است، بنابراین اغلب در مورد آن صحبت می کنند.
اما اگر در پرس و جوها پیوندهایی وجود داشته باشد، همه چیز به طور واضح مشخص نمی شود. و ClickHouse می تواند دو برابر کندتر از Vertica باشد. و اگر کمی درخواست را اصلاح کنید و آن را بازنویسی کنید، تقریباً برابر هستند. بد نیست. و رایگان.
و پس از دریافت نتایج آزمایش، و نگاه کردن به آن از زوایای مختلف، LifeStreet به ClickHouse رفت.
یادآوری میکنم امسال شانزدهمین سال است. مثل یک شوخی در مورد موش هایی بود که گریه می کردند و خود را نیش می زدند، اما به خوردن کاکتوس ادامه می دادند. و این با جزئیات توضیح داده شد، یک ویدیو در این مورد وجود دارد و غیره.
بنابراین، من در مورد آن به طور مفصل صحبت نمی کنم، فقط در مورد نتایج و چند چیز جالب که در آن زمان در مورد آنها صحبت نکردم صحبت خواهم کرد.
نتایج عبارتند از:
- مهاجرت موفقیت آمیز و بیش از یک سال سیستم در حال حاضر در حال تولید است.
- بهره وری و انعطاف پذیری افزایش یافته است. از 10 میلیارد رکوردی که می‌توانستیم در روز و سپس برای مدت کوتاهی هزینه کنیم، LifeStreet اکنون 75 میلیارد رکورد را در روز ذخیره می‌کند و می‌تواند این کار را برای 3 ماه یا بیشتر انجام دهد. اگر در اوج بشمارید، این عدد تا یک میلیون رویداد در ثانیه است. بیش از یک میلیون پرس و جو SQL در روز در این سیستم وارد می شود که بیشتر از ربات های مختلف است.
- علیرغم این واقعیت که سرورهای بیشتری برای ClickHouse نسبت به Vertica استفاده شد، آنها در سخت افزار نیز صرفه جویی کردند، زیرا دیسک های SAS نسبتاً گران قیمت در Vertica استفاده می شد. کلیک هاوس از SATA استفاده کرد. و چرا؟ زیرا در Vertica insert همزمان است. و همگام سازی مستلزم این است که دیسک ها خیلی کند نشوند و همچنین سرعت شبکه خیلی کم نشود، یعنی یک عملیات نسبتاً گران قیمت. و در ClickHouse درج ناهمزمان است. علاوه بر این، همیشه می توانید همه چیز را به صورت محلی بنویسید، هیچ هزینه اضافی برای این کار وجود ندارد، بنابراین داده ها را می توان بسیار سریعتر از Vertika در ClickHouse وارد کرد، حتی در درایوهای کندتر. و خواندن هم تقریباً همین است. خواندن در SATA، اگر آنها در RAID هستند، پس این همه به اندازه کافی سریع است.
- محدود به مجوز نیست، یعنی 3 پتابایت داده در 60 سرور (20 سرور یک کپی است) و 6 تریلیون رکورد در حقایق و تجمیع. چنین چیزی در Vertica قابل خرید نیست.
اکنون در این مثال به موارد عملی می پردازم.
- اولی یک طرح کارآمد است. خیلی به طرح واره بستگی دارد.
- دومی تولید SQL کارآمد است.
یک پرس و جو معمولی OLAP یک انتخاب است. برخی از ستون ها به گروه بندی بر اساس، برخی از ستون ها به توابع جمع می روند. جایی وجود دارد که می توان آن را به عنوان یک تکه مکعب نشان داد. کل گروه توسط را می توان به عنوان یک فرافکنی در نظر گرفت. و به همین دلیل است که به آن تحلیل داده های چند متغیره می گویند.
و اغلب این به شکل یک طرح ستاره مدل می شود، زمانی که یک واقعیت مرکزی و ویژگی های این واقعیت در امتداد طرفین، در امتداد پرتوها وجود دارد.
و از نظر طراحی فیزیکی، نحوه قرار گرفتن آن روی میز، معمولاً یک نمایش عادی انجام می دهند. می‌توانید غیرعادی کنید، اما روی دیسک گران است و در پرس‌و‌جوها خیلی کارآمد نیست. بنابراین، آنها معمولا یک نمایش نرمال شده، یعنی یک جدول واقعیت و بسیاری از جداول ابعادی ایجاد می کنند.
اما در ClickHouse به خوبی کار نمی کند. دو دلیل وجود دارد:
- اولی به این دلیل است که ClickHouse جوین های خیلی خوبی ندارد، یعنی اتصالات وجود دارد، اما بد هستند. در حالی که بد است.
- دوم اینکه جداول به روز نمی شوند. معمولاً در این صفحات که در اطراف مدار ستاره قرار دارند، باید چیزی را تغییر داد. به عنوان مثال، نام مشتری، نام شرکت و غیره. و این کار نمی کند.
و در ClickHouse راهی برای خروج از این امر وجود دارد. حتی دو تا:
- اولین مورد استفاده از فرهنگ لغت است. دیکشنری های خارجی چیزی است که به 99٪ کمک می کند تا مشکل با طرح ستاره، با به روز رسانی و غیره حل شود.
- مورد دوم استفاده از آرایه است. آرایه ها همچنین به خلاص شدن از شر اتصالات و مشکلات نرمال سازی کمک می کنند.
- نیازی به پیوستن نیست
- قابل ارتقا. از مارس 2018، یک فرصت غیرمستند ظاهر شده است (شما این را در اسناد پیدا نمی کنید) تا لغت نامه ها را تا حدی به روز کنید، یعنی ورودی هایی که تغییر کرده اند. عملاً مانند یک میز است.
- همیشه در حافظه است، بنابراین پیوستن با یک فرهنگ لغت سریعتر از جدولی است که روی دیسک است و هنوز یک واقعیت در حافظه پنهان نیست، به احتمال زیاد نه، کار می کند.
- شما هم نیازی به پیوستن ندارید.
- این یک نمایش جمع و جور 1 به چند است.
- و به نظر من آرایه ها برای گیک ها ساخته شده اند. اینها توابع لامبدا و غیره هستند.
این برای کلمات قرمز نیست. این یک عملکرد بسیار قدرتمند است که به شما امکان می دهد بسیاری از کارها را به روشی بسیار ساده و زیبا انجام دهید.
مثال‌های معمولی که به حل آرایه‌ها کمک می‌کنند. این مثال ها به اندازه کافی ساده و واضح هستند:
- جستجو بر اساس برچسب ها اگر در آنجا هشتگ دارید و می خواهید چند پست را با هشتگ پیدا کنید.
- جستجو بر اساس جفت کلید-مقدار. برخی از صفات با مقدار نیز وجود دارد.
- فهرستی از کلیدها را ذخیره کنید که باید آنها را به چیز دیگری ترجمه کنید.
همه این وظایف را می توان بدون آرایه حل کرد. برچسب ها را می توان در یک خط قرار داد و با یک عبارت منظم یا در یک جدول جداگانه انتخاب کرد، اما پس از آن باید Join ها را انجام دهید.
و در ClickHouse، شما نیازی به انجام کاری ندارید، کافی است آرایه رشته ای را برای هشتگ ها توصیف کنید یا یک ساختار تودرتو برای سیستم های ارزش کلیدی ایجاد کنید.
ساختار تودرتو ممکن است بهترین نام نباشد. اینها دو آرایه هستند که یک قسمت مشترک در نام و برخی ویژگی های مرتبط دارند.
و جستجو بر اساس برچسب بسیار آسان است. عملکرد داشته باشد has، که بررسی می کند که آرایه حاوی یک عنصر باشد. همه، همه ورودی‌های مربوط به کنفرانس ما را پیدا کردند.
جستجو بر اساس subid کمی پیچیده تر است. ابتدا باید نمایه کلید را پیدا کنیم و سپس عنصری را با این شاخص بگیریم و بررسی کنیم که این مقدار همان چیزی است که ما نیاز داریم. با این حال، بسیار ساده و جمع و جور است.
عبارت منظمی که دوست دارید بنویسید اگر همه را در یک خط نگه دارید، اولاً ناشیانه خواهد بود. و دوم اینکه خیلی بیشتر از دو آرایه کار می کرد.
مثالی دیگر. شما یک آرایه دارید که شناسه را در آن ذخیره می کنید. و می توانید آنها را به نام ترجمه کنید. تابع arrayMap. این یک تابع لامبدا معمولی است. شما عبارات لامبدا را در آنجا ارسال می کنید. و او مقدار نام را برای هر شناسه از فرهنگ لغت بیرون می آورد.
جستجو را می توان به همین روش انجام داد. یک تابع محمول ارسال می شود که بررسی می کند عناصر مطابقت دارند.
این موارد مدار را تا حد زیادی ساده می کند و دسته ای از مشکلات را حل می کند.
اما مشکل بعدی که ما با آن روبرو هستیم و می خواهم به آن اشاره کنم، پرس و جوهای کارآمد است.
- ClickHouse برنامه ريزي پرس و جو ندارد. قطعا نه.
- با این وجود، پرس و جوهای پیچیده هنوز باید برنامه ریزی شوند. در چه مواردی؟
- اگر چندین اتصال در پرس و جو وجود داشته باشد، آنها را در قسمت های فرعی قرار می دهید. و ترتیب اجرای آنها مهم است.
- و دوم - اگر درخواست توزیع شود. زیرا در یک پرس و جو توزیع شده، تنها درونی ترین زیرمجموعه به صورت توزیع شده اجرا می شود و بقیه موارد به سروری که به آن متصل شده اید و در آنجا اجرا شده اید ارسال می شود. بنابراین، اگر پرس و جوهایی را با تعداد زیادی جوین (join) توزیع کرده اید، باید سفارش را انتخاب کنید.
و حتی در موارد ساده تر، گاهی اوقات نیز لازم است که کار برنامه نویس را انجام دهید و پرس و جوها را کمی بازنویسی کنید.
به عنوان مثال. در سمت چپ یک پرس و جو وجود دارد که 5 کشور برتر را نشان می دهد. و به نظر من 2,5 ثانیه طول می کشد. و در سمت راست، همان پرس و جو، اما کمی بازنویسی شده است. به جای گروه بندی با رشته، شروع به گروه بندی بر اساس کلید (int) کردیم. و سریعتر است. و سپس یک دیکشنری را به نتیجه وصل کردیم. به جای 2,5 ثانیه، درخواست 1,5 ثانیه طول می کشد. این خوبه.
نمونه مشابه با فیلترهای بازنویسی. در اینجا یک درخواست برای روسیه است. 5 ثانیه اجرا می شود. اگر آن را به گونه ای بازنویسی کنیم که دوباره نه یک رشته، بلکه اعداد را با مجموعه ای از کلیدهای مربوط به روسیه مقایسه کنیم، آنگاه بسیار سریعتر خواهد بود.
از این دست ترفندها زیاد است. و آنها به شما اجازه می دهند تا به طور قابل توجهی پرس و جوهایی را که فکر می کنید در حال حاضر سریع اجرا می شوند، یا برعکس، به کندی اجرا می شوند، افزایش دهید. می توان آنها را حتی سریعتر ساخت.
- حداکثر کار در حالت توزیع شده.
- مرتب سازی بر اساس حداقل انواع، همانطور که من با ints انجام دادم.
- اگر پیوندها (پیوستن)، فرهنگ لغت وجود دارد، بهتر است آنها را به عنوان آخرین راه حل انجام دهید، زمانی که از قبل داده هایی را حداقل تا حدی گروه بندی کرده اید، در این صورت عملیات پیوستن یا تماس فرهنگ لغت کمتر فراخوانی می شود و سریعتر می شود. .
- تعویض فیلترها
تکنیک های دیگری نیز وجود دارد، و نه فقط آنهایی که من نشان داده ام. و همه آنها گاهی اوقات می توانند به طور قابل توجهی سرعت اجرای پرس و جوها را افزایش دهند.
بیایید به مثال بعدی برویم. شرکت X از ایالات متحده آمریکا. او چه کار می کند؟
وظیفه ای بود:
- پیوند آفلاین تراکنش های تبلیغاتی.
- مدل سازی مدل های مختلف صحافی
سناریو چیست؟
یک بازدیدکننده معمولی مثلاً 20 بار در ماه از تبلیغات مختلف به سایت می آید یا همینطور گاهی اوقات بدون تبلیغات می آید، زیرا این سایت را به خاطر می آورد. به برخی از محصولات نگاه می کند، آنها را در سبد می گذارد، آنها را از سبد خارج می کند. و در پایان، چیزی می‌خرد.
سوالات منطقی: "در صورت لزوم چه کسی باید هزینه تبلیغات را بپردازد؟" و "در صورت وجود چه تبلیغاتی بر او تأثیر گذاشته است؟". یعنی چرا خرید کرده و چگونه می توان امثال این شخص را هم خرید کرد؟
برای حل این مشکل باید اتفاقاتی که در وب سایت رخ می دهد را به روش صحیح به هم متصل کنید، یعنی به نوعی بین آنها ارتباط برقرار کنید. سپس برای تجزیه و تحلیل به DWH فرستاده می شوند. و بر اساس این تجزیه و تحلیل، مدل هایی بسازید که چه کسانی و چه تبلیغاتی باید نمایش داده شوند.
تراکنش تبلیغاتی مجموعه‌ای از رویدادهای کاربر مرتبط است که از نمایش یک آگهی شروع می‌شود، سپس اتفاقی می‌افتد، سپس ممکن است یک خرید، و سپس ممکن است خریدهایی در یک خرید وجود داشته باشد. به عنوان مثال، اگر این یک برنامه تلفن همراه یا یک بازی موبایل است، معمولاً نصب برنامه به صورت رایگان انجام می شود و اگر کاری در آنجا انجام شود، ممکن است برای این کار نیاز به پول باشد. و هر چه شخص بیشتر در برنامه خرج کند، ارزش آن بیشتر است. اما برای این شما باید همه چیز را به هم وصل کنید.
مدل های صحافی زیادی وجود دارد.
محبوب ترین ها عبارتند از:
- آخرین تعامل، که در آن تعامل یا یک کلیک یا یک برداشت است.
- اولین تعامل، یعنی اولین چیزی که یک شخص را به سایت آورد.
- ترکیب خطی - همه به یک اندازه.
- تضعیفی.
- و غیره.
و در وهله اول چگونه همه کار کردند؟ Runtime و Cassandra وجود داشت. Cassandra به عنوان ذخیره تراکنش استفاده می شد، یعنی تمام تراکنش های مرتبط در آن ذخیره می شد. و هنگامی که رویدادی در Runtime می آید، به عنوان مثال، صفحه یا چیز دیگری را نشان می دهد، سپس درخواستی از کاساندرا انجام شد - آیا چنین شخصی وجود دارد یا خیر. سپس معاملات مربوط به آن به دست آمد. و ارتباط برقرار شد.
و اگر خوش شانس باشد که درخواست دارای شناسه تراکنش باشد، آسان است. اما معمولاً شانسی نیست. بنابراین لازم بود آخرین تراکنش یا تراکنش با آخرین کلیک و غیره پیدا شود.
و تا زمانی که صحافی تا آخرین کلیک بود، همه چیز بسیار خوب کار می کرد. چون مثلاً 10 میلیون کلیک در روز وجود دارد، 300 میلیون در ماه، اگر یک پنجره برای یک ماه تنظیم کنیم. و از آنجایی که در Cassandra باید همه آن در حافظه باشد تا سریع اجرا شود، زیرا Runtime باید سریع پاسخ دهد، حدود 10-15 سرور طول کشید.
و هنگامی که آنها می خواستند یک تراکنش را به صفحه نمایش پیوند دهند، بلافاصله معلوم شد که چندان جالب نیست. و چرا؟ مشاهده می شود که 30 برابر بیشتر رویدادها باید ذخیره شوند. و بر این اساس، شما به 30 برابر بیشتر سرور نیاز دارید. و معلوم می شود که این یک نوع رقم نجومی است. نگه داشتن حداکثر 500 سرور برای انجام پیوند، علیرغم این واقعیت که سرورهای بسیار کمتری در Runtime وجود دارد، این رقم اشتباهی است. و شروع کردند به فکر کردن که چه کنند.
و به کلیک هاوس رفتیم. و چگونه می توان آن را در ClickHouse انجام داد؟ در نگاه اول به نظر می رسد که این مجموعه ای از ضد الگوها است.
- تراکنش رشد می کند، رویدادهای بیشتری را به آن متصل می کنیم، یعنی قابل تغییر است، و ClickHouse با اشیاء قابل تغییر خیلی خوب کار نمی کند.
- زمانی که یک بازدیدکننده به ما مراجعه می‌کند، باید تراکنش‌های او را با کلید، با شناسه بازدید او انجام دهیم. این نیز یک پرس و جو نقطه ای است، آنها این کار را در ClickHouse انجام نمی دهند. معمولا ClickHouse دارای ... اسکن های بزرگ است، اما در اینجا ما باید چند رکورد را دریافت کنیم. همچنین یک ضد الگو.
- علاوه بر این، تراکنش در json بود، اما آنها نمی‌خواستند آن را بازنویسی کنند، بنابراین می‌خواستند json را به صورت بدون ساختار ذخیره کنند و در صورت لزوم، چیزی را از آن بیرون بکشند. و این نیز یک ضد الگو است.
یعنی مجموعه ای از آنتی الگوها.
اما با این وجود معلوم شد که سیستمی ساخته شده است که بسیار خوب کار می کند.
چه کاری انجام شد؟ ClickHouse ظاهر شد، که سیاهههای مربوط به آن پرتاب شدند و به رکوردها تقسیم شدند. یک سرویس منتسب ظاهر شد که گزارش‌هایی را از ClickHouse دریافت کرد. پس از آن، برای هر ورودی، با شناسه بازدید، تراکنش هایی را دریافت کردم که ممکن است هنوز پردازش نشده باشند و به علاوه عکس های فوری، یعنی تراکنش هایی که قبلا متصل شده اند، یعنی نتیجه کار قبلی. من قبلاً از آنها منطق ساختم، تراکنش صحیح را انتخاب کردم، رویدادهای جدید را متصل کردم. دوباره وارد شد. گزارش به ClickHouse بازگشت، یعنی یک سیستم دائما چرخه ای است. و علاوه بر این، من به DWH رفتم تا آن را در آنجا تجزیه و تحلیل کنم.
در این شکل بود که خیلی خوب کار نکرد. و برای تسهیل کار ClickHouse، زمانی که یک درخواست بر اساس شناسه بازدید وجود داشت، آنها این درخواست ها را در بلوک های 1-000 شناسه بازدید گروه بندی کردند و تمام تراکنش های 2-000 نفر را خارج کردند. و سپس همه چیز کار کرد.
اگر به داخل ClickHouse نگاه کنید، تنها 3 جدول اصلی وجود دارد که همه اینها را ارائه می دهند.
اولین جدولی که گزارش‌ها در آن آپلود می‌شوند و گزارش‌ها تقریباً بدون پردازش آپلود می‌شوند.
جدول دوم. از طریق نمای مادی شده، از این گزارش‌ها، رویدادهایی که هنوز نسبت داده نشده‌اند، یعنی موارد غیرمرتبط، حذف شدند. و از طریق نمای مادی‌شده، تراکنش‌ها برای ساختن یک عکس فوری از این گزارش‌ها خارج شدند. به این معنا که یک نمای مادی خاص، یک عکس فوری، یعنی آخرین وضعیت انباشته تراکنش ایجاد کرد.
در اینجا متن نوشته شده در SQL است. من می خواهم در مورد چند نکته مهم در آن نظر بدهم.
اولین چیز مهم، توانایی بیرون کشیدن ستون ها و فیلدها از json در ClickHouse است. یعنی ClickHouse چند روش برای کار با json دارد. آنها بسیار بسیار ابتدایی هستند.
VisitParamExtractInt به شما امکان می دهد تا ویژگی ها را از json استخراج کنید، یعنی اولین ضربه کار می کند. و از این طریق می توانید شناسه تراکنش یا شناسه بازدید را بیرون بکشید. این بار.
ثانیاً، در اینجا از یک میدان مادی شده پیچیده استفاده شده است. چه مفهومی داره؟ این بدان معنی است که شما نمی توانید آن را در جدول وارد کنید، یعنی درج نشده است، در هنگام درج محاسبه و ذخیره می شود. هنگام چسباندن، ClickHouse کار را برای شما انجام می دهد. و آنچه بعداً نیاز دارید قبلاً از json خارج شده است.
در این مورد، نمای متریال شده برای ردیف های خام است. و اولین جدول با لاگ های عملا خام فقط استفاده می شود. و چه می کند؟ اولاً مرتب‌سازی را تغییر می‌دهد، یعنی مرتب‌سازی اکنون با شناسه بازدید انجام می‌شود، زیرا باید به سرعت تراکنش او را برای یک شخص خاص خارج کنیم.
دومین مورد مهم index_granularity است. اگر MergeTree را دیده اید، معمولاً به طور پیش فرض index_granularity 8 است. آن چیست؟ این پارامتر پراکندگی شاخص است. در ClickHouse ایندکس پراکنده است، هرگز هر ورودی را ایندکس نمی کند. این کار را هر 192 انجام می‌دهد و زمانی که نیاز به محاسبه داده‌های زیادی است خوب است، اما زمانی که مقدار کمی است بد است، زیرا سربار زیادی وجود دارد. و اگر دانه بندی شاخص را کاهش دهیم، سربار را کاهش می دهیم. نمی توان آن را به یک کاهش داد، زیرا ممکن است حافظه کافی وجود نداشته باشد. شاخص همیشه در حافظه ذخیره می شود.
اسنپ شات همچنین از برخی دیگر از ویژگی های جالب کلیک هاوس استفاده می کند.
اول، آن AggregatingMergeTree است. و AggregatingMergeTree argMax را ذخیره می کند، یعنی این وضعیت تراکنش مربوط به آخرین مهر زمانی است. تراکنش ها همیشه برای یک بازدیدکننده خاص ایجاد می شوند. و در آخرین حالت این تراکنش، یک رویداد اضافه کردیم و یک حالت جدید داریم. دوباره به ClickHouse برخورد کرد. و از طریق argMax در این نمای مادی شده، همیشه می توانیم وضعیت فعلی را بدست آوریم.
- صحافی از Runtime جدا شده است.
- تا 3 میلیارد تراکنش در ماه ذخیره و پردازش می شود. این یک مرتبه بزرگتر از آنچه در کاساندرا بود، یعنی در یک سیستم معاملاتی معمولی است.
- خوشه ای از سرورهای ClickHouse 2×5. 5 سرور و هر سرور یک ماکت دارد. این حتی کمتر از آن چیزی است که در کاساندرا بود تا بتوان اسناد مبتنی بر کلیک را انجام داد، و در اینجا ما بر اساس برداشت داریم. یعنی به جای اینکه تعداد سرورها را 30 برابر کنند، موفق شدند آنها را کاهش دهند.
و آخرین مثال شرکت مالی Y است که همبستگی تغییرات قیمت سهام را تجزیه و تحلیل کرد.
و وظیفه این بود:
- تقریباً 5 سهم وجود دارد.
- نقل قول در هر 100 میلی ثانیه مشخص است.
- داده ها در طول 10 سال جمع آوری شده است. ظاهراً برای برخی شرکت ها بیشتر و برای برخی کمتر.
- در مجموع حدود 100 میلیارد ردیف وجود دارد.
و لازم بود همبستگی تغییرات محاسبه شود.
در اینجا دو سهم و قیمت آنها وجود دارد. اگر یکی بالا رفت و دیگری بالا رفت، این یک همبستگی مثبت است، یعنی یکی بالا می رود و دیگری بالا می رود. اگر یکی بالا رود، مانند انتهای نمودار، و دیگری پایین بیاید، این یک همبستگی منفی است، یعنی وقتی یکی بالا می رود، دیگری سقوط می کند.
با تحلیل این تغییرات متقابل می توان پیش بینی هایی را در بازار مالی انجام داد.
اما کار دشوار است. برای این کار چه می شود؟ ما 100 میلیارد رکورد داریم که دارای: زمان، سهام و قیمت هستند. ابتدا باید 100 میلیارد برابر در حال اجرا تفاوت را از الگوریتم قیمت محاسبه کنیم. RunningDifference تابعی در ClickHouse است که به صورت متوالی تفاوت بین دو رشته را محاسبه می کند.
و پس از آن، شما باید همبستگی را محاسبه کنید، و همبستگی باید برای هر جفت محاسبه شود. برای 5 سهم، جفت 000 میلیون است. و این مقدار زیادی است، یعنی 12,5 برابر محاسبه چنین تابع همبستگی لازم است.
و اگر کسی فراموش کرد، ͞x و ͞y یک مات است. انتظار نمونه گیری یعنی نه تنها باید ریشه ها و مجموع ها را محاسبه کرد، بلکه یک مجموع دیگر نیز در داخل این مجموعات لازم است. یک دسته از محاسبات باید 12,5 میلیون بار انجام شود و حتی بر اساس ساعت گروه بندی شود. ساعات زیادی هم داریم. و شما باید آن را در 60 ثانیه انجام دهید. این یه شوخیه.
لازم بود حداقل به نحوی زمان داشته باشیم، زیرا همه اینها قبل از آمدن ClickHouse بسیار بسیار کند کار می کرد.
آنها سعی کردند آن را روی Hadoop، در Spark، در Greenplum محاسبه کنند. و همه اینها بسیار کند یا گران بود. یعنی یه جورایی میشد حساب کرد ولی بعدش گرون شد.
و سپس ClickHouse آمد و اوضاع خیلی بهتر شد.
به شما یادآوری می کنم که ما با محلی بودن داده ها مشکل داریم، زیرا همبستگی ها قابل بومی سازی نیستند. ما نمی توانیم برخی از داده ها را روی یک سرور قرار دهیم، برخی را در سرور دیگری و محاسبه کنیم، باید همه داده ها را در همه جا داشته باشیم.
آنها چه کردند؟ در ابتدا داده ها بومی سازی می شوند. هر سرور داده ها را در مورد قیمت گذاری مجموعه خاصی از سهام ذخیره می کند. و با هم همپوشانی ندارند. بنابراین، می توان logReturn را به صورت موازی و مستقل محاسبه کرد، همه اینها تا کنون به صورت موازی و توزیع شده اتفاق می افتد.
سپس تصمیم گرفتیم این داده ها را کاهش دهیم، در حالی که بیانگر بودن را از دست ندهیم. استفاده از آرایه ها را کاهش دهید، یعنی برای هر دوره زمانی، مجموعه ای از سهام و مجموعه ای از قیمت ها را بسازید. بنابراین فضای داده بسیار کمتری را اشغال می کند. و کار با آنها کمی راحت تر است. اینها عملیات تقریباً موازی هستند، یعنی تا حدی به صورت موازی می خوانیم و سپس در سرور می نویسیم.
پس از آن، می توان آن را تکرار کرد. حرف "r" به این معنی است که ما این داده ها را تکرار کردیم. یعنی در هر سه سرور داده های یکسانی داریم - اینها آرایه ها هستند.
و سپس با یک اسکریپت خاص از این مجموعه 12,5 میلیون همبستگی که باید محاسبه شود، می توانید بسته بندی کنید. یعنی 2 کار با 500 جفت همبستگی. و این وظیفه باید بر روی یک سرور ClickHouse خاص محاسبه شود. او همه داده ها را دارد، زیرا داده ها یکسان است و می تواند آنها را به ترتیب محاسبه کند.
یک بار دیگر، این چیزی است که به نظر می رسد. اول، ما تمام داده ها را در این ساختار داریم: زمان، سهام، قیمت. سپس logReturn را محاسبه کردیم، یعنی داده های همان ساختار، اما به جای قیمت، از قبل logReturn داریم. سپس آنها دوباره ساخته شدند، یعنی ما زمان و GroupArray را برای سهام و قیمت ها دریافت کردیم. تکثیر شده. و پس از آن، ما یکسری وظایف تولید کردیم و آنها را به ClickHouse دادیم تا آنها را شمارش کند. و کار می کند.
در اثبات مفهوم، وظیفه یک کار فرعی بود، یعنی داده‌های کمتری گرفته شد. و فقط سه سرور
این دو مرحله اول: محاسبه Log_return و بسته بندی در آرایه ها حدود یک ساعت طول کشید.
و محاسبه همبستگی حدود 50 ساعت است. اما 50 ساعت کافی نیست، زیرا آنها هفته ها کار می کردند. موفقیت بزرگی بود. و اگر حساب کنید، 70 بار در ثانیه همه چیز روی این خوشه حساب شده است.
اما مهمترین چیز این است که این سیستم عملاً بدون گلوگاه است، یعنی تقریباً به صورت خطی مقیاس می شود. و آنها آن را بررسی کردند. با موفقیت آن را افزایش داد.
- طرح درست نیمی از موفقیت است. و طرح درست استفاده از تمام فناوری های ClickHouse ضروری است.
- Summing/AggregatingMergeTrees فن آوری هایی هستند که به شما امکان می دهند یک عکس فوری حالت را به عنوان یک مورد خاص جمع آوری یا در نظر بگیرید. و خیلی چیزها را بسیار ساده می کند.
- نماهای متریال شده به شما امکان می دهد از حد یک شاخص عبور کنید. شاید خیلی واضح نگفتم، اما وقتی لاگ‌ها را بارگذاری کردیم، لاگ‌های خام در جدول با یک شاخص بودند و گزارش‌های ویژگی در جدول، یعنی همان داده‌ها، فقط فیلتر شده بودند، اما ایندکس کاملاً بود. دیگران. به نظر می رسد داده های یکسان است، اما مرتب سازی متفاوت است. و Materialized Views به شما امکان می دهد، در صورت نیاز، از چنین محدودیت های ClickHouse عبور کنید.
- کاهش جزئیات شاخص برای پرس و جوهای نقطه ای.
- و داده ها را هوشمندانه توزیع کنید، سعی کنید تا حد امکان داده ها را در سرور بومی سازی کنید. و سعی کنید اطمینان حاصل کنید که درخواست ها تا آنجا که ممکن است از محلی سازی نیز استفاده می کنند.
و با جمع‌بندی این سخنرانی کوتاه، می‌توان گفت که ClickHouse اکنون به طور محکم قلمرو پایگاه‌های داده تجاری و پایگاه‌های داده منبع باز، یعنی به طور خاص برای تجزیه و تحلیل را اشغال کرده است. او کاملاً با این منظره مطابقت دارد. و علاوه بر این، به آرامی شروع به ازدحام دیگران می کند، زیرا وقتی ClickHouse دارید، به InfiniDB نیاز ندارید. اگر Vertika از SQL معمولی پشتیبانی کند، ممکن است به زودی مورد نیاز نباشد. لذت ببرید!
-با تشکر از گزارش! بسیار جالب! آیا مقایسه ای با آپاچی فینیکس وجود داشت؟
نه، من نشنیدم کسی مقایسه کند. ما و Yandex سعی می کنیم همه مقایسه های ClickHouse را با پایگاه های داده مختلف پیگیری کنیم. زیرا اگر ناگهان چیزی سریعتر از ClickHouse باشد، لشا میلوویدوف نمی تواند شب بخوابد و شروع به سرعت بخشیدن به آن می کند. من چنین مقایسه ای نشنیده ام.
-
(Aleksey Milovidov) Apache Phoenix یک موتور SQL است که توسط Hbase طراحی شده است. Hbase عمدتاً برای سناریوهای کاری با ارزش کلیدی است. در آنجا، در هر خط، می تواند تعداد دلخواه ستون با نام دلخواه وجود داشته باشد. این را می توان در مورد سیستم هایی مانند Hbase، Cassandra گفت. و دقیقاً پرس و جوهای تحلیلی سنگین هستند که به طور معمول برای آنها کار نمی کنند. یا اگر تجربه ای با ClickHouse نداشته باشید، ممکن است فکر کنید که آنها خوب کار می کنند.
-
سپاس ها
-
عصر بخیر من قبلاً کاملاً به این موضوع علاقه مند هستم ، زیرا یک زیر سیستم تحلیلی دارم. اما وقتی به ClickHouse نگاه می کنم، احساس می کنم که ClickHouse برای تجزیه و تحلیل رویداد بسیار مناسب است، قابل تغییر است. و اگر من نیاز به تجزیه و تحلیل بسیاری از داده های تجاری با یک دسته جداول بزرگ داشته باشم، کلیک هاوس، تا آنجا که من متوجه شدم، برای من خیلی مناسب نیست؟ به خصوص اگر تغییر کنند. آیا این درست است یا نمونه هایی وجود دارد که می تواند این موضوع را رد کند؟
-
این درست است. و این در مورد اکثر پایگاه های تخصصی تحلیلی صادق است. آنها برای این واقعیت طراحی شده اند که یک یا چند میز بزرگ وجود دارد که قابل تغییر هستند و برای بسیاری از میزهای کوچک که به آرامی تغییر می کنند. یعنی ClickHouse مانند اوراکل نیست که بتوانید همه چیز را در آن قرار دهید و چند کوئری بسیار پیچیده بسازید. به منظور استفاده موثر از ClickHouse، باید طرحی را بسازید که در ClickHouse به خوبی کار کند. یعنی از عادی سازی بیش از حد خودداری کنید، از فرهنگ لغت استفاده کنید، سعی کنید لینک های طولانی کمتری ایجاد کنید. و اگر طرح به این شکل ساخته شود، وظایف تجاری مشابه را می توان در ClickHouse بسیار کارآمدتر از یک پایگاه داده رابطه ای سنتی حل کرد.
-
با تشکر از گزارش! من یک سوال در مورد آخرین پرونده مالی دارم. تجزیه و تحلیل داشتند. باید مقایسه کرد که چگونه بالا و پایین می روند. و من می دانم که شما سیستم را به طور خاص برای این تجزیه و تحلیل ساخته اید؟ مثلاً اگر فردا به گزارش دیگری در مورد این داده ها نیاز داشته باشند، آیا باید طرحواره را دوباره بسازند و داده ها را آپلود کنند؟ یعنی یک نوع پیش پردازش برای دریافت درخواست انجام شود؟
البته این استفاده از ClickHouse برای یک کار بسیار خاص است. به طور سنتی می‌توان آن را در Hadoop حل کرد. برای Hadoop، این یک کار ایده آل است. اما در Hadoop بسیار کند است. و هدف من این است که نشان دهم که ClickHouse می تواند وظایفی را که معمولاً با روش های کاملاً متفاوت حل می شوند، حل کند، اما در عین حال آن را بسیار کارآمدتر انجام دهد. برای یک کار خاص طراحی شده است. واضح است که اگر مشکلی در مورد مشابه وجود داشته باشد، می توان آن را به روش مشابه حل کرد.
واضح است. گفتید 50 ساعت پردازش شد. آیا از همان ابتدا، چه زمانی داده ها را بارگذاری کردید یا نتایج را دریافت کردید؟
بله بله.
باشه، خیلی از شما ممنونم.
این در یک خوشه سرور 3 است.
با درود! با تشکر از گزارش! همه چیز بسیار جالب است. من کمی در مورد عملکرد سؤال نمی کنم، اما در مورد استفاده از ClickHouse از نظر پایداری. یعنی داشتی باید ریستور کنی؟ کلیک هاوس در این مورد چگونه رفتار می کند؟ و آیا این اتفاق افتاده است که شما یک ماکت هم داشته باشید؟ به عنوان مثال، زمانی که ClickHouse هنوز از حد خود خارج شده و سقوط می کند، با مشکل مواجه شدیم.
البته هیچ سیستم ایده آلی وجود ندارد. و ClickHouse نیز مشکلات خاص خود را دارد. اما آیا شنیده اید که Yandex.Metrica برای مدت طولانی کار نمی کند؟ احتمالا نه. از سال 2012 تا 2013 روی ClickHouse به طور قابل اعتماد کار می کند. در مورد تجربه خودم هم همین را می توانم بگویم. ما هرگز شکست کامل نداشته ایم. برخی از چیزهای جزئی ممکن است اتفاق بیفتد، اما هرگز به اندازه کافی حیاتی نبودند که بر تجارت تأثیر جدی بگذارند. هرگز اتفاق نیفتاد. ClickHouse کاملاً قابل اعتماد است و به طور تصادفی خراب نمی شود. شما لازم نیست در مورد آن نگران باشید. چیز خامی نیست این را بسیاری از شرکت ها ثابت کرده اند.
سلام! شما گفتید که باید فوراً به طرح داده فکر کنید. اگر این اتفاق می افتاد چه؟ داده های من می ریزد و می ریزد. شش ماه می‌گذرد، و من می‌دانم که نمی‌توان اینطور زندگی کرد، باید داده‌ها را دوباره آپلود کنم و کاری با آنها انجام دهم.
این البته به سیستم شما بستگی دارد. روش های مختلفی برای انجام این کار تقریباً بدون توقف وجود دارد. برای مثال، می‌توانید یک نمای Materialized ایجاد کنید که در آن ساختار داده‌ای متفاوت ایجاد کنید، اگر بتوان آن را به طور منحصربه‌فرد نگاشت. یعنی اگر اجازه نقشه‌برداری با استفاده از ClickHouse را می‌دهد، یعنی برخی چیزها را استخراج می‌کند، کلید اصلی را تغییر می‌دهد، پارتیشن‌بندی را تغییر می‌دهد، سپس می‌توانید یک نمای Materialized ایجاد کنید. داده های قدیمی خود را در آنجا بازنویسی کنید، موارد جدید به طور خودکار نوشته می شوند. و سپس فقط به استفاده از نمای Materialized تغییر دهید، سپس رکورد را تغییر دهید و جدول قدیمی را بکشید. این به طور کلی یک روش بدون توقف است.
متشکرم.
منبع: www.habr.com