বাস্তব অ্যাপ্লিকেশনে ক্লিকহাউস ব্যবহার করার তত্ত্ব এবং অনুশীলন। আলেকজান্ডার জাইতসেভ (2018)

প্রায় সর্বত্র এখন প্রচুর ডেটা থাকা সত্ত্বেও, বিশ্লেষণাত্মক ডেটাবেসগুলি এখনও বেশ বহিরাগত। তারা খারাপভাবে পরিচিত এবং এমনকি খারাপভাবে তাদের কার্যকরভাবে ব্যবহার করতে সক্ষম। অনেকেই MySQL বা PostgreSQL এর সাথে "ক্যাকটাস খাওয়া" চালিয়ে যাচ্ছেন, যা অন্যান্য পরিস্থিতির জন্য ডিজাইন করা হয়েছে, NoSQL এর সাথে ভুগছে, বা বাণিজ্যিক সমাধানের জন্য অতিরিক্ত অর্থ প্রদান করে। ClickHouse গেমের নিয়ম পরিবর্তন করে এবং বিশ্লেষণাত্মক DBMS-এর জগতে প্রবেশের থ্রেশহোল্ডকে উল্লেখযোগ্যভাবে কমিয়ে দেয়।

ব্যাকএন্ড কনফ 2018 থেকে রিপোর্ট এবং এটি স্পিকারের অনুমতি নিয়ে প্রকাশিত হয়।

আমি কে এবং কেন আমি ক্লিকহাউসের কথা বলছি? আমি LifeStreet-এর একজন ডেভেলপমেন্ট ডিরেক্টর, যেটি ClickHouse ব্যবহার করে। এছাড়াও, আমি Altinity এর প্রতিষ্ঠাতা। এটি একটি ইয়ানডেক্স অংশীদার যা ClickHouse প্রচার করে এবং Yandex কে ClickHouse কে আরও সফল করতে সাহায্য করে। এছাড়াও ClickHouse সম্পর্কে জ্ঞান শেয়ার করতে প্রস্তুত.

এবং আমি পেটিয়া জাইতসেভের ভাই নই। আমাকে প্রায়ই এই সম্পর্কে জিজ্ঞাসা করা হয়. না, আমরা ভাই না।

"সবাই জানে" যে ক্লিকহাউস:

• খুব দ্রুত,
• খুব আরামদায়ক
• ইয়ানডেক্সে ব্যবহৃত।

কোন কোম্পানীতে এবং কিভাবে এটি ব্যবহার করা হয় তা একটু কমই জানা যায়।

ইয়ানডেক্স ব্যতীত কেন, কোথায় এবং কীভাবে ক্লিকহাউস ব্যবহার করা হয় তা আমি আপনাকে বলব।

আমি আপনাকে বলব কিভাবে বিভিন্ন কোম্পানিতে ক্লিকহাউসের সাহায্যে নির্দিষ্ট কাজগুলি সমাধান করা হয়, আপনি আপনার কাজের জন্য কি ক্লিকহাউস টুল ব্যবহার করতে পারেন এবং বিভিন্ন কোম্পানিতে সেগুলি কীভাবে ব্যবহার করা হয়েছিল।

আমি তিনটি উদাহরণ তুলেছি যা বিভিন্ন কোণ থেকে ক্লিকহাউস দেখায়। আমি মনে করি এটা আকর্ষণীয় হবে.

প্রথম প্রশ্ন হল: "কেন আমাদের ClickHouse দরকার?"। এটি একটি মোটামুটি সুস্পষ্ট প্রশ্ন বলে মনে হচ্ছে, কিন্তু এটির একাধিক উত্তর আছে।

• প্রথম উত্তর হল পারফরম্যান্সের জন্য। ক্লিক হাউস খুব দ্রুত। ক্লিকহাউসের বিশ্লেষণও খুব দ্রুত। এটি প্রায়শই ব্যবহার করা যেতে পারে যেখানে অন্য কিছু খুব ধীর বা খুব খারাপ।
• দ্বিতীয় উত্তর হল খরচ। এবং প্রথমত, স্কেলিং এর খরচ। উদাহরণস্বরূপ, ভার্টিকা একটি একেবারে দুর্দান্ত ডাটাবেস। আপনার কাছে প্রচুর টেরাবাইট ডেটা না থাকলে এটি খুব ভাল কাজ করে। কিন্তু যখন শত শত টেরাবাইট বা পেটাবাইটের কথা আসে, তখন লাইসেন্স এবং সহায়তার খরচ মোটামুটি উল্লেখযোগ্য পরিমাণে চলে যায়। এবং এটি ব্যয়বহুল। এবং ক্লিক হাউস বিনামূল্যে।
• তৃতীয় উত্তর হল অপারেটিং খরচ। এটি একটি সামান্য ভিন্ন পদ্ধতির. RedShift একটি মহান এনালগ. RedShift এ, আপনি খুব দ্রুত একটি সিদ্ধান্ত নিতে পারেন। এটি ভাল কাজ করবে, তবে একই সময়ে, প্রতি ঘন্টা, প্রতিদিন এবং প্রতি মাসে, আপনি অ্যামাজনকে বেশ মূল্যবান অর্থ প্রদান করবেন, কারণ এটি একটি উল্লেখযোগ্যভাবে ব্যয়বহুল পরিষেবা। Google BigQueryও। যদি কেউ এটি ব্যবহার করে, তবে সে জানে যে সেখানে আপনি বেশ কয়েকটি অনুরোধ চালাতে পারেন এবং হঠাৎ করে শত শত ডলারের বিল পেতে পারেন।

ClickHouse এই সমস্যা নেই.

ক্লিকহাউস এখন কোথায় ব্যবহার করা হয়? Yandex ছাড়াও, ClickHouse বিভিন্ন ব্যবসা এবং কোম্পানির একটি গুচ্ছ ব্যবহার করা হয়।

• প্রথমত, এটি ওয়েব অ্যাপ্লিকেশন বিশ্লেষণ, অর্থাৎ এটি একটি ব্যবহারের ক্ষেত্রে যা ইয়ানডেক্স থেকে এসেছে।
• অনেক AdTech কোম্পানি ClickHouse ব্যবহার করে।
• বিভিন্ন উত্স থেকে লেনদেন লগ বিশ্লেষণ করতে হবে যে অনেক কোম্পানি.
• নিরাপত্তা লগ নিরীক্ষণ করার জন্য বেশ কিছু কোম্পানি ClickHouse ব্যবহার করে। তারা সেগুলিকে ক্লিক হাউসে আপলোড করে, প্রতিবেদন তৈরি করে এবং তাদের প্রয়োজনীয় ফলাফলগুলি পায়৷
• কোম্পানিগুলি আর্থিক বিশ্লেষণে এটি ব্যবহার করতে শুরু করেছে, অর্থাৎ ধীরে ধীরে বড় ব্যবসাগুলিও ক্লিকহাউসের কাছে আসছে৷
• ক্লাউডফ্লেয়ার. যদি কেউ ClickHouse অনুসরণ করে, তাহলে তারা সম্ভবত এই কোম্পানির নাম শুনেছে। এই সম্প্রদায় থেকে অপরিহার্য অবদানকারী এক. এবং তাদের একটি খুব গুরুতর ক্লিকহাউস ইনস্টলেশন রয়েছে। উদাহরণস্বরূপ, তারা ক্লিক হাউসের জন্য কাফকা ইঞ্জিন তৈরি করেছিল।
• টেলিকমিউনিকেশন কোম্পানি ব্যবহার করতে শুরু করে। বেশ কিছু কোম্পানি ক্লিকহাউস ব্যবহার করে ধারণার প্রমাণ হিসেবে অথবা ইতিমধ্যেই উৎপাদনে রয়েছে।
• একটি কোম্পানি উৎপাদন প্রক্রিয়া নিরীক্ষণ করতে ক্লিক হাউস ব্যবহার করে। তারা মাইক্রোসার্কিট পরীক্ষা করে, একগুচ্ছ প্যারামিটার লিখে দেয়, প্রায় 2 বৈশিষ্ট্য রয়েছে। এবং তারপরে তারা বিশ্লেষণ করে খেলাটি ভাল না খারাপ।
• ব্লকচেইন বিশ্লেষণ। Bloxy.info এর মতো একটি রাশিয়ান কোম্পানি আছে। এটি ইথেরিয়াম নেটওয়ার্কের একটি বিশ্লেষণ। তারা ক্লিক হাউসেও এটি করেছে।

এবং আকার কোন ব্যাপার না. অনেক কোম্পানি আছে যারা একটি ছোট সার্ভার ব্যবহার করে। এবং তিনি তাদের সমস্যা সমাধানের অনুমতি দেন। এবং এমনকি আরো কোম্পানি অনেক সার্ভার বা কয়েক ডজন সার্ভারের বড় ক্লাস্টার ব্যবহার করে।

এবং আপনি যদি রেকর্ডগুলি দেখেন, তাহলে:

