প্রশ্ন ও উত্তরে উন্নত ব্যবহারকারীদের জন্য ক্লিক হাউস

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

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

সাবধান, কাটার নিচে অনেক লেখা আছে। আমরা আশা করি যে প্রশ্ন সহ বিষয়বস্তু আপনাকে নেভিগেট করতে সহায়তা করবে।

সন্তুষ্ট

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

আপনি যদি পাঠ্যটি পড়তে না চান তবে আপনি সমাবেশের রেকর্ডিং দেখতে পারেন আমাদের ইউটিউব চ্যানেলে. টাইমকোডগুলি ভিডিওর নীচে প্রথম মন্তব্যে রয়েছে৷

ClickHouse ক্রমাগত আপডেট করা হয়, কিন্তু আমাদের তথ্য নেই. এটা সম্পর্কে কি করতে হবে?

ClickHouse ক্রমাগত আপডেট করা হয়, এবং আমাদের ডেটা, যা অপ্টিমাইজ করা চূড়ান্ত প্রক্রিয়াকরণ করা হয়েছিল, আপডেট করা হয় না এবং একটি ব্যাকআপ কপিতে রয়েছে৷

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

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

ক্লিকহাউস থেকে ডেটা ব্যাক আপ করার জন্য বর্তমান সেরা অনুশীলনগুলি কী কী?

কিভাবে ব্যাকআপ করা যায়, এই বিবেচনায় নিয়ে যে আমাদের কাছে চূড়ান্ত ক্রিয়াকলাপগুলি অপ্টিমাইজ করা আছে, টেরাবাইটের একটি বিশাল ডাটাবেস এবং ডেটা যা আপডেট করা হয়েছে, বলুন, গত তিন দিন ধরে, এবং তারপরে এটির কোনও প্রক্রিয়া ঘটবে না?

আমরা আমাদের নিজস্ব সমাধান তৈরি করতে পারি এবং ব্যাশে লিখতে পারি: এই ব্যাকআপ কপিগুলি এইভাবে সংগ্রহ করতে পারি। হয়তো কোন কিছু ক্রাচ করার প্রয়োজন নেই, এবং সাইকেল অনেক আগে উদ্ভাবিত হয়েছিল?

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

ব্যাকআপের জন্য কোন সম্পূর্ণ সমাধান নেই, একশো শতাংশ ক্লিক হাউসে তৈরি। কিছু ফাঁকা আছে যা ব্যবহার করা যেতে পারে। একটি সম্পূর্ণ সমাধান পেতে, আপনাকে হয় একটু ম্যানুয়ালি টিঙ্ক করতে হবে, অথবা স্ক্রিপ্ট আকারে মোড়ক তৈরি করতে হবে।

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

যদি ডেটা সহ টেবিলটি মাত্র কয়েক গিগাবাইট দখল করে তবে ব্যাকআপ এইভাবে করা যেতে পারে:

1. টেবিল সংজ্ঞা সংরক্ষণ করুন যেমন মেটাডেটা − তৈরি টেবিল দেখান.
2. ক্লিকহাউস ক্লায়েন্ট ব্যবহার করে একটি ডাম্প তৈরি করুন - নির্বাচন করা * টেবিল থেকে নথিতে. ডিফল্টরূপে আপনি TabSeparated ফরম্যাটে একটি ফাইল পাবেন। আপনি যদি আরও দক্ষ হতে চান তবে আপনি এটি নেটিভ ফরম্যাটে করতে পারেন।

ডেটার পরিমাণ বেশি হলে ব্যাকআপ নিতে বেশি সময় লাগবে এবং অনেক জায়গাও লাগবে। এটিকে লজিক্যাল ব্যাকআপ বলা হয়; এটি ক্লিকহাউস ডেটা বিন্যাসের সাথে আবদ্ধ নয়। যদি এটি হয়, তাহলে শেষ অবলম্বন হিসাবে আপনি একটি ব্যাকআপ নিতে পারেন এবং পুনরুদ্ধারের জন্য এটি MySQL এ আপলোড করতে পারেন৷

আরও উন্নত ক্ষেত্রে, ক্লিক হাউসে স্থানীয় ফাইল সিস্টেমে পার্টিশনের একটি স্ন্যাপশট তৈরি করার একটি অন্তর্নির্মিত ক্ষমতা রয়েছে। এই বৈশিষ্ট্যটি একটি অনুরোধ হিসাবে উপলব্ধ টেবিল ফ্রিজ পার্টিশন পরিবর্তন করুন. অথবা সহজভাবে টেবিল হিমায়িত পরিবর্তন - এটি পুরো টেবিলের একটি স্ন্যাপশট।

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

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

