څرنګه چې ClickHouse یو ځانګړی سیسټم دی، کله چې دا کار کوي نو دا مهمه ده چې د دې جوړښت ځانګړتیاوې په پام کې ونیسئ. په دې راپور کې، الیکسي به د کلک هاوس کارولو په وخت کې د عام غلطیو مثالونو په اړه خبرې وکړي، کوم چې کولی شي د غیر اغیزمن کار لامل شي. عملي مثالونه به وښيي چې څنګه د یو یا بل ډیټا پروسس کولو سکیم غوره کول د اندازې امرونو سره فعالیت بدلولی شي.
سلام و ټولو ته! زما نوم الیکسي دی، زه کلیک هاوس جوړوم.
لومړی، زه سمدلاسه تاسو راضي کړم، نن به تاسو ته ونه وایم چې کلیک هاوس څه شی دی. د ریښتیني کیدو لپاره ، زه له دې څخه ستړی شوی یم. هر وخت زه تاسو ته وایم چې دا څه دي. او شاید هرڅوک دمخه پوهیږي.
پرځای یې، زه به تاسو ته ووایم چې کوم احتمالي غلطۍ شتون لري، دا دی، تاسو څنګه کولی شئ د ClickHouse په غلط ډول وکاروئ. په حقیقت کې، د ویره کولو اړتیا نشته، ځکه چې موږ د کلک هاوس د سیسټم په توګه وده کوو چې ساده، اسانه، او د بکس څخه بهر کار کوي. ما دا نصب کړی، کومه ستونزه نشته.
مګر تاسو لاهم اړتیا لرئ په پام کې ونیسئ چې دا سیسټم ځانګړی دی او تاسو کولی شئ په اسانۍ سره د غیر معمولي کارونې قضیې سره مخ شئ چې دا سیسټم به د دې آرامۍ زون څخه بهر کړي.
نو، کوم ډول ریک شتون لري؟ زه به اکثرا د څرګند شیانو په اړه وغږیږم. هر څه ټولو ته څرګند دي، هرڅوک په هرڅه پوهیږي او خوشحاله کیدی شي چې دوی دومره هوښیار دي، او هغه څوک چې نه پوهیږي یو څه به نوي زده کړي.
لومړی او ساده بیلګه، چې له بده مرغه، ډیری وختونه واقع کیږي، د کوچنیو بستونو سره د ننوتلو لوی شمیر دی، د بیلګې په توګه د کوچنیو داخلونو لوی شمیر.
که موږ په پام کې ونیسو چې څنګه ClickHouse insert ترسره کوي، نو تاسو کولی شئ په یوه غوښتنه کې لږترلږه یو ټیرابایټ ډیټا واستوئ. دا کومه ستونزه نه ده.
او راځئ وګورو چې عادي فعالیت به څه وي. د مثال په توګه، موږ د Yandex.Metrica ډاټا څخه یو میز لرو. هټ. 105 ځینې کالمونه. 700 بایټس غیر کمپریس شوی. او موږ به د یو ملیون قطارونو په بیچونو کې په ښه توګه داخل کړو.
موږ په میز کې MergeTree داخل کوو، دا په هره ثانیه کې نیم ملیون قطارونه بدلوي. غوره. په یو نقل شوي جدول کې به یو څه کوچنی وي، نږدې 400 قطارونه په یوه ثانیه کې.
او که تاسو د کورم داخلول فعال کړئ ، تاسو یو څه لږ ، مګر لاهم ښه فعالیت ترلاسه کوئ ، په هره ثانیه کې 250 شرایط. د کورم داخلول په ClickHouse* کې یو غیر مستند شوی خصوصیت دی.
* تر 2020 پورې، .
که تاسو کوم بد کار کوئ نو څه پیښیږي؟ موږ یو قطار د MergeTree جدول ته داخل کړو او په هر ثانیه کې 59 قطارونه ترلاسه کړو. دا 10 ځله ورو دی. په ReplicatedMergeTree کې - په هر ثانیه کې 000 قطارونه. او که چیرې کورم فعال وي، نو دا په هره ثانیه کې 6 کرښې راګرځي. زما په اند، دا یو ډول مطلق خپګان دی. تاسو څنګه کولی شئ داسې سست کړئ؟ ما حتی دا زما په ټي شرټ کې لیکلی دی چې کلیک هاوس باید ورو نه شي. مګر بیا هم کله ناکله پیښیږي.
په حقیقت کې دا زموږ نیمګړتیا ده. موږ کولی شو په اسانۍ سره هرڅه سم کړو، مګر موږ ونه کړل. او موږ دا ونه کړل ځکه چې زموږ سکریپټ ورته اړتیا نه درلوده. موږ دمخه قصابان درلودل. موږ یوازې زموږ په ننوتلو کې بیچونه ترلاسه کړل، او هیڅ ستونزه نشته. موږ دا دننه کوو او هرڅه سم کار کوي. مګر، البته، هر ډول سناریوګانې ممکن دي. د مثال په توګه، کله چې تاسو د سرورونو یوه ډله لرئ په کوم کې چې ډاټا تولید کیږي. او دوی ډیری وختونه ډاټا نه داخلوي، مګر دوی لاهم د مکرر داخلولو سره پای ته رسیږي. او موږ باید یو څه له دې څخه مخنیوی وکړو.
د تخنیکي نظر څخه، نقطه دا ده چې کله تاسو په ClickHouse کې داخل کړئ، ډاټا په هیڅ یادښت کې پای ته نه رسیږي. موږ حتی د ریښتیني لاګ جوړښت MergeTree نه لرو ، مګر یوازې یو MergeTree ، ځکه چې دلته نه لاګ شتون لري او نه هم یاد میز. موږ په ساده ډول سمدلاسه ډاټا د فایل سیسټم ته لیکو، مخکې له دې چې په کالمونو کې تنظیم شوي وي. او که تاسو 100 کالمونه لرئ، نو له 200 څخه ډیر فایلونه به یو جلا لارښود ته ولیکل شي. دا ټول خورا پیچلي دي.
او پوښتنه راپورته کیږي: "دا څنګه سم ترسره کړئ؟" که وضعیت داسې وي چې تاسو لاهم اړتیا لرئ په یو ډول په کلیک هاوس کې ډاټا ثبت کړئ.
طریقه 1. دا ترټولو اسانه لار ده. یو ډول توزیع شوي قطار وکاروئ. د مثال په توګه، کافکا. تاسو په ساده ډول د کافکا څخه ډیټا راوباسئ او په ثانیه کې یو ځل یې بسته کړئ. او هرڅه به سم وي، تاسو ریکارډ کړئ، هرڅه سم کار کوي.
زیانونه یې دا دي چې کافکا یو بل لوی توزیع شوی سیسټم دی. زه دا هم پوهیږم که تاسو دمخه په خپل شرکت کې کافکا لرئ. دا ښه دی، دا مناسب دی. مګر که دا شتون ونلري، نو تاسو باید په خپله پروژه کې د بل ویشل شوي سیسټم راښکته کولو دمخه درې ځله فکر وکړئ. او نو دا د بدیلونو په پام کې نیولو سره ارزښت لري.
میتود 2. دا د زاړه ښوونځي بدیل دی او په ورته وخت کې خورا ساده دی. ایا تاسو یو ډول سرور لرئ چې ستاسو لاګونه تولیدوي. او دا یوازې ستاسو لاګونه فایل ته لیکي. او یو ځل په ثانیه کې، د بیلګې په توګه، موږ د دې فایل نوم بدلوو او یو نوی یې ماتوو. او یو جلا سکریپټ، یا د کرون یا ځینې ډیمون له لارې، زوړ فایل اخلي او کلیک هاوس ته یې لیکي. که تاسو په ثانیه کې یو ځل لاګ ثبت کړئ نو هرڅه به سم وي.
مګر د دې میتود نیمګړتیا دا ده چې که ستاسو سرور چې لاګونه رامینځته شوي په کوم ځای کې ورک شي ، نو ډاټا به هم ورک شي.
میتود 3. یو بل په زړه پوری میتود شتون لري، کوم چې لنډمهاله فایلونو ته اړتیا نلري. د مثال په توګه، تاسو یو ډول د اعلاناتو سپنر یا کوم بل په زړه پورې ډیمون لرئ چې ډاټا تولیدوي. او تاسو کولی شئ په مستقیم ډول په RAM کې ، بفر کې د ډیټا یوه ډله راټول کړئ. او کله چې کافي وخت تیر شو ، تاسو دا بفر یوې خوا ته کیږدئ ، یو نوی رامینځته کړئ ، او په جلا تار کې ، هغه څه دننه کړئ چې دمخه یې په کلیک هاؤس کې راټول شوي.
له بلې خوا، ډاټا هم د وژنې -9 سره ورک کیږي. که ستاسو سرور خراب شي، تاسو به دا ډاټا له لاسه ورکړئ. او بله ستونزه دا ده چې که تاسو ډیټابیس ته د لیکلو توان نه درلود، نو ستاسو ډاټا به په RAM کې راټول شي. او یا به رام پای ته ورسیږي، یا تاسو به په ساده ډول ډاټا له لاسه ورکړئ.
طريقه 4. بله په زړه پورې طريقه. ایا تاسو یو ډول سرور پروسې لرئ. او دا کولی شي سمدلاسه کلیک هاوس ته معلومات واستوي ، مګر دا په یوه اړیکه کې ترسره کړئ. د مثال په توګه، ما د لیږد کوډ کولو سره د HTTP غوښتنه لیږلې: د ننوتلو سره ټوټه شوې. او دا په ندرت سره ټوټې رامینځته کوي ، تاسو کولی شئ هره کرښه واستوئ ، که څه هم د دې معلوماتو چوکاټ کولو لپاره به سر وي.
په هرصورت، پدې حالت کې ډاټا به سمدلاسه ClickHouse ته واستول شي. او کلیک هاوس به دوی پخپله بفر کړي.
خو ستونزې هم رامنځته کیږي. اوس به تاسو ډیټا له لاسه ورکړئ ، پشمول کله چې ستاسو پروسه وژل کیږي او که د ClickHouse پروسه وژل شوې وي ، ځکه چې دا به یو نامکمل داخل وي. او په ClickHouse کې داخلونه د قطارونو په اندازې کې تر یو ټاکلي حد پورې اټومي دي. په اصل کې، دا په زړه پورې لاره ده. هم کارول کیدی شي.
میتود 5. دلته یو بل په زړه پورې میتود دی. دا د ډیټا بسته کولو لپاره د ټولنې لخوا رامینځته شوی یو ډول سرور دی. ما دا پخپله نه دی لیدلی، نو زه د هیڅ شی تضمین نشم کولی. په هرصورت، پخپله د ClickHouse لپاره هیڅ تضمین ندی ورکړل شوی. دا خلاص سرچینه هم ده ، مګر له بلې خوا ، تاسو ممکن د کیفیت ځینې معیارونو سره عادت شئ چې موږ یې چمتو کولو هڅه کوو. مګر د دې شی لپاره - زه نه پوهیږم، GitHub ته لاړ شئ، کوډ وګورئ. شاید دوی یو څه نورمال لیکلي وي.
* د 2020 پورې، باید په پام کې ونیول شي .
6. بله طریقه د بفر میزونو کارول دي. د دې میتود ګټه دا ده چې د کارولو پیل کول خورا اسانه دي. د بفر میز جوړ کړئ او په هغې کې دننه کړئ.
نیمګړتیا دا ده چې ستونزه په بشپړه توګه نه حل کیږي. که، د MergeTree په څیر نرخ کې، تاسو باید په هره ثانیه کې د یوې بستې په واسطه ډاټا ګروپ کړئ، نو بیا په بفر میز کې په نرخ کې، تاسو اړتیا لرئ لږترلږه په هر ثانیه کې تر څو زرو پورې ګروپ کړئ. که دا په هره ثانیه کې له 10 څخه ډیر وي، دا به لاهم خراب وي. او که تاسو دا په بیچونو کې دننه کړئ ، نو تاسو ولیدل چې دا په یوه ثانیه کې سل زره لینونه بدلیږي. او دا لا دمخه په کافي اندازه درنو معلوماتو کې دی.
او همدارنګه بفر میزونه لاګ نلري. او که ستاسو په سرور کې یو څه غلط وي، نو ډاټا به ورک شي.
او د بونس په توګه، موږ په دې وروستیو کې په ClickHouse کې فرصت ترلاسه کړ چې د کافکا څخه ډاټا بیرته ترلاسه کړو. د میز انجن شتون لري - کافکا. تاسو یوازې جوړ کړئ. او تاسو کولی شئ پدې کې مادي نمایشونه ځړ کړئ. په دې حالت کې، دا به پخپله د کافکا څخه ډاټا راوباسي او هغه میزونو ته چې تاسو ورته اړتیا لرئ داخل کړئ.
او هغه څه چې په ځانګړي ډول د دې فرصت په اړه خوښ دي دا دي چې دا موږ نه وو چې دا یې وکړل. دا د ټولنې ځانګړتیا ده. او کله چې زه د "ټولنې ځانګړتیا" وایم، زما مطلب دا دی چې پرته له کوم سپکاوی څخه. موږ کوډ لوستل، بیاکتنه یې وکړه، دا باید ښه کار وکړي.
* تر 2020 پورې ، ورته ملاتړ څرګند شوی .
د معلوماتو داخلولو پر مهال نور څه ناشونی یا غیر متوقع کیدی شي؟ که تاسو د ارزښتونو داخلولو غوښتنه وکړئ او په ارزښتونو کې ځینې محاسبې څرګندونې ولیکئ. د مثال په توګه، اوس () هم یو حساب شوی بیان دی. او په دې حالت کې، ClickHouse مجبور دی چې په هره کرښه کې د دې بیانونو ژباړونکي په لاره واچوي، او فعالیت به د پراخوالي امرونو سره راټیټ شي. دا غوره ده چې له دې څخه ډډه وکړئ.
* په اوس وخت کې، ستونزه په بشپړه توګه حل شوې، په VALUES کې د څرګندونو کارولو په وخت کې نور د فعالیت ریګریشن شتون نلري.
بله بیلګه دا ده کله چې ځینې ستونزې شتون ولري کله چې تاسو په یوه بسته کې ډاټا لرئ چې د برخې برخې پورې اړه لري. د ډیفالټ په واسطه، د ClickHouse ویشونه د میاشتې لخوا دي. او که تاسو د یو ملیون قطارونو بسته دننه کړئ ، او د څو کلونو لپاره ډیټا شتون لري ، نو تاسو به هلته څو درجن برخې ولرئ. او دا د دې حقیقت سره مساوي دي چې په اندازې کې به څو لس ځله کوچنۍ بستې وي، ځکه چې دننه دوی تل لومړی په برخو ویشل شوي.
* په دې وروستیو کې، په تجربوي حالت کې، ClickHouse د لیکلو مخکې لاګ سره په RAM کې د ټوټو او ټوټو کمپیکٹ فارمیټ لپاره ملاتړ اضافه کړ، کوم چې نږدې په بشپړه توګه ستونزه حل کوي.
اوس راځئ چې دوهم ډول ستونزه وګورو - د معلوماتو ټایپ کول.
د ډاټا ټایپ کول کیدای شي سخت یا تار وي. سټرینګ هغه وخت دی کله چې تاسو یې اخیستی او اعلان یې کړی چې ستاسو ټولې ساحې د سټرینګ ډول دي. دا خندا ده. د دې کولو لپاره هیڅ اړتیا نشته.
راځئ چې معلومه کړو چې دا څنګه په داسې حالتونو کې په سمه توګه ترسره کړئ کله چې تاسو غواړئ ووایاست چې موږ یو څه ساحه لرو، یو تار لرو، او کلیک هاوس ته اجازه راکړئ چې دا پخپله معلومه کړي، او زه به زحمت ونه کړم. مګر دا لاهم د یو څه هڅې کولو ارزښت لري.
د مثال په توګه، موږ یو IP پته لرو. په یوه حالت کې، موږ دا د تار په توګه خوندي کړ. د مثال په توګه، 192.168.1.1. او په بل حالت کې، دا به د یو شمیر ډوله UInt32* وي. د IPv32 پته لپاره 4 بټونه کافي دي.
لومړی، په عجیب ډول کافي، ډاټا به تقریبا په مساوي توګه فشارول شي. البته، توپیر به وي، مګر دومره لوی نه وي. نو د ډیسک I/O سره کومه ځانګړې ستونزه شتون نلري.
مګر د پروسیسر وخت او د پوښتنو اجرا کولو وخت کې جدي توپیر شتون لري.
راځئ چې د ځانګړي IP پتې شمیره وګورو که چیرې دوی د شمیرو په توګه زیرمه شوي وي. دا په هره ثانیه کې 137 ملیون لینونو ته کار کوي. که ورته د تارونو په بڼه وي، نو په هر ثانیه کې 37 ملیون لینونه. زه نه پوهیږم چې دا تصادف ولې رامنځته شو. ما دا غوښتنې پخپله ترسره کړې. مګر بیا هم شاوخوا 4 ځله ورو.
او که تاسو د ډیسک ځای کې توپیر محاسبه کړئ نو بیا هم توپیر شتون لري. او توپیر تقریبا یو ربع دی، ځکه چې ډیری ځانګړي IP پتې شتون لري. او که چیرې د لږ شمیر مختلف معنی سره کرښې شتون ولري ، نو دوی به په اسانۍ سره د قاموس له مخې نږدې ورته حجم ته فشار ورکړي.
او څلور ځله د وخت توپیر په سړک کې نه دی. شاید تاسو ته تاوان ونه رسئ، البته، مګر کله چې زه دا توپیر وینم، دا زما غم کوي.
راځئ چې مختلف قضیې وګورو.
1. یوه قضیه کله چې تاسو لږ مختلف ځانګړي ارزښتونه لرئ. پدې حالت کې، موږ یو ساده تمرین کاروو چې تاسو شاید پوهیږئ او د هر DBMS لپاره کارولی شئ. دا ټول نه یوازې د کلیک هاوس لپاره معنی لري. یوازې په ډیټابیس کې شمیرې پیژندونکي ولیکئ. او تاسو کولی شئ تارونو ته بدل کړئ او بیرته ستاسو د غوښتنلیک اړخ ته.
د مثال په توګه، تاسو یوه سیمه لرئ. او تاسو هڅه کوئ چې دا د تار په توګه خوندي کړئ. او هلته به لیکل کیږي: مسکو او مسکو سیمه. او کله چې زه ګورم چې دا "مسکو" وايي، دا هیڅ شی نه دی، مګر کله چې دا مسکو وي، دا یو څه په بشپړه توګه غمجن کیږي. دا څو بایټس دی.
پرځای یې، موږ په ساده ډول د Ulnt32 او 250 شمیره لیکو. موږ په Yandex کې 250 لرو، مګر ستاسو ممکن توپیر ولري. یوازې په هغه حالت کې ، زه به ووایم چې کلیک هاوس د جیوبیس سره کار کولو لپاره جوړ شوی وړتیا لري. تاسو په ساده ډول د سیمو سره یو لارښود ولیکئ ، پشمول د یو درجه بندي په شمول ، د بیلګې په توګه به مسکو ، د مسکو سیمه او هرڅه چې تاسو ورته اړتیا لرئ وي. او تاسو کولی شئ د غوښتنې په کچه بدل کړئ.
دوهم اختیار تقریبا ورته دی، مګر د کلک هاؤس دننه د ملاتړ سره. دا د اینوم ډیټا ډول دی. تاسو په ساده ډول ټول هغه ارزښتونه ولیکئ چې تاسو ورته اړتیا لرئ د اینوم دننه. د مثال په توګه، د وسیلې ډول او هلته ولیکئ: ډیسټاپ، موبایل، ټابلیټ، تلویزیون. په ټولیز ډول 4 اختیارونه شتون لري.
نیمګړتیا دا ده چې تاسو اړتیا لرئ دا په دوره توګه بدل کړئ. یوازې یو اختیار اضافه شوی. راځئ چې جدول بدل کړو. په حقیقت کې، په ClickHouse کې د بدلون میز وړیا دی. په ځانګړي توګه د اینوم لپاره وړیا ځکه چې په ډیسک کې معلومات نه بدلیږي. مګر سره له دې، بدلون په میز کې یو لاک * ترلاسه کوي او باید انتظار وکړي تر هغه چې ټول انتخابونه اجرا شي. او یوازې وروسته له دې چې دا بدلون به اجرا شي، د بیلګې په توګه لاهم ځینې ناخوالې شتون لري.
* د ClickHouse په وروستي نسخو کې، ALTER په بشپړ ډول غیر بلاک شوی دی.
بل اختیار چې د ClickHouse لپاره خورا ځانګړی دی د بهرني لغتونو نښلول دي. تاسو کولی شئ په ClickHouse کې شمیرې ولیکئ، او خپل لارښودونه په هر هغه سیسټم کې وساتئ چې ستاسو لپاره مناسب وي. د مثال په توګه، تاسو کولی شئ وکاروئ: MySQL، Mongo، Postgres. تاسو حتی کولی شئ خپل مایکرو خدمت رامینځته کړئ چې دا معلومات به د http له لارې واستوي. او د ClickHouse په کچه، تاسو یو فنکشن ولیکئ چې دا ډاټا به د شمیرو څخه تارونو ته واړوي.
دا په بهرني میز کې د یوځای کیدو ترسره کولو لپاره یوه ځانګړې مګر خورا مؤثره لاره ده. او دوه اختیارونه شتون لري. په یو شکل کې، دا ډاټا به په بشپړه توګه زیرمه شي، په بشپړ ډول په رام کې موجود وي او د یو څه فریکونسۍ سره تازه شي. او په بل اختیار کې، که دا ډاټا په RAM کې مناسب نه وي، نو تاسو کولی شئ په جزوي توګه دا زیرمه کړئ.
دلته یو مثال دی. د Yandex.Direct شتون لري. او د اعلاناتو شرکت او بینر شتون لري. شاید په لسګونو ملیون اعلاناتو شرکتونه شتون ولري. او دوی تقریبا په رام کې فټ کوي. او په ملیاردونو بینرونه شتون لري ، دوی مناسب ندي. او موږ د MySQL څخه زیرمه شوي قاموس کاروو.
یوازینۍ ستونزه دا ده چې زیرمه شوي لغت به ښه کار وکړي که چیرې د هټ نرخ 100٪ ته نږدې وي. که دا کوچنی وي، نو کله چې د معلوماتو د هرې برخې لپاره د پوښتنو پروسس کول، تاسو باید په حقیقت کې ورک شوي کیلي واخلئ او د MySQL څخه ډاټا ترلاسه کړئ. د ClickHouse په اړه، زه لاهم تضمین کولی شم - هو، دا سست نه دی، زه به د نورو سیسټمونو په اړه خبرې ونه کړم.
او د بونس په توګه، لغاتونه په ClickHouse کې د بیرته فعاله معلوماتو تازه کولو لپاره خورا اسانه لار ده. دا، تاسو د اعلاناتو شرکتونو په اړه راپور درلود، کاروونکي یوازې د اعلاناتو شرکت بدل کړ او په ټولو پخوانیو معلوماتو کې، په ټولو راپورونو کې، دا ډاټا هم بدله شوه. که تاسو په مستقیم ډول میز ته قطارونه ولیکئ، نو د دوی تازه کول به ناممکن وي.
بله لاره کله چې تاسو نه پوهیږئ چیرې د خپلو تارونو لپاره پیژندونکي ترلاسه کړئ. تاسو کولی شئ په ساده ډول یې هش کړئ. سربیره پردې ، ترټولو ساده اختیار د 64-bit هش اخیستل دي.
یوازینۍ ستونزه دا ده چې که هش 64-bit وي، نو تاسو به تقریبا یقینا ټکرونه ولرئ. ځکه چې که هلته یو ملیارد کرښې شتون ولري، نو احتمال لا دمخه د پام وړ کیږي.
او دا به ښه نه وي چې په دې ډول د اعلاناتو شرکتونو نومونه هش کړئ. که د مختلف شرکتونو اعلاناتو کمپاینونه مخلوط شي، نو بیا به یو څه د پوهیدو وړ وي.
او یو ساده چال دی. ریښتیا ، دا د جدي ډیټا لپاره هم خورا مناسب ندي ، مګر که یو څه خورا جدي نه وي ، نو یوازې د لغت کیلي ته د پیرودونکي پیژندونکی اضافه کړئ. او بیا به تاسو ټکرونه ولرئ ، مګر یوازې په یو پیرودونکي کې. او موږ دا طریقه په Yandex.Metrica کې د لینک نقشو لپاره کاروو. موږ هلته URLونه لرو، موږ هش ذخیره کوو. او موږ پوهیږو چې البته، ټکرونه شتون لري. مګر کله چې پاڼه ښکاره شي، احتمال چې د یو کارونکي په یوه پاڼه کې ځینې URLs یوځای ودرول شي او دا به په پام کې ونیول شي غفلت کیدی شي.
د بونس په توګه ، د ډیری عملیاتو لپاره یوازې هشونه کافي دي او تارونه پخپله اړتیا نلري چیرې چې زیرمه شي.
بله بیلګه دا ده که تارونه لنډ وي، د بیلګې په توګه، د ویب پاڼې ډومینونه. دوی کولی شي ذخیره شي لکه څنګه چې وي. یا، د مثال په توګه، د براوزر ژبه ru 2 بایټ دی. البته ، زه واقعیا د بایټونو لپاره بخښنه لرم ، مګر اندیښنه مه کوئ ، 2 بایټس افسوس ندی. مهرباني وکړئ دا په څیر وساتئ، اندیښنه مه کوئ.
بله قضیه هغه وخت ده چې برعکس، ډیری کرښې شتون لري او په دوی کې ډیری ځانګړي دي، او حتی سیټ احتمالي لامحدود وي. یو عام مثال د لټون جملې یا URLs دي. د ټایپونو په شمول د جملو لټون. راځئ وګورو چې هره ورځ څومره ځانګړي لټون جملې شتون لري. او دا معلومه شوه چې دوی د ټولو پیښو نږدې نیمایي دي. او په دې حالت کې، تاسو شاید فکر وکړئ چې تاسو اړتیا لرئ چې ډاټا نورمال کړئ، پیژندونکي حساب کړئ، او په جلا جدول کې یې واچوئ. مګر تاسو اړتیا نلرئ دا کار وکړئ. یوازې دا کرښې وساتئ لکه څنګه چې دوی دي.
دا غوره ده چې هیڅ شی اختراع نه کړئ، ځکه چې که تاسو دا په جلا توګه ذخیره کړئ، نو تاسو اړتیا لرئ چې یوځای شئ. او دا یوځای کیدل په غوره توګه حافظې ته تصادفي لاسرسی دی ، که چیرې دا لاهم په حافظه کې فټ شي. که دا مناسب نه وي، نو ستونزې به وي.
او که چیرې ډاټا په خپل ځای کې زیرمه شي، نو دا په ساده ډول د فایل سیسټم څخه په اړین ترتیب کې لوستل کیږي او هرڅه سم دي.
که تاسو URLs یا کوم بل پیچلي اوږد تار لرئ، نو دا د پام وړ ارزښت لري چې تاسو کولی شئ یو ډول استخراج مخکې له مخکې محاسبه کړئ او په جلا کالم کې یې ولیکئ.
د URLs لپاره، د بیلګې په توګه، تاسو کولی شئ په جلا توګه ډومین ذخیره کړئ. او که تاسو واقعیا یو ډومین ته اړتیا لرئ، نو یوازې دا کالم وکاروئ، او URLs به هلته پروت وي، او تاسو به حتی دوی ته لاس ورنکړئ.
راځئ وګورو چې توپیر څه دی. ClickHouse یو ځانګړی فعالیت لري چې ډومین محاسبه کوي. دا خورا ګړندی دی ، موږ یې غوره کړی دی. او ، ریښتیني اوسئ ، دا حتی د RFC سره مطابقت نلري ، مګر سره له دې دا هرڅه په پام کې نیسي چې موږ ورته اړتیا لرو.
او په یو حالت کې به موږ په ساده ډول یو آر ایل ترلاسه کړو او ډومین حساب کړو. دا په 166 ملی ثانیو کې کار کوي. او که تاسو یو چمتو شوی ډومین واخلئ، نو دا به یوازې 67 ملی ثانیه وي، د بیلګې په توګه نږدې درې ځله ګړندی. او دا ګړندی ندی ځکه چې موږ اړتیا لرو یو څه محاسبه وکړو ، مګر ځکه چې موږ لږ معلومات لوستل.
له همدې امله یوه غوښتنه، چې ورو ده، په هر ثانیه کې د ګیګابایټ لوړ سرعت لري. ځکه چې دا ډیر ګیګابایټ لوستل کیږي. دا په بشپړه توګه غیر ضروري معلومات دي. غوښتنه داسې ښکاري چې په چټکۍ سره پرمخ ځي، مګر دا بشپړولو لپاره ډیر وخت نیسي.
او که تاسو په ډیسک کې د ډیټا مقدار وګورئ، نو دا معلومه شوه چې URL 126 میګابایټ دی، او ډومین یوازې 5 میګابایټ دی. دا 25 ځله کم وګرځي. مګر سره له دې، غوښتنه یوازې 4 ځله ګړندي اجرا کیږي. مګر دا ځکه چې معلومات ګرم دي. او که دا ساړه وي، نو دا به د ډیسک I/O له امله 25 ځله ګړندی وي.
په هرصورت، که تاسو اټکل وکړئ چې یو ډومین د یو آر ایل په پرتله څومره کوچنی دی، نو دا به شاوخوا 4 ځله کوچنی وي. مګر د ځینو دلیلونو لپاره، ډاټا په ډیسک کې 25 ځله لږ وخت نیسي. ولې؟ د کمپریشن له امله. او URL کمپریس شوی، او ډومین کمپریس شوی. مګر ډیری وختونه URL د کثافاتو یوه ډله لري.
او البته، دا د سم ډیټا ډولونو کارولو لپاره تادیه کوي چې په ځانګړي ډول د مطلوب ارزښتونو لپاره ډیزاین شوي یا مناسب دي. که تاسو په IPv4 کې یاست، نو UInt32* ذخیره کړئ. که IPv6 وي، نو بیا FixedString(16)، ځکه چې د IPv6 پته 128 بټونه دي، د بیلګې په توګه په مستقیم ډول په بائنری بڼه کې زیرمه شوي.
مګر څه که تاسو ځینې وختونه IPv4 پتې او ځینې وختونه IPv6 لرئ؟ هو، تاسو کولی شئ دواړه ذخیره کړئ. یو کالم د IPv4 لپاره، بل د IPv6 لپاره. البته، په IPv4 کې د IPv6 ښودلو لپاره یو اختیار شتون لري. دا به هم کار وکړي، مګر که تاسو ډیری وختونه په غوښتنو کې د IPv4 پتې ته اړتیا لرئ، نو دا به ښه وي چې دا په جلا کالم کې واچوئ.
* ClickHouse اوس جلا IPv4، IPv6 ډیټا ډولونه لري چې ډاټا د شمیرو په څیر په اغیزمنه توګه ذخیره کوي، مګر د تارونو په څیر په اسانۍ سره استازیتوب کوي.
دا هم مهمه ده چې یادونه وکړو چې دا د معلوماتو دمخه پروسس کولو ارزښت لري. د مثال په توګه، تاسو ځینې خام لاګونه ترلاسه کوئ. او شاید تاسو باید دا سمدلاسه په کلیک هاؤس کې ونه واچوئ ، که څه هم دا د هیڅ کولو لپاره خورا لیوالتیا ده او هرڅه به کار وکړي. مګر دا لاهم د امکان وړ محاسبې ترسره کولو ارزښت لري.
د مثال په توګه، د براوزر نسخه. په ځینې نږدې ډیپارټمنټ کې ، کوم چې زه نه غواړم ګوته په ګوته کړم ، د براوزر نسخه د دې په څیر زیرمه شوې ، دا د تار په توګه دی: 12.3. او بیا، د راپور جوړولو لپاره، دوی دا تار اخلي او په یوه صف کې یې ویشي، او بیا د صف په لومړي عنصر کې. په طبیعي توګه، هرڅه ورو کیږي. ما وپوښتل چې ولې دا کار کوي. دوی ماته وویل چې دوی د وخت دمخه اصلاح نه خوښوي. او زه د وخت څخه مخکې خپګان نه خوښوم.
نو پدې حالت کې دا به ډیر سم وي چې په 4 کالمونو ویشل شي. دلته مه وېرېږئ، ځکه چې دا د کلک کور دی. ClickHouse یو کالم ډیټابیس دی. او هرڅومره پاک کوچني کالمونه ، ښه. د 5 براوزر نسخه به وي، 5 کالمونه جوړ کړئ. دا ښه ده.
اوس راځئ وګورو چې څه وکړئ که تاسو ډیر اوږد تارونه ولرئ، ډیر اوږده صفونه. دوی اړتیا نلري په کلیک هاوس کې زیرمه شي. پرځای یې، تاسو کولی شئ یوازې په ClickHouse کې یو پیژندونکی ذخیره کړئ. او دا اوږدې کرښې په کوم بل سیسټم کې واچوئ.
د مثال په توګه، زموږ د تحلیلي خدماتو څخه یو د پیښې پیرامیټونه لري. او که چیرې د پیښو لپاره ډیری پیرامیټونه شتون ولري، موږ په ساده ډول لومړی 512 خوندي کوو چې منځ ته راځي. ځکه چې 512 د افسوس وړ ندی.
او که تاسو نشئ کولی د خپلو ډیټا ډولونو په اړه پریکړه وکړئ ، نو تاسو کولی شئ په کلیک هاوس کې ډاټا هم ثبت کړئ ، مګر د Log ډول په لنډمهاله جدول کې ، د لنډمهاله معلوماتو لپاره ځانګړي. له دې وروسته، تاسو کولی شئ د ارزښتونو ویش تحلیل کړئ چې تاسو هلته لرئ، په عمومي توګه څه شتون لري، او سم ډولونه جوړ کړئ.
*کلک هاؤس اوس د ډیټا ډول لري کوم چې تاسو ته اجازه درکوي د لږې هڅې سره په اغیزمنه توګه تارونه ذخیره کړئ.
اوس راځئ چې یو بل په زړه پورې قضیه وګورو. ځینې وختونه شیان د خلکو لپاره عجیب کار کوي. زه دننه راځم او دا ګورم. او سمدلاسه داسې بریښي چې دا د یو څه تجربه لرونکي ، هوښیار مدیر لخوا ترسره شوی چې د MySQL نسخه 3.23 ترتیب کولو کې پراخه تجربه لري.
دلته موږ زر جدولونه ګورو، چې هر یو یې د ویش پاتې برخه ثبتوي څوک پوهیږي چې د زرو لخوا څه شی دی.
په اصولو کې، زه د نورو خلکو تجربې ته درناوی کوم، په شمول د هغه رنځ پوهه چې د دې تجربې له لارې ترلاسه کیدی شي.
او لاملونه یې ډیر یا لږ روښانه دي. دا زاړه سټیریوټایپونه دي چې ممکن د نورو سیسټمونو سره د کار کولو پرمهال راټول شوي وي. د مثال په توګه، MyISAM جدولونه کلستر شوي ابتدايي کیلي نلري. او د ډیټا ویشلو دا طریقه ممکن د ورته فعالیت ترلاسه کولو لپاره نا امیده هڅه وي.
بل دلیل دا دی چې په لوی میزونو کې د هر ډول بدلون عملیات کول ستونزمن دي. هر څه به بند شي. که څه هم د MySQL په عصري نسخو کې دا ستونزه نوره جدي نه ده.
یا، د بیلګې په توګه، مایکرو شارډینګ، مګر وروسته په دې اړه نور.
په ClickHouse کې دا کولو ته اړتیا نشته، ځکه چې لومړی، لومړنۍ کیلي کلستر شوي، ډاټا د لومړني کیلي لخوا ترتیب شوي.
او ځینې وختونه خلک له ما څخه پوښتنه کوي: "په ClickHouse کې د رینج پوښتنو فعالیت څنګه د میز اندازې پورې اړه لري؟" زه وایم چې دا هیڅ بدلون نه کوي. د مثال په توګه، تاسو د یو ملیارد قطارونو سره میز لرئ او تاسو د یو ملیون قطارونو لړۍ لوستلئ. هر څه سم دي. که په یو میز کې یو ټریلیون قطارونه وي او تاسو یو ملیون قطارونه ولولئ، دا به تقریبا ورته وي.
او، دوهم، هر ډول شیان لکه د لاسي ویشونو ته اړتیا نشته. که تاسو دننه لاړ شئ او وګورئ چې د فایل سیسټم کې څه دي، تاسو به وګورئ چې میز خورا لوی معامله ده. او دننه د پارټیشنونو په څیر یو څه شتون لري. دا دی ، کلیک هاوس ستاسو لپاره هرڅه کوي او تاسو اړتیا نلرئ رنځ ولرئ.
په کلک هاؤس کې بدلون وړیا دی که چیرې کالم اضافه کړئ / پریږدئ.
او تاسو باید کوچني میزونه مه جوړوئ، ځکه که تاسو په میز کې 10 قطارونه یا 10 قطارونه لرئ، نو دا مهمه نده. ClickHouse یو سیسټم دی چې د ټرپوټ اصلاح کوي، نه ځنډ، نو دا د 000 لینونو پروسس کولو لپاره هیڅ معنی نلري.
دا سمه ده چې یو لوی میز وکاروئ. د زړو سټریوټائپونو څخه ځان خلاص کړئ، هرڅه به سم وي.
او د بونس په توګه، په وروستي نسخه کې موږ اوس د دې وړتیا لرو چې په انفرادي برخو کې د ساتنې هر ډول عملیات ترسره کولو لپاره د خپل سري ویش کولو کیلي رامینځته کړو.
د مثال په توګه، تاسو ډیری کوچني میزونو ته اړتیا لرئ، د بیلګې په توګه، کله چې ځینې منځني ډاټا پروسس کولو ته اړتیا وي، تاسو ټوټې ترلاسه کوئ او تاسو اړتیا لرئ چې وروستي میز ته د لیکلو دمخه د دوی بدلون ترسره کړئ. د دې قضیې لپاره، یو په زړه پورې میز انجن شتون لري - StripeLog. دا د TinyLog په څیر دی، یوازې غوره.
* اوس ClickHouse هم لري .
بل ضد نمونه مایکرو شارډینګ دی. د مثال په توګه، تاسو اړتیا لرئ ډاټا شارډ کړئ او تاسو 5 سرورونه لرئ، او سبا به 6 سرورونه وي. او تاسو فکر کوئ چې دا ډاټا څنګه توازن کړئ. او پرځای یې تاسو په 5 ټوټو نه، بلکې په 1 برخو ویشئ. او بیا تاسو د دې مایکروشارډونو څخه هر یو جلا سرور ته نقشه کړئ. او تاسو به ترلاسه کړئ، د مثال په توګه، په یو سرور کې 000 کلیک هاوسونه، د بیلګې په توګه. په جلا بندرونو یا جلا ډیټابیسونو کې جلا مثالونه.
مګر دا په ClickHouse کې خورا ښه ندی. ځکه چې حتی یو کلیک هاوس مثال هڅه کوي د یوې غوښتنې پروسس کولو لپاره د سرور ټولې موجودې سرچینې وکاروي. دا دی، تاسو یو ډول سرور لرئ او دا لري، د بیلګې په توګه، 56 پروسیسر کورونه. تاسو یوه پوښتنه پرمخ وړئ چې یوه ثانیه وخت نیسي او دا به 56 کورونه وکاروي. او که تاسو هلته په یو سرور کې 200 کلیک هاوسونه ځای په ځای کړئ، نو دا معلومه شوه چې 10 تارونه به پیل شي. په عموم کې، هرڅه به ډیر خراب وي.
بل دلیل دا دی چې په دې مواردو کې د کار ویش به نا مساوي وي. ځینې به مخکې پای ته ورسیږي، ځینې به وروسته پای ته ورسیږي. که دا ټول په یوه مثال کې پیښ شوي وي، نو کلیک هاوس به پخپله معلومه کړي چې څنګه د تارونو ترمنځ ډاټا په سمه توګه توزیع کړي.
او بل دلیل دا دی چې تاسو به د TCP له لارې د پروسیسر اړیکه ولرئ. ډاټا باید سیریلائز شي، ډیسیریل شي، او دا د مایکرو شارډونو لوی شمیر دی. دا به په ساده ډول په مؤثره توګه کار ونکړي.
بل ضد نمونه، که څه هم دا په سختۍ سره د انټي پیټرن په نامه یادیږي. دا د مخکې راټولولو لوی مقدار دی.
په عموم کې، مخکې راټولول ښه دي. تاسو یو ملیارد قطارونه درلودل، تاسو یې راټول کړل او دا 1 قطارونه شول، او اوس پوښتنه په سمدستي توګه اجرا کیږي. هرڅه عالي دي. تاسو کولی شئ دا کار وکړئ. او د دې لپاره، حتی ClickHouse د ځانګړي جدول ډول لري، AggregatingMergeTree، کوم چې د ډیټا داخلولو په وخت کې زیاتیدونکي مجموعه ترسره کوي.
مګر ځینې وختونه شتون لري کله چې تاسو فکر کوئ چې موږ به د دې په څیر ډیټا راټول کړو او د دې په څیر ډیټا راټول کړو. او په ځینو ګاونډیو څانګو کې، زه هم نه غواړم ووایم چې کوم یو، دوی د لومړني کیلي لخوا لنډیز کولو لپاره د SummingMergeTree جدولونه کاروي، او شاوخوا 20 کالمونه د لومړني کیلي په توګه کارول کیږي. یوازې په هغه حالت کې ، ما د محرمیت لپاره د ځینې کالمونو نومونه بدل کړل ، مګر دا خورا ډیر دی.
او دا ډول ستونزې رامنځ ته کیږي. لومړی، ستاسو د معلوماتو حجم ډیر کم نه کوي. د مثال په توګه، دا درې ځله کمیږي. درې ځله به د لامحدود تحلیلي وړتیاو د برداشت کولو لپاره ښه قیمت وي چې رامینځته کیږي که ستاسو معلومات راټول شوي نه وي. که معلومات راټول شوي وي، نو د تحلیلونو پرځای تاسو یوازې د افسوس وړ احصایې ترلاسه کوئ.
او په دې کې څه ځانګړی دی؟ حقیقت دا دی چې دا خلک کله ناکله د ګاونډیو څانګو څخه ځي او غوښتنه کوي چې په ابتدايي کیلي کې بل کالم اضافه کړي. دا دی، موږ د دې په څیر معلومات راټول کړل، مګر اوس موږ یو څه نور غواړو. مګر ClickHouse د بدلون لومړني کیلي نلري. له همدې امله، موږ باید په C++ کې ځینې سکریپټونه ولیکو. او زه سکریپټونه نه خوښوم، حتی که دوی په C++ کې وي.
او که تاسو وګورئ چې کلیک هاؤس د څه لپاره رامینځته شوی و ، نو غیر راټول شوي ډاټا دقیقا هغه سناریو ده چې د هغې لپاره رامینځته شوې. که تاسو د غیر راټول شوي معلوماتو لپاره ClickHouse کاروئ، نو تاسو دا سم ترسره کوئ. که تاسو راټول کړئ، دا ځینې وختونه د بخښنې وړ وي.
بله په زړه پورې قضیه په لامحدود لوپ کې پوښتنې دي. ځینې وختونه زه د تولید سرور ته ځم او هلته د شو پروسس لیست ګورم. او هرکله چې زه ومومم چې یو څه ناوړه پیښیږي.
د مثال په توګه، دا ډول. دا سمدلاسه روښانه ده چې هرڅه په یوه غوښتنه کې کیدی شي. یوازې یو آر ایل او لیست هلته ولیکئ.
ولې دا ډول پوښتنې په نه ختمیدونکي لوپ کې خرابې دي؟ که یو شاخص ونه کارول شي، نو تاسو به د ورته معلوماتو ډیری پاسونه ولرئ. مګر که شاخص کارول کیږي، د بیلګې په توګه، تاسو د ru لپاره لومړنۍ کلیدي لرئ او تاسو url = یو څه هلته ولیکئ. او تاسو فکر کوئ چې که یوازې یو URL د میز څخه لوستل شي، هرڅه به سم وي. مګر په حقیقت کې نه. ځکه چې کلیک هاوس هرڅه په بیچونو کې کوي.
کله چې هغه د ډیټا یو ټاکلی سلسله لوستلو ته اړتیا لري ، هغه یو څه نور لوستل کوي ، ځکه چې په کلیک هاوس کې شاخص لږ دی. دا شاخص تاسو ته اجازه نه ورکوي چې په جدول کې یو انفرادي قطار ومومئ، یوازې یو ډول لړۍ. او ډاټا په بلاکونو کې فشار شوي. د یوې کرښې لوستلو لپاره ، تاسو اړتیا لرئ ټول بلاک واخلئ او خلاص یې کړئ. او که تاسو د پوښتنو یوه ډله ترسره کوئ، نو تاسو به ډیر تکرار ولرئ، او تاسو به ډیر کار ولرئ چې بیا تکرار کړئ.
او د بونس په توګه، تاسو کولی شئ په یاد ولرئ چې په ClickHouse کې تاسو باید د IN برخې ته حتی میګابایټ او حتی په سلګونو میګابایټ لیږدولو څخه ویره ونلرئ. زه زموږ له تمرین څخه په یاد لرم چې که چیرې په MySQL کې موږ د IN برخې ته د ارزښتونو یوه ډله لیږدوو، د بیلګې په توګه، موږ د ځینې شمیرو 100 میګابایټ لیږد کوو، نو مای ایس کیو ایل 10 ګیګابایټ حافظه خوري او نور هیڅ شی نه کیږي، هرڅه. خراب کار کوي.
او دوهم دا چې په ClickHouse کې، که ستاسو پوښتنې یو شاخص کاروي، نو دا تل د بشپړ سکین څخه ورو نه وي، د بیلګې په توګه که تاسو اړتیا لرئ چې نږدې ټول جدول ولولئ، دا به په ترتیب سره لاړ شي او ټول میز به ولولي. په عموم کې، هغه به دا پخپله معلومه کړي.
مګر بیا هم ځینې ستونزې شتون لري. د مثال په توګه، دا حقیقت چې د فرعي پوښتنې سره IN شاخص نه کاروي. مګر دا زموږ ستونزه ده او موږ یې باید حل کړو. دلته هیڅ بنسټیز شتون نلري. موږ به یې اصلاح کړو*.
او بله په زړه پورې خبره دا ده چې که تاسو خورا اوږده غوښتنه ولرئ او د توزیع شوي غوښتنې پروسس په جریان کې وي ، نو دا خورا اوږده غوښتنه به هر سرور ته پرته له فشار څخه لیږل کیږي. د مثال په توګه، 100 میګابایټ او 500 سرورونه. او، په وینا، تاسو به 50 ګیګابایټ په شبکه کې لیږدول شوي وي. دا به لیږدول کیږي او بیا به هرڅه په بریالیتوب سره بشپړ شي.
* دمخه کارول؛ هر څه د وعدې سره سم تنظیم شوي.
او یو مناسب عام قضیه ده کله چې غوښتنې د API څخه راځي. د مثال په توګه، تاسو خپل یو ډول خدمت جوړ کړی. او که یو څوک ستاسو خدمت ته اړتیا ولري، نو تاسو API خلاص کړئ او په لفظي توګه دوه ورځې وروسته تاسو وګورئ چې یو څه د نه پوهیدو وړ پیښیږي. هرڅه ډیر بار شوي او ځینې ناوړه غوښتنې په کې راځي چې باید هیڅکله پیښ شوي نه وي.
او یوازې یو حل شتون لري. که تاسو API خلاص کړی وي، نو تاسو به یې پرې کړئ. د مثال په توګه، یو ډول کوټې معرفي کړئ. نور نورمال انتخابونه نشته. که نه، دوی به سمدلاسه یو سکریپټ ولیکي او ستونزې به وي.
او ClickHouse یو ځانګړی ځانګړتیا لري - د کوټا حساب. سربیره پردې، تاسو کولی شئ د خپلې کوټې کیلي انتقال کړئ. دا د مثال په توګه د داخلي کارن ID دی. او کوټې به د هر یو لپاره په خپلواکه توګه محاسبه شي.
اوس یوه بله جالبه خبره. دا په لاسي ډول نقل دی.
زه د ډیری قضیو په اړه پوهیږم چیرې چې د کلیک هاوس د جوړ شوي نقل ملاتړ سره سره ، خلک په لاسي ډول د کلیک هاوس نقل کوي.
اصول څه شی دی؟ تاسو د معلوماتو پروسس کولو پایپ لاین لرئ. او دا په خپلواکه توګه کار کوي، د بیلګې په توګه، په مختلفو ډیټا مرکزونو کې. تاسو ورته ډاټا په کلیک هاوس کې په ورته ډول ولیکئ. ریښتیا، تمرین ښیې چې ډاټا به لاهم ستاسو په کوډ کې د ځینو ځانګړتیاو له امله توپیر ولري. زه امید لرم چې دا ستاسو کې وي.
او د وخت په تیریدو سره به تاسو لاهم په لاسي ډول همغږي کړئ. د مثال په توګه، په میاشت کې یو ځل منتظمین rsync کوي.
په حقیقت کې، په ClickHouse کې جوړ شوي نقل کارول خورا اسانه دي. مګر ممکن یو څه متضاد وي ، ځکه چې د دې لپاره تاسو اړتیا لرئ زوکیپر وکاروئ. زه به د ZooKeeper په اړه څه بد ونه وایم، په اصولو کې، سیسټم کار کوي، مګر داسې پیښیږي چې خلک د جاوا فوبیا له امله نه کاروي، ځکه چې کلیک هاوس یو ښه سیسټم دی، په C++ کې لیکل شوی، چې تاسو یې کارولی شئ. هرڅه به سم شي. او ZooKeeper په جاوا کې دی. او یو څه تاسو حتی نه غواړئ چې وګورئ، مګر بیا تاسو کولی شئ د لاسي نقل څخه کار واخلئ.
ClickHouse یو عملي سیسټم دی. هغه ستاسو اړتیاوې په پام کې نیسي. که تاسو لاسي نقل ولرئ ، نو تاسو کولی شئ یو توزیع شوی جدول رامینځته کړئ چې ستاسو لارښود نقلونه ګوري او د دوی ترمینځ ناکامي کوي. او حتی یو ځانګړی اختیار شتون لري چې تاسو ته اجازه درکوي د فلاپونو څخه مخنیوی وکړئ، حتی که ستاسو لینونه په سیستماتیک ډول توپیر ولري.
نورې ستونزې به رامینځته شي که تاسو د لومړني میز انجنونه کاروئ. ClickHouse یو جوړونکی دی چې د مختلف میز انجنونو ډله لري. د ټولو جدي قضیو لپاره، لکه څنګه چې په اسنادو کې لیکل شوي، د MergeTree کورنۍ میزونه وکاروئ. او ټول پاتې - دا د انفرادي قضیو یا ازموینو لپاره دی.
په MergeTree جدول کې، تاسو اړتیا نلرئ چې هیڅ نیټه او وخت ولرئ. تاسو اوس هم کولی شئ دا وکاروئ. که چیرې نیټه او وخت شتون ونلري، نو ولیکئ چې ډیفالټ 2000 دی. دا به کار وکړي او سرچینو ته اړتیا نلري.
او د سرور په نوې نسخه کې، تاسو حتی کولی شئ مشخص کړئ چې تاسو د ویشلو کیلي پرته دودیز ویش لرئ. همداسې به وي.
له بلې خوا، تاسو کولی شئ د لومړني میز انجنونه وکاروئ. د مثال په توګه، یو ځل ډاټا ډک کړئ او وګورئ، موړ او حذف کړئ. تاسو کولی شئ Log وکاروئ.
یا د منځنۍ پروسس لپاره د کوچنیو حجمونو ذخیره کول StripeLog یا TinyLog دي.
حافظه کارول کیدی شي که چیرې د ډیټا مقدار لږ وي او تاسو کولی شئ په ساده ډول په رام کې یو څه دوه چنده کړئ.
کلیک هاؤس واقعیا له سره تنظیم شوي ډاټا نه خوښوي.
دلته یو عادي مثال دی. دا د URLs لوی شمیر دی. تاسو یې په راتلونکي میز کې واچوئ. او بیا دوی پریکړه وکړه چې د دوی سره یوځای شي، مګر دا به د یوې قاعدې په توګه کار ونکړي، ځکه چې کلیک هاوس یوازې د هش شمولیت ملاتړ کوي. که چیرې د ډیری ډیټا لپاره کافي رام شتون ونلري چې وصل کیدو ته اړتیا لري ، نو شمولیت به کار ونکړي*.
که چیرې ډاټا د لوړې کچې وي، نو اندیښنه مه کوئ، دا په غیر معمولي بڼه کې ذخیره کړئ، URLs مستقیم په اصلي جدول کې ځای پر ځای شوي دي.
* او اوس ClickHouse هم یو ملا جلا کول لري، او دا په داسې شرایطو کې کار کوي چیرې چې منځمهاله ډاټا په رام کې نه وي. مګر دا غیر موثر دی او سپارښتنه په عمل کې پاتې کیږي.
یو څو نور مثالونه، مګر زه دمخه شک لرم چې ایا دوی د نمونې ضد دي که نه.
ClickHouse یوه پیژندل شوې نیمګړتیا لري. دا نه پوهیږي چې څنګه تازه کول *. په ځینو لارو کې، دا حتی ښه دی. که تاسو ځینې مهم معلومات لرئ، د بیلګې په توګه، محاسبه، نو هیڅوک به یې ونه لیږل شي، ځکه چې تازه معلومات شتون نلري.
* په بیچ حالت کې د تازه کولو او حذف کولو ملاتړ ډیر وخت دمخه اضافه شوی.
مګر ځینې ځانګړي لارې شتون لري چې تازه کولو ته اجازه ورکوي لکه څنګه چې په شالید کې. د مثال په توګه، میزونه لکه ReplaceMergeTree. دوی د شالید ادغام پرمهال تازه معلومات کوي. تاسو کولی شئ دا د اصلاح کولو میز په کارولو سره مجبور کړئ. مګر دا ډیر ځله مه کوئ، ځکه چې دا به په بشپړه توګه د ویشلو په اړه بیاکتنه وکړي.
په ClickHouse کې توزیع شوي JOINs هم د پوښتنې پلان کونکي لخوا په خراب ډول اداره کیږي.
خراب، مګر کله ناکله ښه.
د کلیک هاوس کارول یوازې د انتخاب * په کارولو سره د معلوماتو بیرته لوستلو لپاره.
زه به د پیچلو محاسبو لپاره د ClickHouse کارولو وړاندیز ونه کړم. مګر دا په بشپړ ډول ریښتیا ندي، ځکه چې موږ دمخه د دې سپارښتنې څخه لیرې یو. او موږ پدې وروستیو کې په ClickHouse - Catboost کې د ماشین زده کړې ماډلونو پلي کولو وړتیا اضافه کړې. او دا ما ځوروي ځکه چې زه فکر کوم، "څه وحشت دی. دا په هر بایټ کې څو سایکلونه وګرځي! زه واقعیا په بایټونو کې د ساعتونو ضایع کولو څخه نفرت کوم.
مګر مه ویره مه کوئ، ClickHouse نصب کړئ، هرڅه به سم وي. که څه هم، موږ یوه ټولنه لرو. په لاره کې، ټولنه تاسو یاست. او که تاسو کومه ستونزه لرئ، تاسو کولی شئ لږترلږه زموږ چیٹ ته لاړ شئ، او امید دی چې دوی به ستاسو سره مرسته وکړي.
پوښتنې
د راپور لپاره مننه! زه د ClickHouse د غورځیدو په اړه چیرته شکایت کولی شم؟
تاسو کولی شئ همدا اوس ما ته شخصي شکایت وکړئ.
ما پدې وروستیو کې د ClickHouse کارول پیل کړل. ما سمدلاسه د کلی انٹرفیس پریښود.
څومره نمرې.
یو څه وروسته ما د یو کوچني انتخاب سره سرور خراب کړ.
تاسو استعداد لرئ.
ما د GitHub بګ خلاص کړ، مګر دا له پامه غورځول شوی و.
راځئ چې وګورو.
الیکسي ما په راپور کې د ګډون لپاره وهل ، ژمنه یې وکړه چې ما ته ووایی چې تاسو دننه معلوماتو ته څنګه لاسرسی لرئ.
ډیر ساده.
ما دا پرون پوه کړه. نور مشخصات.
هلته هیڅ ناوړه چلونه شتون نلري. دلته یوازې د بلاک لخوا بلاک کمپریشن شتون لري. ډیفالټ LZ4 دی، تاسو کولی شئ ZSTD * فعال کړئ. له 64 کیلوبایټ څخه تر 1 میګابایټ پورې بلاکونه.
* د ځانګړي کمپریشن کوډیکونو لپاره هم ملاتړ شتون لري چې د نورو الګوریتمونو سره په زنځیر کې کارول کیدی شي.
ایا بلاکونه یوازې خام معلومات دي؟
په بشپړه توګه خام نه دی. صفونه شتون لري. که تاسو عددي کالم لرئ، نو بیا په قطار کې شمیرې په یوه صف کې ځای پرځای شوي.
دا صفا ده.
الیکسي، یوه بیلګه چې د IPs په پرتله د UniqExact سره وه، د بیلګې په توګه دا حقیقت چې UniqExact د شمیرو په پرتله د کرښو په واسطه محاسبه کول ډیر وخت نیسي، او داسې نور. که چیرې موږ د پروف ریډینګ په وخت کې د خپلو غوږونو او کاسټ سره یو فینټ وکاروو؟ دا، تاسو داسې ښکاري چې زموږ په ډیسک کې دا ډیر توپیر نلري. که موږ د ډیسک او کاسټ څخه کرښې ولولو، ایا زموږ مجموعه به چټکه وي که نه؟ یا به موږ لاهم دلته یو څه لاسته راوړو؟ ماته داسې ښکاري چې تاسو دا ازموینه کړې، مګر د ځینو دلیلونو لپاره یې په بنچمارک کې نه دی ښودلی.
زه فکر کوم چې دا به د کاسټ کولو پرته ورو وي. په دې حالت کې، IP پته باید د تار څخه تجزیه شي. البته، په ClickHouse کې، زموږ د IP پته تجزیه کول هم غوره شوي. موږ ډېره هڅه وکړه، خو هلته مو شمېرې په لس زره بڼه ليکلې دي. ډیر نا آرامه. له بلې خوا، د UniqExact فعالیت به په تارونو کې ورو کار وکړي، نه یوازې دا چې دا تارونه دي، بلکې د دې لپاره چې د الګوریتم مختلف تخصص غوره شوی. تارونه په ساده ډول په مختلف ډول پروسس کیږي.
څه که موږ یو ډیر ابتدايي ډیټا ډول واخلو؟ د مثال په توګه، موږ د کارونکي id چې موږ یې په کې لرو، د کرښې په توګه لیکلی، او بیا یې سکریبل کړی، ایا دا به ډیر په زړه پورې وي که نه؟
زه شک لرم. زه فکر کوم چې دا به حتی د افسوس وړ وي، ځکه چې په هرصورت، د شمیرو تحلیل یوه جدي ستونزه ده. ماته داسې ښکاري چې دې همکار حتی یو راپور ورکړی چې په لس زره شکل کې د شمیرو تحلیل څومره ستونزمن دی، مګر شاید نه.
الیکسي، د راپور لپاره ډیره مننه! او د ClickHouse لپاره ډیره مننه! زه د پلانونو په اړه پوښتنه لرم. ایا د یوې ځانګړتیا لپاره کوم پلان شتون لري چې لغتونه په بشپړ ډول تازه کړي؟
دا دی، یو جزوی ریبوټ؟
او او. د مای ایس کیو ایل ساحې تنظیم کولو وړتیا په څیر ، د بیلګې په توګه وروسته تازه کول ترڅو یوازې دا ډاټا بار شي که قاموس خورا لوی وي.
یو ډیر په زړه پوری ځانګړتیا. او زه فکر کوم یو چا دا زموږ په چیٹ کې وړاندیز کړی. شاید دا حتی تاسو و.
زه فکر نه کوم چې داسې وي.
ښه، اوس دا معلومه شوه چې دوه غوښتنې شتون لري. او تاسو کولی شئ ورو ورو دا پیل کړئ. مګر زه غواړم تاسو ته سمدستي خبرداری ورکړم چې دا ځانګړتیا د پلي کولو لپاره خورا ساده ده. دا دی، په تیوري کې، تاسو اړتیا لرئ چې په جدول کې د نسخې شمیره ولیکئ او بیا یې ولیکئ: د داسې او داسې څخه لږ نسخه. دا پدې مانا ده چې، ډیری احتمال، موږ به دا لیوالتیا ته وړاندې کړو. ایا تاسو لیوال یاست؟
هو، مګر، له بده مرغه، په C++ کې نه.
ایا ستاسو همکاران پوهیږي چې څنګه په C++ کې لیکل کیږي؟
زه به یو څوک پیدا کړم.
غوره*.
* فیچر د راپور څخه دوه میاشتې وروسته اضافه شوی - د پوښتنې لیکوال دا رامینځته کړی او خپل لیږلی .
ساپی!
سلام! د راپور لپاره مننه! تاسو یادونه وکړه چې کلیک هاوس د دې لپاره موجود ټولو سرچینو مصرف کولو کې خورا ښه دی. او د Luxoft تر څنګ سپیکر د روسیې پوسټ لپاره د هغه د حل په اړه خبرې وکړې. هغه وویل چې دوی واقعیا کلک هاؤس خوښوي ، مګر دوی دا د خپل اصلي سیالي پرځای په دقیق ډول نه کاروي ځکه چې دا ټول CPU خوري. او دوی نشي کولی دا د دوی په جوړښت کې ، د دوی زوکیپر کې د ډاکرانو سره ولګوي. ایا دا ممکنه ده چې په یو ډول کلیک هاؤس محدود کړئ ترڅو دا هر هغه څه مصرف نکړي چې ورته شتون لري؟
هو، دا ممکنه او خورا اسانه ده. که تاسو غواړئ لږ کورونه مصرف کړئ، نو یوازې ولیکئ set max_threads = 1. او دا دی، دا به غوښتنه په یوه کور کې اجرا کړي. سربیره پردې ، تاسو کولی شئ د مختلف کاروونکو لپاره مختلف تنظیمات مشخص کړئ. نو کومه ستونزه نشته. او د Luxoft څخه خپلو همکارانو ته ووایاست چې دا ښه نه ده چې دوی دا ترتیب په اسنادو کې ونه موندل.
الیکسي، سلام! زه غواړم د دې پوښتنې په اړه وپوښتم. دا لومړی ځل ندی چې ما اوریدلي چې ډیری خلک د کلیک هاوس کارولو لپاره د لاګونو ذخیره کولو لپاره پیل کوي. په راپور کې تاسو وویل چې دا کار مه کوئ، د بیلګې په توګه تاسو اړتیا نلرئ اوږد تارونه ذخیره کړئ. تاسو په دې اړه څه فکر کوئ؟
لومړی، لاګونه، د یوې قاعدې په توګه، اوږد تارونه ندي. البته، استثناوې شتون لري. د مثال په توګه، په جاوا کې لیکل شوي ځینې خدمتونه یو استثنا راوباسي، دا لاګ شوی. او همداسې په نه ختمیدونکي لوپ کې، او په هارډ ډرایو کې ځای پای ته رسیږي. د حل لاره خورا ساده ده. که لینونه خورا اوږد وي، نو بیا یې پرې کړئ. اوږد څه معنی لري؟ لسګونه کیلوبایټ خراب دي*.
* د ClickHouse په وروستي نسخو کې، "د تطبیق وړ شاخص ګرانولریت" فعال شوی، کوم چې د ډیری برخې لپاره د اوږد قطارونو ذخیره کولو ستونزه له منځه وړي.
ایا یو کیلوبایټ نورمال دی؟
نوری.
سلام! د راپور لپاره مننه! ما دمخه په چیٹ کې د دې په اړه پوښتنه کړې ، مګر زه په یاد نه یم چې ما ځواب ترلاسه کړی که نه. ایا داسې پلانونه شتون لري چې په یو ډول د CTE په څیر د WITH برخه پراخه کړي؟
تر اوسه نه. زموږ سره برخه یو څه بې ځایه ده. دا زموږ لپاره د یوې کوچنۍ ځانګړتیا په څیر دی.
زه پوهیږم. له تاسو مننه!
د راپور لپاره مننه! ډیر په زړه پوری! نړیواله پوښتنه. ایا د ډیټا حذف کولو ترمیم کولو لپاره کوم پلان شتون لري ، شاید د یو ډول سټبونو په شکل کې؟
لازمه ده. دا زموږ په کتار کې زموږ لومړی دنده ده. موږ اوس په فعاله توګه فکر کوو چې څنګه هرڅه په سمه توګه ترسره کړو. او تاسو باید د کیبورډ فشار پیل کړئ*.
* په کیبورډ کې تڼۍ کیکاږئ او هرڅه یې وکړل.
ایا دا به یو څه د سیسټم فعالیت اغیزه وکړي یا نه؟ ایا داخل کول به د اوس په څیر ګړندي وي؟
شاید پخپله حذف کول او تازه کول به پخپله خورا دروند وي ، مګر دا به د انتخابونو فعالیت یا د داخلولو فعالیت اغیزه ونکړي.
او یوه بله کوچنۍ پوښتنه. په پریزنټشن کې تاسو د لومړني کلیدي په اړه خبرې وکړې. په دې اساس، موږ ویشل لرو، کوم چې د ډیفالټ له مخې میاشتنی دی، سمه ده؟ او کله چې موږ د نیټې حد ټاکو چې په میاشت کې فټ کیږي، نو بیا یوازې دا ویش لوستل کیږي، سمه ده؟
هو.
يوه پوښتنه. که موږ نشو کولی کوم ابتدايي کیلي وټاکو، نو ایا دا سمه ده چې دا په ځانګړې توګه د "نیټې" ساحې سره سم ترسره کړئ ترڅو په شالید کې د دې معلوماتو لږ تنظیم کول وي ترڅو دا په ډیر منظم ډول سره سمون ولري؟ که تاسو د سلسلې پوښتنې نلرئ او تاسو حتی نشئ کولی کومه لومړنۍ کیلي وټاکئ، ایا دا ارزښت لري چې په ابتدايي کیلي کې نیټه واچول شي؟
هو.
شاید دا معنی ولري چې په لومړني کیلي کې یوه ساحه ځای په ځای کړئ چې دا به د دې ساحې لخوا ترتیب شوي وي نو ډیټا به ښه فشار کړي. د مثال په توګه، د کارن ID. کارن، د بیلګې په توګه، ورته سایټ ته ځي. په دې حالت کې، د کاروونکي ID او وخت وساتئ. او بیا ستاسو معلومات به ښه کمپریس شي. د نیټې په څیر، که تاسو واقعیا نلرئ او هیڅکله په نیټو کې د رینج پوښتنې نلرئ، نو تاسو اړتیا نلرئ نیټه په ابتدايي کیلي کې واچوئ.
سمه ده ډیره مننه!
سرچینه: www.habr.com