• ইয়ানডেক্স: 500+ সার্ভার, তারা সেখানে প্রতিদিন 25 বিলিয়ন রেকর্ড সঞ্চয় করে।
• লাইফস্ট্রিট: 60টি সার্ভার, প্রতিদিন প্রায় 75 বিলিয়ন রেকর্ড। ইয়ানডেক্সের তুলনায় কম সার্ভার, আরও রেকর্ড রয়েছে।
• ক্লাউডফ্লেয়ার: 36টি সার্ভার, তারা প্রতিদিন 200 বিলিয়ন রেকর্ড সংরক্ষণ করে। তাদের আরও কম সার্ভার রয়েছে এবং আরও বেশি ডেটা সঞ্চয় করে।
• ব্লুমবার্গ: 102 সার্ভার, প্রতিদিন প্রায় এক ট্রিলিয়ন এন্ট্রি। তথ্য সংরক্ষণকারী.

ভৌগোলিকভাবে, এটিও অনেক। এই মানচিত্রটি এখানে একটি হিটম্যাপ দেখায় যেখানে ক্লিকহাউস বিশ্বে ব্যবহৃত হচ্ছে। রাশিয়া, চীন, আমেরিকা এখানে স্পষ্টভাবে দাঁড়িয়ে আছে। ইউরোপের কয়েকটি দেশ আছে। এবং ক্লাস্টার আছে 4টি।

এটি একটি তুলনামূলক বিশ্লেষণ, পরম পরিসংখ্যান খোঁজার প্রয়োজন নেই। এটি সেই দর্শকদের বিশ্লেষণ যারা Altinity ওয়েবসাইটে ইংরেজি-ভাষা সামগ্রী পড়েন, কারণ সেখানে কোনও রাশিয়ান-ভাষী নেই৷ এবং রাশিয়া, ইউক্রেন, বেলারুশ, অর্থাৎ সম্প্রদায়ের রাশিয়ান-ভাষী অংশ, এরাই সর্বাধিক অসংখ্য ব্যবহারকারী। এরপর আসে যুক্তরাষ্ট্র ও কানাডা। চীন খুব বেশি ধরছে। ছয় মাস আগে সেখানে চীন প্রায় ছিল না, এখন চীন ইতিমধ্যে ইউরোপকে ছাড়িয়ে গেছে এবং বৃদ্ধি অব্যাহত রয়েছে। পুরানো ইউরোপও খুব বেশি পিছিয়ে নেই, এবং ক্লিকহাউস ব্যবহারে নেতা, অদ্ভুতভাবে যথেষ্ট, ফ্রান্স।

আমি কেন এই সব বলছি? দেখানোর জন্য যে ClickHouse বড় ডেটা বিশ্লেষণের জন্য একটি আদর্শ সমাধান হয়ে উঠছে এবং ইতিমধ্যে অনেক জায়গায় ব্যবহার করা হয়েছে। আপনি যদি এটি ব্যবহার করেন, আপনি সঠিক প্রবণতায় আছেন। আপনি যদি এখনও এটি ব্যবহার না করেন তবে আপনি ভয় পাবেন না যে আপনাকে একা ছেড়ে দেওয়া হবে এবং কেউ আপনাকে সাহায্য করবে না, কারণ অনেকেই ইতিমধ্যে এটি করছেন।

এগুলি বেশ কয়েকটি কোম্পানিতে বাস্তব ক্লিকহাউস ব্যবহারের উদাহরণ।

• প্রথম উদাহরণ হল একটি বিজ্ঞাপন নেটওয়ার্ক: ভার্টিকা থেকে ক্লিকহাউসে স্থানান্তর। এবং আমি কয়েকটি কোম্পানিকে জানি যারা ভার্টিকা থেকে স্থানান্তরিত হয়েছে বা স্থানান্তরের প্রক্রিয়ায় রয়েছে।
• দ্বিতীয় উদাহরণ হল ClickHouse-এ লেনদেন সংক্রান্ত স্টোরেজ। এটি অ্যান্টিপ্যাটার্নের উপর নির্মিত একটি উদাহরণ। বিকাশকারীদের পরামর্শে ক্লিকহাউসে যা করা উচিত নয় তা এখানে করা হয়েছে। এবং এটি এত কার্যকরভাবে করা হয়েছে যে এটি কাজ করে। এবং এটি সাধারণ লেনদেন সমাধানের চেয়ে অনেক ভাল কাজ করে।
• তৃতীয় উদাহরণটি ক্লিক হাউসে বিতরণ করা কম্পিউটিং। কিভাবে ClickHouse Hadoop ইকোসিস্টেমে একত্রিত করা যায় সে সম্পর্কে একটি প্রশ্ন ছিল। আমি একটি উদাহরণ দেখাব কিভাবে একটি কোম্পানি ক্লিকহাউসে একটি মানচিত্র হ্রাস কন্টেইনারের অনুরূপ কিছু করেছে, একটি খুব তুচ্ছ কাজ গণনা করার জন্য ডেটা স্থানীয়করণের ট্র্যাক রাখা ইত্যাদি।

• লাইফস্ট্রিট হল একটি অ্যাড টেক কোম্পানি যেখানে বিজ্ঞাপন নেটওয়ার্কের সাথে আসা সমস্ত প্রযুক্তি রয়েছে৷
• তিনি বিজ্ঞাপন অপ্টিমাইজেশান, প্রোগ্রাম্যাটিক বিডিংয়ের সাথে জড়িত।
• প্রচুর ডেটা: প্রতিদিন প্রায় 10 বিলিয়ন ইভেন্ট। একই সময়ে, সেখানকার ঘটনাগুলোকে কয়েকটি উপ-ইভেন্টে ভাগ করা যায়।
• এই ডেটার অনেক ক্লায়েন্ট রয়েছে এবং এগুলি কেবল মানুষই নয়, আরও অনেক কিছু - এগুলি বিভিন্ন অ্যালগরিদম যা প্রোগ্রামেটিক বিডিংয়ের সাথে জড়িত।

কোম্পানিটি একটি দীর্ঘ এবং কাঁটাযুক্ত পথ এসেছে। এবং আমি হাইলোডে এটি সম্পর্কে কথা বলেছি। প্রথমত, LifeStreet MySQL থেকে (Oracle এ একটি সংক্ষিপ্ত স্টপ সহ) ভার্টিকায় চলে গেছে। এবং আপনি এটি সম্পর্কে একটি গল্প খুঁজে পেতে পারেন.

এবং সবকিছু খুব ভাল ছিল, কিন্তু এটি দ্রুত পরিষ্কার হয়ে গেল যে ডেটা বাড়ছে এবং ভার্টিকা ব্যয়বহুল। তাই বিভিন্ন বিকল্প খোঁজা হয়েছে। তাদের কিছু এখানে তালিকাভুক্ত করা হয়. এবং প্রকৃতপক্ষে, আমরা ধারণার প্রমাণ বা কখনও কখনও প্রায় সমস্ত ডেটাবেসগুলির কার্যকারিতা পরীক্ষা করেছি যা 13 থেকে 16 তম বছর পর্যন্ত বাজারে উপলব্ধ ছিল এবং কার্যকারিতার ক্ষেত্রে প্রায় উপযুক্ত ছিল৷ এবং আমি হাইলোডে তাদের কিছু সম্পর্কেও কথা বলেছি।

কাজটি ছিল ভার্টিকা থেকে প্রথম স্থানান্তর করা, কারণ ডেটা বেড়েছে। এবং তারা বছরের পর বছর ধরে দ্রুত বৃদ্ধি পেয়েছে। তারপর তারা বালুচর গিয়েছিলাম, কিন্তু তবুও. এবং এই বৃদ্ধির ভবিষ্যদ্বাণী করা, ডেটার পরিমাণের জন্য ব্যবসায়ের প্রয়োজনীয়তা যার উপর কিছু ধরণের বিশ্লেষণ করা দরকার, এটি স্পষ্ট ছিল যে পেটাবাইট শীঘ্রই আলোচনা করা হবে। এবং পেটাবাইটের জন্য অর্থ প্রদান ইতিমধ্যেই খুব ব্যয়বহুল, তাই আমরা একটি বিকল্প খুঁজছিলাম যেখানে যেতে হবে।

কোথায় যাব? এবং একটি দীর্ঘ সময়ের জন্য কোথায় যেতে হবে তা মোটেও পরিষ্কার ছিল না, কারণ একদিকে বাণিজ্যিক ডাটাবেস রয়েছে, তারা ভাল কাজ করছে বলে মনে হচ্ছে। কিছু কাজ প্রায় পাশাপাশি ভার্টিকার, কিছু খারাপ। তবে সেগুলি সবই ব্যয়বহুল, সস্তা এবং ভাল কিছুই পাওয়া যায়নি।

অন্যদিকে, ওপেন সোর্স সলিউশন আছে, যেগুলোর সংখ্যা খুব বেশি নয়, অর্থাৎ বিশ্লেষণের জন্য, সেগুলো হাতের নাগালেই গণনা করা যায়। এবং তারা বিনামূল্যে বা সস্তা, কিন্তু ধীর. এবং তারা প্রায়ই প্রয়োজনীয় এবং দরকারী কার্যকারিতা অভাব.

এবং বাণিজ্যিক ডাটাবেসে থাকা ভাল এবং ওপেন সোর্সে থাকা সমস্ত বিনামূল্যের একত্রিত করার মতো কিছুই ছিল না।

ততক্ষণ পর্যন্ত কিছুই ছিল না, যতক্ষণ না, অপ্রত্যাশিতভাবে, ইয়ানডেক্স একটি টুপি থেকে জাদুকরের মতো, খরগোশের মতো ক্লিক হাউসকে টেনে আনে। এবং এটি একটি অপ্রত্যাশিত সিদ্ধান্ত ছিল, তারা এখনও প্রশ্ন জিজ্ঞাসা করে: "কেন?", কিন্তু তবুও।