কখনও কখনও আপনার আরও ঠান্ডা কিছুর প্রয়োজন হয় - এমন ক্ষেত্রে যেখানে আপনার প্রতিটি সার্ভারে এবং শত শত টেরাবাইট রয়েছে। এখানে একটি সমাধান আছে যা আমি Yandex.Metrica থেকে আমার সহকর্মীদের কাছ থেকে তুলেছি। আমি প্রত্যেকের কাছে এটি সুপারিশ করব না - এটি পড়ুন এবং এটি উপযুক্ত কিনা তা নিজের জন্য সিদ্ধান্ত নিন।

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

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

শ্যাফ্টগুলিতে প্রতিলিপিগুলির একটি নিয়ন্ত্রিত ল্যাগ সংগঠিত করা কি সম্ভব হবে?

এই বছর আপনি ক্লিকহাউসে শ্যাফ্ট তৈরি করার পরিকল্পনা করছেন। তাদের মধ্যে প্রতিলিপিগুলির একটি নিয়ন্ত্রিত ল্যাগ সংগঠিত করা কি সম্ভব হবে? আমরা পরিবর্তন এবং অন্যান্য পরিবর্তন সহ নেতিবাচক পরিস্থিতি থেকে নিজেদের রক্ষা করতে এটি ব্যবহার করতে চাই।

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

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

প্রথমত, প্রতিলিপিগুলির নিয়ন্ত্রিত ল্যাগ সম্পর্কে। ব্যবহারকারীদের কাছ থেকে এই ধরনের একটি অনুরোধ ছিল, এবং আমরা অনুরোধের সাথে গিথুবে একটি সমস্যা তৈরি করেছি: "যদি কারো এটির প্রয়োজন হয় তবে এটি পছন্দ করুন, একটি হৃদয় রাখুন।" কেউ বিতরণ করেনি, এবং সমস্যাটি বন্ধ হয়ে গেছে। যাইহোক, আপনি ইতিমধ্যে ক্লিকহাউস সেট আপ করে এই সুযোগ পেতে পারেন। সত্য, শুধুমাত্র সংস্করণ 20.3 থেকে শুরু।

ClickHouse ক্রমাগত ব্যাকগ্রাউন্ডে ডেটা মার্জ করে। একটি মার্জ সম্পন্ন হলে, ডেটার টুকরোগুলির একটি নির্দিষ্ট সেট একটি বড় টুকরা দিয়ে প্রতিস্থাপিত হয়। একই সময়ে, আগে সেখানে থাকা ডেটার টুকরো কিছু সময়ের জন্য ডিস্কে থেকে যায়।

প্রথমত, অ-ব্লকিং ক্রিয়াকলাপ প্রদানের জন্য সেগুলিকে ব্যবহার করার জন্য নির্বাচিত প্রশ্নগুলি যতক্ষণ না থাকে ততক্ষণ সেগুলি সংরক্ষণ করা অব্যাহত থাকে৷ পুরানো অংশগুলি থেকে বেছে নেওয়া প্রশ্নগুলি সহজেই পড়া যায়৷

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

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

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

মিউটেশনের মতো পরিবর্তনের ক্ষেত্রেও একই কথা প্রযোজ্য। যখন তুমি কর মুছে ফেলুন বা আপডেট পরিবর্তন করুন, এটি টুকরা পরিবর্তন করে না, কিন্তু একটি নতুন তৈরি করে। এবং তারপর পুরানো এক মুছে দেয়.

যদি টেবিলের গঠন পরিবর্তন হয়?

পুরানো স্কিম দিয়ে তৈরি করা একটি ব্যাকআপ কীভাবে পুনরুদ্ধার করবেন? এবং দ্বিতীয় প্রশ্নটি স্ন্যাপশট এবং ফাইল সিস্টেম সরঞ্জামগুলির ক্ষেত্রে। লিনাক্স এলভিএম-এ ZFS এর পরিবর্তে Btrfs কি এখানে ভাল?

যদি তুমি করো পার্টিশন সংযুক্ত করুন একটি ভিন্ন কাঠামোর সাথে পার্টিশন, তারপর ক্লিকহাউস আপনাকে বলবে যে এটি সম্ভব নয়। এটাই সমাধান। প্রথমটি হল পুরানো কাঠামোর সাথে MergeTree টাইপের একটি অস্থায়ী টেবিল তৈরি করা, সেখানে সংযুক্ত ব্যবহার করে ডেটা সংযুক্ত করা এবং একটি পরিবর্তন কোয়েরি করা। তারপর আপনি হয় এই ডেটা অনুলিপি বা স্থানান্তর করতে পারেন এবং আবার সংযুক্ত করতে পারেন, অথবা একটি অনুরোধ ব্যবহার করতে পারেন৷ পরিবর্তন টেবিল সরানো পার্টিশন.

