گذريل ڪجھ سالن کان، وقت جي سيريز ڊيٽابيس هڪ غير معمولي شيء کان تبديل ٿي ويا آهن (انتهائي خاص استعمال ٿيل يا ته اوپن مانيٽرنگ سسٽم ۾ (۽ مخصوص حلن سان ڳنڍيل) يا بگ ڊيٽا منصوبن ۾) "صارفين جي پيداوار" ۾. روسي فيڊريشن جي سرزمين تي، هن لاء خاص مهرباني Yandex ۽ ClickHouse کي ڏنو وڃي. هن نقطي تائين، جيڪڏهن توهان کي وقت جي سيريز جي ڊيٽا جي وڏي مقدار کي ذخيرو ڪرڻ جي ضرورت هئي، توهان کي يا ته ضرورت سان شرطن تي اچڻو پوندو هودوپ اسٽيڪ ٺاهڻ ۽ ان کي برقرار رکڻ، يا هر سسٽم لاء انفرادي پروٽوڪول سان رابطو ڪرڻ.
اهو لڳي سگھي ٿو ته 2019 ۾ هڪ مضمون جنهن بابت TSDB استعمال ڪرڻ جي قابل آهي صرف هڪ جملي تي مشتمل هوندو: "صرف ڪلڪ هاؤس استعمال ڪريو." پر ... اتي nuances آهن.
درحقيقت، ClickHouse فعال طور تي ترقي ڪري رهيو آهي، صارف جو بنياد وڌي رهيو آهي، ۽ سپورٽ تمام سرگرم آهي، پر ڇا اسان ڪلڪ هائوس جي عوامي ڪاميابيءَ جا يرغمال بڻيل آهيون، جنهن ٻين، شايد وڌيڪ اثرائتي/قابل اعتماد حلن جي ڇنڊڇاڻ ڪئي آهي؟
گذريل سال جي شروعات ۾، اسان پنهنجي نگراني واري نظام کي ٻيهر ڪم ڪرڻ شروع ڪيو، جنهن دوران ڊيٽا کي محفوظ ڪرڻ لاء هڪ مناسب ڊيٽابيس چونڊڻ جو سوال پيدا ٿيو. مان هتي هن چونڊ جي تاريخ بابت ڳالهائڻ چاهيان ٿو.
مسئلو جي ترتيب
سڀ کان اول، هڪ ضروري preface. اسان کي پنهنجي نگراني واري نظام جي ضرورت ڇو آهي ۽ اهو ڪيئن ٺاهيو ويو؟
اسان 2008 ۾ سپورٽ خدمتون مهيا ڪرڻ شروع ڪيو، ۽ 2010 تائين اهو واضح ٿي ويو ته ڪلائنٽ انفراسٽرڪچر ۾ موجود عملن بابت ڊيٽا کي گڏ ڪرڻ ڏکيو ٿي ويو آهي انهن حلن سان جيڪي ان وقت موجود هئا (اسان بابت ڳالهائي رهيا آهيون، خدا مون کي معاف ڪري، ڪيٽي، زيبڪس. ۽ اڀرندڙ گرافائٽ).
اسان جون بنيادي ضرورتون ھيون:
- سپورٽ (ان وقت - درجنين، ۽ مستقبل ۾ - سوين) ڪلائنٽ جي ھڪڙي سسٽم اندر ۽ ساڳئي وقت مرڪزي الرٽ مئنيجمينٽ سسٽم جي موجودگي؛
- الرٽ سسٽم کي منظم ڪرڻ ۾ لچڪ (ڊيوٽي آفيسرن جي وچ ۾ خبردارين جي واڌ، شيڊولنگ، علم جي بنياد)؛
- گہرے تفصيلي گراف جي صلاحيت (Zabbix ان وقت تصويرن جي صورت ۾ پيش ڪيل گراف)؛
- ڊيٽا جي وڏي مقدار جي ڊگهي مدت اسٽوريج (هڪ سال يا وڌيڪ) ۽ جلدي ان کي ٻيهر حاصل ڪرڻ جي صلاحيت.
هن مقالي ۾ اسان کي آخري نقطي ۾ دلچسپي آهي.
اسٽوريج جي ڳالهائيندي، گهربل گهربل هئا:
- سسٽم کي جلدي ڪم ڪرڻ گهرجي؛
- اهو ضروري آهي ته سسٽم جو هڪ SQL انٽرفيس آهي؛
- سسٽم کي مستحڪم هجڻ گهرجي ۽ هڪ فعال صارف جو بنياد ۽ سپورٽ هجڻ گهرجي (هڪ دفعو اسان کي سسٽم جي حمايت ڪرڻ جي ضرورت هئي جهڙوڪ MemcacheDB، جيڪو هاڻي ترقي يافته نه هو، يا MooseFS ورهايل اسٽوريج، جنهن جو بگ ٽريڪر چيني ۾ رکيو ويو هو: اسان هن ڪهاڻي کي ٻيهر ورجائيندا آهيون اسان جي منصوبي لاء نه چاهيو؛
- CAP ٿيوريم جي تعميل: مطابقت (گهربل) - ڊيٽا کي اپڊيٽ ٿيڻ گهرجي، اسان نٿا چاهيون ته الرٽ مئنيجمينٽ سسٽم نئين ڊيٽا حاصل نه ڪري ۽ سڀني منصوبن لاءِ ڊيٽا جي غير آمد بابت خبردارين کي ختم ڪري؛ ورهاڱي جي رواداري (گهربل) - اسان هڪ تقسيم دماغ سسٽم حاصل ڪرڻ نٿا چاهيون؛ دستيابي (نازڪ نه آهي، جيڪڏهن ڪو فعال نقل آهي) - اسان ڪوڊ استعمال ڪندي، حادثي جي صورت ۾ پاڻ کي بيڪ اپ سسٽم ڏانهن تبديل ڪري سگهون ٿا.
عجيب ڳالهه آهي، ان وقت MySQL اسان لاءِ مثالي حل ثابت ٿيو. اسان جي ڊيٽا جو ڍانچو بلڪل سادو هو: سرور id، counter id، timestamp ۽ value؛ گرم ڊيٽا جي تيز نموني کي وڏي بفر پول طرفان يقيني بڻايو ويو، ۽ تاريخي ڊيٽا جي نموني کي SSD پاران يقيني بڻايو ويو.
اهڙيء طرح، اسان حاصل ڪيو تازو ٻن هفتن جي ڊيٽا جو هڪ نمونو، تفصيل سان هڪ سيڪنڊ 200 ms تائين تفصيل سان ڊيٽا مڪمل طور تي پيش ڪرڻ کان اڳ، ۽ هن سسٽم ۾ ڪافي وقت تائين رهندو هو.
ان دوران، وقت گذري ويو ۽ ڊيٽا جو مقدار وڌي ويو. 2016 تائين، ڊيٽا جي مقدار ڏهن ٽيرا بائيٽ تائين پهچي وئي، جيڪا ڪرائي تي ڏنل SSD اسٽوريج جي حوالي سان هڪ اهم خرچ هو.
هن وقت تائين، ڪالمن ڊيٽابيس فعال طور تي وسيع ٿي چڪا هئا، جنهن بابت اسان فعال طور تي سوچڻ شروع ڪيو: ڪالمن ڊيٽابيس ۾، ڊيٽا محفوظ ڪئي وئي آهي، جيئن توهان سمجهي سگهو ٿا، ڪالمن ۾، ۽ جيڪڏهن توهان اسان جي ڊيٽا کي ڏسو، اهو ڏسڻ ۾ آسان آهي ته هڪ وڏو. نقلن جو تعداد جيڪو ڪري سگھي ٿو، جيڪڏھن توھان استعمال ڪريو ڪالمن ڊيٽابيس، ان کي ڪمپريشن استعمال ڪندي.
بهرحال، ڪمپني جو اهم سسٽم مستحڪم طور تي ڪم ڪرڻ جاري رکي، ۽ مان ڪنهن ٻئي کي تبديل ڪرڻ سان تجربو نه ڪرڻ چاهيان ٿو.
2017 ۾، سان جوس ۾ پرڪونا لائيو ڪانفرنس ۾، ڪلڪ هائوس ڊولپرز شايد پهريون ڀيرو پاڻ کي اعلان ڪيو. پهرين نظر ۾، سسٽم پيداوار لاء تيار هو (چڱو، Yandex.Metrica هڪ سخت پيداوار سسٽم آهي)، سپورٽ تيز ۽ سادي هئي، ۽، سڀ کان اهم، آپريشن سادو هو. 2018 کان وٺي، اسان منتقلي جي عمل کي شروع ڪيو آهي. پر ان وقت تائين، ڪافي ”بالغ“ ۽ وقت جي آزمائشي TSDB سسٽم موجود هئا، ۽ اسان ڪافي وقت وقف ڪرڻ جو فيصلو ڪيو ۽ متبادلن جو مقابلو ڪرڻ جو فيصلو ڪيو ته پڪ ڪرڻ لاءِ ته ڪلڪ هاؤس جا ڪي به متبادل حل نه هئا، اسان جي گهرجن مطابق.
اڳ ۾ ئي مخصوص اسٽوريج گهرجن جي اضافي ۾، نوان ظاهر ٿيا آهن:
- نئين سسٽم کي گهٽ ۾ گهٽ ساڳئي ڪارڪردگي مهيا ڪرڻ گهرجي جيئن MySQL هارڊويئر جي ساڳئي مقدار تي؛
- نئين سسٽم جي اسٽوريج کي تمام گھٽ جاء وٺڻ گهرجي؛
- DBMS اڃا تائين منظم ڪرڻ آسان هجڻ گهرجي؛
- مون کي ڊي بي ايم ايس کي تبديل ڪرڻ وقت ايپليڪيشن کي گهٽ ۾ گهٽ تبديل ڪرڻ چاهيندو هو.
اسان ڪهڙي نظام تي غور ڪرڻ شروع ڪيو؟
Apache Hive / Apache Impala
هڪ پراڻو، جنگ جي آزمائشي Hadoop اسٽيڪ. لازمي طور تي، اهو هڪ SQL انٽرفيس آهي جيڪو HDFS تي اصلي فارميٽ ۾ ڊيٽا کي محفوظ ڪرڻ جي چوٽي تي ٺهيل آهي.
پرو.
- مستحڪم آپريشن سان، ڊيٽا کي ماپڻ تمام آسان آهي.
- ڊيٽا اسٽوريج لاء ڪالم حل آهن (گهٽ جاء).
- متوازي ڪمن جي تمام تيز عملدرآمد جڏهن وسيلا موجود آهن.
ڪن
- اهو Hadoop آهي، ۽ اهو استعمال ڪرڻ ڏکيو آهي. جيڪڏهن اسان ڪلائوڊ ۾ تيار ٿيل حل وٺڻ لاءِ تيار نه آهيون (۽ اسان قيمت جي لحاظ کان تيار نه آهيون)، سڄي اسٽيڪ کي گڏ ڪرڻو پوندو ۽ منتظمين جي هٿن سان سهڪار ڪيو ويندو، ۽ اسان واقعي نٿا چاهيون. هي.
- ڊيٽا گڏ ڪئي وئي آهي .
پر:
رفتار ڪمپيوٽنگ سرورز جي تعداد کي اسڪيل ڪندي حاصل ڪئي ويندي آهي. آسان لفظ ۾، جيڪڏهن اسان هڪ وڏي ڪمپني آهيون، تجزياتي ۾ مصروف آهيون، ۽ اهو ڪاروبار لاء ضروري آهي ته معلومات کي جلدي ممڪن طور تي گڏ ڪري (جيتوڻيڪ وڏي مقدار ۾ ڪمپيوٽنگ وسيلن کي استعمال ڪرڻ جي قيمت تي)، اهو اسان جي پسند ٿي سگهي ٿو. پر اسان ڪمن کي تيز ڪرڻ لاءِ هارڊويئر فليٽ کي وڌائڻ لاءِ تيار نه هئاسين.
ڊروڊ / پينٽ
خاص طور تي TSDB بابت گهڻو ڪجهه آهي، پر ٻيهر، هدوپ اسٽيڪ.
ڪري سگهو ٿا .
ٿورن لفظن ۾: Druid/Pinot صورتن ۾ ڪلڪ هائوس کان بهتر نظر اچن ٿا جتي:
- توهان وٽ ڊيٽا جي هڪ متضاد نوعيت آهي (اسان جي صورت ۾، اسان صرف سرور جي ميٽرڪ جي ٽائيم سيريز کي رڪارڊ ڪريون ٿا، ۽ حقيقت ۾، هي هڪ ٽيبل آهي. پر ٻيا ڪيس ٿي سگهن ٿا: سامان جي وقت سيريز، اقتصادي وقت سيريز، وغيره - هر هڪ سان. ان جي پنهنجي جوڙجڪ، جنهن کي گڏ ڪرڻ ۽ پروسيس ڪرڻ جي ضرورت آهي).
- ان کان سواء، هن ڊيٽا جو تمام گهڻو آهي.
- جدول ۽ ڊيٽا ٽائم سيريز سان گڏ ظاهر ۽ غائب ٿي وڃن ٿا (يعني ڊيٽا جو ڪجهه سيٽ آيو، تجزيو ڪيو ويو ۽ ختم ڪيو ويو).
- ڪو به واضح معيار نه آهي جنهن جي ذريعي ڊيٽا کي ورهاڱي ڪري سگهجي ٿو.
مخالف حالتن ۾، ClickHouse بهتر ڪارڪردگي ڏيکاري ٿو، ۽ اهو اسان جو معاملو آهي.
ڪلڪ ڪريو هائوس
- SQL جهڙو
- منظم ڪرڻ آسان.
- ماڻهو چون ٿا ته اهو ڪم ڪري ٿو.
ٽيسٽ لاءِ شارٽ لسٽ ڪيو وڃي ٿو.
InfluxDB
ClickHouse لاء هڪ پرڏيهي متبادل. مائنس مان: اعلي دستيابي صرف تجارتي ورزن ۾ موجود آهي، پر ان جي مقابلي ڪرڻ جي ضرورت آهي.
ٽيسٽ لاءِ شارٽ لسٽ ڪيو وڃي ٿو.
Cassandra
هڪ طرف، اسان ڄاڻون ٿا ته اهو استعمال ڪيو ويندو آهي ميٽرڪ ٽائمريز کي ذخيرو ڪرڻ لاءِ اهڙين نگراني سسٽم ذريعي، مثال طور، يا OkMeter. بهرحال، اتي خاصيتون آهن.
Cassandra روايتي معنى ۾ هڪ ڪالمن ڊيٽابيس نه آهي. اهو هڪ قطار جي ڏيک وانگر وڌيڪ ڏسڻ ۾ اچي ٿو، پر هر لڪير ۾ ڪالمن جو هڪ مختلف نمبر ٿي سگهي ٿو، اهو آسان بڻائي ٿو ته هڪ ڪالمن واري ڏيک کي ترتيب ڏيڻ. انهي لحاظ کان، اهو واضح آهي ته 2 بلين ڪالمن جي حد سان، اهو ممڪن آهي ته ڪجهه ڊيٽا کي ڪالمن ۾ محفوظ ڪرڻ (۽ ساڳئي وقت سيريز). مثال طور، MySQL ۾ 4096 ڪالمن جي حد آهي ۽ اهو آسان آهي ته ڪوڊ 1117 سان ڪنهن غلطي تي ٿڪجي پوي جيڪڏهن توهان ساڳيو ڪم ڪرڻ جي ڪوشش ڪريو.
Cassandra انجڻ هڪ ماسٽر کان سواء ورهايل سسٽم ۾ ڊيٽا جي وڏي مقدار کي ذخيرو ڪرڻ تي مرکوز آهي، ۽ مٿي ڄاڻايل Cassandra CAP ٿيوريم AP بابت وڌيڪ آهي، اهو آهي، ڊيٽا جي دستيابي ۽ ورهاڱي جي مزاحمت بابت. ان ڪري، هي اوزار تمام سٺو ٿي سگهي ٿو جيڪڏهن توهان کي صرف هن ڊيٽابيس تي لکڻ جي ضرورت آهي ۽ گهٽ ۾ گهٽ ان مان پڙهي. ۽ هتي اهو منطقي آهي ته Cassandra کي "ٿڌي" اسٽوريج طور استعمال ڪيو وڃي. اھو آھي، ھڪڙي ڊگھي مدت، قابل اعتماد جڳھ جي طور تي تاريخي ڊيٽا جي وڏي مقدار کي ذخيرو ڪرڻ لاء، جيڪا تمام گھٽ ضرورت آھي، پر جيڪڏھن ضروري ھجي ته حاصل ڪري سگھجي ٿو. تنهن هوندي به، پوريء طرح جي لاء، اسان کي به ان جي جاچ ڪنداسين. پر، جيئن مون اڳ ۾ چيو، چونڊيل ڊيٽابيس حل لاءِ ڪوڊ کي فعال طور تي ٻيهر لکڻ جي ڪا به خواهش نه آهي، تنهن ڪري اسان ان کي ڪجهه حد تائين آزمائينداسين - بغير ڊيٽابيس جي جوڙجڪ کي ڪئاسندرا جي خاصيتن جي مطابق.
Prometheus
خير، تجسس کان ٻاهر، اسان Prometheus اسٽوريج جي ڪارڪردگي کي جانچڻ جو فيصلو ڪيو - صرف اهو سمجهڻ لاء ته ڇا اسان موجوده حلن کان تيز يا سست آهيون ۽ ڪيترو.
جاچ جا طريقا ۽ نتيجا
تنهن ڪري، اسان 5 ڊيٽابيسس کي هيٺين 6 ترتيبن ۾ آزمايو: ClickHouse (1 node)، ClickHouse (3 نوڊس لاءِ ورهايل ٽيبل)، InfluxDB، Mysql 8، Cassandra (3 nodes) ۽ Prometheus. امتحان جو منصوبو هن ريت آهي:
- هڪ هفتي لاءِ تاريخي ڊيٽا اپلوڊ ڪريو (840 ملين قيمتون في ڏينهن؛ 208 هزار ميٽرڪ)؛
- اسان هڪ رڪارڊنگ لوڊ ٺاهيندا آهيون (6 لوڊ طريقن تي غور ڪيو ويو، هيٺ ڏسو)؛
- رڪارڊنگ سان گڏوگڏ، اسان وقتي طور تي چونڊون ڪندا آهيون، چارٽ سان ڪم ڪندڙ صارف جي درخواستن کي نقل ڪندي. شين کي تمام گهڻو پيچيدگي نه ڪرڻ لاءِ، اسان هڪ هفتي لاءِ 10 ميٽرڪ لاءِ ڊيٽا چونڊيو (جيڪو بلڪل سي پي يو گراف تي آهي).
اسان پنهنجي مانيٽرنگ ايجنٽ جي رويي کي نقل ڪندي لوڊ ڪريون ٿا، جيڪو هر 15 سيڪنڊن ۾ هڪ ڀيرو هر ميٽرڪ ڏانهن قدر موڪلي ٿو. ساڳئي وقت، اسان کي مختلف ڪرڻ ۾ دلچسپي آهي:
- ميٽرڪ جو ڪل تعداد جنهن ۾ ڊيٽا لکيل آهي؛
- هڪ ميٽرڪ تائين قدر موڪلڻ لاء وقفو؛
- بيچ جي ماپ.
بيچ جي سائيز جي باري ۾. جيئن ته اسان جي تقريبن سڀني تجرباتي ڊيٽابيس کي اڪيلو داخل ڪرڻ سان لوڊ ڪرڻ جي سفارش نه ڪئي وئي آهي، اسان کي هڪ رلي جي ضرورت پوندي جيڪا ايندڙ ميٽرڪ گڏ ڪري ۽ انهن کي گروپن ۾ گروپ ڪري ۽ انهن کي ڊيٽابيس ۾ بيچ داخل ڪرڻ جي طور تي لکي.
انهي سان گڏ، بهتر سمجهڻ لاءِ ته پوءِ حاصل ڪيل ڊيٽا کي ڪيئن تشريح ڪجي، اچو ته تصور ڪريون ته اسان صرف ميٽرڪ جو هڪ گروپ نه موڪلي رهيا آهيون، پر ميٽرڪس سرورز ۾ ترتيب ڏنل آهن - 125 ميٽرڪس في سرور. هتي سرور صرف هڪ مجازي ادارو آهي - صرف انهي کي سمجهڻ لاء، مثال طور، 10000 ميٽرڪس تقريبا 80 سرورز سان ملن ٿا.
۽ هتي، هي سڀ ڪجهه حساب ۾ رکندي، اسان جا 6 ڊيٽابيس لکڻ جا طريقا آهن:
هتي ٻه نقطا آهن. پهرين ڳالهه ته، ڪئاسنڊرا لاءِ اهي بيچ سائيز تمام وڏا هئا، اتي اسان 50 يا 100 جي قدر استعمال ڪندا هئاسين. ۽ ٻيو، ڇاڪاڻ ته پروميٿيوس سختي سان پل موڊ ۾ ڪم ڪري ٿو، يعني. اهو پاڻ وڃي ٿو ۽ ميٽرڪ ذريعن کان ڊيٽا گڏ ڪري ٿو (۽ جيتوڻيڪ pushgateway، نالي جي باوجود، بنيادي طور تي صورتحال کي تبديل نٿو ڪري)، لاڳاپيل لوڊ جامد ترتيبن جي ميلاپ کي استعمال ڪندي لاڳو ڪيا ويا.
امتحان جا نتيجا هن ريت آهن:
ڇا قابل ذڪر آهي: پروميٿيوس کان شاندار طور تي تيز نمونا، ڪئاسندرا کان انتهائي سست نموني، InfluxDB کان ناقابل قبول سست نموني؛ رڪارڊنگ جي رفتار جي لحاظ کان، ڪلڪ هائوس سڀني کي فتح ڪيو، ۽ پروميٿيوس مقابلي ۾ حصو نه وٺندو آهي، ڇاڪاڻ ته اهو پنهنجو پاڻ کي داخل ڪري ٿو ۽ اسان ڪجھ به ماپ نه ڪندا آهيون.
آخر ۾: ClickHouse ۽ InfluxDB پاڻ کي بھترين طور ڏيکاريو، پر Influx مان ھڪڙو ڪلستر صرف انٽرپرائز ورزن جي بنياد تي ٺاھي سگھجي ٿو، جنھن تي پئسا خرچ ٿين ٿا، جڏھن ته ClickHouse جي قيمت ڪجھ به نه آھي ۽ روس ۾ ٺاھيو ويو آھي. اهو منطقي آهي ته آمريڪا ۾ انتخاب شايد انفلوڪس ڊي بي جي حق ۾ آهي، ۽ اسان جي ملڪ ۾ اهو ڪلڪ هائوس جي حق ۾ آهي.
جو ذريعو: www.habr.com