এবং সরাসরি 2016 সালের গ্রীষ্মে, আমরা ক্লিকহাউস কী তা দেখতে শুরু করেছি। এবং এটি পরিণত হয়েছে যে কখনও কখনও এটি ভার্টিকার চেয়ে দ্রুত হতে পারে। আমরা বিভিন্ন অনুরোধে বিভিন্ন পরিস্থিতিতে পরীক্ষা করেছি। এবং যদি ক্যোয়ারীটি শুধুমাত্র একটি টেবিল ব্যবহার করে, অর্থাৎ কোন যোগদান (যোগদান) ছাড়াই, তাহলে ক্লিকহাউস ভার্টিকার চেয়ে দ্বিগুণ দ্রুত ছিল।

আমি খুব অলস ছিলাম না এবং অন্য দিন ইয়ানডেক্স পরীক্ষার দিকে তাকিয়েছিলাম। এটি সেখানে একই: ক্লিকহাউস ভার্টিকার চেয়ে দ্বিগুণ দ্রুত, তাই তারা প্রায়শই এটি সম্পর্কে কথা বলে।

তবে যদি প্রশ্নগুলিতে যোগদান থাকে তবে সবকিছু খুব দ্ব্যর্থহীনভাবে দেখা যায় না। এবং ClickHouse ভার্টিকার চেয়ে দ্বিগুণ ধীর হতে পারে। এবং যদি আপনি অনুরোধটি সামান্য সংশোধন করেন এবং এটি পুনরায় লিখুন, তাহলে তারা প্রায় সমান। খারাপ না. এবং বিনামূল্যে.

এবং পরীক্ষার ফলাফল পেয়ে, এবং এটিকে বিভিন্ন কোণ থেকে দেখে, লাইফস্ট্রিট ক্লিক হাউসে গিয়েছিল৷

এটি 16 তম বছর, আমি আপনাকে মনে করিয়ে দিচ্ছি। এটি ইঁদুর সম্পর্কে একটি রসিকতার মতো যা কাঁদছিল এবং নিজেদের ছিঁড়েছিল, কিন্তু ক্যাকটাস খেতে থাকে। এবং এটি বিশদভাবে বর্ণনা করা হয়েছিল, এটি সম্পর্কে একটি ভিডিও রয়েছে ইত্যাদি।

অতএব, আমি এটি সম্পর্কে বিস্তারিতভাবে কথা বলব না, আমি কেবল ফলাফল এবং কয়েকটি আকর্ষণীয় জিনিস সম্পর্কে কথা বলব যা আমি তখন কথা বলিনি।

ফলাফল হল:

• সফল স্থানান্তর এবং এক বছরেরও বেশি সময় ধরে সিস্টেমটি ইতিমধ্যে উত্পাদনে কাজ করছে।
• উত্পাদনশীলতা এবং নমনীয়তা বৃদ্ধি পেয়েছে। 10 বিলিয়ন রেকর্ডের মধ্যে যা আমরা প্রতিদিন এবং তারপরে অল্প সময়ের জন্য সঞ্চয় করতে পারতাম, LifeStreet এখন প্রতিদিন 75 বিলিয়ন রেকর্ড সঞ্চয় করে এবং এটি 3 মাস বা তার বেশি সময় ধরে করতে পারে। আপনি যদি শীর্ষে গণনা করেন, তাহলে এটি প্রতি সেকেন্ডে এক মিলিয়ন ইভেন্ট পর্যন্ত। এই সিস্টেমে প্রতিদিন এক মিলিয়নেরও বেশি SQL প্রশ্ন আসে, বেশিরভাগই বিভিন্ন রোবট থেকে।
• ভার্টিকার চেয়ে ক্লিকহাউসের জন্য বেশি সার্ভার ব্যবহার করা সত্ত্বেও, তারা হার্ডওয়্যারেও সংরক্ষিত ছিল, কারণ ভার্টিকায় বরং ব্যয়বহুল এসএএস ডিস্ক ব্যবহার করা হয়েছিল। ক্লিকহাউস SATA ব্যবহার করেছে। এবং কেন? কারণ ভার্টিকায় সন্নিবেশ সিঙ্ক্রোনাস। এবং সিঙ্ক্রোনাইজেশনের জন্য প্রয়োজন যে ডিস্কগুলি খুব বেশি ধীর না করে, এবং এছাড়াও যে নেটওয়ার্কটি খুব বেশি ধীর না করে, অর্থাৎ একটি বরং ব্যয়বহুল অপারেশন। এবং ক্লিকহাউসে সন্নিবেশ করা হয় অ্যাসিঙ্ক্রোনাস। তদুপরি, আপনি সর্বদা স্থানীয়ভাবে সবকিছু লিখতে পারেন, এর জন্য কোনও অতিরিক্ত খরচ নেই, তাই ভার্টিকার চেয়ে অনেক দ্রুত ক্লিকহাউসে ডেটা ঢোকানো যেতে পারে, এমনকি ধীর গতির ড্রাইভেও। এবং পড়া প্রায় একই. SATA-তে পড়া, যদি তারা RAID-এ থাকে, তাহলে এই সবই যথেষ্ট দ্রুত।
• লাইসেন্স দ্বারা সীমাবদ্ধ নয়, অর্থাৎ 3টি সার্ভারে 60 পেটাবাইট ডেটা (20 সার্ভার একটি প্রতিরূপ) এবং তথ্য এবং সমষ্টিতে 6 ট্রিলিয়ন রেকর্ড। ভার্টিকায় এর মতো কিছুই বহন করা যাবে না।

আমি এখন এই উদাহরণে ব্যবহারিক বিষয়গুলিতে ফিরে আসি।

• প্রথমটি একটি দক্ষ স্কিম। স্কিমার উপর অনেক কিছু নির্ভর করে।
• দ্বিতীয়টি দক্ষ এসকিউএল প্রজন্ম।

একটি সাধারণ OLAP ক্যোয়ারী হল একটি নির্বাচন। কিছু কলাম গ্রুপে যায়, কিছু কলাম সমষ্টিগত ফাংশনে যায়। একটি ঘনক্ষেত্রের একটি টুকরা হিসাবে উপস্থাপিত করা যেতে পারে, যেখানে যেখানে আছে. দ্বারা সমগ্র গ্রুপ একটি অভিক্ষেপ হিসাবে চিন্তা করা যেতে পারে. আর সেই কারণেই একে মাল্টিভেরিয়েট ডেটা অ্যানালাইসিস বলা হয়।

এবং প্রায়শই এটি একটি তারকা-স্কিম আকারে মডেল করা হয়, যখন রশ্মি বরাবর, পার্শ্ব বরাবর এই সত্যটির একটি কেন্দ্রীয় তথ্য এবং বৈশিষ্ট্য থাকে।

এবং শারীরিক নকশার পরিপ্রেক্ষিতে, এটি টেবিলে কীভাবে ফিট করে, তারা সাধারণত একটি স্বাভাবিক উপস্থাপনা করে। আপনি ডিনরমালাইজ করতে পারেন, তবে এটি ডিস্কে ব্যয়বহুল এবং প্রশ্নের ক্ষেত্রে খুব কার্যকর নয়। অতএব, তারা সাধারণত একটি স্বাভাবিক উপস্থাপনা করে, যেমন একটি ফ্যাক্ট টেবিল এবং অনেক, অনেক মাত্রার টেবিল।

কিন্তু এটি ক্লিক হাউসে ভাল কাজ করে না। দুটি কারণ আছে:

• প্রথমটি হল কারণ ClickHouse-এ খুব ভাল যোগদান নেই, অর্থাৎ সেখানে যোগদান আছে, কিন্তু সেগুলো খারাপ। খারাপ থাকাকালীন।
• দ্বিতীয়টি হল যে টেবিলগুলি আপডেট করা হয় না। সাধারণত স্টার-সার্কিটের চারপাশে থাকা এই প্লেটগুলিতে কিছু পরিবর্তন করা দরকার। যেমন গ্রাহকের নাম, কোম্পানির নাম ইত্যাদি। এবং এটা কাজ করে না.

এবং ক্লিকহাউসে এটি থেকে বেরিয়ে আসার একটি উপায় রয়েছে। এমনকি দুটি:

• প্রথমটি অভিধানের ব্যবহার। এক্সটার্নাল ডিকশনারিজ হল যা 99% স্টার-স্কিম, আপডেট সহ সমস্যা সমাধান করতে সাহায্য করে।
• দ্বিতীয়টি হল অ্যারের ব্যবহার। অ্যারেগুলি যোগদান এবং স্বাভাবিককরণের সমস্যা থেকে মুক্তি পেতে সহায়তা করে।

• যোগদানের প্রয়োজন নেই।
• আপগ্রেডযোগ্য। মার্চ 2018 সাল থেকে, অভিধানগুলিকে আংশিকভাবে আপডেট করার জন্য একটি অনথিভুক্ত সুযোগ উপস্থিত হয়েছে (আপনি এটি ডকুমেন্টেশনে পাবেন না), অর্থাৎ যে এন্ট্রিগুলি পরিবর্তিত হয়েছে। কার্যত, এটি একটি টেবিলের মত।
• সবসময় মেমরিতে, তাই ডিস্কে থাকা একটি টেবিলের চেয়ে দ্রুত ডিকশনারি কাজ করে এবং এটি ক্যাশে আছে এমন একটি সত্য নয়, সম্ভবত না।