এখন দ্বিতীয় প্রশ্ন হল Btrfs ব্যবহার করা যাবে কিনা। শুরুতে, আপনার যদি LVM থাকে, তাহলে LVM স্ন্যাপশটগুলিই যথেষ্ট, এবং ফাইল সিস্টেমটি ext4 হতে পারে, এটা কোন ব্যাপার না। Btrts এর সাথে, সবকিছু এটি ব্যবহার করার ক্ষেত্রে আপনার অভিজ্ঞতার উপর নির্ভর করে। এটি একটি পরিপক্ক ফাইল সিস্টেম, তবে একটি নির্দিষ্ট পরিস্থিতিতে অনুশীলনে কীভাবে সবকিছু কার্যকর হবে সে সম্পর্কে এখনও কিছু সন্দেহ রয়েছে। আপনার উৎপাদনে Btrf না থাকলে আমি এটি ব্যবহার করার সুপারিশ করব না।

ডেটা রিশার্ডিংয়ের বর্তমান সেরা অনুশীলনগুলি কী কী?

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

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

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

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

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

এর মানে হল যে কোন শার্ডে কোন ডেটা শেষ হয়েছে তা আসলে আপনার কাছে গুরুত্বপূর্ণ নয়। প্রধান জিনিস হল যে একটি পথ বরাবর ডেটা একটি শার্ডে শেষ হয়, তবে কোনটি গুরুত্বপূর্ণ নয়। এই ক্ষেত্রে, রেডিমেড পার্টিশন স্থানান্তর করা নিখুঁত, কারণ নির্বাচিত প্রশ্নগুলির সাথে আপনি সম্পূর্ণ ডেটাও পাবেন - পুনঃশর্তকরণের আগে বা পরে, স্কিমটি আসলেই গুরুত্বপূর্ণ নয়।

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

তাই এই পদ্ধতি নম্বর এক. এবং আমি আপনার উত্তরের জন্য অপেক্ষা করছি, পদ্ধতিটি উপযুক্ত কিনা, বা চলুন এগিয়ে যাই।

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

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

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

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

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

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

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

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

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

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

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

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

Yandex.Metrica ইভেন্টগুলির সাথে একটি প্রধান ক্লাস্টার রয়েছে। ইভেন্ট হল পেজ ভিউ, ক্লিক এবং কনভার্সন। বেশিরভাগ অনুরোধ একটি নির্দিষ্ট ওয়েবসাইটে যায়। আপনি Yandex.Metrica পরিষেবাটি খুলুন, আপনার একটি ওয়েবসাইট আছে - avito.ru, প্রতিবেদনে যান এবং আপনার ওয়েবসাইটের জন্য একটি অনুরোধ করা হয়।

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

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

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

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

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

এই সব স্কেল কিভাবে? ক্লাস্টারের সংখ্যা পরিবর্তিত হয় না - কয়েক বছর আগে যেমন ঊনত্রিশ ছিল, তেমনই রয়েছে। কিন্তু তাদের প্রত্যেকের মধ্যে, আমরা ধীরে ধীরে শার্ডের সংখ্যা বাড়াই কারণ আমরা ডেটা জমা করি। এবং সামগ্রিকভাবে শার্ডিং স্কিমটি এরকম: এই ক্লাস্টারগুলিকে ওয়েবসাইটগুলিতে ভাগ করা হয়েছে এবং কোন ওয়েবসাইটটি কোন ক্লাস্টারে রয়েছে তা বোঝার জন্য, MySQL-এ একটি পৃথক মেটাবেস ব্যবহার করা হয়। এক সাইট - এক ক্লাস্টারে। এবং এর ভিতরে, ভিজিটর আইডি অনুযায়ী শার্ডিং ঘটে।

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

কিন্তু আমার গল্পটি অসম্পূর্ণ থেকে যাবে যদি আমি না বলি যে আমরা এই পরিকল্পনা পরিত্যাগ করেছি। নতুন স্কিমে, আমরা সবকিছু পরিবর্তন করেছি এবং ক্লিকহাউস-কপিয়ার ব্যবহার করে সমস্ত ডেটা কপি করেছি।

নতুন স্কিমে, সমস্ত সাইট দুটি বিভাগে বিভক্ত - বড় এবং ছোট। আমি জানি না কীভাবে থ্রেশহোল্ডটি বেছে নেওয়া হয়েছিল, তবে ফলাফল হল যে বড় সাইটগুলি একটি ক্লাস্টারে রেকর্ড করা হয়েছে, যেখানে প্রতিটিতে তিনটি প্রতিলিপি সহ 120 টি শার্ড রয়েছে - অর্থাৎ 360 সার্ভার। এবং শার্ডিং স্কিমটি এমন যে যেকোন অনুরোধ একবারে সমস্ত শার্ডে যায়। আপনি যদি এখন Yandex.Metrica-এ avito.ru-এর জন্য কোনো প্রতিবেদন পৃষ্ঠা খোলেন, তাহলে অনুরোধটি 120টি সার্ভারে যাবে। রুনেটে কয়েকটি বড় সাইট রয়েছে। এবং অনুরোধগুলি প্রতি সেকেন্ডে এক হাজার নয়, তবে একশোরও কম। এই সমস্ত কিছু নিঃশব্দে বিতরণ করা টেবিল দ্বারা চিবানো হয়, যা তাদের প্রতিটি 120 সার্ভারের সাথে প্রক্রিয়া করে।

