څنګه موږ د ډیری وخت لړۍ ډیټابیسونه ازمویل

په تیرو څو کلونو کې، د وخت لړۍ ډیټابیسونه د یو غیر معمولي شی څخه بدل شوي (ډیر تخصص چې یا په خلاص څارنې سیسټمونو کې کارول کیږي (او د ځانګړو حلونو سره تړل شوي) یا د لوی ډیټا پروژو کې) په "مصرف محصول" بدل شوي. د روسیې د فدراسیون په خاوره کې، د Yandex او ClickHouse څخه ځانګړې مننه باید ورکړل شي. تر دې وخته پورې، که تاسو د وخت لړۍ ډیټا لوی مقدار ذخیره کولو ته اړتیا لرئ، تاسو باید د یو لوی هډوپ سټیک جوړولو او ساتلو اړتیا ته اړتیا ولرئ، یا د هر سیسټم لپاره انفرادي پروتوکولونو سره اړیکه ونیسئ.

داسې بریښي چې په 2019 کې یوه مقاله چې د TSDB په اړه یې د کارولو ارزښت لري یوازې یوه جمله ولري: "یوازې د کلیک هاؤس وکاروئ." مګر ... باریکي شتون لري.

په حقیقت کې، ClickHouse په فعاله توګه وده کوي، د کاروونکي اساس وده کوي، او ملاتړ خورا فعال دی، مګر ایا موږ د ClickHouse عامه بریالیتوب ته یرغمل شوي یو، کوم چې نور، شاید ډیر اغیزمن / معتبر حلونه یې تر سیوري لاندې کړي؟

د تیر کال په پیل کې، موږ د خپل څارنې سیسټم بیا کار پیل کړ، چې په ترڅ کې یې د معلوماتو ذخیره کولو لپاره د مناسب ډیټابیس غوره کولو پوښتنه راپورته شوه. زه غواړم دلته د دې انتخاب د تاریخ په اړه خبرې وکړم.

د ستونزې تشکیل

تر ټولو لومړی، یو اړین وړاندیز. موږ ولې خپل د څارنې سیسټم ته اړتیا لرو او دا څنګه ډیزاین شوی؟

موږ په 2008 کې د ملاتړ خدماتو چمتو کول پیل کړل، او په 2010 کې دا څرګنده شوه چې د پیرودونکي زیربنا کې د هغه پروسو په اړه د معلوماتو راټولول ستونزمن شوي چې په هغه وخت کې شتون درلود (موږ په دې اړه خبرې کوو، خدای ما معاف کړي، کیکټي، زیبکس او راپورته کیدونکی ګرافائٹ).

زموږ اساسي غوښتنې وې:

• په یو سیسټم کې د پیرودونکو ملاتړ (په هغه وخت کې - لسګونه، او په راتلونکي کې - په سلګونو) او په ورته وخت کې د مرکزي خبرتیا مدیریت سیسټم شتون؛
• د خبرتیا سیسټم اداره کولو کې انعطاف (د دندو افسرانو ترمینځ د خبرتیاو زیاتوالی ، مهالویش ، د پوهې اساس)؛
• د ژورې توضیحي ګرافونو وړتیا (زابکس په هغه وخت کې ګرافونه د عکسونو په بڼه وړاندې کړل)؛
• د ډیټا لوی مقدار (یو کال یا ډیر) اوږدمهاله ذخیره کول او د ګړندي ترلاسه کولو وړتیا.

پدې مقاله کې موږ په وروستي ټکي کې علاقه لرو.

د ذخیره کولو په اړه خبرې کول، اړتیاوې په لاندې ډول وې:

• سیسټم باید په چټکۍ سره کار وکړي؛
• دا د پام وړ ده چې سیسټم د SQL انٹرفیس ولري؛
• سیسټم باید باثباته وي او د فعال کارونکي اساس او ملاتړ ولري (یوځل چې موږ د سیسټمونو ملاتړ کولو اړتیا سره مخ شو لکه MemcacheDB، ​​کوم چې نور نه دی رامینځته شوی، یا د MooseFS توزیع شوی ذخیره، د بګ ټریکر چې په چینایي کې ساتل شوی و: موږ دا کیسه د دې لپاره تکرار کړه چې زموږ پروژه یې نه غوښتل؛
• د CAP تیورم سره موافقت: مطابقت (اړین) - ډاټا باید تازه وي، موږ نه غواړو چې د خبرتیا مدیریت سیسټم نوي معلومات ترلاسه نکړي او د ټولو پروژو لپاره د معلوماتو د نه رسیدلو په اړه خبرتیاوې سپکې کړي؛ د تقسیم زغم (اړین) - موږ نه غواړو د سپلیټ دماغ سیسټم ترلاسه کړو؛ شتون (مهم نه دی، که چیرې فعال نقل شتون ولري) - موږ کولی شو د کوډ په کارولو سره د حادثې په صورت کې پخپله د بیک اپ سیسټم ته لاړ شو.

په عجیبه توګه، په هغه وخت کې MySQL زموږ لپاره غوره حل وګرځید. زموږ د معلوماتو جوړښت خورا ساده و: د سرور ID، کاونټر ID، مهال ویش او ارزښت؛ د ګرمو معلوماتو ګړندي نمونه کول د لوی بفر پول لخوا تضمین شوي ، او د تاریخي معلوماتو نمونه کول د SSD لخوا تضمین شوي.

په دې توګه، موږ د تازه دوه اونیو ډیټا نمونه ترلاسه کړه، مخکې له دې چې ډاټا په بشپړه توګه وړاندې شي، د دویم 200 ms په تفصیل سره، او په دې سیسټم کې د اوږدې مودې لپاره ژوند کاوه.

په عین وخت کې، وخت تیر شو او د معلوماتو اندازه زیاته شوه. په 2016 کې، د معلوماتو حجم لسګونو ټیرابایټ ته ورسید، کوم چې د کرایه شوي SSD ذخیره کولو په شرایطو کې د پام وړ لګښت و.

پدې وخت کې ، د کالم ډیټابیسونه په فعاله توګه پراخه شوي ، کوم چې موږ په فعاله توګه په اړه فکر کول پیل کړل: په کالم ډیټابیسونو کې ، ډیټا ذخیره کیږي ، لکه څنګه چې تاسو پوهیږئ ، په کالمونو کې ، او که تاسو زموږ ډیټا ته ګورئ نو د لوی لید لیدل اسانه دي. د نقلونو شمیر چې کولی شي، که تاسو د کالمر ډیټابیس کاروئ، د کمپریشن په کارولو سره یې فشار کړئ.

په هرصورت، د شرکت کلیدي سیسټم په ثابت ډول کار کولو ته دوام ورکړ، او زه نه غواړم چې بل څه ته د بدلولو تجربه وکړم.

په 2017 کې، په سان جوز کې د پرکونا ژوندی کنفرانس کې، د کلک هاؤس پراختیا کونکو شاید د لومړي ځل لپاره ځان اعلان کړ. په لومړي نظر کې، سیسټم د تولید لپاره چمتو و (ښه، Yandex.Metrica یو سخت تولید سیسټم دی)، ملاتړ ګړندی او ساده و، او تر ټولو مهم، عملیات ساده وو. د 2018 راهیسې، موږ د لیږد بهیر پیل کړی دی. مګر په هغه وخت کې، ډیری "بالغ" او د وخت ازمول شوي TSDB سیسټمونه شتون درلود، او موږ پریکړه وکړه چې د پام وړ وخت وقف کړو او بدیلونه پرتله کړو ترڅو ډاډ ترلاسه کړو چې زموږ د اړتیاو سره سم د Clickhouse لپاره بدیل حلونه شتون نلري.

د دمخه ټاکل شوي ذخیره کولو اړتیاو سربیره ، نوي څرګند شوي:

• نوی سیسټم باید لږترلږه د مای ایس کیو ایل په ورته هارډویر کې ورته فعالیت چمتو کړي؛
• د نوي سیسټم ذخیره باید د پام وړ لږ ځای ونیسي؛
• DBMS باید لاهم اداره کول اسانه وي؛
• ما غوښتل غوښتنلیک لږ تر لږه بدل کړم کله چې د DBMS بدلول.

کوم سیسټمونه مو په پام کې نیول پیل کړل؟

Apache Hive/Apache Impala
یو زوړ، د جګړې ازمول شوی هډوپ سټیک. په لازمي ډول ، دا یو SQL انٹرفیس دی چې په HDFS کې په اصلي فارمیټونو کې د معلوماتو ذخیره کولو په سر کې جوړ شوی.

پرو.

• د مستحکم عملیاتو سره، د معلوماتو اندازه کول خورا اسانه دي.
• د معلوماتو ذخیره کولو لپاره د کالم حلونه شتون لري (لږ ځای).
• د موازي کارونو خورا ګړندي اجرا کول کله چې سرچینې شتون ولري.

د

• دا هډوپ دی، او کارول یې ستونزمن دي. که موږ په بادل کې د چمتو شوي حل اخیستو لپاره چمتو نه یو (او موږ د لګښت له مخې چمتو نه یو) ، ټول سټیک باید د مدیرانو لاسونو لخوا راټول او ملاتړ یې وشي ، او موږ واقعیا نه غواړو. دا.
• معلومات راټول شوي دي واقعیا ګړندی.

په هرصورت:

سرعت د کمپیوټري سرورونو شمیر په اندازه کولو سره ترلاسه کیږي. په ساده ډول، که موږ یو لوی شرکت یو، په تحلیلونو کې بوخت یو، او دا د سوداګرۍ لپاره خورا مهم دی چې معلومات ژر تر ژره راټول کړي (حتی د ډیرو کمپیوټري سرچینو کارولو په لګښت)، دا ممکن زموږ انتخاب وي. مګر موږ چمتو نه وو چې د کارونو ګړندي کولو لپاره د هارډویر بیړۍ ضرب کړو.

Druid/Pinot

په ځانګړي ډول د TSDB په اړه ډیر څه شتون لري ، مګر بیا ، د هډوپ سټیک.

موجود دي د کلک هاؤس په مقابل کې د ډرویډ او پینټ ګټې او زیانونو پرتله کولو عالي مقاله .

په یو څو کلمو کې: ډرایډ/پینوټ د کلک هاؤس څخه په هغه قضیو کې غوره ښکاري چیرې چې:

• تاسو د ډیټا متفاوت طبیعت لرئ (زموږ په قضیه کې، موږ یوازې د سرور میټریکونو وختونه ثبت کوو، او په حقیقت کې دا یو جدول دی. مګر ممکن نورې قضیې وي: د تجهیزاتو وخت لړۍ، د اقتصادي وخت لړۍ، او داسې نور - هر یو سره. خپل جوړښت، کوم چې باید راټول او پروسس شي).
• برسېره پر دې، د دې معلوماتو ډیری برخه شتون لري.
• جدولونه او ډیټا د وخت لړۍ سره څرګندیږي او ورک کیږي (دا د ډیټا ځینې سیټ ته رسیدلي ، تحلیل شوي او حذف شوي).
• هیڅ روښانه معیار شتون نلري چې له مخې یې ډاټا ویشل کیدی شي.

په مخالفو قضیو کې، ClickHouse ښه فعالیت کوي، او دا زموږ قضیه ده.

ټک هاوس

• د SQL په څیر
• د اداره کولو لپاره اسانه.
• خلک وايي چې دا کار کوي.

د ازموینې لپاره شارټ لیست کیږي.

InfluxDB

د ClickHouse لپاره یو بهرنی بدیل. د نیمګړتیاوو څخه: لوړ شتون یوازې په سوداګریز نسخه کې شتون لري، مګر دا باید پرتله شي.

د ازموینې لپاره شارټ لیست کیږي.

Cassandra

له یوې خوا، موږ پوهیږو چې دا د داسې څارنې سیسټمونو لخوا د میټریک وختونو ذخیره کولو لپاره کارول کیږي لکه د بیلګې په توګه، SignalFX یا OkMeter. په هرصورت، ځانګړتیاوې شتون لري.

کیسینډرا په دودیز معنی کې د کالم ډیټابیس ندی. دا د قطار لید په څیر ښکاري، مګر هره کرښه کولی شي د کالمونو مختلف شمیر ولري، د کالم لید تنظیم کول اسانه کوي. په دې معنی، دا روښانه ده چې د 2 ملیارد کالمونو محدودیت سره، دا ممکنه ده چې ځینې معلومات په کالمونو کې ذخیره کړئ (او د ورته وخت لړۍ). د مثال په توګه، په MySQL کې د 4096 کالمونو حد شتون لري او د کوډ 1117 سره د یوې تېروتنې مخه نیول اسانه دي که تاسو د ورته کولو هڅه وکړئ.

د کیسینډرا انجن د ماسټر پرته په توزیع شوي سیسټم کې د ډیټا لوی مقدار ذخیره کولو باندې تمرکز کوي ، او پورته ذکر شوي د Cassandra CAP تیورم د AP په اړه خورا ډیر دی ، دا د ډیټا شتون او د تقسیم کولو مقاومت په اړه دی. پدې توګه ، دا وسیله خورا ښه کیدی شي که تاسو یوازې دې ډیټابیس ته لیکلو ته اړتیا لرئ او په ندرت سره له دې څخه ولولئ. او دلته دا منطقی دی چې کیسیندرا د "سړې" ذخیره په توګه وکاروئ. دا، د اوږدې مودې، د باور وړ ځای په توګه د تاریخي معلوماتو لوی مقدار ذخیره کولو لپاره چې په ندرت سره ورته اړتیا لیدل کیږي، مګر د اړتیا په صورت کې بیرته اخیستل کیدی شي. په هرصورت، د بشپړتیا لپاره، موږ به یې هم ازموینه وکړو. مګر، لکه څنګه چې ما مخکې وویل، د ټاکل شوي ډیټابیس حل لپاره د کوډ په فعاله توګه بیا لیکلو لپاره هیڅ لیوالتیا نشته، نو موږ به دا یو څه محدود ازموینه وکړو - پرته له دې چې د ډیټابیس جوړښت د کاسندرا ځانګړتیاوو ته تطبیق کړو.

Prometheus

ښه، د تجسس څخه بهر، موږ پریکړه وکړه چې د Prometheus ذخیره کولو فعالیت ازموینه وکړو - یوازې د دې پوهیدلو لپاره چې ایا موږ د اوسني حلونو په پرتله ګړندي یا ورو یو او څومره.

د ازموینې میتودولوژي او پایلې

نو ، موږ په لاندې 5 تشکیلاتو کې 6 ډیټابیسونه ازمویل: کلیک هاؤس (1 نوډ) ، کلیک هاوس (د 3 نوډونو لپاره توزیع شوی جدول) ، انفلوکس ډی بی ، مای ایس کیو ایل 8 ، کاسندرا (3 نوډونه) او پرومیتیس. د ازموینې پلان په لاندې ډول دی:

1. د یوې اونۍ لپاره تاریخي ډاټا اپلوډ کړئ (هره ورځ 840 ملیون ارزښتونه؛ 208 زره میټریکونه)؛
2. موږ د ثبت کولو بار تولید کوو (6 بار موډونه په پام کې نیول شوي، لاندې وګورئ)؛
3. د ثبت کولو سره موازي کې، موږ وخت په وخت انتخابونه کوو، د کارونکي غوښتنې تقلید چې د چارټونو سره کار کوي. د دې لپاره چې شیان ډیر پیچلي نه کړي، موږ د یوې اونۍ لپاره د 10 میټریکونو لپاره ډاټا غوره کړه (دا په حقیقت کې د CPU ګراف کې څومره شتون لري).

موږ د خپل څارونکي اجنټ چلند تقلید کولو سره بار کوو ، کوم چې په هر 15 ثانیو کې یو ځل هر میټریک ته ارزښتونه لیږي. په ورته وخت کې، موږ د توپیر سره علاقه لرو:

• د میټریکونو مجموعه چې په کې ډاټا لیکل کیږي؛
• یو میټریک ته د ارزښتونو لیږلو لپاره وقفه؛
• د بست اندازه.

د بستې اندازې په اړه. څرنګه چې دا سپارښتنه نه کیږي چې زموږ نږدې ټول تجربه لرونکي ډیټابیسونه د واحد داخلونو سره پورته کړئ، موږ به یو ریل ته اړتیا ولرو چې راتلونکی میټریکونه راټول کړي او په ګروپونو کې یې ګروپ کړي او ډیټابیس ته یې د بیچ داخلولو په توګه ولیکي.

همدارنګه، د ښه پوهیدو لپاره چې څنګه ترلاسه شوي ډاټا تشریح کړئ، راځئ چې تصور وکړو چې موږ یوازې د میټریکونو یوه ډله نه لیږو، مګر میټریکونه په سرورونو کې تنظیم شوي - په هر سرور کې 125 میټریکونه. دلته سرور په ساده ډول یو مجازی وجود دی - یوازې د دې پوهیدلو لپاره، د بیلګې په توګه، 10000 میټریکونه د 80 سرورونو سره مطابقت لري.

او دلته، دا ټول په پام کې نیولو سره، زموږ د 6 ډیټابیس لیکلو طریقې دي:

دلته دوه ټکي شتون لري. لومړی، د کاسندرا لپاره د دې بستې اندازې خورا لوی و، هلته موږ د 50 یا 100 ارزښتونو څخه کار اخلو. او دوهم، ځکه چې پرومیټیوس په کلکه په پل موډ کې کار کوي، د بیلګې په توګه. دا پخپله ځي او د میټریک سرچینو څخه ډاټا راټولوي (او حتی pushgateway، د نوم سره سره، په بنسټیز ډول وضعیت نه بدلوي)، اړونده بارونه د جامد تشکیلاتو د ترکیب په کارولو سره پلي شوي.

د ازموینې پایلې په لاندې ډول دي:

هغه څه چې د پام وړ دي: د پرومیتیوس څخه په زړه پوري ګړندي نمونې ، د کاسندرا څخه خورا ورو ورو نمونې ، د انفلوکس ډی بی څخه د نه منلو وړ ورو نمونې؛ د ثبت کولو سرعت په شرایطو کې ، کلیک هاوس هرڅوک وګټل ، او پرومیټیوس په سیالۍ کې برخه نه اخلي ، ځکه چې دا پخپله داخل کوي او موږ هیڅ اندازه نه کوو.

په پایله کې،: ClickHouse او InfluxDB غوره ترسره کړي، مګر د انفلوکس څخه کلستر یوازې د تصدۍ نسخې پراساس جوړ کیدی شي، کوم چې پیسې لګوي، پداسې حال کې چې کلیک هاوس هیڅ لګښت نلري او په روسیه کې جوړ شوی. دا منطقي ده چې په متحده ایالاتو کې انتخاب شاید د InfluxDB په ګټه وي، او زموږ په هیواد کې دا د ClickHouse په ګټه دی.

سرچینه: www.habr.com