• আপনার যোগদানেরও দরকার নেই।
• এটি একটি কম্প্যাক্ট 1-থেকে-অনেক প্রতিনিধিত্ব।
• এবং আমার মতে, অ্যারে geeks জন্য তৈরি করা হয়. এগুলো ল্যাম্বডা ফাংশন ইত্যাদি।

এটি লাল শব্দের জন্য নয়। এটি একটি খুব শক্তিশালী কার্যকারিতা যা আপনাকে একটি খুব সহজ এবং মার্জিত উপায়ে অনেক কিছু করতে দেয়।

সাধারণ উদাহরণ যা অ্যারে সমাধান করতে সাহায্য করে। এই উদাহরণগুলি সহজ এবং যথেষ্ট পরিষ্কার:

• ট্যাগ দ্বারা অনুসন্ধান. আপনার যদি সেখানে হ্যাশট্যাগ থাকে এবং হ্যাশট্যাগ দ্বারা কিছু পোস্ট খুঁজে পেতে চান।
• কী-মান জোড়া দ্বারা অনুসন্ধান করুন। একটি মান সঙ্গে কিছু বৈশিষ্ট্য আছে.
• আপনাকে অন্য কিছুতে অনুবাদ করতে হবে এমন কীগুলির তালিকা সংরক্ষণ করা।

এই সমস্ত কাজ অ্যারে ছাড়াই সমাধান করা যেতে পারে। ট্যাগগুলিকে কিছু লাইনে রাখা যেতে পারে এবং একটি রেগুলার এক্সপ্রেশন বা একটি পৃথক টেবিলে নির্বাচন করা যেতে পারে, তবে আপনাকে যোগদান করতে হবে।

এবং ক্লিকহাউসে, আপনাকে কিছু করার দরকার নেই, হ্যাশট্যাগের জন্য স্ট্রিং অ্যারে বর্ণনা করা বা কী-মান সিস্টেমের জন্য একটি নেস্টেড কাঠামো তৈরি করা যথেষ্ট।

নেস্টেড স্ট্রাকচার সেরা নাম নাও হতে পারে। এই দুটি অ্যারে যা নামের একটি সাধারণ অংশ এবং কিছু সম্পর্কিত বৈশিষ্ট্য রয়েছে।

এবং ট্যাগ দ্বারা অনুসন্ধান করা খুব সহজ। একটি ফাংশন আছে has, যা পরীক্ষা করে যে অ্যারেতে একটি উপাদান রয়েছে। সবাই, আমাদের সম্মেলনের সাথে সম্পর্কিত সমস্ত এন্ট্রি পাওয়া গেছে।

সাবিড দ্বারা অনুসন্ধান করা একটু বেশি জটিল। আমাদের প্রথমে কীটির সূচী খুঁজে বের করতে হবে, এবং তারপর এই সূচকটির সাথে উপাদানটি নিতে হবে এবং এই মানটি আমাদের প্রয়োজন কিনা তা পরীক্ষা করতে হবে। যাইহোক, এটি খুব সহজ এবং কমপ্যাক্ট।

আপনি যে রেগুলার এক্সপ্রেশনটি লিখতে চান যদি আপনি এটি সব এক লাইনে রাখেন, এটি হবে, প্রথমত, আনাড়ি। এবং, দ্বিতীয়ত, এটি দুটি অ্যারের চেয়ে অনেক বেশি কাজ করেছে।

আরেকটি উদাহরণ. আপনি আইডি সংরক্ষণ যেখানে আপনি একটি অ্যারে আছে. এবং আপনি তাদের নাম অনুবাদ করতে পারেন. ফাংশন arrayMap. এটি একটি সাধারণ ল্যাম্বডা ফাংশন। আপনি সেখানে ল্যাম্বডা এক্সপ্রেশন পাস. এবং সে অভিধান থেকে প্রতিটি আইডির নামের মান বের করে।

অনুসন্ধান একইভাবে করা যেতে পারে। একটি predicate ফাংশন পাস করা হয় যা উপাদানগুলি কী মেলে তা পরীক্ষা করে।

এই জিনিসগুলি সার্কিটটিকে ব্যাপকভাবে সরল করে এবং একগুচ্ছ সমস্যার সমাধান করে।

কিন্তু পরবর্তী সমস্যা আমরা সম্মুখীন করছি, এবং যা আমি উল্লেখ করতে চাই, দক্ষ প্রশ্ন.

• ClickHouse-এর কোনো প্রশ্ন পরিকল্পনাকারী নেই। একেবারে না.
• তবুও, জটিল প্রশ্নগুলি এখনও পরিকল্পনা করা দরকার। কোন ক্ষেত্রে?
• ক্যোয়ারীতে একাধিক যোগদান থাকলে, আপনি সেগুলিকে উপ-নির্বাচনে মোড়ানো করুন। এবং তাদের মৃত্যুদণ্ড কার্যকর করা হয় তা গুরুত্বপূর্ণ।
• এবং দ্বিতীয় - যদি অনুরোধ বিতরণ করা হয়। কারণ একটি ডিস্ট্রিবিউটেড ক্যোয়ারীতে, শুধুমাত্র সবচেয়ে ভিতরের উপনির্বাচনটি ডিস্ট্রিবিউট করা হয়, এবং বাকি সব কিছু একটি সার্ভারে পাঠানো হয় যার সাথে আপনি কানেক্ট করেছেন এবং সেখানে এক্সিকিউট করেছেন। অতএব, আপনি যদি অনেক যোগদান (যোগদান) সহ প্রশ্নগুলি বিতরণ করে থাকেন তবে আপনাকে অর্ডারটি বেছে নিতে হবে।

এবং এমনকি সহজ ক্ষেত্রে, কখনও কখনও এটি শিডিউলারের কাজ করা এবং প্রশ্নগুলিকে সামান্য পুনঃলিখন করাও প্রয়োজন।

এখানে একটি উদাহরণ. বাম দিকে একটি প্রশ্ন রয়েছে যা শীর্ষ 5টি দেশকে দেখায়। এবং এটি 2,5 সেকেন্ড সময় নেয়, আমার মতে। এবং ডান দিকে, একই প্রশ্ন, কিন্তু সামান্য পুনর্লিখিত. স্ট্রিং দ্বারা গোষ্ঠীভুক্ত করার পরিবর্তে, আমরা কী (int) দ্বারা গোষ্ঠীবদ্ধ করতে শুরু করি। এবং এটি দ্রুততর। এবং তারপর আমরা ফলাফল একটি অভিধান সংযুক্ত. 2,5 সেকেন্ডের পরিবর্তে, অনুরোধটি 1,5 সেকেন্ড সময় নেয়। এটা ভাল.

ফিল্টার পুনর্লিখনের সাথে একটি অনুরূপ উদাহরণ। এখানে রাশিয়ার জন্য একটি অনুরোধ। এটি 5 সেকেন্ডের জন্য চলে। যদি আমরা এটিকে এমনভাবে লিখি যে আমরা আবার কোন স্ট্রিং নয়, তবে রাশিয়ার সাথে সম্পর্কিত সেই কীগুলির কিছু সেটের সাথে সংখ্যার তুলনা করি, তবে এটি আরও দ্রুত হবে।

এরকম অনেক কৌশল আছে। এবং তারা আপনাকে উল্লেখযোগ্যভাবে এমন প্রশ্নের গতি বাড়ানোর অনুমতি দেয় যা আপনি মনে করেন যে ইতিমধ্যেই দ্রুত চলছে, বা বিপরীতভাবে, ধীরে চলছে। এগুলি আরও দ্রুত তৈরি করা যেতে পারে।

• বিতরণ মোডে সর্বাধিক কাজ।
• ন্যূনতম ধরনের দ্বারা বাছাই, আমি ints দ্বারা কি হিসাবে.
• যদি কোনও যোগদান (যোগদান), অভিধান থাকে, তবে শেষ অবলম্বন হিসাবে সেগুলি করা আরও ভাল, যখন আপনার কাছে ইতিমধ্যে ডেটা কমপক্ষে আংশিকভাবে গোষ্ঠীবদ্ধ থাকে, তখন যোগদান অপারেশন বা অভিধান কলটি কম বার কল করা হবে এবং এটি দ্রুততর হবে। .
• ফিল্টার প্রতিস্থাপন.

অন্যান্য কৌশল আছে, এবং আমি যে প্রদর্শন করেছি শুধু না. এবং এগুলি সবই কখনও কখনও প্রশ্নের সম্পাদনকে উল্লেখযোগ্যভাবে ত্বরান্বিত করতে পারে।

এর পরবর্তী উদাহরণে যাওয়া যাক। মার্কিন যুক্তরাষ্ট্র থেকে কোম্পানি এক্স। সে কি করছে?

একটি কাজ ছিল:

• বিজ্ঞাপন লেনদেনের অফলাইন লিঙ্কিং।
• মডেলিং বিভিন্ন বাঁধাই মডেল.

দৃশ্যকল্প কি?

একজন সাধারণ ভিজিটর সাইটে আসে, উদাহরণস্বরূপ, বিভিন্ন বিজ্ঞাপন থেকে মাসে 20 বার, বা ঠিক সেরকম কখনও কখনও কোনও বিজ্ঞাপন ছাড়াই আসে, কারণ সে এই সাইটের কথা মনে রাখে। কিছু পণ্য দেখে, ঝুড়িতে রাখে, ঝুড়ি থেকে বের করে। এবং, শেষ পর্যন্ত, কিছু কেনে।