এবং দ্বিতীয় ক্লাস্টারটি ছোট সাইটগুলির জন্য। এখানে সাইট আইডির উপর ভিত্তি করে একটি শার্ডিং স্কিম রয়েছে এবং প্রতিটি অনুরোধ ঠিক একটি শার্ডে যায়৷

ক্লিকহাউসের একটি ক্লিকহাউস-কপিয়ার ইউটিলিটি রয়েছে। আপনি তার সম্পর্কে আমাদের বলতে পারেন?

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

এর মানে হল যে এটি কাজ করার জন্য আপনার দুটি ক্লাস্টার থাকতে হবে। এগুলি একই সার্ভারে অবস্থিত হতে পারে, তবে, তবুও, ডেটা ক্রমবর্ধমানভাবে সরানো হবে না, তবে অনুলিপি করা হবে।

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

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

আপনার কাছে রিশার্ডিং নামে একটি পাইলট জিনিস ছিল। তার সাথে কি?

2017 সালে, আপনার কাছে রিশার্ডিং নামে একটি পাইলট জিনিস ছিল। এমনকি ক্লিকহাউসে একটি বিকল্প রয়েছে। আমি এটা বুঝতে, এটা বন্ধ নিতে না. আপনি আমাকে বলতে পারেন কেন এটি ঘটেছে? এটা খুব প্রাসঙ্গিক বলে মনে হচ্ছে.

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

স্লো ডিস্কে সরানোর আগে কি সমস্ত ডেটা একত্রে একত্রিত করা সম্ভব?

একত্রিতকরণের প্রসঙ্গে স্লো ডিস্ক বিকল্পে সরানো সহ TTL সম্পর্কে প্রশ্ন। স্লো ডিস্কে স্থানান্তর করার আগে সমস্ত অংশগুলিকে একটিতে একত্রিত করার জন্য ক্রনের মাধ্যমে ছাড়া অন্য কোনও উপায় আছে কি?

প্রশ্নের উত্তর হল যে কোনওভাবে স্বয়ংক্রিয়ভাবে সমস্ত টুকরোগুলিকে স্থানান্তর করার আগে একটিতে আঠালো করা সম্ভব - না। আমি এটা প্রয়োজনীয় মনে করি না. আপনাকে সমস্ত অংশগুলিকে একত্রে একত্রিত করতে হবে না, তবে কেবলমাত্র সেগুলি স্বয়ংক্রিয়ভাবে ধীর ডিস্কে স্থানান্তরিত হবে তা বিশ্বাস করুন।

স্থানান্তর বিধির জন্য আমাদের দুটি মানদণ্ড রয়েছে। প্রথমটি যেমন পূর্ণ হয়। যদি বর্তমান সঞ্চয়স্থান স্তরে একটি নির্দিষ্ট শতাংশের কম ফাঁকা স্থান থাকে, আমরা একটি অংশ নির্বাচন করি এবং এটিকে ধীর সঞ্চয়স্থানে নিয়ে যাই। অথবা বরং, ধীরগতির নয়, কিন্তু পরেরটি - যেমন আপনি কনফিগার করেন।

দ্বিতীয় মানদণ্ড হল আকার। এটা বড় টুকরা সরানো সম্পর্কে. আপনি দ্রুত ডিস্কের ফাঁকা স্থান অনুযায়ী থ্রেশহোল্ড সামঞ্জস্য করতে পারেন এবং ডেটা স্বয়ংক্রিয়ভাবে স্থানান্তরিত হবে।

আগাম সামঞ্জস্য পরীক্ষা করার কোন উপায় না থাকলে ক্লিকহাউসের নতুন সংস্করণে কীভাবে স্থানান্তর করবেন?

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

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

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

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

20.3.4 সংস্করণ আছে। 20 নম্বরটি উত্পাদনের বছর নির্দেশ করে - 2020। ভিতরে কী রয়েছে তার দৃষ্টিকোণ থেকে, এটি কোনও ব্যাপার নয়, তাই আমরা এতে মনোযোগ দেব না। পরবর্তী - 20.3। আমরা দ্বিতীয় সংখ্যা বাড়াই - এই ক্ষেত্রে 3 - প্রতিবার আমরা কিছু নতুন কার্যকারিতা সহ একটি রিলিজ প্রকাশ করি। আমরা যদি ক্লিকহাউসে কিছু বৈশিষ্ট্য যোগ করতে চাই তবে আমাদের অবশ্যই এই সংখ্যা বাড়াতে হবে। অর্থাৎ, 20.4 সংস্করণে ClickHouse আরও ভালো কাজ করবে। তৃতীয় সংখ্যা হল 20.3.4। এখানে 4 হল প্যাচ রিলিজের সংখ্যা যেখানে আমরা নতুন বৈশিষ্ট্য যোগ করিনি, তবে কিছু বাগ সংশোধন করেছি। এবং 4 মানে আমরা এটা চারবার করেছি।

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

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

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

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

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

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

