اس حقیقت کے باوجود کہ اب تقریباً ہر جگہ بہت زیادہ ڈیٹا موجود ہے، تجزیاتی ڈیٹا بیس اب بھی کافی غیر ملکی ہیں۔ وہ ناقص طور پر جانے جاتے ہیں اور ان کو مؤثر طریقے سے استعمال کرنے کے قابل بھی نہیں ہیں۔ بہت سے لوگ MySQL یا PostgreSQL کے ساتھ "کیکٹس کھاتے ہیں"، جو دوسرے منظرناموں، NoSQL کے ساتھ جدوجہد، یا تجارتی حل کے لیے زیادہ ادائیگی کے لیے بنائے گئے ہیں۔ ClickHouse ایک گیم چینجر ہے اور تجزیاتی DBMS کی دنیا میں داخلے کی رکاوٹ کو نمایاں طور پر کم کرتا ہے۔
رپورٹ BackEnd Conf 2018 کی ہے اور اسے اسپیکر کی اجازت سے شائع کیا گیا ہے۔
میں کون ہوں اور میں ClickHouse کے بارے میں کیوں بات کر رہا ہوں؟ میں لائف اسٹریٹ میں ترقی کا ڈائریکٹر ہوں، جو کلک ہاؤس کا استعمال کرتا ہے۔ میں Altinity کا بانی بھی ہوں۔ یہ Yandex پارٹنر ہے جو ClickHouse کو فروغ دیتا ہے اور Yandex کو ClickHouse کو مزید کامیاب بنانے میں مدد کرتا ہے۔ میں کلک ہاؤس کے بارے میں علم بانٹنے کے لیے بھی تیار ہوں۔
اور میں بھی پیٹیا زیٹسیف کا بھائی نہیں ہوں۔ مجھ سے اکثر اس بارے میں پوچھا جاتا ہے۔ نہیں ہم بھائی نہیں ہیں۔
"ہر کوئی جانتا ہے" کہ کلک ہاؤس:
- بہت تیز،
- بہت آسان،
- Yandex میں استعمال کیا جاتا ہے۔
یہ بہت کم معلوم ہے کہ کن کمپنیوں میں اور اسے کیسے استعمال کیا جاتا ہے۔
میں آپ کو بتاؤں گا کہ Yandex کے علاوہ ClickHouse کیوں، کہاں اور کیسے استعمال ہوتا ہے۔
میں آپ کو بتاؤں گا کہ مختلف کمپنیوں میں ClickHouse کا استعمال کرتے ہوئے مخصوص مسائل کیسے حل کیے جاتے ہیں، آپ اپنے کاموں کے لیے کون سے ClickHouse ٹولز استعمال کر سکتے ہیں، اور وہ مختلف کمپنیوں میں کیسے استعمال ہوتے تھے۔
میں نے تین مثالیں منتخب کی ہیں جو مختلف اطراف سے ClickHouse کو ظاہر کرتی ہیں۔ میرے خیال میں یہ دلچسپ ہوگا۔
پہلا سوال یہ ہے: "آپ کو کلک ہاؤس کی ضرورت کیوں ہے؟" ایسا لگتا ہے کہ سوال بالکل واضح ہے، لیکن اس کے ایک سے زیادہ جوابات ہیں۔
- پہلا جواب کارکردگی کی وجوہات کے لیے ہے۔ کلک ہاؤس بہت تیز ہے۔ کلک ہاؤس پر تجزیات بھی بہت تیز ہیں۔ اسے اکثر استعمال کیا جا سکتا ہے جہاں کوئی اور چیز بہت آہستہ یا بہت خراب کام کر رہی ہو۔
- دوسرا جواب لاگت ہے۔ اور سب سے پہلے، اسکیلنگ کی لاگت. مثال کے طور پر، Vertica ایک بالکل بہترین ڈیٹا بیس ہے۔ اگر آپ کے پاس بہت زیادہ ٹیرا بائٹس ڈیٹا نہیں ہے تو یہ بہت اچھا کام کرتا ہے۔ لیکن جب ہم سینکڑوں ٹیرا بائٹس یا پیٹا بائٹس کے بارے میں بات کر رہے ہیں، تو لائسنس اور سپورٹ کی قیمت کافی حد تک اہم ہے۔ اور یہ مہنگا ہے۔ اور کلک ہاؤس مفت ہے۔
- تیسرا جواب آپریٹنگ لاگت ہے۔ یہ قدرے مختلف انداز ہے۔ RedShift ایک بہترین ینالاگ ہے۔ RedShift کے ساتھ آپ بہت جلد فیصلہ کر سکتے ہیں۔ یہ اچھی طرح سے کام کرے گا، لیکن ایک ہی وقت میں، ہر گھنٹے، ہر دن اور ہر مہینے آپ ایمیزون کو بہت زیادہ ادائیگی کریں گے، کیونکہ یہ ایک خاصی مہنگی سروس ہے۔ Google BigQuery بھی۔ اگر کسی نے اسے استعمال کیا ہے، تو وہ جانتا ہے کہ آپ وہاں کئی سوالات چلا سکتے ہیں اور اچانک سینکڑوں ڈالر کی رسید وصول کر سکتے ہیں۔
کلک ہاؤس میں یہ مسائل نہیں ہیں۔
کلک ہاؤس اب کہاں استعمال ہوتا ہے؟ Yandex کے علاوہ، ClickHouse مختلف کاروباروں اور کمپنیوں کے ایک گروپ میں استعمال ہوتا ہے۔
- سب سے پہلے، یہ ویب ایپلیکیشن اینالیٹکس ہے، یعنی یہ ایک استعمال کیس ہے جو Yandex سے آیا ہے۔
- کئی AdTech کمپنیاں ClickHouse استعمال کرتی ہیں۔
- متعدد کمپنیاں جنہیں مختلف ذرائع سے آپریشنل لاگز کا تجزیہ کرنے کی ضرورت ہے۔
- کئی کمپنیاں سیکیورٹی لاگز کی نگرانی کے لیے کلک ہاؤس کا استعمال کرتی ہیں۔ وہ انہیں کلک ہاؤس پر اپ لوڈ کرتے ہیں، رپورٹیں بناتے ہیں، اور مطلوبہ نتائج حاصل کرتے ہیں۔
- کمپنیاں اسے مالیاتی تجزیہ میں استعمال کرنا شروع کر رہی ہیں، یعنی آہستہ آہستہ بڑے کاروبار بھی ClickHouse کے قریب آ رہے ہیں۔
- کلاؤڈ فلیئر۔ اگر کوئی کلک ہاؤس کی پیروی کرتا ہے، تو آپ نے شاید اس کمپنی کا نام سنا ہوگا۔ یہ کمیونٹی کے اہم شراکت داروں میں سے ایک ہے۔ اور ان کے پاس کلک ہاؤس کی بہت سنجیدہ تنصیب ہے۔ مثال کے طور پر، انہوں نے کلک ہاؤس کے لیے کافکا انجن بنایا۔
- ٹیلی کمیونیکیشن کمپنیوں نے استعمال کرنا شروع کر دیا ہے۔ کئی کمپنیاں ClickHouse کو یا تو تصور کے ثبوت کے طور پر استعمال کرتی ہیں یا پہلے سے پروڈکشن میں ہیں۔
- ایک کمپنی پروڈکشن کے عمل کی نگرانی کے لیے کلک ہاؤس کا استعمال کرتی ہے۔ وہ مائکرو سرکٹس کی جانچ کرتے ہیں، پیرامیٹرز کا ایک گروپ لکھتے ہیں، تقریبا 2،000 خصوصیات ہیں. اور پھر وہ تجزیہ کرتے ہیں کہ بیچ اچھا ہے یا برا۔
- بلاکچین تجزیات۔ ایک روسی کمپنی ہے جسے Bloxy.info کہتے ہیں۔ یہ Ethereum نیٹ ورک کا تجزیہ ہے۔ انہوں نے یہ کلک ہاؤس پر بھی کیا۔
اس کے علاوہ، سائز کوئی فرق نہیں پڑتا. بہت سی کمپنیاں ہیں جو ایک چھوٹا سرور استعمال کرتی ہیں۔ اور وہ انہیں اپنے مسائل حل کرنے کی اجازت دیتا ہے۔ اور اس سے بھی زیادہ کمپنیاں بہت سے سرورز یا درجنوں سرورز کے بڑے کلسٹرز کا استعمال کرتی ہیں۔
اور اگر آپ ریکارڈ دیکھیں تو:
- Yandex: 500+ سرورز، وہ وہاں ایک دن میں 25 بلین ریکارڈ اسٹور کرتے ہیں۔
- لائف اسٹریٹ: 60 سرورز، تقریباً 75 بلین ریکارڈز فی دن۔ Yandex کی نسبت کم سرورز اور زیادہ ریکارڈز ہیں۔
- CloudFlare: 36 سرورز، وہ روزانہ 200 بلین ریکارڈ محفوظ کرتے ہیں۔ ان کے پاس اس سے بھی کم سرورز ہیں اور اس سے بھی زیادہ ڈیٹا اسٹور کرتے ہیں۔
- بلومبرگ: 102 سرورز، تقریباً ایک ٹریلین ریکارڈز فی دن۔ ریکارڈ ہولڈر۔
جغرافیائی طور پر، یہ بھی بہت ہے. یہ نقشہ ہیٹ میپ دکھاتا ہے جہاں کلک ہاؤس دنیا میں استعمال ہوتا ہے۔ یہاں روس، چین اور امریکہ واضح طور پر کھڑے ہیں۔ چند یورپی ممالک ہیں۔ اور 4 کلسٹرز کو پہچانا جا سکتا ہے۔
یہ ایک تقابلی تجزیہ ہے، مطلق اعداد تلاش کرنے کی ضرورت نہیں۔ یہ ان زائرین کا تجزیہ ہے جو Altinity ویب سائٹ پر انگریزی زبان کا مواد پڑھتے ہیں، کیونکہ وہاں کوئی روسی بولنے والا نہیں ہے۔ اور روس، یوکرین، بیلاروس، یعنی کمیونٹی کا روسی بولنے والا حصہ، سب سے زیادہ صارفین ہیں۔ اس کے بعد امریکہ اور کینیڈا آتا ہے۔ چین بہت زیادہ پکڑ رہا ہے۔ چھ ماہ پہلے وہاں تقریباً کوئی چین نہیں تھا؛ اب چین پہلے ہی یورپ کو پیچھے چھوڑ چکا ہے اور ترقی جاری رکھے ہوئے ہے۔ پرانا یورپ بھی پیچھے نہیں ہے، اور ClickHouse کے استعمال میں سب سے آگے فرانس ہے، عجیب بات ہے۔
میں یہ سب کیوں بتا رہا ہوں؟ یہ ظاہر کرنے کے لیے کہ ClickHouse بڑے ڈیٹا کے تجزیہ کے لیے ایک معیاری حل بنتا جا رہا ہے اور پہلے ہی کئی جگہوں پر استعمال ہو چکا ہے۔ اگر آپ اسے استعمال کرتے ہیں، تو آپ صحیح رجحان پر ہیں۔ اگر آپ اسے ابھی تک استعمال نہیں کرتے ہیں، تو آپ کو ڈرنے کی ضرورت نہیں کہ آپ اکیلے رہ جائیں گے اور کوئی آپ کی مدد نہیں کرے گا، کیونکہ بہت سے لوگ پہلے ہی یہ کام کر رہے ہیں۔
یہ کئی کمپنیوں میں ClickHouse کے حقیقی استعمال کی مثالیں ہیں۔
- پہلی مثال ایک اشتہاری نیٹ ورک ہے: ورٹیکا سے کلک ہاؤس کی طرف ہجرت۔ اور میں کئی کمپنیوں کو جانتا ہوں جنہوں نے ورٹیکا سے سوئچ کیا ہے یا سوئچ کرنے کے عمل میں ہیں۔
- دوسری مثال ClickHouse پر ٹرانزیکشنل اسٹوریج ہے۔ یہ اینٹی پیٹرن پر بنی ایک مثال ہے۔ ہر وہ کام جو کلک ہاؤس میں کرنے کی ضرورت نہیں ہے ڈویلپرز کے مشورے کے مطابق یہاں کیا جاتا ہے۔ اور ایک ہی وقت میں یہ اتنا مؤثر طریقے سے کیا جاتا ہے کہ یہ کام کرتا ہے. اور یہ ایک عام لین دین کے حل سے بہت بہتر کام کرتا ہے۔
- تیسری مثال ClickHouse پر تقسیم شدہ کمپیوٹنگ ہے۔ اس بارے میں ایک سوال تھا کہ ClickHouse کو Hadoop ماحولیاتی نظام میں کیسے ضم کیا جا سکتا ہے۔ میں ایک مثال دکھاؤں گا کہ کس طرح ایک کمپنی نے ClickHouse پر نقشہ کم کرنے والے کنٹینر کی طرح کچھ کیا، ڈیٹا لوکلائزیشن کی نگرانی وغیرہ، ایک انتہائی غیر معمولی کام کا حساب لگانے کے لیے۔
- لائف اسٹریٹ ایک ایڈ ٹیک کمپنی ہے جس میں اشتہاری نیٹ ورک سے وابستہ تمام ٹیکنالوجیز ہیں۔
- وہ اشتہار کی اصلاح اور پروگرامی بولی لگانے میں مصروف ہے۔
- بہت سا ڈیٹا: تقریباً 10 بلین واقعات فی دن۔ مزید یہ کہ واقعات کو کئی ذیلی واقعات میں تقسیم کیا جا سکتا ہے۔
- اس ڈیٹا کے بہت سے کلائنٹس ہیں، اور یہ صرف لوگ ہی نہیں ہیں، اور بہت سے مختلف الگورتھم ہیں جو پروگرامی بولی میں مشغول ہیں۔
کمپنی نے ایک طویل اور کانٹے دار راستہ طے کیا ہے۔ اور میں نے اس کے بارے میں ہائی لوڈ پر بات کی۔ سب سے پہلے، لائف اسٹریٹ MySQL سے (Oracle پر ایک مختصر اسٹاپ کے ساتھ) Vertica میں منتقل ہوئی۔ اور آپ کو اس کے بارے میں ایک کہانی مل سکتی ہے۔
اور سب کچھ بہت اچھا تھا، لیکن یہ تیزی سے واضح ہو گیا کہ ڈیٹا بڑھ رہا تھا اور ورٹیکا مہنگا تھا۔ اس لیے مختلف متبادل تلاش کیے گئے۔ ان میں سے کچھ یہاں درج ہیں۔ اور درحقیقت، ہم نے تصور کا ثبوت یا بعض اوقات تقریباً تمام ڈیٹا بیسز کی کارکردگی کی جانچ کی جو 13 سے 16 تک مارکیٹ میں دستیاب تھے اور فعالیت میں تقریباً موزوں تھے۔ اور میں نے ہائی لوڈ پر ان میں سے کچھ کے بارے میں بھی بات کی۔
کام پہلے ورٹیکا سے ہجرت کرنا تھا، کیونکہ ڈیٹا بڑھ رہا تھا۔ اور وہ کئی سالوں تک تیزی سے بڑھتے گئے۔ پھر وہ شیلف پر چلے گئے، لیکن پھر بھی۔ اور اس ترقی کی پیشن گوئی، اعداد و شمار کے حجم کے لئے کاروباری ضروریات جس پر کسی قسم کے تجزیات کرنے کی ضرورت ہے، یہ واضح تھا کہ جلد ہی پیٹا بائٹس کے بارے میں بات کی جائے گی. اور پیٹا بائٹس کی ادائیگی کرنا پہلے ہی بہت مہنگا ہے، اس لیے ہم ایک متبادل تلاش کر رہے تھے کہ کہاں جانا ہے۔
کہاں جانا؟ اور ایک طویل عرصے سے یہ مکمل طور پر واضح نہیں تھا کہ کہاں جانا ہے، کیونکہ ایک طرف تجارتی ڈیٹا بیس ہیں، وہ اچھی طرح سے کام کرتے نظر آتے ہیں۔ کچھ تقریباً ورٹیکا کے ساتھ ساتھ کام کرتے ہیں، کچھ بدتر۔ لیکن وہ سب مہنگے ہیں، اس سے سستا یا بہتر کچھ نہیں مل سکتا۔
دوسری طرف، اوپن سورس حل ہیں، جن میں سے بہت زیادہ نہیں ہیں، یعنی تجزیات کے لیے ایک طرف ان کا شمار کیا جا سکتا ہے۔ اور وہ مفت یا سستے ہیں، لیکن وہ آہستہ آہستہ کام کرتے ہیں۔ اور ان میں اکثر ضروری اور مفید فعالیت کی کمی ہوتی ہے۔
اور تجارتی ڈیٹا بیس میں موجود اچھی چیزوں اور اوپن سورس میں موجود تمام مفت چیزوں کو یکجا کرنے کے لیے کچھ بھی نہیں تھا۔
کچھ بھی نہیں ہوا جب تک کہ Yandex نے اچانک ClickHouse کو جادوگر کے خرگوش کی طرح ٹوپی سے باہر نہ نکالا۔ اور یہ ایک غیر متوقع فیصلہ تھا؛ لوگ اب بھی سوال پوچھتے ہیں: "کیوں؟"، لیکن اس کے باوجود۔
اور فوراً ہی 2016 کے موسم گرما میں، ہم نے یہ دیکھنا شروع کیا کہ ClickHouse کیا ہے۔ اور یہ پتہ چلا کہ یہ کبھی کبھی ورٹیکا سے بھی تیز ہو سکتا ہے۔ ہم نے مختلف درخواستوں پر مختلف منظرناموں کا تجربہ کیا۔ اور اگر استفسار میں صرف ایک ٹیبل استعمال کیا گیا، یعنی بغیر کسی جوڑ کے، تو کلک ہاؤس ورٹیکا سے دوگنا تیز تھا۔
میں زیادہ سست نہیں تھا اور دوسرے دن مزید Yandex ٹیسٹ دیکھتا تھا۔ وہاں بھی ایسا ہی ہے: ClickHouse Vertica سے دوگنا تیز ہے، اس لیے وہ اکثر اس کے بارے میں بات کرتے ہیں۔
لیکن اگر سوالات میں جوائن ہوتا ہے تو پھر سب کچھ واضح نہیں ہوتا۔ اور کلک ہاؤس ورٹیکا سے دوگنا سست ہو سکتا ہے۔ اور اگر آپ درخواست کو تھوڑا درست کر کے دوبارہ لکھیں گے تو وہ تقریباً برابر ہو جائیں گے۔ برا نہیں ہے. اور یہ مفت ہے۔
اور ٹیسٹ کے نتائج حاصل کرنے کے بعد، اور اسے مختلف زاویوں سے دیکھنے کے بعد، لائف اسٹریٹ کلک ہاؤس چلا گیا۔
یہ 16 واں سال ہے، میں آپ کو یاد دلاتا ہوں۔ یہ ان چوہوں کے بارے میں مذاق کی طرح تھا جو رو کر اپنے آپ کو انجیکشن لگاتے تھے، لیکن کیکٹس کھاتے رہے۔ اور اس پر تفصیلی گفتگو ہوئی، اس بارے میں ایک ویڈیو بھی موجود ہے۔
اس لیے میں اس پر تفصیل سے بات نہیں کروں گا، میں صرف ان نتائج اور چند دلچسپ چیزوں کے بارے میں بات کروں گا جن کے بارے میں میں نے تب بات نہیں کی۔
نتائج یہ ہیں:
- کامیاب منتقلی اور نظام ایک سال سے زیادہ عرصے سے پیداوار میں ہے۔
- پیداواری صلاحیت اور لچک میں اضافہ ہوا ہے۔ 10 بلین ریکارڈز میں سے جسے ہم صرف ایک مختصر مدت کے لیے فی دن اسٹور کرنے کے متحمل ہوسکتے ہیں، LifeStreet اب 75 بلین ریکارڈز فی دن اسٹور کرتی ہے اور 3 ماہ یا اس سے زیادہ کے لیے ایسا کرسکتی ہے۔ اگر آپ چوٹی پر شمار کرتے ہیں، تو یہ فی سیکنڈ ایک ملین واقعات تک محفوظ ہوتا ہے۔ اس سسٹم کو روزانہ دس لاکھ سے زیادہ SQL سوالات بھیجے جاتے ہیں، زیادہ تر مختلف روبوٹس سے۔
- اس حقیقت کے باوجود کہ کلک ہاؤس نے ورٹیکا سے زیادہ سرورز استعمال کرنا شروع کیے، ہارڈ ویئر پر بھی بچت کی گئی، کیونکہ ورٹیکا نے کافی مہنگی SAS ڈسکیں استعمال کیں۔ کلک ہاؤس نے SATA استعمال کیا۔ اور کیوں؟ کیونکہ Vertica میں insert synchronous ہوتا ہے۔ اور مطابقت پذیری کا تقاضا ہے کہ ڈسکیں بہت زیادہ سست نہ ہوں، اور یہ بھی کہ نیٹ ورک بہت زیادہ سست نہ ہو، یعنی ایک مہنگا آپریشن۔ اور ClickHouse میں insert asynchronous ہے۔ مزید یہ کہ، آپ ہمیشہ مقامی طور پر ہر چیز لکھ سکتے ہیں، اس کے لیے کوئی اضافی لاگت نہیں ہے، لہذا ڈیٹا کو کلک ہاؤس میں ورٹیکا کے مقابلے میں بہت تیزی سے داخل کیا جا سکتا ہے، یہاں تک کہ تیز ترین ڈسکوں پر بھی نہیں۔ اور پڑھنا بھی ایسا ہی ہے۔ SATA پر پڑھنا، اگر وہ RAID میں ہیں، تو یہ سب کافی تیز ہے۔
- لائسنس کے ذریعے لامحدود، یعنی 3 سرورز میں 60 پیٹا بائٹس ڈیٹا (20 سرورز ایک نقل ہیں) اور حقائق اور مجموعوں میں 6 ٹریلین ریکارڈ۔ ورٹیکا ایسا کچھ بھی برداشت نہیں کر سکتا تھا۔
اب میں اس مثال میں عملی چیزوں کی طرف جا رہا ہوں۔
- پہلی ایک موثر اسکیم ہے۔ اسکیم پر بہت کچھ منحصر ہے۔
- دوسرا موثر ایس کیو ایل تیار کر رہا ہے۔
ایک عام OLAP استفسار منتخب کیا جاتا ہے۔ کچھ کالم گروپ کے لحاظ سے جاتے ہیں، کچھ کالم مجموعی افعال میں جاتے ہیں۔ وہاں ہے جہاں، جس کے بارے میں مکعب کا ایک ٹکڑا سمجھا جا سکتا ہے۔ پورے گروپ کو ایک پروجیکشن کے طور پر سوچا جا سکتا ہے۔ اور اسی لیے اسے ملٹی ویریٹیٹ ڈیٹا اینالیسس کہا جاتا ہے۔
اور اکثر یہ ستارے کے خاکے کی شکل میں وضع کیا جاتا ہے، جب شعاعوں کے ساتھ ساتھ اطراف میں اس حقیقت کی مرکزی حقیقت اور خصوصیات موجود ہوتی ہیں۔
اور جسمانی ڈیزائن کے نقطہ نظر سے، یہ میز پر کس طرح فٹ بیٹھتا ہے، وہ عام طور پر ایک معمول کی نمائندگی کرتے ہیں۔ آپ غیر معمولی کر سکتے ہیں، لیکن یہ ڈسک پر مہنگا ہے اور سوالات پر زیادہ موثر نہیں ہے۔ لہذا، وہ عام طور پر ایک عام نظریہ بناتے ہیں، یعنی حقیقت کی میز اور بہت سی، بہت سی ڈائمینشن ٹیبل۔
لیکن یہ ClickHouse میں اچھی طرح سے کام نہیں کرتا ہے۔ اس کی دو وجوہات ہیں:
- پہلی وجہ یہ ہے کہ کلک ہاؤس میں بہت اچھے جوائن نہیں ہوتے ہیں، یعنی جوائنز ہیں، لیکن وہ خراب ہیں۔ اب تک وہ خراب ہیں۔
- دوسرا یہ کہ میزیں اپ ڈیٹ نہیں ہوتیں۔ عام طور پر ان نشانیوں میں جو ستارے کے خاکے کے ارد گرد ہوتے ہیں، کچھ تبدیل کرنے کی ضرورت ہوتی ہے۔ مثال کے طور پر، کلائنٹ کا نام، کمپنی کا نام، وغیرہ۔ اور یہ کام نہیں کرتا۔
اور کلک ہاؤس میں اس سے باہر نکلنے کا ایک طریقہ ہے۔ یہاں تک کہ دو:
- پہلی لغت کا استعمال ہے۔ ایکسٹرنل ڈکشنریز وہ ہے جو اپ ڈیٹس وغیرہ کے ساتھ اسٹار اسکیم کے مسئلے کو حل کرنے میں 99% کی مدد کرتی ہے۔
- دوسرا arrays کا استعمال ہے۔ صفوں سے جوائن اور نارملائزیشن کے مسائل سے چھٹکارا حاصل کرنے میں بھی مدد ملتی ہے۔
- شمولیت کی ضرورت نہیں۔
- قابل اپ ڈیٹ۔ مارچ 2018 کے بعد سے، لغت کو جزوی طور پر اپ ڈیٹ کرنے کا ایک غیر دستاویزی موقع ظاہر ہوا ہے (یہ آپ کو دستاویزات میں نہیں ملے گا، یعنی وہ اندراجات جو تبدیل ہو چکی ہیں۔ عملی طور پر، یہ ایک میز کی طرح ہے.
- ہمیشہ میموری میں، لہذا لغت کے ساتھ تیزی سے کام کرتا ہے اگر یہ ایک ٹیبل ہوتا جو ڈسک پر ہوتا ہے اور یہ حقیقت نہیں ہے کہ یہ کیشے میں ہے، زیادہ تر امکان نہیں ہے۔
- آپ کو شمولیت کی بھی ضرورت نہیں ہے۔
- یہ بہت ساری نمائندگی کے لیے ایک کمپیکٹ 1 ہے۔
- اور میری رائے میں، صفیں گیکس کے لیے بنائی گئی ہیں۔ یہ لیمبڈا کے افعال اور چیزیں ہیں۔
یہ الفاظ کی خاطر نہیں ہے۔ یہ ایک بہت ہی طاقتور فعالیت ہے جو آپ کو بہت سی چیزیں بہت آسان اور خوبصورتی سے کرنے کی اجازت دیتی ہے۔
مخصوص مثالیں جو صفوں کو حل کرنے میں مدد کرتی ہیں۔ یہ مثالیں سادہ اور بالکل واضح ہیں:
- ٹیگز کے ذریعے تلاش کریں۔ اگر آپ کے پاس وہاں ہیش ٹیگ ہیں اور آپ ہیش ٹیگ کے ذریعے کچھ پوسٹس تلاش کرنا چاہتے ہیں۔
- کلیدی قدر کے جوڑوں کے ذریعہ تلاش کریں۔ معنی کے ساتھ کچھ صفات بھی ہیں۔
- ان کلیدوں کی فہرستیں ذخیرہ کرنا جن کا آپ کو کسی اور چیز میں ترجمہ کرنے کی ضرورت ہے۔
یہ تمام مسائل صفوں کے بغیر حل ہو سکتے ہیں۔ ٹیگز کو کچھ لائن میں رکھا جا سکتا ہے اور ریگولر ایکسپریشن کا استعمال کرتے ہوئے منتخب کیا جا سکتا ہے، یا ایک علیحدہ ٹیبل میں، لیکن پھر آپ کو جوائن کرنا پڑے گا۔
لیکن کلک ہاؤس میں آپ کو کچھ کرنے کی ضرورت نہیں ہے، صرف ہیش ٹیگز کے لیے سٹرنگ اری کی وضاحت کریں یا کلیدی قدر کے نظام کے لیے ایک نیسٹڈ ڈھانچہ بنائیں۔
گھریلو ڈھانچہ بہترین نام نہیں ہوسکتا ہے۔ یہ دو صفیں ہیں جن کا نام میں ایک مشترکہ حصہ اور کچھ متعلقہ خصوصیات ہیں۔
اور ٹیگ کے ذریعے تلاش کرنا بہت آسان ہے۔ ایک فنکشن ہے۔ has، جو چیک کرتا ہے کہ صف میں ایک عنصر موجود ہے۔ ہر کوئی، ہمیں وہ تمام اندراجات مل گئے جو ہماری کانفرنس سے متعلق ہیں۔
سبڈ کے ذریعہ تلاش کرنا تھوڑا زیادہ پیچیدہ ہے۔ ہمیں پہلے کلید کا اشاریہ تلاش کرنے کی ضرورت ہے، اور پھر عنصر کو اس اشاریہ کے ساتھ لیں اور چیک کریں کہ یہ قدر وہی ہے جس کی ہمیں ضرورت ہے۔ لیکن اس کے باوجود بہت سادہ اور کمپیکٹ۔
باقاعدہ اظہار جو آپ لکھنا چاہیں گے، اگر آپ یہ سب ایک لائن میں محفوظ کرتے ہیں، تو یہ سب سے پہلے اناڑی ہوگا۔ اور، دوسرا، اس نے دو صفوں سے کہیں زیادہ کام کیا۔
ایک اور مثال. آپ کے پاس ایک صف ہے جس میں آپ IDs اسٹور کرتے ہیں۔ اور آپ ان کا ترجمہ ناموں میں کر سکتے ہیں۔ فنکشن arrayMap. یہ ایک عام لیمبڈا فنکشن ہے۔ آپ وہاں لیمبڈا ایکسپریشن پاس کرتے ہیں۔ اور وہ ڈکشنری سے ہر ID کے لیے نام کی قدر نکالتی ہے۔
آپ اسی طرح تلاش کر سکتے ہیں۔ ایک predicate فنکشن پاس کیا جاتا ہے، جو چیک کرتا ہے کہ عناصر کیا مماثل ہیں۔
یہ چیزیں سرکٹ کو بہت آسان بناتی ہیں اور مسائل کا ایک گروپ حل کرتی ہیں۔
لیکن اگلا مسئلہ جس کا ہم نے سامنا کیا اور جس کا میں ذکر کرنا چاہوں گا وہ ہے موثر سوالات۔
- کلک ہاؤس کے پاس استفسار کا منصوبہ ساز نہیں ہے۔ بالکل نہیں.
- لیکن اس کے باوجود، پیچیدہ سوالات کو ابھی بھی منصوبہ بندی کرنے کی ضرورت ہے۔ کن صورتوں میں؟
- اگر درخواست میں کئی جوائنز ہیں، جنہیں آپ ذیلی انتخاب میں لپیٹتے ہیں۔ اور جس ترتیب سے ان کو انجام دیا جاتا ہے اہمیت رکھتا ہے۔
- اور دوسری بات یہ کہ اگر درخواست تقسیم ہو جائے۔ کیونکہ تقسیم شدہ استفسار میں، صرف سب سے اندرونی ذیلی انتخاب کو تقسیم شدہ طریقے سے عمل میں لایا جاتا ہے، اور باقی سب کچھ اس سرور کو بھیج دیا جاتا ہے جس سے آپ نے منسلک کیا اور وہاں پر عمل درآمد کیا ہے۔ لہذا، اگر آپ نے بہت سے جوائنز کے ساتھ سوالات تقسیم کیے ہیں، تو آپ کو آرڈر کا انتخاب کرنے کی ضرورت ہے۔
اور یہاں تک کہ آسان معاملات میں، بعض اوقات آپ کو شیڈولر کا کام بھی کرنا پڑتا ہے اور سوالات کو تھوڑا سا دوبارہ لکھنا پڑتا ہے۔
یہاں ایک مثال ہے۔ بائیں جانب ایک سوال ہے جو سرفہرست 5 ممالک کو دکھاتا ہے۔ اور یہ 2,5 سیکنڈ میں چلتا ہے، میرے خیال میں۔ اور دائیں طرف وہی درخواست ہے، لیکن قدرے دوبارہ لکھی ہوئی ہے۔ سٹرنگ کے ذریعہ گروپ بندی کے بجائے، ہم نے کلید (int) کے ذریعہ گروپ بندی شروع کردی۔ اور یہ تیز تر ہے۔ اور پھر ہم نے ایک لغت کو نتیجہ سے منسلک کیا۔ 2,5 سیکنڈ کے بجائے، درخواست میں 1,5 سیکنڈ لگتے ہیں۔ یہ اچھا ہے.
دوبارہ لکھنے والے فلٹرز کے ساتھ اسی طرح کی مثال۔ یہاں روس کے لیے ایک درخواست ہے۔ یہ 5 سیکنڈ تک چلتا ہے۔ اگر ہم اسے دوبارہ اس طرح سے لکھیں کہ ہم پھر سے کسی تار کا نہیں بلکہ نمبروں کا موازنہ ان کلیدوں کے کچھ سیٹ سے کریں جو روس سے تعلق رکھتی ہیں، تو یہ بہت تیز ہوگا۔
ایسی بہت سی چالیں ہیں۔ اور وہ آپ کو ان سوالات کو نمایاں طور پر تیز کرنے کی اجازت دیتے ہیں جو آپ کے خیال میں پہلے ہی تیزی سے چل رہے ہیں، یا اس کے برعکس، آہستہ چل رہے ہیں۔ انہیں اور بھی تیز بنایا جا سکتا ہے۔
- تقسیم شدہ موڈ میں زیادہ سے زیادہ کام۔
- کم سے کم اقسام کے لحاظ سے چھانٹنا، جیسا کہ میں نے ints کے ذریعے کیا تھا۔
- اگر کوئی جوائنز یا ڈکشنریز ہیں تو بہتر ہے کہ ان کو آخری بار کریں، جب آپ کے پاس ڈیٹا پہلے سے ہی کم از کم جزوی طور پر گروپ ہو جائے تو جوائن آپریشن یا لغت کو کال کرنے کو کم بار کہا جائے گا اور یہ تیز تر ہوگا۔
- فلٹرز کو تبدیل کرنا۔
اور بھی تکنیکیں ہیں، نہ صرف وہی جن کا میں نے مظاہرہ کیا۔ اور یہ سب بعض اوقات آپ کو سوالات پر عمل درآمد کو نمایاں طور پر تیز کرنے کی اجازت دیتے ہیں۔
آئیے اگلی مثال کی طرف چلتے ہیں۔ امریکہ سے کمپنی X۔ وہ کیا کر رہی ہے؟
ایک کام تھا:
- اشتہاری لین دین کی آف لائن لنکنگ۔
- مختلف بائنڈنگ ماڈلز کا تخروپن۔
کیا منظر نامہ ہے؟
ایک عام سیاح سائٹ پر جاتا ہے، مثال کے طور پر، مختلف اشتہارات سے مہینے میں 20 بار، یا کبھی کبھی وہ بغیر کسی اشتہار کے آتا ہے، کیونکہ اسے یہ سائٹ یاد ہے۔ کچھ مصنوعات کو دیکھتا ہے، انہیں ٹوکری میں رکھتا ہے، انہیں ٹوکری سے باہر لے جاتا ہے. اور، آخر میں، وہ کچھ خریدتا ہے.
معقول سوالات: "اگر ضروری ہو تو اشتہارات کے لیے کس کو ادائیگی کرنی چاہیے؟" اور "کس اشتہارات نے، اگر کوئی ہے، اسے متاثر کیا؟" یعنی اس نے کیوں خریدا اور اس بات کو کیسے یقینی بنایا کہ اس شخص سے ملتے جلتے لوگ بھی خریدیں؟
اس مسئلے کو حل کرنے کے لیے، آپ کو ویب سائٹ پر پیش آنے والے واقعات کو صحیح طریقے سے جوڑنے کی ضرورت ہے، یعنی کسی طرح ان کے درمیان رابطہ قائم کرنا چاہیے۔ پھر انہیں تجزیہ کے لیے ڈی ڈبلیو ایچ میں منتقل کر دیا جاتا ہے۔ اور اس تجزیے کی بنیاد پر، اس کے ماڈل بنائیں کہ کون کون سا اشتہار دکھانا ہے۔
اشتہاری لین دین متعلقہ صارف کے واقعات کا ایک مجموعہ ہے جو اشتہار دکھائے جانے سے شروع ہوتا ہے، پھر کچھ ہوتا ہے، پھر شاید خریداری، اور پھر خریداری کے اندر خریداری ہوسکتی ہے۔ مثال کے طور پر، اگر یہ موبائل ایپلی کیشن یا موبائل گیم ہے، تو عام طور پر ایپلی کیشن کو انسٹال کرنا مفت ہے، لیکن اگر وہاں کچھ اور کیا جاتا ہے، تو اس کے لیے پیسے کی ضرورت پڑ سکتی ہے۔ اور ایک شخص ایپ میں جتنا زیادہ خرچ کرتا ہے، یہ اتنا ہی زیادہ قیمتی ہوتا ہے۔ لیکن اس کے لیے آپ کو ہر چیز کو جوڑنے کی ضرورت ہے۔
بہت سے پابند ماڈل ہیں.
سب سے زیادہ مقبول ہیں:
- آخری تعامل، جہاں تعامل یا تو کلک یا تاثر ہے۔
- پہلا تعامل، یعنی پہلی چیز جو کسی شخص کو سائٹ پر لے آئی۔
- لکیری امتزاج - سب کے لیے برابر حصہ داری۔
- توجہ
- اور اسی طرح.
اور یہ سب شروع میں کیسے کام کرتا تھا؟ رن ٹائم اور کیسینڈرا تھا۔ کیسینڈرا کو لین دین کے ذخیرہ کے طور پر استعمال کیا گیا تھا، یعنی تمام متعلقہ لین دین اس میں محفوظ تھے۔ اور جب رن ٹائم میں کوئی واقعہ پیش آتا ہے، مثال کے طور پر، کسی صفحہ کا ڈسپلے یا کوئی اور چیز، کیسینڈرا سے درخواست کی جاتی ہے کہ آیا کوئی ایسا شخص ہے یا نہیں۔ پھر اس سے متعلق لین دین موصول ہوا۔ اور بائنڈنگ ہو گئی۔
اور اگر آپ خوش قسمت ہیں کہ درخواست میں ٹرانزیکشن آئی ڈی ہے، تو یہ آسان ہے۔ لیکن عام طور پر آپ کی قسمت نہیں ہوتی ہے۔ اس لیے آخری لین دین یا آخری کلک کے ساتھ لین دین کا پتہ لگانا ضروری تھا۔
اور یہ سب بہت اچھی طرح سے کام کرتا تھا جب تک کہ لنکنگ آخری کلک تک نہ ہو۔ کیونکہ اگر آپ ایک مہینے کے لیے ونڈو سیٹ کرتے ہیں تو، 10 ملین کلکس فی دن، 300 ملین فی مہینہ ہوتے ہیں۔ اور چونکہ کیسینڈرا میں تیزی سے کام کرنے کے لیے یہ سب کچھ میموری میں ہونا ضروری ہے، کیونکہ رن ٹائم کو فوری جواب دینے کی ضرورت ہوتی ہے، اس لیے تقریباً 10-15 سرورز درکار تھے۔
اور جب وہ کسی لین دین کو ڈسپلے سے جوڑنا چاہتے تھے تو یہ فوراً اتنا مزہ نہیں نکلا۔ اور کیوں؟ یہ دیکھا جا سکتا ہے کہ 30 گنا زیادہ واقعات کو ذخیرہ کرنے کی ضرورت ہے۔ اور، اس کے مطابق، آپ کو 30 گنا زیادہ سرورز کی ضرورت ہے۔ اور پتہ چلتا ہے کہ یہ کسی قسم کی فلکیاتی شخصیت ہے۔ اس حقیقت کے باوجود کہ رن ٹائم میں نمایاں طور پر کم سرورز موجود ہیں، لنکنگ کرنے کے لیے 500 سرورز تک رکھنا ایک قسم کا غلط اعداد و شمار ہے۔ اور سوچنے لگے کہ کیا کیا جائے۔
اور ہم کلک ہاؤس گئے۔ ClickHouse پر یہ کیسے کریں؟ پہلی نظر میں ایسا لگتا ہے کہ یہ اینٹی پیٹرن کا ایک سیٹ ہے۔
- لین دین بڑھ رہا ہے، ہم اس کے ساتھ زیادہ سے زیادہ واقعات منسلک کر رہے ہیں، یعنی یہ متغیر ہے، اور ClickHouse متغیر اشیاء کے ساتھ بہت اچھا کام نہیں کرتا ہے۔
- جب کوئی وزیٹر ہمارے پاس آتا ہے، تو ہمیں اس کے لین دین کو کلید کے ذریعے، اس کے وزٹ آئی ڈی کے ذریعے بازیافت کرنے کی ضرورت ہوتی ہے۔ یہ بھی ایک نقطہ سوال ہے؛ ClickHouse ایسا نہیں کرتا ہے۔ عام طور پر کلک ہاؤس میں بڑے… اسکینز ہوتے ہیں، لیکن یہاں ہمیں کئی ریکارڈز حاصل کرنے کی ضرورت ہے۔ ایک اینٹی پیٹرن بھی۔
- اس کے علاوہ، لین دین json میں تھا، لیکن وہ اسے دوبارہ نہیں لکھنا چاہتے تھے، اس لیے وہ json کو غیر ساختہ ذخیرہ کرنا چاہتے تھے، اور اگر ضروری ہو تو اس میں سے کچھ نکال لیں۔ اور یہ بھی ایک اینٹی پیٹرن ہے۔
یعنی اینٹی پیٹرنز کا ایک سیٹ۔
لیکن اس کے باوجود، ہم ایک ایسا نظام بنانے میں کامیاب ہوئے جس نے بہت اچھا کام کیا۔
کیا کیا گیا؟ کلک ہاؤس نمودار ہوا، جس میں نوشتہ جات، ریکارڈز میں تقسیم کیے گئے، پھینکے گئے۔ ایک منسوب سروس نمودار ہوئی جسے کلک ہاؤس سے لاگ موصول ہوئے تھے۔ اس کے بعد، وزٹ آئی ڈی کے ذریعے ہر اندراج کے لیے، مجھے ایسی ٹرانزیکشنز موصول ہوئیں جن پر ابھی تک کارروائی نہیں ہوئی تھی اور اس کے علاوہ اسنیپ شاٹس، یعنی پہلے سے منسلک لین دین، یعنی پچھلے کام کا نتیجہ۔ میں نے پہلے ہی ان میں سے منطق بنا لی ہے، صحیح لین دین کا انتخاب کیا ہے، اور نئے واقعات کو منسلک کیا ہے۔ دوبارہ لاگ ان کیا۔ لاگ واپس کلک ہاؤس پر چلا گیا، یعنی یہ ایک مسلسل چکراتی نظام ہے۔ اور اس کے علاوہ، میں وہاں اس کا تجزیہ کرنے DWH گیا تھا۔
یہ اس فارم میں بہت اچھا کام نہیں کیا. اور ClickHouse کے لیے آسان بنانے کے لیے، جب وزٹ آئی ڈی کی درخواست آئی، تو انھوں نے ان درخواستوں کو 1-000 وزٹ آئی ڈیز کے بلاکس میں گروپ کیا اور 2-000 لوگوں کے لیے تمام لین دین کو نکال دیا۔ اور پھر یہ سب کام کر گیا۔
اگر آپ کلک ہاؤس کے اندر دیکھیں تو صرف 3 اہم میزیں ہیں جو یہ سب کچھ پیش کرتی ہیں۔
پہلا ٹیبل جس میں لاگز اپ لوڈ کیے جاتے ہیں، اور لاگز کو عملی طور پر بغیر کسی پروسیسنگ کے اپ لوڈ کیا جاتا ہے۔
دوسری میز۔ مادی نظریہ کے ذریعے، ایسے واقعات جو ابھی تک منسوب نہیں کیے گئے ہیں، یعنی غیر متعلق، ان نوشتہ جات سے نکالے گئے تھے۔ اور مادی منظر کے ذریعے، ایک سنیپ شاٹ بنانے کے لیے لین دین کو ان لاگز سے نکالا گیا۔ یعنی، ایک اسنیپ شاٹ کو ایک خاص مادی نظر کے ساتھ بنایا گیا تھا، یعنی لین دین کی آخری جمع شدہ حالت۔
یہاں ایس کیو ایل میں متن لکھا ہوا ہے۔ میں اس میں کئی اہم باتوں پر تبصرہ کرنا چاہوں گا۔
پہلی اہم چیز کلک ہاؤس میں json سے کالم اور فیلڈز نکالنے کی صلاحیت ہے۔ یعنی کلک ہاؤس کے پاس json کے ساتھ کام کرنے کے کچھ طریقے ہیں۔ وہ بہت، بہت قدیم ہیں۔
visitParamExtractInt آپ کو json سے اوصاف نکالنے کی اجازت دیتا ہے، یعنی پہلی ہٹ ٹرگر ہوتی ہے۔ اور اس طرح آپ ٹرانزیکشن آئی ڈی یا وزٹ آئی ڈی نکال سکتے ہیں۔ اس بار۔
دوم، یہاں ایک مشکل مادی فیلڈ استعمال کیا گیا ہے۔ اس کا کیا مطلب ہے؟ اس کا مطلب یہ ہے کہ آپ اسے ٹیبل میں داخل نہیں کر سکتے ہیں، یعنی یہ داخل نہیں کیا گیا ہے، جب داخل کیا جاتا ہے تو اس کا حساب اور ذخیرہ کیا جاتا ہے۔ جب آپ داخل کرتے ہیں، تو ClickHouse آپ کے لیے کام کرتا ہے۔ اور جس چیز کی آپ کو بعد میں ضرورت ہوگی وہ json سے نکال لی گئی ہے۔
اس صورت میں، مادی نظر خام تاروں کے لیے ہے۔ اور تقریباً کچے نوشتہ جات والی پہلی میز استعمال کی جاتی ہے۔ اور یہ کیا کرتا ہے؟ سب سے پہلے، یہ ترتیب کو تبدیل کرتا ہے، یعنی چھانٹنا اب وزٹ آئی ڈی کے ذریعے کیا جاتا ہے، کیونکہ ہمیں خاص طور پر کسی مخصوص شخص کے لیے اس کے لین دین کو فوری طور پر نکالنے کی ضرورت ہے۔
دوسری اہم چیز index_granularity ہے۔ اگر آپ نے MergeTree دیکھا ہے، تو عام طور پر ڈیفالٹ ویلیو 8 index_granularity ہوتی ہے۔ یہ کیا ہے؟ یہ انڈیکس اسپارسٹی پیرامیٹر ہے۔ کلک ہاؤس میں، انڈیکس بہت کم ہے؛ یہ ہر ریکارڈ کو کبھی بھی انڈیکس نہیں کرتا ہے۔ یہ ہر 192 پر ایسا کرتا ہے۔ اور یہ اس وقت اچھا ہوتا ہے جب آپ کو بہت سارے ڈیٹا کا حساب لگانے کی ضرورت ہوتی ہے، لیکن جب آپ کو تھوڑا سا حساب لگانے کی ضرورت ہوتی ہے تو یہ برا ہوتا ہے، کیونکہ بہت زیادہ اوور ہیڈ ہوتا ہے۔ اور اگر ہم انڈیکس گرینولریٹی کو کم کرتے ہیں، تو ہم اوور ہیڈ کو کم کرتے ہیں۔ آپ اسے ایک تک کم نہیں کر سکتے، کیونکہ ہو سکتا ہے کافی میموری نہ ہو۔ انڈیکس ہمیشہ میموری میں محفوظ ہوتا ہے۔
اور سنیپ شاٹ کچھ دوسرے دلچسپ ClickHouse افعال کا استعمال کرتا ہے۔
سب سے پہلے AggregatingMergeTree ہے۔ اور AggregatingMergeTree argMax کو اسٹور کرتا ہے، یعنی یہ آخری ٹائم اسٹیمپ کے مطابق لین دین کی حالت ہے۔ اس وزیٹر کے لیے ہمیشہ نئی ٹرانزیکشنز تیار کی جاتی ہیں۔ اور اس لین دین کی بالکل آخری حالت میں، ہم نے ایک واقعہ شامل کیا اور ہمیں ایک نئی حالت ملی۔ اس نے دوبارہ کلک ہاؤس کو مارا۔ اور ارگ میکس کے ذریعے اس مادی نظر میں ہم ہمیشہ موجودہ حالت حاصل کر سکتے ہیں۔
- بائنڈنگ رن ٹائم سے "غیر ٹیچرڈ" ہے۔
- ہر ماہ 3 بلین تک کے لین دین کو ذخیرہ اور پروسیس کیا جاتا ہے۔ یہ ایک عام لین دین کے نظام میں کیسینڈرا کے مقابلے میں زیادہ مقدار کا حکم ہے۔
- 2x5 کلک ہاؤس سرورز کا کلسٹر۔ 5 سرورز اور ہر سرور کی ایک نقل ہے۔ کلک پر مبنی انتساب کرنے کے لیے یہ کیسنڈرا سے بھی کم ہے، لیکن یہاں ہمارے پاس تاثر کی بنیاد ہے۔ یعنی سرورز کی تعداد 30 گنا بڑھانے کے بجائے کم کردی گئی۔
اور آخری مثال مالیاتی کمپنی Y ہے، جس نے اسٹاک کی قیمتوں میں تبدیلی کے ارتباط کا تجزیہ کیا۔
اور کام یہ تھا:
- تقریباً 5 شیئرز ہیں۔
- ہر 100 ملی سیکنڈ میں اقتباسات معلوم ہوتے ہیں۔
- اعداد و شمار 10 سالوں میں جمع ہوئے ہیں۔ بظاہر، کچھ کمپنیوں کے لیے یہ زیادہ ہے، کچھ کے لیے یہ کم ہے۔
- مجموعی طور پر تقریباً 100 بلین قطاریں ہیں۔
اور تبدیلیوں کے ارتباط کا حساب لگانا ضروری تھا۔
یہاں دو اسٹاک اور ان کے اقتباسات ہیں۔ اگر ایک اوپر جاتا ہے اور دوسرا اوپر جاتا ہے، تو یہ ایک مثبت تعلق ہے، یعنی ایک اوپر جاتا ہے اور دوسرا اوپر جاتا ہے۔ اگر ایک اوپر جاتا ہے، جیسا کہ گراف کے آخر میں، اور دوسرا نیچے چلا جاتا ہے، تو یہ ایک منفی تعلق ہے، یعنی جب ایک اوپر جاتا ہے تو دوسرا نیچے چلا جاتا ہے۔
ان باہمی تبدیلیوں کا تجزیہ کرکے، کوئی بھی مالیاتی منڈی میں پیشین گوئیاں کرسکتا ہے۔
لیکن کام مشکل ہے۔ اس کے لیے کیا کیا جا رہا ہے؟ ہمارے پاس 100 بلین ریکارڈز ہیں جن میں شامل ہیں: وقت، اسٹاک اور قیمت۔ ہمیں پہلے قیمت کے الگورتھم سے 100 بلین گنا رننگ فرق کا حساب لگانا ہوگا۔ RunningDifference ClickHouse میں ایک فنکشن ہے جو ترتیب وار دو لائنوں کے درمیان فرق کا حساب لگاتا ہے۔
اور اس کے بعد ہمیں ارتباط کا حساب لگانے کی ضرورت ہے، اور ہر جوڑے کے لیے ارتباط کا حساب لگانا چاہیے۔ 5 شیئرز کے لیے جوڑے 000 ملین ہیں۔ اور یہ بہت زیادہ ہے، یعنی 12,5 بار آپ کو اس ارتباطی فعل کا حساب لگانے کی ضرورت ہے۔
اور اگر کوئی بھول جائے تو، ͞x اور ͞y چیک میٹ ہیں۔ نمونہ کی توقع یعنی، آپ کو نہ صرف جڑوں اور رقوم کا، بلکہ ان رقوم کے اندر دیگر رقوم کا بھی حساب لگانا ہوگا۔ بہت سارے حسابات کو 12,5 ملین بار کرنے کی ضرورت ہے، اور انہیں گھنٹے کے حساب سے گروپ کرنے کی بھی ضرورت ہے۔ اور ہمارے پاس بھی بہت سارے گھنٹے ہیں۔ اور آپ کو یہ 60 سیکنڈ میں کرنا ہے۔ یہ ایک مذاق ہے.
ہمیں اسے کسی نہ کسی طرح بنانا پڑا، کیونکہ کلک ہاؤس کے آنے سے پہلے یہ سب بہت، بہت آہستہ سے کام کرتا تھا۔
انہوں نے ہڈوپ پر، اسپارک پر، گرین پلم پر اس کا حساب لگانے کی کوشش کی۔ اور یہ سب بہت سست یا مہنگا تھا۔ یعنی کسی نہ کسی طرح اس کا حساب لگانا ممکن تھا لیکن پھر مہنگا پڑ گیا۔
اور پھر کلک ہاؤس آیا اور سب کچھ بہت بہتر ہو گیا۔
میں آپ کو یاد دلاتا ہوں کہ ہمیں ڈیٹا لوکلٹی میں مسئلہ ہے، اس لیے ارتباط کو مقامی نہیں بنایا جا سکتا۔ ہم ایک سرور میں کچھ ڈیٹا شامل نہیں کر سکتے، کچھ دوسرے میں اور حساب لگا سکتے ہیں؛ ہمارے پاس تمام ڈیٹا ہر جگہ ہونا چاہیے۔
انہوں نے کیا کیا؟ ابتدائی طور پر، ڈیٹا مقامی ہے. ہر سرور حصص کے مخصوص سیٹ کے لیے قیمتوں کا ڈیٹا اسٹور کرتا ہے۔ اور وہ آپس میں نہیں بٹتے۔ لہذا، متوازی اور آزادانہ طور پر لاگ ریٹرن کا حساب لگانا ممکن ہے؛ یہ سب متوازی اور تقسیم میں ہوتا ہے۔
پھر ہم نے اظہار خیال کو کھونے کے بغیر اس ڈیٹا کو کم کرنے کا فیصلہ کیا۔ صفوں کا استعمال کم کریں، یعنی ہر وقت کے لیے حصص کی ایک صف اور قیمتوں کی ایک صف بنائیں۔ اس طرح یہ بہت کم ڈیٹا کی جگہ لیتا ہے۔ اور ان کے ساتھ کام کرنا کچھ زیادہ آسان ہے۔ یہ تقریباً متوازی کارروائیاں ہیں، یعنی ہم جزوی طور پر متوازی میں شمار کرتے ہیں اور پھر سرور کو لکھتے ہیں۔
اس کے بعد اس کی نقل تیار کی جاسکتی ہے۔ حرف "r" کا مطلب ہے کہ ہم نے اس ڈیٹا کو نقل کیا۔ یعنی، ہمارے پاس تینوں سرورز پر ایک ہی ڈیٹا ہے - یہ arrays ہیں۔
اور پھر، ایک خاص اسکرپٹ کا استعمال کرتے ہوئے، آپ 12,5 ملین ارتباط کے اس سیٹ سے پیکجز بنا سکتے ہیں جن کا حساب لگانے کی ضرورت ہے۔ یعنی 2 کام جس میں 500 جوڑے ارتباط کے ہیں۔ اور اس کام کا حساب ایک مخصوص ClickHouse سرور پر ہونا چاہیے۔ اس کے پاس تمام ڈیٹا موجود ہے کیونکہ ڈیٹا ایک جیسا ہے اور وہ ترتیب وار اس کا حساب لگا سکتا ہے۔
یہ پھر سے کیسا لگتا ہے۔ سب سے پہلے، ہمارے پاس درج ذیل ڈھانچے میں تمام ڈیٹا موجود ہے: وقت، حصص، قیمت۔ پھر ہم نے logReturn کا حساب لگایا، یعنی ایک ہی ڈھانچے کا ڈیٹا، صرف قیمت کے بجائے ہمارے پاس logReturn ہے۔ پھر انہیں دوبارہ کیا گیا، یعنی ہمیں پروموشنز اور قیمت کی فہرستوں کے ذریعے وقت اور گروپ آرے ملا۔ نقل شدہ۔ اور اس کے بعد، انہوں نے کاموں کا ایک گروپ تیار کیا اور انہیں ClickHouse کو کھلایا تاکہ یہ ان کی گنتی کر سکے۔ اور یہ کام کرتا ہے۔
تصور کے ثبوت پر، کام ایک ذیلی کام تھا، یعنی انہوں نے کم ڈیٹا لیا۔ اور صرف تین سرورز پر۔
یہ پہلے دو مراحل: Log_return کا حساب لگانے اور اسے صفوں میں لپیٹنے میں تقریباً ایک گھنٹہ لگا۔
اور ارتباط کا حساب لگانے میں تقریباً 50 گھنٹے لگتے ہیں۔ لیکن 50 گھنٹے کافی نہیں ہیں، کیونکہ پہلے یہ ان کے لیے ہفتوں تک کام کرتا تھا۔ یہ ایک بڑی کامیابی تھی۔ اور اگر آپ گنتے ہیں، تو اس کلسٹر پر ہر سیکنڈ میں 70 بار ہر چیز کی گنتی کی گئی۔
لیکن سب سے اہم بات یہ ہے کہ اس نظام میں عملی طور پر کوئی رکاوٹ نہیں ہے، یعنی یہ تقریباً لکیری پیمانے پر ہے۔ اور انہوں نے اسے چیک کیا۔ اسے کامیابی سے پیمانہ کیا گیا۔
- صحیح اسکیم آدھی کامیابی ہے۔ اور درست اسکیم یہ ہے کہ کلک ہاؤس کی تمام ضروری ٹیکنالوجیز استعمال کی جائیں۔
- Summing/AggregatingMergeTrees وہ ٹیکنالوجیز ہیں جو آپ کو ایک خاص کیس کے طور پر ریاست کے اسنیپ شاٹ کو جمع کرنے یا شمار کرنے کی اجازت دیتی ہیں۔ اور یہ بہت سی چیزوں کو آسان بنا دیتا ہے۔
- مٹیریلائزڈ ویوز آپ کو ون انڈیکس کی حد سے گزرنے کی اجازت دیتے ہیں۔ شاید میں نے یہ واضح طور پر نہیں کہا تھا، لیکن جب ہم نے لاگز کو لوڈ کیا تو خام لاگز ایک انڈیکس کے ساتھ ایک ٹیبل میں تھے، اور انتساب پر لاگز ٹیبل میں تھے، یعنی وہی ڈیٹا، صرف فلٹر کیا گیا تھا، لیکن انڈیکس تھا۔ دوسروں کو مکمل طور پر. ایسا لگتا ہے کہ یہ ایک ہی ڈیٹا ہے، لیکن مختلف چھانٹی ہوئی ہے۔ اور میٹریلائزڈ ویوز آپ کو اجازت دیتا ہے، اگر آپ کو اس کی ضرورت ہو تو، کلک ہاؤس کی اس حد کو نظرانداز کرنے کے لیے۔
- پوائنٹ کے سوالات کے لیے انڈیکس گرینولریٹی کو کم کریں۔
- اور ڈیٹا کو ہوشیاری سے تقسیم کریں، سرور کے اندر ڈیٹا کو زیادہ سے زیادہ لوکلائز کرنے کی کوشش کریں۔ اور اس بات کو یقینی بنانے کی کوشش کریں کہ جہاں تک ممکن ہو درخواستوں میں لوکلائزیشن کا بھی استعمال کیا جائے۔
اور اس مختصر تقریر کا خلاصہ کرنے کے لیے، ہم کہہ سکتے ہیں کہ ClickHouse نے اب کمرشل ڈیٹا بیس اور اوپن سورس ڈیٹا بیس، یعنی خاص طور پر تجزیات کے لیے دونوں کے علاقے پر مضبوطی سے قبضہ کر لیا ہے۔ وہ اس زمین کی تزئین میں بالکل فٹ بیٹھتا ہے۔ اور مزید کیا ہے، یہ آہستہ آہستہ دوسروں کو بے گھر کرنا شروع کر رہا ہے، کیونکہ جب ClickHouse ہوتا ہے، تو آپ کو InfiniDB کی ضرورت نہیں ہوتی۔ اگر وہ نارمل ایس کیو ایل سپورٹ فراہم کرتے ہیں تو عمودی کی جلد ضرورت نہیں ہوگی۔ استعمال کرو!
-رپورٹ کے لیے شکریہ! بہت دلچسپ! کیا اپاچی فینکس کے ساتھ کوئی موازنہ کیا گیا ہے؟
- نہیں، میں نے کسی کو موازنہ کرتے نہیں سنا۔ ہم اور Yandex مختلف ڈیٹا بیس کے ساتھ ClickHouse کے تمام موازنہوں پر نظر رکھنے کی کوشش کرتے ہیں۔ کیونکہ اگر اچانک کوئی چیز ClickHouse سے زیادہ تیز نکلے تو لیشا میلووڈوف رات کو سو نہیں پاتے اور تیزی سے اسے تیز کرنا شروع کر دیتے ہیں۔ میں نے ایسا موازنہ نہیں سنا۔
-
(Alexey Milovidov) Apache Phoenix ایک SQL انجن ہے جو Hbase پر مبنی ہے۔ Hbase بنیادی طور پر کلیدی قدر کی قسم کے کام کے منظر نامے کے لیے ڈیزائن کیا گیا ہے۔ وہاں، ہر لائن میں صوابدیدی ناموں کے ساتھ کالموں کی صوابدیدی تعداد ہوسکتی ہے۔ یہ Hbase اور Cassandra جیسے سسٹمز کے بارے میں کہا جا سکتا ہے۔ اور یہ خاص طور پر بھاری تجزیاتی سوالات ہیں جو ان کے لیے عام طور پر کام نہیں کریں گے۔ یا آپ سوچ سکتے ہیں کہ وہ ٹھیک کام کرتے ہیں اگر آپ کو ClickHouse کے ساتھ کوئی تجربہ نہیں ہے۔
-
شکریہ
-
صبح بخیر میں پہلے ہی اس موضوع میں کافی دلچسپی رکھتا ہوں، کیونکہ میرے پاس ایک تجزیاتی سب سسٹم ہے۔ لیکن جب میں ClickHouse کو دیکھتا ہوں تو مجھے یہ احساس ہوتا ہے کہ ClickHouse ایونٹ کے تجزیہ کے لیے بہت موزوں ہے، تغیر پذیر۔ اور اگر مجھے بڑی میزوں کے ایک گروپ کے ساتھ بہت سارے کاروباری ڈیٹا کا تجزیہ کرنے کی ضرورت ہے، تو کلک ہاؤس، جہاں تک میں سمجھتا ہوں، میرے لیے بہت موزوں نہیں ہے؟ خاص طور پر اگر وہ بدل جائیں۔ کیا یہ درست ہے یا ایسی مثالیں ہیں جو اس کو غلط ثابت کر سکتی ہیں؟
-
یہ درست ہے. اور یہ سب سے زیادہ خصوصی تجزیاتی ڈیٹا بیس کے بارے میں سچ ہے۔ وہ اس حقیقت کے مطابق بنائے گئے ہیں کہ ایک یا کئی بڑی میزیں ہیں جو بدلنے والی ہیں، اور بہت سی چھوٹی ہیں جو آہستہ آہستہ تبدیل ہوتی ہیں۔ یعنی کلک ہاؤس اوریکل کی طرح نہیں ہے، جہاں آپ سب کچھ ڈال سکتے ہیں اور کچھ انتہائی پیچیدہ سوالات بنا سکتے ہیں۔ ClickHouse کو مؤثر طریقے سے استعمال کرنے کے لیے، آپ کو اسکیم کو اس طریقے سے بنانا ہوگا جو ClickHouse میں اچھی طرح سے کام کرے۔ یعنی ضرورت سے زیادہ نارملائزیشن سے گریز کریں، لغات استعمال کریں، کم لمبے کنکشن بنانے کی کوشش کریں۔ اور اگر اسکیم کو اس طرح بنایا گیا ہے، تو پھر اسی طرح کے کاروباری مسائل کو کلک ہاؤس پر روایتی رشتہ دار ڈیٹا بیس کی نسبت زیادہ مؤثر طریقے سے حل کیا جاسکتا ہے۔
-
رپورٹ کے لیے شکریہ! میرے پاس تازہ ترین مالیاتی کیس کے بارے میں ایک سوال ہے۔ ان کے پاس تجزیات تھے۔ یہ موازنہ کرنا ضروری تھا کہ وہ کیسے اوپر اور نیچے جاتے ہیں۔ اور میں سمجھتا ہوں کہ آپ نے خاص طور پر اس تجزیات کے لیے سسٹم بنایا ہے؟ اگر کل، آئیے کہتے ہیں، انہیں اس ڈیٹا پر کسی اور رپورٹ کی ضرورت ہے، تو کیا انہیں دوبارہ خاکہ بنانے اور ڈیٹا لوڈ کرنے کی ضرورت ہے؟ یعنی درخواست وصول کرنے کے لیے کسی قسم کی پری پروسیسنگ کرتے ہیں؟
یقینا، یہ ایک خاص کام کے لیے ClickHouse کا استعمال کر رہا ہے۔ اسے ہڈوپ کے اندر زیادہ روایتی طور پر حل کیا جاسکتا ہے۔ Hadoop کے لیے یہ ایک مثالی کام ہے۔ لیکن ہڈوپ پر یہ بہت سست ہے۔ اور میرا مقصد یہ ظاہر کرنا ہے کہ ClickHouse ان مسائل کو حل کر سکتا ہے جو عام طور پر بالکل مختلف طریقوں سے حل کیے جاتے ہیں، لیکن ساتھ ہی اسے بہت زیادہ مؤثر طریقے سے بھی کرتے ہیں۔ یہ ایک مخصوص کام کے لیے تیار کیا گیا ہے۔ یہ واضح ہے کہ اگر کوئی مسئلہ ہے جو کسی حد تک ملتا جلتا ہے، تو اسے اسی طرح حل کیا جا سکتا ہے.
یہ بات واضح ہے. آپ نے کہا کہ کارروائی میں 50 گھنٹے لگے۔ کیا یہ شروع سے شروع ہو رہا ہے، جب آپ نے ڈیٹا لوڈ کیا یا نتائج موصول ہوئے؟
ہاں ہاں.
ٹھیک ہے آپ کا بہت بہت شکریہ.
یہ 3 سرور کلسٹر پر ہے۔
سلام! رپورٹ کے لیے شکریہ! سب کچھ بہت دلچسپ ہے۔ میں فعالیت کے بارے میں تھوڑا نہیں پوچھ رہا ہوں، لیکن استحکام کے نقطہ نظر سے ClickHouse کو استعمال کرنے کے بارے میں پوچھ رہا ہوں۔ یعنی کیا آپ کو کوئی مسئلہ درپیش تھا اور کیا آپ نے انہیں بحال کرنا تھا؟ کلک ہاؤس کیسے برتاؤ کرتا ہے؟ اور کیا کبھی ایسا ہوا ہے کہ آپ کا چربہ بھی کریش ہوا ہو؟ مثال کے طور پر، ہمیں ClickHouse کے ساتھ ایک مسئلہ کا سامنا کرنا پڑا جب یہ اب بھی اپنی حد سے آگے نکل گیا اور گر گیا۔
یقیناً کوئی مثالی نظام نہیں ہے۔ اور کلک ہاؤس کے بھی اپنے مسائل ہیں۔ لیکن کیا آپ نے Yandex.Metrica کے بارے میں سنا ہے کہ طویل عرصے سے کام نہیں کر رہا ہے؟ شاید نہیں۔ یہ ClickHouse پر تقریباً 2012-2013 سے قابل اعتماد طریقے سے کام کر رہا ہے۔ میں اپنے تجربے کے بارے میں بھی یہی کہہ سکتا ہوں۔ ہمیں کبھی مکمل ناکامی نہیں ہوئی۔ کچھ جزوی چیزیں ہو سکتی ہیں، لیکن وہ کبھی بھی اتنی نازک نہیں تھیں کہ کاروبار کو سنجیدگی سے متاثر کریں۔ ایسا پہلے کبھی نہیں ہوا۔ کلک ہاؤس کافی قابل اعتماد ہے اور تصادفی طور پر کریش نہیں ہوتا ہے۔ آپ کو اس کے بارے میں فکر کرنے کی ضرورت نہیں ہے۔ یہ کوئی کچی بات نہیں ہے۔ یہ بہت سی کمپنیوں کی طرف سے ثابت کیا گیا ہے.
ہیلو! آپ نے کہا کہ آپ کو فوری طور پر ڈیٹا اسکیما کے بارے میں احتیاط سے سوچنے کی ضرورت ہے۔ اگر ایسا ہوا تو کیا ہوگا؟ میرا ڈیٹا اندر اور باہر بہا رہا ہے۔ چھ مہینے گزر جاتے ہیں، اور میں سمجھتا ہوں کہ میں اس طرح نہیں رہ سکتا، مجھے ڈیٹا کو دوبارہ اپ لوڈ کرنے اور اس کے ساتھ کچھ کرنے کی ضرورت ہے۔
یہ یقیناً آپ کے سسٹم پر منحصر ہے۔ یہ تقریباً نہ رکنے کے کئی طریقے ہیں۔ مثال کے طور پر، آپ ایک میٹریلائزڈ ویو بنا سکتے ہیں جس میں آپ ایک مختلف ڈیٹا ڈھانچہ بنا سکتے ہیں اگر اسے منفرد طریقے سے میپ کیا جا سکے۔ یعنی، اگر یہ کلک ہاؤس کا استعمال کرتے ہوئے نقشہ سازی کی اجازت دیتا ہے، یعنی کچھ چیزوں کو نکالنا، بنیادی کلید کو تبدیل کرنا، تقسیم کاری کو تبدیل کرنا، تو آپ میٹریلائزڈ ویو بنا سکتے ہیں۔ وہاں آپ کا پرانا ڈیٹا دوبارہ لکھا جائے گا، نیا خود بخود لکھا جائے گا۔ اور پھر صرف میٹریلائزڈ ویو استعمال کرنے پر سوئچ کریں، پھر ریکارڈ کو سوئچ کریں اور پرانے ٹیبل کو ختم کریں۔ یہ عام طور پر نان اسٹاپ طریقہ ہے۔
آپ کا شکریہ.
ماخذ: www.habr.com