যুক্তিসঙ্গত প্রশ্ন: "প্রয়োজনে কার বিজ্ঞাপনের জন্য অর্থ প্রদান করা উচিত?" এবং "কোন বিজ্ঞাপন তাকে প্রভাবিত করেছে, যদি থাকে?"। অর্থাৎ তিনি কেন কিনলেন এবং কীভাবে এই ব্যক্তির মতো লোককেও কিনতে পাবেন?

এই সমস্যাটি সমাধান করার জন্য, আপনাকে সঠিক উপায়ে ওয়েবসাইটে ঘটতে থাকা ইভেন্টগুলিকে সংযুক্ত করতে হবে, অর্থাৎ তাদের মধ্যে কোনওভাবে সংযোগ তৈরি করতে হবে। তারপর তাদের ডিডব্লিউএইচ-এ বিশ্লেষণের জন্য পাঠানো হয়। এবং এই বিশ্লেষণের উপর ভিত্তি করে, কাকে এবং কি বিজ্ঞাপন দেখানো হবে তার মডেল তৈরি করুন।

একটি বিজ্ঞাপন লেনদেন হল সংশ্লিষ্ট ব্যবহারকারীর ইভেন্টগুলির একটি সেট যা একটি বিজ্ঞাপন দেখানো থেকে শুরু হয়, তারপরে কিছু ঘটে, তারপরে একটি কেনাকাটা হতে পারে এবং তারপরে একটি ক্রয়ের মধ্যে কেনাকাটা হতে পারে। উদাহরণস্বরূপ, যদি এটি একটি মোবাইল অ্যাপ্লিকেশন বা একটি মোবাইল গেম হয় তবে সাধারণত অ্যাপ্লিকেশনটির ইনস্টলেশনটি বিনামূল্যে হয় এবং যদি সেখানে কিছু করা হয় তবে এর জন্য অর্থের প্রয়োজন হতে পারে। এবং অ্যাপ্লিকেশনটিতে একজন ব্যক্তি যত বেশি ব্যয় করেন, তত বেশি মূল্যবান। তবে এর জন্য আপনাকে সবকিছু সংযুক্ত করতে হবে।

অনেক বাঁধাই মডেল আছে.

সবচেয়ে জনপ্রিয় হল:

• শেষ ইন্টারঅ্যাকশন, যেখানে মিথস্ক্রিয়া হয় একটি ক্লিক বা একটি ইমপ্রেশন।
• প্রথম ইন্টারঅ্যাকশন, অর্থাৎ প্রথম জিনিস যা একজন ব্যক্তিকে সাইটে নিয়ে আসে।
• রৈখিক সমন্বয় - সব সমানভাবে।
• মনোযোগ
• ইত্যাদি।

এবং কিভাবে এটি সব প্রথম স্থানে কাজ করেনি? রানটাইম এবং ক্যাসান্দ্রা ছিল। ক্যাসান্দ্রা লেনদেন স্টোরেজ হিসাবে ব্যবহার করা হয়েছিল, অর্থাত্ সমস্ত সম্পর্কিত লেনদেন এটিতে সংরক্ষিত ছিল। এবং যখন রানটাইমে কিছু ইভেন্ট আসে, উদাহরণস্বরূপ, কিছু পৃষ্ঠা বা অন্য কিছু দেখানো, তখন ক্যাসান্দ্রার কাছে একটি অনুরোধ করা হয়েছিল - এমন একজন ব্যক্তি আছে কি না। তারপর এর সাথে সম্পর্কিত লেনদেনগুলি পাওয়া গেল। এবং সংযোগ তৈরি হয়েছিল।

এবং যদি ভাগ্যবান হয় যে অনুরোধটির একটি লেনদেন আইডি আছে, তাহলে এটি সহজ। কিন্তু সাধারণত ভাগ্য নেই। অতএব, শেষ লেনদেন বা শেষ ক্লিকের মাধ্যমে লেনদেন ইত্যাদি খুঁজে বের করা প্রয়োজন ছিল।

এবং যতক্ষণ পর্যন্ত বাইন্ডিং শেষ ক্লিকে ছিল ততক্ষণ এটি সবই খুব ভাল কাজ করেছে। কারণ আছে, বলুন, প্রতিদিন 10 মিলিয়ন ক্লিক, প্রতি মাসে 300 মিলিয়ন, যদি আমরা এক মাসের জন্য একটি উইন্ডো সেট করি। এবং যেহেতু ক্যাসান্ড্রাতে দ্রুত চালানোর জন্য এটি সমস্ত মেমরিতে থাকতে হবে, কারণ রানটাইমকে দ্রুত প্রতিক্রিয়া জানাতে হবে, এটি প্রায় 10-15 সার্ভার নেয়।

এবং যখন তারা ডিসপ্লেতে একটি লেনদেন লিঙ্ক করতে চেয়েছিল, এটি অবিলম্বে এত মজার নয়। এবং কেন? এটি দেখা যায় যে 30 গুণ বেশি ইভেন্ট সংরক্ষণ করা প্রয়োজন। এবং, সেই অনুযায়ী, আপনার 30 গুণ বেশি সার্ভার প্রয়োজন। এবং এটি দেখা যাচ্ছে যে এটি এক ধরণের জ্যোতির্বিজ্ঞানের চিত্র। রানটাইমে উল্লেখযোগ্যভাবে কম সার্ভার থাকা সত্ত্বেও লিঙ্কিং করার জন্য 500 সার্ভার পর্যন্ত রাখা, তাহলে এটি একধরনের ভুল চিত্র। আর তারা ভাবতে লাগলো কি করা যায়।

এবং আমরা ক্লিক হাউস গিয়েছিলাম. এবং ClickHouse এ কিভাবে করবেন? প্রথম নজরে, মনে হচ্ছে এটি বিরোধী প্যাটার্নগুলির একটি সেট।

• লেনদেন বাড়তে থাকে, আমরা এতে আরো বেশি ইভেন্ট সংযুক্ত করি, অর্থাৎ এটি পরিবর্তনযোগ্য, এবং ClickHouse পরিবর্তনযোগ্য বস্তুর সাথে খুব ভালোভাবে কাজ করে না।
• যখন একজন ভিজিটর আমাদের কাছে আসে, তখন আমাদের তার ভিজিট আইডি দ্বারা চাবির মাধ্যমে তার লেনদেন বের করতে হবে। এটিও একটি পয়েন্ট কোয়েরি, তারা ক্লিকহাউসে তা করে না। সাধারণত ক্লিকহাউসে বড় …স্ক্যান থাকে, কিন্তু এখানে আমাদের কিছু রেকর্ড পেতে হবে। এছাড়াও একটি অ্যান্টিপ্যাটার্ন।
• উপরন্তু, লেনদেনটি json-এ ছিল, কিন্তু তারা এটি পুনরায় লিখতে চায়নি, তাই তারা json কে একটি অসংগঠিত উপায়ে সঞ্চয় করতে চেয়েছিল এবং প্রয়োজনে এটি থেকে কিছু বের করে আনতে চেয়েছিল। এবং এটিও একটি অ্যান্টিপ্যাটার্ন।

যে, antipatterns একটি সেট.

তবে তবুও এটি এমন একটি সিস্টেম তৈরি করতে পরিণত হয়েছে যা খুব ভাল কাজ করেছে।

কি করা হয়েছিল? ক্লিক হাউস উপস্থিত হয়েছিল, যেখানে লগগুলি নিক্ষেপ করা হয়েছিল, রেকর্ডে বিভক্ত। একটি বৈশিষ্ট্যযুক্ত পরিষেবা উপস্থিত হয়েছে যা ক্লিকহাউস থেকে লগ পেয়েছে৷ এর পরে, প্রতিটি এন্ট্রির জন্য, ভিজিট আইডি দ্বারা, আমি এমন লেনদেন পেয়েছি যেগুলি এখনও প্রক্রিয়া করা হয়নি এবং আরও স্ন্যাপশটগুলি, যেমন লেনদেনগুলি ইতিমধ্যেই সংযুক্ত, যথা পূর্ববর্তী কাজের ফলাফল৷ আমি ইতিমধ্যে তাদের থেকে যুক্তি তৈরি করেছি, সঠিক লেনদেন বেছে নিয়েছি, নতুন ইভেন্ট সংযুক্ত করেছি। আবার লগ ইন. লগটি ক্লিক হাউসে ফিরে গেছে, অর্থাৎ এটি একটি ক্রমাগত চক্রাকার সিস্টেম। এবং তাছাড়া, আমি সেখানে এটি বিশ্লেষণ করতে DWH গিয়েছিলাম।

এটি এই ফর্মে ছিল যে এটি খুব ভাল কাজ করেনি। এবং ClickHouse-এর জন্য এটি সহজ করার জন্য, যখন ভিজিট আইডি দ্বারা একটি অনুরোধ ছিল, তারা এই অনুরোধগুলিকে 1-000 ভিজিট আইডির ব্লকে গোষ্ঠীভুক্ত করে এবং 2-000 জনের জন্য সমস্ত লেনদেন বের করে দেয়৷ এবং তারপর এটা সব কাজ.