আলেক্সি মিলোভিডভ: Yandex.Metrica থেকে আমাদের বন্ধুদের পরীক্ষার পরিবেশ কেমন তা আমি আপনাকে বলব৷ একটি ক্লাস্টারে 600-বিজোড় সার্ভার ছিল, অন্যটিতে 360টি ছিল এবং একটি তৃতীয় এবং বেশ কয়েকটি ক্লাস্টার রয়েছে। তাদের একজনের জন্য পরীক্ষার পরিবেশ হল দুটি শার্ড যার প্রতিটিতে দুটি প্রতিলিপি। কেন দুই ভাগ? যাতে আপনি একা না হন। এবং খুব প্রতিলিপি থাকা উচিত. শুধু একটি নির্দিষ্ট ন্যূনতম পরিমাণ যা আপনি সামর্থ্য করতে পারেন।

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

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

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

তারপর নতুন সংস্করণ ইনস্টল করার জন্য সহকর্মীদের বোঝানো কঠিন ছিল। আমি বলি: "ঠিক আছে, রোল আউট করুন। আপনার আঙ্গুল ক্রস রাখুন, সবকিছু কাজ করবে। এখন গ্রাফগুলিতে লোড বেড়েছে, তবে সবকিছু ঠিক আছে। সেখানে দাঁড়াও।" সাধারণভাবে, আমরা এটি করেছি, এবং এটিই - সংস্করণটি উত্পাদনের জন্য প্রকাশিত হয়েছিল। কিন্তু প্রায় প্রতিটি লেআউটের সাথে একই ধরনের সমস্যা দেখা দেয়।

কিল কোয়েরি প্রশ্নগুলিকে হত্যা করার কথা, কিন্তু তা হয় না। কেন?

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

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

এখন একটি বরং অদ্ভুত উত্তর হবে। মূল বিষয় হল হত্যা ক্যোয়ারী প্রশ্নগুলিকে হত্যা করে না।

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

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

পড়ার লোডের অধীনে প্রতিক্রিয়া সময় কীভাবে গণনা করবেন?

একটি টেবিল রয়েছে যা আইটেম সমষ্টি সংরক্ষণ করে - বিভিন্ন কাউন্টার। লাইনের সংখ্যা প্রায় একশ মিলিয়ন। আপনি যদি 1K আইটেমগুলির জন্য 1K RPS ঢালা তবে একটি অনুমানযোগ্য প্রতিক্রিয়া সময় গণনা করা কি সম্ভব?

প্রসঙ্গ বিচার করে, আমরা পড়ার লোড সম্পর্কে কথা বলছি, কারণ লেখার সাথে কোনও সমস্যা নেই - এমনকি এক হাজার, এমনকি এক লক্ষ, এবং কখনও কখনও কয়েক মিলিয়ন সারি ঢোকানো যেতে পারে।

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

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

আপনি যদি সাধারণ অনুরোধের সংখ্যা দ্বারা একটি ক্লিকহাউস ক্লাস্টার স্কেল করতে চান, তাহলে আমি সবচেয়ে সহজ জিনিসটি সুপারিশ করি - প্রতিলিপিগুলির সংখ্যা বাড়ান এবং একটি এলোমেলো প্রতিলিপিতে অনুরোধ পাঠান৷ যদি একটি প্রতিলিপি প্রতি সেকেন্ডে পাঁচশত অনুরোধ ধারণ করে, যা সম্পূর্ণ বাস্তবসম্মত, তাহলে তিনটি রেপ্লিকা দেড় হাজার হ্যান্ডেল করবে।

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

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

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

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

আমি ক্লিকহাউসে কী পরিবর্তন করতে পারি যাতে আরও ডেটা ক্যাশে থাকে?

আসুন একটি পরিস্থিতি কল্পনা করা যাক - সার্ভারগুলিতে 256 GB RAM রয়েছে, দৈনিক রুটিনে ক্লিকহাউসে প্রায় 60-80 GB লাগে, সর্বোচ্চ - 130 পর্যন্ত। কী সক্ষম এবং টুইক করা যেতে পারে যাতে আরও ডেটা ক্যাশে থাকে এবং সেই অনুযায়ী, ডিস্কে কম ট্রিপ আছে?

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

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

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

আমি কিভাবে RAM এ স্টোরেজের জন্য স্টোরেজ_কনফিগারেশন কনফিগার করতে পারি?

নতুন ক্লিকহাউস ডকুমেন্টেশনে আমি সম্পর্কিত বিভাগটি পড়ি ডাটা স্টোরেজ সহ. বর্ণনায় দ্রুত SSD সহ একটি উদাহরণ রয়েছে।

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

