HighLoad++ ماسڪو 2018، ڪانگريس هال. نومبر 9, 15:00
خلاصو ۽ پيشڪش:
Yuri Nasretdinov (VKontakte): رپورٽ اسان جي ڪمپني ۾ ClickHouse کي لاڳو ڪرڻ جي تجربي بابت ڳالهائي ويندي - اسان کي ان جي ضرورت ڇو آهي، اسان ڪيترو ڊيٽا ذخيرو ڪريون ٿا، اسان ان کي ڪيئن لکندا آهيون، وغيره.
اضافي مواد
يوري ناصردينوف: - هيلو سڀ! منهنجو نالو Yuri Nasretdinov آهي، جيئن منهنجو تعارف ٿي چڪو آهي. مان VKontakte ۾ ڪم ڪريان ٿو. مان ان بابت ڳالهائيندس ته اسان ڪيئن ڊيٽا داخل ڪندا ڪلڪ هاؤس ۾ اسان جي سرور فليٽ مان (هزارين هزارين).
لاگ ڇا آهن ۽ انهن کي ڇو گڏ ڪيو وڃي؟
اسان توهان کي ڇا ٻڌائينداسين: اسان ڇا ڪيو، اسان کي "ڪلڪ هائوس" جي ضرورت ڇو آهي، ترتيب سان، اسان اهو ڇو چونڊيو، توهان ڪهڙي قسم جي ڪارڪردگي حاصل ڪري سگهو ٿا بغير ڪنهن خاص ترتيب جي بغير. مان توهان کي بفر ٽيبل جي باري ۾ وڌيڪ ٻڌائيندس، انهن مسئلن بابت جيڪي اسان وٽ هئا ۽ اسان جي حلن بابت جيڪي اسان اوپن سورس - KittenHouse ۽ Lighthouse مان ٺاهيا آهن.
ڇو ته اسان کي ڪجهه ڪرڻ جي ضرورت هئي (هر شيء هميشه VKontakte تي سٺو آهي، صحيح؟). اسان ڊيبگ لاگ گڏ ڪرڻ چاهيون ٿا (۽ اتي سوين ٽيرا بائيٽ ڊيٽا موجود هئا)، ٿي سگهي ٿو ته ڪنهن نه ڪنهن طريقي سان انگ اکر ڳڻڻ وڌيڪ آسان هجي؛ ۽ اسان وٽ هزارين سرورن جو هڪ جهاز آهي جنهن مان اهو سڀ ڪجهه ڪرڻ جي ضرورت آهي.
اسان فيصلو ڇو ڪيو؟ اسان وٽ شايد لاگ محفوظ ڪرڻ لاءِ حل هئا. هتي - اتي هڪ اهڙي عوامي آهي "پسند VK". مان ان جي رڪنيت حاصل ڪرڻ جي ڏاڍي صلاح ڏيان ٿو.
لاگس ڇا آهن؟ هي هڪ انجڻ آهي جيڪو خالي صفن کي موٽائي ٿو. VK ۾ انجڻون آھن جيڪي ٻيا سڏين ٿا microservices. ۽ هتي هڪ مسڪرائيندڙ اسٽيڪر آهي (ڪافي تمام گهڻو پسند). ائين ڪيئن؟ چڱو، اڳتي ٻڌو!
لاگن کي ذخيرو ڪرڻ لاء ڇا استعمال ڪري سگهجي ٿو؟ هيڊپ جو ذڪر نه ڪرڻ ناممڪن آهي. پوء، مثال طور، Rsyslog (هنن لاگن کي فائلن ۾ محفوظ ڪرڻ). LSD. ڪير ڄاڻي ٿو LSD ڇا آهي؟ نه، هي LSD نه. ذخيرو فائلون، ترتيب سان، پڻ. خير، ClickHouse هڪ عجيب اختيار آهي.
ڪلڪ هائوس ۽ مقابلا: گهرجون ۽ موقعا
اسان ڇا ٿا چاهيون؟ اسان انهي ڳالهه کي يقيني بڻائڻ چاهيون ٿا ته اسان کي آپريشن بابت تمام گهڻو پريشان ٿيڻ جي ضرورت ناهي، انهي ڪري ته اهو دٻي کان ٻاهر ڪم ڪري، ترجيح سان گهٽ ۾ گهٽ ترتيب سان. اسان گهڻو ڪجهه لکڻ چاهيون ٿا، ۽ جلدي لکڻ چاهيون ٿا. ۽ اسان ان کي هر قسم جي مهينن، سالن، يعني گهڻي وقت تائين رکڻ چاهيون ٿا. اسان شايد ڪنهن مسئلي کي سمجهڻ چاهيون ٿا ته اهي اسان وٽ آيا ۽ چيو، "ڪجهه هتي ڪم نه ڪري رهيو آهي،" ۽ اهو 3 مهينا اڳ هو)، ۽ اسان اهو ڏسڻ چاهيون ٿا ته 3 مهينا اڳ ڇا ٿيو " ڊيٽا ڪمپريشن - اهو واضح آهي ته اهو هڪ پلس ڇو هوندو - ڇاڪاڻ ته اهو گھٽائي ٿو خلا جي مقدار کي جيڪو وٺندو آهي.
۽ اسان وٽ هڪ اهڙي دلچسپ گهرج آهي: اسان ڪڏهن ڪڏهن ڪجهه حڪمن جي پيداوار لکندا آهيون (مثال طور، لاگز)، اهو آساني سان 4 ڪلوبائٽس کان وڌيڪ ٿي سگهي ٿو. ۽ جيڪڏهن اها شيءِ UDP تي ڪم ڪري ٿي، ته پوءِ ان کي خرچ ڪرڻ جي ضرورت ناهي... ان ۾ ڪنيڪشن لاءِ ڪو به ”اوور هيڊ“ نه هوندو، ۽ وڏي تعداد ۾ سرورز لاءِ اهو هڪ پلس هوندو.
اچو ته ڏسو ته ڪهڙو کليل ذريعو اسان کي پيش ڪري ٿو. پهرين، اسان وٽ لاگ انجڻ آهي - هي اسان جي انجڻ آهي؛ اصول ۾، هو سڀ ڪجهه ڪري سگهي ٿو، هو به ڊگهي لائين لکي سگهي ٿو. خير، اهو شفاف طور تي ڊيٽا کي دٻائڻ وارو نه آهي - اسان پاڻ کي وڏي ڪالمن کي دٻائي سگهون ٿا جيڪڏهن اسان چاهيون ٿا ... اسان، يقينا، نٿا چاهيون (جيڪڏهن ممڪن هجي). مسئلو صرف اهو آهي ته هو ڄاڻي ٿو ته صرف اهو ئي ڏئي ٿو جيڪو هن جي ياداشت ۾ مناسب آهي؛ باقي پڙهڻ لاء، توهان کي هن انجڻ جي binlog حاصل ڪرڻ جي ضرورت آهي، ۽ مطابق، ان کي ڪافي وقت لڳن ٿا.
ٻيا ڪهڙا آپشن آهن؟ مثال طور، "Hadup". آپريشن جي آسانيءَ... ڪير سوچي ٿو ته هيڊپ کي ترتيب ڏيڻ آسان آهي؟ يقينن، رڪارڊنگ سان ڪو مسئلو ناهي. پڙهندي، ڪڏهن ڪڏهن سوال پيدا ٿيندا آهن. اصول ۾، مان چوندس شايد نه، خاص طور تي لاگز لاء. ڊگھي مدي واري اسٽوريج - يقينا، ها، ڊيٽا کمپريشن - ها، ڊگھي تار - اهو واضح آهي ته توهان رڪارڊ ڪري سگهو ٿا. پر سرورز جي وڏي تعداد مان رڪارڊنگ... توهان کي اڃا به ڪجهه ڪرڻو پوندو پاڻ کي!
Rsyslog. حقيقت ۾، اسان ان کي هڪ بيڪ اپ آپشن طور استعمال ڪيو ته جيئن اسان ان کي binlog کي ڊمپ ڪرڻ کان سواءِ پڙهي سگهون، پر اهو ڊگهيون لائينون نٿو لکي سگهي؛ اصولي طور تي، اهو 4 ڪلو بائيٽ کان وڌيڪ نٿو لکي سگهي. توهان کي ڊيٽا ڪمپريشن کي ساڳيو طريقي سان ڪرڻو پوندو. پڙهڻ فائلن مان ايندو.
ان کان پوء اتي آهي "badushka" LSD جي ترقي. لازمي طور تي ساڳيو "Rsyslog": اهو ڊگھي تارن کي سپورٽ ڪري ٿو، پر اهو UDP تي ڪم نٿو ڪري سگهي ۽ حقيقت ۾، انهي جي ڪري، بدقسمتي سان، اتي ڪافي شيون آهن جن کي ٻيهر لکڻ جي ضرورت آهي. LSD کي ٻيهر ڊزائين ڪرڻ جي ضرورت آهي هزارين سرورن مان رڪارڊ ڪرڻ جي قابل.
۽ هتي! هڪ عجيب اختيار آهي ElasticSearch. ڪيئن چئجي؟ هو پڙهڻ سان سٺو ڪم ڪري رهيو آهي، اهو آهي، هو جلدي پڙهي ٿو، پر لکڻ سان تمام سٺو ناهي. پهرين، جيڪڏهن اهو ڊيٽا کي دٻائي ٿو، اهو تمام ڪمزور آهي. گهڻو ڪري، هڪ مڪمل ڳولا اصل حجم کان وڏي ڊيٽا جي جوڙجڪ جي ضرورت آهي. ان کي هلائڻ ڏکيو آهي ۽ مسئلا اڪثر ان سان پيدا ٿئي ٿو. ۽، ٻيهر، لچڪدار ۾ رڪارڊنگ - اسان کي پنهنجو پاڻ کي ڪرڻو پوندو.
هتي ڪلڪ هاؤس هڪ مثالي اختيار آهي، يقينا. رڳو اها ڳالهه آهي ته هزارين سرورن مان رڪارڊنگ هڪ مسئلو آهي. پر گهٽ ۾ گهٽ هڪ مسئلو آهي، اسان ان کي ڪنهن به طريقي سان حل ڪرڻ جي ڪوشش ڪري سگهون ٿا. ۽ باقي رپورٽ هن مسئلي بابت آهي. ڪلڪ هائوس مان توهان ڪهڙي قسم جي ڪارڪردگي جي توقع ڪري سگهو ٿا؟
اسان ان کي ڪيئن داخل ڪرڻ وارا آهيون؟ مرج ٽري
توهان مان ڪير نه ٻڌو آهي يا نه ڄاڻيو آهي "ClickHouse" بابت؟ مون کي توهان کي ٻڌائڻ جي ضرورت آهي، نه؟ تمام تيز، تمام تڪڙو. اتي داخل ڪرڻ - 1-2 گيگا بائيٽ في سيڪنڊ، 10 گيگا بائيٽ في سيڪنڊ تائين پھٽڻ اصل ۾ ھن ترتيب کي برداشت ڪري سگھن ٿا - اتي ٻه 6-ڪور Xeons (يعني تمام طاقتور نه آھن)، 256 گيگا بائيٽ ريم، 20 ٽيرا بائيٽ RAID ۾ (ڪنهن به ترتيب نه ڏني، ڊفالٽ سيٽنگون). Alexey Milovidov، ClickHouse ڊولپر، شايد اتي روئي رهيو آهي ڇاڪاڻ ته اسان ڪجھ به ترتيب نه ڏنو آهي (هر شيء اسان لاء ڪم ڪيو آهي). ان جي مطابق، هڪ اسڪيننگ جي رفتار، چون ٿا، اٽڪل 6 بلين لائين في سيڪنڊ حاصل ڪري سگهجي ٿو جيڪڏهن ڊيٽا کي چڱي طرح ٺهرايو وڃي. جيڪڏھن توھان پسند ڪريو % تي ٽيڪسٽ اسٽرنگ - 100 ملين لائين في سيڪنڊ، اھو آھي، اھو ڪافي تيز لڳي ٿو.
اسان ان کي ڪيئن داخل ڪرڻ وارا آهيون؟ خير، توهان کي خبر آهي ته VK PHP استعمال ڪري ٿو. اسان هر PHP ورڪر کان HTTP ذريعي "ClickHouse" ۾ داخل ڪنداسين، هر رڪارڊ لاءِ MergeTree ٽيبل ۾. هن منصوبي سان مسئلو ڪير ڏسي ٿو؟ ڪجهه سببن لاء، هرڪو پنهنجا هٿ نه اٿاريو. مان توکي ٻڌايان.
پهرين، اتي تمام گهڻا سرور آهن - مطابق، اتي تمام گهڻا ڪنيڪشن (خراب) هوندا. پوءِ اهو بهتر آهي ته ڊيٽا داخل ڪيو وڃي MergeTree ۾ هڪ ڀيرو في سيڪنڊ کان وڌيڪ نه. ۽ ڪير ڄاڻي ڇو؟ ٺيڪ آهي، ٺيڪ آهي. مان توهان کي ان بابت ٿورو وڌيڪ ٻڌائيندس. هڪ ٻيو دلچسپ سوال اهو آهي ته اسان اينالائيٽڪس نه ڪري رهيا آهيون، اسان کي ڊيٽا کي بهتر ڪرڻ جي ضرورت ناهي، اسان کي وچولي سرور جي ضرورت ناهي، اسان سڌو سنئون "ClickHouse" ۾ داخل ڪرڻ چاهيون ٿا (ترجيح طور تي - وڌيڪ سڌو، بهتر).
ان مطابق، ڪيئن داخل ڪيو ويو آهي MergeTree ۾؟ اهو ڇو بهتر آهي ته ان ۾ داخل ٿيڻ کان وڌيڪ ڀيرا هڪ سيڪنڊ يا گهٽ ۾ گهٽ نه؟ حقيقت اها آهي ته "ClickHouse" هڪ ڪالمن جو ڊيٽابيس آهي ۽ ڊيٽا کي ترتيب ڏئي ٿو بنيادي ڪي جي وڌندي ترتيب ۾، ۽ جڏهن توهان داخل ڪريو ٿا، ته فائلن جو تعداد گهٽ ۾ گهٽ ڪالمن جي تعداد جي برابر آهي، جنهن ۾ ڊيٽا ترتيب ڏنل آهي. پرائمري ڪيچ جي وڌندي ترتيب ۾ (هڪ الڳ ڊاريڪٽري ٺاهي وئي آهي، هر داخل ڪرڻ لاء ڊسڪ تي فائلن جو هڪ سيٽ). ان کان پوء ايندڙ داخل ٿيڻ اچي ٿو، ۽ پس منظر ۾ اهي وڏيون "پارشنز" ۾ گڏيل آهن. جيئن ته ڊيٽا کي ترتيب ڏنو ويو آهي، اهو ممڪن آهي ته "ضم ڪرڻ" ٻن ترتيب ڏنل فائلن کي وڌيڪ ياداشت جي استعمال کان سواء.
پر، جيئن توھان اندازو لڳائي سگھوٿا، جيڪڏھن توھان ھر داخل ڪرڻ لاءِ 10 فائلون لکو، ته پوءِ ڪلڪ ھاؤس (يا توھان جو سرور) جلدي ختم ٿي ويندو، تنھنڪري اھو سفارش ڪئي وئي آھي ته وڏي بيچ ۾ داخل ڪريو. ان جي مطابق، اسان ڪڏهن به پيداوار ۾ پهريون منصوبو شروع نه ڪيو. اسان فوري طور تي هڪ لانچ ڪيو، جيڪو هتي نمبر 2 آهي:
هتي تصور ڪريو ته اٽڪل هڪ هزار سرور آهن جن تي اسان شروع ڪيو آهي، اتي صرف PHP آهي. ۽ هر سرور تي اسان جو مقامي ايجنٽ هوندو آهي، جنهن کي اسان ”ڪيٽن هائوس“ سڏيندا آهيون، جيڪو ”ڪلڪ هاؤس“ سان هڪ ڪنيڪشن برقرار رکي ٿو ۽ هر چند سيڪنڊن ۾ ڊيٽا داخل ڪري ٿو. ڊيٽا داخل ڪري ٿو MergeTree ۾ نه، پر هڪ بفر ٽيبل ۾، جيڪو سڌو سنئون MergeTree ۾ داخل ٿيڻ کان بچڻ لاءِ صحيح طور تي ڪم ڪري ٿو.
بفر ٽيبل سان ڪم ڪرڻ
هي ڇا آهي؟ بفر ٽيبل ميموري جو ھڪڙو ٽڪرو آھي جيڪو شارڊ ٿيل آھي (يعني اھو ان ۾ گھڙي سگھجي ٿو). اهي ڪيترن ئي ٽڪرن تي مشتمل آهن، ۽ هر هڪ ٽڪرا هڪ آزاد بفر طور ڪم ڪري ٿو، ۽ اهي آزاد طور تي فلش ڪيا ويا آهن (جيڪڏهن توهان وٽ بفر ۾ ڪيترائي ٽڪرا آهن، ته پوء في سيڪنڊ ۾ ڪيترائي داخل ٿيندا). انھن جدولن مان پڙھڻ ممڪن آھي - پوءِ توھان پڙھو مواد جي اتحاد کي بفر ۽ پيرين ٽيبل جي، پر ھن وقت لکڻ بند ٿيل آھي، تنھنڪري اھو بھتر آھي ته اتان کان پڙھو نه. ۽ بفر ٽيبل تمام سٺي QPS ڏيکاري ٿو، يعني 3 هزار QPS تائين توهان کي داخل ڪرڻ وقت ڪو به مسئلو نه ٿيندو. اهو واضح آهي ته جيڪڏهن سرور طاقت وڃائي ٿو، پوء ڊيٽا گم ٿي سگهي ٿو، ڇاڪاڻ ته اهو صرف ميموري ۾ ذخيرو ٿيل هو.
ساڳي ئي وقت، بفر سان گڏ اسڪيم ALTER کي پيچيده ڪري ٿو، ڇو ته توهان کي پهريان پراڻي اسڪيم سان پراڻي بفر ٽيبل کي ڇڏڻ جي ضرورت آهي (ڊيٽا ڪٿي به غائب نه ٿيندي، ڇاڪاڻ ته اها ميز کي ختم ٿيڻ کان اڳ فلش ڪيو ويندو). پوء توهان ٽيبل کي "تبديل" ڪريو جيڪو توهان کي گهربل آهي ۽ ٻيهر بفر ٽيبل ٺاهيو. ان مطابق، جڏهن ته بفر ٽيبل نه آهي، توهان جي ڊيٽا ڪٿي به نه وهندي، پر توهان ان کي ڊسڪ تي گهٽ ۾ گهٽ مقامي طور تي رکي سگهو ٿا.
Kittenhouse ڇا آهي ۽ اهو ڪيئن ڪم ڪندو آهي؟
KittenHouse ڇا آهي؟ هي هڪ پراکسي آهي. سمجهو ڪهڙي ٻولي؟ مون پنهنجي رپورٽ ۾ سڀ کان وڌيڪ hype عنوان گڏ ڪيا - "ڪلڪ هاؤس"، وڃ، شايد مون کي ڪجهه ٻيو ياد هوندو. ها، هي گو ۾ لکيل آهي، ڇاڪاڻ ته مون کي خبر ناهي ته سي ۾ ڪيئن لکجي، مان نه ٿو چاهيان.
ان جي مطابق، اهو هر سرور سان هڪ ڪنيڪشن برقرار رکي ٿو ۽ ميموري ڏانهن لکي سگهي ٿو. مثال طور، جيڪڏهن اسان ڪلڪ هاؤس تي غلطي لاگ لکندا آهيون، پوء جيڪڏهن ڪلڪ هاؤس وٽ ڊيٽا داخل ڪرڻ جو وقت نه آهي (سڀني کان پوء، جيڪڏهن تمام گهڻو لکيو ويو آهي)، ته پوء اسان ياداشت کي سوڀ نه ڪندا آهيون - اسان صرف باقي ڪڍي ڇڏيندا آهيون. ڇاڪاڻ ته جيڪڏهن اسان غلطين جي في سيڪنڊ ۾ ڪيترائي گيگابٽ لکون ٿا، ته پوء اسان شايد ڪجهه ڪڍي سگهون ٿا. Kittenhouse اهو ڪري سگهي ٿو. ان سان گڏ، اهو قابل اعتماد ترسيل انجام ڏئي سگهي ٿو، اهو آهي، مقامي مشين تي ڊسڪ تي لکڻ ۽ هڪ ڀيرو هر وقت (اتي، هڪ ڀيرو هر سيڪنڊن جي هڪ ڀيرو) هن فائل مان ڊيٽا پهچائڻ جي ڪوشش ڪري ٿو. ۽ پھريون ڀيرو اسان استعمال ڪيو باقاعده قدر فارميٽ - ڪجھ بائنري فارميٽ نه، ھڪڙي ٽيڪسٽ فارميٽ (جيئن باقاعده SQL ۾).
پر پوءِ اهو ٿيو. اسان قابل اعتماد ترسيل استعمال ڪيو، لاگ لکيا، پوء فيصلو ڪيو (اهو هڪ مشروط ٽيسٽ ڪلسٽر هو)... اهو ڪيترن ئي ڪلاڪن لاءِ ٻاهر رکيو ويو ۽ واپس آندو ويو، ۽ هڪ اندراج هڪ هزار سرورن مان شروع ٿيو - اهو ظاهر ٿيو ته ڪلڪ هائوس اڃا تائين هڪ آهي. "ڪنيڪشن تي ڌاڳو" - مطابق، هڪ هزار ڪنيڪشن ۾، هڪ فعال داخل ٿيڻ سرور تي لڳ ڀڳ هڪ اڌ هزار جي اوسط لوڊ ڪري ٿي. حيرت انگيز طور تي، سرور درخواستن کي قبول ڪيو، پر ڊيٽا اڃا تائين ڪجهه وقت کان پوء داخل ڪيو ويو. پر سرور لاءِ ان جي خدمت ڪرڻ تمام ڏکيو هو...
nginx شامل ڪريو
ٿريڊ في ڪنيڪشن ماڊل لاءِ اهڙو حل nginx آهي. اسان ڪلڪ هائوس جي سامهون نينڪس نصب ڪيو، ساڳئي وقت ٻن نقلن لاءِ توازن قائم ڪيو (اسان جي داخل ڪرڻ جي رفتار 2 ڀيرا وڌي وئي، جيتوڻيڪ اها حقيقت ناهي ته اهو معاملو هجڻ گهرجي) ۽ ڪلڪ هائوس تائين ڪنيڪشن جو تعداد محدود ڪيو. upstream ۽، مطابق، وڌيڪ، 50 ڪنيڪشن ۾، اهو لڳي ٿو ته داخل ڪرڻ ۾ ڪو به مقصد ناهي.
پوء اسان محسوس ڪيو ته هن اسڪيم ۾ عام طور تي نقصانات آهن، ڇاڪاڻ ته اسان وٽ هتي صرف هڪ نينگڪس آهي. انهي جي مطابق، جيڪڏهن هي نينگڪس حادثو، نقلن جي موجودگي جي باوجود، اسان ڊيٽا وڃائي يا گهٽ ۾ گهٽ، ڪٿي به نه لکندا آهيون. ان ڪري اسان پنهنجو لوڊ بيلنس ڪيو آهي. اسان اهو پڻ محسوس ڪيو ته “Clickhouse” اڃا تائين لاگن لاءِ موزون آهي، ۽ “شيطان” پڻ “Clickhouse” ۾ پنهنجا لاگ لکڻ شروع ڪيا - تمام آسان، ايماندار هجڻ لاءِ. اسان اڃا تائين ان کي استعمال ڪندا آهيون ٻين "شيطانن" لاءِ.
ان کان پوء اسان اهو دلچسپ مسئلو دريافت ڪيو: جيڪڏهن توهان SQL موڊ ۾ داخل ڪرڻ جو غير معياري طريقو استعمال ڪندا آهيو، اهو هڪ مڪمل AST-based SQL parser تي زور ڏئي ٿو، جيڪو ڪافي سست آهي. انهي جي مطابق، اسان سيٽنگون شامل ڪيون آهن انهي کي يقيني بڻائڻ ته اهو ڪڏهن به نه ٿئي. اسان لوڊ بيلنس ڪيو، صحت جي چڪاس ڪئي، ته جيئن ڪو مري وڃي، اسان اڃا تائين ڊيٽا کي ڇڏي ڏيو. اسان وٽ ھاڻي ڪافي جدول آھن جن کي اسان کي ضرورت آھي مختلف ڪلڪ ھاؤس ڪلسٽرز. ۽ اسان ٻين استعمالن جي باري ۾ پڻ سوچڻ شروع ڪيو - مثال طور، اسان nginx ماڊلز کان لاگ لکڻ چاهيون ٿا، پر انهن کي خبر ناهي ته اسان جي RPC استعمال ڪندي گفتگو ڪيئن ڪجي. خير، مان انهن کي سيکارڻ چاهيان ٿو ته ڪيئن موڪليا وڃن گهٽ ۾ گهٽ ڪنهن طرح - مثال طور، يو ڊي پي ذريعي لوڪل هوسٽ تي واقعا وصول ڪرڻ ۽ پوءِ انهن کي ڪلڪ هائوس ڏانهن اڳتي وڌايو.
حل کان هڪ قدم پري
فائنل اسڪيم هن طرح ڏسڻ شروع ڪيو (هن اسڪيم جو چوٿون نسخو): ڪلڪ هائوس جي سامهون هر سرور تي نينڪس (ساڳئي سرور تي) آهي ۽ اهو صرف 50 ڪنيڪشن جي تعداد جي حد سان لوڪل هوسٽ جي درخواستن کي پراڪس ڪري ٿو. ٽڪرا. ۽ هي اسڪيم اڳ ۾ ئي ڪافي ڪم ڪري رهيو هو، هر شي ان سان تمام سٺي هئي.
اسان اٽڪل هڪ مهينو اهڙي طرح رهندا هئاسين. هرڪو خوش هو، انهن ٽيبل شامل ڪيا، انهن شامل ڪيو، انهن شامل ڪيو ... عام طور تي، اهو ظاهر ٿيو ته اسان بفر جدولن کي شامل ڪرڻ جو طريقو تمام گهڻو بهتر نه هو (اچو ته ان کي انهي طريقي سان رکون). اسان هر ٽيبل ۾ 16 ٽڪرا ڪيا ۽ ڪجهه سيڪنڊن جو فليش وقفو؛ اسان وٽ 20 ٽيبلون ھيون ۽ ھر ٽيبل کي 8 انسرٽس في سيڪنڊ مليا - ۽ ھن وقت ”ڪلڪ ھاؤس“ شروع ٿيو... رڪارڊ سست ٿيڻ شروع ٿيا. نه رڳو اهي پاس نه ڪيا ويا ... ڊفالٽ طور، nginx هڪ اهڙي دلچسپ شيء هئي ته جيڪڏهن ڪنيڪشن اپ اسٽريم تي ختم ٿي ويا، پوء اهو صرف "502" سڀني نئين درخواستن ڏانهن واپس آيو.
۽ هتي اسان وٽ آهي (مون صرف ڪلڪ هاؤس ۾ لاگ ان کي ڏٺو) اٽڪل اڌ سيڪڙو درخواستون ناڪام ٿيون. ان جي مطابق، ڊسڪ جو استعمال اعلي هو، اتي تمام گھڻا ضم ٿي ويا. خير، مون ڇا ڪيو؟ قدرتي طور تي، مون اهو ڄاڻڻ جي زحمت نه ڪئي ته واقعي ڇو ڪنيڪشن ۽ اپ اسٽريم ختم ٿي ويو.
ريورس پراکسي سان نينڪس کي تبديل ڪرڻ
مون فيصلو ڪيو ته اسان کي ان کي پاڻ سنڀالڻ جي ضرورت آهي، اسان کي ان کي ڇڏڻ جي ضرورت ناهي nginx - nginx کي خبر ناهي ته ڪلڪ هائوس ۾ ڪهڙيون ٽيبلون آهن، ۽ مون نينڪس کي ريورس پراکسي سان تبديل ڪيو، جيڪو مون پاڻ لکيو.
هي ڇا ڪري رهيو آهي؟ اهو ڪم ڪري ٿو fasthttp لائبريري “goshnoy” جي بنياد تي، اهو آهي، تيز، تقريبا nginx جيترو تيز. معاف ڪجو، Igor، جيڪڏھن توھان ھتي موجود آھيو (نوٽ: Igor Sysoev ھڪڙو روسي پروگرامر آھي جنھن ٺاھيو nginx ويب سرور). اهو سمجھي سگھي ٿو ته ھي ڪھڙي قسم جا سوال آھن - INSERT يا SELECT - مطابق، اھو مختلف ڪنيڪشن پول رکي ٿو مختلف قسمن جي سوالن لاءِ.
ان جي مطابق، جيتوڻيڪ اسان وٽ وقت نه آهي داخل ڪرڻ جي درخواستن کي مڪمل ڪرڻ لاء، "چونڊ" گذري ويندا، ۽ ان جي برعڪس. ۽ اھو ڊيٽا کي بفر جدولن ۾ گروپ ڪري ٿو - ھڪڙي ننڍڙي بفر سان: جيڪڏھن ڪو نقص ھجي، نحوي غلطيون، وغيره - ته جيئن اھي باقي ڊيٽا تي گھڻو اثر انداز نه ٿين، ڇاڪاڻتہ جڏھن اسان بفر جدولن ۾ داخل ڪيون ٿا، اسان ننڍي هئي "بچي"، ۽ سڀني نحوي غلطين صرف هن ننڍڙي ٽڪري کي متاثر ڪيو؛ ۽ هتي اهي پهريان ئي هڪ وڏي بفر کي متاثر ڪندا. ننڍو 1 ميگا بائيٽ آهي، اهو آهي، ايترو ننڍڙو ناهي.
هڪ هم وقت سازي داخل ڪرڻ ۽ لازمي طور تي نينڪس کي تبديل ڪرڻ، بنيادي طور تي ساڳيو ڪم ڪري ٿو جيڪو نينڪس اڳ ڪيو هو - توهان کي ان لاءِ مقامي ”ڪيٽن هائوس“ کي تبديل ڪرڻ جي ضرورت ناهي. ۽ جيئن ته اهو fasthttp استعمال ڪري ٿو، اهو تمام تيز آهي - توهان ڪري سگهو ٿا 100 هزار کان وڌيڪ درخواستون في سيڪنڊ لاءِ هڪ ريورس پراڪسي ذريعي. نظرياتي طور تي، توهان هڪ وقت ۾ هڪ لڪير داخل ڪري سگهو ٿا kittenhouse ريورس پراکسي ۾، پر يقينن اسان اهو نه ڪندا آهيون.
اسڪيم هن طرح ڏسڻ شروع ڪيو: ”ڪيٽن هائوس“، ريورس پراڪسي گروپن ۾ ڪيتريون ئي درخواستون جدولن ۾ شامل ڪيون ويون آهن ۽ نتيجي ۾، بفر ٽيبل انهن کي مکيه ۾ داخل ڪن ٿا.
قاتل هڪ عارضي حل آهي، ڪتن مستقل آهي
هي هڪ دلچسپ مسئلو آهي... ڇا توهان مان ڪنهن فاسٽhttp استعمال ڪيو آهي؟ POST درخواستن سان فاسٽhttp ڪير استعمال ڪيو؟ شايد، اهو واقعي نه ڪيو وڃي ها، ڇاڪاڻ ته اهو ڊفالٽ طرفان درخواست جي جسم کي بفر ڪري ٿو، ۽ اسان جي بفر جي سائيز 16 ميگا بائيٽ تي مقرر ڪئي وئي هئي. داخل ٿيڻ ڪجهه نقطي تي رکڻ بند ٿي ويو، ۽ 16-ميگا بائيٽ chunks سڀني هزارين سرورن مان اچڻ شروع ڪيو، ۽ اهي سڀئي ڪلڪ هاؤس ڏانهن موڪلڻ کان اڳ ياداشت ۾ بفر ٿي ويا. ان جي مطابق، ميموري ختم ٿي وئي، آئوٽ آف ميموري قاتل آيو ۽ ريورس پراکسي کي ماريو (يا "ڪلڪ هائوس"، جيڪو نظرياتي طور تي ريورس پراکسي کان وڌيڪ "کائي" سگهي ٿو). چڪر پاڻ کي بار بار ڪيو. هڪ تمام خوشگوار مسئلو ناهي. جيتوڻيڪ اسان ڪيترن ئي مهينن جي آپريشن کان پوءِ ئي ان تي ٺٺول ڪيو.
مون ڇا ڪيو آهي؟ ٻيهر، مان واقعي سمجهڻ پسند نٿو ڪريان ته واقعي ڇا ٿيو. منهنجو خيال آهي ته اهو بلڪل واضح آهي ته توهان کي يادگيري ۾ بفر نه ڪرڻ گهرجي. مان فاسٽhttp کي پيچ نه ڪري سگهيو، جيتوڻيڪ مون ڪوشش ڪئي. پر مون ان کي ٺاهڻ جو هڪ طريقو مليو ته جيئن ڪنهن به شيءِ کي پيچ ڪرڻ جي ضرورت نه هئي، ۽ مان پنهنجي طريقي سان HTTP ۾ آيو آهيان - مون ان کي KITTEN سڏيو آهي. خير، اهو منطقي آهي - "VK"، "Kitten" ... ٻيو ڇا؟ ..
جيڪڏهن ڪا درخواست سرور ڏانهن ڪتن جي طريقي سان اچي ٿي، پوء سرور کي جواب ڏيڻ گهرجي "ميائو" - منطقي طور تي. جيڪڏهن هو هن جو جواب ڏئي ٿو، پوء اهو سمجهيو ويندو آهي ته هو هن پروٽوڪول کي سمجهي، ۽ پوء آئون ڪنيڪشن کي روڪيو (fasthttp وٽ هڪ طريقو آهي)، ۽ ڪنيڪشن "خام" موڊ ۾ وڃي ٿو. مون کي ان جي ضرورت ڇو آهي؟ مان ڪنٽرول ڪرڻ چاهيان ٿو ته TCP ڪنيڪشن مان پڙهڻ ڪيئن ٿئي ٿو. TCP هڪ شاندار ملڪيت آهي: جيڪڏهن ڪو به ٻئي پاسي کان نه پڙهي، پوء لکڻ جو انتظار ڪرڻ شروع ٿئي ٿو، ۽ ياداشت خاص طور تي هن تي خرچ نه ڪيو ويو آهي.
۽ پوءِ مان هڪ وقت ۾ اٽڪل 50 ڪلائنٽس کان پڙهندو آهيان (پچاس مان ڇو ته پنجاهه ضرور ڪافي هجڻ گهرجي، جيتوڻيڪ اها شرح ڪنهن ٻئي DC کان اچي ٿي)... هن طريقي سان استعمال گهٽ ۾ گهٽ 20 ڀيرا گهٽجي ويو آهي، پر مان، سچ پڇان. مان اندازو نه ڪري سگهيو آهيان ته ڪهڙي وقت، ڇاڪاڻ ته اهو اڳ ۾ ئي بي معني آهي (اهو اڳ ۾ ئي غلطي جي سطح تي پهچي چڪو آهي). پروٽوڪول بائنري آهي، اهو آهي، ان ۾ ٽيبل جو نالو ۽ ڊيٽا شامل آهي؛ هتي ڪو به http هيڊر نه آهن، تنهنڪري مون ويب ساکٽ استعمال نه ڪيو (مون کي برائوزرن سان ڳالهائڻ جي ضرورت ناهي - مون هڪ پروٽوڪول ٺاهيو جيڪو اسان جي ضرورتن کي پورو ڪري ٿو). ۽ هن سان گڏ سڀ ڪجهه ٺيڪ ٿي ويو.
بفر ٽيبل اداس آهي
تازو اسان بفر ٽيبل جي هڪ ٻي دلچسپ خصوصيت ۾ آيا آهيون. ۽ اهو مسئلو اڳ ۾ ئي ٻين جي ڀيٽ ۾ وڌيڪ ڏکوئيندڙ آهي. اچو ته هن صورتحال جو تصور ڪريو: توهان اڳ ۾ ئي فعال طور تي ڪلڪ هائوس استعمال ڪري رهيا آهيو، توهان وٽ درجن وارا ڪلڪ هائوس سرور آهن، ۽ توهان وٽ ڪجهه درخواستون آهن جن کي پڙهڻ ۾ تمام گهڻو وقت لڳندو آهي (چون ٿا ته، 60 سيڪنڊن کان وڌيڪ)؛ ۽ توهان اچو ۽ هن وقت Alter ڪريو... ان دوران، "منتخب" جيڪي "Alter" کان اڳ شروع ٿيا، هن جدول ۾ شامل نه ٿيندا، "Alter" شروع نه ٿيندا - شايد ڪجھ خاصيتون "Clickhouse" ۾ ڪيئن ڪم ڪري ٿو. هن جڳهه. ٿي سگهي ٿو اهو طئي ٿي سگهي ٿو؟ يا اهو ناممڪن آهي؟
عام طور تي، اهو واضح آهي ته حقيقت ۾ اهو هڪ وڏو مسئلو ناهي، پر بفر ٽيبل سان اهو وڌيڪ دردناڪ ٿيندو. ڇو ته، جيڪڏهن، چئو ته، توهان جي "تبديل" ٽائيم آئوٽ (۽ اهو وقت ڪنهن ٻئي ميزبان تي ختم ٿي سگهي ٿو - توهان جي نه، پر هڪ نقل تي، مثال طور)، پوء ... توهان بفر ٽيبل کي حذف ڪيو، توهان جي "Alter" ( يا ڪجهه ٻيو ميزبان) وقت ختم ٿي ويو. پوء هڪ "تبديل" جي غلطي ٿي وئي آهي) - توهان کي اڃا تائين پڪ ڪرڻ جي ضرورت آهي ته ڊيٽا لکڻ جاري آهي: توهان بفر جدولن کي واپس ٺاهيو (ساڳئي اسڪيم جي مطابق جيئن والدين ٽيبل)، پوء "تبديل" گذري ٿو، آخرڪار ختم ٿئي ٿو، ۽ بفر ٽيبل شروع ٿئي ٿو اسڪيما ۾ والدين کان مختلف. ان تي منحصر ڪيو ويو ته "Alter" ڇا هو، داخل ٿيڻ هاڻي هن بفر ٽيبل تي نه وڃي سگهي ٿو - اهو تمام اداس آهي.
هتي پڻ هڪ اهڙي نشاني آهي (شايد ڪنهن ان کي محسوس ڪيو) - ان کي سڏيو ويندو آهي query_thread_log Clickhouse جي نئين ورزن ۾. ڊفالٽ طور، ڪجھ نسخن ۾ ھڪڙو ھو. هتي اسان ڪجهه مهينن ۾ 840 ملين رڪارڊ گڏ ڪيا آهن (100 گيگا بائيٽ). اهو حقيقت جي ڪري آهي ته "داخلا" اتي لکيل هئا (شايد هاڻي، رستي ۾، اهي نه لکيل آهن). جيئن مون توهان کي ٻڌايو، اسان جا ”داخلا“ ننڍا آهن - اسان وٽ بفر ٽيبل ۾ تمام گهڻو ”داخل“ هو. اهو واضح آهي ته اهو غير فعال آهي - مان صرف توهان کي ٻڌائي رهيو آهيان جيڪو مون اسان جي سرور تي ڏٺو. ڇو؟ هي بفر ٽيبل استعمال ڪرڻ جي خلاف هڪ ٻيو دليل آهي! سپوت ڏاڍو اداس آهي.
ڪنهن کي خبر هئي ته هن ماڻهوءَ جو نالو Spotty هو؟ وي ڪي ملازمن پنهنجا هٿ مٿي ڪيا. ٺيڪ.
"KittenHouse" جي منصوبن بابت
منصوبا عام طور تي حصيداري نه ڪيا ويا آهن، صحيح؟ اوچتو توهان انهن کي پورو نه ڪندا ۽ ٻين ماڻهن جي نظر ۾ تمام سٺو نه ڏسندا. پر مان خطرو کڻندس! اسان ھيٺيون ڪم ڪرڻ چاھيون ٿا: بفر ٽيبل، اھو مون کي لڳي ٿو، اڃا تائين ھڪڙو ڪچو آھي ۽ اسان کي پاڻ کي بفر ڪرڻ جي ضرورت آھي. پر اسان اڃا تائين ان کي ڊسڪ تي بفر ڪرڻ نٿا چاهيون، تنهنڪري اسان ميموري ۾ داخل ڪرڻ کي بفر ڪنداسين.
ان جي مطابق، جڏهن هڪ "داخل" ڪيو ويندو آهي، اهو هاڻي هم وقت ساز نه هوندو - اهو اڳ ۾ ئي هڪ بفر ٽيبل جي طور تي ڪم ڪندو، پيرن ٽيبل ۾ داخل ڪندو (چڱو، ڪنهن ڏينهن بعد) ۽ هڪ الڳ چينل ذريعي رپورٽ ڪندو جيڪو داخل ٿي چڪو آهي ۽ جيڪو نه آهي.
مان هم وقت ساز داخل ڇو نه ٿو ڇڏي سگهان؟ اهو گهڻو وڌيڪ آسان آهي. حقيقت اها آهي ته جيڪڏهن توهان 10 هزار ميزبانن مان داخل ڪيو ته پوءِ سڀ ڪجهه ٺيڪ آهي - توهان کي هر ميزبان کان ٿورو گهڻو ملندو، توهان هڪ سيڪنڊ ۾ هڪ ڀيرو داخل ڪيو، سڀ ڪجهه ٺيڪ آهي. پر مان چاهيان ٿو ته هي اسڪيم ڪم ڪري، مثال طور، ٻن مشينن مان، ته جيئن توهان تيز رفتار سان ڊائون لوڊ ڪري سگهو - شايد ڪلڪ هاؤس مان وڌ ۾ وڌ حاصل نه ڪريو، پر ريورس پراڪسي ذريعي هڪ مشين مان گهٽ ۾ گهٽ 100 ميگا بائيٽ في سيڪنڊ لکو. ھن اسڪيم کي وڏي ۽ ننڍي مقدار ۾ ماپڻ گھرجي، تنھنڪري اسين ھر داخل ٿيڻ لاءِ ھڪ سيڪنڊ انتظار نٿا ڪري سگھون، تنھنڪري اھو لازمي طور تي غير مطابقت رکندڙ ھجڻ گھرجي. ۽ ساڳيء طرح، غير مطابقت جي تصديق ٿيڻ گهرجي داخل ٿيڻ کان پوء مڪمل ٿيڻ کان پوء. اسان کي خبر پوندي ته اهو گذري ويو يا نه.
سڀ کان وڌيڪ اهم ڳالهه اها آهي ته هن اسڪيم ۾ اسان کي پڪ سان معلوم ٿئي ٿو ته داخلا ٿي آهي يا نه. هن صورتحال کي تصور ڪريو: توهان وٽ هڪ بفر ٽيبل آهي، توهان ان ۾ ڪجهه لکيو، ۽ پوء، اچو ته چئو، ٽيبل صرف پڙهڻ واري موڊ ۾ ويو ۽ بفر کي فلش ڪرڻ جي ڪوشش ڪئي. ڊيٽا ڪيڏانهن ويندي؟ اهي بفر ۾ رهندا. پر اسان ان جي باري ۾ يقين نه ٿا ڪري سگهون - ڇا جيڪڏهن ڪا ٻي غلطي آهي، جنهن جي ڪري ڊيٽا بفر ۾ نه رهندي ... (ايڊريس Alexey Milovidov، Yandex، ClickHouse ڊولپر) يا اهو رهندو؟ هميشه؟ Alexey اسان کي يقين ڏياريو ته سڀ ڪجهه ٺيڪ ٿي ويندو. اسان وٽ ڪو به سبب نه آهي ته هن کي يقين نه ڏيو. پر سڀ ڪجهه ساڳيو: جيڪڏهن اسان بفر ٽيبل استعمال نٿا ڪريون، ته پوءِ انهن سان ڪو به مسئلو نه ٿيندو. ٻه ڀيرا ڪيتريون ئي ٽيبل ٺاهڻ پڻ مشڪل آهي، جيتوڻيڪ اصول ۾ ڪو وڏو مسئلو ناهي. هي منصوبو آهي.
اچو ته پڙهڻ جي باري ۾ ڳالهايون
هاڻي اچو ته پڙهڻ جي باري ۾ ڳالهايون. اسان پڻ هتي پنهنجو اوزار لکيو آهي. اهو لڳي ٿو، چڱو، هتي توهان جو پنهنجو اوزار ڇو لکو؟ ... ۽ ڪير استعمال ڪيو Tabix؟ ٿورن ماڻهن پنهنجا هٿ مٿي ڪيا... ۽ ڪير مطمئن آهي ٽيبڪس جي ڪارڪردگيءَ مان؟ خير، اسان ان سان خوش نه آهيون، ۽ اهو ڊيٽا کي ڏسڻ لاء بلڪل آسان ناهي. اهو اينالائيٽڪس لاءِ ٺيڪ آهي، پر صرف ڏسڻ لاءِ اهو واضح طور تي بهتر نه ڪيو ويو آهي. تنهنڪري مون پنهنجو پاڻ لکيو، منهنجو پنهنجو انٽرفيس.
اهو تمام سادو آهي - اهو صرف ڊيٽا پڙهي سگهي ٿو. هن کي خبر ناهي ته گرافڪس ڪيئن ڏيکاري، هن کي خبر ناهي ته ڪجهه ڪيئن ڪجي. پر اهو ڏيکاري سگھي ٿو ته اسان کي ڪهڙي ضرورت آهي: مثال طور، ٽيبل ۾ ڪيتريون قطارون آهن، اهو ڪيترو جاء وٺندو آهي (ان کي ڪالمن ۾ ٽوڙڻ کان سواء)، اهو آهي، هڪ تمام بنيادي انٽرفيس آهي جيڪو اسان کي گهرجي.
۽ اهو ڏسڻ ۾ بلڪل ملندو آهي Sequel Pro، پر صرف Twitter جي بوٽ اسٽراپ تي ٺاهيو ويو آهي، ۽ ٻيو نسخو. توهان پڇو: "يوري، ٻئي نسخي تي ڇو؟" ڪهڙو سال؟ 2018؟ عام طور تي، مون اهو ڪافي وقت اڳ ڪيو هو “Muscle” (MySQL) لاءِ ۽ صرف اتي سوالن ۾ ڪجهه لائينون تبديل ڪيون، ۽ اهو “Clickhouse” لاءِ ڪم ڪرڻ شروع ڪيو، جنهن لاءِ خاص مهرباني! ڇاڪاڻ ته parser "عضلات" هڪ سان تمام گهڻو ملندڙ جلندڙ آهي، ۽ سوال تمام گهڻا آهن - تمام آسان، خاص طور تي پهريون ڀيرو.
خير، اهو ٽيبل کي فلٽر ڪري سگهي ٿو، ٽيبل جي ساخت ۽ مواد کي ڏيکاري سگھي ٿو، توهان کي ترتيب ڏيڻ جي اجازت ڏئي ٿو، ڪالمن ذريعي فلٽر ڪري ٿو، سوال ڏيکاري ٿو جنهن جي نتيجي ۾ نتيجو، متاثر ٿيل قطارون (ڪيترن جو نتيجو)، اهو آهي، ڊيٽا کي ڏسڻ لاء بنيادي شيون. ڪافي تيز.
هڪ ايڊيٽر پڻ آهي. مون ايمانداري سان سڄي ايڊيٽر کي ٽيبڪس مان چوري ڪرڻ جي ڪوشش ڪئي، پر نه ٿي سگهيو. پر ڪنهن به طرح اهو ڪم ڪري ٿو. اصول ۾، اهو سڀ ڪجهه آهي.
"Clickhouse" dens لاء مناسب آهي
مان توهان کي ٻڌائڻ چاهيان ٿو ته ڪلڪ هاؤس، بيان ڪيل سڀني مسئلن جي باوجود، لاگز لاء تمام مناسب آهي. سڀ کان اهم، اهو اسان جي مسئلي کي حل ڪري ٿو - اهو تمام تيز آهي ۽ توهان کي ڪالمن طرفان لاگ ان کي فلٽر ڪرڻ جي اجازت ڏئي ٿو. اصولي طور تي، بفر ٽيبل سٺو نه ڪيو آهي، پر عام طور تي ڪو به نٿو ڄاڻي ڇو... شايد هاڻي توهان بهتر ڄاڻو ٿا ته توهان کي ڪٿي مسئلا آهن.
ٽي سي پي؟ عام طور تي، VK ۾ اهو UDP استعمال ڪرڻ لاء رواج آهي. ۽ جڏهن مون استعمال ڪيو TCP... يقيناً، ڪنهن به مون کي نه چيو: ”يوري، تون ڪهڙي ڳالهه ڪري رهيو آهين! توهان نٿا ڪري سگهو، توهان کي UDP جي ضرورت آهي. اهو ظاهر ٿيو ته TCP ايترو خوفناڪ نه آهي. صرف هڪ شيء آهي، جيڪڏهن توهان وٽ هزارين فعال مرڪب آهن جيڪي توهان لکندا آهيو، توهان کي ان کي ٿورو وڌيڪ احتياط سان تيار ڪرڻ جي ضرورت آهي؛ پر اهو ممڪن آهي، ۽ بلڪل آسان.
مون واعدو ڪيو هو ”ڪيٽن هاؤس“ ۽ ”لائيٽ هائوس“ هاءِ لوڊ سائبيريا تي پوسٽ ڪرڻ جو جيڪڏهن هرڪو اسان جي پبلڪ “VK backend” کي سبسڪرائب ڪري ٿو... ۽ توهان کي خبر آهي ته، هر ڪنهن سبسڪرائب نه ڪيو... يقينا، مان اهو مطالبو نه ڪندس ته توهان اسان جي رڪنيت حاصل ڪريو. عوامي. توھان مان اڃا به گھڻا آھن، ڪو ماڻھو ناراض به ٿي سگھي ٿو، پر پوءِ به، مھرباني ڪري رڪنيت حاصل ڪريو (۽ ھتي مون کي ٻلي وانگر اکيون ٺاهڻيون آھن). اهو آهي . توهان جي وڏي مهرباني! گيتب اسان جو آهي . ڪلڪ هائوس سان توهان جا وار نرم ۽ ريشمي ٿي ويندا.
اڳواڻي: - دوست، ھاڻي سوالن لاءِ. ان کان پوءِ اسان پيش ڪريون ٿا تعريف جو سرٽيفڪيٽ ۽ توهان جي رپورٽ VHS تي.
Yuri Nasretdinov (هاڻي بعد ۾ YN طور حوالو ڏنو ويو): - توهان VHS تي منهنجي رپورٽ ڪيئن رڪارڊ ڪرڻ جي قابل هئا جيڪڏهن اهو صرف ختم ٿي ويو؟
اڳواڻي: - توهان پڻ مڪمل طور تي طئي نه ڪري سگهو ٿا ته ڪيئن "ڪلڪ هائوس" ڪم ڪندو يا نه! دوستو، سوالن لاءِ 5 منٽ!
توهان جا سوال
سامعين کان سوال (هتي ق جي طور تي حوالو ڏنو ويو): - منجهند جو سلام. رپورٽ لاء توهان جي وڏي مهرباني. مون وٽ ٻه سوال آهن. مان شروع ڪريان ٿو هڪ غير معمولي شيءِ سان: ڇا ڊراگرام (3، 4، 7...) ۾ ”ڪيٽن هائوس“ جي نالي ۾ ٽي اکر جو تعداد ٻلين جي اطمينان تي اثر انداز ٿئي ٿو؟
YN: - ڇا جي مقدار؟
Z: - خط ٽي. اتي ٽي ٽي آهن، ڪٿي ٽي ٽي جي چوڌاري.
YN: - مون ان کي درست نه ڪيو؟ خير، يقينا اهو ڪندو آهي! اهي مختلف پراڊڪٽس آهن - مان صرف توهان کي هر وقت ٺڳي رهيو هوس. ٺيڪ، مان مذاق ڪري رهيو آهيان - اهو مسئلو ناهي. ها، هتي ئي! نه، اها ساڳي شيء آهي، مون هڪ ٽائپو ڪيو.
Z: - تنهنجي مهرباني. ٻيو سوال سنجيده آهي. جيتري قدر مان سمجهان ٿو، ڪلڪ هاؤس ۾، بفر ٽيبل خاص طور تي ياداشت ۾ رهن ٿا، ڊسڪ تي بفر نه آهن ۽، مطابق، مسلسل نه آهن.
YN: - ها.
Z: - ۽ ساڳئي وقت، توهان جو ڪلائنٽ ڊسڪ ڏانهن بفر ڪري ٿو، جيڪو انهن ساڳين لاگن جي پهچائڻ جي ڪجهه ضمانت ڏئي ٿو. پر اهو ڪنهن به طرح جي ضمانت نه آهي Clickhouse تي. وضاحت ڪريو ته گارنٽي ڪيئن ٿيندي آهي، ڇا جي ڪري؟... هتي هي ميکانيزم وڌيڪ تفصيل سان آهي
YN: - ها، نظرياتي طور تي هتي ڪو به تضاد نه آهي، ڇاڪاڻ ته جڏهن ڪلڪ هائوس پوي ٿو، توهان اصل ۾ ان کي هڪ ملين مختلف طريقن سان ڳولي سگهو ٿا. جيڪڏهن ڪلڪ هاؤس حادثو ٿئي ٿو (جيڪڏهن اهو غلط طور تي ختم ٿئي ٿو)، توهان ڪري سگهو ٿا، تقريبا ڳالهائڻ، توهان جي لاگ ان جو ٿورڙو جيڪو توهان لکيو آهي ۽ ان وقت کان شروع ڪريو جڏهن سڀ ڪجهه ٺيڪ هو. اچو ته چئو ته توهان هڪ منٽ کي ريوائنڊ ڪيو، اهو آهي، اهو سمجهيو ويندو آهي ته توهان هڪ منٽ ۾ سڀ ڪجهه فلش ڪيو آهي.
Z: - اھو آھي، "Kittenhouse" ونڊو ڊگھو رکي ٿو ۽، زوال جي صورت ۾، ان کي سڃاڻي سگھي ٿو ۽ ان کي واپس ڪري سگھي ٿو؟
YN: - پر هي نظريي ۾ آهي. عملي طور تي، اسان اهو نه ڪندا آهيون، ۽ قابل اعتماد ترسيل صفر کان لامحدود وقت تائين آهي. پر سراسري طور تي هڪ. اسان مطمئن آهيون ته جيڪڏهن ڪلڪ هاؤس ڪجهه سببن لاءِ حادثو ٿئي ٿو يا سرور ”ريبوٽ“ ڪريون ٿا ته پوءِ اسان ٿورو وڃائي ويهون. ٻين سڀني حالتن ۾، ڪجھ به نه ٿيندو.
Z: - سلام. شروعات کان ئي مون کي لڳي ٿو ته توهان واقعي رپورٽ جي شروعات کان ئي UDP استعمال ڪري رهيا آهيو. توھان وٽ آھي http، اھو سڀ... ۽ گھڻا مسئلا جيڪي توھان بيان ڪيا آھن، جيئن مان سمجھان ٿو، ھن خاص حل جي ڪري پيدا ٿيا آھن...
YN: - اسان TCP ڇا استعمال ڪريون ٿا؟
Z: - لازمي طور تي ها.
YN: - نه.
Z: - اهو fasthttp سان هو ته توهان کي مسئلا هئا ، ڪنيڪشن سان توهان کي مسئلا هئا. جيڪڏهن توهان صرف UDP استعمال ڪيو ها ته توهان پنهنجو پاڻ کي ڪجهه وقت بچائي ها. خير، ڊگهو پيغامن سان مسئلو هوندو يا ٻيو ڪجهه ...
YN: - ڇا سان؟
Z: - ڊگھي پيغامن سان، ڇاڪاڻ ته اهو MTU ۾ مناسب نه ٿي سگھي، ٻيو ڪجهه ... خير، انهن جا پنهنجا مسئلا ٿي سگهن ٿا. سوال آهي: ڇو نه UDP؟
YN: - مان سمجهان ٿو ته ليکڪ جيڪي TCP/IP ٺاهيا آهن اهي مون کان تمام گهڻو هوشيار آهن ۽ مون کان بهتر ڄاڻن ٿا ته پيڪٽس کي ڪيئن سيريل ڪرڻ (جيئن اهي هلن)، ساڳئي وقت موڪلڻ واري ونڊو کي ترتيب ڏيو، نيٽ ورڪ کي اوورلوڊ نه ڪريو، راء ڏيو ته ڇا؟ نه پڙهيل آهي، نه ڳڻڻ جي ٻئي پاسي... اهي سڀ مسئلا، منهنجي خيال ۾، UDP ۾ موجود هوندا، صرف مون کي ان کان به وڌيڪ ڪوڊ لکڻو پوندو، جيڪو مون اڳ ۾ ئي لکيو هو، ان ساڳي شيءِ کي پاڻ لاڳو ڪرڻ لاءِ. خراب طور تي. مون کي به سي ۾ لکڻ پسند نه آهي، اتي ئي ڇڏي ڏيو...
Z: - بس آسان! موڪليو ٺيڪ آهي ۽ ڪنهن به شيءِ جو انتظار نه ڪريو - اهو مڪمل طور تي هم وقت ساز آهي. هڪ نوٽيفڪيشن واپس آيو ته سڀ ڪجهه ٺيڪ آهي - ان جو مطلب آهي پهچي ويو؛ جيڪڏهن اهو نٿو اچي، ان جو مطلب آهي ته اهو خراب آهي.
YN: - مون کي ٻنهي جي ضرورت آهي - مون کي پهچائڻ جي ضمانت ۽ ترسيل جي ضمانت جي بغير ٻنهي کي موڪلڻ جي قابل ٿيڻو پوندو. اهي ٻه مختلف منظرنامو آهن. مون کي ڪجهه لاگ نه وڃائڻ جي ضرورت آهي يا نه انهن کي سبب جي اندر وڃائڻ.
Z: - مان وقت ضايع نه ڪندس. هن وڌيڪ بحث ڪرڻ جي ضرورت آهي. تنهنجي مهرباني.
اڳواڻي: - ڪير سوال آهي - آسمان ڏانهن هٿ!
Z: - هيلو، مان ساشا آهيان. رپورٽ جي وچ ۾ ڪٿي، هڪ احساس ظاهر ٿيو ته، TCP کان علاوه، اهو ممڪن آهي ته هڪ تيار ڪيل حل استعمال ڪرڻ ممڪن آهي - ڪافڪا جو ڪجهه قسم.
YN: - خير... مون توهان کي ٻڌايو ته مان انٽرميڊيٽ سرور استعمال ڪرڻ نه ٿو چاهيان، ڇاڪاڻ ته... ڪافڪا ۾، اهو معلوم ٿئي ٿو ته اسان وٽ ڏهه هزار ميزبان آهن؛ حقيقت ۾، اسان وٽ وڌيڪ آهن - هزارين لشڪر. اهو پڻ ڏکوئيندڙ ٿي سگهي ٿو ڪافڪا سان بغير ڪنهن پراکسي سان ڪرڻ. ان کان علاوه، سڀ کان اهم، اهو اڃا تائين ڏئي ٿو "ويڪرائي"، اهو اضافي ميزبان ڏئي ٿو جيڪو توهان کي گهرجي. پر مان ان کي حاصل ڪرڻ نه ٿو چاهيان - مان چاهيان ٿو ...
Z: "پر آخر ۾ اهو وري به اهو ئي نڪتو."
YN: - نه، ڪو به ميزبان ناهي! اهو سڀ ڪم ڪري ٿو Clickhouse ميزبان تي.
Z: - خير، ۽ "Kittenhouse"، جيڪو ريورس آهي - هو ڪٿي رهندو آهي؟
YN: - ڪلڪ هاؤس ميزبان تي، اهو ڊسڪ تي ڪجھ به نه لکندو آهي.
Z: - اچو ته فرض ڪريون.
اڳواڻي: - توهان مطمئن آهيو؟ ڇا اسان توهان کي تنخواه ڏئي سگهون ٿا؟
Z: - ها، توهان ڪري سگهو ٿا. حقيقت ۾، ساڳي شيء حاصل ڪرڻ لاء ڪافي ڪچيون آهن، ۽ هاڻي - TCP جي موضوع تي پوئين جواب، منهنجي خيال ۾، هن صورتحال سان تضاد آهي. اهو محسوس ٿئي ٿو ته سڀ ڪجهه منهنجي گوڏن تي تمام گهٽ وقت ۾ ٿي سگهي ٿو.
YN: - ۽ اهو پڻ ته ڇو مون ڪافڪا کي استعمال ڪرڻ نه چاهيو، ڇاڪاڻ ته ڪلڪ هائوس ٽيليگرام چيٽ ۾ ڪافي شڪايتون هيون، مثال طور، ڪافڪا جا پيغام گم ٿي ويا هئا. پاڻ ڪافڪا کان نه، پر ڪافڪا ۽ ڪلڪهوس جي انضمام ۾؛ يا ڪا شيء اتي ڳنڍيل نه آهي. ان وقت ڪافڪا لاءِ ڪلائنٽ لکڻ ضروري هوندو. مان نه ٿو سمجهان ته ڪو آسان يا وڌيڪ قابل اعتماد حل ٿي سگهي ٿو.
Z: - مون کي ٻڌاءِ، توهان ڇو نه ڪا قطار يا ڪنهن قسم جي عام بس جي ڪوشش ڪئي؟ جيئن توهان چئو ٿا ته asynchrony سان توهان لاگس پاڻ کي قطار ذريعي موڪلي سگهو ٿا ۽ جواب حاصل ڪري سگهو ٿا غير هم وقتي طور تي قطار ذريعي؟
YN: - مھرباني ڪري صلاح ڏيو ته ڪھڙي قطار استعمال ٿي سگھي ٿي؟
Z: - ڪو به، بغير ڪنهن ضمانت جي ته اهي ترتيب ۾ آهن. ڪجهه قسم جو Redis، RMQ ...
YN: - مون کي اهو احساس آهي ته ريڊس گهڻو ڪري قابل نه هوندو ته داخل ٿيڻ جي اهڙي مقدار کي هڪ ميزبان تي به (ڪيترن ئي سرورن جي معنى ۾) جيڪو ڪلڪ ڪري ٻاهر ڪڍندو آهي. مان هن کي ڪنهن به ثبوت سان واپس نه ٿو ڪري سگهان (مون ان کي بينچ مارڪ نه ڪيو آهي)، پر اهو مون کي لڳي ٿو ته ريڊس هتي بهترين حل ناهي. اصول ۾، هن سسٽم کي هڪ بهتر پيغام جي قطار طور سمجهي سگهجي ٿو، پر اهو صرف "ڪلڪ هائوس" لاء ٺهيل آهي.
اڳواڻي: - يوري، توهان جي وڏي مهرباني. مان سوالن ۽ جوابن کي هتي ختم ڪرڻ جي تجويز پيش ڪريان ٿو ۽ اهو چوان ٿو ته جن سوال ڪيو تن مان ڪھڙي کي ڪتاب ڏينداسين.
YN: - مان پهرين شخص کي ڪتاب ڏيڻ چاهيان ٿو جنهن سوال ڪيو.
اڳواڻي: - عجيب! زبردست! شاندار! تمام گهڻي مهرباني!
ڪجھ اشتهار 🙂
اسان سان گڏ رهڻ لاء توهان جي مهرباني. ڇا توهان اسان جا مضمون پسند ڪندا آهيو؟ وڌيڪ دلچسپ مواد ڏسڻ چاهيو ٿا؟ آرڊر ڏيڻ يا دوستن کي سفارش ڪندي اسان جي مدد ڪريو، , داخلا-سطح سرورز جو هڪ منفرد اينالاگ، جيڪو اسان توهان لاءِ ايجاد ڪيو هو: (RAID1 ۽ RAID10 سان دستياب آهي، 24 ڪور تائين ۽ 40GB DDR4 تائين).
ڊيل R730xd 2x سستا Equinix Tier IV ڊيٽا سينٽر ۾ Amsterdam ۾؟ صرف هتي هالينڊ ۾! ڊيل R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 کان! جي باري ۾ پڙهو
جو ذريعو: www.habr.com