আপনি যদি ClickHouse এর ভিতরে তাকান, তাহলে সেখানে শুধুমাত্র 3টি প্রধান টেবিল রয়েছে যা এই সব পরিবেশন করে।

প্রথম টেবিল যেখানে লগ আপলোড করা হয় এবং লগগুলি প্রায় প্রক্রিয়াকরণ ছাড়াই আপলোড করা হয়৷

দ্বিতীয় টেবিল। বস্তুগত দৃষ্টিভঙ্গির মাধ্যমে, যে ঘটনাগুলিকে এখনও দায়ী করা হয়নি, যেমন, সম্পর্কহীন, এই লগগুলি থেকে কামড় দেওয়া হয়েছিল। এবং বস্তুগত দৃশ্যের মাধ্যমে, একটি স্ন্যাপশট তৈরি করতে এই লগগুলি থেকে লেনদেনগুলি টেনে আনা হয়েছিল৷ অর্থাৎ, একটি বিশেষ বস্তুগত দৃশ্য একটি স্ন্যাপশট তৈরি করেছে, যথা লেনদেনের শেষ সঞ্চিত অবস্থা।

এখানে এসকিউএল লেখা আছে। আমি এতে কয়েকটি গুরুত্বপূর্ণ বিষয়ে মন্তব্য করতে চাই।

প্রথম গুরুত্বপূর্ণ বিষয় হল ক্লিকহাউসে json থেকে কলাম এবং ক্ষেত্রগুলি বের করার ক্ষমতা। অর্থাৎ, json এর সাথে কাজ করার জন্য ClickHouse এর কিছু পদ্ধতি রয়েছে। তারা খুব, খুব আদিম.

visitParamExtractInt আপনাকে json থেকে অ্যাট্রিবিউট বের করতে দেয়, যেমন প্রথম হিট কাজ করে। এবং এইভাবে আপনি লেনদেন আইডি বা ভিজিট আইডি বের করতে পারেন। এইবার.

দ্বিতীয়ত, একটি জটিল বস্তুগত ক্ষেত্র এখানে ব্যবহার করা হয়েছে। এর মানে কী? এর মানে হল যে আপনি এটি টেবিলে ঢোকাতে পারবেন না, অর্থাৎ এটি ঢোকানো হয় না, এটি গণনা করা হয় এবং সন্নিবেশের পরে সংরক্ষণ করা হয়। পেস্ট করার সময়, ক্লিক হাউস আপনার জন্য কাজ করে। এবং আপনি পরে যা প্রয়োজন তা ইতিমধ্যেই json থেকে টানা হয়েছে।

এই ক্ষেত্রে, বস্তুগত দৃশ্য কাঁচা সারির জন্য। এবং কার্যত কাঁচা লগ সহ প্রথম টেবিলটি ব্যবহার করা হয়। এবং তিনি কি করবেন না? প্রথমত, এটি সাজানোর পরিবর্তন করে, যেমন এখন সাজানো ভিজিট আইডি দ্বারা যায়, কারণ আমাদের দ্রুত একজন নির্দিষ্ট ব্যক্তির জন্য তার লেনদেন বের করতে হবে।

দ্বিতীয় গুরুত্বপূর্ণ বিষয় হল index_granularity. আপনি যদি MergeTree দেখে থাকেন তবে এটি সাধারণত 8 ডিফল্ট index_granularity হয়। এটা কি? এই সূচক sparseness পরামিতি. ক্লিকহাউসে সূচীটি বিরল, এটি কখনই প্রতিটি এন্ট্রিকে সূচী করে না। এটি প্রতি 192 এ এটি করে। এবং এটি ভাল যখন প্রচুর ডেটা গণনা করার প্রয়োজন হয়, তবে সামান্য হলে খারাপ, কারণ একটি বড় ওভারহেড রয়েছে। এবং যদি আমরা সূচক গ্রানুলারিটি কম করি, তাহলে আমরা ওভারহেড কমিয়ে দিই। এটি একটি কমানো যাবে না, কারণ যথেষ্ট স্মৃতি নাও থাকতে পারে। সূচক সবসময় মেমরিতে সংরক্ষণ করা হয়।

স্ন্যাপশট আরও কিছু আকর্ষণীয় ক্লিকহাউস বৈশিষ্ট্য ব্যবহার করে।

প্রথমত, এটি AggregatingMergeTree। এবং AggregatingMergeTree argMax সঞ্চয় করে, অর্থাৎ এটি শেষ টাইমস্ট্যাম্পের সাথে সম্পর্কিত লেনদেনের অবস্থা। লেনদেন একটি প্রদত্ত দর্শকের জন্য সব সময় উত্পন্ন হয়. এবং এই লেনদেনের একেবারে শেষ অবস্থায়, আমরা একটি ইভেন্ট যোগ করেছি এবং আমাদের একটি নতুন রাষ্ট্র আছে। এটা আবার ক্লিক হাউস আঘাত. এবং এই বস্তুগত দৃশ্যে argMax এর মাধ্যমে, আমরা সর্বদা বর্তমান অবস্থা পেতে পারি।

• বাইন্ডিং রানটাইম থেকে "ডিকুপল" হয়।
• প্রতি মাসে 3 বিলিয়ন পর্যন্ত লেনদেন সংরক্ষণ এবং প্রক্রিয়া করা হয়। এটি ক্যাসান্দ্রার চেয়ে বেশি মাত্রার একটি আদেশ, অর্থাৎ একটি সাধারণ লেনদেন ব্যবস্থায়।
• 2x5 ক্লিকহাউস সার্ভারের ক্লাস্টার। 5 সার্ভার এবং প্রতিটি সার্ভার একটি প্রতিরূপ আছে. ক্লিক ভিত্তিক অ্যাট্রিবিউশন করার জন্য এটি ক্যাসান্দ্রার চেয়েও কম, এবং এখানে আমাদের ইম্প্রেশন ভিত্তিক আছে। অর্থাৎ, সার্ভারের সংখ্যা 30 গুণ বাড়ানোর পরিবর্তে, তারা সেগুলি হ্রাস করতে সক্ষম হয়েছিল।

এবং শেষ উদাহরণ হল আর্থিক কোম্পানি Y, যা স্টকের দামের পরিবর্তনের পারস্পরিক সম্পর্ক বিশ্লেষণ করে।

এবং কাজটি ছিল:

• প্রায় 5 শেয়ার রয়েছে।
• প্রতি 100 মিলিসেকেন্ডে উদ্ধৃতি জানা যায়।
• তথ্য 10 বছর ধরে জমা করা হয়েছে. দৃশ্যত, কিছু কোম্পানির জন্য বেশি, কিছুর জন্য কম।
• মোট আনুমানিক 100 বিলিয়ন সারি আছে।

এবং পরিবর্তনের পারস্পরিক সম্পর্ক গণনা করা প্রয়োজন ছিল।

এখানে দুটি স্টক এবং তাদের উদ্ধৃতি আছে. যদি একটি উপরে যায় এবং অন্যটি উপরে যায়, তবে এটি একটি ইতিবাচক সম্পর্ক, অর্থাৎ একটি উপরে যায় এবং অন্যটি উপরে যায়। যদি একটি উপরে যায়, যেমন গ্রাফের শেষে, এবং অন্যটি নিচে যায়, তাহলে এটি একটি নেতিবাচক সম্পর্ক, অর্থাৎ যখন একটি উঠে যায়, অন্যটি পড়ে যায়।

এই পারস্পরিক পরিবর্তনগুলি বিশ্লেষণ করে, কেউ আর্থিক বাজারে ভবিষ্যদ্বাণী করতে পারে।

কিন্তু কাজটা কঠিন। এই জন্য কি করা হচ্ছে? আমাদের কাছে 100 বিলিয়ন রেকর্ড রয়েছে যা আছে: সময়, স্টক এবং মূল্য। আমাদের মূল্য অ্যালগরিদম থেকে চলমান পার্থক্যের প্রথম 100 বিলিয়ন গুণ গণনা করতে হবে। RunningDifference হল ClickHouse-এর একটি ফাংশন যা ক্রমানুসারে দুটি স্ট্রিংয়ের মধ্যে পার্থক্য গণনা করে।

এবং এর পরে, আপনাকে পারস্পরিক সম্পর্ক গণনা করতে হবে এবং প্রতিটি জোড়ার জন্য পারস্পরিক সম্পর্ক গণনা করতে হবে। 5 শেয়ারের জন্য, জোড়া 000 মিলিয়ন। এবং এটি অনেক, অর্থাত্ 12,5 বার এই ধরনের একটি পারস্পরিক সম্পর্ক ফাংশন গণনা করা প্রয়োজন।

এবং যদি কেউ ভুলে যায়, তাহলে ͞x এবং ͞y হল চেকমেট। নমুনা প্রত্যাশা। অর্থাৎ, শুধুমাত্র মূল এবং যোগফল গণনা করা নয়, এই রাশিগুলির ভিতরে আরও একটি যোগফলও প্রয়োজন। গণনার একটি গুচ্ছ 12,5 মিলিয়ন বার করা প্রয়োজন, এবং এমনকি ঘন্টা দ্বারা গোষ্ঠীবদ্ধ। আমাদেরও অনেক ঘন্টা আছে। এবং আপনাকে এটি 60 সেকেন্ডের মধ্যে করতে হবে। এটা একটা রসিকতা.

অন্তত কোনওভাবে সময় থাকা দরকার ছিল, কারণ ক্লিকহাউস আসার আগে এই সমস্ত খুব, খুব ধীরে ধীরে কাজ করেছিল।