এই সেটিং ডেটা খণ্ডের সঞ্চয়স্থানকে প্রভাবিত করে এবং তাদের বিন্যাস কোনোভাবেই পরিবর্তন হয় না।
এর একটি ঘনিষ্ঠ কটাক্ষপাত করা যাক.

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

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

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

এই ক্ষেত্রে, RAM-এর ডেটা ডিস্কের মতো ঠিক একই বিন্যাসে সংরক্ষণ করা হয়। একইভাবে সিলেক্ট ক্যোয়ারী সেই টুকরোগুলিকে নির্বাচন করে যেগুলি পড়তে হবে, টুকরোগুলিতে প্রয়োজনীয় ডেটা রেঞ্জগুলি নির্বাচন করে এবং সেগুলি পড়ে৷ এবং প্রি-কোথাও ঠিক একইভাবে কাজ করে, ডেটা RAM-তে বা ডিস্কে থাকুক না কেন।

নিম্ন কার্ডিনালিটি কত সংখ্যক অনন্য মান কার্যকর?

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

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

পাঁচ বিলিয়ন সারি সহ একটি টেবিলে পূর্ণ-পাঠ্য অনুসন্ধানের জন্য সেরা অনুশীলনগুলি কী কী?

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

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

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

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

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

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

সম্প্রতি, ClickHouse পূর্ণ-পাঠ্য অনুসন্ধানের জন্য আরও উন্নত ফাংশন যোগ করেছে। এটি, প্রথমত, UTF-8 বা শুধুমাত্র ASCII-এর জন্য সমর্থন সহ কেস-সংবেদনশীল, কেস-সংবেদনশীল বিকল্পগুলি সহ এক পাসে একবারে একগুচ্ছ সাবস্ট্রিংগুলির জন্য একটি অনুসন্ধান। আপনার প্রয়োজন সবচেয়ে কার্যকর একটি চয়ন করুন.

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

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

বিপুল সংখ্যক ব্যবহারকারীর জন্য ক্লিকহাউসে অ্যাক্সেস সংগঠিত করার সর্বোত্তম উপায় কী?

বিপুল সংখ্যক ভোক্তা এবং বিশ্লেষকদের জন্য কীভাবে সর্বোত্তমভাবে অ্যাক্সেসের ব্যবস্থা করা যায় তা আমাদের বলুন৷ কিভাবে একটি সারি তৈরি করতে হয়, সর্বাধিক সমসাময়িক প্রশ্নগুলিকে অগ্রাধিকার দিতে হয় এবং কোন সরঞ্জামগুলির সাহায্যে?

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

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

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

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

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

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

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

আপনাকে সর্বোচ্চ অনুরোধ কার্যকর করার সময় কনফিগার করতে হবে - বলুন, পাঁচ মিনিট। ক্যোয়ারী এক্সিকিউশনের ন্যূনতম গতি সবচেয়ে ভালো জিনিস। এই সেটিংটি দীর্ঘকাল ধরে চলে আসছে, এবং এটি শুধুমাত্র জোর দিয়েই নয় যে ClickHouse ধীর হয়ে যায় না, বরং জোর করে।

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

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

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

দশজন ক্লায়েন্টকে একটি প্রশ্নের ফলাফল দেওয়া কি সম্ভব?

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

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

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

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

একটি বিকল্প সমাধান রয়েছে যা ক্লিকহাউসের পাশে সাইডকার হিসাবে স্থাপন করা হয়েছে - ক্লিক হাউস প্রক্সি.

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

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

অ্যাসিঙ্ক্রোনাস অপারেশন এবং বস্তুগত মতামত সম্পর্কে কি?

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

একটি সুস্পষ্ট সমাধান আছে - একটি অ্যাসিঙ্ক্রোনাস পতন অপারেশন চলাকালীন একটি নির্দিষ্ট শ্রেণীর ম্যাটভিউতে একটি ট্রিগার প্রয়োগ করা। কোন রূপালী বুলেট বা অনুরূপ কার্যকারিতা বাস্তবায়নের পরিকল্পনা আছে?

ডিডপ্লিকেশন কিভাবে কাজ করে তা বোঝার যোগ্য। আমি এখন আপনাকে যা বলব তা প্রশ্নের সাথে প্রাসঙ্গিক নয়, তবে এটি মনে রাখার মতো।

একটি প্রতিলিপি করা টেবিলে সন্নিবেশ করার সময়, সম্পূর্ণ সন্নিবেশিত ব্লকের অনুলিপি রয়েছে। আপনি যদি একই ক্রমে একই সারিগুলির একই সংখ্যক সমন্বিত একই ব্লক পুনরায় সন্নিবেশ করেন, তাহলে ডেটাটি অনুলিপি করা হয়। সন্নিবেশের প্রতিক্রিয়া হিসাবে আপনি "ঠিক আছে" পাবেন, কিন্তু আসলে ডেটার একটি প্যাকেট লেখা হবে, এবং এটি নকল করা হবে না।

