از آنجایی که ClickHouse یک سیستم تخصصی است، مهم است که در هنگام استفاده از آن، ویژگی های معماری آن را در نظر بگیرید. در این گزارش، الکسی در مورد نمونه هایی از خطاهای معمولی هنگام استفاده از ClickHouse صحبت خواهد کرد که می تواند منجر به کار ناکارآمد شود. با استفاده از مثال‌های عملی، نشان خواهیم داد که چگونه انتخاب یک یا آن طرح پردازش داده‌ها می‌تواند عملکرد را بر اساس مرتبه‌های بزرگی تغییر دهد.
سلام به همه! اسم من الکسی است، من کلیک هاوس را می سازم.
اولاً، من عجله می کنم تا فوراً شما را خوشحال کنم، امروز به شما نمی گویم ClickHouse چیست. راستش ازش خسته شدم هر بار بهت میگم چیه و احتمالاً همه از قبل می دانند.
درعوض، من به شما خواهم گفت که رنک احتمالی چیست، یعنی چگونه می توان از ClickHouse سوء استفاده کرد. در واقع، نباید بترسید، زیرا ما در حال توسعه ClickHouse به عنوان سیستمی هستیم که ساده، راحت و خارج از جعبه کار می کند. همه چی نصب شد مشکلی نیست
اما باز هم باید در نظر داشت که این سیستم تخصصی است و به راحتی می توانید به یک مورد غیرعادی برخورد کنید که این سیستم را از محدوده راحتی خود خارج کند.
بنابراین، چنگک ها چیست؟ اساساً در مورد چیزهای واضح صحبت خواهم کرد. همه چیز برای همه واضح است، همه همه چیز را می فهمند و می توانند خوشحال باشند که اینقدر باهوش هستند و کسانی که نمی فهمند چیز جدیدی یاد می گیرند.
اولین مثال ساده، که متأسفانه اغلب اتفاق می افتد، تعداد زیادی درج با دسته های کوچک، یعنی تعداد زیادی درج کوچک است.
اگر در نظر بگیریم که ClickHouse چگونه یک درج را انجام می دهد، می توانید حداقل یک ترابایت داده را در یک درخواست ارسال کنید. مشکلی نیست.
و بیایید ببینیم عملکرد معمولی چه خواهد بود. به عنوان مثال، ما یک جدول با داده های Yandex.Metrica داریم. بازدید. 105 چند ستون. 700 بایت فشرده نشده و ما به روش خوبی دسته های یک میلیون خطی را درج خواهیم کرد.
در جدول MergeTree وارد می کنیم، نیم میلیون ردیف در ثانیه به دست می آید. عالی. در یک جدول تکراری - کمی کمتر، حدود 400 ردیف در ثانیه خواهد بود.
و اگر درج حد نصاب را روشن کنید، 250 بار در ثانیه عملکرد کمی کمتر، اما با این حال مناسب خواهید داشت. Quorum Insertion یک ویژگی غیر مستند در ClickHouse* است.
* از سال 2020، .
اگر اشتباه انجام دهید چه اتفاقی می افتد؟ یک ردیف را در جدول MergeTree وارد می کنیم و 59 سطر در ثانیه می گیریم. این 10 برابر کند است. در ReplicateMergeTree - 000 ردیف در ثانیه. و در صورت روشن شدن حد نصاب، 6 خط در ثانیه به دست می آید. به نظر من، این یک نوع مزخرف مطلق است. چطور می توانی اینطوری سرعتت را کم کنی؟ حتی روی تیشرت من می گوید که کلیک هاوس نباید کند شود. اما با این حال گاهی اوقات اتفاق می افتد.
در واقع این نقص ماست. می‌توانستیم کاری کنیم که به خوبی کار کند، اما این کار را نکردیم. و ما این کار را نکردیم، زیرا فیلمنامه ما به آن نیاز نداشت. ما قبلا دسته هایی داشتیم. ما فقط دسته هایی را در ورودی دریافت کردیم و هیچ مشکلی نداشتیم. آن را به برق وصل کنید و همه چیز خوب کار می کند. اما، البته، همه نوع سناریو ممکن است. به عنوان مثال، زمانی که شما یک دسته سرور دارید که داده ها روی آنها تولید می شود. و آنها داده ها را به دفعات وارد نمی کنند، اما همچنان درج های مکرر دریافت می کنند. و شما باید به نحوی از این امر اجتناب کنید.
از نقطه نظر فنی، نکته اصلی این است که وقتی یک درج در ClickHouse انجام می دهید، داده ها وارد هیچ memtable نمی شوند. ما حتی یک ساختار log MergeTree واقعی نداریم، بلکه فقط یک MergeTree داریم، زیرا نه log و نه memTable وجود دارد. ما فقط بلافاصله داده ها را در سیستم فایل می نویسیم که قبلاً به ستون ها تجزیه شده اند. و اگر 100 ستون دارید، باید بیش از 200 فایل در یک دایرکتوری جداگانه نوشته شود. همه اینها بسیار دست و پا گیر است.
و این سوال مطرح می شود: "چگونه این کار را درست انجام دهیم؟" در چنین شرایطی، هنوز باید به نحوی داده ها را در ClickHouse بنویسید.
روش 1. این ساده ترین راه است. از نوعی صف توزیع شده استفاده کنید. مثلا کافکا. شما فقط داده ها را از کافکا خارج می کنید، ما هر ثانیه یک بار آن ها را دسته بندی می کنیم. و همه چیز خوب خواهد بود، شما ضبط کنید، همه چیز خوب کار می کند.
معایب آن این است که کافکا یکی دیگر از سیستم های توزیع شده دست و پا گیر است. همچنین می‌دانم که آیا قبلاً کافکا را در شرکت خود دارید یا خیر. خوب است، راحت است. اما اگر وجود ندارد، قبل از کشیدن یک سیستم توزیع شده دیگر به پروژه خود، باید سه بار فکر کنید. و بنابراین ارزش در نظر گرفتن جایگزین ها را دارد.
روش 2. در اینجا یک جایگزین قدیمی و در عین حال بسیار ساده وجود دارد. آیا نوعی سرور دارید که لاگ های شما را تولید کند؟ و فقط لاگ های شما را در یک فایل می نویسد. و یک بار در ثانیه، برای مثال، نام این فایل را تغییر می دهیم، یک فایل جدید باز می کنیم. و یک اسکریپت جداگانه یا توسط cron یا برخی دیمون ها قدیمی ترین فایل را می گیرد و در ClickHouse می نویسد. اگر هر ثانیه یک بار لاگ بنویسید، همه چیز درست می شود.
اما عیب این روش این است که اگر سرور شما که لاگ ها روی آن تولید می شوند در جایی ناپدید شده باشد، داده ها نیز ناپدید می شوند.
روش 3. راه جالب دیگری هم وجود دارد که اصلاً بدون فایل های موقت است. به عنوان مثال، شما نوعی اسپینر تبلیغاتی یا دیمون جالب دیگری دارید که داده تولید می کند. و شما می توانید دسته ای از داده ها را درست در RAM، در بافر جمع آوری کنید. و هنگامی که زمان کافی گذشت، این بافر را کنار می گذارید، یک بافر جدید ایجاد می کنید و آنچه را که قبلاً در ClickHouse انباشته شده است در یک موضوع جداگانه وارد می کنید.
از سوی دیگر، داده ها نیز با kill -9 ناپدید می شوند. اگر سرور شما خراب شود، این داده ها را از دست خواهید داد. و مشکل دیگر این است که اگر نتوانستید در پایگاه داده بنویسید، اطلاعات شما در رم جمع می شود. و یا رم تمام می شود یا فقط اطلاعات را از دست می دهید.
روش 4. راه جالب دیگر. آیا فرآیند سرور دارید؟ و او می تواند داده ها را به یکباره به ClickHouse ارسال کند، اما این کار را در یک اتصال انجام دهد. به عنوان مثال، من یک درخواست http با transfer-encoding ارسال کردم: chunked with insert. و به ندرت تکه‌ها را تولید می‌کند، می‌توانید هر خط را ارسال کنید، اگرچه هزینه‌ای برای کادربندی این داده‌ها وجود خواهد داشت.
اما در این صورت داده ها بلافاصله به ClickHouse ارسال می شود. و خود ClickHouse آنها را بافر می کند.
اما مشکلاتی نیز وجود دارد. اکنون داده ها را از دست خواهید داد، از جمله زمانی که فرآیند شما کشته می شود و اگر فرآیند ClickHouse از بین برود، زیرا یک درج ناقص خواهد بود. و در ClickHouse درج‌ها تا مقداری آستانه مشخص در اندازه ردیف‌ها اتمی هستند. در اصل، این یک راه جالب است. همچنین قابل استفاده است.
روش 5. در اینجا یک راه جالب دیگر وجود دارد. این نوعی سرور توسعه یافته توسط جامعه برای دسته بندی داده ها است. من خودم به آن نگاه نکرده ام، بنابراین نمی توانم چیزی را تضمین کنم. با این حال، هیچ تضمینی برای خود ClickHouse وجود ندارد. این نیز منبع باز است، اما از سوی دیگر، می توانید به استانداردهای کیفیتی که ما سعی می کنیم ارائه کنیم عادت کنید. اما برای این چیز - من نمی دانم، به GitHub بروید، به کد نگاه کنید. شاید چیز خوبی نوشتند.
*از سال 2020 نیز باید به بررسی اضافه شود .
روش 6. راه دیگر استفاده از جداول بافر است. مزیت این روش این است که استفاده از آن بسیار آسان است. یک جدول بافر ایجاد کنید و در آن قرار دهید.
اما عیب این است که مشکل به طور کامل حل نشده است. اگر با نرخی از نوع MergeTree باید داده ها را بر اساس یک دسته در ثانیه گروه بندی کنید، سپس با نرخی در یک جدول بافر، باید حداقل تا چندین هزار در ثانیه گروه بندی کنید. اگر بیش از 10 در ثانیه باشد، باز هم بد خواهد بود. و اگر به صورت دسته ای وارد کنید، می بینید که صد هزار خط در ثانیه در آنجا به دست می آید. و این در حال حاضر بر روی داده های نسبتا سنگین است.
و همچنین جداول بافر لاگ ندارند. و اگر مشکلی در سرور شما وجود داشته باشد، داده ها از بین می روند.
و به عنوان یک امتیاز، اخیراً این فرصت را داشتیم که داده ها را از کافکا در ClickHouse جمع آوری کنیم. یک موتور جدول وجود دارد - کافکا. شما به سادگی خلق می کنید. و می توانید دیدگاه های مادی شده را روی آن آویزان کنید. در این صورت، او داده ها را از کافکا خارج کرده و در جداول مورد نیاز شما قرار می دهد.
و آنچه در مورد این فرصت خوشحال کننده است این است که ما از آن استفاده نکردیم. این یک ویژگی جامعه است. و وقتی می‌گویم «ویژگی جامعه»، بدون هیچ تحقیرآمیزی می‌گویم. ما کد را خواندیم، بررسی کردیم، باید خوب کار کند.
* از سال 2020، پشتیبانی مشابهی وجود دارد .
چه چیز دیگری می تواند هنگام درج داده ناخوشایند یا غیرمنتظره باشد؟ اگر یک پرس و جو مقادیر درج کنید و چند عبارت محاسبه شده را در مقادیر بنویسید. برای مثال now() نیز یک عبارت ارزیابی شده است. و در این حالت، ClickHouse مجبور می‌شود مفسر این عبارات را برای هر خط راه‌اندازی کند و عملکرد با مرتبه‌ای بزرگ کاهش می‌یابد. بهتر است از آن اجتناب کنید.
* در حال حاضر، مشکل کاملاً حل شده است، هنگام استفاده از عبارات در VALUES، دیگر رگرسیون عملکرد وجود ندارد.
مثال دیگری که در آن ممکن است مشکلاتی وجود داشته باشد، زمانی است که داده های شما در یک دسته به دسته ای از پارتیشن ها تعلق دارد. به طور پیش فرض، پارتیشن های ClickHouse بر اساس ماه. و اگر دسته ای از یک میلیون ردیف را وارد کنید و چندین سال داده وجود داشته باشد، چندین پارتیشن در آنجا خواهید داشت. و این معادل این واقعیت است که دسته هایی چندین ده برابر کوچکتر وجود خواهد داشت ، زیرا در داخل آنها همیشه ابتدا به پارتیشن ها تقسیم می شوند.
* اخیراً در ClickHouse در حالت آزمایشی پشتیبانی از فرمت فشرده قطعات و تکه‌ها در RAM با ثبت پیش‌نویس اضافه شده است که تقریباً به طور کامل مشکل را حل می‌کند.
اکنون نوع دوم مشکل - تایپ داده ها را در نظر بگیرید.
تایپ داده می تواند سختگیرانه و گاهی رشته ای باشد. String - این زمانی است که شما فقط گرفتید و اعلام کردید که تمام فیلدهای نوع رشته را دارید. بد است. شما مجبور نیستید این کار را انجام دهید.
بیایید در مواردی که می خواهید بگویید که ما مقداری فیلد، یک رشته داریم، چگونه درست انجام دهیم، و اجازه دهید ClickHouse خودش آن را بفهمد، اما من حمام بخار نمی گیرم. اما هنوز هم ارزش کمی تلاش را دارد.
به عنوان مثال، ما یک آدرس IP داریم. در یک مورد، ما آن را به عنوان یک رشته ذخیره کردیم. به عنوان مثال، 192.168.1.1. در غیر این صورت، تعدادی از نوع UInt32* خواهد بود. 32 بیت برای یک آدرس IPv4 کافی است.
اول، به اندازه کافی عجیب، داده ها تقریباً به همان اندازه فشرده می شوند. تفاوت وجود خواهد داشت، مطمئنا، اما نه آنقدر بزرگ. بنابراین مشکل خاصی در ورودی/خروجی دیسک وجود ندارد.
اما تفاوت جدی در زمان CPU و زمان اجرای پرس و جو وجود دارد.
بیایید تعداد آدرس‌های IP منحصربه‌فرد را در صورتی که به صورت اعداد ذخیره می‌شوند، بشماریم. 137 میلیون خط در ثانیه به دست می آید. اگر همان خطوط باشد، 37 میلیون خط در ثانیه. نمی دانم چرا این اتفاق افتاد. من خودم این درخواست ها را انجام داده ام. اما با این وجود حدود 4 برابر کندتر است.
و اگر تفاوت فضای دیسک را محاسبه کنید، تفاوت نیز وجود دارد. و این تفاوت حدود یک چهارم است، زیرا تعداد زیادی آدرس IP منحصر به فرد وجود دارد. و اگر خطوطی با تعداد کمی از مقادیر مختلف وجود داشته باشد، آنها به آرامی در فرهنگ لغت به حجم تقریباً یکسان فشرده می شوند.
و چهار برابر اختلاف زمانی در راه نبودن است. شاید شما، البته، اهمیتی ندهید، اما وقتی چنین تفاوتی را می بینم، غمگین می شوم.
بیایید موارد مختلف را در نظر بگیریم.
1. یک مورد که مقادیر کمی متفاوت و منحصر به فرد دارید. در این مورد، ما از یک تمرین ساده استفاده می کنیم که احتمالاً می دانید و می توانید برای هر DBMS از آن استفاده کنید. همه اینها نه تنها برای ClickHouse منطقی است. فقط شناسه های عددی را در پایگاه داده بنویسید. و شما می توانید به رشته و پشت در کنار برنامه خود تبدیل کنید.
به عنوان مثال، شما یک منطقه دارید. و شما سعی می کنید آن را به عنوان یک رشته ذخیره کنید. و در آنجا نوشته خواهد شد: مسکو و منطقه مسکو. و وقتی می بینم که "Moscow" در آنجا نوشته شده است ، این هنوز چیزی نیست و وقتی MO است ، به نوعی کاملاً غم انگیز می شود. این چند بایت است.
در عوض، ما به سادگی شماره Ulnt32 و 250 را یادداشت می کنیم. ما در Yandex 250 داریم، اما ممکن است مال شما متفاوت باشد. در هر صورت، من می گویم که ClickHouse دارای توانایی داخلی برای کار با geobase است. شما به سادگی یک دایرکتوری با مناطق، از جمله یک فهرست سلسله مراتبی، بنویسید، یعنی مسکو، منطقه مسکو و هر چیزی که نیاز دارید وجود خواهد داشت. و می توانید در سطح درخواست تبدیل کنید.
گزینه دوم تقریباً مشابه است، اما با پشتیبانی در داخل ClickHouse. این یک نوع داده Enum است. شما به سادگی تمام مقادیر مورد نیاز خود را در Enum بنویسید. به عنوان مثال، نوع دستگاه و نوشتن در آنجا: دسکتاپ، موبایل، تبلت، تلویزیون. فقط 4 گزینه
نقطه ضعف این است که شما باید به طور دوره ای تغییر دهید. فقط یک گزینه اضافه شده است. میز آلتر درست می کنیم. در واقع، alter table در ClickHouse رایگان است. به خصوص رایگان برای Enum زیرا داده های روی دیسک تغییر نمی کند. اما با این وجود، alter یک قفل * روی میز به دست می آورد و باید منتظر بماند تا تمام انتخاب ها تکمیل شوند. و تنها پس از این که این تغییر اجرا می شود، یعنی هنوز برخی از ناراحتی ها وجود دارد.
* در نسخه های اخیر ClickHouse، ALTER کاملا غیر مسدود کننده ساخته شده است.
یکی دیگر از گزینه های کاملا منحصر به فرد برای ClickHouse، اتصال دیکشنری های خارجی است. می توانید اعداد را در ClickHouse بنویسید و دایرکتوری های خود را در هر سیستمی که برای شما مناسب است نگه دارید. به عنوان مثال، می توانید از: MySQL، Mongo، Postgres استفاده کنید. حتی می توانید میکروسرویس خود را ایجاد کنید که این داده ها را از طریق http ارسال می کند. و در سطح ClickHouse، تابعی می نویسید که این داده ها را از اعداد به رشته ها تبدیل می کند.
این یک روش تخصصی اما بسیار کارآمد برای انجام اتصال روی میز خارجی است. و دو گزینه وجود دارد. در یک گزینه، این داده ها به طور کامل در حافظه پنهان، به طور کامل در RAM موجود و در فواصل زمانی به روز می شوند. و در یک گزینه دیگر، اگر این داده ها در رم جا نمی شوند، می توانید تا حدی آن را کش کنید.
به عنوان مثال. Yandex.Direct وجود دارد. و یک شرکت تبلیغاتی و بنر وجود دارد. احتمالاً ده ها میلیون شرکت تبلیغاتی وجود دارد. و تقریباً در رم جا می شود. و میلیاردها بنر وجود دارد که مناسب نیستند. و ما از یک دیکشنری کش شده از MySQL استفاده می کنیم.
تنها مشکل این است که دیکشنری کش شده به خوبی کار می کند اگر نرخ ضربه نزدیک به 100٪ باشد. اگر کوچکتر باشد، هنگام پردازش درخواست‌ها برای هر بسته داده، باید در واقع کلیدهای گمشده را بردارید و به سراغ گرفتن داده از MySQL بروید. درباره ClickHouse، من هنوز هم می توانم تضمین کنم که - بله، سرعت آن کاهش نمی یابد، من در مورد سیستم های دیگر صحبت نمی کنم.
و به عنوان یک امتیاز، دیکشنری ها یک راه بسیار آسان برای به روز رسانی داده ها در ClickHouse به صورت ماسبق هستند. یعنی شما یک گزارش از شرکت های تبلیغاتی داشتید، کاربر به سادگی شرکت تبلیغاتی را تغییر داد و در تمام داده های قدیمی، در همه گزارش ها، این داده ها نیز تغییر کرد. اگر ردیف ها را مستقیماً روی جدول بنویسید، نمی توانید آنها را به روز کنید.
راه دیگر زمانی که نمی دانید شناسه رشته های خود را از کجا دریافت کنید. شما فقط می توانید هش کنید. و ساده ترین گزینه گرفتن هش 64 بیتی است.
تنها مشکل این است که اگر هش 64 بیتی باشد، تقریباً مطمئناً برخورد خواهید داشت. زیرا اگر یک میلیارد خط وجود داشته باشد، آنگاه احتمال آن در حال ملموس شدن است.
و هش کردن نام شرکت های تبلیغاتی مانند آن خیلی خوب نیست. اگر کمپین های تبلیغاتی شرکت های مختلف با هم مخلوط شوند، چیزی غیرقابل درک وجود خواهد داشت.
و یک ترفند ساده وجود دارد. درست است، برای داده های جدی نیز مناسب نیست، اما اگر چیزی خیلی جدی نیست، به سادگی یک شناسه مشتری دیگر را به کلید فرهنگ لغت اضافه کنید. و سپس شما برخورد خواهید داشت، اما فقط در یک مشتری. و ما از این روش برای نقشه پیوند در Yandex.Metrica استفاده می کنیم. ما آدرس‌های اینترنتی را در آنجا داریم، هش‌ها را ذخیره می‌کنیم. و ما می دانیم که البته درگیری وجود دارد. اما وقتی صفحه ای نمایش داده می شود، احتمال اینکه در یک صفحه است که یک کاربر آدرس های اینترنتی به هم چسبیده باشد و این مورد توجه قرار گیرد، می توان از این موضوع صرف نظر کرد.
به عنوان یک امتیاز، برای بسیاری از عملیات ها، فقط هش ها کافی است و خود رشته ها را نمی توان در جایی ذخیره کرد.
مثال دیگر اگر رشته ها کوتاه باشند، مانند دامنه های وب سایت. آنها را می توان همانطور که هست ذخیره کرد. یا مثلا زبان مرورگر ru 2 بایت است. البته برای بایت ها متاسفم اما نگران نباشید 2 بایت حیف نیست. لطفا آن را همانطور که هست نگه دارید، نگران نباشید.
مورد دیگر زمانی است که برعکس، رشته های زیادی وجود دارد و در عین حال تعداد زیادی رشته منحصر به فرد در آنها وجود دارد و حتی مجموعه به طور بالقوه نامحدود است. یک مثال معمولی عبارت‌های جستجو یا آدرس‌های اینترنتی است. عبارات جستجو، از جمله به دلیل غلط املایی. بیایید ببینیم چند عبارت جستجوی منحصر به فرد در روز است. و معلوم می شود که آنها تقریباً نیمی از همه رویدادها هستند. و در این مورد، ممکن است فکر کنید که باید داده ها را عادی کنید، شناسه ها را بشمارید، آنها را در یک جدول جداگانه قرار دهید. اما شما مجبور نیستید این کار را انجام دهید. فقط این خطوط را همانطور که هست نگه دارید.
بهتر است - چیزی اختراع نکنید، زیرا اگر آن را جداگانه ذخیره کنید، باید یک پیوست انجام دهید. و این پیوستن در بهترین حالت یک دسترسی تصادفی به حافظه است، اگر هنوز در حافظه جا می شود. اگر مناسب نباشد، به طور کلی مشکلاتی وجود خواهد داشت.
و اگر داده ها در جای خود ذخیره شوند، آنها به سادگی از سیستم فایل به ترتیب صحیح خوانده می شوند و همه چیز خوب است.
اگر آدرس های اینترنتی یا رشته های طولانی پیچیده دیگری دارید، باید به این موضوع فکر کنید که می توانید مقداری فشار را از قبل محاسبه کنید و آن را در یک ستون جداگانه بنویسید.
برای url ها، برای مثال، می توانید دامنه را جداگانه ذخیره کنید. و اگر واقعاً به یک دامنه نیاز دارید، فقط از این ستون استفاده کنید، آدرس‌های اینترنتی دروغ می‌گویند و شما حتی آنها را لمس نخواهید کرد.
بیایید ببینیم تفاوت چیست. ClickHouse یک تابع تخصصی دارد که دامنه را محاسبه می کند. بسیار سریع است، ما آن را بهینه کرده ایم. و صادقانه بگویم، حتی با RFC مطابقت ندارد، اما با این وجود همه چیزهایی را که ما نیاز داریم در نظر می گیرد.
و در یک مورد، ما به سادگی آدرس ها را دریافت کرده و دامنه را محاسبه می کنیم. معلوم می شود 166 میلی ثانیه است. و اگر یک دامنه آماده بگیرید، فقط 67 میلی ثانیه، یعنی تقریباً سه برابر سریعتر به نظر می رسد. و سریعتر، نه به این دلیل که باید محاسباتی انجام دهیم، بلکه به این دلیل که داده‌های کمتری می‌خوانیم.
بنا به دلایلی، یک درخواست، که کندتر است، سرعت بیشتری بر حسب گیگابایت در ثانیه می گیرد. چون گیگ بیشتر میخونه. این اطلاعات کاملاً زائد است. به نظر می‌رسد درخواست سریعتر اجرا می‌شود، اما تکمیل شدن زمان بیشتری طول می‌کشد.
و اگر به مقدار داده روی دیسک نگاه کنید، معلوم می شود که URL 126 مگابایت است و دامنه فقط 5 مگابایت است. 25 برابر کمتر معلوم می شود. با این حال، پرس و جو هنوز هم فقط 4 برابر سریعتر است. اما این به این دلیل است که داده ها داغ هستند. و اگر سرد بود، احتمالاً به دلیل ورودی / خروجی دیسک، 25 برابر سریعتر بود.
به هر حال، اگر ارزیابی کنید که دامنه کمتر از URL است، معلوم می شود که حدود 4 برابر است، اما به دلایلی، داده های روی دیسک 25 برابر کمتر می شود. چرا؟ به دلیل فشرده سازی. و url فشرده می شود و دامنه فشرده می شود. اما اغلب آدرس اینترنتی حاوی یک دسته زباله است.
و، البته، ارزش استفاده از انواع داده های مناسب را دارد که به طور خاص برای مقادیر مناسب یا مناسب طراحی شده اند. اگر در IPv4 هستید، UInt32* را ذخیره کنید. اگر IPv6، سپس FixedString(16)، زیرا آدرس IPv6 128 بیتی است، یعنی مستقیماً در فرمت باینری ذخیره می شود.
اما اگر گاهی آدرس IPv4 و گاهی IPv6 داشته باشید چه؟ بله، شما می توانید هر دو را نگه دارید. یک ستون برای IPv4، دیگری برای IPv6. البته گزینه ای برای نگاشت IPv4 به IPv6 وجود دارد. این نیز کار می کند، اما اگر اغلب در درخواست های خود به آدرس IPv4 نیاز دارید، بهتر است آن را در یک ستون جداگانه قرار دهید.
* ClickHouse اکنون دارای انواع داده های IPv4 و IPv6 جداگانه است که داده ها را به همان اندازه کارآمدی اعداد ذخیره می کند، اما آنها را به راحتی مانند رشته ها نشان می دهد.
همچنین مهم است که توجه داشته باشید که ارزش پیش پردازش داده ها را از قبل دارد. به عنوان مثال، برخی از سیاهههای مربوط به شما می آید. و، شاید، شما نباید فورا آنها را در ClickHouse قرار دهید، اگرچه انجام هیچ کاری بسیار وسوسه انگیز است و همه چیز کار خواهد کرد. اما هنوز هم انجام محاسباتی که امکان پذیر است ارزشمند است.
به عنوان مثال، نسخه مرورگر. در برخی از بخش‌های همسایه، که نمی‌خواهم با انگشت اشاره کنم، نسخه مرورگر در آنجا به این صورت ذخیره می‌شود، یعنی به صورت رشته: 12.3. و سپس برای تهیه گزارش، این رشته را می گیرند و بر یک آرایه و سپس بر عنصر اول آرایه تقسیم می کنند. طبیعتاً همه چیز کند می شود. پرسیدم چرا این کار را می کنند؟ آنها به من گفتند که بهینه سازی زودرس را دوست ندارند. و بدبینی زودرس را دوست ندارم.
بنابراین در این مورد تقسیم به 4 ستون صحیح تر است. در اینجا نترسید، زیرا اینجا ClickHouse است. ClickHouse یک پایگاه داده ستونی است. و هر چه ستون‌های کوچک مرتب‌تر باشد، بهتر است. 5 BrowserVersion وجود خواهد داشت، 5 ستون ایجاد کنید. این خوبه.
اکنون در نظر بگیرید که اگر رشته های بسیار طولانی، آرایه های بسیار طولانی دارید، چه کاری انجام دهید. اصلاً نیازی نیست که در ClickHouse ذخیره شوند. در عوض، شما می توانید فقط برخی از شناسه ها را در ClickHouse ذخیره کنید. و این صف های طولانی آنها را به سیستم دیگری می برد.
به عنوان مثال، یکی از سرویس های تجزیه و تحلیل ما دارای برخی پارامترهای رویداد است. و اگر پارامترهای زیادی به رویدادها بیایند، ما به سادگی اولین 512 را ذخیره می کنیم. زیرا 512 حیف نیست.
و اگر نمی توانید در مورد انواع داده های خود تصمیم بگیرید، می توانید داده ها را در ClickHouse بنویسید، اما در یک جدول موقت از نوع Log که مخصوص داده های موقت است. پس از آن، می توانید تجزیه و تحلیل کنید که چه نوع توزیع مقادیری در آنجا دارید، چه چیزی به طور کلی وجود دارد و انواع صحیح را ایجاد کنید.
* اکنون ClickHouse یک نوع داده دارد که به شما امکان می دهد رشته ها را با تلاش کمتر به طور موثر ذخیره کنید.
حال یک مورد جالب دیگر را در نظر بگیرید. گاهی اوقات همه چیز برای مردم به طرز عجیبی کار می کند. من میرم اینو میبینم و بلافاصله به نظر می رسد که این کار توسط یک مدیر بسیار با تجربه و باهوش انجام شده است که تجربه زیادی در راه اندازی MySQL نسخه 3.23 دارد.
در اینجا هزار جدول را می بینیم که هر کدام شامل باقیمانده تقسیم مشخص نیست چه بر هزار است.
در اصل، من به تجربه دیگران احترام می گذارم، از جمله درک اینکه این تجربه چه نوع رنجی را می توان به دست آورد.
و دلایل آن کم و بیش روشن است. اینها کلیشه های قدیمی هستند که ممکن است هنگام کار با سیستم های دیگر انباشته شده باشند. به عنوان مثال، جداول MyISAM یک کلید اولیه خوشه ای ندارند. و این روش به اشتراک گذاری داده ها می تواند تلاشی ناامیدکننده برای به دست آوردن همان عملکرد باشد.
دلیل دیگر این است که انجام هر نوع عملیات تغییر روی میزهای بزرگ دشوار است. همه چیز مسدود خواهد شد. اگرچه در نسخه های مدرن MySQL، این مشکل دیگر چندان جدی نیست.
یا مثلاً میکروشاردینگ، اما بعداً در مورد آن بیشتر توضیح خواهیم داد.
در ClickHouse، نیازی به انجام این کار ندارید، زیرا اولاً، کلید اصلی خوشه‌بندی می‌شود، داده‌ها بر اساس کلید اصلی مرتب می‌شوند.
و گاهی اوقات مردم از من می پرسند: "عملکرد جستجوهای محدوده در ClickHouse با اندازه جدول چگونه تغییر می کند؟". میگم اصلا تغییر نمیکنه به عنوان مثال، شما یک جدول با یک میلیارد ردیف دارید و در حال خواندن محدوده یک میلیون ردیف هستید. همه چیز خوب است. اگر جدول دارای یک تریلیون ردیف باشد و شما در حال خواندن یک میلیون ردیف هستید، تقریباً یکسان خواهد بود.
و ثانیاً هیچ قطعه ای مانند پارتیشن دستی مورد نیاز نیست. اگر وارد شوید و به آنچه در سیستم فایل است نگاه کنید، خواهید دید که جدول یک چیز بسیار جدی است. و در داخل آن چیزی شبیه پارتیشن وجود دارد. یعنی ClickHouse همه کارها را برای شما انجام می دهد و نیازی به رنج نیست.
تغییر در ClickHouse در صورت تغییر ستون افزودن/ رها کردن رایگان است.
و شما نباید میزهای کوچک درست کنید، زیرا اگر 10 ردیف یا 10 ردیف در جدول خود داشته باشید، اصلاً مهم نیست. ClickHouse سیستمی است که توان عملیاتی را بهینه می کند، نه تأخیر، بنابراین پردازش 000 خط منطقی نیست.
استفاده از یک میز بزرگ صحیح است. از شر کلیشه های قدیمی خلاص شوید، همه چیز خوب خواهد شد.
و به عنوان یک امتیاز، در آخرین نسخه، ما این فرصت را داریم که یک کلید پارتیشن بندی دلخواه بسازیم تا بتوانیم انواع عملیات تعمیر و نگهداری را روی پارتیشن های جداگانه انجام دهیم.
به عنوان مثال، شما به بسیاری از جداول کوچک نیاز دارید، به عنوان مثال، زمانی که نیاز به پردازش برخی از داده های میانی وجود دارد، شما تکه هایی را دریافت می کنید و باید قبل از نوشتن در جدول نهایی، یک تبدیل روی آنها انجام دهید. برای این مورد، یک موتور جدول فوق العاده وجود دارد - StripeLog. مانند TinyLog است، فقط بهتر است.
* اکنون ClickHouse موارد بیشتری دارد .
یکی دیگر از ضد الگوها میکرو شاردینگ است. به عنوان مثال، شما باید اطلاعات را به اشتراک بگذارید و 5 سرور دارید و فردا 6 سرور وجود دارد. و شما فکر می کنید که چگونه این داده ها را دوباره متعادل کنید. و در عوض، شما به 5 قطعه تقسیم نمی شوید، بلکه به 1 قطعه تقسیم می شوید. و سپس هر یک از این microshard ها را به یک سرور جداگانه نگاشت می کنید. و شما در یک سرور به عنوان مثال 000 ClickHouse موفق خواهید شد. نمونه جداگانه در پورت های جداگانه یا پایگاه داده جداگانه.
اما در ClickHouse این خیلی خوب نیست. زیرا حتی یک نمونه از ClickHouse سعی می کند از تمام منابع سرور موجود برای پردازش یک درخواست استفاده کند. یعنی شما یک نوع سرور دارید و مثلاً 56 هسته پردازنده در آنجا وجود دارد. شما یک پرس و جو را اجرا می کنید که یک ثانیه طول می کشد و از 56 هسته استفاده می کند. و اگر 200 ClickHouses را روی یک سرور در آنجا قرار دهید، معلوم می شود که 10 موضوع شروع می شود. به طور کلی، همه چیز بسیار بد خواهد بود.
دلیل دیگر این است که توزیع کار در این موارد نابرابر خواهد بود. بعضی ها زودتر تمام می شوند، بعضی ها دیرتر. اگر همه اینها در یک نمونه اتفاق می افتاد، خود ClickHouse متوجه می شد که چگونه داده ها را به درستی بین جریان ها توزیع کند.
و دلیل دیگر این است که شما ارتباط بین پردازنده ای از طریق TCP خواهید داشت. داده‌ها باید سریال‌سازی شوند، سریال‌زدایی شوند، و این تعداد زیادی میکروشارد است. این فقط کار نخواهد کرد.
یک ضدالگوی دیگر، اگرچه به سختی می توان آن را ضد الگو نامید. این مقدار زیادی از پیش تجمیع است.
به طور کلی، پیش تجمیع خوب است. شما یک میلیارد ردیف داشتید، آن را جمع کردید و به 1 ردیف تبدیل شد و اکنون پرس و جو فوراً اجرا می شود. همه چی عالیه. اینطوری میتونی انجامش بدی و برای این کار، حتی ClickHouse دارای یک نوع جدول AggregatingMergeTree ویژه است که همزمان با درج داده ها، تجمع افزایشی را انجام می دهد.
اما مواقعی پیش می‌آید که فکر می‌کنید ما داده‌ها را به این شکل و داده‌ها را به این شکل جمع می‌کنیم. و در برخی از بخش‌های همسایه، نمی‌خواهم بگویم کدام یک، از جداول SummingMergeTree برای جمع‌بندی با کلید اصلی استفاده می‌کنند و 20 ستون به عنوان کلید اصلی استفاده می‌شود. در هر صورت، نام برخی از ستون ها را به دلیل توطئه تغییر دادم، اما همین.
و چنین مشکلاتی پیش می آید. اولاً، مقدار داده ای که دارید خیلی کاهش نمی یابد. مثلاً سه برابر کاهش می یابد. سه بار قیمت مناسبی برای تحلیل نامحدودی است که همراه با داده های غیر انباشته است. اگر داده ها انباشته شوند، به جای تجزیه و تحلیل، فقط آمارهای بدی دریافت می کنید.
و به خصوص چه چیزی خوب است؟ که این افراد از دپارتمان بعدی بروند و گاهی بخواهند یک ستون دیگر به کلید اصلی اضافه کنند. یعنی داده ها را به این صورت جمع کرده ایم و حالا کمی بیشتر می خواهیم. اما کلید اصلی تغییر دهنده در ClickHouse وجود ندارد. بنابراین، شما باید چند اسکریپت را در C ++ بنویسید. و من اسکریپت ها را دوست ندارم، حتی اگر در C++ باشند.
و اگر نگاه کنید که ClickHouse برای چه چیزی ایجاد شده است، داده های غیر انباشته دقیقاً سناریویی است که برای آن متولد شده است. اگر از ClickHouse برای داده های غیر انباشته استفاده می کنید، پس همه چیز را درست انجام می دهید. اگر در حال جمع شدن هستید، این گاهی اوقات قابل بخشش است.
مورد جالب دیگر درخواست ها در یک حلقه بی نهایت است. من گاهی اوقات به برخی از سرورهای تولید می روم و لیست فرآیندهای نمایش را در آنجا نگاه می کنم. و هر بار متوجه می شوم که اتفاق وحشتناکی در حال رخ دادن است.
به عنوان مثال، اینجا این است. بلافاصله مشخص می شود که انجام همه چیز در یک درخواست امکان پذیر بود. فقط آدرس و لیست را در آنجا بنویسید.
چرا بسیاری از این درخواست ها در یک حلقه بی نهایت بد هستند؟ اگر از ایندکس استفاده نشود، پس از آن تعداد زیادی پاس روی داده های مشابه خواهید داشت. اما اگر مثلاً از یک ایندکس استفاده شود، شما یک کلید اصلی روی ru دارید و url = چیزی را در آنجا می نویسید. و شما فکر می کنید که یک آدرس اینترنتی به صورت نقطه ای از جدول خوانده می شود، همه چیز خوب خواهد بود. اما واقعا نه زیرا ClickHouse همه چیز را به صورت دسته ای انجام می دهد.
هنگامی که او نیاز به خواندن محدوده ای از داده ها دارد، کمی بیشتر می خواند، زیرا ایندکس در ClickHouse پراکنده است. این شاخص به شما اجازه نمی دهد که یک ردیف جداگانه در جدول پیدا کنید، فقط نوعی محدوده. و داده ها در بلوک ها فشرده می شوند. برای خواندن یک خط، باید کل بلوک را بردارید و آن را از حالت فشرده خارج کنید. و اگر مجموعه ای از پرس و جوها را اجرا کنید، تقاطع های زیادی از آن ها خواهید داشت و کارهای زیادی را بارها و بارها انجام خواهید داد.
و به عنوان یک امتیاز می توانید ببینید که در ClickHouse نباید از انتقال حتی مگابایت و حتی صدها مگابایت به بخش IN ترسید. از تمرینمان به یاد دارم که اگر یک دسته مقادیر را در بخش IN در MySQL پاس کنیم، مثلاً 100 مگابایت از برخی اعداد را در آنجا پاس کنیم، سپس MySQL 10 گیگابایت حافظه را می خورد و هیچ اتفاق دیگری نمی افتد. همه چیز بد کار می کند
و دومین مورد این است که در ClickHouse، اگر پرس و جوهای شما از یک فهرست استفاده می کنند، همیشه سرعت آن کمتر از اسکن کامل نیست، یعنی اگر شما نیاز به خواندن تقریباً کل جدول دارید، به صورت متوالی پیش می رود و کل جدول را می خواند. به طور کلی، او آن را کشف خواهد کرد.
با این حال، برخی از مشکلات وجود دارد. به عنوان مثال، آن IN با یک جستجوی فرعی از ایندکس استفاده نمی کند. اما این مشکل ماست و باید آن را برطرف کنیم. هیچ چیز اساسی در اینجا وجود ندارد. بیایید آن را انجام دهیم*.
و نکته جالب دیگر این است که اگر درخواست بسیار طولانی دارید و پردازش درخواست توزیع شده در حال انجام است، این درخواست بسیار طولانی بدون فشرده سازی برای هر سرور ارسال می شود. مثلاً 100 مگابایت و 500 سرور. و بر این اساس 50 گیگابایت از طریق شبکه منتقل می شود. انتقال داده می شود و سپس همه چیز با موفقیت اجرا می شود.
* در حال حاضر استفاده می شود. همه چیز همانطور که قول داده بود درست شد
و اگر درخواست ها از API باشد، بسیار رایج است. به عنوان مثال، شما نوعی خدمات انجام داده اید. و اگر کسی به خدمات شما نیاز داشته باشد، API را باز کرده اید و به معنای واقعی کلمه دو روز بعد می بینید که چیزی غیرقابل درک در حال رخ دادن است. همه چیز بیش از حد بارگذاری شده است و درخواست های وحشتناکی وارد می شود که هرگز نباید می شد.
و تنها یک راه حل وجود دارد. اگر API را باز کرده اید، باید آن را برش دهید. مثلا برای وارد کردن چند سهمیه. هیچ گزینه منطقی دیگری وجود ندارد. در غیر این صورت بلافاصله فیلمنامه می نویسند و مشکلاتی به وجود می آید.
و ClickHouse یک ویژگی خاص دارد - این محاسبه سهمیه ها است. علاوه بر این، می توانید کلید سهمیه خود را انتقال دهید. برای مثال، این یک شناسه کاربری داخلی است. و سهمیه برای هر کدام به صورت مستقل محاسبه خواهد شد.
حالا یه چیز جالب دیگه این تکرار دستی است.
من موارد زیادی را می شناسم که علیرغم اینکه ClickHouse دارای پشتیبانی داخلی از تکرار است، افراد ClickHouse را به صورت دستی تکرار می کنند.
اصل چیست؟ شما یک خط لوله پردازش داده دارید. و به طور مستقل، به عنوان مثال، در مراکز داده مختلف کار می کند. شما همان داده ها را به همان روش در ClickHouse می نویسید. درست است، تمرین نشان می‌دهد که داده‌ها به دلیل برخی ویژگی‌های کد شما همچنان متفاوت خواهند بود. امیدوارم در مال شما باشد.
و به طور دوره ای هنوز باید به صورت دستی همگام سازی کنید. به عنوان مثال، یک بار در ماه، ادمین ها Rsync را انجام می دهند.
در واقع، استفاده از Replication داخلی در ClickHouse بسیار ساده تر است. اما ممکن است برخی موارد منع مصرف وجود داشته باشد، زیرا برای این کار باید از ZooKeeper استفاده کنید. من چیز بدی در مورد ZooKeeper نمی گویم، در اصل سیستم کار می کند، اما اتفاق می افتد که مردم به دلیل جاوا فوبیا از آن استفاده نمی کنند، زیرا ClickHouse سیستم بسیار خوبی است که با C ++ نوشته شده است که می توانید از آن استفاده کنید و همه چیز خوب خواهد شد و ZooKeeper در جاوا. و به نوعی حتی نمی خواهید نگاه کنید، اما سپس می توانید از تکرار دستی استفاده کنید.
ClickHouse یک سیستم عملی است. نیازهای شما را در نظر می گیرد. اگر نسخه دستی دارید، می‌توانید یک جدول توزیع شده ایجاد کنید که به کپی‌های دستی شما نگاه می‌کند و بین آنها یک Failover انجام می‌دهد. و حتی یک گزینه ویژه وجود دارد که به شما امکان می دهد از فلاپ اجتناب کنید، حتی اگر خطوط شما به طور سیستماتیک واگرا باشند.
علاوه بر این، اگر از موتورهای جدول ابتدایی استفاده می کنید، ممکن است مشکلاتی وجود داشته باشد. ClickHouse چنین سازنده ای است که دارای دسته ای از موتورهای جدول مختلف است. برای همه موارد جدی، همانطور که در مستندات نوشته شده است، از جداول خانواده MergeTree استفاده کنید. و بقیه - این برای موارد فردی یا برای آزمایش است.
در جدول MergeTree، نیازی به داشتن تاریخ و ساعت ندارید. هنوز هم می توانید استفاده کنید. اگر تاریخ و ساعت وجود ندارد، بنویسید که پیش فرض 2000 است. کار خواهد کرد و نیازی به منابع نخواهد داشت.
و در نسخه جدید سرور حتی می توانید مشخص کنید که پارتیشن بندی سفارشی بدون کلید پارتیشن داشته باشید. همینطور خواهد بود.
از طرفی می توان از موتورهای رومیزی اولیه استفاده کرد. مثلا یک بار داده ها را پر کنید و ببینید، بچرخانید و حذف کنید. می توانید از Log استفاده کنید.
یا ذخیره حجم های کوچک برای پردازش میانی StripeLog یا TinyLog است.
اگر مقدار کمی داده وجود داشته باشد و فقط چیزی را در RAM بچرخانید، می توان از حافظه استفاده کرد.
ClickHouse داده های عادی سازی شده را زیاد دوست ندارد.
در اینجا یک مثال معمولی است. این تعداد زیادی آدرس است. آنها را در جدول مجاور قرار می دهید. و سپس تصمیم گرفتیم JOIN را با آنها انجام دهیم، اما این معمولاً کار نخواهد کرد، زیرا ClickHouse فقط از Hash JOIN پشتیبانی می کند. اگر RAM کافی برای داده های زیادی برای اتصال وجود نداشته باشد، JOIN کار نمی کند *.
اگر داده ها کاردینالیته بالایی دارند، نگران نباشید، آنها را به شکل غیرعادی ذخیره کنید، URL ها مستقیماً در جدول اصلی قرار دارند.
* و اکنون ClickHouse یک ادغام هم دارد و در شرایطی کار می‌کند که داده‌های میانی در RAM جا نمی‌شوند. اما این بی اثر است و توصیه همچنان معتبر است.
چند مثال دیگر، اما من از قبل شک دارم که آیا آنها ضد الگو هستند یا نه.
ClickHouse یک اشکال شناخته شده دارد. او نمی داند چگونه * را به روز کند. به یک معنا، این حتی خوب است. اگر داده های مهمی دارید، به عنوان مثال، حسابداری، هیچ کس نمی تواند آنها را ارسال کند، زیرا هیچ به روز رسانی وجود ندارد.
* پشتیبانی از به روز رسانی و حذف در حالت دسته ای مدت هاست اضافه شده است.
اما راه‌های خاصی وجود دارد که به‌روزرسانی‌ها را در پس‌زمینه نمایش می‌دهند. به عنوان مثال، جداول از نوع ReplaceMergeTree. آنها در طول ادغام پس زمینه به روز رسانی می کنند. شما می توانید این را با بهینه سازی جدول مجبور کنید. اما این کار را زیاد انجام ندهید، زیرا پارتیشن را کاملاً بازنویسی می کند.
JOIN های توزیع شده در ClickHouse - این نیز توسط برنامه ریز پرس و جو به خوبی مدیریت نمی شود.
بد است، اما گاهی اوقات خوب است.
استفاده از ClickHouse فقط برای بازخوانی داده ها با select*.
من استفاده از ClickHouse را برای محاسبات حجیم توصیه نمی کنم. اما این کاملاً درست نیست، زیرا ما در حال دور شدن از این توصیه هستیم. و ما اخیراً توانایی اعمال مدل های یادگیری ماشین را در ClickHouse - Catboost اضافه کرده ایم. و این من را نگران می کند، زیرا فکر می کنم: "چه وحشتناک است. این تعداد چرخه در هر بایت است! برای من حیف است که چرخه های ساعت را بر روی بایت راه اندازی کنم.
اما نترسید، ClickHouse را نصب کنید، همه چیز درست می شود. اگر چیزی باشد، ما یک جامعه داریم. اتفاقاً جامعه شما هستید. و اگر مشکلی داشتید حداقل می توانید به چت ما بروید و امیدوارم کمکتان شود.
پرسش
با تشکر از گزارش! در مورد خرابی ClickHouse کجا شکایت کنیم؟
شما می توانید همین الان به شخص من شکایت کنید.
من اخیراً شروع به استفاده از ClickHouse کردم. بلافاصله رابط cli حذف شد.
تو خوش شانس هستی.
کمی بعد با یک انتخاب کوچک سرور را رها کردم.
تو استعداد داری
من یک باگ GitHub را باز کردم، اما نادیده گرفته شد.
خواهیم دید.
الکسی مرا فریب داد تا در گزارش شرکت کنم و قول داد که به من بگوید چگونه داده ها را در داخل فشرده می کنی.
خیلی ساده است.
این چیزی است که من دیروز متوجه شدم. مشخصات بیشتر
هیچ ترفند وحشتناکی وجود ندارد. این فقط فشرده سازی بلوک به بلوک است. پیش فرض LZ4 است، می توانید ZSTD* را فعال کنید. بلوک از 64 کیلوبایت تا 1 مگابایت.
* همچنین پشتیبانی از کدک های فشرده سازی تخصصی وجود دارد که می توانند به صورت زنجیره ای با الگوریتم های دیگر استفاده شوند.
آیا بلوک ها فقط داده های خام هستند؟
دقیقا خام نیست آرایه ها وجود دارد. اگر یک ستون عددی دارید، اعداد در یک ردیف در یک آرایه روی هم قرار می گیرند.
واضح است.
الکسی، مثالی که با uniqExact روی IP بود، یعنی این واقعیت که شمارش uniqExact با رشته ها بیشتر از اعداد طول می کشد و غیره. چه می شود اگر در لحظه تصحیح با گوش هایمان یک فانتزی بزنیم و گچ بگیریم؟ یعنی گویا گفتی روی دیسک زیاد فرق نمی کند. اگر خطوطی را از روی دیسک بخوانیم، ریخته گری کنیم، آیا تجمیع سریعتر خواهیم داشت یا خیر؟ یا ما هنوز در اینجا به طور جزئی سود می کنیم؟ به نظر من شما آن را تست کردید، اما به دلایلی آن را در بنچمارک نشان ندادید.
من فکر می کنم کندتر از عدم بازیگری خواهد بود. در این مورد، آدرس IP باید از رشته تجزیه شود. البته در ClickHouse تجزیه آدرس IP نیز بهینه شده است. ما خیلی تلاش کردیم، اما در همان جا شما اعداد را به شکل ده هزارم نوشته اید. خیلی ناراحت کننده از سوی دیگر، تابع uniqExact روی رشته‌ها کندتر کار می‌کند، نه تنها به این دلیل که این رشته‌ها هستند، بلکه به این دلیل که تخصص متفاوتی از الگوریتم انتخاب شده است. رشته ها به گونه ای متفاوت اداره می شوند.
و اگر نوع داده ابتدایی تری را در نظر بگیریم؟ مثلا یوزر id رو که داریم یادداشت کردند و به صورت یک خط نوشتند و بعد ریختند، لذتش بیشتر می شود یا نه؟
شک دارم. من فکر می کنم غم انگیزتر خواهد بود، زیرا در نهایت، تجزیه اعداد یک مشکل جدی است. به نظر من حتی این همکار گزارشی از دشواری تجزیه اعداد به شکل ده هزارم داشته است، اما شاید نه.
الکسی، از گزارش شما بسیار متشکرم! و از ClickHouse بسیار سپاسگزارم! من یک سوال در مورد برنامه ها دارم. آیا در طرح ها قابلیتی برای به روز رسانی ناقص لغت نامه ها وجود دارد؟
یعنی راه اندازی مجدد جزئی؟
بله بله. مانند امکان تنظیم یک فیلد MySQL در آنجا، یعنی به روز رسانی بعد از آن به طوری که اگر فرهنگ لغت بسیار بزرگ باشد، فقط این داده ها بارگیری شوند.
ویژگی بسیار جالب. و به نظر من، شخصی آن را در چت ما پیشنهاد داد. شاید حتی تو بودی
من اینطور فکر نمی کنم.
عالی، حالا معلوم می شود که دو درخواست. و می توانید به آرامی این کار را شروع کنید. اما من می خواهم بلافاصله به شما هشدار دهم که اجرای این ویژگی بسیار ساده است. یعنی در تئوری، فقط باید شماره نسخه را در جدول بنویسید و سپس بنویسید: نسخه کمتر از فلان است. و این بدان معنی است که به احتمال زیاد ما آن را به علاقه مندان ارائه خواهیم داد. آیا شما یک مشتاق هستید؟
بله، اما متاسفانه در C++ نه.
آیا همکاران شما می توانند به زبان C++ بنویسند؟
من کسی را پیدا می کنم.
عالی*.
* این ویژگی دو ماه پس از گزارش اضافه شد - توسط نویسنده سوال توسعه داده شد و توسط وی ارسال شد .
با تشکر از شما!
سلام! با تشکر از گزارش! شما اشاره کردید که ClickHouse تمام منابع موجود را به خوبی مصرف می کند. و سخنران کنار لوکسافت در مورد تصمیم خود برای پست روسیه صحبت کرد. او گفت که آنها واقعاً ClickHouse را دوست داشتند، اما از آن به جای رقیب اصلی خود استفاده نکردند، دقیقاً به این دلیل که کل پردازنده را خورد. و آنها نتوانستند آن را در معماری خود، در ZooKeeper خود با داکرها جا دهند. آیا می توان به نحوی ClickHouse را محدود کرد تا هر آنچه در دسترس است را مصرف نکند؟
بله، ممکن است و بسیار آسان است. اگر می خواهید هسته های کمتری مصرف کنید، فقط بنویسید set max_threads = 1. و این همه، درخواست را در یک هسته اجرا می کند. علاوه بر این، می توانید تنظیمات مختلفی را برای کاربران مختلف تعیین کنید. پس مشکلی نیست و به همکاران خود از Luxoft بگویید که خوب نیست که آنها این تنظیمات را در اسناد پیدا نکرده اند.
الکسی، سلام! من می خواهم این سوال را بپرسم. این اولین بار نیست که می شنوم که بسیاری از افراد شروع به استفاده از ClickHouse به عنوان یک مخزن برای لاگ ها کرده اند. در گزارش گفتید این کار را نکنید، یعنی نیازی به ذخیره صف های طولانی ندارید. تو در مورد آن چه فکر می کنی؟
اول، سیاهههای مربوط معمولاً خطوط طولانی نیستند. البته استثناهایی هم وجود دارد. به عنوان مثال، برخی از سرویس هایی که در جاوا نوشته شده است، یک استثنا می اندازد، ثبت می شود. و به همین ترتیب در یک حلقه بی پایان، و خالی شدن فضای هارد دیسک. راه حل بسیار ساده است. اگر خطوط بسیار طولانی هستند، آنها را برش دهید. طولانی یعنی چه؟ ده ها کیلوبایت بد است *.
* در نسخه‌های اخیر ClickHouse، «تطبیق‌پذیری فهرست» فعال است که مشکل ذخیره رشته‌های طولانی را تا حد زیادی برطرف می‌کند.
آیا یک کیلوبایت طبیعی است؟
این طبیعی است
سلام! با تشکر از گزارش! قبلاً در این مورد در چت پرسیدم، اما یادم نیست که پاسخی دریافت کردم یا خیر. آیا برنامه ای برای گسترش بخش WITH به روش CTE وجود دارد؟
نه هنوز. بخش WITH تا حدودی بیهوده است. برای ما مانند یک ویژگی کوچک است.
من میفهمم. متشکرم!
با تشکر از گزارش! بسیار جالب! سوال جهانی آیا برنامه ریزی شده است، شاید به شکل نوعی خرد، اصلاح حذف داده ها انجام شود؟
لزوما. این اولین وظیفه ما در صف است. ما اکنون فعالانه به این فکر می کنیم که چگونه همه چیز را درست انجام دهیم. و باید شروع به فشار دادن صفحه کلید* کنید.
* دکمه های کیبورد را فشار داد و همه چیز تمام شد.
آیا به نحوی بر عملکرد سیستم تأثیر می گذارد یا خیر؟ آیا درج به همان سرعتی که الان هست خواهد بود؟
شاید خود حذف ها، خود به روز رسانی ها بسیار سنگین باشند، اما این به هیچ وجه بر عملکرد انتخاب ها و عملکرد درج ها تأثیر نمی گذارد.
و یک سوال کوچک دیگر در ارائه، شما در مورد کلید اصلی صحبت کردید. بر این اساس، ما پارتیشن بندی داریم که به طور پیش فرض ماهانه است، درست است؟ و وقتی یک محدوده تاریخی را تنظیم می کنیم که در یک ماه قرار می گیرد، فقط این پارتیشن را می خوانیم، درست است؟
بله.
یک سوال. اگر نمی‌توانیم هیچ کلید اولیه‌ای را انتخاب کنیم، آیا درست است که دقیقاً با فیلد «تاریخ» این کار را انجام دهیم تا در پس‌زمینه ساختار کوچک‌تری از این داده‌ها وجود داشته باشد تا آنها به شیوه‌ای منظم‌تر قرار بگیرند؟ اگر کوئری های محدوده ندارید و حتی نمی توانید هیچ کلید اصلی را انتخاب کنید، آیا ارزش گذاشتن تاریخ در کلید اصلی را دارد؟
بله.
شاید منطقی باشد که در کلید اصلی فیلدی قرار دهیم که اگر داده ها بر اساس این فیلد مرتب شوند، بهتر فشرده شوند. برای مثال شناسه کاربری. برای مثال کاربر به همان سایت می رود. در این صورت شناسه کاربری و زمان را قرار دهید. و سپس داده های شما بهتر فشرده می شود. در مورد تاریخ، اگر واقعاً سؤالات محدوده تاریخ را ندارید و هرگز ندارید، نمی توانید تاریخ را در کلید اصلی قرار دهید.
باشه، خیلی از شما ممنونم!
منبع: www.habr.com