د اپریل په میاشت کې، د Avito انجنیران د کلیک هاوس د اصلي پراختیا کونکي الیکسي میلویدوف او کیریل شواکوف سره د آنلاین غونډو لپاره راټول شول، د انټیګروس څخه د ګولنګ پراختیا کونکي. موږ بحث وکړ چې څنګه موږ د ډیټابیس مدیریت سیسټم کاروو او له کومو ستونزو سره مخ یو.
د غونډې پراساس، موږ د بیک اپ، ډیټا بیا ځای کولو، بهرني لغتونو، ګولنګ ډرایور او د کلک هاوس نسخو تازه کولو په اړه زموږ او د لیدونکو پوښتنو ته د متخصصینو ځوابونو سره یوه مقاله جوړه کړې. دا ممکن د پراختیا کونکو لپاره ګټور وي څوک چې دمخه په فعاله توګه د Yandex DBMS سره کار کوي او د دې اوسني او راتلونکي سره علاقه لري. په ډیفالټ ډول، ځوابونه د الیکسي میلویدوف لخوا دي، پرته لدې چې بل ډول لیکلي وي.
محتاط اوسئ، د کټ لاندې ډیر متن شتون لري. موږ امید لرو چې د پوښتنو سره مینځپانګه به تاسو سره په تګ کې مرسته وکړي.
منځپانګې
که تاسو نه غواړئ متن ولولئ، تاسو کولی شئ د غونډو ریکارډ وګورئ . د وخت کوډونه د ویډیو لاندې په لومړي نظر کې دي.
ClickHouse په دوامداره توګه تازه کیږي، مګر زموږ معلومات ندي. په دې اړه څه وکړي؟
ClickHouse په دوامداره توګه تازه کیږي، او زموږ ډاټا، چې وروستی پروسس شوی، تازه شوی نه دی او په بیک اپ کاپي کې دی.
راځئ چې ووایو موږ یو څه ستونزه درلوده او معلومات ورک شوي. موږ د بیا رغولو پریکړه وکړه، او دا معلومه شوه چې زاړه برخې، چې په بیک اپ سرورونو کې زیرمه شوي، د کلک هاؤس اوسنۍ کارول شوي نسخې څخه خورا توپیر لري. په داسې حالت کې څه وکړي، او دا ممکنه ده؟
یو داسې حالت چې تاسو په زاړه بڼه کې د بیک اپ څخه ډاټا بیرته راګرځولې، مګر دا د نوي نسخې سره نښلول ناممکن دي. موږ ډاډ ترلاسه کوو چې په ClickHouse کې د معلوماتو بڼه تل د شاته سره مطابقت لري. دا په فعالیت کې د شاته مطابقت په پرتله خورا مهم دی که چیرې د ځینې نادر کارول شوي فعالیت چلند بدل شوی وي. د ClickHouse نوې نسخه باید تل د دې وړتیا ولري چې هغه معلومات ولولي چې په ډیسک کې زیرمه شوي. دا قانون دی.
د ClickHouse څخه د معلوماتو بیک اپ کولو لپاره اوسني غوره تمرینونه کوم دي؟
د بیک اپ کولو څرنګوالی، په پام کې نیولو سره چې موږ وروستي عملیات غوره کړي، د ټیرابایټ لوی ډیټابیس، او هغه ډاټا چې تازه شوي، ووایه، د تیرو دریو ورځو لپاره، او بیا یې هیڅ ډول پروسیجر نه کیږي؟
موږ کولی شو خپل حل پخپله جوړ کړو او په بش باندې ولیکئ: دا بیک اپ کاپي په داسې ډول راټول کړئ. شاید هیڅ شی ته اړتیا نشته، او بایسکل ډیر پخوا اختراع شوی و؟
راځئ چې د غوره کړنو سره پیل وکړو. زما همکاران تل مشوره ورکوي ، د بیک اپ په اړه پوښتنو ته په ځواب کې ، دوی ته د Yandex.Cloud خدمت په اړه یادونه وکړي ، چیرې چې دا ستونزه دمخه حل شوې. نو د امکان په صورت کې یې وکاروئ.
د بیک اپ لپاره هیڅ بشپړ حل شتون نلري ، سل په سلو کې په کلیک هاوس کې جوړ شوی. دلته ځینې خالي ځایونه شتون لري چې کارول کیدی شي. د بشپړ حل ترلاسه کولو لپاره ، تاسو باید یا په لاسي ډول یو څه ټینکر وکړئ ، یا د سکریپټونو په بڼه ریپرونه جوړ کړئ.
زه به د ساده حلونو سره پیل وکړم او د خورا پیچلي حلونو سره پای ته ورسوم، د ډیټا حجم او د کلستر اندازې پورې اړه لري. هرڅومره چې کلستر لوی وي ، حل خورا پیچلی کیږي.
که چیرې د ډیټا سره میز یوازې یو څو ګیګابایټ ونیسي، بیک اپ په دې ډول ترسره کیدی شي:
- د جدول تعریف خوندي کړئ لکه میټاډاټا - د جوړولو جدول وښایاست.
- د کلک هاؤس پیرودونکي په کارولو سره ډمپ جوړ کړئ - غوره * له میز څخه دوسیه کول. په ډیفالټ تاسو به د TabSeparated بڼه کې یو فایل ترلاسه کړئ. که تاسو غواړئ ډیر اغیزمن اوسئ، تاسو کولی شئ دا په اصلي بڼه کې ترسره کړئ.
که چیرې د معلوماتو مقدار لوی وي ، نو بیک اپ به ډیر وخت او ډیر ځای ونیسي. دې ته منطقي بیک اپ ویل کیږي؛ دا د ClickHouse ډیټا فارمیټ سره تړاو نلري. که دا وي، نو د وروستي ریزورټ په توګه تاسو کولی شئ بیک اپ واخلئ او د بیا رغونې لپاره MySQL ته یې اپلوډ کړئ.
د نورو پرمختللو قضیو لپاره، ClickHouse د محلي فایل سیسټم کې د پارټیشنونو سنیپ شاټ رامینځته کولو وړتیا لري. دا خصوصیت د غوښتنې په توګه شتون لري د جدول منجمد تقسیم بدل کړئ. یا په ساده ډول د میز منجمد بدل کړئ - دا د ټول میز یو عکس دی.
سنیپ شاټ به په دوامداره توګه د یو میز لپاره په یوه شارډ کې رامینځته شي ، دا په دې توګه د ټول کلستر یو ثابت سنیپ شاټ رامینځته کول ناممکن دي. مګر د ډیری کارونو لپاره ورته اړتیا نشته، او دا کافي ده چې په هر شارډ کې غوښتنه اجرا کړئ او یو ثابت سنیپ شاټ ترلاسه کړئ. دا د هارډ لینکونو په بڼه رامینځته شوی او له همدې امله اضافي ځای نه نیسي. بیا، تاسو دا سنیپ شاټ بیک اپ سرور یا هغه ذخیره ته کاپي کړئ چې تاسو یې د بیک اپ لپاره کاروئ.
د داسې بیک اپ بیا رغول خورا اسانه دي. لومړی، د موجوده جدول تعریفونو په کارولو سره میزونه جوړ کړئ. بیا، د دې جدولونو لپاره د برخې خوندي شوي سنیپ شاټونه ډایرکټر - جلا شوي ته کاپي کړئ او پوښتنه پرمخ وړئ برخه ضمیمه کړئ. دا حل د ډیټا خورا جدي حجمونو لپاره خورا مناسب دی.
ځینې وختونه تاسو حتی یخ ته اړتیا لرئ - په هغه حالتونو کې چې تاسو په هر سرور او سلګونو سرورونو کې لسګونه یا حتی په سلګونو ټیرابایټونه لرئ. دلته یو حل شتون لري چې ما د خپلو همکارانو څخه د Yandex.Metrica څخه اخیستی دی. زه به دا ټولو ته وړاندیز نه کړم - دا ولولئ او د ځان لپاره پریکړه وکړئ چې ایا دا مناسب دی که نه.
لومړی تاسو اړتیا لرئ د لوی ډیسک الماریو سره ډیری سرورونه رامینځته کړئ. بیا، په دې سرورونو کې، د کلک هاوس ډیری سرورونه پورته کړئ او دوی یې تنظیم کړئ ترڅو دوی د ورته شارډونو لپاره د بل نقل په توګه کار وکړي. او بیا په دې سرورونو کې د فایل سیسټم یا ځینې وسیله وکاروئ چې تاسو ته اجازه درکوي سنیپ شاټونه رامینځته کړئ. دلته دوه اختیارونه شتون لري. لومړی اختیار د LVM سنیپ شاټونه دي، دوهم اختیار په لینکس کې ZFS دی.
له هغې وروسته، هره ورځ تاسو اړتیا لرئ چې یو سنیپ شاټ جوړ کړئ، دا به دروغ وي او یو څه ځای ونیسي. په طبيعي توګه، که معلومات بدل شي، د ځای اندازه به د وخت په تېرېدو سره زيات شي. دا سنیپ شاټ په هر وخت کې اخیستل کیدی شي او ډاټا بیرته راګرځول کیږي، دا ډول عجیب حل. برسیره پردې، موږ اړتیا لرو چې دا نقلونه په ترتیب کې محدود کړو ترڅو دوی هڅه ونه کړي چې مشران شي.
ایا دا به ممکنه وي چې په شافټونو کې د عکسونو کنټرول شوي وقف تنظیم کړئ؟
سږکال تاسو پلان لرئ چې په کلیک هاوس کې شافټونه جوړ کړئ. ایا دا به امکان ولري چې په دوی کې د عکسونو کنټرول شوي وقف تنظیم کړئ؟ موږ غواړو دا د بدلونونو او نورو بدلونونو سره د منفي سناریوګانو څخه د ځان ساتلو لپاره وکاروو.
ایا دا ممکنه ده چې د بدلونونو لپاره یو ډول رول بیرته ترسره کړئ؟ د مثال په توګه، په موجوده شافټ کې، واخلئ او ووایاست چې تر دې شیبې پورې تاسو بدلونونه پلي کوئ، او له دې شیبې څخه تاسو د بدلونونو پلي کول ودروئ؟
که یو کمانډ زموږ کلستر ته راشي او هغه یې مات کړي، نو موږ د یو ساعت ځنډ سره مشروط نقل لرو، چیرې چې موږ کولی شو ووایو چې دا په اوس وخت کې وکاروو، مګر موږ به د تیرو لسو دقیقو لپاره پدې کې بدلونونه پلي نه کړو؟
لومړی، د نقلونو کنټرول شوي وقفې په اړه. د کاروونکو لخوا ورته غوښتنه وه ، او موږ د غوښتنې سره په ګیتوب کې یوه مسله رامینځته کړه: "که څوک ورته اړتیا ولري ، دا خوښ کړئ ، زړه یې ورکړئ." هېچا ونه سپاره، او مسله بنده شوه. په هرصورت، تاسو کولی شئ دا فرصت د کلک هاؤس په ترتیب کولو سره ترلاسه کړئ. ریښتیا، یوازې د 20.3 نسخه څخه پیل کیږي.
ClickHouse په دوامداره توګه په شاليد کې د معلوماتو ادغام ترسره کوي. کله چې ادغام بشپړ شي، د ډیټا ټوټو یو ټاکلی سیټ د یوې لویې ټوټې سره بدلیږي. په ورته وخت کې، د معلوماتو ټوټې چې مخکې شتون درلود د یو څه وخت لپاره په ډیسک کې پاتې کیږي.
لومړی، دوی تر هغه وخته پورې زیرمه کیږي تر څو چې انتخابي پوښتنې شتون ولري چې دوی یې کاروي، د غیر بلاک کولو عملیات چمتو کولو لپاره. غوره پوښتنې په اسانۍ سره د زړو برخو څخه لوستل کیږي.
دوهم، د وخت حد هم شتون لري - د معلوماتو زاړه ټوټې د اتو دقیقو لپاره په ډیسک کې پرتې دي. دا اته دقیقې دودیز کیدی شي او حتی په یوه ورځ بدلیږي. دا به د ډیسک ځای مصرف کړي: د ډیټا جریان پورې اړه لري ، دا معلومه شوه چې په وروستۍ ورځ کې به ډاټا نه یوازې دوه چنده شي ، دا ممکن پنځه ځله ډیر شي. مګر که کومه جدي ستونزه وي، تاسو کولی شئ د ClickHouse سرور ودروئ او هرڅه تنظیم کړئ.
اوس پوښتنه راپورته کیږي چې دا څنګه د بدلونونو پروړاندې محافظت کوي. دلته د ژور نظر اخیستلو ارزښت لري، ځکه چې د ClickHouse په پخوانیو نسخو کې، بدلون په داسې ډول کار کاوه چې دا په ساده ډول په مستقیم ډول ټوټې بدلوي. د ځینو فایلونو سره د معلوماتو یوه ټوټه شتون لري، او موږ یې کوو، د بیلګې په توګه، د ډراپ کالم بدل کړئ. بیا دا کالم په فزیکي توګه د ټولو برخو څخه لیرې شوی.
مګر د 20.3 نسخه سره پیل کول، د بدلون میکانیزم په بشپړه توګه بدل شوی، او اوس د معلوماتو ټوټې تل د بدلون وړ دي. دوی هیڅ بدلون نه کوي - بدلونونه اوس د یوځای کیدو په څیر کار کوي. په ځای کې د یوې ټوټې د ځای پرځای کولو پر ځای، موږ یو نوی جوړوو. په نوې برخه کې، هغه فایلونه چې نه دي بدل شوي هارډ لینکونه کیږي، او که موږ یو کالم حذف کړو، دا به په ساده ډول په نوې ټوټه کې ورک شي. زوړ ټوټه به د اتو دقیقو وروسته په ډیفالټ ډول حذف شي ، او دلته تاسو کولی شئ پورته ذکر شوي تنظیمات ټیک کړئ.
ورته بدلونونو لکه بدلونونو باندې تطبیق کیږي. کله چې تاسو وکړئ ړنګول بدل کړئ او یا تازه کولدا ټوټه نه بدلوي، مګر یو نوی جوړوي. او بیا زاړه حذف کوي.
که چیرې د میز جوړښت بدل شوی وي نو څه به وي؟
څنګه یو بیک اپ بحال کړئ چې د زاړه سکیم سره جوړ شوی و؟ او دویمه پوښتنه د سنیپ شاټونو او فایل سیسټم وسیلو سره د قضیې په اړه ده. ایا Btrfs دلته په لینکس LVM کې د ZFS پرځای ښه دی؟
که تاسو وکړئ برخه ضمیمه کړئ د مختلف جوړښت سره تقسیم کړئ، نو ClickHouse به تاسو ته ووایي چې دا ممکنه نه ده. دا د حل لاره ده. لومړی دا دی چې د زاړه جوړښت سره د MergeTree ډول لنډمهاله جدول رامینځته کړئ ، د اتصال په کارولو سره ډیټا ضمیمه کړئ ، او د بدلون پوښتنه وکړئ. بیا تاسو کولی شئ دا ډاټا کاپي یا انتقال کړئ او بیا ضمیمه کړئ، یا غوښتنه وکاروئ د جدول حرکت کولو تقسیم بدل کړئ.
اوس دویمه پوښتنه دا ده چې ایا Btrfs کارول کیدی شي. د پیل کولو لپاره، که تاسو LVM لرئ، نو د LVM سنیپ شاټونه کافي دي، او د فایل سیسټم کیدای شي ext4 وي، دا مهمه نده. د Btrts سره، هرڅه د دې کارولو په تجربه پورې اړه لري. دا یو بالغ فایل سیسټم دی، مګر لاهم پدې اړه ځینې شکونه شتون لري چې هر څه به په یوه ځانګړي سناریو کې په عمل کې څنګه کار وکړي. زه به د دې کارولو وړاندیز ونه کړم پرته لدې چې تاسو په تولید کې Btrfs نلرئ.
د معلوماتو د بیا تنظیمولو اوسني غوره کړنې کوم دي؟
د بیا شریکولو مسله پیچلې او څو اړخیزه ده. دلته ډیری احتمالي ځوابونه شتون لري. تاسو کولی شئ د یوې خوا څخه لاړ شئ او دا ووایاست - ClickHouse د جوړ شوي resharding ځانګړتیا نلري. مګر زه ویره لرم چې دا ځواب به د هیچا سره مناسب نه وي. له همدې امله، تاسو کولی شئ له بل لوري لاړ شئ او ووایاست چې ClickHouse د معلوماتو بیا ځای کولو لپاره ډیری لارې لري.
که کلستر د ځای څخه تیریږي یا دا نشي کولی بار اداره کړي، تاسو نوي سرورونه اضافه کړئ. مګر دا سرورونه د ډیفالټ له مخې خالي دي ، په دوی کې هیڅ معلومات شتون نلري ، هیڅ بار شتون نلري. تاسو اړتیا لرئ ډاټا بیا تنظیم کړئ ترڅو دا په مساوي ډول په نوي، لوی کلستر کې خپور شي.
لومړۍ لاره چې دا ترسره کیدی شي د غوښتنې په کارولو سره نوي سرورونو ته د برخې برخې کاپي کول دي د جدول د راوړلو تقسیم بدل کړئ. د مثال په توګه، تاسو د میاشتې لخوا ویشونه درلودل، او تاسو د 2017 لومړۍ میاشت واخلئ او نوي سرور ته یې کاپي کړئ، بیا دریمه میاشت بل نوي سرور ته کاپي کړئ. او تاسو دا تر هغه وخته پورې کوئ چې دا ډیر یا لږ هم شي.
لیږد یوازې د هغو برخو لپاره ترسره کیدی شي چې د ثبت کولو پرمهال نه بدلیږي. د تازه برخو لپاره، ثبت کول باید غیر فعال وي، ځکه چې د دوی لیږد اټومي نه دی. که نه نو، تاسو به په ډاټا کې د نقلونو یا تشو سره پای ته ورسیږئ. په هرصورت، دا طریقه عملي ده او په اغیزمنه توګه کار کوي. چمتو شوي کمپریس شوي برخې په شبکه کې لیږدول کیږي، دا دا دی چې ډاټا نه کمپریس شوي یا بیا کوډ شوي.
دا طریقه یو نیمګړتیا لري، او دا د شارډینګ سکیم پورې اړه لري، ایا تاسو د دې شارډینګ سکیم سره ژمنه کړې، تاسو کوم شارډینګ کیلي لرئ. ستاسو په مثال کې د میټریک سره قضیه کې، د شارډینګ کیلي د لارې هش دی. کله چې تاسو توزیع شوی جدول غوره کړئ، دا په یوځل کې د کلستر ټولو شارډونو ته ځي او له هغه ځایه ډاټا اخلي.
دا پدې مانا ده چې دا واقعیا تاسو ته مهمه نده چې کوم معلومات په کوم شارډ پای ته رسیدلي. اصلي شی دا دی چې د یوې لارې په اوږدو کې ډاټا په یوه شارډ کې پای ته رسیږي، مګر کوم یو مهم نه دی. په دې حالت کې، د چمتو شوي ویشونو لیږد مناسب دی، ځکه چې د انتخاب پوښتنو سره به تاسو بشپړ معلومات هم ترلاسه کړئ - که د بیا شارډ کولو دمخه یا وروسته، سکیم واقعیا مهمه نده.
مګر داسې قضیې شتون لري چې ډیر پیچلي دي. که د غوښتنلیک منطق په کچه تاسو په ځانګړي شارډینګ سکیم تکیه کوئ ، چې دا پیرودونکی په داسې او داسې شارډ کې موقعیت لري ، او غوښتنه مستقیم هلته لیږل کیدی شي ، نه توزیع شوي میز ته. یا تاسو د ClickHouse خورا وروستي نسخه کاروئ او تنظیم یې فعال کړی نه کارول شوي شارډونه غوره کړئ. په دې حالت کې، د انتخاب پوښتنې په جریان کې، د کومې برخې بیان به تحلیل شي او دا به محاسبه شي چې د شارډینګ سکیم سره سم کوم شارډونه کارول کیږي. دا په دې شرط کار کوي چې ډاټا په سمه توګه د دې شارډینګ سکیم سره سم ویشل شوي. که تاسو دوی په لاسي ډول تنظیم کړئ، لیکنه ممکن بدلون ومومي.
نو دا د میتود نمبر لومړی دی. او زه ستاسو ځواب ته په تمه یم، ایا دا طریقه مناسبه ده، یا راځئ چې حرکت وکړو.
ولادیمیر کولوبایف، په Avito کې د سیسټم مشر مدیر: الیکسي، هغه طریقه چې تاسو یې یادونه کړې هغه ډیر ښه کار نه کوي کله چې تاسو د لوستلو په شمول د بار خپرولو ته اړتیا لرئ. موږ کولی شو یوه برخه واخلو چې میاشتنۍ وي او تیره میاشت بل نوډ ته واخلو ، مګر کله چې د دې ډیټا لپاره غوښتنه راشي ، موږ به یې یوازې پورته کړو. مګر موږ غواړو ټول کلستر بار کړو، ځکه چې که نه نو، د یو څه وخت لپاره د لوستلو ټول بار به د دوو شارډونو لخوا پروسس شي.
الیکسي میلویدوف: دلته ځواب عجيب دی - هو، دا خراب دی، مګر دا ممکن کار وکړي. زه به دقیقا تشریح کړم چې څنګه. دا د بار سناریو ته د کتلو ارزښت لري چې ستاسو د معلوماتو شاته راځي. که دا د څارنې ډاټا وي، نو موږ تقریبا یقینا ووایو چې ډیری غوښتنې د تازه معلوماتو لپاره دي.
تاسو نوي سرورونه نصب کړل، زاړه برخې یې لیږدولې، مګر دا هم بدل شوي چې تازه معلومات څنګه ثبت کیږي. او تازه معلومات به په ټول کلستر کې خپاره شي. په دې توګه، یوازې پنځه دقیقې وروسته، د تیرو پنځو دقیقو غوښتنې به په مساوي ډول کلستر بار کړي؛ د یوې ورځې وروسته، د XNUMX ساعتونو غوښتنې به په مساوي ډول کلستر بار کړي. او د تیرې میاشتې غوښتنې، له بده مرغه، یوازې د کلستر سرورونو برخې ته ځي.
مګر ډیری وختونه تاسو به په ځانګړي ډول د فبروري 2019 لپاره غوښتنې ونه لرئ. ډیری احتمال، که غوښتنې 2019 ته لاړې شي، نو بیا به دوی د ټول 2019 لپاره وي - د یوې لویې مودې لپاره، او نه د ځینې کوچنۍ لړۍ لپاره. او دا ډول غوښتنې به په مساوي ډول د کلسټر بار کولو وړ وي. مګر په عموم کې، ستاسو تبصره په بشپړه توګه سمه ده چې دا یو اډ هاک حل دی چې ډاټا په بشپړ ډول مساوي نه خپروي.
زه د پوښتنې ځواب لپاره یو څو نور ټکي لرم. یو له دوی څخه د دې په اړه دی چې څنګه په پیل کې د شارډینګ سکیم ډیزاین کړئ ترڅو بیا شارډ کول د لږ درد لامل شي. دا تل ممکنه نه ده.
د مثال په توګه، تاسو د څارنې ډاټا لرئ. د معلوماتو څارنه د دریو دلیلونو لپاره وده کوي. لومړی د تاریخي معلوماتو راټولول دي. دوهم د ترافیک وده ده. او دریم د هغو شیانو په شمیر کې زیاتوالی دی چې د څارنې تابع دي. دلته نوي مایکرو خدمتونه او میټریکونه شتون لري چې باید خوندي شي.
دا ممکنه ده چې له دې څخه، ترټولو لوی زیاتوالی د دریم دلیل سره تړاو لري - د څارنې کارولو زیاتوالی. او پدې حالت کې ، دا د بار نوعیت ته د کتلو ارزښت لري ، اصلي انتخاب پوښتنې څه دي. لومړني انتخابي پوښتنې به ډیری احتمال د میټریکونو ځینې فرعي سیټ پراساس وي.
د مثال په توګه، د ځینو خدماتو لخوا په ځینو سرورونو کې د CPU کارول. دا معلومه شوه چې د کیلي یو ځانګړی فرعي سیټ شتون لري چې تاسو یې دا ډاټا ترلاسه کوئ. او پخپله د دې ډیټا لپاره غوښتنه خورا احتمال خورا ساده ده او په لسګونو ملی ثانیو کې بشپړیږي. د څارنې خدماتو او ډشبورډونو لپاره کارول کیږي. زه امید لرم چې زه دا په سمه توګه پوهیږم.
ولادیمیر کولوبایف: حقیقت دا دی چې موږ ډیری وختونه د تاریخي معلوماتو غوښتنه کوو، ځکه چې موږ اوسنی وضعیت په ریښتیني وخت کې د تاریخي سره پرتله کوو. او دا زموږ لپاره مهم دی چې ډیری ډیټا ته ګړندي لاسرسی ولرو ، او کلیک هاوس د دې سره عالي دنده ترسره کوي.
تاسو بالکل سم یاست، موږ په وروستۍ ورځ کې د هر ډول څارنې سیسټم په څیر د لوستلو ډیری غوښتنې تجربه کوو. مګر په ورته وخت کې، د تاریخي معلوماتو بار هم خورا لوی دی. دا اساسا د خبرتیا سیسټم څخه دی چې شاوخوا دېرش ثانیې تیریږي او کلیک هاوس ته وايي: "ما ته د تیرو شپږو اونیو لپاره معلومات راکړئ. اوس ما له دوی څخه یو ډول حرکت اوسط جوړ کړئ، او راځئ چې اوسنی ارزښت له تاریخي ارزښت سره پرتله کړو.
زه غواړم ووایم چې د دې وروستي غوښتنو لپاره موږ یو بل کوچنی میز لرو چې پکې موږ یوازې دوه ورځې ډیټا ذخیره کوو ، او اصلي غوښتنې پدې کې تیریږي. موږ یوازې لوی تاریخي پوښتنې لوی ټوټه شوي میز ته لیږو.
الیکسي میلویدوف: له بده مرغه، دا ستاسو د سناریو لپاره ضعیفه پلي کیږي، مګر زه به تاسو ته د دوو خراب او پیچلي شارډینګ سکیمونو توضیحات درکړم چې کارولو ته اړتیا نلري، مګر زما د ملګرو په خدمت کې کارول کیږي.
د Yandex.Metrica پیښو سره یو اصلي کلستر شتون لري. پیښې د پاڼې لیدونه، کلیکونه، او تبادلې دي. ډیری غوښتنې یو ځانګړي ویب پاڼې ته ځي. تاسو د Yandex.Metrica خدمت پرانیزئ، تاسو ویب پاڼه لرئ - avito.ru، راپور ته لاړ شئ، او ستاسو د ویب پاڼې لپاره غوښتنه کیږي.
مګر نورې غوښتنې شتون لري - تحلیلي او نړیوال - چې د داخلي شنونکو لخوا رامینځته شوي. یوازې په هغه حالت کې، زه یادونه کوم چې داخلي شنونکي یوازې د Yandex خدماتو لپاره غوښتنې کوي. مګر سره له دې، حتی د Yandex خدمتونه د ټولو معلوماتو د پام وړ برخه نیسي. دا غوښتنې د ځانګړو کاونټرو لپاره ندي، مګر د پراخ فلټر کولو لپاره.
ډاټا څنګه په داسې ډول تنظیم کړئ چې هرڅه د یو کاونټر لپاره په مؤثره توګه کار کوي، او نړیوالې پوښتنې هم؟ بله ستونزه دا ده چې د میټریک کلستر لپاره په کلیک هاوس کې د غوښتنو شمیر په هر ثانیه کې څو زره دی. په ورته وخت کې، د ClickHouse یو سرور نشي کولی غیر معمولی غوښتنې اداره کړي، د بیلګې په توګه، په هر ثانیه کې څو زره.
د کلستر اندازه شپږ سوه - یو څه سرورونه دي. که تاسو په ساده ډول په دې کلستر کې توزیع شوی میز راوباسئ او هلته څو زره غوښتنې واستوئ، نو دا به د یو سرور ته د لیږلو په پرتله خورا خراب شي. له بلې خوا، هغه اختیار چې ډاټا په مساوي ډول خپریږي، او موږ ځو او د ټولو سرورونو څخه غوښتنه کوو، سمدلاسه ګوښه کیږي.
یو اختیار شتون لري چې په متضاد ډول دی. تصور وکړئ که موږ په سایټونو کې ډاټا شریک کړو، او د یوې سایټ لپاره غوښتنه یو شارډ ته ځي. اوس کلستر به وکولی شي په یوه ثانیه کې لس زره غوښتنې اداره کړي ، مګر په یوه شارډ کې به یوه غوښتنه خورا ورو کار وکړي. دا به نور د throughput په شرایطو کې اندازه ونکړي. په ځانګړې توګه که دا سایټ avito.ru وي. زه به راز ښکاره نه کړم که زه ووایم چې Avito په RuNet کې یو له خورا لیدل شوي سایټونو څخه دی. او په یوه ټوټه یې پروسس کول به جنون وي.
له همدې امله ، د شارډینګ سکیم په ډیر چالاک ډول ډیزاین شوی. ټول کلستر په څو کلسترونو ویشل شوي، چې موږ یې پرتونه بولو. هر کلستر له یو درجن څخه تر څو درجن شارډونه لري. په مجموع کې دغه ډول نهه دېرش کلسترونه شتون لري.
دا ټول څنګه اندازه کوي؟ د کلسترونو شمیر نه بدلیږي - لکه څنګه چې څو کاله وړاندې نهه دېرش وو، همداسې پاتې دي. مګر د دوی په هر یو کې، موږ په تدریجي ډول د شارډونو شمیر ډیروو ځکه چې موږ ډاټا راټولوو. او په ټوله کې د شارډینګ سکیم داسې دی: دا کلسترونه په ویب پاڼو ویشل شوي، او د دې لپاره چې پوه شي چې کومه ویب پاڼه په کوم کلستر کې ده، په MySQL کې یو جلا میټابیس کارول کیږي. یو سایټ - په یوه کلستر کې. او د هغې دننه، د لیدونکي IDs مطابق شارډینګ واقع کیږي.
کله چې ثبت کول، موږ دوی د لیدونکي ID د ویش پاتې برخې لخوا ویشو. مګر کله چې یو نوی شارډ اضافه کړئ ، د شارډینګ سکیم بدلیږي؛ موږ ویشلو ته دوام ورکوو ، مګر د بلې شمیرې لخوا د ویش پاتې پاتې کیدو سره. دا پدې مانا ده چې یو لیدونکی لا دمخه په څو سرورونو کې موقعیت لري، او تاسو نشئ کولی پدې تکیه وکړئ. دا یوازې د دې لپاره ترسره کیږي چې ډاډ ترلاسه شي چې معلومات ښه کمپرس شوي دي. او کله چې غوښتنې وکړو، موږ توزیع شوي میز ته ځو، کوم چې کلستر ته ګوري او په لسګونو سرورونو ته لاسرسی لري. دا دومره احمقانه سکیم دی.
مګر زما کیسه به نیمګړې وي که زه دا ونه وایم چې موږ دا سکیم پریښود. په نوي سکیم کې، موږ هرڅه بدل کړل او ټول معلومات د کلک هاؤس کاپیر په کارولو سره کاپي کړل.
په نوي سکیم کې، ټول سایټونه په دوو کټګوریو ویشل شوي - لوی او کوچني. زه نه پوهیږم چې حد څنګه غوره شوی، مګر پایله دا وه چې لوی سایټونه په یوه کلستر کې ثبت شوي، چیرته چې 120 شارډونه شتون لري چې هر یو یې درې نقلونه لري - دا 360 سرورونه دي. او د شارډینګ سکیم داسې دی چې هره غوښتنه په یوځل کې ټولو شارډونو ته ځي. که تاسو اوس په Yandex.Metrica کې د avito.ru لپاره کوم راپور پاڼه پرانیزئ، غوښتنه به 120 سرورونو ته لاړ شي. په RuNet کې لږ لوی سایټونه شتون لري. او غوښتنې په هره ثانیه کې زر نه دي، مګر حتی د سلو څخه کم دي. دا ټول په خاموشۍ سره د توزیع شوي میز لخوا ژاول شوي، کوم چې هر یو یې د 120 سرورونو سره پروسس کوي.
او دوهم کلستر د کوچنیو سایټونو لپاره دی. دلته د سایټ ID پراساس د شارډینګ سکیم دی ، او هره غوښتنه دقیقا یو شارډ ته ځي.
ClickHouse د کلک هاؤس-کاپير اسانتیا لري. ایا تاسو کولی شئ ما د هغې په اړه ووایاست؟
زه به سمدلاسه ووایم چې دا حل ډیر پیچلی او یو څه لږ ګټور دی. ګټه دا ده چې دا ډاټا په بشپړ ډول د هغه نمونې سره سم چې تاسو یې مشخص کوئ. مګر د افادیت نیمګړتیا دا ده چې دا په هیڅ ډول نه تکراریږي. دا د یو کلستر سکیما څخه بل کلستر سکیما ته ډاټا کاپي کوي.
دا پدې مانا ده چې د دې کار کولو لپاره تاسو باید دوه کلسترونه ولرئ. دوی کولی شي په ورته سرورونو کې موقعیت ولري، مګر، سره له دې، ډاټا به په تدریجي ډول نه لیږدول کیږي، مګر کاپي کیږي.
د مثال په توګه، څلور سرورونه وو، اوس اته دي. تاسو په ټولو سرورونو کې یو نوی توزیع شوی جدول جوړ کړئ، نوي محلي میزونه او د کلک هاؤس کاپير پیل کړئ، په دې کې د کار سکیم په ګوته کوي چې دا باید له هغه ځایه ولوستل شي، د نوي شارډینګ سکیم ومني او هلته ډاټا انتقال کړي. او په زړو سرورونو کې به تاسو د اوس په پرتله یو نیم چنده ډیر ځای ته اړتیا ولرئ ، ځکه چې زاړه ډیټا باید په دوی کې پاتې شي ، او د ورته زاړه ډیټا نیمایي به د دوی په سر کې راشي. که تاسو دمخه فکر کاوه چې ډاټا باید بیاځل شي او ځای شتون ولري، نو دا طریقه مناسبه ده.
د کلک هاؤس کاپیر دننه څنګه کار کوي؟ دا ټول کارونه په یوه شارډ کې د یو میز د یوې برخې پروسس کولو لپاره د دندو په سیټ کې ماتوي. دا ټولې دندې په موازي ډول اجرا کیدی شي ، او د کلیک هاوس کاپير په ډیری مواردو کې په مختلف ماشینونو کې پرمخ وړل کیدی شي ، مګر هغه څه چې دا د یوې برخې لپاره کوي د داخل کولو انتخاب پرته بل څه ندي. ډاټا لوستل کیږي، کمپریشن شوی، بیا ویشل شوی، بیا بیا بیا کمپریس شوی، چیرته لیکل شوی، او بیا ترتیب شوی. دا یوه سخته پریکړه ده.
تاسو یو ازمایښتي شی درلود چې د resharding په نوم یادیږي. د هغې سره څه؟
بیرته په 2017 کې، تاسو یو پیلوټ شی درلود چې د ریشیرډینګ په نوم یادیږي. په ClickHouse کې حتی یو اختیار شتون لري. لکه څنګه چې زه پوهیږم، دا یې نه دی اخیستی. ایا تاسو کولی شئ ما ته ووایاست چې دا ولې پیښ شوي؟ دا خورا اړونده ښکاري.
ټوله ستونزه دا ده چې که چیرې دا اړینه وي چې ډاټا په ځای کې بیا ځای پرځای شي، نو په اټومي ډول د دې کولو لپاره خورا پیچلي همغږي ته اړتیا ده. کله چې موږ وګورو چې دا همغږي څنګه کار کوي، دا څرګنده شوه چې بنسټیزې ستونزې شتون لري. او دا بنسټیزې ستونزې نه یوازې نظري دي، مګر سمدلاسه په عمل کې د یو څه په بڼه ځان ښکاره کول پیل کړل چې په ساده ډول تشریح کیدی شي - هیڅ کار نه کوي.
ایا دا ممکنه ده چې د ډیټا ټولې برخې یوځای سره یوځای کړئ مخکې لدې چې ورو ډیسکونو ته یې حرکت ورکړئ؟
د ادغام په شرایطو کې د سست ډیسک اختیار ته حرکت سره د TTL په اړه پوښتنه. ایا د کرون له لارې پرته بله لاره شتون لري چې ټولې برخې په یوه کې یوځای کړي مخکې لدې چې ورو ډیسکونو ته یې حرکت وکړي؟
د پوښتنې ځواب دا دی چې دا ممکنه ده چې په یو ډول په اتوماتيک ډول ټولې ټوټې د لیږدولو دمخه په یوه کې وخورئ - نه. زه فکر نه کوم چې دا اړین دی. تاسو اړتیا نلرئ ټولې برخې په یوه کې ضم کړئ ، مګر په ساده ډول پدې حقیقت باندې حساب وکړئ چې دوی به په اوتومات ډول سست ډیسکونو ته لیږدول کیږي.
موږ د لیږد قواعدو لپاره دوه معیارونه لرو. لومړی هغه دی لکه څنګه چې ډک شوی. که چیرې د ذخیره کولو اوسنۍ کچه له ټاکلې سلنې څخه کم خالي ځای ولري، موږ یوه ټوټه غوره کوو او ورو ذخیره ته یې لیږدوو. یا بلکه، ورو نه، مګر راتلونکی - لکه څنګه چې تاسو تنظیم کړئ.
دوهم معیار اندازه ده. دا د لویو ټوټو حرکت کولو په اړه دی. تاسو کولی شئ په ګړندي ډیسک کې د وړیا ځای سره سم حد تنظیم کړئ ، او ډاټا به په اوتومات ډول لیږدول کیږي.
د ClickHouse نوي نسخو ته د مهاجرت څرنګوالی که چیرې مخکې له مخکې د مطابقت چک کولو لپاره کومه لاره شتون ونلري؟
دا موضوع په منظمه توګه بحث کیږي د مختلفو نسخو په پام کې نیولو سره، او لاهم. له 19.11 څخه تر 19.16 نسخې پورې او د مثال په توګه له 19.16 څخه تر 20.3 پورې اپ گریڈ کول څومره خوندي دي. نوي نسخو ته د مهاجرت غوره لاره کومه ده پرته لدې چې مخکې له مخکې په سینڈ باکس کې مطابقت چیک کړئ؟
دلته ډیری "طلایی" قواعد شتون لري. لومړی - . دا لوی دی، مګر د شاته غیر متقابل بدلونونو په اړه جلا پراګرافونه شتون لري. دا ټکي د سور بیرغ په توګه مه اخلئ. دا معمولا کوچني ناانډولتیاوې دي چې د څنډې ځینې فعالیت پکې شامل دي چې تاسو یې احتمال نه کاروئ.
دوهم ، که چیرې په سینڈ باکس کې د مطابقت چک کولو لپاره کومه لاره شتون ونلري ، او تاسو غواړئ سمدلاسه په تولید کې تازه کړئ ، سپارښتنه دا ده چې تاسو دې ته اړتیا نلرئ. لومړی د شګو بکس جوړ کړئ او ازموینه وکړئ. که چیرې د ازموینې چاپیریال شتون ونلري ، نو تاسو ډیری احتمال ډیر لوی شرکت نلرئ ، پدې معنی چې تاسو کولی شئ ځینې ډیټا خپل لپ ټاپ ته کاپي کړئ او ډاډ ترلاسه کړئ چې هرڅه پدې کې سم کار کوي. تاسو حتی کولی شئ په خپل ماشین کې په ځایی ډول ډیری نقلونه پورته کړئ. یا تاسو کولی شئ په نږدې ځای کې نوې نسخه غوره کړئ او هلته ځینې ډاټا اپلوډ کړئ - دا د ازموینې اصلاح شوي چاپیریال رامینځته کړئ.
بله قاعده دا ده چې د نسخې له خپریدو وروسته د یوې اونۍ لپاره تازه نه شي ځکه چې په تولید کې د بګونو نیولو او ورپسې ګړندي اصلاحات. راځئ چې د ClickHouse نسخو شمیره معلومه کړو ترڅو مغشوش نه شي.
20.3.4 نسخه شتون لري. 20 شمیره د تولید کال په ګوته کوي - 2020. د هغه څه له نظره چې دننه دي ، دا مهمه نده ، نو موږ به ورته پام ونه کړو. بل - 20.3. موږ دویمه شمیره لوړه کوو - پدې حالت کې 3 - هرکله چې موږ د یو څه نوي فعالیت سره خوشې کول. که موږ غواړو په ClickHouse کې ځینې ځانګړتیاوې اضافه کړو، موږ باید دا شمیر زیات کړو. دا دی، په 20.4 نسخه کې ClickHouse به لا ښه کار وکړي. دریم عدد 20.3.4 دی. دلته 4 د پیچ ریلیزونو شمیر دی په کوم کې چې موږ نوي ب featuresې ندي اضافه کړي ، مګر ځینې بګونه مو حل کړي. او 4 پدې معنی چې موږ دا څلور ځله وکړل.
فکر مه کوئ چې دا یو څه وحشتناک دی. معمولا کارونکي کولی شي وروستی نسخه نصب کړي او دا به په کال کې د اپټایم سره پرته له کومې ستونزې کار وکړي. مګر تصور وکړئ چې د بټ میپ پروسس کولو لپاره په ځینې فعالیت کې ، کوم چې زموږ د چینایي ملګرو لخوا اضافه شوي ، سرور د غلط دلیلونو په تیریدو سره خرابیږي. موږ د دې د سمولو مسؤلیت لرو. موږ به یو نوی پیچ نسخه خپور کړو او کلیک هاوس به ډیر مستحکم شي.
که تاسو د ClickHouse په تولید کې روان یاست، او د ClickHouse نوې نسخه د اضافي ځانګړتیاو سره راځي - د بیلګې په توګه، 20.4.1 خورا لومړی دی، په لومړۍ ورځ یې تولید ته د اچولو لپاره بیړه مه کوئ. ولې حتی اړتیا ده؟ که تاسو دمخه د ClickHouse نه کاروئ ، نو تاسو کولی شئ دا نصب کړئ ، او ډیری احتمال به هرڅه سم وي. مګر که کلیک هاوس دمخه په ثابت ډول کار کوي ، نو بیا پیچونو او تازه معلوماتو ته پام وکړئ ترڅو وګورئ چې موږ کومې ستونزې حل کوو.
کریل شواکوف: زه غواړم د ازموینې چاپیریال په اړه لږ څه اضافه کړم. هرڅوک د ازموینې چاپیریال څخه ډیر ویره لري او د ځینې دلیلونو لپاره دوی پدې باور دي چې که تاسو خورا لوی کلیک هاؤس کلستر لرئ نو د ازموینې چاپیریال باید لږ یا لږ تر لږه لس ځله کوچنی نه وي. دا په هیڅ ډول داسې نه ده.
زه کولی شم تاسو ته د خپل مثال څخه ووایم. زه یوه پروژه لرم، او دلته ClickHouse شتون لري. زموږ د ازموینې چاپیریال یوازې د هغه لپاره دی - دا په هیټزنر کې د شل یورو لپاره یو کوچنی مجازی ماشین دی ، چیرې چې هرڅه په بشپړ ډول ځای په ځای شوي. د دې کولو لپاره ، موږ په ځواب کې بشپړ اتومات لرو ، او له همدې امله ، په اصولو کې ، دا هیڅ توپیر نلري چې چیرې لاړشئ - هارډویر سرورونو ته یا یوازې په مجازی ماشینونو کې ځای په ځای کړئ.
څه شی کیدی شي؟ دا به ښه وي چې د ClickHouse اسنادو کې یو مثال وړاندې کړئ چې څنګه په خپل کور کې یو کوچنی کلستر ځای په ځای کړئ - په ډاکر کې، په LXC کې، شاید د ځواب وړ لوبې کتاب جوړ کړئ، ځکه چې مختلف خلک مختلف ګمارنې لري. دا به ډیر ساده کړي. کله چې تاسو په پنځو دقیقو کې یو کلستر واخلئ او ځای په ځای کړئ، نو دا خورا اسانه ده چې د یو څه پیژندلو هڅه وکړئ. دا خورا ډیر اسانه دی ، ځکه چې د تولید نسخه ته فشار ورکول چې تاسو یې ندي ازمول شوي د هیڅ ځای لپاره سړک دی. ځینې وختونه دا کار کوي او ځینې وختونه دا نه کوي. او له همدې امله، د بریالیتوب هیله بده ده.
ماکسیم کوتیاکوف، لوړ پوړی انجنیر ایویټو: زه به د لوی شرکتونو لخوا د ستونزو له لړۍ څخه د ازموینې چاپیریال په اړه یو څه اضافه کړم. موږ د کلک هاوس منلو بشپړ کلستر لرو؛ د ډیټا سکیمونو او تنظیماتو شرایطو کې ، دا د هغه څه دقیق کاپي ده چې په تولید کې دي. دا کلستر د لږ تر لږه منابعو سره په کافي اندازه په کانټینرونو کې ځای پر ځای شوی دی. موږ هلته د تولید ډیټا یوه ټاکلې سلنه لیکو ، له نېکه مرغه دا امکان لري چې په کافکا کې جریان تکرار کړئ. دلته هرڅه همغږي شوي او اندازه شوي دي - دواړه د ظرفیت او جریان له مخې ، او په تیوري کې ، نور ټول شیان مساوي دي ، دا باید د میټریکونو له مخې د تولید په څیر چلند وکړي. هرڅه چې احتمالي چاودیدونکي وي لومړی په دې سټینډ کې اچول کیږي او د څو ورځو لپاره چمتو کیږي. مګر په طبیعي توګه، دا حل ګران، ستونزمن او غیر صفر ملاتړ لګښت لري.
الیکسي میلویدوف: زه به تاسو ته ووایم چې د Yandex.Metrica څخه زموږ د ملګرو د ازموینې چاپیریال څه ډول دی. یو کلستر 600-بې ساري سرورونه درلودل، بل یې 360 درلودل، او دریم او څو کلسترونه شتون لري. د دوی د یوې لپاره د ازموینې چاپیریال په ساده ډول دوه شارډونه دي چې په هر یو کې دوه نقلونه لري. ولې دوه ټوټې؟ نو تاسو یوازې نه یاست. او دلته باید نقلونه هم وي. یوازې یو ټاکلی لږترلږه مقدار چې تاسو یې کولی شئ.
دا ازموینې چاپیریال تاسو ته اجازه درکوي چې وګورئ چې ستاسو پوښتنې کار کوي او که کوم لوی مات شوی وي. مګر ډیری وختونه ستونزې د بشپړ مختلف طبیعت څخه رامینځته کیږي ، کله چې هرڅه کار کوي ، مګر په بار کې ځینې کوچني بدلونونه شتون لري.
اجازه راکړئ تاسو ته یو مثال درکړم. موږ پریکړه وکړه چې د ClickHouse نوې نسخه نصب کړو. دا د ازموینې چاپیریال کې ځړول شوی، اتوماتیک ازموینې پخپله په Yandex.Metrica کې بشپړ شوي، کوم چې په زاړه نسخه او نوي نسخه کې ډاټا پرتله کوي، ټول پایپ لاین چلوي. او البته، زموږ د CI شنه ازموینې. که نه نو موږ به حتی دا نسخه وړاندیز نه وای کړې.
هر څه سم دي. موږ تولید ته حرکت پیل کوو. زه یو پیغام ترلاسه کوم چې په ګرافونو کې بار څو ځله ډیر شوی. موږ نسخه بیرته راګرځوو. زه ګراف ته ګورم او ګورم: بار په حقیقت کې د رول آوټ په جریان کې څو ځله ډیر شوی ، او کله چې دوی راوتلی بیرته راټیټ شو. بیا موږ نسخه بیرته راګرځول پیل کړل. او بار په همدې ډول زيات شو او بېرته په هماغه ډول ښکته شو. نو پایله دا ده: بار د ترتیب له امله ډیر شوی، هیڅ حیرانتیا نشته.
بیا دا ستونزمنه وه چې همکاران قانع کړي چې نوې نسخه نصب کړي. زه وايم: "ښه ده، راوګرځئ. خپلې ګوتې تیرې وساتئ، هرڅه به کار وکړي. اوس په ګرافونو کې بار ډیر شوی، مګر هرڅه سم دي. هلته یی ځوړند کړه." په عموم کې، موږ دا وکړل، او دا دی - نسخه د تولید لپاره خپره شوه. مګر نږدې د هر ترتیب سره ورته ستونزې رامینځته کیږي.
د وژنې پوښتنې باید پوښتنې ووژني، مګر داسې نه کیږي. ولې؟
یو کارن، یو ډول شنونکی، ما ته راغی او یوه غوښتنه یې جوړه کړه چې زما د ClickHouse کلستر یې واچوله. ځینې نوډ یا ټول کلستر، پدې پورې اړه لري چې کوم نقل یا شارډ غوښتنه شوې. زه ګورم چې په دې سرور کې د CPU ټولې سرچینې په شیلف کې دي، هرڅه سور دي. په ورته وخت کې، ClickHouse پخپله غوښتنو ته ځواب ورکوي. او زه لیکم: "مهرباني وکړئ ما ته وښایاست، د پروسې لیست، کومې غوښتنې دا جنون رامینځته کړی."
زه دا غوښتنه ومومم او د وژلو لپاره یې لیکم. او زه ګورم چې هیڅ شی نه کیږي. زما سرور په شیلف کې دی، کلیک هاوس بیا ماته ځینې امرونه راکوي، ښیې چې سرور ژوندی دی، او هرڅه عالي دي. مګر زه د کارونکي په ټولو غوښتنو کې تخریب لرم ، تخریب په کلیک هاوس کې د ریکارډونو سره پیل کیږي ، او زما د وژنې پوښتنه کار نه کوي. ولې؟ ما فکر کاوه چې د وژنې پوښتنې باید پوښتنې ووژني، مګر داسې نه کیږي.
اوس به یو عجیب ځواب وي. خبره دا ده چې د وژنې پوښتنې پوښتنې نه وژني.
د وژنې پوښتنې یو کوچنی بکس چیک کوي چې "زه غواړم دا پوښتنه ووژل شي." او غوښتنه پخپله دا بیرغ ګوري کله چې د هر بلاک پروسس کوي. که دا تنظیم شوی وي، غوښتنه کار کوي. دا معلومه شوه چې هیڅوک غوښتنه نه وژني، هغه باید پخپله هرڅه وګوري او ودروي. او دا باید په ټولو قضیو کې کار وکړي چیرې چې غوښتنه د ډیټا بلاکس پروسس کولو حالت کې وي. دا به د معلوماتو راتلونکی بلاک پروسس کړي، بیرغ وګوري، او ودروي.
دا په هغو قضیو کې کار نه کوي چیرې چې غوښتنه په ځینو عملیاتو کې بنده شوې وي. ریښتیا، ډیری احتمال دا ستاسو قضیه نده، ځکه چې ستاسو په وینا، دا د ټن سرور سرچینې کاروي. دا ممکنه ده چې دا د بهرني ترتیب او ځینې نورو توضیحاتو په صورت کې کار نه کوي. مګر په عموم کې دا باید پیښ نشي، دا یوه ستونزه ده. او یوازینی شی چې زه یې وړاندیز کولی شم د ClickHouse تازه کول دي.
د لوستلو بار لاندې د غبرګون وخت څنګه محاسبه کړئ؟
دلته یو میز شتون لري چې د توکو مجموعه ذخیره کوي - مختلف کاونټرونه. د لیکو شمیر نږدې سل ملیون دی. ایا دا ممکنه ده چې د وړاندوینې وړ ځواب وخت حساب کړئ که تاسو د 1K توکو لپاره 1K RPS واچوئ؟
د شرایطو په پام کې نیولو سره، موږ د لوستلو بار په اړه خبرې کوو، ځکه چې د لیکلو سره کومه ستونزه شتون نلري - حتی زر، حتی سل زره، او ځینې وختونه څو ملیون قطارونه داخل کیدی شي.
د لوستلو غوښتنې خورا توپیر لري. په 1 انتخاب کې، ClickHouse کولی شي په هره ثانیه کې لسګونه زره غوښتنې ترسره کړي، نو حتی د یوې کیلي لپاره غوښتنې به دمخه ځینې سرچینو ته اړتیا ولري. او دا ډول ټکي پوښتنې به د ځینې کلیدي ارزښت ډیټابیسونو په پرتله خورا ستونزمن وي ، ځکه چې د هر لوستلو لپاره دا اړینه ده چې د شاخص په واسطه د ډیټا بلاک ولولئ. زموږ شاخص هر ریکارډ نه، بلکې هر سلسله په ګوته کوي. دا دی، تاسو باید ټوله سلسله ولولئ - دا په ډیفالټ 8192 لینونه دي. او تاسو باید د 64 KB څخه تر 1 MB پورې د کمپریس شوي ډیټا بلاک ډیکمپریس کړئ. عموما، دا ډول هدف شوي پوښتنې د بشپړولو لپاره څو ملی ثانیې وخت نیسي. مګر دا ترټولو ساده اختیار دی.
راځئ چې یو څه ساده ریاضي هڅه وکړو. که تاسو څو ملیسیکنډونه په زره سره ضرب کړئ، تاسو څو ثانیې ترلاسه کوئ. دا لکه څنګه چې په هره ثانیه کې د زرو غوښتنو سره ساتل ناممکن دي، مګر په حقیقت کې دا ممکنه ده، ځکه چې موږ ډیری پروسیسر کورونه لرو. نو، په اصولو کې، ClickHouse کله ناکله 1000 RPS لري، مګر د لنډو غوښتنو لپاره، په ځانګړې توګه په نښه شوي.
که تاسو اړتیا لرئ د ساده غوښتنو شمیر له مخې د کلیک هاوس کلستر اندازه کړئ ، نو زه ترټولو ساده شی وړاندیز کوم - د نقلونو شمیر زیات کړئ او تصادفي عکس ته غوښتنې واستوئ. که یو نقل په هره ثانیه کې پنځه سوه غوښتنې ولري، کوم چې په بشپړ ډول واقعیت لري، نو درې نقلونه به یو نیم زره اداره کړي.
ځینې وختونه، البته، تاسو کولی شئ د ډیری ټکي لوستلو لپاره کلیک هاوس تنظیم کړئ. د دې لپاره څه ته اړتیا ده؟ لومړی دا دی چې د شاخص د کثافاتو کمول. په دې حالت کې، دا باید یو ته راټیټ نه شي، مګر په دې اساس چې په شاخص کې د ننوتلو شمیر به په هر سرور کې څو ملیون یا لسګونه ملیونه وي. که چیرې جدول سل ملیونه قطارونه ولري، نو بیا د ګرانوالی 64 ته ټاکل کیدی شي.
تاسو کولی شئ د فشار شوي بلاک اندازه کمه کړئ. د دې لپاره ترتیبات شتون لري د کمپریشن بلاک اندازه, د اعظمي کمپریس بلاک اندازه. دوی کولی شي کم شي، د معلوماتو سره ډک شي، او بیا په نښه شوي پوښتنې به چټکې وي. مګر بیا هم، ClickHouse د کلیدي ارزښت ډیټابیس ندی. د وړو غوښتنو لوی شمیر د بار ضد پیټرن دی.
کریل شواکوف: زه به مشوره درکړم که چیرې عادي حسابونه شتون ولري. دا یو مناسب معیاري حالت دی کله چې ClickHouse یو ډول کاونټر ذخیره کوي. زه یو کارن لرم، هغه د داسې یو هیواد څخه دی، او د دریمې برخې څخه دی، او زه اړتیا لرم چې په تدریجي ډول یو څه زیات کړم. MySQL واخلئ، یو ځانګړی کیلي جوړه کړئ - په MySQL کې دا یو نقل کیلي ده، او په PostgreSQL کې دا یو شخړه ده - او د جمع نښه اضافه کړئ. دا به ډیر ښه کار وکړي.
کله چې تاسو ډیر معلومات نلرئ، نو د ClickHouse په کارولو کې ډیر څه شتون نلري. منظم ډیټابیسونه شتون لري او دوی دا ښه کوي.
زه په ClickHouse کې څه شی کولی شم چې نور معلومات په کیچ کې وي؟
راځئ چې یو وضعیت تصور کړو - سرورونه 256 GB رام لري، په ورځني معمول کې کلیک هاوس شاوخوا 60-80 GB وخت نیسي، په لوړه کچه - تر 130 پورې. څه شی فعال او ټیک کیدی شي ترڅو ډیر معلومات په زیرمه کې وي او په وینا یې، ډیسک ته لږ سفرونه شتون لري؟
عموما، د عملیاتي سیسټم پاڼې کیچ د دې لپاره ښه دنده ترسره کوي. که تاسو یوازې سر خلاص کړئ ، هلته کیچ یا وړیا وګورئ - دا هم وايي چې څومره کیچ شوی - نو تاسو به وګورئ چې ټول وړیا حافظه د کیچ لپاره کارول کیږي. او کله چې دا ډاټا لوستل، دا به د ډیسک څخه نه لوستل کیږي، مګر د رام څخه. په ورته وخت کې ، زه کولی شم ووایم چې کیچ په مؤثره توګه کارول کیږي ځکه چې دا کمپریس شوي ډیټا دي چې زیرمه شوي.
په هرصورت، که تاسو غواړئ یو څه ساده پوښتنې نور هم ګړندۍ کړئ، نو دا ممکنه ده چې د کلیک هاؤس دننه د ډیمپریس شوي ډاټا کې کیچ فعال کړئ. دې ته وایې غیر کمپریس شوی کیچ. د config.xml ترتیب کولو فایل کې، د غیر کمپریس شوي کیچ اندازه هغه ارزښت ته وټاکئ چې تاسو ورته اړتیا لرئ - زه وړاندیز کوم چې د وړیا RAM نیمایي څخه زیات نه وي، ځکه چې پاتې به د پاڼې کیچ لاندې ځي.
سربیره پردې ، د غوښتنې کچې دوه تنظیمات شتون لري. لومړی ترتیب - غیر کمپریس شوي کیچ وکاروئ - د هغې کارول شامل دي. دا سپارښتنه کیږي چې دا د ټولو غوښتنو لپاره فعال کړئ، پرته له درنو څخه، کوم چې کولی شي ټول معلومات ولولي او کیچ فلش کړي. او دوهم ترتیب یو څه دی لکه د کیچ کارولو لپاره د لینونو اعظمي شمیر. دا په اوتومات ډول لوی پوښتنې محدودوي ترڅو دوی زیرمه پریږدي.
زه څنګه کولی شم په رام کې د ذخیره کولو لپاره د ذخیره کولو ترتیب تنظیم کړم؟
په نوي ClickHouse اسنادو کې ما اړوند برخه لوستل . تفصیل د چټک SSD سره یو مثال لري.
زه حیران یم چې ورته شی د حجم ګرم حافظې سره څنګه تنظیم کیدی شي. او یوه بله پوښتنه. انتخاب څنګه د دې ډیټا تنظیم سره کار کوي ، ایا دا به ټوله سیټ ولولي یا یوازې هغه چې په ډیسک کې وي ، او ایا دا ډاټا په حافظه کې کمپریس شوې؟ او د مخکې ځای برخه څنګه د داسې ډیټا تنظیم سره کار کوي؟
دا ترتیب د ډیټا ټوټو ذخیره اغیزه کوي، او د دوی بڼه په هیڅ ډول نه بدلیږي.
راځئ چې نږدې وګورو.
تاسو کولی شئ په رام کې د معلوماتو ذخیره تنظیم کړئ. ټول هغه څه چې د ډیسک لپاره تنظیم شوي د هغې لاره ده. تاسو د tmpfs ویش جوړ کړئ چې د فایل سیسټم کې ځینې لارې ته ایښودل شوی. تاسو دا لاره د خورا ګرمې برخې لپاره د ډیټا ذخیره کولو لپاره د لارې په توګه مشخص کړئ ، د معلوماتو ټوټې را رسیدل پیل کیږي او هلته لیکل کیږي ، هرڅه سم دي.
مګر زه د ټیټ اعتبار له امله دا کار کولو وړاندیز نه کوم ، که څه هم که تاسو په مختلف ډیټا مرکزونو کې لږترلږه درې نقلونه لرئ ، نو دا امکان لري. که څه پیښ شي، ډاټا به بیرته راشي. راځئ چې تصور وکړو چې سرور ناڅاپه بند شو او بیرته فعال شو. تقسیم بیا نصب شو، مګر هیڅ شی شتون نلري. کله چې د ClickHouse سرور پیل شي، دا ګوري چې دا دا ټوټې نلري، که څه هم، د ZooKeeper میټاډاټا په وینا، دوی باید هلته وي. هغه ګوري چې کوم نقلونه یې لري، غوښتنه یې کوي او ډاونلوډ یې کوي. پدې توګه به ډاټا بیرته راشي.
پدې معنی ، په RAM کې د ډیټا ذخیره کول په ډیسک کې د ذخیره کولو څخه اساسا توپیر نلري ، ځکه چې کله ډیسک ته ډیټا لیکل کیږي ، دا هم لومړی د پاڼې کیچ کې پای ته رسیږي او وروسته په فزیکي توګه لیکل کیږي. دا د فایل سیسټم نصبولو اختیار پورې اړه لري. مګر یوازې په هغه حالت کې ، زه به ووایم چې کلیک هاؤس د ننوتلو پرمهال fsync نه کوي.
په دې حالت کې، په RAM کې ډاټا د ډیسک په څیر په ورته بڼه کې ساتل کیږي. د انتخاب پوښتنه په ورته ډول هغه ټوټې غوره کوي چې لوستلو ته اړتیا لري، په ټوټو کې د اړین معلوماتو سلسله غوره کوي، او لوستل یې کوي. او مخکې چیرته کار کوي په سمه توګه ورته کار کوي، پرته له دې چې ډاټا په رام یا ډیسک کې وي.
د ټيټ کارډینالیت تر کوم شمیر ځانګړي ارزښتونو پورې اغیزمن دی؟
ټیټ کارډینالیټي په هوښیارۍ سره ډیزاین شوی. دا د ډیټا قاموسونه راټولوي، مګر دوی محلي دي. لومړی، د هرې برخې لپاره مختلف لغتونه شتون لري، او دویم، حتی په یوه ټوټه کې دوی د هرې لړۍ لپاره توپیر کولی شي. کله چې د ځانګړو ارزښتونو شمیر حد ته ورسیږي - یو ملیون، زما په اند - قاموس په ساده ډول ساتل کیږي او یو نوی جوړ شوی.
ځواب په عموم کې دی: د هر محلي حد لپاره - ووایه ، د هرې ورځې لپاره - په کوم ځای کې تر یو ملیون پورې ځانګړي ارزښتونه ټیټ کارډینالیټي مؤثره ده. وروسته به په ساده ډول یو فال بیک وي، په کوم کې چې ډیری مختلف لغتونه به کارول کیږي، نه یوازې یو. دا به تقریبا د منظم تار کالم په څیر کار وکړي، شاید یو څه لږ اغیزمن وي، مګر د فعالیت جدي تخریب به شتون ونلري.
د پنځه ملیارد قطارونو سره د میز لټون کولو بشپړ متن لپاره غوره تمرینونه کوم دي؟
مختلف ځوابونه شتون لري. لومړی دا دی چې ووایاست چې ClickHouse د بشپړ متن لټون انجن نه دی. د دې لپاره ځانګړي سیسټمونه شتون لري، د بیلګې په توګه، и . په هرصورت، زه په زیاتیدونکي توګه خلک ګورم چې وايي دوی د Elasticsearch څخه ClickHouse ته ځي.
ولې داسې کیږي؟ دوی دا د دې حقیقت له مخې تشریح کوي چې Elasticsearch په ځینو حجمونو کې د بار سره مقابله بندوي، د شاخصونو جوړولو سره پیل کیږي. شاخصونه خورا پیچلي کیږي، او که تاسو په ساده ډول کلیک هاؤس ته ډاټا لیږدئ، نو دا معلومه شوه چې دوی د حجم په شرایطو کې څو ځله ډیر اغیزمن ساتل کیږي. په ورته وخت کې، د لټون پوښتنې اکثرا داسې نه وې چې دا اړینه وه چې د معلوماتو په ټول حجم کې ځینې جملې ومومئ، د مورفولوژي په پام کې نیولو سره، مګر په بشپړ ډول مختلف. د مثال په توګه، په تیرو څو ساعتونو کې په لاګونو کې د بایټونو ځینې تعقیب ومومئ.
په دې حالت کې، تاسو په ClickHouse کې یو شاخص جوړ کړئ، چې لومړی ساحه به یې نیټه او وخت وي. او ترټولو لوی ډیټا کټ آف به د نیټې رینج پراساس وي. د ټاکل شوې نیټې حد کې ، د یوې قاعدې په توګه ، دا دمخه ممکنه ده چې د بشپړ متن لټون ترسره کړئ ، حتی د بریټ ځواک میتود په کارولو سره لکه په کارولو سره. په کلیک هاؤس کې ورته آپریټر ترټولو مؤثره آپریټر دی چې تاسو یې موندلی شئ. که تاسو یو څه ښه ومومئ، ما ته ووایاست.
مګر بیا هم، لکه یو بشپړ سکین دی. او بشپړ سکین نه یوازې په CPU کې ، بلکه په ډیسک کې هم ورو کیدی شي. که ناڅاپه تاسو هره ورځ یو ټیرابایټ ډیټا ولرئ، او تاسو د ورځې په اوږدو کې د یوې کلمې لټون کوئ، نو تاسو باید د ټیرابایټ سکین کړئ. او دا شاید په منظم هارډ ډرایو کې وي ، او په پای کې به دوی په داسې ډول بار شي چې تاسو به د SSH له لارې دې سرور ته لاسرسی ونلرئ.
په دې حالت کې، زه چمتو یم چې یو بل کوچنی چال وړاندې کړم. دا تجربه ده - دا ممکن کار وکړي، دا ممکن نه وي. ClickHouse د ټریګرام بلوم فلټرونو په شکل کې د بشپړ متن شاخصونه لري. په اریناډاټا کې زموږ همکارانو دمخه دا شاخصونه هڅه کړې ، او دوی ډیری وختونه په سمه توګه کار کوي لکه څنګه چې اراده شوي.
د دې په سمه توګه کارولو لپاره، تاسو باید په سمه توګه ښه پوهه ولرئ چې دوی څنګه کار کوي: د ټریګرام بلوم فلټر څه شی دی او څنګه یې اندازه غوره کړئ. زه کولی شم ووایم چې دوی به په ځینو نادرو جملو کې د پوښتنو لپاره مرسته وکړي، فرعي سټینګونه چې په ندرت سره په ډیټا کې موندل کیږي. په دې حالت کې، فرعي رینجونه به د شاخصونو لخوا وټاکل شي او لږ معلومات به لوستل شي.
په دې وروستیو کې، ClickHouse د بشپړ متن لټون لپاره حتی نور پرمختللي فعالیتونه اضافه کړي. دا، لومړی، په یوه پاس کې په یوځل کې د ډیری فرعي سټینګونو لټون دی، پشمول هغه اختیارونه چې د قضیې حساس دي، د قضیې حساس دي، د UTF-8 یا یوازې د ASCII لپاره مالتړ سره. ترټولو اغېزمن یو غوره کړئ چې تاسو ورته اړتیا لرئ.
په یوه پاس کې د ډیری منظم څرګندونو لټون هم څرګند شوی. تاسو اړتیا نلرئ د یو سبسټرینګ په څیر X یا د بل فرعي سټینګ په څیر X ولیکئ. تاسو سمدلاسه ولیکئ، او هرڅه د امکان تر حده مؤثره ترسره کیږي.
دریم، اوس د regexps لپاره نږدې لټون او د فرعي سټینګونو لپاره نږدې لټون شتون لري. که څوک یوه کلمه غلطه کړي، دا به د اعظمي میچ لپاره وپلټل شي.
د ډیری کاروونکو لپاره کلیک هاوس ته د لاسرسي تنظیم کولو غوره لاره څه ده؟
موږ ته ووایاست چې څنګه د لوی شمیر پیرودونکو او شنونکو لپاره لاسرسی تنظیم کړو. څنګه یو کتار جوړ کړئ، د ډیرو سمو پوښتنو ته لومړیتوب ورکړئ، او د کومو وسیلو سره؟
که کلستر په کافي اندازه لوی وي، نو یو ښه حل به دا وي چې دوه نور سرورونه پورته کړي، کوم چې به د شنونکو لپاره د ننوتلو ځای شي. دا دی، شنونکو ته اجازه مه ورکوئ چې په کلستر کې ځانګړي شارډونو ته لاسرسی ومومي، مګر په ساده ډول دوه خالي سرورونه جوړ کړئ، پرته له ډاټا، او په دوی باندې د لاسرسي حقونه تنظیم کړئ. پدې حالت کې ، د توزیع شوي غوښتنو لپاره د کارونکي تنظیمات ریموټ سرورونو ته لیږدول کیږي. دا دی، تاسو په دې دوو سرورونو کې هرڅه تنظیم کړئ، او ترتیبات په ټول کلستر باندې اغیزه لري.
په اصل کې، دا سرورونه هیڅ معلومات نلري، مګر په دوی کې د RAM اندازه د غوښتنو پلي کولو لپاره خورا مهم دی. ډیسک د لنډمهاله معلوماتو لپاره هم کارول کیدی شي که چیرې بهرنۍ راټولول یا بهرنۍ ترتیب فعال وي.
دا مهمه ده چې هغه ترتیبات وګورئ چې د ټولو ممکنه حدودو سره تړاو لري. که زه اوس د شنونکي په توګه د Yandex.Metrica کلستر ته لاړ شم او غوښتنه وکړم د هټ څخه شمیره غوره کړئ، بیا به زه سمدلاسه یو استثنا ترلاسه کړم چې زه نشم کولی غوښتنه اجرا کړم. د قطارونو اعظمي شمیر چې زه یې د سکین کولو اجازه لرم سل ملیارده دي، او په ټولیزه توګه په کلستر کې په یو میز کې پنځوس ټریلیون شتون لري. دا لومړی محدودیت دی.
راځئ چې ووایو زه د قطار حد لرې کړم او بیا پوښتنه پرمخ وړم. بیا به زه لاندې استثنا وګورم - ترتیب فعال شوی د نیټې لخوا د ځواک شاخص. زه نشم کولی دا پوښتنه بشپړه کړم که ما د نیټې حد نه وي مشخص کړی. تاسو اړتیا نلرئ په شنونکو تکیه وکړئ ترڅو دا په لاسي ډول مشخص کړئ. یو عادي قضیه ده کله چې د نیټې حد لیکل کیږي چیرې چې د اونۍ تر مینځ د پیښې نیټه وي. او بیا دوی په ساده ډول په غلط ځای کې بریکٹ مشخص کړ، او پرځای یې دا یا - یا د URL میچ وګرځید. که چیرې هیڅ حد شتون ونلري، نو دا به د URL کالم وګرځوي او یوازې یو ټن سرچینې ضایع کړي.
سربیره پردې، ClickHouse دوه لومړیتوب ترتیبات لري. له بده مرغه، دوی خورا ابتدايي دي. یو په ساده ډول ویل کیږي لومړیتوب. که لومړیتوب ≠ 0، او غوښتنې د یو څه لومړیتوب سره اجرا کیږي، مګر یوه غوښتنه چې د لومړیتوب ارزښت څخه کم وي، چې د لوړ لومړیتوب په معنی وي، اجرا کیږي، نو بیا د لومړیتوب ارزښت سره غوښتنه، چې د ټیټ لومړیتوب معنی لري. ، په ساده ډول تعلیق شوی او پدې وخت کې به کار ونکړي.
دا یو ډیر خام ترتیب دی او د قضیو لپاره مناسب نه دی چیرې چې کلستر دوامداره بار لري. مګر که تاسو لنډې، پټې غوښتنې لرئ چې مهمې دي، او کلستر اکثرا بې کاره وي، دا ترتیب مناسب دی.
راتلونکی لومړیتوب ترتیب بلل کیږي د OS موضوع لومړیتوب. دا په ساده ډول د لینکس مهالویش لپاره د ټولو غوښتنې اجرا کولو تارونو لپاره ښه ارزښت ټاکي. دا داسې کار کوي، مګر دا لاهم کار کوي. که تاسو لږ تر لږه ښه ارزښت وټاکئ - دا په ارزښت کې ترټولو لوی دی، او له همدې امله ټیټ لومړیتوب - او د لوړ لومړیتوبونو غوښتنو لپاره -19 ترتیب کړئ، نو CPU به د ټیټ لومړیتوب غوښتنې د لوړ لومړیتوبونو په پرتله څلور چنده کم مصرف کړي.
تاسو اړتیا لرئ د غوښتنې اعظمي اجرا کولو وخت تنظیم کړئ - ووایه ، پنځه دقیقې. د پوښتنو اجرا کولو لږترلږه سرعت خورا ښه شی دی. دا ترتیب د اوږدې مودې راهیسې شتون لري، او دا اړینه ده چې نه یوازې دا ثابته کړئ چې کلیک هاؤس ورو نه کوي، مګر دا مجبوروي.
تصور وکړئ، تاسو تنظیم کړئ: که ځینې پوښتنې په هره ثانیه کې له یو ملیون قطارونو څخه کم پروسس کوي، تاسو دا نشئ کولی. دا زموږ ښه نوم، زموږ ښه ډیټابیس بدناموي. راځئ چې یوازې دا منع کړو. په حقیقت کې دوه ترتیبات شتون لري. یو ته ویل کیږي دقیق اجرا کولو سرعت - په هره ثانیه کې په لیکو کې، او دویمه د دقیقې اجرا کولو سرعت چک کولو دمخه د وخت پای ته ویل کیږي - په ډیفالټ ډول پنځلس ثانیې. دا دی، پنځلس ثانیې امکان لري، او بیا، که دا ورو وي، نو یوازې یو استثنا وغورځوئ او غوښتنه یې لغوه کړئ.
تاسو هم اړتیا لرئ چې کوټې تنظیم کړئ. ClickHouse د جوړ شوي کوټې ځانګړتیا لري چې د سرچینو مصرف حسابوي. مګر، له بده مرغه، د هارډویر سرچینې نه لکه CPU، ډیسکونه، مګر منطقي - د پروسس شویو غوښتنو شمیر، لاینونه او بایټ لوستل کیږي. او تاسو کولی شئ تنظیم کړئ ، د مثال په توګه ، په پنځه دقیقو کې اعظمي سل غوښتنې او په ساعت کې زر غوښتنې.
ولې دا مهمه ده؟ ځکه چې ځینې تحلیلي پوښتنې به په مستقیم ډول د ClickHouse پیرودونکي څخه په لاسي ډول ترسره شي. او ټول به ښه شي. مګر که تاسو په خپل شرکت کې پرمختللي شنونکي لرئ، دوی به یو سکریپټ ولیکي، او ممکن په سکریپټ کې تېروتنه وي. او دا تېروتنه به د دې لامل شي چې غوښتنه په لامحدود لوپ کې اجرا شي. دا هغه څه دي چې موږ یې باید د ځان ساتنه وکړو.
ایا دا ممکنه ده چې د یوې پوښتنې پایلې لسو پیرودونکو ته ورکړئ؟
موږ ډیری کارونکي لرو چې په ورته وخت کې د خورا لوی غوښتنو سره راځي. غوښتنه لویه ده او په اصولو کې په چټکۍ سره اجرا کیږي، مګر د دې حقیقت له امله چې په ورته وخت کې ډیری غوښتنې شتون لري، دا خورا دردناک کیږي. ایا دا ممکنه ده چې ورته غوښتنه ترسره کړئ، کوم چې په پرله پسې ډول لس ځله راځي، یو ځل، او لسو مراجعینو ته پایله ورکړي؟
ستونزه دا ده چې موږ د منځګړیتوب ډاټا د زیرمې یا زیرمې پایلې نلرو. د عملیاتي سیسټم د پاڼې زیرمه شتون لري، کوم چې به تاسو د ډیسک څخه بیا د ډیټا لوستلو مخه ونیسي، مګر، له بده مرغه، ډاټا به لا هم ډیمپریس، غیر منظم او بیا پروسس شي.
زه غواړم په یو ډول د دې څخه مخنیوی وکړم، یا د منځګړیتوب ډیټا کیچ کولو سره، یا په یو ډول کتار کې د ورته پوښتنو قطار کولو او د پایلو کیچ اضافه کولو سره. موږ دا مهال په پراختیا کې د پلولو غوښتنه لرو چې د غوښتنې کیچ اضافه کوي ، مګر یوازې د دننه او یوځای کیدو برخو کې د فرعي پوښتنو لپاره - دا دی ، حل نیمګړی دی.
په هرصورت، موږ هم د ورته حالت سره مخ یو. په ځانګړې توګه کانونیکي بیلګه د پاڼې پوښل شوي پوښتنې دي. یو راپور شتون لري، دا څو پاڼې لري، او د 10 حد لپاره غوښتنه شتون لري. بیا ورته شی، مګر 10,10 حد. بیا بل بل مخ. او پوښتنه دا ده چې ولې موږ هر وخت دا ټول حساب کوو؟ مګر اوس د حل لاره نشته، او د مخنیوي لپاره هیڅ لاره نشته.
یو بدیل حل شتون لري چې د کلک هاوس څنګ ته د سایډ کار په توګه ځای په ځای شوی - .
کریل شواکوف: د کلیک هاوس پراکسي یو جوړ شوی نرخ محدودونکی او یو جوړ شوی پایلې کیچ لري. دلته ډیری ترتیبات رامینځته شوي ځکه چې ورته ستونزه حل شوې وه. پراکسي تاسو ته اجازه درکوي چې غوښتنې په قطار کې محدود کړئ او تنظیم کړئ چې د غوښتنې زیرمه څومره وخت ژوند کوي. که غوښتنې واقعیا ورته وې ، پراکسي به یې څو ځله واستوي ، مګر یوازې یو ځل به کلیک هاوس ته لاړ شي.
نګینکس په وړیا نسخه کې کیچ هم لري، او دا به هم کار وکړي. نګینکس حتی تنظیمات لري که چیرې غوښتنې په ورته وخت کې راشي ، نو دا به نور ورو کړي تر هغه چې یو بشپړ نشي. مګر دا په کلیک هاوس پراکسي کې دی چې تنظیم خورا ښه ترسره شوی. دا په ځانګړي ډول د ClickHouse لپاره جوړ شوی و، په ځانګړې توګه د دې غوښتنو لپاره، نو دا خورا مناسب دی. ښه، دا نصب کول اسانه دي.
د غیر متناسب عملیاتو او مادي لیدونو په اړه څه؟
یوه ستونزه شتون لري چې د ریپلی انجن سره عملیات غیر متناسب دي - لومړی معلومات لیکل کیږي ، بیا سقوط کوي. که چیرې یو مادي شوی ټابلیټ د ځینې مجموعو سره د نښې لاندې ژوند وکړي ، نو نقلونه به ورته لیکل کیږي. او که چیرې پیچلي منطق شتون ونلري، نو ډاټا به نقل شي. تاسو په دې اړه څه کولی شئ؟
یو څرګند حل شتون لري - د غیر متمرکز سقوط عملیاتو په جریان کې د میټ ویو په یو ځانګړي ټولګي کې محرک پلي کول. ایا د ورته فعالیت پلي کولو لپاره د سپینو زرو ګولۍ یا پالنونه شتون لري؟
دا د پوهیدو وړ ده چې څنګه تخریب کار کوي. هغه څه چې زه به یې اوس تاسو ته ووایم د پوښتنې سره تړاو نلري، مګر یوازې په هغه صورت کې چې دا د یادولو وړ وي.
کله چې نقل شوي میز ته داخل شي، د ټول داخل شوي بلاکونو نقل کول شتون لري. که تاسو په ورته ترتیب کې د ورته قطارونو ورته شمیر لرونکي ورته بلاک بیا ځای په ځای کړئ ، نو بیا ډاټا نقل کیږي. تاسو به د داخلولو په ځواب کې "Ok" ترلاسه کړئ، مګر په حقیقت کې د معلوماتو یوه کڅوړه به لیکل کیږي، او دا به نقل نشي.
دا د ډاډ لپاره اړین دی. که تاسو د ننوتلو پرمهال "Ok" ترلاسه کړئ ، نو ستاسو معلومات داخل شوي. که تاسو د ClickHouse څخه یوه تېروتنه ترلاسه کړئ، دا پدې مانا ده چې دوی نه دي داخل شوي او تاسو اړتیا لرئ چې داخلول تکرار کړئ. مګر که پیوستون د ننوتلو پرمهال مات شوی وي ، نو تاسو نه پوهیږئ چې ډاټا داخل شوې که نه. یوازینی اختیار دا دی چې داخلول بیا تکرار کړئ. که چیرې ډاټا واقعیا دننه شوې وي او تاسو یې بیا ځای په ځای کړئ ، د بلاک تخریب شتون لري. دا اړینه ده چې د نقلونو څخه مخنیوی وشي.
او دا هم مهمه ده چې دا څنګه د مادي لیدونو لپاره کار کوي. که چیرې معلومات په اصلي جدول کې د ننوتلو په وخت کې نقل شوي وي، نو دا به مادي لید ته هم نه ځي.
اوس د پوښتنې په اړه. ستاسو وضعیت ډیر پیچلی دی ځکه چې تاسو د انفرادي لینونو نقلونه ثبت کوئ. دا دی، دا ټوله بسته نه ده چې نقل شوې، مګر ځانګړي کرښې، او دوی په شالید کې سقوط کوي. په حقیقت کې، ډاټا به په اصلي جدول کې سقوط وکړي، مګر ناپاک شوي ډاټا به مادي لید ته ځي، او د یوځای کیدو په وخت کې به د مادي لیدونو سره هیڅ شی نه وي. ځکه چې یو مادي لید د ننوتلو محرک پرته بل څه ندي. د نورو عملیاتو په جریان کې، نور هیڅ شی نه پیښیږي.
او زه نشم کولی تاسو دلته خوشحاله کړم. تاسو یوازې د دې قضیې لپاره د ځانګړي حل په لټه کې یاست. د مثال په توګه، ایا دا ممکنه ده چې دا په مادي لید کې بیا پیل شي، او د نقل کولو طریقه ممکن ورته کار وکړي. مګر له بده مرغه، تل نه. که دا راټول شي، دا به کار ونکړي.
کریل شواکوف: موږ په ورځ کې د کرچ جوړونه هم درلوده. دلته یوه ستونزه وه چې د اعلاناتو تاثیرات شتون لري، او ځینې معلومات شتون لري چې موږ یې په ریښتیني وخت کې ښودلی شو - دا یوازې تاثیرات دي. دوی په ندرت سره نقل شوي ، مګر که دا پیښ شي ، موږ به یې وروسته په هر ډول سقوط کړو. او داسې شیان وو چې نقل نشي کولی - کلیکونه او دا ټوله کیسه. مګر ما هم غوښتل چې دوی سمدلاسه وښیم.
مادي نظرونه څنګه جوړ شول؟ داسې لیدونه شتون درلود چیرې چې دا مستقیم لیکل شوي - دا خام ډیټا ته لیکل شوي ، او لیدونو ته لیکل شوي. هلته، په ځینو وختونو کې ډاټا خورا سم نه وي، دا نقل شوي، او داسې نور. او د جدول دویمه برخه شتون لري ، چیرې چې دوی په بشپړ ډول د مادي لیدونو سره ورته ښکاري ، دا په جوړښت کې بالکل ورته دي. یوځل په یو وخت کې موږ ډاټا بیا محاسبه کوو، ډاټا د نقلونو پرته شمیرو، دې میزونو ته ولیکئ.
موږ د API له لارې لاړ - دا به په لاسي ډول په ClickHouse کې کار ونکړي. او API داسې ښکاري: کله چې زه په میز کې د وروستي اضافه کولو نیټه لرم، چیرته چې دا تضمین کیږي چې سم معلومات دمخه حساب شوي، او دا یو میز او بل میز ته غوښتنه کوي. له یوه څخه غوښتنه تر ټاکلې اندازې پورې ټاکل کیږي، او له بل څخه دا هغه څه ترلاسه کوي چې تر اوسه نه دي حساب شوي. او دا کار کوي، مګر یوازې د کلک هاؤس له لارې نه.
که تاسو یو ډول API لرئ - د شنونکو لپاره، د کاروونکو لپاره - بیا، په اصولو کې، دا یو اختیار دی. تاسو تل حساب کوئ، تل حساب کوئ. دا په ورځ کې یو ځل یا په بل وخت کې ترسره کیدی شي. تاسو د ځان لپاره داسې سلسله غوره کوئ چې تاسو ورته اړتیا نلرئ او مهم نه وي.
ClickHouse ډیری لاګونه لري. زه څنګه کولی شم هر څه وګورم چې سرور ته پیښیږي په یو نظر کې؟
ClickHouse د مختلفو لاګونو خورا لوی شمیر لري، او دا شمیر مخ په ډیریدو دی. په نویو نسخو کې، ځینې یې حتی د ډیفالټ لخوا فعال شوي؛ په زړو نسخو کې دوی باید د تازه کولو پر مهال فعال شي. په هرصورت، د دوی ډیری نور شتون لري. په نهایت کې ، زه غواړم وګورم چې اوس زما د سرور سره څه پیښیږي ، شاید په یو ډول لنډیز ډشبورډ کې.
ایا تاسو د کلک هاوس ټیم یا ستاسو د ملګرو ټیمونه لرئ چې د چمتو شوي ډشبورډونو ځینې فعالیت ملاتړ کوي چې دا لاګونه به د بشپړ محصول په توګه ښکاره کړي؟ په نهایت کې ، یوازې په کلیک هاوس کې لاګونو ته کتل خورا ښه دي. مګر دا به خورا ښه وي که چیرې دا دمخه د ډشبورډ په بڼه چمتو شوي وي. زه به له هغې څخه یو لښتی ترلاسه کړم.
ډشبورډونه شتون لري، که څه هم دوی معیاري ندي. زموږ په شرکت کې، شاوخوا 60 ټیمونه ClickHouse کاروي، او تر ټولو عجیب خبره دا ده چې ډیری یې ډشبورډونه لري چې دوی د ځان لپاره جوړ کړي، او یو څه توپیر لري. ځینې ټیمونه د داخلي Yandex.Cloud نصب کاروي. ځینې چمتو شوي راپورونه شتون لري، که څه هم ټول اړین ندي. نور خپل لري.
زما د میټریکا همکاران په ګرافانا کې خپل ډشبورډ لري، او زه د دوی د کلستر لپاره خپل ځان لرم. زه د سیرف کیچ لپاره د کیچ هټ په څیر شیانو ته ګورم. او حتی ډیر ستونزمن دا دی چې موږ مختلف وسایل کاروو. ما خپل ډشبورډ د ګرافیټ ویب په نوم د خورا زوړ وسیلې په کارولو سره رامینځته کړ. هغه په بشپړه توګه بدرنګه ده. او زه لاهم دا پدې لاره کاروم ، که څه هم ګرافانا به شاید ډیر اسانه او ښکلی وي.
په ډشبورډونو کې اساسی شی یو شان دی. دا د کلستر لپاره د سیسټم میټریکونه دي: CPU، حافظه، ډیسک، شبکه. نور - د یو ځای غوښتنو شمیر، د یوځل بیا یوځای کیدو شمیر، په هره ثانیه کې د غوښتنو شمیر، د MergeTree جدول ویشونو لپاره د ټوټو اعظمي شمیر، د نقل کولو ځنډ، د نقل کتار اندازه، په هر ثانیه کې د داخل شوي قطارونو شمیر، په هر ثانیه کې د داخل شوي بلاکونو شمیر. دا ټول هغه څه دي چې د لوګو څخه نه، مګر د میټریکونو څخه ترلاسه کیږي.
ولادیمیر کولوبایف: الیکسي، زه غواړم دا یو څه سم کړم. Grafana شتون لري. ګرافانا د ډیټا سرچینه لري، کوم چې کلیک هاوس دی. دا دی ، زه کولی شم له ګرافانا څخه مستقیم کلیک هاوس ته غوښتنې وکړم. ClickHouse د لاګونو سره یو میز لري، دا د هرچا لپاره یو شان دی. د پایلې په توګه، زه غواړم په ګرافانا کې دې لاګ جدول ته لاسرسی وموم او هغه غوښتنې وګورم چې زما سرور یې کوي. دا به ښه وي چې داسې ډشبورډ ولرئ.
ما پخپله موټر سایکل کړ. مګر زه یوه پوښتنه لرم - که دا ټول معیاري وي ، او ګرافانا د هرچا لخوا کارول کیږي ، نو ولې یانډیکس داسې رسمي ډشبورډ نلري؟
کریل شواکوف: په حقیقت کې، د ډیټا سرچینه چې ClickHouse ته ځي اوس د Altinity ملاتړ کوي. او زه یوازې غواړم یو ویکتور ورکړم چې چیرې کیندل شي او څوک فشار راوړي. تاسو کولی شئ له دوی څخه وپوښتئ، ځکه چې Yandex لاهم د ClickHouse جوړوي، او نه د هغې شاوخوا کیسه. Altinity اصلي شرکت دی چې اوس مهال د ClickHouse ته وده ورکوي. دوی به هغه پریږدي، مګر د هغه ملاتړ به وکړي. ځکه چې، په اصل کې، د ګرافانا ویب پاڼې ته د ډشبورډ اپلوډ کولو لپاره، تاسو یوازې راجستر او اپلوډ کولو ته اړتیا لرئ - کومه ځانګړې ستونزه شتون نلري.
الیکسي میلویدوف: په تیر کال کې، ClickHouse د پوښتنو پروفایل کولو ډیری وړتیاوې اضافه کړې. د سرچینې کارولو په اړه د هرې غوښتنې لپاره میټریکونه شتون لري. او پدې وروستیو کې ، موږ حتی د ټیټې کچې پوښتنې پروفایلر اضافه کړ ترڅو وګورو چې چیرې یوه پوښتنه هره ملی ثانیه مصرفوي. مګر د دې فعالیت کارولو لپاره ، زه باید د کنسول پیرودونکي خلاص کړم او غوښتنه ټایپ کړم ، کوم چې زه تل هیر کوم. ما دا یو ځای خوندي کړ او هیر یې کړم چې دقیقا چیرې.
کاش یو داسې وسیله وي چې یوازې ویلي وي، دلته ستاسو درنې پوښتنې دي، د پوښتنو ټولګي لخوا ګروپ شوي. ما په یو باندې فشار واچاوه، او دوی به ما ته ووایي چې له همدې امله دا دروند دی. اوس داسې کومه حل لاره نشته. او دا واقعیا خورا عجیب دی چې کله خلک له ما څخه پوښتنه کوي: "ما ته ووایاست ، ایا د ګرافانا لپاره کوم چمتو شوي ډشبورډونه شتون لري؟" ، زه وایم: "د ګرافانا ویب پا toې ته لاړشئ ، دلته د "ډشبورډونو" ټولنه شتون لري ، او یو ډشبورډ شتون لري. د ډیمکا څخه، د کوستیان څخه یو ډشبورډ شتون لري. زه نه پوهیږم چې دا څه دي، ما پخپله نه دی کارولی.
څنګه په ادغام اغیزه وکړي ترڅو سرور په OOM کې ټکر نشي؟
زه یو میز لرم، په میز کې یوازې یوه برخه شتون لري، دا د مرج ټریټ بدلول دي. زه د څلورو کلونو راهیسې پدې کې معلومات لیکم. ما اړتیا درلوده چې پدې کې یو بدلون رامینځته کړم او ځینې معلومات حذف کړم.
ما دا وکړل، او د دې غوښتنې پروسس کولو په جریان کې، په کلستر کې د ټولو سرورونو ټولې حافظې مصرف شوې، او په کلستر کې ټول سرورونه OOM ته لاړل. بیا دوی ټول یو ځای شول، ورته عملیات، دا ډیټا بلاک یوځای کول پیل کړل، او بیا په OOM کې راښکته شول. بیا دوی بیا پورته شول او بیا راښکته شول. او دا کار ودرېد.
بیا دا معلومه شوه چې دا واقعیا یوه بګ وه چې هلکانو حل کړه. دا ډیر په زړه پوری دی، ډیره مننه. خو یو پاتې شونی پاتې شو. او اوس، کله چې زه په جدول کې د یو ډول ادغام کولو په اړه فکر کوم، زه یوه پوښتنه لرم - ولې زه نشم کولی په دې ادغامونو اغیزه وکړم؟ د مثال په توګه، دوی د اړتیا وړ RAM مقدار محدود کړئ، یا په اصولو کې، د هغه مقدار له مخې چې دا ځانګړي جدول به پروسس کړي.
زه د "میتریک" په نوم یو میز لرم، مهرباني وکړئ دا زما لپاره په دوه تارونو کې پروسس کړئ. اړتیا نشته چې په موازي توګه لس یا پنځه انضمام رامینځته کړئ ، دا په دوه کې وکړئ. زه فکر کوم چې زه د دوو لپاره کافي حافظه لرم، مګر دا ممکن د لسو پروسس کولو لپاره کافي نه وي. وېره ولې پاتې ده؟ ځکه چې میز وده کوي، او یوه ورځ به زه د داسې وضعیت سره مخ شم چې په اصل کې، نور د بګ له امله نه وي، مګر دا چې ډاټا به په دومره لوی مقدار کې بدل شي چې زه به په ساده ډول په کافي اندازه حافظه ونه لرم. سرور او بیا سرور به د یوځای کیدو په وخت کې OOM سره ټکر شي. برسېره پردې، زه کولی شم بدلون لغوه کړم، مګر مرجي نور شتون نلري.
تاسو پوهیږئ، کله چې یوځای کیږي، سرور به په OOM کې نه راځي، ځکه چې کله یوځای کیږي، د RAM اندازه یوازې د ډیټا د یوې کوچنۍ لړۍ لپاره کارول کیږي. نو هرڅه به سم وي پرته لدې چې د ډیټا مقدار وي.
ولادیمیر کولوبایف: ښه. دلته شیبه داسې ده چې وروسته له دې چې بګ سم شو ، ما د ځان لپاره نوې نسخه ډاونلوډ کړه ، او په بل میز کې یو کوچنی ، چیرې چې ډیری برخې شتون لري ، ما ورته عملیات ترسره کړل. او د ادغام په جریان کې ، شاوخوا 100 GB رام په سرور کې سوځیدلی و. ما 150 نیولي و، 100 یې خوړلي، او د 50 GB کړکۍ پاتې دي، نو زه په OOM کې نه وم.
څه شی اوس مهال ما په OOM کې له راښکته کیدو څخه ساتي که چیرې دا واقعیا 100 GB رام مصرف کړي؟ څه باید وکړو که ناڅاپه په ادغام کې رام پای ته ورسي؟
الیکسي میلویدوف: داسې ستونزه شتون لري چې په ځانګړي ډول د ادغام لپاره د RAM مصرف محدود ندی. او دویمه ستونزه دا ده چې که یو ډول انضمام ټاکل شوی وي نو باید اجرا شي ځکه چې دا د نقل کولو لاګ کې ثبت شوی. د نقل کولو لاګ هغه کړنې دي چې د ریپلیکا په ثابت حالت کې راوستلو لپاره اړین دي. که تاسو لاسي لاسوهنې ونه کړئ چې دا د نقل کولو لاګ بیرته راوباسي، نو ضمیمه به په یو یا بل ډول ترسره شي.
البته، دا به بې ځایه نه وي چې د رام محدودیت ولري چې "یوازې په هغه صورت کې" د OOM په وړاندې ساتنه کوي. دا به د ادغام په بشپړولو کې مرسته ونکړي، دا به بیا پیل شي، یو څه حد ته ورسیږي، یو استثنا وغورځوئ، او بیا به بیا پیل شي - له دې څخه به هیڅ ښه نه وي. مګر په اصولو کې، دا به ګټور وي چې دا محدودیت معرفي کړي.
د ClickHouse لپاره د ګولنګ ډرایور به څنګه رامینځته شي؟
د ګولنګ ډرایور، چې د کریل شواکوف لخوا لیکل شوی، اوس په رسمي توګه د کلک هاوس ټیم لخوا ملاتړ کیږي. هغه هغه اوس لوی او ریښتینی دی.
یو کوچنی یادښت. د لامحدود نظم د نورمال ډولونو یو عالي او محبوب ذخیره شتون لري - دا ویرټیکا دی. دوی خپل رسمي پیتون ډرایور هم لري ، کوم چې د ورټیکا پراختیا کونکو لخوا ملاتړ کیږي. او څو ځله داسې پیښ شوي چې د ذخیره کولو نسخې او د ډرایور نسخې په ډراماتیک ډول توپیر لري، او چلوونکي په یو وخت کې کار بند کړ. او دوهم ټکی. د دې رسمي چلوونکي لپاره ملاتړ، داسې ښکاري چې د "نپل" سیسټم لخوا ترسره کیږي - تاسو دوی ته یوه مسله ولیکئ، او دا د تل لپاره ځړول کیږي.
زه دوه پوښتنې لرم. اوس د کیریل ګولنګ ډرایور د ګولنګ څخه د کلیک هاوس سره د خبرو اترو لپاره نږدې ډیفالټ لاره ده. پرته لدې چې څوک لاهم د http انٹرفیس له لارې اړیکه ونیسي ځکه چې هغه دا ورته خوښوي. د دې چلوونکي پرمختګ به څنګه پرمخ ځي؟ ایا دا به پخپله په ذخیره کې د کوم ماتونکي بدلونونو سره همغږي شي؟ او د یوې مسئلې د غور کولو کړنلاره څه ده؟
کریل شواکوف: لومړی دا چې څنګه هر څه په بیوروکراټیک ډول تنظیم شوي. دا ټکی بحث نه دی شوی، نو زه د ځواب ورکولو لپاره هیڅ نه لرم.
د مسلې په اړه د پوښتنې ځواب لپاره، موږ د موټر چلوونکي لږ تاریخ ته اړتیا لرو. ما د یوې شرکت لپاره کار کاوه چې ډیر معلومات یې درلودل. دا د اعلاناتو سپنر و چې د لوی شمیر پیښو سره چې چیرې یې زیرمه کولو ته اړتیا درلوده. او په یو وخت کې کلیک هاوس ښکاره شو. موږ دا د معلوماتو سره ډک کړل، او په لومړي سر کې هرڅه سم وو، مګر بیا د کلیک هاوس خراب شو. په دې وخت کې موږ پریکړه وکړه چې موږ ورته اړتیا نلرو.
یو کال وروسته، موږ د ClickHouse کارولو مفکورې ته راستانه شو، او موږ اړتیا درلوده چې هلته یو څه معلومات ولیکو. ابتدايي پیغام دا و: هارډویر خورا کمزوری دی، لږې سرچینې شتون لري. مګر موږ تل په دې ډول کار کړی، او له همدې امله موږ اصلي پروتوکول ته ګورو.
له هغه ځایه چې موږ په Go کې کار کاوه ، دا روښانه وه چې موږ د Go ډرایور ته اړتیا لرو. ما دا تقریبا بشپړ وخت ترسره کړ - دا زما د کار دنده وه. موږ دا یو ټاکلي نقطې ته راوړو، او په اصولو کې هیڅوک فکر نه کوي چې زموږ پرته بل څوک به یې وکاروي. بیا CloudFlare د ورته ستونزې سره راغی، او د یو څه وخت لپاره موږ د دوی سره خورا په اسانۍ سره کار وکړ، ځکه چې دوی ورته دندې درلودې. سربیره پردې ، موږ دا پخپله په کلیک هاوس کې او په ډرایور کې ترسره کړل.
په یو وخت کې، ما په ساده ډول دا کار بند کړ، ځکه چې زما فعالیت د ClickHouse او کار په برخه کې یو څه بدل شو. له همدې امله مسلې نه تړل کیږي. په دوره توګه، هغه خلک چې یو څه ته اړتیا لري پخپله ذخیره ته ژمن دي. بیا زه د پلټ غوښتنې ته ګورم او ځینې وختونه زه حتی پخپله یو څه ترمیم کوم ، مګر دا په ندرت سره پیښیږي.
زه غواړم موټر چلوونکي ته راستون شم. څو کاله دمخه، کله چې دا ټول شیان پیل شول، کلک هاؤس هم مختلف او د مختلف ظرفیتونو سره. اوس موږ پوهیږو چې څنګه ډرایور بیا جوړ کړو ترڅو دا ښه کار وکړي. که دا پیښ شي، نو بیا نسخه 2 به په هر حالت کې د راټول شوي کرچونو له امله نامناسب وي.
زه نه پوهیږم چې دا موضوع څنګه تنظیم کړم. زه پخپله ډیر وخت نه لرم. که ځینې خلک موټر چلوونکي پای ته ورسوي، زه کولی شم د دوی سره مرسته وکړم او دوی ته ووایم چې څه وکړي. مګر د پروژې په پراختیا کې د Yandex فعال ګډون تر اوسه پورې بحث نه دی شوی.
الیکسي میلویدوف: په حقیقت کې، تر اوسه د دغو چلوونکو په اړه کومه بیروکراسي شتون نلري. یوازینی شی دا دی چې دوی رسمي سازمان ته سپارل شوي، دا دی، دا ډرایور د Go لپاره د رسمي ډیفالټ حل په توګه پیژندل شوی. ځینې نور چلوونکي شتون لري، مګر دوی په جلا توګه راځي.
موږ د دې چلوونکو لپاره هیڅ داخلي پرمختګ نه لرو. پوښتنه دا ده چې ایا موږ کولی شو یو انفرادي کس وګمارو، نه د دې ځانګړي موټر چلوونکي لپاره، مګر د ټولنې د ټولو چلوونکو د پرمختګ لپاره، یا موږ کولی شو له بهر څخه یو څوک پیدا کړو.
بهرنۍ قاموس د lazy_load ترتیب فعالولو سره د ریبوټ وروسته نه پورته کیږي. چې څه کول پکار دي؟
موږ د lazy_load ترتیب فعال کړی دی، او د سرور له ریبوټ کیدو وروسته، قاموس پخپله نه پورته کیږي. دا یوازې وروسته له هغه پورته کیږي کله چې کارونکي دې قاموس ته لاسرسی ومومي. او لومړی ځل چې زه دې ته لاسرسی وموم، دا یوه تېروتنه ورکوي. ایا دا امکان لري چې په یو ډول په اتوماتيک ډول د ClickHouse په کارولو سره قاموسونه پورته کړئ ، یا تاسو اړتیا لرئ تل د دوی چمتووالی پخپله کنټرول کړئ ترڅو کارونکي غلطۍ ترلاسه نکړي؟
شاید موږ د ClickHouse پخوانۍ نسخه لرو، نو قاموس په اوتومات ډول نه پورته کیږي. کیدای شي دا قضیه وي؟
لومړی، لغتونه د یوې پوښتنې په کارولو سره جبري بار وړل کیدی شي د سیسټم بیا پورته کولو لغتونه. دوهم، د خطا په اړه - که قاموس لا دمخه بار شوی وي، نو بیا پوښتنې به د هغه معلوماتو پراساس کار وکړي چې بار شوي. که لغت لا تر اوسه نه وي پورته شوی، دا به د غوښتنې په جریان کې مستقیم پورته شي.
دا د درنو لغتونو لپاره خورا اسانه ندي. د مثال په توګه، تاسو اړتیا لرئ چې د MySQL څخه یو ملیون قطارونه راوباسئ. یو څوک یو ساده انتخاب کوي، مګر دا انتخاب به ورته ملیون قطارونو ته انتظار وکړي. دلته دوه حلونه شتون لري. لومړی د سست_لوډ بندول دي. دوهم، کله چې سرور پورته شي، مخکې له دې چې بار واچوي، ترسره کړئ د سیسټم بیا پورته کولو لغت یا یوازې یوه پوښتنه وکړئ چې لغت کاروي. بیا به قاموس پورته شي. تاسو اړتیا لرئ د lazy_load ترتیب فعالولو سره د لغتونو شتون کنټرول کړئ ، ځکه چې ClickHouse دوی په اوتومات ډول نه پورته کوي.
د وروستۍ پوښتنې ځواب دا دی چې یا نسخه زوړ ده یا دا اړتیا لري چې ډیبګ شي.
د دې حقیقت سره څه باید وکړو چې د سیسټم ریلوډ قاموس د ډیری لغتونو څخه هیڅ نه پورته کوي که لږترلږه یو یې د غلطۍ سره ټکر شي؟
د سیسټم بیالوډ لغتونو په اړه بله پوښتنه شتون لري. موږ دوه لغتونه لرو - یو نه ډک شوی، دوهم بار شوی. پدې حالت کې ، د سیسټم ریلوډ قاموس هیڅ قاموس نه پورته کوي ، او تاسو باید د سیسټم ریلوډ قاموس په کارولو سره د دې نوم لخوا یو مشخص ټکي په ګوته کړئ. ایا دا د ClickHouse نسخه سره هم تړاو لري؟
زه غواړم تاسو خوشحاله کړم. دا چلند بدل شو. دا پدې مانا ده چې که تاسو ClickHouse تازه کړئ، دا به هم بدلون ومومي. که تاسو د خپل اوسني چلند څخه خوښ نه یاست د سیسټم بیا پورته کولو لغتونه، تازه کړئ، او راځئ هیله مند یو چې دا د ښه لپاره بدل شي.
ایا د ClickHouse ترتیب کې د توضیحاتو تنظیم کولو لپاره کومه لاره شتون لري ، مګر د غلطیو په صورت کې یې نه ښیې؟
بله پوښتنه د لغت اړوند غلطیو په اړه ده، یعنې توضیحات. موږ د لغت لپاره د ClickHouse ترتیب کې د پیوستون توضیحات مشخص کړي، او که کومه تېروتنه وي، موږ دا توضیحات او پاسورډ په ځواب کې ترلاسه کوو.
موږ دا تېروتنه د ODBC ډرایور ترتیب کې د توضیحاتو په اضافه کولو سره حل کړه. ایا د ClickHouse ترتیب کې د توضیحاتو تنظیم کولو کومه لاره شتون لري ، مګر د غلطیو په صورت کې دا توضیحات نه ښیې؟
دلته اصلي حل دا دی چې دا اسناد په odbc.ini کې مشخص کړئ، او په ClickHouse کې یوازې د ODBC ډیټا سرچینې نوم مشخص کړئ. دا به د نورو لغت سرچینو لپاره نه وي - نه د MySQL سره قاموس لپاره، او نه د نورو لپاره، تاسو باید پټنوم ونه ګورئ کله چې تاسو د خطا پیغام ترلاسه کوئ. د ODBC لپاره، زه به هم وګورم - که دا شتون ولري، تاسو اړتیا لرئ چې دا لرې کړئ.
بونس: د غونډو څخه د زوم لپاره شالیدونه
په عکس کلیک کولو سره، د غونډو څخه د بونس شالید به د خورا دوامداره لوستونکو لپاره خلاص شي. موږ د Avito ټیکنالوژۍ ماسکوټس سره یوځای اور مړ کړ، موږ د سیسټم مدیر د خونې یا د زاړه ښوونځي کمپیوټر کلب همکارانو سره خبرې کوو، او موږ د پل لاندې ورځنۍ غونډې د ګرافیتي شالید په وړاندې ترسره کوو.
سرچینه: www.habr.com