এটি নিশ্চিততার জন্য প্রয়োজনীয়। আপনি যদি সন্নিবেশের সময় "ঠিক আছে" পান তবে আপনার ডেটা সন্নিবেশ করা হয়েছে। আপনি যদি ClickHouse থেকে একটি ত্রুটি পান, এর অর্থ হল সেগুলি ঢোকানো হয়নি এবং আপনাকে সন্নিবেশটি পুনরাবৃত্তি করতে হবে৷ কিন্তু যদি সন্নিবেশের সময় সংযোগটি ভেঙে যায়, তাহলে আপনি জানেন না যে ডেটা সন্নিবেশ করা হয়েছে কিনা। একমাত্র বিকল্প হল আবার সন্নিবেশ পুনরাবৃত্তি করা। যদি ডেটা আসলে সন্নিবেশ করা হয় এবং আপনি এটি পুনরায় সন্নিবেশ করেন, তাহলে ব্লক ডিডপ্লিকেশন আছে। ডুপ্লিকেট এড়াতে এটি প্রয়োজন।

এবং এটি বাস্তবিক দৃষ্টিভঙ্গির জন্য কীভাবে কাজ করে তাও গুরুত্বপূর্ণ। যদি মূল টেবিলে ঢোকানোর সময় ডেটাটি অনুলিপি করা হয়, তবে এটি বস্তুগত দৃশ্যেও যাবে না।

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

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

কিরিল শ্বাকভ: এক সময় আমাদের ক্রাচ নির্মাণও ছিল। একটি সমস্যা ছিল যে বিজ্ঞাপনের ইম্প্রেশন আছে, এবং কিছু ডেটা আছে যা আমরা রিয়েল টাইমে দেখাতে পারি - এগুলো শুধু ইম্প্রেশন। এগুলি খুব কমই সদৃশ হয়, তবে যদি এটি ঘটে তবে আমরা সেগুলিকে পরে যেভাবেই হোক ভেঙে দেব৷ এবং এমন কিছু জিনিস ছিল যা নকল করা যায় না - ক্লিক এবং সেই পুরো গল্প। কিন্তু আমি তাদের প্রায় সঙ্গে সঙ্গে দেখাতে চেয়েছিলাম।

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

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

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

ClickHouse লগ অনেক আছে. আমি কিভাবে সার্ভারে ঘটে যাওয়া সবকিছু এক নজরে দেখতে পারি?

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

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

ড্যাশবোর্ড আছে, যদিও সেগুলো মানসম্মত নয়। আমাদের কোম্পানিতে, প্রায় 60 টি দল ClickHouse ব্যবহার করে, এবং সবচেয়ে আশ্চর্যের বিষয় হল যে তাদের অনেকেরই ড্যাশবোর্ড রয়েছে যা তারা নিজেদের জন্য তৈরি করেছে এবং কিছুটা আলাদা। কিছু দল একটি অভ্যন্তরীণ Yandex.Cloud ইনস্টলেশন ব্যবহার করে। কিছু রেডিমেড রিপোর্ট আছে, যদিও সবগুলো প্রয়োজনীয় নয়। অন্যদের নিজস্ব আছে।

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

ড্যাশবোর্ডের মূল জিনিস একই। এগুলি ক্লাস্টারের জন্য সিস্টেম মেট্রিক্স: CPU, মেমরি, ডিস্ক, নেটওয়ার্ক। অন্যান্য - একযোগে অনুরোধের সংখ্যা, একযোগে একত্রিত হওয়ার সংখ্যা, প্রতি সেকেন্ডে অনুরোধের সংখ্যা, MergeTree টেবিল পার্টিশনের জন্য সর্বাধিক সংখ্যা, প্রতিলিপি ল্যাগ, প্রতিলিপি সারির আকার, প্রতি সেকেন্ডে সন্নিবেশিত সারির সংখ্যা, প্রতি সেকেন্ডে সন্নিবেশিত ব্লকের সংখ্যা। এই সব যে লগ থেকে প্রাপ্ত করা হয়, কিন্তু মেট্রিক্স থেকে.

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

আমি নিজেই বাইক চালিয়েছি। তবে আমার একটি প্রশ্ন আছে - যদি এটি সমস্ত মানসম্মত হয় এবং গ্রাফানা সবাই ব্যবহার করে তবে ইয়ানডেক্সের এমন একটি অফিসিয়াল ড্যাশবোর্ড নেই কেন?

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

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

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

সার্ভার যাতে ওওএম-এ ক্র্যাশ না হয় সেজন্য মার্জকে কীভাবে প্রভাবিত করবেন?

