جيئن ته ClickHouse هڪ خاص سسٽم آهي، ان کي استعمال ڪرڻ وقت ان جي فن تعمير جي خاصيتن کي ڌيان ڏيڻ ضروري آهي. هن رپورٽ ۾، Alexey عام غلطين جي مثالن جي باري ۾ ڳالهائيندو جڏهن ClickHouse استعمال ڪندي، جيڪو غير موثر ڪم جي ڪري سگھي ٿو. عملي مثال ڏيکاريندو ته ڪيئن هڪ يا ٻئي ڊيٽا پروسيسنگ اسڪيم کي چونڊڻ سان ڪارڪردگي کي تبديل ڪري سگھي ٿو.
هيلو سڀ! منهنجو نالو اليڪسي آهي، مان ڪلڪ هائوس ٺاهيان ٿو.
پهرين، مان توهان کي فوري طور تي خوش ڪرڻ لاء جلدي، اڄ مان توهان کي نه ٻڌايان ٿو ته ڪلڪ هائوس ڇا آهي. ايماندار ٿيڻ لاء، مان ان کان ٿڪل آهيان. هر ڀيري مان توهان کي ٻڌايان ٿو ته اهو ڇا آهي. ۽ شايد هرڪو اڳ ۾ ئي ڄاڻي ٿو.
ان جي بدران، مان توهان کي ٻڌايان ٿو ته اتي ڪهڙيون ممڪن غلطيون آهن، اهو آهي، توهان ڪيئن استعمال ڪري سگهو ٿا ClickHouse غلط. حقيقت ۾، ڊڄڻ جي ڪا ضرورت ناهي، ڇو ته اسان ڪلڪ هائوس کي هڪ سسٽم جي طور تي ترقي ڪري رهيا آهيون جيڪو آسان، آسان، ۽ دٻي کان ٻاهر ڪم ڪري ٿو. مون ان کي انسٽال ڪيو، ڪو مسئلو ناهي.
پر توهان کي اڃا به اهو خيال رکڻو پوندو ته هي سسٽم خاص آهي ۽ توهان آساني سان هڪ غير معمولي استعمال جي صورت ۾ اچي سگهو ٿا جيڪو هن سسٽم کي پنهنجي آرام واري علائقي مان ڪڍي ڇڏيندو.
پوء، اتي ڪهڙي قسم جو ريڪ آهي؟ گهڻو ڪري مان واضح شين بابت ڳالهائيندس. سڀ ڪجهه هر ڪنهن لاءِ پڌرو آهي، هرڪو سڀ ڪجهه سمجهي ٿو ۽ خوش ٿي سگهي ٿو ته اهي تمام هوشيار آهن، ۽ جيڪي نه سمجهندا آهن اهي ڪجهه نئين سکندا.
پهريون ۽ آسان مثال، جيڪو، بدقسمتي سان، اڪثر ٿئي ٿو، ننڍن بيچن سان گڏ داخل ٿيڻ جو هڪ وڏو تعداد، يعني ننڍن داخلن جو وڏو تعداد.
جيڪڏهن اسان غور ڪيو ته ڪلڪ هاؤس داخل ڪيئن ڪندو آهي، پوء توهان هڪ درخواست ۾ گهٽ ۾ گهٽ ٽيرا بائيٽ ڊيٽا موڪلي سگهو ٿا. اهو ڪو مسئلو ناهي.
۽ اچو ته ڏسو ته عام ڪارڪردگي ڇا هوندي. مثال طور، اسان وٽ Yandex.Metrica ڊيٽا مان هڪ ٽيبل آهي. مارو. 105 ڪجهه ڪالم. 700 بائيٽ بي ترتيب. ۽ اسان هڪ لک قطارن جي بيچ ۾ سٺي نموني داخل ڪنداسين.
اسان ٽيبل ۾ MergeTree داخل ڪندا آهيون، اهو اڌ ملين قطار في سيڪنڊ ۾ ڦرندو آهي. زبردست. نقل ٿيل جدول ۾ اهو ٿورڙو ننڍو ٿيندو، لڳ ڀڳ 400 قطارون في سيڪنڊ.
۽ جيڪڏهن توهان ڪورم داخل ڪرڻ کي فعال ڪريو ٿا، توهان کي ٿورو گهٽ ملندو، پر اڃا به مهذب ڪارڪردگي، 250 شرطون في سيڪنڊ. ڪورم داخل ڪرڻ ClickHouse* ۾ هڪ غير دستاويزي خصوصيت آهي.
* 2020 تائين، .
جيڪڏهن توهان ڪجهه خراب ڪيو ته ڇا ٿيندو؟ اسان MergeTree ٽيبل ۾ ھڪڙي قطار داخل ڪريو ۽ 59 قطار في سيڪنڊ حاصل ڪريو. اهو 10 ڀيرا سست آهي. ReplicatedMergeTree ۾ - 000 قطار في سيڪنڊ. ۽ جيڪڏهن ڪورم آن ڪيو وڃي ته پوءِ اهو ڦرندو 6 لائينون في سيڪنڊ. منهنجي خيال ۾، اهو ڪجهه قسم جو مطلق گندو آهي. توهان اهڙي سست ڪيئن ڪري سگهو ٿا؟ مون پنهنجي ٽي شرٽ تي به اهو لکيو آهي ته ClickHouse کي سست نه ٿيڻ گهرجي. پر ان جي باوجود ڪڏهن ڪڏهن ائين ٿيندو آهي.
حقيقت ۾ اها اسان جي ڪمزوري آهي. اسان آساني سان هر شي کي ٺيڪ ڪري سگهون ٿا، پر اسان نه ڪيو. ۽ اسان اهو نه ڪيو ڇو ته اسان جي اسڪرپٽ جي ضرورت نه هئي. اسان وٽ اڳ ۾ ئي قصاب هئا. اسان صرف اسان جي داخلا تي بيچ وصول ڪيو، ۽ ڪو مسئلو ناهي. اسان ان کي داخل ڪيو ۽ سڀ ڪجھ ٺيڪ ڪم ڪري ٿو. پر، يقينا، سڀني قسمن جا منظر ممڪن آهن. مثال طور، جڏهن توهان وٽ سرور جو هڪ گروپ آهي جنهن تي ڊيٽا ٺاهي وئي آهي. ۽ اهي اڪثر ڊيٽا داخل نه ڪندا آهن، پر اهي اڃا تائين بار بار داخل ٿيڻ سان ختم ٿيندا آهن. ۽ اسان کي ڪنهن به طرح هن کان بچڻ جي ضرورت آهي.
هڪ ٽيڪنيڪل نقطي نظر کان، نقطي اهو آهي ته جڏهن توهان ڪلڪ ڪيو هاؤس ۾ داخل ڪريو، ڊيٽا ڪنهن به يادگيري ۾ ختم نه ٿيندي. اسان وٽ هڪ حقيقي لاگ ڍانچي به نه آهي MergeTree، پر صرف هڪ MergeTree، ڇاڪاڻ ته اتي نه ڪو لاگ آهي ۽ نه ئي memTable. اسان فوري طور تي ڊيٽا کي فائيل سسٽم ۾ لکندا آهيون، اڳ ۾ ئي ڪالمن ۾ ترتيب ڏنل آهي. ۽ جيڪڏهن توهان وٽ 100 ڪالمن آهن، ته پوءِ 200 کان وڌيڪ فائلن کي الڳ ڊاريڪٽري ۾ لکڻو پوندو. اهو سڀ ڪجهه ڏاڍو ڏکيو آهي.
۽ سوال پيدا ٿئي ٿو: "اهو ڪيئن ڪجي صحيح؟" جيڪڏهن صورتحال اهڙي آهي ته توهان کي اڃا تائين ڪنهن به طريقي سان ڪلڪ ڪيو هائوس ۾ ڊيٽا رڪارڊ ڪرڻ جي ضرورت آهي.
طريقو 1. هي سڀ کان آسان طريقو آهي. ڪجهه قسم جي ورهايل قطار استعمال ڪريو. مثال طور، ڪافڪا. توهان صرف ڪافڪا مان ڊيٽا ڪڍو ۽ ان کي سيڪنڊ ۾ هڪ ڀيرو بيچ ڪريو. ۽ سڀ ڪجھ ٺيڪ ٿي ويندو، توھان رڪارڊ ڪيو، سڀ ڪجھ ٺيڪ ڪم ڪري ٿو.
نقصانات هي آهن ته ڪافڪا هڪ ٻيو وڏو ورهايل نظام آهي. مان پڻ سمجھان ٿو ته ڇا توھان وٽ اڳ ۾ ئي ڪافڪا آھي توھان جي ڪمپني ۾. اهو سٺو آهي، اهو آسان آهي. پر جيڪڏهن اهو موجود ناهي، ته پوءِ توهان کي ٽي ڀيرا سوچڻ گهرجي اڃا تائين هڪ ٻئي ورهايل سسٽم کي پنهنجي منصوبي ۾ ڇڪڻ کان اڳ. ۽ تنهنڪري اهو متبادل تي غور ڪرڻ جي قابل آهي.
طريقو 2. هي هڪ پراڻي اسڪول جو متبادل آهي ۽ ساڳئي وقت تمام سادو آهي. ڇا توھان وٽ آھي ڪجھ قسم جو سرور جيڪو ٺاھي ٿو توھان جا لاگ. ۽ اهو صرف توهان جي لاگن کي فائل ڏانهن لکندو آهي. ۽ هڪ ڀيرو هڪ سيڪنڊ، مثال طور، اسان هن فائل جو نالو مٽائي ڇڏيو ۽ هڪ نئين کي ٽوڙيو. ۽ هڪ الڳ اسڪرپٽ، يا ته ڪرون يا ڪجهه ڊيمن ذريعي، سڀ کان پراڻي فائل وٺي ٿي ۽ ان کي ڪلڪ هائوس ڏانهن لکي ٿو. جيڪڏهن توهان هڪ سيڪنڊ ۾ هڪ ڀيرو لاگ رڪارڊ ڪيو ته پوءِ سڀ ڪجهه ٺيڪ ٿي ويندو.
پر هن طريقي جو نقصان اهو آهي ته جيڪڏهن توهان جو سرور جنهن تي لاگز ٺاهيا ويا آهن، ڪٿي غائب ٿي ويندا آهن، پوء ڊيٽا پڻ غائب ٿي ويندي.
طريقو 3. هڪ ٻيو دلچسپ طريقو آهي، جنهن کي عارضي فائلن جي ضرورت ناهي. مثال طور، توهان وٽ ڪجهه قسم جو اشتهاري اسپنر يا ڪجهه ٻيو دلچسپ ڊيمون آهي جيڪو ڊيٽا ٺاهي ٿو. ۽ توهان ڊيٽا جو هڪ گروپ گڏ ڪري سگهو ٿا سڌو سنئون رام ۾، بفر ۾. ۽ جڏهن ڪافي وقت گذري چڪو آهي، توهان هن بفر کي هڪ طرف رکي، هڪ نئون ٺاهيو، ۽ هڪ الڳ سلسلي ۾، داخل ڪريو جيڪو اڳ ۾ ئي جمع ڪيو ويو آهي ClickHouse ۾.
ٻئي طرف، ڊيٽا پڻ غائب ٿي قتل -9 سان. جيڪڏهن توهان جو سرور حادثو، توهان هن ڊيٽا کي وڃائي ڇڏيو. ۽ ٻيو مسئلو اهو آهي ته جيڪڏهن توهان ڊيٽابيس ۾ لکڻ جي قابل نه هئا ته پوء توهان جي ڊيٽا رام ۾ جمع ٿي ويندي. ۽ يا ته رام ختم ٿي ويندو، يا توهان صرف ڊيٽا وڃائي ڇڏيندؤ.
طريقو 4. ٻيو دلچسپ طريقو. ڇا توھان وٽ ڪجھ قسم جو سرور عمل آھي. ۽ اهو فوري طور تي ڪلڪ هائوس ڏانهن ڊيٽا موڪلي سگهي ٿو، پر اهو هڪ ڪنيڪشن ۾ ڪريو. مثال طور، مون منتقلي-انڪوڊنگ سان گڏ هڪ http درخواست موڪلي: داخل ڪرڻ سان گڏ. ۽ اهو حصو ٺاهي ٿو تمام گهٽ نه، توهان هر لائن موڪلي سگهو ٿا، جيتوڻيڪ هن ڊيٽا کي ترتيب ڏيڻ لاء مٿي هوندو.
بهرحال، هن معاملي ۾ ڊيٽا کي فوري طور تي ڪلڪ هائوس ڏانهن موڪليو ويندو. ۽ ClickHouse انھن کي پاڻ بفر ڪندو.
پر مسئلا پڻ پيدا ٿين ٿا. ھاڻي توھان ڊيٽا وڃائي ويندؤ، بشمول جڏھن توھان جو عمل ماريو ويندو آھي ۽ جيڪڏھن ClickHouse عمل کي ماريو ويندو آھي، ڇاڪاڻتہ اھو ھڪڙو نامڪمل داخل ٿيندو. ۽ ClickHouse inserts ۾ ايٽمي آھن ھڪڙي مخصوص حد تائين قطار جي سائيز ۾. اصول ۾، هي هڪ دلچسپ طريقو آهي. پڻ استعمال ڪري سگھجي ٿو.
طريقو 5. هتي هڪ ٻيو دلچسپ طريقو آهي. ھي آھي ڪجھ قسم جو ڪميونٽي ڊولپڊ سرور ڊيٽا بيچنگ لاءِ. مون ان کي پاڻ نه ڏٺو آهي، تنهنڪري مان ڪجهه به ضمانت نه ٿو ڏئي سگهان. جڏهن ته، ClickHouse پاڻ لاءِ ڪا به ضمانت فراهم نه ڪئي وئي آهي. اهو پڻ کليل ذريعو آهي، پر ٻئي طرف، توهان شايد استعمال ڪيو وڃي ڪجهه معيار جي معيار تي جيڪو اسان مهيا ڪرڻ جي ڪوشش ڪريون ٿا. پر هن شيء لاء - مون کي خبر ناهي، GitHub ڏانهن وڃو، ڪوڊ ڏسو. ٿي سگهي ٿو اهي ڪجهه عام لکيو.
* 2020 تائين، پڻ غور ۾ شامل ڪيو وڃي .
طريقو 6. ٻيو طريقو بفر ٽيبل استعمال ڪرڻ آهي. هن طريقي جو فائدو اهو آهي ته اهو استعمال ڪرڻ شروع ڪرڻ بلڪل آسان آهي. هڪ بفر ٽيبل ٺاهيو ۽ ان ۾ داخل ڪريو.
نقصان اهو آهي ته مسئلو مڪمل طور تي حل نه ڪيو ويو آهي. جيڪڏهن، MergeTree وانگر شرح ۾، توهان کي ڊيٽا کي هڪ بيچ في سيڪنڊ جي حساب سان گروپ ڪرڻو پوندو، پوءِ بفر ٽيبل جي شرح ۾، توهان کي گهٽ ۾ گهٽ ڪيترن هزار في سيڪنڊ تائين گروپ ڪرڻ جي ضرورت آهي. جيڪڏهن اهو 10 في سيڪنڊ کان وڌيڪ آهي، اهو اڃا تائين خراب ٿيندو. ۽ جيڪڏهن توهان ان کي بيچ ۾ داخل ڪيو، ته توهان ڏٺو ته اهو هڪ لک هزار سٽون في سيڪنڊ آهي. ۽ اهو اڳ ۾ ئي ڪافي ڳري ڊيٽا تي آهي.
۽ پڻ بفر جدولن ۾ لاگ نه آھي. ۽ جيڪڏهن توهان جي سرور سان ڪجهه غلط آهي، ته پوء ڊيٽا گم ٿي ويندي.
۽ بونس جي طور تي، اسان کي تازو موقعو مليو ClickHouse تي ڪافڪا کان ڊيٽا حاصل ڪرڻ لاءِ. اتي هڪ ٽيبل انجڻ آهي - ڪافڪا. توهان صرف ٺاهيو. ۽ توهان ان تي مادي نمائندگي کي لڪائي سگهو ٿا. انهي صورت ۾، اهو پاڻ ڪافڪا مان ڊيٽا ڪڍي ڇڏيندو ۽ ان کي ٽيبل ۾ داخل ڪندو جيڪو توهان کي گهربل آهي.
۽ ڇا خاص طور تي هن موقعي جي باري ۾ خوشگوار آهي ته اهو اسان نه هو جيڪو اهو ڪيو. هي هڪ ڪميونٽي خاصيت آهي. ۽ جڏهن مان چوان ٿو ”ڪميونٽي فيچر“، منهنجو مطلب آهي بغير ڪنهن توهين جي. اسان ڪوڊ پڙهيو، هڪ جائزو ورتو، اهو سٺو ڪم ڪرڻ گهرجي.
* 2020 تائين، ساڳئي سپورٽ لاء ظاهر ٿيو آهي .
ڊيٽا داخل ڪرڻ وقت ٻيو ڇا مشڪل يا غير متوقع ٿي سگهي ٿو؟ جيڪڏهن توهان داخل ڪريو قدرن جي درخواست ڪريو ۽ لکو ڪجهه حساب ڪيل اظهار قدرن ۾. مثال طور، now() پڻ هڪ ڳڻپيوڪر اظهار آهي. ۽ انهي صورت ۾، ڪلڪ هاؤس کي مجبور ڪيو ويو آهي ته هر لڪير تي انهن اظهارن جي ترجماني کي شروع ڪيو وڃي، ۽ ڪارڪردگي شدت جي حڪم سان گهٽجي ويندي. اهو بهتر آهي ته هن کان بچڻ لاء.
* هن وقت، مسئلو مڪمل طور تي حل ڪيو ويو آهي، VALUES ۾ ايڪسپريس استعمال ڪرڻ وقت هاڻي ڪا به ڪارڪردگي رجعت ناهي.
هڪ ٻيو مثال اهو آهي جڏهن ڪجهه مسئلا ٿي سگهن ٿا جڏهن توهان وٽ هڪ بيچ تي ڊيٽا آهي جيڪا پارٽيشنن جي گروپ سان تعلق رکي ٿي. ڊفالٽ طور، ClickHouse ورهاڱي مهيني جي حساب سان. ۽ جيڪڏهن توهان هڪ ملين قطارن جو هڪ بيچ داخل ڪيو، ۽ ڪيترن ئي سالن تائين ڊيٽا موجود آهي، ته پوء توهان وٽ ڪيترائي درجن وارا حصا هوندا. ۽ اهو حقيقت جي برابر آهي ته بيچ ڪيترن ئي ڏهن ڀيرا ننڍا هوندا آهن سائيز ۾، ڇاڪاڻ ته اندر اهي هميشه پهرين ورهاڱي ۾ ورهايل آهن.
* تازو، تجرباتي موڊ ۾، ClickHouse شامل ڪيو ڪمپيڪٽ فارميٽ لاءِ chunks ۽ chunks in RAM ۾ لکڻ-اڳتي لاگ سان، جيڪو تقريبن مڪمل طور تي مسئلو حل ڪري ٿو.
هاڻي اچو ته ٻئي قسم جي مسئلي کي ڏسو - ڊيٽا ٽائپنگ.
ڊيٽا ٽائپنگ سخت يا اسٽرنگ ٿي سگهي ٿو. اسٽرنگ اهو آهي جڏهن توهان صرف ان کي ورتو ۽ اعلان ڪيو ته توهان جا سڀئي فيلڊ اسٽرنگ قسم جا آهن. هي بيڪار. ائين ڪرڻ جي ڪا ضرورت ناهي.
اچو ته سمجهون ته اهو ڪيئن ڪجي انهن حالتن ۾ صحيح طريقي سان جڏهن توهان اهو چوڻ چاهيو ته اسان وٽ ڪجهه فيلڊ، هڪ اسٽرنگ آهي، ۽ ڪلڪ هاؤس کي ان کي پاڻ پتوڙڻ ڏيو، ۽ مان پريشان نه ڪندس. پر اهو اڃا تائين ڪجهه ڪوشش ڪرڻ جي قابل آهي.
مثال طور، اسان وٽ هڪ IP پتو آهي. ھڪڙي صورت ۾، اسان ان کي ھڪڙي تار طور محفوظ ڪيو. مثال طور، 192.168.1.1. ۽ ٻي صورت ۾، اهو هڪ قسم جو تعداد هوندو UInt32*. IPv32 پتي لاءِ 4 بٽ ڪافي آهي.
پهرين، عجيب طور تي ڪافي، ڊيٽا کي تقريبا هڪجهڙائي سان گڏ ڪيو ويندو. فرق ضرور هوندو، پر ايترو وڏو ناهي. تنهنڪري ڊسڪ I/O سان ڪو خاص مسئلو ناهي.
پر پروسيسر جي وقت ۽ سوال جي عمل جي وقت ۾ هڪ سنگين فرق آهي.
اچو ته منفرد IP پتي جي تعداد کي ڳڻپ ڪريو جيڪڏھن اھي انگن جي طور تي ذخيرو ٿيل آھن. اهو ڪم ڪري ٿو 137 ملين لائين في سيڪنڊ تائين. جيڪڏهن ساڳيو تارن جي صورت ۾ آهي ته پوءِ 37 ملين لائينون في سيڪنڊ. خبر ناهي اهو اتفاق ڇو ٿيو. مون اهي درخواستون پاڻ پوريون ڪيون. پر اڃا تائين اٽڪل 4 ڀيرا سست.
۽ جيڪڏھن توھان حساب ڪريو ڊسڪ جي جڳھ ۾ فرق، پوء ھڪڙو فرق آھي. ۽ فرق اٽڪل هڪ چوٿون آهي، ڇاڪاڻ ته اتي ڪافي منفرد IP پتا آهن. ۽ جيڪڏھن سٽون ھجن جن ۾ ٿوري تعداد ۾ مختلف معنائون ھجن ته پوءِ اھي آسانيءَ سان ڊڪشنري جي مطابق تقريباً ساڳي حجم ۾ دٻجي وينديون.
۽ چار ڀيرا وقت جو فرق روڊ تي ڪوڙ نٿو ڪري. ٿي سگهي ٿو ته توهان کي ڪا لعنت نه ڏيو، يقينا، پر جڏهن مون کي اهڙو فرق نظر اچي ٿو، اهو مون کي اداس ڪري ٿو.
اچو ته مختلف ڪيسن تي نظر رکون.
1. ھڪڙو ڪيس جڏھن توھان وٽ ڪجھ مختلف منفرد قدر آھن. انهي حالت ۾، اسان هڪ سادي مشق استعمال ڪندا آهيون جيڪا توهان شايد ڄاڻو ٿا ۽ ڪنهن به DBMS لاء استعمال ڪري سگهو ٿا. اهو سڀ ڪجهه سمجهه ۾ اچي ٿو نه رڳو ڪلڪ هائوس لاءِ. صرف ڊيٽابيس ۾ عددي سڃاڻپ ڪندڙ لکو. ۽ توھان تبديل ڪري سگھوٿا تارن ۾ ۽ واپس پنھنجي ايپليڪيشن جي پاسي تي.
مثال طور، توهان وٽ هڪ علائقو آهي. ۽ توھان ان کي محفوظ ڪرڻ جي ڪوشش ڪري رھيا آھيو تار جي طور تي. ۽ اهو اتي لکيو ويندو: ماسڪو ۽ ماسڪو علائقو. ۽ جڏهن مان ڏسان ٿو ته اهو چوي ٿو "ماسڪو"، اهو ڪجهه به ناهي، پر جڏهن اهو ماسڪو آهي، اهو ڪنهن به طرح مڪمل طور تي اداس ٿي ويندو آهي. هي آهي ڪيترا بائيٽ.
ان جي بدران، اسان صرف Ulnt32 ۽ 250 نمبر لکندا آهيون. اسان وٽ Yandex ۾ 250 آهن، پر توهان جا مختلف هوندا. بس صورت ۾، مان چوندس ته ClickHouse جيو بيس سان ڪم ڪرڻ جي هڪ تعمير ٿيل صلاحيت آهي. توهان صرف علائقن سان گڏ هڪ ڊاريڪٽري لکو، جنهن ۾ هڪ درجه بندي شامل آهي، يعني اتي ماسڪو، ماسڪو علائقو، ۽ هر شيء جيڪا توهان جي ضرورت آهي. ۽ توهان درخواست جي سطح تي تبديل ڪري سگهو ٿا.
ٻيو اختيار تقريبن ساڳيو آهي، پر ڪلڪ هائوس اندر سپورٽ سان. هي آهي Enum ڊيٽا جو قسم. توهان صرف Enum اندر اندر سڀ قدر جيڪي توهان جي ضرورت آهي لکندا. مثال طور، ڊوائيس جو قسم ۽ اتي لکو: ڊيسڪ ٽاپ، موبائل، ٽيبليٽ، ٽي وي. مجموعي طور تي 4 آپشن آھن.
نقصان اهو آهي ته توهان کي وقتي طور تي ان کي تبديل ڪرڻ جي ضرورت آهي. صرف هڪ اختيار شامل ڪيو ويو. اچو ته ٽيبل کي تبديل ڪريو. حقيقت ۾، ڪلڪ هاؤس ۾ ٽيبل تبديل ڪرڻ مفت آهي. خاص طور تي Enum لاء مفت ڇو ته ڊسڪ تي ڊيٽا تبديل نٿو ڪري. پر ان جي باوجود، alter حاصل ڪري ٿو هڪ تالا * ٽيبل تي ۽ انتظار ڪرڻ گهرجي جيستائين سڀني چونڊ تي عمل ڪيو وڃي. ۽ ان کان پوءِ ئي تبديلي ڪئي ويندي، يعني اڃا به ڪي تڪليفون آهن.
* ClickHouse جي جديد نسخن ۾، ALTER مڪمل طور تي غير بلاڪ ڪيو ويو آھي.
ٻيو اختيار جيڪو ClickHouse لاءِ بلڪل منفرد آهي خارجي لغات ڳنڍي رهيو آهي. توھان ڪلڪ ڪري سگھوٿا انگ اکر ClickHouse ۾، ۽ پنھنجي ڊائريڪٽري کي ڪنھن به سسٽم ۾ رکو جيڪو توھان لاءِ آسان آھي. مثال طور، توھان استعمال ڪري سگھو ٿا: MySQL، Mongo، Postgres. توھان پنھنجي مائيڪرو سروس پڻ ٺاھي سگھو ٿا جيڪو ھن ڊيٽا کي http ذريعي موڪليندو. ۽ ڪلڪ هائوس سطح تي، توهان هڪ فنڪشن لکندا آهيو جيڪو هن ڊيٽا کي انگن کان تارن ۾ تبديل ڪندو.
اهو هڪ خاص پر تمام ڪارائتو طريقو آهي جيڪو ٻاهرين ميز تي شامل ٿيڻ لاءِ. ۽ اتي ٻه اختيار آهن. ھڪڙي شڪل ۾، ھي ڊيٽا مڪمل طور تي ڪيش ڪيو ويندو، مڪمل طور تي ريم ۾ موجود آھي ۽ ڪجھ فریکوئنسي سان اپڊيٽ ڪيو ويندو. ۽ ٻئي اختيار ۾، جيڪڏهن هي ڊيٽا رام ۾ مناسب نه آهي، ته توهان جزوي طور تي ڪيش ڪري سگهو ٿا.
هتي هڪ مثال آهي. هتي Yandex.Direct آهي. ۽ اتي هڪ اشتهاري ڪمپني ۽ بينر آهي. اتي شايد لکين اشتهاري ڪمپنيون آهن. ۽ اهي تقريباً رام ۾ مناسب آهن. ۽ اتي اربين بينر آھن، اھي مناسب نه آھن. ۽ اسان MySQL مان ڪيش ڪيل ڊڪشنري استعمال ڪندا آهيون.
صرف مسئلو اهو آهي ته ڪيش ٿيل ڊڪشنري ٺيڪ ڪم ڪندي جيڪڏهن هٽ جي شرح 100٪ جي ويجهو آهي. جيڪڏهن اهو ننڍڙو آهي، پوء جڏهن پروسيسنگ سوالن جي ڊيٽا جي هر بيچ لاء، توهان کي اصل ۾ گم ٿيل چابيون وٺڻو پوندو ۽ MySQL کان ڊيٽا حاصل ڪريو. ClickHouse جي باري ۾، مان اڃا تائين ضمانت ڏئي سگهان ٿو - ها، اهو سست نٿو ٿئي، مان ٻين سسٽم بابت نه ڳالهائيندس.
۽ هڪ بونس جي طور تي، لغات ڪلڪ هاؤس ۾ ڊيٽا کي تازه ڪاري ڪرڻ جو هڪ تمام آسان طريقو آهي. يعني توهان وٽ اشتهاري ڪمپنين جي رپورٽ هئي، صارف صرف اشتهاري ڪمپني کي تبديل ڪيو ۽ سڀني پراڻي ڊيٽا ۾، سڀني رپورٽن ۾، اهو ڊيٽا پڻ تبديل ڪيو. جيڪڏهن توهان قطارون سڌو سنئون ٽيبل تي لکندا، انهن کي تازه ڪاري ڪرڻ ناممڪن ٿي ويندو.
ٻيو طريقو جڏهن توهان کي خبر ناهي ته توهان جي تارن جي سڃاڻپ ڪندڙ ڪٿي حاصل ڪجي. توهان صرف ان کي هٽائي سگهو ٿا. ان کان علاوه، آسان ترين اختيار 64-bit هيش وٺڻ آهي.
صرف مسئلو اهو آهي ته جيڪڏهن هيش 64-bit آهي، ته پوء توهان کي لڳ ڀڳ ضرور ٽڪر هوندو. ڇو ته جيڪڏهن اتي هڪ ارب لائينون آهن، ته امڪان اڳ ۾ ئي قابل ذڪر ٿي ويندو آهي.
۽ اهو تمام سٺو نه هوندو ته هن طريقي سان اشتهارن جي ڪمپنين جا نالا هيش ڪرڻ. جيڪڏهن مختلف ڪمپنين جي اشتهاري مهمن کي گڏ ڪيو وڃي، ته پوء ڪجهه ناقابل سمجھ ۾ هوندو.
۽ اتي هڪ سادي چال آهي. سچ، اهو پڻ سنجيده ڊيٽا لاءِ بلڪل موزون ناهي، پر جيڪڏهن ڪا شيءِ تمام سنجيده نه آهي، ته پوءِ صرف ڪلائنٽ جي سڃاڻپ ڪندڙ کي ڊڪشنري ڪيچ ۾ شامل ڪريو. ۽ پوءِ توهان وٽ ٽڪرا هوندا، پر صرف هڪ ڪلائنٽ اندر. ۽ اسان هي طريقو استعمال ڪندا آهيون لنڪ نقشن لاءِ Yandex.Metrica ۾. اسان وٽ URLs آهن، اسان هيش کي ذخيرو ڪندا آهيون. ۽ اسان ڄاڻون ٿا ته، يقينا، ٽڪر آهن. پر جڏهن صفحو ڏيکاريو ويندو آهي، امڪان اهو آهي ته هڪ صارف جي هڪ صفحي تي ڪجهه URLs گڏ ٿيل آهن ۽ ان کي نظر انداز ڪيو ويندو، نظرانداز ڪري سگهجي ٿو.
بونس جي طور تي، ڪيترن ئي عملن لاءِ اڪيلو هيش ڪافي آهي ۽ تارن کي پاڻ کي ڪٿي به ذخيرو ڪرڻ جي ضرورت ناهي.
ٻيو مثال اهو آهي ته تارون مختصر آهن، مثال طور، ويب سائيٽ ڊومينز. انهن کي محفوظ ڪري سگهجي ٿو جيئن آهي. يا، مثال طور، برائوزر جي ٻولي ru 2 بائيٽ آهي. يقينن، مان واقعي بائيٽس لاءِ افسوس محسوس ڪريان ٿو، پر پريشان نه ٿيو، 2 بائيٽس افسوس جي ڳالهه ناهي. مهرباني ڪري ان کي رکو، پريشان نه ڪريو.
ٻيو معاملو اهو آهي جڏهن، ان جي برعڪس، اتي تمام گهڻيون لائينون آهن ۽ انهن ۾ تمام گهڻا منفرد آهن، ۽ جيتوڻيڪ سيٽ ممڪن طور تي لامحدود آهي. ھڪڙو عام مثال آھي ڳولا جا جملا يا URLs. ڳولها جملا، ٽائيپ سميت. اچو ته ڏسون ته هر روز ڪيترا منفرد ڳولها لفظ آهن. ۽ اهو ظاهر ٿئي ٿو ته اهي تقريبن سڀني واقعن جو اڌ آهن. ۽ انهي حالت ۾، توهان شايد اهو سوچيو ته توهان کي ڊيٽا کي عام ڪرڻ جي ضرورت آهي، سڃاڻپ ڪندڙ کي ڳڻڻ، ۽ ان کي الڳ جدول ۾ رکڻو پوندو. پر توهان کي اهو ڪرڻ جي ضرورت ناهي. بس اهي سٽون رکو جيئن اهي آهن.
اهو بهتر آهي ته ڪنهن به شيءِ کي ايجاد نه ڪيو، ڇاڪاڻ ته جيڪڏهن توهان ان کي الڳ الڳ ذخيرو ڪريو ٿا، توهان کي شامل ٿيڻ جي ضرورت پوندي. ۽ هي شامل آهي، بهترين طور تي، ياداشت تائين هڪ بي ترتيبي رسائي، جيڪڏهن اهو اڃا تائين ياداشت ۾ مناسب آهي. جيڪڏهن اهو مناسب نه آهي، ته پوء مسئلا ٿيندا.
۽ جيڪڏهن ڊيٽا محفوظ ٿيل آهي جڳهه ۾، پوء اهو صرف فائل سسٽم کان گهربل ترتيب ۾ پڙهيو ويندو آهي ۽ هر شيء ٺيڪ آهي.
جيڪڏهن توهان وٽ URLs يا ڪي ٻيون پيچيده ڊگها اسٽرنگ آهن، ته پوءِ اهو سمجهڻ جي لائق آهي ته توهان اڳ ۾ ئي ڪنهن قسم جي اقتباس جو اندازو لڳائي سگهو ٿا ۽ ان کي الڳ ڪالمن ۾ لکي سگهو ٿا.
URLs لاء، مثال طور، توھان ڊومين کي الڳ الڳ ذخيرو ڪري سگھو ٿا. ۽ جيڪڏھن توھان کي واقعي ھڪڙي ڊومين جي ضرورت آھي، ته پوءِ صرف ھي ڪالم استعمال ڪريو، ۽ URLs اتي ھوندا، ۽ توھان انھن کي ھٿ به نه پھچائيندا.
اچو ته ڏسو ته فرق ڇا آهي. ClickHouse وٽ ھڪڙو خاص فنڪشن آھي جيڪو ڊومين جي حساب سان. اهو تمام تيز آهي، اسان ان کي بهتر ڪيو آهي. ۽، ايماندار ٿيڻ لاء، اهو پڻ RFC سان عمل نٿو ڪري، پر ان جي باوجود اهو سڀ ڪجهه سمجهي ٿو جيڪو اسان جي ضرورت آهي.
۽ ھڪڙي صورت ۾ اسان صرف URLs حاصل ڪنداسين ۽ ڊومين جو حساب ڪنداسين. اهو ڪم ڪري ٿو 166 ملي سيڪنڊن تائين. ۽ جيڪڏهن توهان هڪ تيار ڪيل ڊومين وٺو ٿا، ته اهو صرف 67 مليسيڪنڊ، يعني تقريبا ٽي ڀيرا تيز ٿي وڃي ٿو. ۽ اهو تيز نه آهي ڇو ته اسان کي ڪجهه حساب ڪرڻ جي ضرورت آهي، پر ڇاڪاڻ ته اسان گهٽ ڊيٽا پڙهون ٿا.
اهو ئي سبب آهي ته هڪ درخواست، جيڪا سست آهي، ان جي رفتار وڌيڪ گيگا بائيٽ في سيڪنڊ آهي. ڇو ته اهو وڌيڪ گيگا بائيٽ پڙهي ٿو. هي مڪمل طور تي غير ضروري ڊيٽا آهي. گذارش لڳي ٿي ته تيزيءَ سان هلندي، پر ان کي مڪمل ٿيڻ ۾ گهڻي وقت لڳندي.
۽ جيڪڏهن توهان ڊسڪ تي ڊيٽا جي مقدار کي ڏسو، اهو ظاهر ٿئي ٿو ته URL 126 ميگا بائيٽ آهي، ۽ ڊومين صرف 5 ميگا بائيٽ آهي. اهو 25 ڀيرا گهٽ نڪتو. پر ان جي باوجود، درخواست تي عملدرآمد صرف 4 ڀيرا تيز آهي. پر اهو آهي ڇو ته ڊيٽا گرم آهي. ۽ جيڪڏهن اهو ٿڌو هجي ها ته شايد ڊسڪ I/O جي ڪري 25 ڀيرا تيز ٿئي ها.
رستي ۾، جيڪڏهن توهان اندازو لڳايو ته هڪ ڊومين URL کان ڪيترو ننڍو آهي، اهو تقريبا 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 افسوس جوڳو ناهي.
۽ جيڪڏهن توهان پنهنجي ڊيٽا جي قسمن تي فيصلو نه ٿا ڪري سگهو، ته پوء توهان ڪلڪ ڪري سگهو ٿا ڊيٽا کي ڪلڪ هائوس ۾، پر لاگ قسم جي عارضي جدول ۾، خاص عارضي ڊيٽا لاءِ. ان کان پوء، توهان تجزيو ڪري سگھو ٿا ته توهان وٽ قدرن جي ڪهڙي تقسيم آهي، اتي عام طور تي ڇا آهي، ۽ صحيح قسم ٺاهي سگهو ٿا.
*ClickHouse ھاڻي ڊيٽا جو قسم آھي جيڪو توهان کي اجازت ڏئي ٿو ته گهٽ ڪوشش سان تارن کي موثر طريقي سان محفوظ ڪري.
هاڻي اچو ته هڪ ٻيو دلچسپ ڪيس ڏسو. ڪڏهن ڪڏهن شيون ماڻهن لاء عجيب ڪم ڪن ٿيون. مان اندر اچان ٿو ۽ اهو ڏسان ٿو. ۽ اهو فوري طور تي لڳي ٿو ته اهو ڪجهه تمام تجربيڪار، سمارٽ منتظم طرفان ڪيو ويو آهي جنهن کي MySQL ورجن 3.23 کي ترتيب ڏيڻ ۾ وسيع تجربو آهي.
هتي اسان هڪ هزار جدولن کي ڏسون ٿا، جن مان هر هڪ کي ورهائڻ جي باقي رهي ٿو، جيڪو ڄاڻي ٿو ته ڇا هزارن سان.
اصولي طور تي، مان ٻين ماڻهن جي تجربي جو احترام ڪريان ٿو، جنهن ۾ ڏکن جي سمجهاڻي به شامل آهي جيڪا هن تجربي ذريعي حاصل ڪري سگهجي ٿي.
۽ سبب وڌيڪ يا گهٽ واضح آهن. اهي پراڻا اسٽريائپائپس آهن جيڪي شايد گڏ ٿين ٿيون جڏهن ٻين سسٽم سان ڪم ڪندي. مثال طور، MyISAM جدولن ۾ ڪلستر ٿيل پرائمري ڪيچ نه آھي. ۽ ڊيٽا کي ورهائڻ جو هي طريقو ساڳيو ڪارڪردگي حاصل ڪرڻ لاء هڪ خطرناڪ ڪوشش ٿي سگهي ٿو.
ٻيو سبب اهو آهي ته وڏي ٽيبل تي ڪنهن به ڦيرڦار جي عمل کي ڪرڻ ڏکيو آهي. سڀ ڪجهه بلاڪ ڪيو ويندو. جيتوڻيڪ MySQL جي جديد نسخن ۾ اهو مسئلو هاڻي ايترو سنجيده ناهي.
يا، مثال طور، microsharding، پر ان کان پوء وڌيڪ.
ڪلڪ هاؤس ۾ ائين ڪرڻ جي ڪا ضرورت ناهي، ڇاڪاڻ ته، پهرين، پرائمري چيڪ ڪلستر ٿيل آهي، ڊيٽا کي پرائمري ڪيئي طرفان ترتيب ڏني وئي آهي.
۽ ڪڏهن ڪڏهن ماڻهو مون کان پڇندا آهن: "ڪئين طريقي سان رينج سوالن جي ڪارڪردگي ClickHouse ۾ جدول جي سائيز جي لحاظ کان مختلف آهي؟" مان چوان ٿو ته اهو سڀ ڪجهه تبديل نٿو ڪري. مثال طور، توهان وٽ هڪ ٽيبل آهي جنهن ۾ هڪ ارب قطارون آهن ۽ توهان هڪ لک قطارن جي حد پڙهي سگهو ٿا. سڀ ڪجھ ٺيڪ آهي. جيڪڏهن هڪ ٽيبل ۾ هڪ ٽريلين قطارون آهن ۽ توهان هڪ لک قطارون پڙهو ٿا، اهو لڳ ڀڳ ساڳيو هوندو.
۽، ٻيو، سڀني قسمن جي شين جهڙوڪ دستي ورهاڱي جي ضرورت ناهي. جيڪڏهن توهان اندر وڃو ۽ ڏسو ته فائل سسٽم تي ڇا آهي، توهان ڏسندا ته ٽيبل هڪ تمام وڏو معاملو آهي. ۽ اتي ڪجھھ آھي اندر partitions وانگر. اھو آھي، ڪلڪ ھاؤس توھان لاءِ سڀ ڪجھ ڪندو آھي ۽ توھان کي تڪليف نه ٿيندي.
ڪلڪ هائوس ۾ ڦيرڦار مفت آهي جيڪڏهن ڪالم شامل ڪريو / ڊراپ ڪريو.
۽ توهان کي ننڍيون ٽيبلون نه ٺاهڻ گهرجن، ڇاڪاڻ ته جيڪڏهن توهان وٽ هڪ ٽيبل ۾ 10 قطارون يا 10 قطارون آهن، ته پوءِ ان سان ڪو به فرق نه پوندو. ڪلڪ هائوس هڪ سسٽم آهي جيڪو بهتر ڪري ٿو throughput، نه دير سان، تنهنڪري اهو 000 لائنن تي عمل ڪرڻ جو ڪو احساس ناهي.
اهو صحيح آهي ته هڪ وڏي ٽيبل استعمال ڪريو. پراڻي اسٽريٽائپائپ کان نجات حاصل ڪريو، سڀ ڪجھ ٺيڪ ٿي ويندو.
۽ بونس جي طور تي، جديد ورزن ۾ اسان وٽ هاڻي قابليت آهي هڪ خودمختيار ورهاڱي واري ڪيئي ٺاهڻ جي لاءِ ته جيئن هر قسم جي سار سنڀال جا عمل انفرادي ورهاڱي تي.
مثال طور، توھان کي گھڻن ننڍڙن جدولن جي ضرورت آھي، مثال طور، جڏھن ڪجھ وچولي ڊيٽا کي پروسيس ڪرڻ جي ضرورت پوندي آھي، توھان کي ٽڪڙا ملندا آھن ۽ توھان کي حتمي جدول تي لکڻ کان پھريائين انھن کي تبديل ڪرڻ جي ضرورت پوندي آھي. هن معاملي لاء، اتي هڪ شاندار ٽيبل انجڻ آهي - StripeLog. اهو TinyLog وانگر آهي، صرف بهتر.
* هاڻي ClickHouse پڻ آهي .
ٻيو antipattern microsharding آهي. مثال طور، توهان کي ڊيٽا کي ڇڪڻ جي ضرورت آهي ۽ توهان وٽ 5 سرور آهن، ۽ سڀاڻي 6 سرور هوندا. ۽ توهان سوچيو ته هن ڊيٽا کي ڪيئن بحال ڪجي. ۽ ان جي بدران توهان 5 شارڊز ۾ نه، پر 1 شارڊز ۾ ورهايو. ۽ پوءِ توھان انھن مان ھر ھڪ microshards کي ھڪ الڳ سرور ڏانھن نقشو ٺاھيو. ۽ توھان حاصل ڪندا، مثال طور، ھڪڙي سرور تي 000 ClickHouses، مثال طور. الڳ پورٽ يا الڳ ڊيٽابيس تي الڳ مثال.
پر ClickHouse ۾ اهو تمام سٺو ناهي. ڇو ته هڪ ڪلڪ هاؤس مثال هڪ درخواست تي عمل ڪرڻ لاءِ سڀني موجود سرور وسيلن کي استعمال ڪرڻ جي ڪوشش ڪري ٿو. اهو آهي، توهان وٽ ڪجهه قسم جو سرور آهي ۽ اهو آهي، مثال طور، 56 پروسيسر ڪور. توهان هڪ سوال هلائي رهيا آهيو جيڪو هڪ سيڪنڊ وٺندو آهي ۽ اهو 56 ڪور استعمال ڪندو. ۽ جيڪڏھن توھان ھڪڙي سرور تي 200 ڪلڪ ھاؤس رکيا، پوء اھو نڪتو ته 10 موضوع شروع ٿي ويندا. عام طور تي، هر شيء تمام خراب ٿي ويندي.
ٻيو سبب اهو آهي ته ڪم جي ورڇ انهن مثالن ۾ اڻ برابري هوندي. ڪي اڳ ختم ٿيندا، ڪي پوءِ ختم ٿيندا. جيڪڏهن اهو سڀ ڪجهه هڪ مثال ۾ ٿيو، ته پوءِ ڪلڪ هاؤس پاڻ پتو لڳائيندو ته ڊيٽا کي ٿريڊز ۾ صحيح طريقي سان ڪيئن ورهايو وڃي.
۽ ٻيو سبب اهو آهي ته توهان وٽ هوندو انٽرپروسيسر ڪميونيڪيشن TCP ذريعي. ڊيٽا کي serialized ڪرڻو پوندو، deserialized، ۽ اهو microshards جو هڪ وڏو تعداد آهي. اهو صرف اثرائتو ڪم نه ڪندو.
هڪ ٻيو antipattern، جيتوڻيڪ اهو مشڪل سان هڪ antipattern سڏيو وڃي ٿو. هي اڳڀرائي جي هڪ وڏي مقدار آهي.
عام طور تي، اڳي گڏ ڪرڻ سٺو آهي. توهان وٽ هڪ ارب قطارون هيون، توهان ان کي گڏ ڪيو ۽ اهو 1 قطار بڻجي ويو، ۽ هاڻي سوال فوري طور تي عمل ڪيو ويو آهي. هر شي عظيم آهي. توهان اهو ڪري سگهو ٿا. ۽ ان لاءِ، ClickHouse وٽ به ھڪ خاص جدول جو قسم آھي، AggregatingMergeTree، جيڪو ڊيٽا داخل ٿيڻ سان گڏ وڌندڙ مجموعي کي انجام ڏئي ٿو.
پر اهڙا وقت آهن جڏهن توهان سوچيو ٿا ته اسان هن طرح ڊيٽا کي گڏ ڪنداسين ۽ هن وانگر مجموعي ڊيٽا. ۽ ڪجهه پاڙيسري ڊپارٽمينٽ ۾، مان اهو به نه چوڻ چاهيان ٿو ته ڪهڙو، اهي استعمال ڪن ٿا SummingMergeTree جدولن کي اختصار ڪرڻ لاءِ پرائمري ڪي، ۽ اٽڪل 20 ڪالمن استعمال ڪيا ويندا آهن بنيادي ڪي جي طور تي. بس صورت ۾، مون ڪجهه ڪالمن جا نالا تبديل ڪيا آهن رازداري لاء، پر اهو تمام گهڻو آهي.
۽ اهڙا مسئلا پيدا ٿين ٿا. پهرين، توهان جي ڊيٽا جو مقدار تمام گهڻو گهٽ نه ٿو. مثال طور، اهو ٽي ڀيرا گھٽجي ٿو. لامحدود تجزياتي صلاحيتن کي برداشت ڪرڻ لاءِ ٽي دفعا سٺي قيمت هوندي جيڪا پيدا ٿيندي جيڪڏهن توهان جو ڊيٽا گڏ نه ڪيو ويو آهي. جيڪڏهن ڊيٽا گڏ ڪئي وئي آهي، پوء اينالائيٽڪس جي بدران توهان صرف ڏکيا انگ اکر حاصل ڪندا.
۽ ان ۾ ڪهڙي خاص ڳالهه آهي؟ حقيقت هيءَ آهي ته پاڙيسري کاتي جا اهي ماڻهو ڪڏهن ڪڏهن ويندا آهن ته پرائمري ڪي ۾ ٻيو ڪالم شامل ڪرڻ لاءِ. اهو آهي، اسان ڊيٽا کي هن طرح گڏ ڪيو، پر هاڻي اسان ٿورو وڌيڪ چاهيون ٿا. پر ClickHouse وٽ ڪو به الٽر پرائمري چيڪ نه آھي. تنهن ڪري، اسان کي C++ ۾ ڪجهه اسڪرپٽ لکڻو پوندو. ۽ مون کي اسڪرپٽ پسند نه آهي، جيتوڻيڪ اهي C++ ۾ آهن.
۽ جيڪڏھن توھان ڏسو ته ڪھڙي لاءِ ClickHouse ٺاھيو ويو، پوءِ غير مجموعي ڊيٽا بلڪل اھو منظر آھي جنھن لاءِ اھو پيدا ٿيو ھو. جيڪڏھن توھان استعمال ڪري رھيا آھيو ClickHouse غير مجموعي ڊيٽا لاءِ، پوءِ توھان ان کي صحيح ڪري رھيا آھيو. جيڪڏهن توهان مجموعي طور تي، اهو ڪڏهن ڪڏهن قابل معافي آهي.
ٻيو دلچسپ ڪيس هڪ لامحدود لوپ ۾ سوال آهي. ڪڏهن ڪڏهن مان ڪجهه پروڊڪٽ سرور ڏانهن وڃان ٿو ۽ اتي شو پروسيس لسٽ ڏسو. ۽ هر وقت مون کي دريافت ڪيو ته ڪجهه خوفناڪ ٿي رهيو آهي.
مثال طور، هن وانگر. اهو فوري طور تي واضح آهي ته هر شي هڪ درخواست ۾ ٿي سگهي ٿي. بس url لکو ۽ اتي لسٽ.
لامحدود لوپ ۾ اهڙا ڪيترائي سوال ڇو خراب آهن؟ جيڪڏهن هڪ انڊيڪس استعمال نه ڪيو ويو آهي، ته توهان وٽ ساڳئي ڊيٽا تي ڪيترائي پاسا هوندا. پر جيڪڏهن انڊيڪس استعمال ڪيو وڃي، مثال طور، توهان وٽ ru لاءِ پرائمري ڪيئي آهي ۽ توهان url = اتي ڪجهه لکو ٿا. ۽ توهان سوچيو ته جيڪڏهن ٽيبل مان صرف هڪ URL پڙهي وڃي، سڀ ڪجهه ٺيڪ ٿي ويندو. پر اصل ۾ نه. ڇاڪاڻ ته ڪلڪ هائوس بيچ ۾ سڀ ڪجهه ڪندو آهي.
جڏهن هن کي ڊيٽا جي هڪ خاص حد کي پڙهڻ جي ضرورت آهي، هو ٿورو وڌيڪ پڙهي ٿو، ڇاڪاڻ ته ڪلڪ هائوس ۾ انڊيڪس گهٽ آهي. هي انڊيڪس توهان کي ٽيبل ۾ هڪ انفرادي قطار ڳولڻ جي اجازت نٿو ڏئي، صرف ڪجهه قسم جي حد. ۽ ڊيٽا بلاڪ ۾ ٺهيل آهي. ھڪڙي لڪير کي پڙھڻ لاء، توھان کي پورو بلاڪ کڻڻ ۽ ان کي کولڻ جي ضرورت آھي. ۽ جيڪڏهن توهان سوالن جو هڪ گروپ ڪري رهيا آهيو، توهان وٽ تمام گهڻو اوورليپ هوندو، ۽ توهان کي بار بار ڪرڻ لاءِ تمام گهڻو ڪم ڪرڻو پوندو.
۽ بونس طور، توھان نوٽ ڪري سگھوٿا ته ڪلڪ ھاؤس ۾ توھان کي IN سيڪشن ۾ ايستائين ميگا بائيٽ ۽ حتي سوين ميگا بائيٽ منتقل ڪرڻ کان ڊپ نه ٿيڻ گھرجي. مون کي اسان جي مشق کان ياد آهي ته جيڪڏهن MySQL ۾ اسان قدرن جو هڪ گروپ IN سيڪشن ڏانهن منتقل ڪريون ٿا، مثال طور، اسان اتي 100 ميگا بائيٽ ڪجهه نمبرن کي منتقل ڪريون ٿا، پوء MySQL 10 گيگا بائيٽ ميموري کي کائي ٿو ۽ ٻيو ڪجهه به نه ٿيندو، سڀ ڪجهه. خراب ڪم ڪري ٿو.
۽ ٻيو اهو آهي ته ڪلڪ هاؤس ۾، جيڪڏهن توهان جا سوال هڪ انڊيڪس استعمال ڪندا آهن، ته پوءِ اهو هميشه مڪمل اسڪين کان وڌيڪ سست نه هوندو آهي، يعني جيڪڏهن توهان کي لڳ ڀڳ پوري ٽيبل پڙهڻ جي ضرورت آهي، ته اها ترتيب سان ويندي ۽ پوري ٽيبل کي پڙهي ويندي. عام طور تي، هو ان کي پنهنجي پاڻ تي سمجهندو.
پر ان جي باوجود ڪجهه مشڪلاتون آهن. مثال طور، حقيقت اها آهي ته IN هڪ ذيلي سوال سان انڊيڪس استعمال نٿو ڪري. پر اهو اسان جو مسئلو آهي ۽ اسان کي ان کي حل ڪرڻ جي ضرورت آهي. هتي بنيادي شيء ناهي. اسان ان کي درست ڪنداسين*.
۽ ٻي دلچسپ ڳالهه اها آهي ته جيڪڏهن توهان وٽ تمام گهڻي ڊگهي درخواست آهي ۽ تقسيم ٿيل درخواست پروسيسنگ جاري آهي، ته پوءِ اها تمام ڊگهي درخواست هر سرور ڏانهن موڪلي ويندي بغير ڪمپريشن جي. مثال طور، 100 ميگا بائيٽ ۽ 500 سرور. ۽، مطابق، توهان وٽ هوندو 50 گيگا بائيٽ نيٽ ورڪ تي منتقل ٿيل. ان کي منتقل ڪيو ويندو ۽ پوء سڀڪنھن شيء کي ڪاميابي سان مڪمل ڪيو ويندو.
* اڳ ۾ ئي استعمال ڪندي؛ واعدي مطابق سڀ ڪجھ ٺيڪ ٿي ويو.
۽ ھڪڙو عام ڪيس آھي جڏھن درخواستون API کان اچن ٿيون. مثال طور، توهان ڪجهه قسم جي پنهنجي خدمت ٺاهي. ۽ جيڪڏهن ڪنهن کي توهان جي خدمت جي ضرورت آهي، ته پوء توهان API کوليو ۽ لفظي طور تي ٻه ڏينهن بعد توهان ڏسندا ته ڪجهه ناقابل فهم ٿي رهيو آهي. سڀ ڪجهه اوور لوڊ ٿيل آهي ۽ ڪجهه خوفناڪ درخواستون اچي رهيون آهن جيڪي ڪڏهن به نه ٿيڻ گهرجن ها.
۽ اتي رڳو هڪ حل آهي. جيڪڏهن توهان API کوليو آهي، ته توهان کي ان کي ڪٽ ڪرڻو پوندو. مثال طور، ڪجهه قسم جي ڪوٽا متعارف ڪرايو. ٻيو ڪو به عام اختيار نه آهي. ٻي صورت ۾، اهي فوري طور تي هڪ اسڪرپٽ لکندا ۽ مسئلا پيدا ٿيندا.
۽ ClickHouse ۾ هڪ خاص خصوصيت آهي - ڪوٽا حساب ڪتاب. ان کان علاوه، توھان پنھنجي ڪوٽا جي چاٻي کي منتقل ڪري سگھو ٿا. هي آهي، مثال طور، اندروني صارف ID. ۽ ڪوٽا انهن مان هر هڪ لاءِ آزاديءَ سان ڳڻيا ويندا.
هاڻي هڪ ٻي دلچسپ ڳالهه. هي دستي نقل آهي.
مون کي ڪيترن ئي ڪيسن جي خبر آهي جتي، ڪلڪ هائوس جي بلٽ ان ريپليڪشن سپورٽ هجڻ جي باوجود، ماڻهو ڪلڪ هاؤس کي دستي طور تي نقل ڪندا آهن.
اصول ڇا آهي؟ توهان وٽ ڊيٽا پروسيسنگ پائپ لائن آهي. ۽ اهو آزاديء سان ڪم ڪري ٿو، مثال طور، مختلف ڊيٽا سينٽرن ۾. توهان ساڳئي ڊيٽا کي ساڳئي طريقي سان ڪلڪ ڪريو هائوس ۾ لکندا آهيو. سچ، مشق ڏيکاري ٿو ته ڊيٽا اڃا به مختلف ٿي ويندي توهان جي ڪوڊ ۾ ڪجهه خاصيتن جي ڪري. مون کي اميد آهي ته اهو توهان ۾ آهي.
۽ وقت وقت تي توهان کي اڃا به دستي طور تي هم وقت سازي ڪرڻو پوندو. مثال طور، مهيني ۾ هڪ ڀيرو منتظمين rsync ڪندا آهن.
حقيقت ۾، ڪلڪ هاؤس ۾ ٺهيل نقل کي استعمال ڪرڻ تمام آسان آهي. پر اتي ڪجھ تضاد ٿي سگھي ٿو، ڇو ته ھن لاء توھان کي استعمال ڪرڻ جي ضرورت آھي ZooKeeper. مان ZooKeeper جي باري ۾ ڪجھ به خراب نه چوندس، اصولي طور تي، سسٽم ڪم ڪري ٿو، پر ائين ٿئي ٿو ته ماڻهو جاوا فوبيا جي ڪري ان کي استعمال نٿا ڪن، ڇاڪاڻ ته ڪلڪ هائوس هڪ تمام سٺو سسٽم آهي، جيڪو C++ ۾ لکيل آهي، جيڪو توهان استعمال ڪري سگهو ٿا ۽ سڀ ڪجھ ٺيڪ ٿي ويندو. ۽ ZooKeeper جاوا ۾ آهي. ۽ ڪنهن به طرح توهان ڏسڻ به نٿا چاهيو، پر پوءِ توهان استعمال ڪري سگهو ٿا دستي نقل.
ClickHouse هڪ عملي نظام آهي. هوءَ توهان جي ضرورتن تي غور ڪندي. جيڪڏهن توهان وٽ دستي نقل آهي، ته پوءِ توهان ٺاهي سگهو ٿا ورهايل ٽيبل جيڪو توهان جي دستي نقلن کي ڏسندو آهي ۽ انهن جي وچ ۾ هڪ ناڪامي ڪندو آهي. ۽ اتي پڻ ھڪڙو خاص اختيار آھي جيڪو توھان کي فلاپ کان بچڻ جي اجازت ڏئي ٿو، جيتوڻيڪ توھان جون لائينون منظم طور تي مختلف آھن.
وڌيڪ مسئلا پيدا ٿي سگھي ٿي جيڪڏھن توھان استعمال ڪريو پرائمري ٽيبل انجڻ. ClickHouse ھڪڙو ٺاھيندڙ آھي جنھن ۾ مختلف ٽيبل انجڻين جو ھڪڙو گروپ آھي. سڀني سنگين ڪيسن لاءِ، جيئن دستاويز ۾ لکيل آهي، MergeTree خاندان مان ٽيبل استعمال ڪريو. ۽ باقي سڀ - اهو ائين آهي، انفرادي ڪيسن لاء يا ٽيسٽ لاء.
هڪ MergeTree ٽيبل ۾، توهان کي ڪنهن به تاريخ ۽ وقت جي ضرورت ناهي. توھان اڃا تائين استعمال ڪري سگھو ٿا. جيڪڏهن ڪا تاريخ ۽ وقت نه آهي، لکو ته ڊفالٽ 2000 آهي. اهو ڪم ڪندو ۽ وسيلن جي ضرورت نه هوندي.
۽ سرور جي نئين ورزن ۾، توهان اهو به بيان ڪري سگهو ٿا ته توهان وٽ ورهاڱي جي چاٻي کان سواء ڪسٽم ورهاڱي آهي. ائين ئي ٿيندو.
ٻئي طرف، توهان استعمال ڪري سگهو ٿا پرائمري ٽيبل انجڻ. مثال طور، ڊيٽا کي هڪ ڀيرو ڀريو ۽ ڏسو، موڙ ۽ حذف ڪريو. توهان لاگ استعمال ڪري سگهو ٿا.
يا وچولي پروسيسنگ لاءِ ننڍي مقدار کي ذخيرو ڪرڻ آهي StripeLog يا TinyLog.
ميموري استعمال ڪري سگهجي ٿي جيڪڏهن ڊيٽا جو مقدار ننڍڙو آهي ۽ توهان صرف رام ۾ ڪجهه ٽوڙي سگهو ٿا.
ClickHouse واقعي پسند نه ڪندو آھي renormalized ڊيٽا.
هتي هڪ عام مثال آهي. هي URLs جو هڪ وڏو تعداد آهي. توھان انھن کي ايندڙ ٽيبل ۾ رکو. ۽ پوءِ انھن فيصلو ڪيو ته انھن سان شامل ٿيو، پر اھو ڪم نه ڪندو، ضابطي جي طور تي، ڇاڪاڻ ته ClickHouse صرف ھش جوائن کي سپورٽ ڪري ٿو. جيڪڏهن ڪافي ڊيٽا لاءِ ڪافي RAM نه آهي جنهن کي ڳنڍڻ جي ضرورت آهي، پوءِ JOIN ڪم نه ڪندو*.
جيڪڏهن ڊيٽا اعلي ڪارڪردگي جي آهي، پوء پريشان نه ڪريو، ان کي غير معمولي شڪل ۾ ذخيرو ڪريو، URLs سڌو سنئون مکيه جدول ۾ جاء تي آهن.
* ۽ ھاڻي ClickHouse ۾ به ھڪ مرج جوائنٽ آھي، ۽ اھو ڪم ڪري ٿو انھن حالتن ۾ جتي وچولي ڊيٽا RAM ۾ نه ٺھي. پر اهو غير اثرائتو آهي ۽ سفارش لاڳو رهي ٿي.
ڪجھ وڌيڪ مثال، پر مون کي اڳ ۾ ئي شڪ آهي ته اهي مخالف نموني آهن يا نه.
ClickHouse ۾ ھڪڙو ڄاتل نقص آھي. اها خبر ناهي ته ڪيئن تازه ڪاري *. ڪجھ طريقن ۾، اھو بھترين آھي. جيڪڏهن توهان وٽ ڪجهه اهم ڊيٽا آهي، مثال طور، اڪائونٽنگ، پوء ڪو به ان کي موڪلڻ جي قابل نه هوندو، ڇو ته ڪا به تازه ڪاري ناهي.
* بيچ موڊ ۾ تازه ڪاري ۽ حذف ڪرڻ جي حمايت گهڻو وقت اڳ شامل ڪيو ويو آهي.
پر ڪجھ خاص طريقا آھن جيڪي اپڊيٽ جي اجازت ڏين ٿيون ڄڻڪ پس منظر ۾. مثال طور، ٽيبل وانگر ReplaceMergeTree. اهي پس منظر ضم ڪرڻ دوران تازه ڪاري ڪندا آهن. توھان ھن کي زور ڏئي سگھوٿا اصلاحي ٽيبل استعمال ڪندي. پر اهو گهڻو ڪري نه ڪريو، ڇاڪاڻ ته اهو مڪمل طور تي ورهاڱي کي ختم ڪري ڇڏيندو.
ClickHouse ۾ ورهايل JOINs پڻ سوالن جي منصوبه بندي ڪندڙ طرفان خراب طريقي سان سنڀاليل آھن.
خراب، پر ڪڏهن ڪڏهن ٺيڪ.
استعمال ڪندي ڪلڪ هاؤس صرف ڊيٽا کي پڙهڻ لاءِ چونڊيو * استعمال ڪندي.
مان مشڪل حسابن لاءِ ClickHouse استعمال ڪرڻ جي سفارش نه ڪندس. پر اهو مڪمل طور تي درست ناهي، ڇو ته اسان اڳ ۾ ئي هن سفارش کان پري ٿي رهيا آهيون. ۽ اسان تازو شامل ڪيو آهي مشين لرننگ ماڊل لاڳو ڪرڻ جي صلاحيت ClickHouse - Catboost. ۽ اهو مون کي پريشان ڪري ٿو ڇاڪاڻ ته مان سمجهان ٿو، "ڪهڙو خوفناڪ. هي اهو آهي ته ڪيترا سائيڪل في بائيٽ اهو نڪرندو آهي! مون کي بائيٽس تي ڪلاڪ ضايع ڪرڻ کان نفرت آهي.
پر ڊڄو نه، انسٽال ڪريو ClickHouse، سڀ ڪجھ ٺيڪ ٿي ويندو. جيڪڏهن ڪجهه، اسان وٽ هڪ ڪميونٽي آهي. رستي جي ذريعي، ڪميونٽي توهان آهيو. ۽ جيڪڏھن توھان کي ڪو مسئلو آھي، توھان گھٽ ۾ گھٽ اسان جي چيٽ ڏانھن وڃو، ۽ اميد آھي ته اھي توھان جي مدد ڪندا.
توهان جا سوال
رپورٽ لاءِ مهرباني! مان ڪلڪ هائوس جي حادثي بابت ڪٿي شڪايت ڪري سگهان ٿو؟
توهان هن وقت مون کي ذاتي طور تي شڪايت ڪري سگهو ٿا.
مون تازو استعمال ڪرڻ شروع ڪيو ClickHouse. مون فوري طور تي ڪلائي انٽرفيس کي ڇڏي ڏنو.
ڇا هڪ سکور.
ٿوري دير کان پوء مون سرور کي هڪ ننڍڙي چونڊ سان تباهه ڪيو.
توهان وٽ قابليت آهي.
مون هڪ GitHub بگ کوليو، پر ان کي نظرانداز ڪيو ويو.
اچو ته ڏسو.
اليڪسي مون کي رپورٽ ۾ شرڪت ڪرڻ لاءِ فريب ڪيو، مون کي ٻڌائڻ جو واعدو ڪيو ته توهان اندر جي ڊيٽا کي ڪيئن پهچندا آهيو.
تمام سادو.
مون کي ڪالهه اهو احساس ٿيو. وڌيڪ تفصيل.
اتي ڪي به خوفناڪ چالون نه آهن. هتي صرف بلاڪ-بلاڪ ڪمپريشن آهي. ڊفالٽ LZ4 آهي، توهان ZSTD* کي فعال ڪري سگهو ٿا. بلاڪ 64 ڪلو بائيٽ کان 1 ميگا بائيٽ تائين.
* خاص ڪمپريشن ڪوڊيڪس لاءِ سپورٽ پڻ آهي جيڪا ٻين الگورتھم سان زنجير ۾ استعمال ٿي سگهي ٿي.
ڇا بلاڪ صرف خام ڊيٽا آهن؟
مڪمل طور تي خام ناهي. صفون آهن. جيڪڏهن توهان وٽ هڪ عددي ڪالم آهي، ته پوءِ قطار ۾ نمبر هڪ صف ۾ رکيل آهن.
اهو واضح آهي.
Alexey، هڪ مثال جيڪو IPs مٿان UniqExact سان هو، يعني حقيقت اها آهي ته UniqExact کي انگن جي ڀيٽ ۾ لائينن جي حساب سان حساب ڪرڻ ۾ گهڻي وقت لڳي ٿي، وغيره. ڇا جيڪڏهن اسان پروف ريڊنگ جي وقت پنهنجي ڪنن ۽ ڪاسٽ سان فينٽ استعمال ڪريون؟ اهو آهي، توهان اهو محسوس ڪيو آهي ته اسان جي ڊسڪ تي اهو بلڪل مختلف ناهي. جيڪڏهن اسان ڊسڪ ۽ ڪاسٽ مان لائينون پڙهون، ته اسان جا مجموعا تيز ٿيندا يا نه؟ يا ڇا اسان اڃا تائين هتي ٿورو فائدو حاصل ڪنداسين؟ اهو مون کي لڳي ٿو ته توهان هن کي آزمائي ڪئي، پر ڪجهه سببن لاء ان کي معيار ۾ ظاهر نه ڪيو.
منهنجو خيال آهي ته اهو بغير ڪاسٽ ڪرڻ جي ڀيٽ ۾ سست هوندو. انهي حالت ۾، IP پتي کي اسٽرنگ مان پارس ڪيو وڃي. يقينا، ڪلڪ هاؤس تي، اسان جي IP پتي جي تجزيه پڻ بهتر ڪئي وئي آهي. اسان ڏاڍي ڪوشش ڪئي، پر اُتي توهان جا انگ ڏهه هزارن جي شڪل ۾ لکيل آهن. تمام بي آرامي. ٻئي طرف، UniqExact فنڪشن اسٽرنگ تي سست ڪم ڪندو، نه رڳو ان ڪري ته اهي تارون آهن، پر ان ڪري به ڇاڪاڻ ته الگورٿم جي مختلف اسپيشلائيزيشن کي چونڊيو ويو آهي. اسٽرنگ کي صرف مختلف طريقي سان پروسيس ڪيو ويو آهي.
ڇا جيڪڏهن اسان هڪ وڌيڪ ابتدائي ڊيٽا جو قسم وٺون؟ مثال طور، اسان صارف جي آئي ڊي، جنهن ۾ اسان وٽ آهي، ان کي هڪ لڪير طور لکيو، ۽ پوء ان کي ڇڪايو، ڇا اهو وڌيڪ مزو ايندو يا نه؟
مون کي شڪ آهي. منهنجو خيال آهي ته اهو به وڌيڪ اداس هوندو، ڇاڪاڻ ته سڀ کان پوء، انگن اکرن کي هڪ سنگين مسئلو آهي. مون کي لڳي ٿو ته هن همراهه هڪ رپورٽ به ڏني هئي ته ڏهه هزارن جي شڪل ۾ انگن کي پارس ڪرڻ ڪيترو ڏکيو آهي، پر شايد نه.
Alexey، رپورٽ لاء تمام گهڻو مهرباني! ۽ ClickHouse لاء توهان جي وڏي مهرباني! مون وٽ منصوبن بابت هڪ سوال آهي. لغتن کي نامڪمل طور تي اپڊيٽ ڪرڻ لاءِ فيچر لاءِ ڪي منصوبا آهن؟
اهو آهي، هڪ جزوي ريبوٽ؟
ها ها. اتي هڪ MySQL فيلڊ سيٽ ڪرڻ جي صلاحيت وانگر، يعني تازه ڪاري ڪرڻ کان پوء ته جيئن صرف هي ڊيٽا لوڊ ٿئي ٿي جيڪڏهن لغت تمام وڏي آهي.
هڪ تمام دلچسپ خصوصيت. ۽ مان سمجهان ٿو ته ڪنهن شخص ان کي اسان جي چيٽ ۾ تجويز ڪيو. ٿي سگهي ٿو ته اهو به توهان هو.
مان ايئن نٿو سوچيان.
عظيم، هاڻي اهو ظاهر ٿيو ته ٻه درخواستون آهن. ۽ توهان سست رفتار سان شروع ڪري سگهو ٿا. پر مان توهان کي فوري طور تي ڊيڄارڻ چاهيان ٿو ته هي خاصيت لاڳو ڪرڻ بلڪل آسان آهي. اهو آهي، نظريي ۾، توهان کي صرف جدول ۾ نسخو نمبر لکڻ جي ضرورت آهي ۽ پوء لکو: نسخو گهٽ کان گهٽ ۽ اهڙي. هن جو مطلب اهو آهي ته، گهڻو ڪري، اسان هن کي شوقينن کي پيش ڪنداسين. ڇا توهان هڪ پرجوش آهيو؟
ها، پر، بدقسمتي سان، C ++ ۾ نه.
ڇا توهان جا ساٿي ڄاڻن ٿا ته C++ ۾ ڪيئن لکجي؟
مان ڪنهن کي ڳولي وٺندس.
زبردست*.
* مضمون شامل ڪيو ويو ٻن مهينن کانپوءِ رپورٽ - سوال جي ليکڪ ان کي ترقي ڪئي ۽ موڪليو .
مهرباني
سلام! رپورٽ لاءِ مهرباني! توهان ذڪر ڪيو آهي ته ڪلڪ هاؤس تمام سٺو آهي ان کي استعمال ڪرڻ لاءِ موجود سڀني وسيلن کي. ۽ Luxoft جي اڳيان اسپيڪر روسي پوسٽ لاء سندس حل بابت ڳالهايو. هن چيو ته انهن کي واقعي پسند ڪيو ClickHouse، پر انهن ان کي استعمال نه ڪيو ان جي بدران پنهنجي مکيه مقابلي جي بدران، ڇاڪاڻ ته اهو سڄو سي پي يو کائي رهيو هو. ۽ اهي ان کي پنهنجي فن تعمير ۾ پلگ نه ڪري سگهيا ، انهن جي زو ڪيپر ۾ ڊڪرز سان. ڇا اهو ممڪن آهي ته ڪنهن حد تائين ڪلڪ هاؤس کي محدود ڪري ته جيئن اهو هر شي کي استعمال نه ڪري جيڪا ان لاءِ دستياب ٿي وڃي؟
ها، اهو ممڪن آهي ۽ تمام آسان آهي. جيڪڏھن توھان چاھيو ٿا گھٽ ڪور استعمال ڪريو، پوءِ بس لکو set max_threads = 1. ۽ اھو اھو آھي، اھو ھڪڙي ڪور ۾ درخواست تي عمل ڪندو. ان کان علاوه، توهان مختلف استعمال ڪندڙن لاء مختلف سيٽنگون بيان ڪري سگھو ٿا. تنهنڪري ڪو مسئلو ناهي. ۽ Luxoft کان پنهنجن ساٿين کي ٻڌايو ته اهو سٺو ناهي ته انهن دستاويزن ۾ هي سيٽنگ نه ڳولي.
اليڪسي، هيلو! مان هن سوال جي باري ۾ پڇڻ چاهيندس. هي پهريون ڀيرو نه آهي ته مون ٻڌو آهي ته ڪيترائي ماڻهو استعمال ڪرڻ شروع ڪري رهيا آهن ClickHouse لاگ ان لاءِ اسٽوريج طور. رپورٽ ۾ توهان چيو ته اهو نه ڪريو، يعني توهان کي ڊگهي تارن کي ذخيرو ڪرڻ جي ضرورت ناهي. توهان ان بابت ڇا ٿا سوچيو؟
پهرين، لاگز، ضابطي جي طور تي، ڊگهي تار نه آهن. اتي، يقينا، استثنا آهن. مثال طور، جاوا ۾ لکيل ڪجهه خدمت هڪ استثنا ڏئي ٿو، اهو لاگ ان ٿيل آهي. ۽ ائين ئي هڪ لامحدود لوپ ۾، ۽ هارڊ ڊرائيو تي جاء ختم ٿي ويندي آهي. حل بلڪل سادو آهي. جيڪڏهن سٽون تمام ڊگهيون آهن، پوء انهن کي ڪٽيو. مطلب ڇا آھي ڊگھو ڇا آھي؟ ڏهه ڪلو بائيٽ خراب آهن*.
* ClickHouse جي جديد نسخن ۾، "ايڊاپٽو انڊيڪس گرينولرٽي" کي فعال ڪيو ويو آهي، جيڪو گهڻي ڀاڱي ڊگهي قطارن کي محفوظ ڪرڻ جي مسئلي کي ختم ڪري ٿو.
هڪ kilobyte عام آهي؟
Нормально.
سلام! رپورٽ لاءِ مهرباني! مون اڳ ۾ ئي چيٽ ۾ ان بابت پڇيو، پر مون کي ياد ناهي ته مون کي جواب مليو. ڇا ڪي منصوبا آھن سي ٽي اي جي طريقي سان WITH سيڪشن کي وڌائڻ جو؟
اڃا نه. اسان جو WITH سيڪشن ڪجهه غير معمولي آهي. اهو اسان لاء هڪ ننڍڙي خاصيت وانگر آهي.
مان سمجهان ٿو. تنهنجي مهرباني!
رپورٽ لاءِ مهرباني! تمام دلچسپ! عالمي سوال. ڇا ڊيٽا کي ختم ڪرڻ ۾ ترميم ڪرڻ جو ڪو منصوبو آهي، شايد ڪنهن قسم جي اسٽب جي صورت ۾؟
لازمي طور تي. هي اسان جي قطار ۾ اسان جو پهريون ڪم آهي. اسان هاڻي فعال طور تي سوچي رهيا آهيون ته هر شي کي ڪيئن صحيح طريقي سان ڪجي. ۽ توهان کي ڪيبورڊ کي دٻائڻ شروع ڪرڻ گهرجي*.
* ڪيبورڊ تي بٽڻ دٻايو ۽ سڀ ڪجھ ڪيو.
ڇا اهو ڪنهن به طرح سسٽم جي ڪارڪردگي تي اثر انداز ڪندو يا نه؟ ڇا داخل ٿيڻ ايترو تيز ٿيندو جيترو هاڻي آهي؟
ٿي سگهي ٿو پاڻ کي ڊليٽ ڪري ڇڏين ۽ اپ ڊيٽون پاڻ ۾ تمام گهڻيون هونديون، پر هي چونڊ جي ڪارڪردگيءَ يا داخلن جي ڪارڪردگيءَ تي اثر انداز نه ٿيندو.
۽ هڪ وڌيڪ ننڍڙو سوال. پريزنٽيشن ۾ توهان پرائمري ڪيئي بابت ڳالهايو. ان جي مطابق، اسان وٽ ورهاڱي آهي، جيڪا مهيني طور تي ڊفالٽ آهي، صحيح؟ ۽ جڏهن اسان هڪ تاريخ جي حد مقرر ڪريون ٿا جيڪو هڪ مهيني ۾ ٺهڪي اچي ٿو، پوء صرف اهو ورهاڱو پڙهيو وڃي ٿو، صحيح؟
ها.
هڪ سوال. جيڪڏهن اسان ڪنهن به پرائمري ڪيچي کي نه چونڊي سگهون ٿا، ته پوءِ ڇا اهو صحيح آهي ته ان کي خاص طور تي ”تاريخ“ فيلڊ جي مطابق ڪرڻ گهرجي ته جيئن پس منظر ۾ هن ڊيٽا کي گهٽ ترتيب ڏنو وڃي ته جيئن اهو وڌيڪ ترتيب سان ٺهي؟ جيڪڏهن توهان وٽ رينج جا سوال نه آهن ۽ توهان ڪنهن به پرائمري چيڪ کي به نه چونڊي سگهو ٿا، ڇا اهو ضروري آهي ته تاريخ کي پرائمري ڪي ۾ رکڻ جي؟
ها.
ٿي سگهي ٿو اهو سمجهه ۾ اچي ته هڪ فيلڊ کي پرائمري ڪيچ ۾ رکڻ لاءِ جيڪو ڊيٽا کي بهتر طور تي دٻائي ڇڏيندو جيڪڏهن اهو هن فيلڊ ذريعي ترتيب ڏنو وڃي. مثال طور، يوزر ID. استعمال ڪندڙ، مثال طور، ساڳئي سائيٽ ڏانهن وڃي ٿو. انهي حالت ۾، صارف جي سڃاڻپ ۽ وقت رکو. ۽ پوءِ توھان جي ڊيٽا بھتر ٿي ويندي. تاريخ جي طور تي، جيڪڏهن توهان وٽ واقعي نه آهي ۽ تاريخن تي ڪڏهن به رينج جا سوال نه آهن، ته پوء توهان کي تاريخ کي پرائمري چيڪ ۾ رکڻ جي ضرورت ناهي.
ٺيڪ آهي توهان جي وڏي مهرباني!
جو ذريعو: www.habr.com