তারা হ্যাডুপে, স্পার্কে, গ্রিনপ্লামে এটি গণনা করার চেষ্টা করেছিল। এবং এই সব খুব ধীর বা ব্যয়বহুল ছিল. যে, এটি একরকম গণনা করা সম্ভব ছিল, কিন্তু তারপর এটি ব্যয়বহুল ছিল।

এবং তারপর ক্লিক হাউস বরাবর এসেছিল এবং জিনিসগুলি আরও ভাল হয়েছে।

আমি আপনাকে মনে করিয়ে দিচ্ছি যে ডেটা লোকেলিটির সাথে আমাদের একটি সমস্যা আছে, কারণ পারস্পরিক সম্পর্ক স্থানীয়করণ করা যায় না। আমরা কিছু ডেটা এক সার্ভারে, কিছু অন্য সার্ভারে রাখতে পারি না এবং গণনা করতে পারি, আমাদের সর্বত্র সমস্ত ডেটা থাকতে হবে।

তারা কী করেছিলো? প্রাথমিকভাবে, তথ্য স্থানীয়করণ করা হয়. প্রতিটি সার্ভার শেয়ারের একটি নির্দিষ্ট সেটের মূল্যের উপর ডেটা সঞ্চয় করে। এবং তারা ওভারল্যাপ না. অতএব, সমান্তরাল এবং স্বাধীনভাবে logReturn গণনা করা সম্ভব, এই সমস্ত কিছুই সমান্তরাল এবং বিতরণ করা হয়েছে।

তারপরে আমরা অভিব্যক্তি হারাতে না গিয়ে এই ডেটাগুলি হ্রাস করার সিদ্ধান্ত নিয়েছি। অ্যারে ব্যবহার কম করুন, অর্থাৎ প্রতিটি সময়ের জন্য, স্টকের একটি অ্যারে এবং দামের অ্যারে তৈরি করুন। অতএব, এটি অনেক কম ডেটা স্থান নেয়। এবং তাদের সাথে কাজ করা একটু সহজ। এগুলি প্রায় সমান্তরাল ক্রিয়াকলাপ, যেমন আমরা আংশিকভাবে সমান্তরালে পড়ি এবং তারপর সার্ভারে লিখি।

এর পরে, এটি প্রতিলিপি করা যেতে পারে। "r" অক্ষরটির অর্থ হল যে আমরা এই ডেটা প্রতিলিপি করেছি। অর্থাৎ, আমাদের তিনটি সার্ভারে একই ডেটা রয়েছে - এইগুলি অ্যারে।

এবং তারপরে 12,5 মিলিয়ন পারস্পরিক সম্পর্কগুলির এই সেট থেকে একটি বিশেষ স্ক্রিপ্টের সাথে যা গণনা করা দরকার, আপনি প্যাকেজ তৈরি করতে পারেন। অর্থাৎ, 2 জোড়া পারস্পরিক সম্পর্ক সহ 500টি কার্য। এবং এই কাজটি একটি নির্দিষ্ট ClickHouse সার্ভারে গণনা করতে হয়। তার কাছে সমস্ত ডেটা রয়েছে, কারণ ডেটা একই এবং তিনি সেগুলি ক্রমানুসারে গণনা করতে পারেন।

আবার, এটা কি মনে হচ্ছে. প্রথমত, আমাদের কাছে এই কাঠামোর সমস্ত ডেটা রয়েছে: সময়, শেয়ার, মূল্য। তারপরে আমরা logReturn গণনা করেছি, অর্থাৎ একই কাঠামোর ডেটা, কিন্তু মূল্যের পরিবর্তে আমাদের ইতিমধ্যেই logReturn আছে। তারপরে সেগুলি আবার করা হয়েছিল, অর্থাৎ আমরা স্টক এবং দামের জন্য সময় এবং গ্রুপ অ্যারে পেয়েছি। Sreplicated. এবং এর পরে, আমরা একগুচ্ছ টাস্ক তৈরি করেছি এবং সেগুলিকে ক্লিক হাউসে দিয়েছি যাতে এটি তাদের গণনা করে। এবং এটি কাজ করে।

ধারণার প্রমাণে, টাস্কটি একটি সাবটাস্ক ছিল, অর্থাৎ, কম ডেটা নেওয়া হয়েছিল। আর মাত্র তিনটি সার্ভার।

এই প্রথম দুটি পর্যায়: Log_return গণনা করা এবং অ্যারেতে মোড়ানো প্রায় এক ঘন্টা সময় নেয়।

এবং পারস্পরিক সম্পর্কের হিসাব প্রায় 50 ঘন্টা। কিন্তু 50 ঘন্টা যথেষ্ট নয়, কারণ তারা সপ্তাহ ধরে কাজ করত। এটি একটি বড় সাফল্য ছিল. এবং যদি আপনি গণনা করেন, তাহলে প্রতি সেকেন্ডে 70 বার সবকিছু এই ক্লাস্টারে গণনা করা হয়েছিল।

কিন্তু সবচেয়ে গুরুত্বপূর্ণ বিষয় হল এই সিস্টেমটি কার্যত কোন বাধা ছাড়াই, অর্থাৎ, এটি প্রায় রৈখিকভাবে স্কেল করে। এবং তারা এটা চেক আউট. সফলভাবে এটি স্কেল আপ.

• সঠিক পরিকল্পনা অর্ধেক সাফল্য। এবং সঠিক স্কিম হল সমস্ত প্রয়োজনীয় ClickHouse প্রযুক্তির ব্যবহার।
• Summing/AggregatingMergeTrees হল এমন প্রযুক্তি যা আপনাকে একটি রাষ্ট্রীয় স্ন্যাপশটকে একটি বিশেষ ক্ষেত্রে একত্রিত করতে বা বিবেচনা করতে দেয়। এবং এটি ব্যাপকভাবে অনেক কিছু সহজ করে তোলে।
• ম্যাটেরিয়ালাইজড ভিউ আপনাকে একটি সূচক সীমা বাইপাস করতে দেয়। হয়তো আমি এটি খুব স্পষ্টভাবে বলিনি, কিন্তু যখন আমরা লগগুলি লোড করি, তখন কাঁচা লগগুলি একটি সূচী সহ টেবিলে ছিল, এবং বৈশিষ্ট্য লগগুলি টেবিলে ছিল, অর্থাত্ একই ডেটা, শুধুমাত্র ফিল্টার করা হয়েছিল, তবে সূচকটি সম্পূর্ণ ছিল অন্যান্য. এটি একই ডেটা বলে মনে হচ্ছে, কিন্তু ভিন্ন সাজানো। এবং ম্যাটেরিয়ালাইজড ভিউ আপনাকে অনুমতি দেয়, যদি আপনার প্রয়োজন হয়, এই ধরনের ক্লিকহাউসের সীমাবদ্ধতা বাইপাস করতে।
• পয়েন্ট প্রশ্নের জন্য সূচক গ্রানুলারিটি হ্রাস করুন।
• এবং স্মার্টভাবে ডেটা বিতরণ করুন, যতটা সম্ভব সার্ভারের মধ্যে ডেটা স্থানীয়করণ করার চেষ্টা করুন। এবং নিশ্চিত করার চেষ্টা করুন যে অনুরোধগুলি যতটা সম্ভব স্থানীয়করণ ব্যবহার করে।

এবং এই সংক্ষিপ্ত বক্তৃতার সংক্ষিপ্তসারে, আমরা বলতে পারি যে ClickHouse এখন বাণিজ্যিক ডাটাবেস এবং ওপেন সোর্স ডাটাবেস উভয়ের অঞ্চলকে দৃঢ়ভাবে দখল করেছে, অর্থাৎ বিশেষত বিশ্লেষণের জন্য। তিনি এই ল্যান্ডস্কেপ মধ্যে পুরোপুরি ফিট. এবং আরও কী, এটি ধীরে ধীরে অন্যদের ভিড় করতে শুরু করে, কারণ আপনার যখন ক্লিকহাউস থাকে, তখন আপনার InfiniDB-এর প্রয়োজন হয় না। তারা স্বাভাবিক SQL সমর্থন করলে Vertika শীঘ্রই প্রয়োজন নাও হতে পারে। উপভোগ করুন!

-প্রতিবেদনের জন্য ধন্যবাদ! অনেক আগ্রহব্যাঞ্জক! অ্যাপাচি ফিনিক্সের সাথে কোন তুলনা ছিল?

না, আমি কাউকে তুলনা করতে শুনিনি। আমরা এবং ইয়ানডেক্স বিভিন্ন ডাটাবেসের সাথে ক্লিক হাউসের সমস্ত তুলনার ট্র্যাক রাখার চেষ্টা করি। কারণ যদি হঠাৎ কিছু ক্লিকহাউসের চেয়ে দ্রুততর হতে দেখা যায়, তবে লেশা মিলোভিডভ রাতে ঘুমাতে পারে না এবং দ্রুত গতি বাড়াতে শুরু করে। এমন তুলনা আমি শুনিনি।