আমার একটি টেবিল আছে, টেবিলে শুধুমাত্র একটি পার্টিশন আছে, এটি ReplacingMergeTree। আমি চার বছর ধরে এটিতে ডেটা লিখছি। আমার এটিতে একটি পরিবর্তন করা এবং কিছু ডেটা মুছে ফেলা দরকার।

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

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

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

আপনি জানেন, মার্জ করার সময়, সার্ভারটি OOM-এ পড়বে না, কারণ মার্জ করার সময়, শুধুমাত্র একটি ছোট পরিসরের ডেটার জন্য RAM-এর পরিমাণ ব্যবহার করা হয়। তাই ডেটার পরিমাণ নির্বিশেষে সবকিছু ঠিক থাকবে।

ভ্লাদিমির কোলোবায়েভ: ফাইন। এখানে মুহূর্তটি এমন যে বাগটি ঠিক করার পরে, আমি নিজের জন্য একটি নতুন সংস্করণ ডাউনলোড করেছি এবং অন্য একটি টেবিলে, একটি ছোট, যেখানে অনেকগুলি পার্টিশন রয়েছে, আমি একই রকম অপারেশন করেছি। এবং মার্জ করার সময়, সার্ভারে প্রায় 100 গিগাবাইট RAM বার্ন হয়েছিল। আমার 150টি দখল করা, 100টি খাওয়া, এবং একটি 50 GB উইন্ডো বাকি ছিল, তাই আমি OOM-এ পড়িনি।

এটি আসলে 100 গিগাবাইট র‍্যাম ব্যবহার করলে বর্তমানে আমাকে OOM-এ পড়া থেকে কী রক্ষা করে? হঠাৎ মার্জ এর RAM ফুরিয়ে গেলে কি করবেন?

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

অবশ্যই, এটি একটি RAM সীমাবদ্ধতা অতিরিক্ত হবে না যে "কেবল ক্ষেত্রে" OOM থেকে রক্ষা করে। এটি একত্রীকরণকে সম্পূর্ণ করতে সাহায্য করবে না, এটি আবার শুরু হবে, কিছু থ্রেশহোল্ডে পৌঁছাবে, একটি ব্যতিক্রম নিক্ষেপ করবে এবং তারপর আবার শুরু করবে - এর থেকে ভাল কিছুই আসবে না। কিন্তু নীতিগতভাবে, এই নিষেধাজ্ঞা চালু করা দরকারী হবে।

ক্লিকহাউসের জন্য গোলং ড্রাইভার কীভাবে তৈরি হবে?

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

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

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

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

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

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

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

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

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

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

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

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

অলস_লোড সেটিং সক্ষম করে রিবুট করার পরে বহিরাগত অভিধান লোড হয় না। কি করো?

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

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

প্রথমত, অভিধানগুলি একটি ক্যোয়ারী ব্যবহার করে জোর করে লোড করা যেতে পারে সিস্টেম পুনরায় লোড অভিধান. দ্বিতীয়ত, ত্রুটি সম্পর্কিত - যদি অভিধানটি ইতিমধ্যে লোড করা থাকে, তাহলে লোড করা ডেটার উপর ভিত্তি করে প্রশ্নগুলি কাজ করবে। যদি অভিধানটি এখনও লোড করা না হয় তবে অনুরোধের সময় এটি সরাসরি লোড করা হবে।

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

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

সিস্টেম রিলোড ডিকশনারী অনেকগুলো ডিকশনারির কোনো লোড করে না যদি তাদের মধ্যে অন্তত একটি ত্রুটির সাথে ক্র্যাশ হয় তাহলে কি করবেন?

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

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

ClickHouse কনফিগারে বিস্তারিত কনফিগার করার একটি উপায় আছে, কিন্তু ত্রুটির ক্ষেত্রে তাদের প্রদর্শন না?

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

আমরা ODBC ড্রাইভার কনফিগারে বিস্তারিত যোগ করে এই ত্রুটিটি সমাধান করেছি। ClickHouse কনফিগারে বিস্তারিত কনফিগার করার কোন উপায় আছে, কিন্তু ত্রুটির ক্ষেত্রে এই বিবরণগুলি দেখাবে না?

এখানে আসল সমাধান হল এই শংসাপত্রগুলিকে odbc.ini-এ উল্লেখ করা, এবং ClickHouse-এ শুধুমাত্র ODBC ডেটা উৎসের নাম উল্লেখ করা। এটি অন্যান্য অভিধান উত্সের জন্য ঘটবে না - না MySQL-এর সাথে অভিধানের জন্য, না অন্যদের জন্য, আপনি একটি ত্রুটি বার্তা পেলে পাসওয়ার্ডটি দেখতে পাবেন না৷ ODBC-এর জন্য, আমিও দেখব - যদি এটি বিদ্যমান থাকে তবে আপনাকে কেবল এটি সরাতে হবে।

বোনাস: সমাবেশ থেকে জুমের জন্য ব্যাকগ্রাউন্ড

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

উত্স: www.habr.com