ان حقيقت جي باوجود ته هاڻي تقريبن هر هنڌ تمام گهڻو ڊيٽا موجود آهي، تجزياتي ڊيٽابيس اڃا تائين ڪافي غير معمولي آهن. اهي خراب طور تي سڃاتل آهن ۽ اڃا به گهٽ انهن کي مؤثر طريقي سان استعمال ڪرڻ جي قابل آهن. ڪيترائي MySQL يا PostgreSQL سان ”ڪيڪٽس کائڻ“ جاري رکندا آھن، جيڪي ٻين منظرنامي لاءِ ٺاھيا ويا آھن، NoSQL سان وڙھندا آھن، يا تجارتي حلن لاءِ وڌيڪ ادا ڪندا آھن. ClickHouse هڪ راند بدلائيندڙ آهي ۽ خاص طور تي تجزياتي DBMS جي دنيا ۾ داخل ٿيڻ جي رڪاوٽ کي گهٽائي ٿو.
رپورٽ BackEnd Conf 2018 کان آهي ۽ اها اسپيڪر جي اجازت سان شايع ڪئي وئي آهي.
مان ڪير آهيان ۽ مان ڪلڪ هائوس بابت ڇو ڳالهائي رهيو آهيان؟ مان لائف اسٽريٽ تي ڊولپمينٽ جو ڊائريڪٽر آهيان، جيڪو استعمال ڪري ٿو ClickHouse. مان پڻ Altinity جو باني آهيان. هي هڪ Yandex پارٽنر آهي جيڪو ClickHouse کي فروغ ڏئي ٿو ۽ Yandex کي ClickHouse کي وڌيڪ ڪامياب بنائڻ ۾ مدد ڪري ٿو. مان به تيار آهيان ClickHouse بابت ڄاڻ شيئر ڪرڻ لاءِ.
۽ مان پڻ پيٽيا زيتسوف جو ڀاءُ نه آهيان. مون کان اڪثر ان بابت پڇيو ويندو آهي. نه، اسان ڀائر نه آهيون.
"هرڪو ڄاڻي ٿو" اهو ڪلڪ هائوس:
- تمام تيز، تمام تڪڙو،
- تمام آسان،
- Yandex ۾ استعمال ٿيل.
اهو ٿورڙي ڄاڻ آهي جنهن ۾ ڪمپنيون ۽ ڪيئن استعمال ٿينديون آهن.
مان توهان کي ٻڌايان ٿو ڇو، ڪٿي ۽ ڪيئن ClickHouse استعمال ڪيو ويندو آهي، Yandex کان سواء.
مان توهان کي ٻڌايان ٿو ته ڪئين مخصوص مسئلا مختلف ڪمپنين ۾ ڪلڪ هاؤس استعمال ڪندي حل ڪيا ويا آهن، ڪهڙن ڪلڪ هاؤس اوزار توهان پنهنجي ڪمن لاءِ استعمال ڪري سگهو ٿا، ۽ اهي مختلف ڪمپنين ۾ ڪيئن استعمال ڪيا ويا.
مون ٽي مثال چونڊيا آهن جيڪي ڏيکارين ٿا ڪلڪ هائوس کي مختلف پاسن کان. مان سمجهان ٿو ته اهو دلچسپ ٿيندو.
پهريون سوال آهي: "ڇو اسان کي ClickHouse جي ضرورت آهي؟" اهو لڳي ٿو ته سوال بلڪل واضح آهي، پر ان جا هڪ کان وڌيڪ جواب آهن.
- پهريون جواب ڪارڪردگي سببن لاء آهي. ClickHouse تمام تيز آهي. ClickHouse تي تجزياتي پڻ تمام تيز آهي. اهو اڪثر استعمال ڪري سگهجي ٿو جتي ٻيو ڪجهه ڪم ڪري رهيو آهي تمام سست يا تمام خراب.
- ٻيو جواب قيمت آهي. ۽ سڀ کان پهريان، اسڪيلنگ جي قيمت. مثال طور، Vertica هڪ تمام بهترين ڊيٽابيس آهي. اهو تمام سٺو ڪم ڪري ٿو جيڪڏهن توهان وٽ تمام گهڻو ٽيرابائيٽ ڊيٽا نه آهي. پر جڏهن اسان سئو ٽيرا بائيٽس يا پيٽابيٽس جي باري ۾ ڳالهائي رهيا آهيون، لائسنس ۽ سپورٽ جي قيمت هڪ انتهائي اهم رقم آهي. ۽ اهو قيمتي آهي. ۽ ڪلڪ هائوس مفت آهي.
- ٽيون جواب آپريٽنگ خرچ آهي. هي هڪ ٿورو مختلف طريقو آهي. RedShift هڪ عظيم اينالاگ آهي. RedShift سان توهان تمام جلدي فيصلو ڪري سگهو ٿا. اهو سٺو ڪم ڪندو، پر ساڳئي وقت، هر ڪلاڪ، هر ڏينهن ۽ هر مهيني توهان Amazon کي تمام گهڻو ادا ڪنداسين، ڇاڪاڻ ته اها هڪ وڏي قيمتي خدمت آهي. Google BigQuery پڻ. جيڪڏهن ڪنهن ان کي استعمال ڪيو آهي، ته هو ڄاڻي ٿو ته توهان اتي ڪيترن ئي سوالن کي هلائي سگهو ٿا ۽ اوچتو سئو ڊالرن جي انوائس وصول ڪري سگهو ٿا.
ClickHouse اهي مسئلا نه آهن.
ڪلڪ هاؤس هاڻي ڪٿي استعمال ٿئي ٿو؟ Yandex جي اضافي ۾، ClickHouse مختلف ڪاروبار ۽ ڪمپنين جي گروپ ۾ استعمال ٿيندو آهي.
- سڀ کان پهريان، هي ويب ايپليڪيشن اينالائيٽڪس آهي، يعني هي هڪ استعمال ڪيس آهي جيڪو Yandex کان آيو آهي.
- ڪيتريون ئي AdTech ڪمپنيون استعمال ڪن ٿيون ClickHouse.
- ڪيتريون ئي ڪمپنيون جيڪي مختلف ذريعن کان آپريشنل لاگز جو تجزيو ڪرڻ جي ضرورت آهي.
- ڪيترائي ڪمپنيون استعمال ڪن ٿيون ClickHouse حفاظتي لاگن جي نگراني ڪرڻ لاءِ. اھي انھن کي اپلوڊ ڪن ٿا ClickHouse تي، رپورٽون ٺاھيو، ۽ انھن کي گهربل نتيجا حاصل ڪريو.
- ڪمپنيون ان کي مالي تجزيي ۾ استعمال ڪرڻ شروع ڪري رهيون آهن، يعني آهستي آهستي وڏا ڪاروبار به اچي رهيا آهن ClickHouse.
- CloudFlare. جيڪڏهن ڪو ماڻهو ClickHouse جي پيروي ڪري، توهان شايد هن ڪمپني جو نالو ٻڌو هوندو. هي ڪميونٽي جي اهم مدد ڪندڙن مان هڪ آهي. ۽ انهن وٽ هڪ تمام سنجيده ClickHouse تنصيب آهي. مثال طور، انهن ڪلڪ هاؤس لاءِ ڪافڪا انجڻ ٺاهي.
- ٽيلي ڪميونيڪيشن ڪمپنيون استعمال ڪرڻ شروع ڪيون آهن. ڪيتريون ئي ڪمپنيون استعمال ڪن ٿيون ClickHouse يا ته تصور تي ثبوت طور يا اڳ ۾ ئي پيداوار ۾.
- ھڪڙي ڪمپني استعمال ڪري ٿي ClickHouse پيداوار جي عمل جي نگراني ڪرڻ لاء. اهي microcircuits کي جانچيندا آهن، پيٽرولن جو هڪ گروپ لکندا آهن، اٽڪل 2 خاصيتون آهن. ۽ پوءِ اهي تجزيو ڪندا ته ڇا بيچ سٺو آهي يا خراب.
- Blockchain تجزياتي. Bloxy.info نالي هڪ روسي ڪمپني آهي. هي Ethereum نيٽ ورڪ جو هڪ تجزيو آهي. انهن اهو پڻ ڪيو ClickHouse تي.
ان کان سواء، سائيز ڪا به اهميت ناهي. ڪيتريون ئي ڪمپنيون آهن جيڪي هڪ ننڍڙو سرور استعمال ڪن ٿيون. ۽ هو انهن کي انهن جي مسئلن کي حل ڪرڻ جي اجازت ڏئي ٿو. ۽ اڃا به وڌيڪ ڪمپنيون ڪيترن ئي سرورن يا ڪيترن ئي سرورن جا وڏا ڪلستر استعمال ڪن ٿيون.
۽ جيڪڏهن توهان رڪارڊ تي نظر اچن ٿا، پوء:
- Yandex: 500+ سرور، اهي اتي هڪ ڏينهن ۾ 25 بلين رڪارڊ محفوظ ڪن ٿا.
- لائف اسٽريٽ: 60 سرورز، تقريبن 75 بلين رڪارڊ في ڏينهن. Yandex جي ڀيٽ ۾ گھٽ سرور ۽ وڌيڪ رڪارڊ آھن.
- CloudFlare: 36 سرورز، اھي ذخيرو ڪن ٿا 200 بلين رڪارڊ في ڏينھن. انهن وٽ اڃا به گهٽ سرور آهن ۽ اڃا به وڌيڪ ڊيٽا اسٽور.
- بلومبرگ: 102 سرورز، تقريبن هڪ ٽريلين رڪارڊ في ڏينهن. رڪارڊ هولڊر.
جغرافيائي طور تي، اهو پڻ تمام گهڻو آهي. هي نقشو ڏيکاري ٿو گرمي جو نقشو جتي ڪلڪ هائوس دنيا ۾ استعمال ٿئي ٿو. هتي روس، چين ۽ آمريڪا واضح طور تي بيٺا آهن. ڪجھ يورپي ملڪ آھن. ۽ 4 ڪلستر کي فرق ڪري سگهجي ٿو.
هي هڪ تقابلي تجزيو آهي، مطلق نمبر ڳولڻ جي ڪا ضرورت ناهي. هي انهن سياحن جو هڪ تجزيو آهي جيڪي Altinity ويب سائيٽ تي انگريزي ٻولي جو مواد پڙهن ٿا، ڇاڪاڻ ته اتي روسي ڳالهائيندڙ نه آهن. ۽ روس، يوڪرين، بيلاروس، يعني ڪميونٽي جو روسي ڳالهائيندڙ حصو، سڀ کان وڌيڪ استعمال ڪندڙ آهن. ان کان پوء آمريڪا ۽ ڪئناڊا اچي ٿو. چين تمام گهڻو پڪڙي رهيو آهي. ڇهه مهينا اڳ اتي چين لڳ ڀڳ ڪو نه هو؛ هاڻي چين اڳي ئي يورپ کي ختم ڪري چڪو آهي ۽ اڳتي وڌندو رهيو آهي. پراڻو يورپ به پوئتي نه رهيو آهي، ۽ ClickHouse جي استعمال ۾ اڳواڻ، عجيب طور تي ڪافي، فرانس آهي.
مان هي سڀ ڇو ٿو ٻڌايان؟ اهو ڏيکارڻ لاءِ ته ClickHouse وڏي ڊيٽا جي تجزيي لاءِ هڪ معياري حل بڻجي رهيو آهي ۽ اڳ ۾ ئي ڪيترن ئي هنڌن تي استعمال ٿيل آهي. جيڪڏهن توهان ان کي استعمال ڪيو ٿا، توهان صحيح رجحان تي آهيو. جيڪڏهن توهان اڃا تائين ان کي استعمال نه ڪيو آهي، ته پوء توهان کي ڊپ نه ٿيڻ گهرجي ته توهان اڪيلو رهجي ويندا ۽ ڪو به توهان جي مدد نه ڪندو، ڇاڪاڻ ته ڪيترائي اڳ ۾ ئي ڪري رهيا آهن.
اهي ڪيترن ئي ڪمپنين ۾ ClickHouse جي حقيقي استعمال جا مثال آهن.
- پهريون مثال هڪ اشتهاري نيٽ ورڪ آهي: لڏپلاڻ Vertica کان ClickHouse ڏانهن. ۽ مان ڪيترن ئي ڪمپنين کي ڄاڻان ٿو جيڪي ورٽيڪا کان تبديل ٿي ويا آهن يا سوئچنگ جي عمل ۾ آهن.
- ٻيو مثال ClickHouse تي ٽرانزيڪشنل اسٽوريج آهي. هي هڪ مثال آهي جيڪو اينٽي پيٽرن تي ٺهيل آهي. ڊولپرز جي مشوري مطابق ڪلڪ هاؤس ۾ هر ڪم ڪرڻ جي ضرورت ناهي هتي ڪيو ويو آهي. ۽ ساڳئي وقت اهو تمام مؤثر طريقي سان ڪيو ويو آهي ته اهو ڪم ڪري ٿو. ۽ اهو هڪ عام ٽرانزيڪشن حل کان گهڻو بهتر ڪم ڪري ٿو.
- ٽيون مثال ڪلڪ هاؤس تي ورهايل ڪمپيوٽنگ آهي. اتي هڪ سوال هو ته ڪيئن ClickHouse Hadoop ماحولياتي نظام ۾ ضم ٿي سگهي ٿو. مان هڪ مثال ڏيکاريندس ته ڪيئن هڪ ڪمپني ڪلڪ هاؤس تي نقشي کي گهٽائڻ واري ڪنٽينر وانگر ڪجهه ڪيو، ڊيٽا لوڪلائيزيشن جي نگراني، وغيره، هڪ تمام غير معمولي ڪم کي ڳڻڻ لاءِ.
- لائف اسٽريٽ هڪ ايڊ ٽيڪ ڪمپني آهي جنهن ۾ اشتهاري نيٽ ورڪ سان لاڳاپيل سڀئي ٽيڪنالاجيون آهن.
- هوءَ اشتھار جي اصلاح ۽ پروگراماتي بولنگ ۾ مصروف آھي.
- تمام گهڻو ڊيٽا: اٽڪل 10 ارب واقعا في ڏينهن. ان کان علاوه، واقعن کي ڪيترن ئي ذيلي واقعن ۾ ورهائي سگھجي ٿو.
- هن ڊيٽا جا ڪيترائي گراهڪ آهن، ۽ اهي نه رڳو ماڻهو آهن، پر ٻيا به ڪيترائي مختلف الورورٿم آهن جيڪي پروگراماتي بولنگ ۾ مشغول آهن.
ڪمپني هڪ ڊگهو ۽ ٿلهو رستو وٺي آيو آهي. ۽ مون ان بابت ڳالهايو HighLoad. پهريون، لائف اسٽريٽ MySQL کان لڏي ويو (Oracle تي هڪ مختصر اسٽاپ سان) Vertica ڏانهن. ۽ توهان ان بابت هڪ ڪهاڻي ڳولي سگهو ٿا.
۽ هر شيء تمام سٺي هئي، پر اهو جلدي واضح ٿيو ته ڊيٽا وڌي رهي هئي ۽ ورٽيڪا قيمتي هئي. تنهن ڪري، مختلف متبادل ڳوليا ويا. انهن مان ڪجهه هتي درج ٿيل آهن. ۽ حقيقت ۾، اسان تصور جو ثبوت ڪيو يا ڪڏهن ڪڏهن تقريبن سڀني ڊيٽابيس جي ڪارڪردگي جي جاچ ڪئي جيڪي 13 کان 16 تائين مارڪيٽ تي موجود هئا ۽ ڪارڪردگي ۾ تقريبن مناسب هئا. ۽ مون انهن مان ڪجهه بابت ڳالهايو HighLoad.
ڪم پهريون ڀيرو Vertica مان لڏپلاڻ ڪرڻ هو، ڇاڪاڻ ته ڊيٽا وڌي رهي هئي. ۽ اهي ڪيترن ئي سالن تائين تيزيء سان وڌي ويا. ان کان پوء اهي شيلف تي ويا، پر اڃا تائين. ۽ هن ترقي جي اڳڪٿي ڪندي، ڊيٽا جي مقدار لاء ڪاروباري گهرجن، جنهن تي ڪجهه قسم جي تجزياتي ڪرڻ جي ضرورت آهي، اهو واضح هو ته جلد ئي پيٽابيٽس بابت ڳالهائي ويندي. ۽ پيٽابائيٽس لاءِ ادا ڪرڻ اڳ ۾ ئي تمام مهانگو آهي، تنهنڪري اسان هڪ متبادل ڳولي رهيا هئاسين ته ڪٿي وڃو.
ڪيڏانهن وڃڻو آهي؟ ۽ هڪ ڊگهي وقت تائين اهو مڪمل طور تي واضح ناهي ته ڪٿي وڃڻ گهرجي، ڇاڪاڻ ته هڪ طرف تجارتي ڊيٽابيس آهن، اهي سٺو ڪم ڪرڻ لڳي. ڪجھ ڪم لڳ ڀڳ گڏوگڏ Vertica وانگر، ڪجھ وڌيڪ خراب. پر اهي سڀ قيمتي آهن، ڪجھ به سستو يا بهتر نه ملي سگهيو.
ٻئي طرف، اوپن سورس حل آهن، جن مان تمام گهڻا نه آهن، يعني اينالائيٽڪس لاءِ انهن کي هڪ طرف شمار ڪري سگهجي ٿو. ۽ اهي مفت يا سستا آهن، پر اهي سست ڪم ڪن ٿا. ۽ اهي اڪثر ڪري ضروري ۽ مفيد ڪارڪردگي نه آهن.
۽ سٺين شين کي گڏ ڪرڻ لاءِ ڪجھ به نه هو جيڪي تجارتي ڊيٽابيس ۾ آهن ۽ سڀئي مفت شيون جيڪي اوپن سورس ۾ آهن.
ڪجھ به نه ٿيو جيستائين Yandex اوچتو ڪلڪ هاؤس کي ٽوپي مان ڪڍي ڇڏيو جيئن جادوگر جي خرگوش. ۽ اهو هڪ غير متوقع فيصلو هو؛ ماڻهو اڃا تائين سوال پڇن ٿا: "ڇو؟"، پر ان جي باوجود.
۽ فوري طور تي 2016 جي اونهاري ۾، اسان اهو ڏسڻ شروع ڪيو ته ڪلڪ هاؤس ڇا آهي. ۽ اهو ظاهر ٿيو ته اهو ڪڏهن ڪڏهن Vertica کان تيز ٿي سگهي ٿو. اسان مختلف درخواستن تي مختلف منظرنامو آزمايو. ۽ جيڪڏهن سوال صرف هڪ ٽيبل استعمال ڪيو، يعني بغير ڪنهن جوڙ جي، پوءِ ڪلڪ هاؤس ورٽيڪا جي ڀيٽ ۾ ٻه ڀيرا تيز هو.
مان ڏاڍو سست نه هو ۽ ٻئي ڏينهن وڌيڪ Yandex ٽيسٽ کي ڏٺو. اهو ساڳيو ئي آهي: ClickHouse Vertica جي ڀيٽ ۾ ٻه ڀيرا تيز آهي، تنهنڪري اهي اڪثر ان بابت ڳالهائيندا آهن.
پر جيڪڏهن سوالن ۾ شامل آهن، پوء هر شيء بلڪل واضح ناهي. ۽ ClickHouse Vertica جي ڀيٽ ۾ ٻه ڀيرا سست ٿي سگھي ٿو. ۽ جيڪڏھن توھان درست ڪريو ۽ درخواست کي ٿورو وري لکو، پوء اھي لڳ ڀڳ برابر ٿي ويندا. برو ناهي. ۽ اهو مفت آهي.
۽ ٽيسٽ جا نتيجا حاصل ڪرڻ کان پوءِ، ۽ ان کي مختلف زاوين کان ڏسندي، لائف اسٽريٽ ڪلڪتي ھاؤس ڏانھن ويو.
هي 16 هون سال آهي، مان توهان کي ياد ڏيان ٿو. اها ڳالهه انهن چوڏهن جي مذاق وانگر هئي، جن روئڻ ۽ پاڻ کي انجيڪشن لڳائي، پر ڪيڪٽس کائڻ جاري رکيو. ۽ هن تفصيل سان ڳالهه ٻولهه ڪئي وئي، اتي هن جي باري ۾ هڪ وڊيو آهي، وغيره.
تنهن ڪري، مان ان بابت تفصيل سان نه ڳالهائيندس، مان صرف نتيجن ۽ چند دلچسپ ڳالهين بابت ڳالهائيندس، جن بابت مون ان وقت نه ڳالهايو.
نتيجا هي آهن:
- ڪامياب لڏپلاڻ ۽ سسٽم هڪ سال کان وڌيڪ عرصي تائين پيداوار ۾ آهي.
- پيداوار ۽ لچڪ وڌايو آهي. 10 بلين رڪارڊن مان اسان صرف ٿوري عرصي لاءِ في ڏينهن ذخيرو ڪرڻ جي متحمل ٿي سگهيا آهيون، لائف اسٽريٽ هاڻي 75 بلين رڪارڊ في ڏينهن اسٽور ڪري ٿي ۽ ائين ڪري سگهون ٿا 3 مهينن يا وڌيڪ لاءِ. جيڪڏهن توهان چوٽي تي ڳڻيو ٿا، پوء اهو ذخيرو ڪيو ويو آهي هڪ ملين واقعن في سيڪنڊ تائين. روزانه هڪ لک کان وڌيڪ SQL سوال هن سسٽم ڏانهن موڪليا ويندا آهن، گهڻو ڪري مختلف روبوٽس کان.
- ان حقيقت جي باوجود ته ClickHouse Vertica کان وڌيڪ سرور استعمال ڪرڻ شروع ڪيو، هارڊويئر تي به بچت ڪئي وئي، ڇاڪاڻ ته Vertica ڪافي قيمتي SAS ڊسڪ استعمال ڪيو. ClickHouse SATA استعمال ڪيو. ۽ ڇو؟ ڇاڪاڻ ته ورٽيڪا داخل ڪرڻ هم وقت سازي آهي. ۽ هم وقت سازي جي ضرورت آهي ته ڊسڪ تمام گهڻو سست نه ٿين، ۽ اهو پڻ ته نيٽ ورڪ تمام گهڻو سست نه ٿئي، يعني، بلڪه قيمتي آپريشن. ۽ ClickHouse insert asynchronous آهي. ان کان علاوه، توھان ھميشه ھر شيء کي مقامي طور تي لکي سگھو ٿا، ھن لاء ڪو به اضافي خرچ نه آھي، تنھنڪري ڊيٽا داخل ڪري سگھجي ٿو ClickHouse ۾ Vertika جي ڀيٽ ۾ تمام تيز، جيتوڻيڪ تيز ترين ڊسڪ تي نه. ۽ پڙهڻ به ساڳيو آهي. SATA تي پڙهڻ، جيڪڏهن اهي RAID ۾ آهن، پوء اهو تمام تيز آهي.
- لائسنس طرفان لامحدود، يعني 3 سرورز ۾ ڊيٽا جي 60 petabytes (20 سرور هڪ نقل آهن) ۽ حقيقتن ۽ مجموعي ۾ 6 ٽريلين رڪارڊ. Vertica اهڙي ڪا به شيء برداشت نه ڪري سگهي.
هاڻي مان هن مثال ۾ عملي شين ڏانهن وڃي رهيو آهيان.
- پهرين هڪ مؤثر منصوبو آهي. گهڻو ڪري اسڪيم تي منحصر آهي.
- ٻيو موثر SQL ٺاهي رهيو آهي.
هڪ عام OLAP سوال چونڊيو آهي. ڪجهه ڪالم گروپ ۾ ويندا آهن، ڪجهه ڪالم مجموعي افعال ڏانهن ويندا آهن. اتي آهي جتي، جنهن کي ڪعبي جو هڪ ٽڪرو سمجهي سگهجي ٿو. سڄي گروهه کي پروجئشن طور سمجهي سگهجي ٿو. ۽ اهو ئي سبب آهي ته ان کي سڏيو ويندو آهي multivariate ڊيٽا تجزيو.
۽ اڪثر ڪري اهو هڪ اسٽار ڊاگرام جي صورت ۾ ٺهيل آهي، جڏهن اتي هڪ مرڪزي حقيقت آهي ۽ هن حقيقت جي خاصيتن جي ڪنارن تي، شعاعن سان گڏ.
۽ جسماني ڊيزائن جي نقطي نظر کان، اهو ميز تي ڪيئن ٺهڪي اچي ٿو، اهي عام طور تي هڪ معمولي نمائندگي ڪن ٿا. توهان غير معمولي ڪري سگهو ٿا، پر اهو ڊسڪ تي قيمتي آهي ۽ سوالن تي تمام ڪارائتو ناهي. تنهن ڪري، اهي عام طور تي هڪ معمولي ڏيک ٺاهيندا آهن، يعني حقيقت جي جدول ۽ ڪيترائي، ڪيترائي طول و عرض جدول.
پر اهو سٺو ڪم نٿو ڪري ClickHouse ۾. ان جا ٻه سبب آهن:
- پهريون اهو آهي ته ڪلڪ هاؤس ۾ تمام سٺا شامل نه آهن، يعني اتي شامل آهن، پر اهي خراب آهن. هينئر تائين اهي خراب آهن.
- ٻيو اهو آهي ته جدولن کي اپڊيٽ نه ڪيو ويو آهي. عام طور تي انهن نشانين ۾ جيڪي اسٽار ڊاگرام جي چوڌاري آهن، ڪجهه تبديل ڪرڻ جي ضرورت آهي. مثال طور، ڪلائنٽ جو نالو، ڪمپني جو نالو، وغيره. ۽ اهو ڪم نٿو ڪري.
۽ ڪلڪ هاؤس ۾ هن مان نڪرڻ جو هڪ طريقو آهي. اڃا ٻه:
- پهرين لغتن جو استعمال آهي. خارجي ڊڪشنريون اھو آھي جيڪو 99٪ مسئلو حل ڪرڻ ۾ مدد ڪري ٿو اسٽار اسڪيم، اپڊيٽس وغيره سان.
- ٻيو آهي arrays جو استعمال. Arrays پڻ شامل ٿيڻ کان نجات حاصل ڪرڻ ۾ مدد ڪن ٿا ۽ عام ڪرڻ سان مسئلن.
- شامل ٿيڻ جي ڪا ضرورت ناهي.
- تازه ڪاري جي قابل. مارچ 2018 کان وٺي، هڪ غير دستاويزي موقعو ظاهر ٿيو آهي (توهان کي اهو دستاويز ۾ نه ملندو) لغتن کي جزوي طور تي اپڊيٽ ڪرڻ لاءِ، يعني اهي داخلائون جيڪي تبديل ٿي ويون آهن. عملي طور تي، اهو هڪ ٽيبل وانگر آهي.
- هميشه ياداشت ۾، تنهنڪري ڊڪشنري سان گڏ ڪم تيزيءَ سان ٿئي ٿو جيڪڏهن اها هڪ ٽيبل هئي جيڪا ڊسڪ تي آهي ۽ اها حقيقت ناهي ته اها ڪيش ۾ آهي، گهڻو ڪري نه.
- توهان کي به شامل ٿيڻ جي ضرورت ناهي.
- هي هڪ ٺهڪندڙ 1 آهي ڪيترن ئي نمائندگي ڪرڻ لاء.
- ۽ منهنجي خيال ۾، صفون geeks لاء ٺهيل آهن. اهي آهن lambda افعال ۽ شيون.
اهو لفظن جي خاطر نه آهي. هي هڪ تمام طاقتور ڪارڪردگي آهي جيڪا توهان کي تمام گهڻيون شيون ڪرڻ جي اجازت ڏئي ٿي بلڪل آسان ۽ خوبصورت.
عام مثال جيڪي صفن کي حل ڪرڻ ۾ مدد ڪن ٿا. اهي مثال سادي ۽ بلڪل واضح آهن:
- ٽيگ ذريعي ڳولھيو. جيڪڏهن توهان وٽ هيش ٽيگ آهن ۽ هيش ٽيگ ذريعي ڪجهه پوسٽون ڳولڻ چاهيو ٿا.
- ڳولھيو اھم-قدر جوڑوں سان. معنيٰ سان گڏ ڪي صفتون به آهن.
- ڪنجين جي فهرستن کي محفوظ ڪرڻ جيڪي توھان کي ڪنھن ٻئي ۾ ترجمو ڪرڻ جي ضرورت آھي.
اهي سڀئي مسئلا بغير بغير حل ٿي سگهن ٿا. ٽيگ رکي سگھجن ٿا ڪجھ لڪير ۾ ۽ منتخب ڪري سگھجن ٿا ريگولر ايڪسپريس استعمال ڪندي، يا الڳ جدول ۾، پر پوءِ توھان کي جوائن ڪرڻو پوندو.
پر ClickHouse ۾ توهان کي ڪجهه ڪرڻ جي ضرورت ناهي، صرف هيش ٽيگ لاءِ اسٽرنگ ايري بيان ڪريو يا ڪي-ويليو سسٽم لاءِ هڪ نسٽڊ ڍانچي ٺاهيو.
هڪ نڙيل جوڙجڪ شايد بهترين نالو نه هجي. اهي ٻه صفون آهن جن جو نالو ۾ هڪ عام حصو آهي ۽ ڪجهه لاڳاپيل خاصيتون.
۽ ٽيگ ذريعي ڳولڻ تمام آسان آهي. اتي هڪ فنڪشن آهي has، جيڪو چيڪ ڪري ٿو ته صف ۾ هڪ عنصر شامل آهي. هرڪو، اسان کي سڀئي داخلا مليا جيڪي اسان جي ڪانفرنس سان لاڳاپيل آهن.
سبڊ طرفان ڳولها ٿورو وڌيڪ پيچيده آهي. اسان کي سڀ کان پهريان ڪيئي جي انڊيڪس کي ڳولڻو پوندو، ۽ پوءِ عنصر کي ان انڊيڪس سان وٺو ۽ چيڪ ڪريو ته اها قيمت اسان کي گهربل آهي. پر ان جي باوجود بلڪل سادو ۽ جامع.
باقاعده اظهار جيڪو توهان لکڻ چاهيو ٿا، جيڪڏهن توهان اهو سڀ ڪجهه هڪ لڪير ۾ ذخيرو ڪيو، اهو هوندو، سڀ کان پهريان، بيڪار. ۽، ٻيو، اهو ٻن صفن کان گهڻو وقت ڪم ڪيو.
ٻيو مثال. توھان وٽ ھڪڙو صف آھي جنھن ۾ توھان ذخيرو ڪريو IDs. ۽ توھان انھن کي نالن ۾ ترجمو ڪري سگھو ٿا. فنڪشن arrayMap. هي هڪ عام lambda فنڪشن آهي. توهان اتي لامبڊا ايڪسپريس پاس ڪيو. ۽ هوءَ ڊڪشنري مان هر ID لاءِ نالي جي قيمت ڪڍي ٿي.
توهان ساڳئي طريقي سان ڳولي سگهو ٿا. هڪ اڳڪٿي فنڪشن پاس ڪيو ويو آهي، جيڪو چيڪ ڪري ٿو ته ڪهڙا عناصر ملن ٿا.
اهي شيون سرڪٽ کي تمام گهڻو آسان ڪن ٿا ۽ مسئلن جو هڪ گروپ حل ڪن ٿا.
پر ايندڙ مسئلو جيڪو اسان کي سامهون آيو ۽ جيڪو مان ذڪر ڪرڻ چاهيان ٿو اهو موثر سوال آهي.
- ClickHouse وٽ ڪو سوال پلانر نه آھي. بلڪل نه.
- پر ان جي باوجود، پيچيده سوالن کي اڃا به رٿابندي ڪرڻ جي ضرورت آهي. ڪهڙين حالتن ۾؟
- جيڪڏهن درخواست ۾ ڪيترائي شامل آهن، جن کي توهان ذيلي چونڊ ۾ لپيندا آهيو. ۽ اهو حڪم جنهن ۾ اهي ڪم ڪيا ويا آهن.
- ۽ ٻيو، جيڪڏهن درخواست ورهايل آهي. ڇاڪاڻ ته هڪ ورهايل سوال ۾، صرف اندرين ذيلي چونڊ کي ورهايل طريقي سان عمل ڪيو ويندو آهي، ۽ باقي سڀ ڪجهه هڪ سرور ڏانهن موڪليو ويندو آهي جنهن سان توهان ڳنڍيل آهيو ۽ اتي ئي عمل ڪيو آهي. تنهن ڪري، جيڪڏهن توهان ڪيترن ئي شاملن سان سوالن کي ورهايو آهي، پوء توهان کي هڪ آرڊر چونڊڻ جي ضرورت آهي.
۽ اڃا به آسان ڪيسن ۾، ڪڏهن ڪڏهن توهان کي شيڊولر جو ڪم پڻ ڪرڻو پوندو آهي ۽ سوالن کي ٿورڙي ٻيهر لکڻو پوندو.
هتي هڪ مثال آهي. کاٻي پاسي هڪ سوال آهي جيڪو ڏيکاري ٿو مٿين 5 ملڪن. ۽ اهو 2,5 سيڪنڊن ۾ هلندو آهي، منهنجو خيال آهي. ۽ ساڄي پاسي ساڳئي درخواست آهي، پر ٿورڙي ٻيهر لکيل آهي. اسٽرنگ ذريعي گروپ ڪرڻ بدران، اسان ڪيئي (int) سان گروپ ڪرڻ شروع ڪيو. ۽ اهو تيز آهي. ۽ پوءِ اسان هڪ ڊڪشنري جوڙيو نتيجي سان. 2,5 سيڪنڊن جي بدران، درخواست وٺندي 1,5 سيڪنڊ. هي سٺو آهي.
ساڳيو مثال ٻيهر لکڻ واري فلٽر سان. هتي روس لاء هڪ درخواست آهي. اهو 5 سيڪنڊن لاء هلندو آهي. جيڪڏهن اسان ان کي ٻيهر اهڙي طرح لکون ته ٻيهر ڪنهن تار جي نه، پر انگن جو مقابلو انهن ڪنجين جي ڪجهه سيٽن سان ڪريون، جيڪي روس سان تعلق رکن ٿيون، ته پوءِ اهو وڌيڪ تيز ٿيندو.
اهڙيون ڪيتريون ئي چالون آهن. ۽ اهي توهان کي انهن سوالن کي خاص طور تي تيز ڪرڻ جي اجازت ڏين ٿا جيڪي توهان سوچيو ٿا ته اڳ ۾ ئي تيز ڊوڙي رهيا آهن، يا، برعڪس، سست رفتار سان هلائي رهيا آهن. اهي اڃا به تيز ڪري سگهجي ٿو.
- ورهايل موڊ ۾ وڌ ۾ وڌ ڪم.
- گھٽ ۾ گھٽ قسمن جي ترتيب سان، جيئن مون ڪيو ints ذريعي.
- جيڪڏهن ڪو شامل يا ڊڪشنريون آهن ته پوءِ بهتر آهي ته انهن کي آخري ڀيرو ڪريو، جڏهن توهان وٽ اڳ ۾ ئي ڊيٽا گهٽ ۾ گهٽ جزوي طور تي گروپ ٿيل آهي، ته پوءِ جوائننگ آپريشن يا ڊڪشنري ڪال ڪرڻ کي گهٽ وقت سڏيو ويندو ۽ اهو تيز ٿيندو.
- فلٽر کي تبديل ڪرڻ.
اتي ٻيون ٽيڪنڪون آهن، نه رڳو جيڪي مون ڏيکاريا آهن. ۽ اهي سڀ ڪڏهن ڪڏهن توهان کي اجازت ڏين ٿا خاص طور تي سوالن جي عمل کي تيز ڪرڻ.
اچو ته ايندڙ مثال ڏانهن وڃو. ڪمپني X USA کان. ھوء ڇا پئي ڪري؟
اتي هڪ ڪم هو:
- اشتهارن جي ٽرانزيڪشن جي آف لائن لنڪنگ.
- مختلف پابند ماڊلز جي تخليق.
منظرنامو ڇا آهي؟
هڪ عام دورو ڪندڙ سائيٽ جو دورو ڪندو آهي، مثال طور، مختلف اشتهارن مان مهيني ۾ 20 ڀيرا، يا ڪڏهن ڪڏهن هو بغير ڪنهن اشتهار جي اچي ٿو، ڇاڪاڻ ته هن کي هن سائيٽ کي ياد آهي. ڪجهه شين کي ڏسندو آهي، انهن کي ٽوڪري ۾ وجهي ٿو، انهن کي ٽوڪري مان ڪڍي ٿو. ۽، آخر ۾، هو ڪجهه خريد ڪري ٿو.
معقول سوال: "جيڪڏهن ضروري هجي ته اشتهارن لاءِ ڪير ادا ڪري؟" ۽ "ڪهڙي اشتهارن، جيڪڏهن ڪو، هن کي متاثر ڪيو؟" يعني هن ڇو خريد ڪيو ۽ ڪيئن پڪ ڪجي ته هن شخص جهڙا ماڻهو به خريد ڪن؟
هن مسئلي کي حل ڪرڻ لاء، توهان کي ويب سائيٽ تي واقع ٿيندڙ واقعن کي صحيح طريقي سان ڳنڍڻ جي ضرورت آهي، اهو آهي، ڪنهن به طريقي سان انهن جي وچ ۾ ڪنيڪشن ٺاهيو. ان کان پوء اهي تجزيي لاء DWH ڏانهن منتقل ڪيا ويا آهن. ۽ ھن تجزيي جي بنياد تي، ماڊل ٺاھيو جنھن کي ڏيکاريو ڇا اشتهار.
هڪ اشتهاري ٽرانزيڪشن لاڳاپيل صارف جي واقعن جو هڪ سيٽ آهي جيڪو هڪ اشتهار ڏيکاريندي سان شروع ٿئي ٿو، پوء ڪجهه ٿئي ٿو، پوء ٿي سگهي ٿو هڪ خريداري، ۽ پوء خريداري ۾ خريداري ٿي سگهي ٿي. مثال طور، جيڪڏهن هي موبائيل ايپليڪيشن يا موبائيل گيم آهي ته پوءِ عام طور تي ايپليڪيشن کي انسٽال ڪرڻ مفت آهي، پر جيڪڏهن ڪو ٻيو ڪم اتي ڪيو وڃي ته ان لاءِ پئسي جي ضرورت پئجي سگهي ٿي. ۽ جيترو وڌيڪ ماڻهو ايپ ۾ خرچ ڪندو، اهو وڌيڪ قيمتي آهي. پر هن لاء توهان کي هر شيء کي ڳنڍڻ جي ضرورت آهي.
اتي ڪيترائي پابند ماڊل آھن.
سڀ کان وڌيڪ مشهور آهن:
- آخري تعامل، جتي ڳالهه ٻولهه يا ته هڪ ڪلڪ يا تاثر آهي.
- پهرين ڳالهه ٻولهه، يعني پهرين شيء جيڪا هڪ شخص کي سائيٽ تي آندو.
- لڪير ميلاپ - سڀني لاء برابر حصيداري.
- ڌيان ڏيڻ.
- ۽ ايئن.
۽ اهو سڀ ڪيئن شروع ۾ ڪم ڪيو؟ اتي رن ٽائم ۽ ڪاسندرا هئي. Cassandra ٽرانزيڪشن اسٽوريج طور استعمال ڪيو ويو، يعني سڀئي لاڳاپيل ٽرانزيڪشن ان ۾ محفوظ ڪيا ويا. ۽ جڏهن رن ٽائم ۾ ڪو واقعو ٿئي ٿو، مثال طور، ڪنهن صفحي جي ڊسپلي يا ڪا ٻي شيءِ، ڪاسندرا کي گذارش ڪئي ويندي آهي ته ڪو اهڙو ماڻهو آهي يا نه. پوءِ ان سان واسطو رکندڙ ٽرانزيڪشن مليا. ۽ پابند ٿي ويو.
۽ جيڪڏهن توهان خوش قسمت آهيو ته درخواست ۾ ٽرانزيڪشن جي سڃاڻپ شامل آهي، پوء اهو آسان آهي. پر عام طور تي توهان وٽ ڪا قسمت ناهي. تنهن ڪري، اهو ضروري هو ته آخري ٽرانزيڪشن يا آخري ڪلڪ سان ٽرانزيڪشن، وغيره.
۽ اهو سڀ ڪجهه تمام سٺو ڪم ڪيو جيستائين لنڪنگ آخري ڪلڪ تائين هئي. ڇو ته هتي آهن، چئو، 10 ملين ڪلڪ في ڏينهن، 300 ملين في مهيني، جيڪڏهن توهان هڪ مهيني لاءِ ونڊو سيٽ ڪيو. ۽ جتان ڪئاسندرا ۾ اهو سڀ ڪجهه يادگيري ۾ هجڻ ضروري آهي جلدي ڪم ڪرڻ لاءِ، ڇاڪاڻ ته رن ٽائيم گهربل آهي تڪڙو جواب ڏيڻ لاءِ، لڳ ڀڳ 10-15 سرور گهربل هئا.
۽ جڏهن اهي هڪ ٽرانزيڪشن کي ڊسپلي سان ڳنڍڻ چاهيندا هئا، اهو فوري طور تي ظاهر ٿيو ته ايترو مزو نه هو. ۽ ڇو؟ اهو ڏسي سگهجي ٿو ته 30 ڀيرا وڌيڪ واقعن کي ذخيرو ڪرڻ جي ضرورت آهي. ۽، مطابق، توهان کي ضرورت آهي 30 ڀيرا وڌيڪ سرور. ۽ اهو ظاهر ٿئي ٿو ته هي ڪجهه قسم جي astronomical شخصيت آهي. لنڪنگ ڪرڻ لاءِ 500 سرورن تائين رکڻ، ان حقيقت جي باوجود ته رن ٽائم ۾ تمام گهٽ سرورز آهن، هڪ قسم جي غلط انگ اکر آهي. ۽ سوچڻ لڳا ته ڇا ڪجي.
۽ اسان ڪلڪ هائوس ڏانهن ويا. ClickHouse تي اهو ڪيئن ڪجي؟ پهرين نظر ۾، اهو لڳي ٿو ته هي اينٽي پيٽرن جو هڪ سيٽ آهي.
- ٽرانزيڪشن وڌي رهي آهي، اسان ان سان وڌيڪ ۽ وڌيڪ واقعا ڳنڍي رهيا آهيون، يعني اهو ميوٽيڪل آهي، ۽ ClickHouse تبديل ٿيندڙ شين سان تمام سٺو ڪم نٿو ڪري.
- جڏهن ڪو دورو ڪندڙ اسان وٽ اچي ٿو، اسان کي هن جي ٽرانزيڪشن کي ٻيهر حاصل ڪرڻ جي ضرورت آهي، هن جي دوري جي سڃاڻپ ذريعي. اهو پڻ هڪ نقطو سوال آهي؛ ClickHouse اهو نٿو ڪري. عام طور تي ڪلڪ هائوس ۾ وڏا…اسڪين هوندا آهن، پر هتي اسان کي ڪيترائي رڪارڊ حاصل ڪرڻ گهرجن. پڻ هڪ مخالف نمونو.
- ان کان علاوه، ٽرانزيڪشن json ۾ هو، پر اهي ان کي ٻيهر لکڻ نه چاهيندا هئا، تنهن ڪري اهي json کي غير منظم طور تي ذخيرو ڪرڻ چاهيندا هئا، ۽ جيڪڏهن ضروري هجي ته، ان مان ڪجهه ڪڍو. ۽ اهو پڻ هڪ مخالف نمونو آهي.
اهو آهي، antipatterns جو هڪ سيٽ.
پر ان جي باوجود، اسان هڪ سسٽم ٺاهيو جيڪو تمام سٺو ڪم ڪيو.
ڇا ڪيو ويو؟ ڪلڪ هائوس ظاهر ٿيو، جنهن ۾ لاگز، رڪارڊ ۾ ورهايل، اڇلايا ويا. هڪ منسوب ڪيل خدمت ظاهر ٿي جيڪا ڪلڪ هائوس کان لاگ وصول ڪئي. ان کان پوء، هر داخل ٿيڻ لاء وزٽ id ذريعي، مون کي ٽرانزيڪشن مليا جيڪي اڃا تائين پروسيس نه ٿي سگهيا آهن ۽ ان سان گڏ سنيپ شاٽ، يعني ٽرانزيڪشن اڳ ۾ ئي ڳنڍيل آهن، يعني اڳئين ڪم جو نتيجو. مون پهريان ئي انهن مان منطق ٺاهيو، صحيح ٽرانزيڪشن چونڊيو، ۽ نوان واقعا ڳنڍيو. ٻيهر لاگ ان ٿيو. لاگ واپس ڪلڪ هائوس ڏانهن ويو، يعني اهو هڪ مسلسل چڪر وارو نظام آهي. ۽ ان کان علاوه، مان DWH ڏانهن ويو اتي ان جو تجزيو ڪرڻ لاء.
اهو هن فارم ۾ تمام سٺو ڪم نه ڪيو. ۽ ڪلڪ هاؤس لاءِ آسان بڻائڻ لاءِ، جڏهن وزٽ آئي ڊي جي درخواست هئي، انهن درخواستن کي 1-000 وزٽ آئي ڊيز جي بلاڪن ۾ گروپ ڪيو ۽ 2-000 ماڻهن لاءِ سڀ ٽرانزيڪشن ڪڍي ڇڏيا. ۽ پوء اهو سڀ ڪم ڪيو.
جيڪڏھن توھان اندر ڏسو ClickHouse، اتي صرف 3 مکيه جدول آھن جيڪي ھي سڀ ڪم ڪن ٿيون.
پهرين جدول جنهن ۾ لاگ اپ لوڊ ڪيا ويا آهن، ۽ لاگز اپلوڊ ڪيا ويا آهن بغير ڪنهن پروسيسنگ سان.
ٻيو ٽيبل. مادي ڏسڻ جي ذريعي، واقعا جيڪي اڃا تائين منسوب نه ڪيا ويا آهن، يعني، غير لاڳاپيل، انهن لاگن مان ڪڍيا ويا آهن. ۽ مادي ڏسڻ جي ذريعي، ٽرانزيڪشن انهن لاگن مان ڪڍيا ويا هڪ سنيپ شاٽ ٺاهڻ لاء. اهو آهي، هڪ سنيپ شاٽ هڪ خاص مادي نظر سان ٺاهيو ويو، يعني ٽرانزيڪشن جي آخري جمع ٿيل حالت.
هتي متن SQL ۾ لکيل آهي. مان ان ۾ ڪيترن ئي اهم ڳالهين تي تبصرو ڪرڻ چاهيندس.
پهرين اهم شيءِ آهي ClickHouse ۾ صلاحيت آهي json مان ڪالمن ۽ فيلڊز ڪڍڻ لاءِ. اھو آھي، ClickHouse وٽ ڪجھ طريقا آھن json سان ڪم ڪرڻ لاءِ. اهي ڏاڍا، ڏاڍا ابتدائي آهن.
visitParamExtractInt توهان کي json مان خاصيتون ڪڍڻ جي اجازت ڏئي ٿي، يعني پهريون هٽ شروع ڪيو ويو آهي. ۽ هن طريقي سان توهان ٽرانزيڪشن id ڪڍي سگهو ٿا يا id جو دورو ڪري سگهو ٿا. هن ڀيري.
ٻيو، هڪ مشڪل مادي ٿيل فيلڊ هتي استعمال ڪيو ويو آهي. هن جو ڇا مطلب آهي؟ ان جو مطلب اهو آهي ته توهان ان کي ٽيبل ۾ داخل نه ٿا ڪري سگهو، يعني اهو داخل نه ڪيو ويو آهي، اهو حساب ڪيو ويندو آهي ۽ ذخيرو ٿيل آهي جڏهن داخل ڪيو وڃي. جڏهن توهان داخل ڪيو، ڪلڪ هائوس توهان لاء ڪم ڪندو. ۽ توهان کي بعد ۾ ڇا جي ضرورت پوندي json مان ڪڍيو ويو آهي.
هن معاملي ۾، مادي نظر خام تارن لاء آهي. ۽ پھريون ٽيبل لڳ ڀڳ خام لاگن سان استعمال ڪيو ويندو آھي. ۽ اهو ڇا ڪندو آهي؟ پهرين، اها ترتيب تبديل ڪري ٿي، يعني ترتيب ڏيڻ هاڻي وزٽ id ذريعي ڪيو ويو آهي، ڇاڪاڻ ته اسان کي تڪڙو تڪڙو ڪڍڻو پوندو خاص طور تي هڪ خاص شخص لاءِ.
ٻي اهم شيءِ آهي index_granularity. جيڪڏھن توھان ڏٺو آھي MergeTree، پوءِ عام طور تي ڊفالٽ ويل آھي 8 index_granularity. هي ڇا آهي؟ هي آهي انڊيڪس اسپارسٽي پيٽرول. ClickHouse ۾، انڊيڪس ويجھو آھي؛ اھو ڪڏھن به ھر رڪارڊ کي انڊيڪس نٿو ڪري. اهو هر 192 تي ڪري ٿو. ۽ اهو سٺو آهي جڏهن توهان کي تمام گهڻو ڊيٽا کي ڳڻڻ جي ضرورت آهي، پر اهو خراب آهي جڏهن توهان کي ٿورو حساب ڪرڻ جي ضرورت آهي، ڇاڪاڻ ته اتي تمام گهڻو مٿي آهي. ۽ جيڪڏهن اسان انڊيڪس گرينولرٽي کي گھٽائينداسين، ته پوء اسان مٿي کي گھٽائينداسين. توھان ان کي ھڪڙي تائين گھٽائي نٿا سگھو، ڇاڪاڻتہ شايد ڪافي ياداشت نه ھجي. انڊيڪس هميشه ياداشت ۾ ذخيرو ٿيل آهي.
۽ سنيپ شاٽ استعمال ڪري ٿو ڪجھ ٻيا دلچسپ ClickHouse افعال.
پهريون آهي AggregatingMergeTree. ۽ AggregatingMergeTree اسٽور argMax، يعني هي ٽرانزيڪشن اسٽيٽ آهي جيڪو آخري ٽائم اسٽيمپ سان لاڳاپيل آهي. نئين ٽرانزيڪشن هميشه هن دورو ڪندڙ لاء ٺاهي رهيا آهن. ۽ هن ٽرانزيڪشن جي بلڪل آخري حالت ۾، اسان هڪ واقعو شامل ڪيو ۽ اسان وٽ هڪ نئين رياست هئي. اهو وري ڪلڪ هائوس کي ماريو. ۽ ArgMax ذريعي هن مادي نظر ۾ اسان هميشه موجوده حالت حاصل ڪري سگهون ٿا.
- رن ٽائم مان بائنڊنگ ”اڻ ٽٽل“ آهي.
- هر مهيني 3 بلين ٽرانزيڪشن تائين ذخيرو ۽ پروسيس ٿيل آهن. هي هڪ آرڊر جي شدت کان وڌيڪ آهي Cassandra ۾، يعني، هڪ عام ٽرانزيڪشنل سسٽم ۾.
- 2x5 ڪلڪ هائوس سرورز جو ڪلستر. 5 سرورز ۽ هر سرور وٽ هڪ نقل آهي. ڪلڪ جي بنياد تي انتساب ڪرڻ لاءِ اهو Cassandra ۾ هو ان کان به گهٽ آهي، پر هتي اسان وٽ تاثر آهي. يعني سرورن جو تعداد 30 ڀيرا وڌائڻ بدران گھٽجي ويو.
۽ آخري مثال مالي ڪمپني Y آهي، جنهن اسٽاڪ جي قيمتن ۾ تبديلين جي لاڳاپن جو تجزيو ڪيو.
۽ ڪم هي هو:
- لڳ ڀڳ 5 شيئر آهن.
- اقتباس هر 100 milliseconds سڃاتل آهن.
- ڊيٽا 10 سالن کان مٿي گڏ ڪئي وئي آهي. ظاهر آهي، ڪجهه ڪمپنين لاء اهو وڌيڪ آهي، ڪجهه لاء اهو گهٽ آهي.
- مجموعي طور تي لڳ ڀڳ 100 ارب قطارون آهن.
۽ اهو ضروري هو ته تبديلين جي لاڳاپن کي ڳڻڻ.
هتي ٻه اسٽاڪ ۽ انهن جا حوالا آهن. جيڪڏھن ھڪڙو مٿي وڃي ٿو ۽ ٻيو مٿي وڃي ٿو، ته اھو ھڪڙو مثبت تعلق آھي، يعني ھڪڙو مٿي وڃي ٿو ۽ ٻيو مٿي وڃي ٿو. جيڪڏھن ھڪڙو مٿي وڃي ٿو، جيئن گراف جي آخر ۾، ۽ ٻيو ھيٺ وڃي ٿو، پوء اھو ھڪڙو منفي تعلق آھي، يعني جڏھن ھڪڙو مٿي وڃي ٿو، ٻيو ھيٺ وڃي ٿو.
انهن باهمي تبديلين جو تجزيو ڪندي، هڪ ڪري سگھي ٿو اڳڪٿيون مالي مارڪيٽ ۾.
پر ڪم ڏکيو آهي. ان لاءِ ڇا ڪيو پيو وڃي؟ اسان وٽ 100 بلين رڪارڊ آھن جن تي مشتمل آھي: وقت، اسٽاڪ ۽ قيمت. اسان کي پهريان حساب ڪرڻ جي ضرورت آهي 100 بلين ڀيرا ڊوڙندڙ فرق قيمت جي الگورتھم کان. RunningDifference ClickHouse ۾ ھڪڙو فنڪشن آھي جيڪو ترتيب سان حساب ڪري ٿو ٻن لائينن جي وچ ۾ فرق.
۽ ان کان پوء اسان کي باهمي تعلق کي ڳڻڻ جي ضرورت آهي، ۽ باهمي تعلق هر هڪ جوڙي لاء حساب ڪيو وڃي. 5 شيئرز لاءِ، جوڙا 000 ملين آھن. ۽ اهو تمام گهڻو آهي، يعني 12,5 ڀيرا توهان کي هن باضابطه فعل کي ڳڻڻ جي ضرورت آهي.
۽ صورت ۾ ڪو به وساري ويو، ͞x ۽ ͞y چيڪ ميٽ آهن. نموني جي توقع. اهو آهي، توهان کي نه رڳو روٽ ۽ رقم جي حساب ڪرڻ جي ضرورت آهي، پر انهن رقمن ۾ ٻين رقمن کي پڻ. گھڻا ۽ گھڻا حساب 12,5 ملين ڀيرا ڪرڻ جي ضرورت آھي، ۽ انھن کي ڪلاڪ جي حساب سان گڏ ڪرڻ جي ضرورت آھي. ۽ اسان وٽ پڻ ڪيترائي ڪلاڪ آهن. ۽ توهان کي اهو ڪرڻو پوندو 60 سيڪنڊن ۾. اهو هڪ مذاق آهي.
اسان کي ان کي ڪنهن نه ڪنهن طريقي سان ٺاهڻو هو، ڇاڪاڻ ته ڪلڪ هاؤس جي اچڻ کان اڳ اهو سڀ تمام گهڻو، تمام سست ڪم ڪيو.
هنن اهو حساب ڪرڻ جي ڪوشش ڪئي هڊوپ تي، اسپارڪ تي، گرين پلم تي. ۽ اهو سڀ ڪجهه تمام سست يا قيمتي هو. اهو آهي، اهو ممڪن هو ته ڪنهن به حساب سان حساب ڪيو وڃي، پر پوء اهو قيمتي هو.
۽ پوءِ ڪلڪ هائوس آيو ۽ سڀ ڪجهه بهتر ٿي ويو.
مون کي توهان کي ياد ڏيارڻ ڏيو ته اسان وٽ ڊيٽا جي جڳهه سان مسئلو آهي، تنهنڪري لاڳاپا مقامي نٿا ٿي سگهن. اسان ڪجھ ڊيٽا شامل نه ٿا ڪري سگھون ھڪڙي سرور ۾، ڪجھ ٻئي ڏانھن ۽ حساب ڪريو؛ اسان وٽ لازمي آھي سڀ ڊيٽا ھر جڳھ تي.
هنن ڇا ڪيو؟ شروعات ۾، ڊيٽا مقامي آهي. هر سرور حصص جي مخصوص سيٽ لاءِ قيمتن جي ڊيٽا کي ذخيرو ڪري ٿو. ۽ اهي ٽڪرا نه ٿا ڪن. تنهن ڪري، اهو ممڪن آهي logReturn کي متوازي ۽ آزاد طور تي ڳڻڻ؛ اهو سڀ ڪجهه متوازي ۽ تقسيم ۾ ٿئي ٿو.
ان کان پوء اسان اظهار کي وڃائڻ کان سواء هن ڊيٽا کي گهٽائڻ جو فيصلو ڪيو. arrays استعمال ڪندي گھٽايو، يعني، وقت جي هر دور لاءِ، اسٽاڪ جو هڪ صف ۽ قيمتن جو هڪ صف ٺاهيو. اهڙيء طرح اهو تمام گهٽ ڊيٽا جي جاء وٺندو آهي. ۽ اهي ڪم ڪرڻ لاء ڪجهه وڌيڪ آسان آهن. اهي لڳ ڀڳ متوازي عمل آهن، يعني اسين جزوي طور تي متوازي ۾ شمار ڪريون ٿا ۽ پوءِ سرور ڏانهن لکون ٿا.
اهو وري نقل ڪري سگهجي ٿو. خط "r" جو مطلب آهي ته اسان هن ڊيٽا کي نقل ڪيو. اهو آهي، اسان وٽ سڀني ٽن سرورن تي ساڳيو ڊيٽا آهي - اهي آهن arrays.
۽ پوءِ، ھڪ خاص اسڪرپٽ استعمال ڪندي، توھان 12,5 ملين لاڳاپن جي ھن سيٽ مان پيڪيجز ٺاھي سگھو ٿا جن کي ڳڻڻ جي ضرورت آھي. اهو آهي، 2 ڪمن سان گڏ 500 جوڑوں جو تعلق. ۽ اهو ڪم هڪ مخصوص ClickHouse سرور تي حساب ڪيو وڃي. هن وٽ سموري ڊيٽا آهي ڇو ته ڊيٽا ساڳي آهي ۽ هو ان کي ترتيب سان حساب ڪري سگهي ٿو.
هتي اهو آهي ته اهو ٻيهر ڏسڻ ۾ اچي ٿو. پهريون، اسان وٽ ھيٺ ڏنل ڍانچي ۾ سڀ ڊيٽا آھي: وقت، حصص، قيمت. پوءِ اسان حساب ڪيو logReturn، يعني ساڳي ڍانچي جي ڊيٽا، رڳو قيمت جي بدران اسان وٽ logReturn آهي. پوءِ انهن کي ٻيهر ڪيو ويو، يعني اسان کي پروموشنز ۽ پرائس لسٽن ذريعي وقت ۽ گروپ آري ملي وئي. نقل ٿيل. ۽ ان کان پوء، انهن ڪمن جو هڪ گروپ ٺاهيو ۽ انهن کي ClickHouse کي کارايو ته جيئن اهو انهن کي شمار ڪري سگهي. ۽ اهو ڪم ڪري ٿو.
تصور جي ثبوت تي، ڪم ھڪڙو ذيلي ڪم ھو، يعني اھي گھٽ ڊيٽا ورتي. ۽ صرف ٽن سرورن تي.
اهي پهريان ٻه مرحلا: حساب ڪرڻ Log_return ۽ ان کي صفن ۾ لپائڻ هر هڪ ڪلاڪ بابت.
۽ لاڳاپي جي حساب سان لڳ ڀڳ 50 ڪلاڪ لڳن ٿا. پر 50 ڪلاڪ ڪافي نه آهن، ڇاڪاڻ ته اڳ ۾ اهو انهن لاء هفتي لاء ڪم ڪيو. اها هڪ وڏي ڪاميابي هئي. ۽ جيڪڏھن توھان ڳڻيو، پوء سڀ ڪجھ ڳڻيو ويو 70 ڀيرا في سيڪنڊ ھن ڪلستر تي.
پر سڀ کان اهم ڳالهه اها آهي ته هن نظام ۾ عملي طور تي ڪا به رڪاوٽ نه آهي، يعني اهو تقريباً لڪيريءَ سان ماپي ٿو. ۽ انهن کي چڪاس ڪيو. اهو ڪاميابي سان ماپ ڪيو ويو.
- صحيح منصوبو اڌ ڪاميابي آهي. ۽ صحيح اسڪيم تمام ضروري ClickHouse ٽيڪنالاجي استعمال ڪرڻ آهي.
- Summing/AggregatingMergeTrees اهي ٽيڪنالاجيون آهن جيڪي توهان کي هڪ خاص ڪيس جي طور تي رياست جي سنيپ شاٽ کي گڏ ڪرڻ يا ڳڻڻ جي اجازت ڏين ٿيون. ۽ اهو تمام گهڻيون شيون آسان بڻائي ٿو.
- مادي ٿيل نظارا توهان کي هڪ-انڊيڪس جي حد جي چوڌاري حاصل ڪرڻ جي اجازت ڏين ٿا. ٿي سگهي ٿو ته مون اهو واضح طور تي نه چيو هو، پر جڏهن اسان لاگ لوڊ ڪيو، خام لاگ هڪ ٽيبل ۾ هڪ انڊيڪس سان گڏ هئا، ۽ خاصيت تي لاگز ٽيبل ۾ هئا، يعني ساڳي ڊيٽا، صرف فلٽر ٿيل، پر انڊيڪس هو. مڪمل طور تي ٻين کي. اهو لڳي ٿو ساڳيو ڊيٽا، پر مختلف ترتيب. ۽ Materialized Views توهان کي اجازت ڏئي ٿو، جيڪڏهن توهان کي ضرورت هجي، هن ڪلڪ هائوس جي حد کي نظرانداز ڪرڻ لاءِ.
- پوائنٽ سوالن لاء انڊيڪس گرينولرٽي کي گھٽايو.
- ۽ ڊيٽا کي هوشياريءَ سان ورهايو، ڪوشش ڪريو سرور جي اندر ڊيٽا کي جيترو ٿي سگهي مقامي ڪرڻ جي. ۽ انهي ڳالهه کي يقيني بڻائڻ جي ڪوشش ڪريو ته درخواستون پڻ لوڪلائيزيشن کي استعمال ڪن ٿيون جتي ممڪن هجي جيترو ممڪن هجي.
۽ هن مختصر تقرير کي اختصار ڪرڻ لاءِ، اسان اهو چئي سگهون ٿا ته ClickHouse هاڻي مضبوطيءَ سان ٻنهي تجارتي ڊيٽابيس ۽ اوپن سورس ڊيٽابيس جي علائقي تي قبضو ڪري ورتو آهي، يعني خاص طور تي اينالائيٽڪس لاءِ. هو هن منظر ۾ مڪمل طور تي ٺهڪي اچي ٿو. ۽ وڌيڪ ڇا آهي، اهو آهستي آهستي ٻين کي بيهڻ شروع ڪري رهيو آهي، ڇاڪاڻ ته جڏهن ڪلڪ هاؤس موجود آهي، توهان کي InfiniDB جي ضرورت ناهي. عمودي جلد ئي گهربل نه هجي جيڪڏهن اهي عام SQL سپورٽ مهيا ڪن. ان کي استعمال ڪريو!
-رپورٽ لاءِ مهرباني! تمام دلچسپ! ڇا اپاچي فينڪس سان ڪو مقابلو ڪيو ويو آهي؟
- نه، مون ڪنهن کي به مقابلو ڪندي نه ٻڌو آهي. اسان ۽ Yandex مختلف ڊيٽابيسن سان ڪلڪ هائوس جي سڀني موازن جي ٽريڪ رکڻ جي ڪوشش ڪندا آهيون. ڇاڪاڻ ته جيڪڏهن اوچتو ڪا شيءَ ڪلڪ هاؤس کان وڌيڪ تيز ٿي وڃي ٿي، ته پوءِ ليشا ملوودوف رات جو سمهي نه ٿو سگهي ۽ ان کي تيز ڪرڻ شروع ڪري ٿو. مون اهڙي مقابلي بابت نه ٻڌو آهي.
-
(Alexey Milovidov) Apache Phoenix Hbase تي ٻڌل هڪ SQL انجڻ آهي. Hbase بنيادي طور تي ٺهيل قدر جي قسم جي ڪم جي منظر لاء ٺهيل آهي. اتي، ھر لڪير ۾ صوابديدي نالن سان ڪالمن جو ھڪ صوابديدي نمبر ٿي سگھي ٿو. اهو سسٽم بابت چئي سگهجي ٿو جهڙوڪ Hbase ۽ Cassandra. ۽ اهو خاص طور تي ڳري تجزياتي سوال آهي جيڪي عام طور تي انهن لاءِ ڪم نه ڪندا. يا توهان سوچيو ته اهي ٺيڪ ڪم ڪن ٿا جيڪڏهن توهان وٽ ClickHouse سان ڪو تجربو نه آهي.
-
Спасибо
-
منجهند جو سلام مان پهريان ئي هن موضوع ۾ ڪافي دلچسپي وٺان ٿو، ڇاڪاڻ ته مون وٽ هڪ تجزياتي سب سسٽم آهي. پر جڏهن مان ClickHouse کي ڏسان ٿو، مون کي محسوس ٿئي ٿو ته ClickHouse واقعي جي تجزيي لاءِ بلڪل موزون آهي، مٽائي. ۽ جيڪڏهن مون کي وڏي جدولن جي هڪ گروپ سان تمام گهڻي ڪاروباري ڊيٽا جو تجزيو ڪرڻ جي ضرورت آهي، ته پوءِ ڪلڪ هاؤس، جيتري قدر مان سمجهان ٿو، اهو مون لاءِ مناسب ناهي؟ خاص طور تي جيڪڏهن اهي تبديل ٿي وڃن. ڇا اهو صحيح آهي يا اهڙا مثال آهن جيڪي هن کي غلط ثابت ڪري سگھن ٿا؟
-
اهو صحيح آهي. ۽ اھو سچ آھي سڀ کان وڌيڪ خاص تجزياتي ڊيٽابيس بابت. اهي حقيقت جي مطابق ٺهيل آهن ته اتي هڪ يا ڪيترائي وڏا ٽيبل آهن جيڪي ميٽابيل آهن، ۽ ڪيترائي ننڍا آهن جيڪي دير سان تبديل ٿيندا آهن. اهو آهي، ClickHouse Oracle وانگر ناهي، جتي توهان سڀ ڪجهه رکي سگهو ٿا ۽ ڪجهه تمام پيچيده سوال ٺاهي سگهو ٿا. ClickHouse کي مؤثر طريقي سان استعمال ڪرڻ لاءِ، توھان کي ضرورت آھي ته اسڪيم کي اھڙي طريقي سان ٺاھيو جيڪو ClickHouse ۾ سٺو ڪم ڪري. اھو آھي، گھڻي عام ڪرڻ کان پاسو ڪريو، لغات استعمال ڪريو، گھٽ ڊگھو ڪنيڪشن ٺاهڻ جي ڪوشش ڪريو. ۽ جيڪڏهن اسڪيم هن طريقي سان ٺهيل آهي، ته پوءِ ساڳيون ڪاروباري مسئلا حل ٿي سگهن ٿا ClickHouse تي روايتي لاڳاپن واري ڊيٽابيس جي ڀيٽ ۾ وڌيڪ موثر.
-
رپورٽ لاءِ مهرباني! مون وٽ تازو مالي ڪيس بابت هڪ سوال آهي. انهن وٽ تجزيا هئا. ان جو مقابلو ڪرڻ ضروري هو ته اهي ڪيئن مٿي ۽ هيٺ وڃن ٿا. ۽ مان سمجھان ٿو ته توھان سسٽم ٺاھيو آھي خاص طور تي ھن تجزياتي لاءِ؟ جيڪڏهن سڀاڻي، چئو ته، انهن کي هن ڊيٽا تي ڪجهه ٻي رپورٽ جي ضرورت آهي، ڇا انهن کي ٻيهر ڊراگرام ٺاهڻ ۽ ڊيٽا لوڊ ڪرڻ جي ضرورت آهي؟ اهو آهي، درخواست حاصل ڪرڻ لاء ڪجهه قسم جي اڳڀرائي ڪريو؟
يقينا، هي استعمال ڪري رهيو آهي ClickHouse هڪ خاص ڪم لاءِ. اهو وڌيڪ روايتي طور تي Hadoop اندر حل ٿي سگهي ٿو. Hadoop لاء هي هڪ مثالي ڪم آهي. پر Hadoop تي اهو تمام سست آهي. ۽ منهنجو مقصد اهو ظاهر ڪرڻ آهي ته ClickHouse مسئلا حل ڪري سگهي ٿو جيڪي عام طور تي مڪمل طور تي مختلف طريقن سان حل ڪيا ويندا آهن، پر ساڳئي وقت اهو وڌيڪ موثر طريقي سان ڪيو. اهو هڪ خاص ڪم لاء ٺهيل آهي. اهو واضح آهي ته جيڪڏهن ڪو مسئلو آهي جيڪو ڪنهن حد تائين هڪجهڙائي آهي، ته پوء ان کي هڪجهڙائي سان حل ڪري سگهجي ٿو.
اهو واضح آهي. توهان چيو ته ان کي پروسيس ڪرڻ ۾ 50 ڪلاڪ لڳا. ڇا اهو شروع کان شروع ٿئي ٿو، جڏهن توهان ڊيٽا کي لوڊ ڪيو يا نتيجا حاصل ڪيو؟
ها ها.
ٺيڪ آهي توهان جي وڏي مهرباني.
هي هڪ 3 سرور ڪلستر تي آهي.
سلام! رپورٽ لاءِ مهرباني! هر شي ڏاڍي دلچسپ آهي. مان ڪارڪردگي بابت ٿورڙو نه پڇان، پر استحڪام جي نقطي نظر کان ClickHouse استعمال ڪرڻ بابت. اھو آھي، ڇا توھان وٽ ڪو مسئلو آھي ۽ ڇا توھان انھن کي بحال ڪرڻو آھي؟ ClickHouse ڪيئن ڪم ڪندو؟ ۽ ڇا ڪڏهن ائين ٿيو آهي ته توهان جي نقل پڻ تباهه ٿي وئي آهي؟ مثال طور، اسان ClickHouse سان هڪ مسئلو پيش ڪيو جڏهن اهو اڃا تائين پنهنجي حد کان ٻاهر نڪري ويو ۽ گر ٿي ويو.
يقينا، ڪو به مثالي نظام نه آهي. ۽ ClickHouse پڻ ان جا مسئلا آهن. پر ڇا توهان Yandex.Metrica جي باري ۾ ٻڌو آهي هڪ ڊگهي وقت تائين ڪم نه ڪري رهيو آهي؟ شايد نه. اهو ClickHouse تي 2012-2013 کان معتبر طور تي ڪم ڪري رهيو آهي. مان پنهنجي تجربي بابت ساڳيو ئي چئي سگهان ٿو. اسان ڪڏهن به مڪمل ناڪامي نه ڪئي آهي. ڪجهه جزوي شيون ٿي سگهن ٿيون، پر اهي ڪڏهن به ڪافي نازڪ نه هيون ته ڪاروبار کي سنجيده متاثر ڪن. ائين اڳ ڪڏهن به نه ٿيو آهي. ClickHouse ڪافي قابل اعتماد آهي ۽ بي ترتيب سان حادثو نٿو ٿئي. توهان کي ان بابت پريشان ٿيڻ جي ضرورت ناهي. اها ڪا خام شيءِ ناهي. اهو ڪيترن ئي ڪمپنين پاران ثابت ڪيو ويو آهي.
سلام! توهان چيو ته توهان کي فوري طور تي ڊيٽا اسڪيما بابت احتياط سان سوچڻ جي ضرورت آهي. جيڪڏهن ائين ٿيو ته ڇا ٿيو؟ منهنجي ڊيٽا اندر ۽ ٻاهر نڪرندي آهي. ڇهه مهينا گذري ويا، ۽ مان سمجهان ٿو ته مان هن طرح جيئرو نه ٿو رهي سگهان، مون کي ڊيٽا کي ٻيهر اپلوڊ ڪرڻ ۽ ان سان ڪجهه ڪرڻ جي ضرورت آهي.
اهو منحصر آهي، يقينا، توهان جي سسٽم تي. اتي ڪيترائي طريقا آھن ھن کي تقريبا غير اسٽاپ ڪرڻ لاء. مثال طور، توهان ٺاهي سگهو ٿا هڪ مادي ٿيل ڏيک جنهن ۾ توهان هڪ مختلف ڊيٽا ڍانچي ٺاهي سگهو ٿا جيڪڏهن اهو منفرد طور تي ميپ ڪري سگهجي ٿو. اهو آهي، جيڪڏهن اهو ڪلڪ هاؤس استعمال ڪندي ميپنگ جي اجازت ڏئي ٿو، يعني ڪجهه شيون ڪڍڻ، پرائمري ڪيچ کي تبديل ڪرڻ، ورهاڱي کي تبديل ڪرڻ، پوء توهان هڪ مواد ٺاهي سگهو ٿا. اتي توهان جي پراڻي ڊيٽا ٻيهر لکي ويندي، نوان خودڪار طور تي لکيا ويندا. ۽ پوءِ صرف مٽيريل ٿيل ڏيک استعمال ڪرڻ تي سوئچ ڪريو، پوءِ رڪارڊ کي مٽايو ۽ پراڻي ٽيبل کي ماريو. اهو عام طور تي غير اسٽاپ طريقو آهي.
مهرباني
جو ذريعو: www.habr.com