• (আলেক্সি মিলোভিডভ) অ্যাপাচি ফিনিক্স হল একটি এসকিউএল ইঞ্জিন যা Hbase দ্বারা চালিত। Hbase প্রধানত মূল-মান কাজের দৃশ্যের জন্য। সেখানে, প্রতিটি লাইনে, ইচ্ছামত নাম সহ কলামের একটি নির্বিচারে সংখ্যা থাকতে পারে। এটি Hbase, Cassandra এর মতো সিস্টেম সম্পর্কে বলা যেতে পারে। এবং এটি সঠিকভাবে ভারী বিশ্লেষণাত্মক প্রশ্ন যা তাদের জন্য সাধারণত কাজ করবে না। অথবা আপনি ভাবতে পারেন যে ক্লিকহাউসের সাথে আপনার কোন অভিজ্ঞতা না থাকলে তারা ভাল কাজ করে।

• Спасибо

  • শুভ অপরাহ্ন আমি ইতিমধ্যে এই বিষয়ে বেশ আগ্রহী, কারণ আমার একটি বিশ্লেষণাত্মক সাবসিস্টেম আছে। কিন্তু যখন আমি ClickHouse দেখি, তখন আমি অনুভব করি যে ClickHouse ইভেন্ট বিশ্লেষণের জন্য খুবই উপযুক্ত, পরিবর্তনযোগ্য। এবং যদি আমাকে একগুচ্ছ বড় টেবিলের সাথে প্রচুর ব্যবসায়িক ডেটা বিশ্লেষণ করতে হয়, তবে ক্লিকহাউস, যতদূর আমি বুঝি, আমার জন্য খুব উপযুক্ত নয়? বিশেষ করে যদি তারা পরিবর্তন হয়। এটি কি সঠিক বা এমন উদাহরণ আছে যা এটি খণ্ডন করতে পারে?

  • এটা ঠিক। এবং এটি বেশিরভাগ বিশেষ বিশ্লেষণাত্মক ডাটাবেসের ক্ষেত্রে সত্য। এগুলি এই জন্য তৈরি করা হয়েছে যে এক বা একাধিক বড় টেবিল রয়েছে যেগুলি পরিবর্তনযোগ্য এবং অনেকগুলি ছোটগুলির জন্য যা ধীরে ধীরে পরিবর্তিত হয়৷ অর্থাৎ, ক্লিক হাউস ওরাকলের মতো নয়, যেখানে আপনি সবকিছু রাখতে পারেন এবং কিছু জটিল প্রশ্ন তৈরি করতে পারেন। ClickHouse কার্যকরভাবে ব্যবহার করার জন্য, আপনাকে এমনভাবে একটি স্কিম তৈরি করতে হবে যা ক্লিকহাউসে ভাল কাজ করে। অর্থাৎ, অতিরিক্ত স্বাভাবিককরণ এড়িয়ে চলুন, অভিধান ব্যবহার করুন, কম লম্বা লিঙ্ক তৈরি করার চেষ্টা করুন। এবং যদি স্কিমটি এইভাবে তৈরি করা হয়, তাহলে অনুরূপ ব্যবসায়িক কাজগুলি একটি ঐতিহ্যগত রিলেশনাল ডাটাবেসের চেয়ে ক্লিকহাউসে অনেক বেশি দক্ষতার সাথে সমাধান করা যেতে পারে।

প্রতিবেদনের জন্য ধন্যবাদ! সর্বশেষ আর্থিক কেস সম্পর্কে আমার একটি প্রশ্ন আছে। তাদের বিশ্লেষণ ছিল। তারা কীভাবে উপরে এবং নীচে যায় তা তুলনা করা দরকার ছিল। এবং আমি বুঝতে পারি যে আপনি এই বিশ্লেষণের জন্য বিশেষভাবে সিস্টেমটি তৈরি করেছেন? যদি আগামীকাল, উদাহরণস্বরূপ, তাদের এই ডেটার উপর অন্য কিছু প্রতিবেদনের প্রয়োজন হয়, তাহলে তাদের কি স্কিমাটি পুনরায় তৈরি করতে হবে এবং ডেটা আপলোড করতে হবে? অর্থাৎ রিকোয়েস্ট পাওয়ার জন্য কোনো ধরনের প্রিপ্রসেসিং করতে হবে?

অবশ্যই, এটি একটি খুব নির্দিষ্ট কাজের জন্য ক্লিকহাউসের ব্যবহার। এটা আরো ঐতিহ্যগতভাবে Hadoop মধ্যে সমাধান করা যেতে পারে. Hadoop জন্য, এটি একটি আদর্শ কাজ. কিন্তু Hadoop এ এটি খুব ধীর। এবং আমার লক্ষ্য হল প্রদর্শন করা যে ClickHouse কাজগুলিকে সমাধান করতে পারে যা সাধারণত সম্পূর্ণ ভিন্ন উপায়ে সমাধান করা হয়, কিন্তু একই সময়ে এটি আরও দক্ষতার সাথে করতে পারে। এটি একটি নির্দিষ্ট কাজের জন্য তৈরি করা হয়েছে। এটা স্পষ্ট যে অনুরূপ কিছুর সাথে যদি সমস্যা থাকে তবে এটি একইভাবে সমাধান করা যেতে পারে।

এটা পরিস্কার. আপনি বলেছেন যে 50 ঘন্টা প্রক্রিয়া করা হয়েছে। এটা কি প্রথম থেকেই, আপনি কখন ডাটা লোড করেছেন বা ফলাফল পেয়েছেন?

হ্যা হ্যা.

ঠিক আছে, অনেক ধন্যবাদ তোমাকে.

এটি একটি 3 সার্ভার ক্লাস্টারে রয়েছে।

শুভেচ্ছা! প্রতিবেদনের জন্য ধন্যবাদ! সবকিছু খুব আকর্ষণীয়. আমি কার্যকারিতা সম্পর্কে একটু জিজ্ঞাসা করব না, তবে স্থিতিশীলতার ক্ষেত্রে ক্লিকহাউসের ব্যবহার সম্পর্কে। অর্থাৎ, আপনার কি কোনটি ছিল, আপনাকে কি পুনরুদ্ধার করতে হবে? এই ক্ষেত্রে ClickHouse কিভাবে আচরণ করে? এবং এটা কি ঘটেছে যে আপনার একটি প্রতিরূপ ছিল? উদাহরণস্বরূপ, আমরা ক্লিক হাউসে একটি সমস্যার সম্মুখীন হয়েছি যখন এটি এখনও তার সীমার বাইরে চলে যায় এবং পড়ে যায়।

অবশ্যই, কোন আদর্শ সিস্টেম আছে. এবং ক্লিক হাউসেরও নিজস্ব সমস্যা রয়েছে। কিন্তু আপনি Yandex.Metrica সম্পর্কে শুনেছেন যে দীর্ঘদিন ধরে কাজ করছে না? সম্ভবত না. এটি ক্লিকহাউসে 2012-2013 সাল থেকে নির্ভরযোগ্যভাবে কাজ করছে। আমি আমার অভিজ্ঞতা সম্পর্কে একই বলতে পারেন. আমাদের কখনই সম্পূর্ণ ব্যর্থতা ছিল না। কিছু আংশিক জিনিস ঘটতে পারে, কিন্তু সেগুলি ব্যবসাকে গুরুতরভাবে প্রভাবিত করার জন্য যথেষ্ট সমালোচনামূলক ছিল না। এটা কখনো হয়নি। ClickHouse বেশ নির্ভরযোগ্য এবং এলোমেলোভাবে ক্র্যাশ হয় না। আপনাকে এটা নিয়ে চিন্তা করতে হবে না। এটা কোন কাঁচা জিনিস না. এটি অনেক কোম্পানি দ্বারা প্রমাণিত হয়েছে।

হ্যালো! আপনি বলেছেন যে আপনাকে এখনই ডেটা স্কিমা নিয়ে ভাবতে হবে। তা হলে কি হবে? আমার তথ্য ঢালা এবং ঢালা হয়. ছয় মাস কেটে যায়, এবং আমি বুঝতে পারি যে এভাবে বেঁচে থাকা অসম্ভব, আমাকে ডেটা পুনরায় আপলোড করতে হবে এবং তাদের সাথে কিছু করতে হবে।

এটি অবশ্যই আপনার সিস্টেমের উপর নির্ভর করে। কার্যত কোন স্টপ ছাড়া এটি করার বিভিন্ন উপায় আছে। উদাহরণস্বরূপ, আপনি একটি ম্যাটেরিয়ালাইজড ভিউ তৈরি করতে পারেন যাতে একটি ভিন্ন ডেটা স্ট্রাকচার তৈরি করা যায় যদি এটি অনন্যভাবে ম্যাপ করা যায়। অর্থাৎ, যদি এটি ক্লিক হাউস ব্যবহার করে ম্যাপিংয়ের অনুমতি দেয়, যেমন কিছু জিনিস বের করে, প্রাথমিক কী পরিবর্তন করে, পার্টিশন পরিবর্তন করে, তাহলে আপনি একটি ম্যাটেরিয়ালাইজড ভিউ তৈরি করতে পারেন। সেখানে আপনার পুরানো ডেটা ওভাররাইট করুন, নতুনগুলি স্বয়ংক্রিয়ভাবে লেখা হবে। এবং তারপরে শুধুমাত্র ম্যাটেরিয়ালাইজড ভিউ ব্যবহার করতে সুইচ করুন, তারপর রেকর্ডটি সুইচ করুন এবং পুরানো টেবিলটি মেরে ফেলুন। এটি সাধারণত একটি নন-স্টপ পদ্ধতি।

Спасибо।

উত্স: www.habr.com