د دې حقیقت سره سره چې اوس نږدې هرچیرې ډیری ډیټا شتون لري ، تحلیلي ډیټابیسونه لاهم خورا بهرني دي. دوی کمزوري پیژندل شوي او حتی د دې وړتیا لري چې په اغیزمنه توګه وکاروي. ډیری د MySQL یا PostgreSQL سره "کیکټس خوري" ته دوام ورکوي، کوم چې د نورو سناریوګانو لپاره ډیزاین شوي، د NoSQL سره مخ دي، یا د سوداګریزو حلونو لپاره ډیر تادیه کوي. ClickHouse د لوبې قواعد بدلوي او د تحلیلي DBMS نړۍ ته د ننوتلو لپاره د پام وړ حد کموي.
د BackEnd Conf 2018 څخه راپور او دا د سپیکر په اجازه خپریږي.
زه څوک یم او ولې زه د ClickHouse په اړه خبرې کوم؟ زه په LifeStreet کې د پراختیا رییس یم، کوم چې ClickHouse کاروي. همدارنګه، زه د Altinity بنسټ ایښودونکی یم. دا د Yandex شریک دی چې ClickHouse ته وده ورکوي او د Yandex سره مرسته کوي چې ClickHouse ډیر بریالي کړي. د ClickHouse په اړه د پوهې شریکولو لپاره هم چمتو دی.
او زه د پیټیا زیتسیف ورور نه یم. زما څخه ډیری وختونه د دې په اړه پوښتنه کیږي. نه، موږ وروڼه نه یو.
"هرڅوک پوهیږي" چې ClickHouse:
- ډیر چټک،
- ډیر راحته
- په Yandex کې کارول کیږي.
یو څه لږ پوهیږي چې په کوم شرکتونو کې او څنګه کارول کیږي.
زه به تاسو ته ووایم چې ولې، چیرته او څنګه ClickHouse کارول کیږي، پرته له Yandex څخه.
زه به تاسو ته ووایم چې په بیلابیلو شرکتونو کې د ClickHouse په مرسته ځانګړي دندې څنګه حل کیږي، تاسو د خپلو دندو لپاره د ClickHouse کوم اوزار کارولی شئ، او په مختلفو شرکتونو کې څنګه کارول شوي.
ما درې مثالونه غوره کړل چې د مختلف زاویو څخه ClickHouse ښیې. زه فکر کوم چې دا به په زړه پورې وي.
لومړۍ پوښتنه دا ده: "ولې موږ ClickHouse ته اړتیا لرو؟". داسې ښکاري چې دا یوه روښانه پوښتنه ده، مګر د دې لپاره له یو څخه زیات ځوابونه شتون لري.
- لومړی ځواب د فعالیت لپاره دی. کلیک هاوس خورا ګړندی دی. په ClickHouse کې تحلیلونه هم خورا ګړندي دي. دا ډیری وختونه کارول کیدی شي چیرې چې بل څه خورا ورو یا خورا خراب وي.
- دوهم ځواب لګښت دی. او له هرڅه دمخه ، د پیمانه کولو لګښت. د مثال په توګه، Vertica یو خورا ښه ډیټابیس دی. دا خورا ښه کار کوي که تاسو ډیری ټرابایټ ډیټا نلرئ. مګر کله چې دا په سلګونو ټیرابایټ یا پیټابایټ ته راځي ، د جواز او ملاتړ لګښت خورا مهم مقدار ته ځي. او دا ګرانه ده. او ClickHouse وړیا دی.
- دریم ځواب عملیاتي لګښت دی. دا یو څه مختلف طریقه ده. ریډ شفټ یو عالي انلاګ دی. په RedShift کې، تاسو کولی شئ په چټکۍ سره پریکړه وکړئ. دا به ښه کار وکړي، مګر په ورته وخت کې، هر ساعت، هره ورځ، او هره میاشت، تاسو به ایمیزون ته ډیره ګرانه پیسې ورکړئ، ځکه چې دا د پام وړ ګران خدمت دی. ګوګل BigQuery هم. که څوک دا کاروي، نو هغه پوهیږي چې تاسو کولی شئ ډیری غوښتنې پرمخ بوځي او په ناڅاپي توګه د سلګونو ډالرو لپاره بیل ترلاسه کړئ.
ClickHouse دا ستونزې نه لري.
ClickHouse اوس چیرته کارول کیږي؟ د Yandex سربیره، ClickHouse د مختلفو سوداګرۍ او شرکتونو په ډله کې کارول کیږي.
- تر ټولو لومړی، دا د ویب غوښتنلیک تحلیل دی، د بیلګې په توګه دا د کارونې قضیه ده چې د Yandex څخه راغلی.
- ډیری AdTech شرکتونه ClickHouse کاروي.
- ډیری شرکتونه چې اړتیا لري د مختلف سرچینو څخه د راکړې ورکړې لاګونه تحلیل کړي.
- ډیری شرکتونه د امنیت لاګونو څارلو لپاره ClickHouse کاروي. دوی دوی کلیک هاوس ته اپلوډ کوي، راپورونه جوړوي، او هغه پایلې ترلاسه کوي چې دوی ورته اړتیا لري.
- شرکتونه په مالي تحلیل کې د دې کارولو پیل کوي، د بیلګې په توګه په تدریجي ډول لوی کاروبارونه هم کلیک هاوس ته نږدې کیږي.
- بادل که څوک ClickHouse تعقیب کړي، نو شاید دوی د دې شرکت نوم اوریدلی وي. دا د ټولنې یو له اړینو مرسته کونکو څخه دی. او دوی خورا جدي کلیک هاوس نصب لري. د مثال په توګه، دوی د کلک هاؤس لپاره کافکا انجن جوړ کړ.
- مخابراتي شرکتونو کارول پیل کړل. ډیری شرکتونه ClickHouse یا د مفهوم ثبوت یا دمخه په تولید کې کاروي.
- یو شرکت د تولید پروسې څارلو لپاره کلیک هاوس کاروي. دوی د مایکرو سرکیټونو ازموینه کوي، د پیرامیټونو یوه ډله لیکي، شاوخوا 2 ځانګړتیاوې لري. او بیا دوی تحلیل کوي چې ایا لوبه ښه ده یا بد.
- د بلاکچین تحلیلونه. د Bloxy.info په څیر یو روسی شرکت شتون لري. دا د ایتیروم شبکې تحلیل دی. دوی دا په ClickHouse کې هم وکړل.
او اندازه مهمه نده. ډیری شرکتونه شتون لري چې یو کوچنی سرور کاروي. او دوی ته اجازه ورکوي چې خپلې ستونزې حل کړي. او حتی ډیر شرکتونه د ډیری سرورونو یا لسګونو سرورونو لوی کلسترونه کاروي.
او که تاسو ریکارډونو ته وګورئ، نو بیا:
- Yandex: 500+ سرورونه، دوی هلته هره ورځ 25 ملیارد ریکارډونه ذخیره کوي.
- LifeStreet: 60 سرورونه، هره ورځ نږدې 75 ملیارد ریکارډونه. دلته لږ سرورونه شتون لري، د Yandex په پرتله ډیر ریکارډونه.
- CloudFlare: 36 سرورونه، دوی په ورځ کې 200 ملیارد ریکارډونه خوندي کوي. دوی حتی لږ سرورونه لري او حتی ډیر معلومات ذخیره کوي.
- بلومبرګ: 102 سرورونه، هره ورځ شاوخوا یو ټریلیون ننوتل. ریکارډ لرونکی.
په جغرافیه کې، دا هم ډیر دی. دا نقشه دلته د تودوخې نقشه ښیې چیرې چې کلیک هاوس په نړۍ کې کارول کیږي. روسیه، چین او امریکا دلته په ښکاره ډول ولاړ دي. لږ اروپايي هیوادونه شتون لري. او 4 کلسترونه شتون لري.
دا یو مقایسه تحلیل دی، مطلق ارقامو ته اړتیا نشته. دا د هغو لیدونکو تحلیل دی چې د Altinity په ویب پاڼه کې د انګلیسي ژبې مواد لولي، ځکه چې هلته روسي خبرې نه کوي. او روسیه، اوکراین، بیلاروس، یعنی د ټولنې روسی ژبی برخه، دا ډیری ډیری کاروونکي دي. بیا امریکا او کاناډا راځي. چین ډیر په زړه پوری دی. شپږ میاشتې مخکې هلته تقریباً چین نه و، اوس چین لا له وړاندې اروپا ته مخه کړې او وده کوي. زوړ اروپا هم وروسته پاتې نه ده، او د کلک هاؤس په کارولو کې مشر، په عجیب ډول، فرانسه ده.
زه ولې دا ټول وایم؟ د دې ښودلو لپاره چې کلیک هاوس د لوی ډیټا تحلیلونو لپاره معیاري حل کیږي او دمخه په ډیری ځایونو کې کارول کیږي. که تاسو دا کاروئ، تاسو په سم رجحان کې یاست. که تاسو تر اوسه دا کار نه کوئ، نو تاسو ویره مه کوئ چې تاسو به یوازې پاتې شئ او هیڅوک به ستاسو سره مرسته ونکړي، ځکه چې ډیری یې دا کار کوي.
دا په ډیری شرکتونو کې د ریښتیني کلیک هاؤس کارولو مثالونه دي.
- لومړۍ بیلګه د اعلان شبکه ده: له ورټیکا څخه کلیک هاوس ته مهاجرت. او زه یو څو شرکتونه پیژنم چې له ورټیکا څخه لیږدول شوي یا د لیږد په پروسه کې دي.
- دویمه بیلګه په ClickHouse کې د لیږد ذخیره ده. دا یو مثال دی چې د انټي پیټرونو باندې جوړ شوی. هرڅه چې باید د پراختیا کونکو په مشوره په کلیک هاوس کې ترسره نشي دلته ترسره کیږي. او دا په مؤثره توګه ترسره شوی چې دا کار کوي. او دا د عادي لیږد حل په پرتله خورا ښه کار کوي.
- دریمه بیلګه په ClickHouse کې ویشل شوي کمپیوټري دي. دلته یوه پوښتنه وه چې څنګه ClickHouse د هډوپ ایکوسیستم کې مدغم کیدی شي. زه به یو مثال وښیم چې څنګه یو شرکت په کلیک هاوس کې د نقشې کمولو کانټینر ته ورته یو څه ترسره کړي ، د ډیټا ځایی کولو تعقیب ساتل ، او داسې نور ، د خورا غیر معمولي کار محاسبه کولو لپاره.
- LifeStreet د اعلان ټیک شرکت دی چې ټول ټیکنالوژي لري چې د اعلان شبکې سره راځي.
- هغه د اعلان اصلاح کولو، پروګراماتي داوطلبۍ کې بوخته ده.
- ډیری ډاټا: هره ورځ شاوخوا 10 ملیارد پیښې. په ورته وخت کې، پیښې په څو فرعي پیښو ویشل کیدی شي.
- د دې ډاټا ډیری پیرودونکي شتون لري، او دا یوازې خلک نه دي، ډیر څه - دا مختلف الګوریتمونه دي چې د برنامو داوطلبۍ کې بوخت دي.
شرکت یوه اوږده او تنګه لاره راوتلې ده. او ما د دې په اړه په HighLoad کې خبرې وکړې. لومړی، LifeStreet له MySQL څخه (په اوریکل کې د لنډ تمځای سره) ورټیکا ته لاړ. او تاسو کولی شئ د هغې په اړه یوه کیسه ومومئ.
او هرڅه خورا ښه وو، مګر دا په چټکۍ سره روښانه شوه چې ډاټا وده کوي او ورټیکا ګران دی. له همدې امله، د مختلفو بدیلونو په لټه کې شول. ځینې یې دلته لیست شوي دي. او په حقیقت کې ، موږ د تصور ثبوت یا ځینې وختونه د نږدې ټولو ډیټابیسونو فعالیت ازموینې ترسره کړې چې په بازار کې له 13 څخه تر 16 کال پورې شتون درلود او د فعالیت شرایطو کې نږدې مناسب و. او ما د دوی د ځینو په اړه په HighLoad کې هم خبرې وکړې.
دنده دا وه چې په لومړي ځای کې له ورټیکا څخه مهاجرت وکړي، ځکه چې ډاټا وده کړې. او دوی د کلونو په اوږدو کې په چټکۍ سره وده وکړه. بیا دوی په المارۍ کې لاړل، مګر بیا هم. او د دې ودې وړاندوینه کول، د ډیټا مقدار لپاره د سوداګرۍ اړتیاوې چې په اړه یې ځینې ډول تحلیلونو ته اړتیا درلوده، دا روښانه وه چې پیټابایټ به ډیر ژر خبرې وکړي. او د پیټابایټ لپاره تادیه کول دمخه خورا ګران دي ، نو موږ د یو بدیل په لټه کې یو چیرې چې لاړ شو.
چیرته لاړ شه؟ او د اوږدې مودې لپاره دا روښانه نه وه چې چیرته ځي، ځکه چې له یوې خوا سوداګریز ډیټابیسونه شتون لري، داسې ښکاري چې ښه کار کوي. ځینې یې تقریبا د ورټیکا په څیر کار کوي، ځینې نور هم خراب دي. مګر دا ټول ګران دي، هیڅ ارزانه او غوره نشي موندل کیدی.
له بلې خوا، د خلاصې سرچینې حلونه شتون لري، کوم چې ډیر شمیر نه دي، د بیلګې په توګه، د تحلیلاتو لپاره، دوی په ګوتو کې شمیرل کیدی شي. او دوی وړیا یا ارزانه دي، مګر سست. او دوی ډیری وختونه اړین او ګټور فعالیت نلري.
او د ښه یوځای کولو لپاره هیڅ شی نه و چې په سوداګریز ډیټابیسونو کې دي او ټول وړیا چې په خلاصې سرچینې کې دي.
تر هغه وخته پورې هیڅ نه و، په ناڅاپي ډول، یاندیکس د کلیک هاوس څخه د جادوګر په څیر، د خولۍ څخه د خرگوش په څیر ایستل. او دا یو غیر متوقع پریکړه وه، دوی لاهم پوښتنه کوي: "ولې؟"، مګر بیا هم.
او سمدلاسه د 2016 په دوبي کې ، موږ په دې اړه پیل وکړ چې کلیک هاوس څه شی دی. او دا معلومه شوه چې ځینې وختونه دا د ویرټیکا څخه ګړندی کیدی شي. موږ په مختلف غوښتنو کې مختلف سناریوګانې ازمولې. او که چیرې پوښتنې یوازې یو میز کارولی وي، دا دی، پرته له کوم یوځای کیدو (یوځای کیدو)، نو کلیک هاوس د ورټیکا په پرتله دوه چنده ګړندی و.
زه ډیر سست نه وم او بله ورځ د Yandex ازموینې ته ګورم. دا هلته ورته دی: ClickHouse د ورټیکا په پرتله دوه چنده ګړندی دی، نو دوی ډیری وختونه د هغې په اړه خبرې کوي.
مګر که چیرې په پوښتنو کې یوځای شي، نو بیا هرڅه په ښکاره ډول نه ښکاري. او کلیک هاؤس د ورټیکا په څیر دوه ځله سست کیدی شي. او که تاسو غوښتنه لږ څه سمه کړئ او بیا یې ولیکئ، نو دوی نږدې مساوي دي. بد نه دی. او وړیا.
او د ازموینې پایلې ترلاسه کولو سره ، او د مختلف زاویو څخه یې په لټه کې ، لائف سټریټ کلیک هاوس ته لاړ.
دا 16م کال دی، زه تاسو ته یادونه کوم. دا د موږکانو په اړه د ټوکې په څیر و چې چیغې یې کړې او ځان یې ټوپ کړ، مګر د کیکټس خوړلو ته یې دوام ورکړ. او دا په تفصیل سره بیان شوی، د دې په اړه ویډیو شتون لري، او داسې نور.
له همدې امله، زه به په دې اړه په تفصیل سره خبرې ونه کړم، زه به یوازې د پایلو او یو څو په زړه پورې شیانو په اړه وغږیږم چې ما بیا په اړه خبرې نه وې کړې.
پایلې یې دا دي:
- بریالي مهاجرت او د یو کال څخه ډیر سیسټم لا دمخه په تولید کې کار کوي.
- تولید او انعطاف پذیري زیاته شوې ده. د 10 ملیارد ریکارډونو څخه چې موږ یې کولی شو هره ورځ ذخیره کړو او بیا د لنډ وخت لپاره ، LifeStreet اوس هره ورځ 75 ملیارد ریکارډونه ذخیره کوي او کولی شي دا د 3 میاشتو یا ډیرو لپاره ترسره کړي. که تاسو په چوکۍ کې حساب کړئ، نو دا په هر ثانیه کې یو ملیون پیښې دي. په ورځ کې له یو ملیون څخه ډیر SQL پوښتنې پدې سیسټم کې راځي ، ډیری یې د مختلف روبوټونو څخه.
- د دې حقیقت سره سره چې د کلک هاؤس لپاره د ورټیکا په پرتله ډیر سرورونه کارول شوي ، دوی په هارډویر کې هم خوندي شوي ، ځکه چې په ویرټیکا کې خورا ګران SAS ډیسک کارول شوي. ClickHouse د SATA کارول. او ولې؟ ځکه چې په ورټیکا کې داخل کول همغږي دي. او همغږي کول دې ته اړتیا لري چې ډیسکونه ډیر سست نه کړي ، او دا هم چې شبکه خورا ورو نه کوي ، دا یو خورا ګران عملیات دی. او په ClickHouse کې داخل کول غیر متناسب دی. سربیره پردې ، تاسو تل کولی شئ هرڅه په ځایی ډول ولیکئ ، د دې لپاره هیڅ اضافي لګښتونه شتون نلري ، نو ډیټا د ویرټیکا په پرتله خورا ګړندي کلیک هاؤس ته داخل کیدی شي ، حتی په ورو ډرایو کې. او لوستل هم په همدې اړه دي. په SATA کې لوستل، که دوی په RAID کې وي، نو دا ټول خورا چټک دي.
- د جواز لخوا محدود ندي، د بیلګې په توګه په 3 سرورونو کې د 60 پیټابایټ ډیټا (20 سرورونه یو نقل دی) او په حقایقو او مجموعو کې 6 ټریلیون ریکارډونه. په ورټیکا کې د دې په څیر هیڅ شی نشي اخیستل کیدی.
زه اوس په دې مثال کې عملي شیانو ته راځم.
- لومړی یو اغیزمن سکیم دی. ډیری په سکیما پورې اړه لري.
- دوهم د موثر SQL نسل دی.
د OLAP عمومي پوښتنه یو انتخاب دی. ځینې کالمونه ګروپ ته ځي، ځینې کالمونه مجموعي افعال ته ځي. هلته شتون لري، کوم چې د کیوب د ټوټې په توګه ښودل کیدی شي. ټوله ډله د یوې پروجیکشن په توګه فکر کیدی شي. او له همدې امله دې ته د څو اړخیز ډیټا تحلیل ویل کیږي.
او ډیری وختونه دا د ستوري سکیم په شکل کې ماډل کیږي، کله چې د دې حقیقت مرکزي حقیقت او ځانګړتیاوې د اړخونو په اوږدو کې، د شعاعو په اوږدو کې وي.
او د فزیکي ډیزاین په شرایطو کې، دا څنګه په میز کې فټ کیږي، دوی معمولا یو عادي استازیتوب کوي. تاسو کولی شئ غیر نورمال کړئ، مګر دا په ډیسک کې ګران دی او په پوښتنو کې خورا اغیزمن ندي. نو ځکه، دوی معمولا یو نورمال نمایندګي کوي، د بیلګې په توګه د حقیقت جدول او ډیری، ډیری ابعاد جدول.
مګر دا په ClickHouse کې ښه کار نه کوي. دوه لاملونه دي:
- لومړی دا چې ClickHouse ډیر ښه یوځای کیدل نه لري، د بیلګې په توګه یوځای کیدل شتون لري، مګر دوی خراب دي. په داسې حال کې چې بد.
- دوهم دا چې میزونه نوي شوي ندي. معمولا په دې پلیټونو کې، کوم چې د ستوري سرکټ په شاوخوا کې وي، یو څه بدلولو ته اړتیا لري. د مثال په توګه، د پیرودونکي نوم، د شرکت نوم، او داسې نور. او دا کار نه کوي.
او په ClickHouse کې له دې څخه د وتلو یوه لاره شتون لري. حتی دوه:
- لومړی د لغتونو کارول دي. بهرنۍ لغتونه هغه څه دي چې د سټار سکیما سره د 99٪ ستونزې حل کولو کې مرسته کوي، تازه معلومات او داسې نور.
- دوهم د صفونو کارول دي. سرې هم د یوځای کیدو او نورمال کیدو سره ستونزو څخه خلاصیدو کې مرسته کوي.
- یوځای کیدو ته اړتیا نشته.
- د لوړولو وړ. د مارچ 2018 راهیسې، یو غیر مستند فرصت ښکاره شوی (تاسو به دا په اسنادو کې ونه مومئ) ترڅو لغتونه په جزوي ډول تازه کړئ، د بیلګې په توګه هغه ننوتل چې بدل شوي دي. په عملي توګه، دا د میز په څیر دی.
- تل په حافظه کې ، نو د قاموس سره یوځای کیږي د دې په پرتله ګړندي کار کوي که چیرې دا یو میز وي چې په ډیسک کې وي او دا لاهم حقیقت نده چې دا په زیرمه کې وي ، ډیری احتمال نلري.
- تاسو هم یوځای کیدو ته اړتیا نلرئ.
- دا یو کمپیکٹ 1-to-ډیری نمایش دی.
- او زما په نظر، صفونه د جیکس لپاره جوړ شوي دي. دا د لامبډا دندې دي او داسې نور.
دا د سور کلمو لپاره ندي. دا یو خورا پیاوړی فعالیت دی چې تاسو ته اجازه درکوي ډیری شیان په خورا ساده او ښکلي ډول ترسره کړئ.
عادي مثالونه چې د صفونو په حلولو کې مرسته کوي. دا مثالونه ساده او روښانه دي:
- د ټګونو په واسطه لټون وکړئ. که تاسو هلته هشټاګ لرئ او غواړئ د هشټاګ لخوا ځینې پوسټونه ومومئ.
- د کلیدي ارزښت جوړو په واسطه لټون وکړئ. د ارزښت سره ځینې ځانګړتیاوې هم شتون لري.
- د کیلي لیستونو ذخیره کول چې تاسو ورته اړتیا لرئ په بل څه کې ژباړئ.
دا ټولې دندې پرته له صفونو حل کیدی شي. ټاګونه په یو کرښه کې کیښودل کیدی شي او د منظم بیان یا جلا جدول سره غوره کیدی شي ، مګر بیا تاسو باید یوځای کیدو ته اړتیا ولرئ.
او په ClickHouse کې، تاسو اړتیا نلرئ کوم څه وکړئ، دا د هشټاګونو لپاره د سټینګ سرې تشریح کولو یا د کلیدي ارزښت سیسټمونو لپاره د نسج جوړښت رامینځته کولو لپاره کافي دی.
ځړول شوی جوړښت ممکن غوره نوم نه وي. دا دوه صفونه دي چې په نوم او ځینې اړوند ځانګړتیاوې لري.
او د ټګ لخوا لټون کول خورا اسانه دي. فعالیت ولري has، کوم چې ګوري چې سرې یو عنصر لري. هرڅوک، ټولې ننوتنې وموندلې چې زموږ کنفرانس پورې اړه لري.
د سبایډ لخوا لټون یو څه ډیر پیچلی دی. موږ باید لومړی د کیلي شاخص ومومئ، او بیا د دې شاخص سره عنصر واخلو او وګورو چې دا ارزښت هغه څه دي چې موږ ورته اړتیا لرو. په هرصورت، دا خورا ساده او کمپیکٹ دی.
منظم بیان چې تاسو یې غواړئ ولیکئ که تاسو دا ټول په یوه کرښه کې وساتئ، نو دا به لومړی، ناپاک وي. او، دوهم، دا د دوو صفونو څخه ډیر اوږد کار کاوه.
بل مثال. تاسو یو صف لرئ چیرې چې تاسو ID ذخیره کوئ. او تاسو کولی شئ دوی په نومونو وژباړئ. فعالیت arrayMap. دا د لامبدا یو عادي فعالیت دی. تاسو هلته د لامبډا څرګندونې تیرې کړئ. او هغه د لغت څخه د هر ID لپاره د نوم ارزښت راوباسي.
لټون په ورته ډول ترسره کیدی شي. د وړاندوینې فنکشن تیریږي چې ګوري چې عناصر څه سره سمون لري.
دا شیان د سرکټ خورا ساده کوي او د ستونزو یوه ډله حل کوي.
مګر بله ستونزه چې موږ ورسره مخ یو، او کوم چې زه یې غواړم یادونه وکړم، اغیزمنې پوښتنې دي.
- ClickHouse د پوښتنې پالن جوړونکی نه لري. بالکل نه.
- په هرصورت، پیچلې پوښتنې لاهم پالن کولو ته اړتیا لري. په کومو حالاتو کې؟
- که چیرې په پوښتنې کې ډیری شمولیت شتون ولري، تاسو یې په فرعي انتخابونو کې وتړئ. او په کوم حکم کې چې دوی اعدام شوي دي مهم دي.
- او دوهم - که غوښتنه ویشل کیږي. ځکه چې په توزیع شوي پوښتنې کې، یوازې ترټولو داخلي فرعي انتخاب په توزیع اجرا کیږي، او نور هرڅه یو سرور ته لیږدول کیږي چې تاسو ورسره وصل شوي او هلته اعدام شوي. له همدې امله، که تاسو د ډیری شمولیتونو (ګډون) سره پوښتنې توزیع کړې وي، نو تاسو اړتیا لرئ امر غوره کړئ.
او حتی په ساده قضیو کې ، ځینې وختونه دا هم اړین دي چې د مهالویش کار ترسره کړئ او پوښتنې لږ څه بیا ولیکئ.
دلته یو مثال دی. په کیڼ اړخ کې یوه پوښتنه ده چې غوره 5 هیوادونه ښیې. او دا زما په نظر 2,5 ثانیې وخت نیسي. او په ښي خوا کې، ورته پوښتنه، مګر یو څه بیا لیکل شوی. د تار په واسطه د ګروپ کولو پرځای، موږ د کلیدي (int) په واسطه ګروپ کول پیل کړل. او دا چټک دی. او بیا موږ پایلې ته یو لغت وصل کړ. د 2,5 ثانیو پرځای، غوښتنه 1,5 ثانیې وخت نیسي. دا ښه دی.
د بیا لیکلو فلټرونو سره ورته مثال. دلته د روسیې غوښتنه ده. دا د 5 ثانیو لپاره ځي. که موږ دا په داسې ډول بیا ولیکئ چې موږ بیا د تار سره نه پرتله کوو، مګر د ځینو کلیمو سره شمیرې چې د روسیې سره تړاو لري، نو دا به خورا چټک وي.
ډیری داسې چلونه شتون لري. او دوی تاسو ته اجازه درکوي د پام وړ پوښتنو ګړندۍ کړئ چې تاسو فکر کوئ دمخه ګړندي روان دي ، یا په برعکس ، ورو روان دي. دوی حتی ګړندي کیدی شي.
- په توزیع شوي حالت کې اعظمي کار.
- د لږترلږه ډولونو له مخې ترتیب کول، لکه څنګه چې ما د ints لخوا ترسره کړل.
- که چیرې کوم یوځای کیدل (ګډون)، لغتونه وي، نو دا به غوره وي چې دوی د وروستي حل په توګه ترسره کړئ، کله چې تاسو دمخه لږ تر لږه یو څه ډله ایز معلومات لرئ، نو د یوځای کولو عملیات یا لغت کال به لږ وخت ویل کیږي او دا به ګړندی وي. .
- د فلټرونو بدلول.
نور تخنیکونه شتون لري، او نه یوازې هغه چې ما ښودلي دي. او دا ټول کولی شي ځینې وختونه د پوښتنو اجرا کولو کې د پام وړ ګړندي کړي.
راځئ چې راتلونکي مثال ته لاړ شو. شرکت X د متحده ایالاتو څخه. هغه څه کوي؟
یوه دنده وه:
- د اعلاناتو لیږدونو آفلاین لینک کول.
- د مختلف پابندۍ موډل جوړول.
سناریو څه ده؟
یو عادي لیدونکی سایټ ته راځي، د بیلګې په توګه، په میاشت کې 20 ځله د مختلفو اعلاناتو څخه، یا لکه څنګه چې ځینې وختونه پرته له اعلاناتو راځي، ځکه چې هغه دا سایټ په یاد لري. ځینې محصولات ګوري، په ټوکرۍ کې یې اچوي، له ټوکرۍ څخه یې اخلي. او، په پای کې، یو څه اخلي.
معقول پوښتنې: "څوک باید د اعلاناتو لپاره پیسې ورکړي، که اړتیا وي؟" او "کوم اعلاناتو په هغه اغیزه کړې، که کوم؟" يعنې ولې يې پېرودلې او څنګه يې د دې په څېر خلک هم پېرودلو ته اړ کړل؟
د دې ستونزې د حل کولو لپاره، تاسو اړتیا لرئ هغه پیښې چې په ویب پاڼه کې واقع کیږي په سمه توګه وصل کړئ، دا په یو ډول د دوی ترمنځ اړیکه جوړه کړئ. بیا دوی DWH ته د تحلیل لپاره لیږل کیږي. او د دې تحلیل پراساس ، د چا او کوم اعلاناتو ښودلو ماډلونه جوړ کړئ.
د اعلان لیږد د اړوندو کاروونکو پیښو یوه مجموعه ده چې د اعلان ښودلو څخه پیل کیږي، بیا یو څه پیښیږي، بیا شاید پیرود، او بیا ممکن د پیرود دننه پیرود وي. د مثال په توګه، که دا یو ګرځنده اپلیکیشن یا ګرځنده لوبه وي، نو معمولا د اپلیکیشن نصب کول په وړیا توګه ترسره کیږي، او که چیرې یو څه ترسره شي، نو د دې لپاره پیسو ته اړتیا لیدل کیدی شي. او هرڅومره چې یو څوک په غوښتنلیک کې مصرف کوي ، هومره ارزښت لري. مګر د دې لپاره تاسو اړتیا لرئ چې هرڅه وصل کړئ.
ډیری پابند ماډلونه شتون لري.
تر ټولو مشهور دي:
- وروستی تعامل، چیرې چې تعامل یا یو کلیک یا تاثیر دی.
- لومړی متقابل عمل، د بیلګې په توګه لومړی شی چې یو سړی سایټ ته راوړی.
- خطي ترکیب - ټول مساوي.
- توجه کول.
- او همداسی پسی.
او دا ټول په لومړي ځای کې څنګه کار وکړ؟ هلته رنټیم او کیسیندرا وه. کیسیندرا د لیږد ذخیره کولو په توګه کارول کیده، د بیلګې په توګه ټول اړوند لیږدونه په دې کې زیرمه شوي. او کله چې په Runtime کې کومه پیښه راشي، د بیلګې په توګه، یو څه پاڼه یا بل څه ښودل، نو بیا کیسندرا ته غوښتنه وشوه - ایا داسې څوک شتون لري که نه. بیا هغه معاملې چې پدې پورې اړه لري ترلاسه شوې. او اړیکه جوړه شوه.
او که دا نېکمرغه وي چې غوښتنه د راکړې ورکړې ID لري، نو دا اسانه ده. مګر معمولا هیڅ قسمت نلري. له همدې امله، دا اړینه وه چې وروستی لیږد یا د وروستي کلیک سره معامله ومومئ، وغيره.
او دا ټول خورا ښه کار کاوه تر هغه چې بندیز وروستی کلیک ته و. ځکه چې دلته هره ورځ 10 ملیون کلیکونه شتون لري، په میاشت کې 300 ملیون، که موږ د یوې میاشتې لپاره کړکۍ وټاکو. او له هغه ځایه چې په کاسندرا کې دا باید د ګړندي چلولو لپاره ټول په حافظه کې وي ، ځکه چې د رنټیم ګړندي ځواب ورکولو ته اړتیا لري ، شاوخوا 10-15 سرورونه یې اخیستي.
او کله چې دوی غوښتل د نندارتون سره معامله وصل کړي ، نو سمدلاسه دومره ساتیري نه وه. او ولې؟ دا لیدل کیدی شي چې 30 ځله نور پیښې ذخیره کولو ته اړتیا لري. او، په وینا، تاسو 30 ځله نور سرورونو ته اړتیا لرئ. او دا معلومه شوه چې دا یو ډول ستورپوهنه ده. د لینک کولو لپاره تر 500 سرورونو پورې ساتلو لپاره ، سره له دې چې په رنټیم کې د پام وړ لږ سرورونه شتون لري ، نو دا یو ډول غلط شمیر دی. او دوی فکر پیل کړ چې څه وکړي.
او موږ ClickHouse ته لاړو. او دا څنګه په ClickHouse کې ترسره کړئ؟ په لومړي نظر کې، داسې ښکاري چې دا د ضد نمونو یوه مجموعه ده.
- راکړه ورکړه وده کوي، موږ دې ته ډیر او ډیرې پیښې وټاکو، د بیلګې په توګه دا بدلون وړ دی، او کلیک هاوس د بدلون وړ شیانو سره ډیر ښه کار نه کوي.
- کله چې یو لیدونکی موږ ته راځي، موږ باید د هغه د لیدنې ID په واسطه د کیلي په واسطه د هغه لیږد راوباسئ. دا هم د ټکي پوښتنه ده، دوی دا په ClickHouse کې نه کوي. معمولا کلک هاؤس لوی … سکینونه لري، مګر دلته موږ اړتیا لرو چې ځینې ریکارډونه ترلاسه کړو. همدارنګه یو ضد نمونه.
- سربیره پردې، معامله په json کې وه، مګر دوی نه غوښتل چې دا بیا ولیکي، نو دوی غوښتل چې json په غیر منظم ډول ذخیره کړي، او که اړتیا وي، له هغې څخه یو څه وباسي. او دا هم یو ضد پیټی دی.
دا د انټي پیټرونو یوه سیټ دی.
مګر بیا هم دا د داسې سیسټم رامینځته کولو لپاره وګرځید چې خورا ښه کار کوي.
څه وشول؟ ClickHouse ښکاره شو، په کوم کې چې لاګونه اچول شوي، په ریکارډونو ویشل شوي. یو منسوب خدمت ښکاره شو چې د ClickHouse څخه لاګونه ترلاسه کړي. له هغې وروسته، د هرې ننوتلو لپاره، د لیدنې id په واسطه، ما هغه لیږدونه ترلاسه کړل چې ممکن تر اوسه پروسس شوي نه وي او همدارنګه سنیپ شاټونه، د بیلګې په توګه د پخوانۍ کار پایله. ما دمخه له دوی څخه منطق رامینځته کړی ، سمه معامله غوره کړې ، نوي پیښې وصل کړې. بیا ننوتل. لاګ بیرته ClickHouse ته لاړ، د بیلګې په توګه دا یو دوامداره سایکل سیسټم دی. او سربیره پردې، زه DWH ته لاړم چې هلته یې تحلیل کړم.
دا په دې بڼه وه چې دا خورا ښه کار نه و. او د ClickHouse لپاره د اسانه کولو لپاره، کله چې د لیدنې id لخوا غوښتنه وشوه، دوی دا غوښتنې د 1-000 لیدنې ids په بلاکونو کې ګروپ کړې او د 2-000 خلکو لپاره یې ټولې لیږدونه ایستل. او بیا دا ټول کار وکړ.
که تاسو د ClickHouse دننه وګورئ، نو یوازې 3 اصلي میزونه شتون لري چې دا ټول خدمت کوي.
لومړی جدول په کوم کې چې لاګونه اپلوډ شوي ، او لاګونه پرته له پروسس کولو اپلوډ شوي.
دوهم میز. د مادي لید له لارې، له دې لاګونو څخه، هغه پیښې چې لا تر اوسه پورې ندي منسوب شوي، د بیلګې په توګه، غیر تړل شوي، له مینځه وړل شوي. او د مادي لید له لارې، لیږدونه د دې لاګونو څخه ایستل شوي ترڅو د سنیپ شاټ جوړ کړي. دا دی، یو ځانګړی مادي لید یو سنیپ شاټ جوړ کړی، د بیلګې په توګه د لیږد وروستی جمع شوی حالت.
دلته په SQL کې لیکل شوی متن دی. زه غواړم په دې کې یو څو مهم ټکي په ګوته کړم.
لومړی مهم شی په ClickHouse کې د json څخه د کالمونو او ساحو د ایستلو وړتیا ده. دا دی، ClickHouse د json سره کار کولو لپاره ځینې میتودونه لري. دوی ډیر، ډیر ابتدايي دي.
visitParamExtractInt تاسو ته اجازه درکوي د json څخه ځانګړتیاوې راوباسئ، د بیلګې په توګه لومړی هټ کار کوي. او په دې توګه تاسو کولی شئ د لیږد id یا د لیدنې ID راوباسئ. همدا اوس.
دوهم، دلته یو ستونزمن مادي ساحه کارول کیږي. دا څه معنی ورکوي؟ دا پدې مانا ده چې تاسو نشئ کولی دا په میز کې داخل کړئ، د بیلګې په توګه دا نه دی داخل شوی، دا د ننوتلو په وخت کې حساب شوی او ذخیره شوی. کله چې پیسټ کول، ClickHouse ستاسو لپاره کار کوي. او هغه څه چې تاسو وروسته ورته اړتیا لرئ دمخه د json څخه ایستل شوي.
په دې حالت کې، مادي لید د خام قطارونو لپاره دی. او لومړی جدول په عملي ډول خام لوګو سره یوازې کارول کیږي. او هغه څه کوي؟ لومړی، دا ترتیب کول بدلوي، د بیلګې په توګه اوس ترتیب کول د لیدنې id لخوا پرمخ ځي، ځکه چې موږ باید ژر تر ژره د یو ځانګړي کس لپاره د هغه معامله وباسو.
دوهم مهم شی د index_granularity دی. که تاسو MergeTree لیدلی وي، دا معمولا 8 د ډیفالټ index_granularity لخوا وي. دا څه شی دی؟ دا د شاخص سپکوالي پیرامیټر دی. په ClickHouse کې شاخص لږ دی، دا هیڅکله د هرې ننوتلو شاخص نه کوي. دا په هر 192 کې دا کار کوي. او دا ښه ده کله چې ډیری ډیټا محاسبه کولو ته اړتیا وي، مګر خراب کله چې لږ وي، ځکه چې لوی سر شتون لري. او که موږ د شاخص ګرانولریت کم کړو، نو بیا موږ سر ټیټ کوو. دا نشي کولی یو ته راټیټ شي، ځکه چې ممکن کافي حافظه نه وي. شاخص تل په حافظه کې ساتل کیږي.
سنیپ شاټ ځینې نور په زړه پوري کلیک هاؤس ځانګړتیاوې هم کاروي.
لومړی، دا AggregatingMergeTree دی. او AggregatingMergeTree argMax ذخیره کوي، د بیلګې په توګه دا د لیږد حالت دی چې د وروستي مهال ویش سره مطابقت لري. راکړې ورکړې هر وخت د ورکړل شوي لیدونکي لپاره رامینځته کیږي. او د دې لیږد په وروستي حالت کې، موږ یوه پیښه اضافه کړه او موږ یو نوی حالت لرو. دا یو ځل بیا کلیک هاؤس ته ورسید. او پدې مادي لید کې د ارګ میکس له لارې ، موږ تل اوسنی حالت ترلاسه کولی شو.
- پابند د رن ټایم څخه "ډیکل شوی" دی.
- په میاشت کې تر 3 ملیاردو پورې لیږدونه زیرمه او پروسس کیږي. دا په کاسندرا کې د دې په پرتله خورا لوی ترتیب دی، د بیلګې په توګه په یو عادي لیږد سیسټم کې.
- د 2x5 ClickHouse سرورونو کلستر. 5 سرورونه او هر سرور یو نقل لري. دا د کلک پراساس انتساب کولو لپاره په کاسندرا کې د دې څخه حتی لږ دی ، او دلته موږ د تاثیر پراساس لرو. دا د دې پر ځای چې د سرورونو شمیر 30 ځله زیات کړي، دوی اداره کړي چې دوی یې کم کړي.
او وروستی مثال یې مالي شرکت Y دی، کوم چې د سټاک قیمتونو کې د بدلونونو ارتباط تحلیل کړی.
او دنده دا وه:
- نږدې 5 ونډې شتون لري.
- په هرو 100 ملی ثانیو کې نرخونه پیژندل کیږي.
- معلومات په 10 کلونو کې راټول شوي. په ښکاره ډول، د ځینو شرکتونو لپاره ډیر، د ځینو لپاره لږ.
- په مجموع کې نږدې 100 ملیارد قطارونه شتون لري.
او دا اړینه وه چې د بدلونونو ارتباط محاسبه کړي.
دلته دوه ذخیره او د دوی نرخونه دي. که یو پورته کیږي او بل پورته کیږي، نو دا یو مثبت اړیکه ده، یعنې یو پورته کیږي او بل پورته کیږي. که یو پورته شي، لکه د ګراف په پای کې، او بل ښکته ځي، نو دا یو منفي اړیکه ده، د بیلګې په توګه کله چې یو پورته کیږي، بل راټیټیږي.
د دې متقابل بدلونونو تحلیل، یو څوک کولی شي په مالي بازار کې وړاندوینې وکړي.
خو کار ستونزمن دی. د دې لپاره څه کیږي؟ موږ 100 ملیارد ریکارډونه لرو چې لري: وخت، ذخیره او قیمت. موږ اړتیا لرو چې د قیمت الګوریتم څخه د چلولو توپیر لومړی 100 ملیارد ځله محاسبه کړو. RunningDifference په ClickHouse کې یو فنکشن دی چې په ترتیب سره د دوو تارونو ترمنځ توپیر محاسبه کوي.
او له هغې وروسته، تاسو اړتیا لرئ چې ارتباط محاسبه کړئ، او اړیکه باید د هرې جوړې لپاره محاسبه شي. د 5 ونډو لپاره، جوړه 000 ملیون دي. او دا ډیر دی، د بیلګې په توګه 12,5 ځله دا اړینه ده چې یوازې د ورته ارتباط فعالیت محاسبه کړئ.
او که څوک هیر کړي، نو بیا ͞x او ͞y یو چیک میټ دی. د نمونې اخیستلو تمه. يعنې دا نه يوازې د ريښو او رقمونو محاسبه کول ضروري دي، بلکې د دې رقمونو دننه يو بل رقم هم پکار دی. د محاسبې یوه ډله باید 12,5 ملیون ځله ترسره شي، او حتی د ساعتونو په واسطه ګروپ شوي. موږ هم ډیر ساعتونه لرو. او تاسو باید دا په 60 ثانیو کې ترسره کړئ. دا یوه ټوکه ده.
دا اړینه وه چې لږ تر لږه یو څه وخت ولرئ، ځکه چې دا ټول ډیر، ډیر ورو ورو مخکې له دې چې د کلک هاوس راشي کار کاوه.
دوی هڅه وکړه چې دا په هډوپ، سپارک، ګرین پلم کې محاسبه کړي. او دا ټول ډیر سست یا ګران وو. دا دی، دا ممکنه وه چې یو څه محاسبه شي، مګر بیا دا ګرانه وه.
او بیا کلیک هاوس راغی او شیان خورا ښه شول.
زه تاسو ته یادونه کوم چې موږ د معلوماتو ځای په ځای کولو کې ستونزه لرو، ځکه چې ارتباط نشي کولی ځایی شي. موږ نشو کولی ځینې ډاټا په یو سرور کې واچوو، ځینې په بل کې او محاسبه کړو، موږ باید ټول معلومات په هر ځای کې ولرو.
دوی څه وکړل؟ په پیل کې، معلومات محلي شوي دي. هر سرور د ونډو د یوې ټاکلې سیټ قیمت په اړه معلومات ذخیره کوي. او دوی نه یو ځای کیږي. له همدې امله، دا ممکنه ده چې په موازي او خپلواک ډول د logReturn محاسبه کړئ، دا ټول تر اوسه په موازي او ویشل شوي.
بیا موږ پریکړه وکړه چې دا ډاټا کم کړو، پداسې حال کې چې د څرګندتیا له لاسه ورکولو نه. د صفونو کارول کم کړئ، د بیلګې په توګه د هرې مودې لپاره، د سټاکونو لړۍ او د قیمتونو لړۍ جوړه کړئ. له همدې امله، دا خورا لږ ډیټا ځای نیسي. او دوی سره کار کول یو څه اسانه دي. دا تقریبا موازي عملیات دي، د بیلګې په توګه موږ یو څه په موازي توګه لوستلو او بیا سرور ته لیکو.
له هغې وروسته، دا تکرار کیدی شي. د "r" لیک معنی دا ده چې موږ دا ډاټا نقل کړې. دا دی، موږ په ټولو دریو سرورونو کې ورته معلومات لرو - دا سرې دي.
او بیا د دې 12,5 ملیون ارتباطاتو سیټ څخه د ځانګړي سکریپټ سره چې محاسبه کولو ته اړتیا لري ، تاسو کولی شئ کڅوړې جوړې کړئ. یعنی ۲۵۰۰ کارونه د ۵۰۰۰ جوړه اړیکو سره. او دا دنده په یو ځانګړي کلیک هاؤس سرور کې محاسبه کیږي. هغه ټول معلومات لري، ځکه چې ډاټا یو شان دي او هغه کولی شي په ترتیب سره حساب کړي.
یو ځل بیا، دا هغه څه دي چې داسې ښکاري. لومړی، موږ په دې جوړښت کې ټول معلومات لرو: وخت، ونډې، قیمت. بیا موږ د logReturn محاسبه کړه، د بیلګې په توګه د ورته جوړښت ډاټا، مګر د قیمت پرځای موږ دمخه logReturn لرو. بیا دوی بیا ترسره شوي، د بیلګې په توګه موږ د سټاک او نرخونو لپاره وخت او ګروپ آری ترلاسه کړ. ځړول شوی. او له هغې وروسته، موږ د دندو یوه ډله جوړه کړه او دوی یې ClickHouse ته ورکړل ترڅو دا یې حساب کړي. او دا کار کوي.
د مفهوم په ثبوت کې، دنده یو فرعي ټاسک و، د بیلګې په توګه، لږ معلومات اخیستل شوي. او یوازې درې سرورونه.
دا لومړی دوه مرحلې: د Log_return محاسبه کول او په صفونو کې پوښل شاوخوا یو ساعت وخت نیسي.
او د ارتباط محاسبه شاوخوا 50 ساعته ده. مګر 50 ساعته کافي ندي، ځکه چې دوی د اونیو لپاره کار کاوه. دا یوه لویه بریا وه. او که تاسو حساب کړئ، نو په هر ثانیه کې 70 ځله هر څه په دې کلستر کې شمیرل شوي.
مګر ترټولو مهمه خبره دا ده چې دا سیسټم په عملي توګه پرته له خنډونو څخه دی، د بیلګې په توګه، دا تقریبا په خطي توګه اندازه کوي. او دوی یې چک کړل. په بریالیتوب سره یې اندازه کړه.
- سمه سکیم نیمه بریا ده. او سمه سکیم د ټولو اړین کلیک هاوس ټیکنالوژیو کارول دي.
- Summing/AggregatingMergeTrees هغه ټیکنالوژي دي چې تاسو ته اجازه درکوي د یوې ځانګړې قضیې په توګه د دولت سنیپ شاټ راټول یا په پام کې ونیسئ. او دا ډیری شیان خورا ساده کوي.
- مادي شوي لید تاسو ته اجازه درکوي د یو شاخص حد څخه تیر شئ. شاید ما دا په روښانه ډول نه وي ویلي، مګر کله چې موږ لاګونه پورته کړل، خام لاګونه په میز کې د یو شاخص سره وو، او د ځانګړتیاوو لاګونه په میز کې وو، د بیلګې په توګه ورته ډاټا، یوازې فلټر شوی، مګر شاخص په بشپړه توګه و. نور داسې ښکاري چې ورته ډاټا وي، مګر مختلف ترتیب کول. او مادي لید تاسو ته اجازه درکوي ، که تاسو ورته اړتیا لرئ ، د داسې کلیک هاوس محدودیت څخه تیر شئ.
- د پوائنټ پوښتنو لپاره د شاخص کثافت کم کړئ.
- او ډیټا په هوښیارۍ سره توزیع کړئ ، هڅه وکړئ څومره چې امکان ولري ډیټا په سرور کې ځایی کړئ. او هڅه وکړئ ډاډ ترلاسه کړئ چې غوښتنې هم د امکان تر حده د امکان تر حده سیمه ایز کول کاروي.
او د دې لنډې وینا لنډیز، موږ کولی شو ووایو چې کلیک هاوس اوس د دواړو سوداګریزو ډیټابیسونو او خلاصې سرچینې ډیټابیسونو ساحه په کلکه نیولې ده، د بیلګې په توګه، په ځانګړې توګه د تحلیلاتو لپاره. هغه په بشپړ ډول په دې منظره کې فټ کوي. او نور څه دي، دا ورو ورو د نورو په راټولولو پیل کوي، ځکه چې کله تاسو کلیک هاؤس لرئ، تاسو InfiniDB ته اړتیا نلرئ. ورټیکا ممکن ژر اړتیا ونلري که چیرې دوی نورمال SQL ملاتړ وکړي. خوند واخلئ!
-د راپور لپاره مننه! ډیر په زړه پوری! ایا د اپاچی فینکس سره کوم پرتله شتون درلود؟
نه، ما د چا پرتله نه دی اوریدلی. موږ او Yandex هڅه کوو چې د مختلف ډیټابیسونو سره د ټولو کلیک هاوس پرتله کولو تعقیب وساتو. ځکه چې که ناڅاپه یو څه د ClickHouse په پرتله ګړندی شي ، نو لیشا میلویدوف نشي کولی د شپې خوب وکړي او په چټکۍ سره یې پیل کړي. ما د داسې پرتله کولو په اړه ندي اوریدلي.
-
(Aleksey Milovidov) Apache Phoenix یو SQL انجن دی چې د Hbase لخوا پرمخ وړل کیږي. Hbase په عمده توګه د کلیدي ارزښت کاري سناریو لپاره دی. هلته، په هره کرښه کې، د خپل سري نومونو سره د کالمونو خپلمنځي شمیر شتون لري. دا د داسې سیسټمونو په اړه ویل کیدی شي لکه Hbase، Cassandra. او دا دقیقا درنې تحلیلي پوښتنې دي چې د دوی لپاره به په نورمال ډول کار ونکړي. یا تاسو شاید فکر وکړئ چې دوی ښه کار کوي که تاسو د ClickHouse سره کومه تجربه نه لرئ.
-
سپوږمکۍ
-
بعد له غرمه مو پخیر زه لا دمخه په دې موضوع کې ډیره علاقه لرم، ځکه چې زه یو تحلیلي فرعي سیسټم لرم. مګر کله چې زه ClickHouse ته ګورم، زه احساس کوم چې ClickHouse د پیښو تحلیل لپاره خورا مناسب دی، بدلون وړ. او که زه اړتیا لرم چې د ډیری لوی میزونو سره ډیری سوداګریز ډیټا تحلیل کړم، نو کلیک هاوس، تر هغه چې زه پوهیږم، زما لپاره خورا مناسب نه دی؟ په ځانګړې توګه که دوی بدل شي. ایا دا سمه ده یا داسې مثالونه شتون لري چې کولی شي دا رد کړي؟
-
دا سمه ده. او دا د ډیری تخصصي تحلیلي ډیټابیسونو ریښتیا ده. دوی د دې حقیقت لپاره جوړ شوي چې یو یا ډیر لوی میزونه شتون لري چې د بدلون وړ دي، او د ډیری کوچنیو لپاره چې ورو ورو بدلیږي. دا دی، کلیک هاؤس د اوریکل په څیر ندی، چیرې چې تاسو کولی شئ هرڅه وساتئ او ځینې خورا پیچلې پوښتنې جوړې کړئ. د دې لپاره چې د ClickHouse په اغیزمنه توګه کار واخلئ، تاسو اړتیا لرئ چې یو سکیم په داسې طریقه جوړ کړئ چې په کلک هاوس کې ښه کار وکړي. يعنې د زياتو نارمل کولو څخه ډډه وکړئ، لغتونه وکاروئ، هڅه وکړئ چې لږې اوږدې اړيکې جوړې کړئ. او که سکیم په دې ډول جوړ شوی وي، نو بیا ورته سوداګریزې دندې په کلک هاوس کې د دودیز اړیکو ډیټابیس په پرتله خورا اغیزمن حل کیدی شي.
-
د راپور لپاره مننه! زه د وروستي مالي قضیې په اړه پوښتنه لرم. دوی تحلیلونه درلودل. دا اړینه وه چې پرتله کړئ چې دوی څنګه پورته او ښکته ځي. او زه پوهیږم چې تاسو سیسټم په ځانګړي ډول د دې تحلیلونو لپاره جوړ کړی؟ که سبا، د مثال په توګه، دوی د دې معلوماتو په اړه بل راپور ته اړتیا لري، ایا دوی اړتیا لري چې سکیما بیا جوړ کړي او ډاټا اپلوډ کړي؟ دا د غوښتنې ترلاسه کولو لپاره یو ډول پری پروسس کول دي؟
البته، دا د یو ځانګړي کار لپاره د ClickHouse کارول دي. دا په دودیز ډول په هډوپ کې حل کیدی شي. د هډوپ لپاره، دا یو مثالی دنده ده. مګر په هډوپ کې دا خورا ورو دی. او زما هدف دا دی چې وښیې چې ClickHouse کولی شي هغه دندې حل کړي چې معمولا د بشپړ مختلف وسیلو لخوا حل کیږي ، مګر په ورته وخت کې دا خورا مؤثره ترسره کوي. دا د یو ځانګړي کار لپاره مناسب دی. ښکاره خبره ده چې که په یو څه کې ورته ستونزه وي، نو په ورته ډول حل کیدی شي.
دا صفا ده. تاسو وویل چې 50 ساعته پروسس شوي. ایا دا د پیل څخه دی، تاسو کله ډاټا بار کړې یا پایلې یې ترلاسه کړې؟
او او.
سمه ده ډیره مننه.
دا په 3 سرور کلستر کې دی.
سلامونه! د راپور لپاره مننه! هرڅه خورا په زړه پوري دي. زه به د فعالیت په اړه لږ څه پوښتنه ونه کړم، مګر د ثبات په شرایطو کې د ClickHouse کارولو په اړه. دا دی، آیا تاسو کوم یو درلود، آیا تاسو باید بیا رغونه وکړئ؟ په دې قضیه کې ClickHouse څنګه چلند کوي؟ او ایا دا پیښ شوي چې تاسو هم یو نقل درلود؟ د مثال په توګه، موږ د ClickHouse سره د یوې ستونزې سره مخ شو کله چې دا لاهم د خپل حد څخه بهر کیږي او راټیټیږي.
البته، هیڅ مثالی سیسټمونه شتون نلري. او ClickHouse هم خپلې ستونزې لري. مګر ایا تاسو د Yandex.Metrica په اړه اوریدلي چې د اوږدې مودې لپاره کار نه کوي؟ احتمالا چې نه. دا په کلک هاؤس کې د 2012-2013 راهیسې په اعتبار سره کار کوي. زه کولی شم د خپلې تجربې په اړه ورته ووایم. موږ هیڅکله بشپړ ناکامي نه لرو. ځینې جزوي شیان واقع کیدی شي، مګر دوی هیڅکله دومره مهم ندي چې په سوداګرۍ باندې جدي اغیزه وکړي. دا هیڅکله نه و. ClickHouse خورا معتبر دی او په تصادفي ډول نه غورځیږي. تاسو د دې په اړه اندیښنه نلرئ. دا خامه خبره نه ده. دا د ډیری شرکتونو لخوا ثابت شوی.
سلام! تاسو وویل چې تاسو اړتیا لرئ سمدلاسه د ډیټا سکیما په اړه فکر وکړئ. که دا پیښ شي څه به وي؟ زما معلومات توییږي او توییږي. شپږ میاشتې تیریږي، او زه پوهیږم چې د دې په څیر ژوند کول ناممکن دي، زه اړتیا لرم چې ډاټا بیا پورته کړم او د دوی سره یو څه وکړم.
دا البته ستاسو په سیسټم پورې اړه لري. د دې کولو لپاره ډیری لارې شتون لري چې په حقیقت کې هیڅ بند نه وي. د مثال په توګه، تاسو کولی شئ یو مادي لید جوړ کړئ په کوم کې چې د مختلف ډیټا جوړښت رامینځته کړئ که چیرې دا په ځانګړي ډول نقشه شي. دا دی، که دا د ClickHouse په کارولو سره نقشه کولو ته اجازه ورکړي، د بیلګې په توګه ځینې شیان استخراج کړئ، ابتدايي کیلي بدل کړئ، ویش بدل کړئ، نو تاسو کولی شئ د موادو لید جوړ کړئ. خپل زاړه معلومات هلته ولیکئ، نوي به په اوتومات ډول لیکل کیږي. او بیا یوازې د موادو لید کارولو ته لاړشئ ، بیا ریکارډ بدل کړئ او زوړ میز وژنئ. دا عموما یو نه ودریدونکی میتود دی.
سپوږمکۍ.
سرچینه: www.habr.com