ClickHouse কার্যকরী ব্যবহার. আলেক্সি মিলোভিডভ (ইয়ানডেক্স)

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

হাই সব! আমার নাম আলেক্সি, আমি ক্লিক হাউস তৈরি করি।

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

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

কিন্তু তবুও, এটি অবশ্যই মনে রাখতে হবে যে এই সিস্টেমটি বিশেষায়িত এবং আপনি সহজেই একটি অস্বাভাবিক ব্যবহারের ক্ষেত্রে হোঁচট খেতে পারেন যা এই সিস্টেমটিকে এর কমফোর্ট জোনের বাইরে নিয়ে যাবে।

তাই, rakes কি? মূলত আমি স্পষ্ট বিষয় সম্পর্কে কথা বলতে হবে. সবকিছু সবার কাছে স্পষ্ট, সবাই সবকিছু বোঝে এবং খুশি হতে পারে যে তারা এত স্মার্ট, এবং যারা বোঝে না তারা নতুন কিছু শিখবে।

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

যদি আমরা বিবেচনা করি কিভাবে ক্লিকহাউস একটি সন্নিবেশ সঞ্চালন করে, তাহলে আপনি একটি অনুরোধে কমপক্ষে এক টেরাবাইট ডেটা পাঠাতে পারেন। এটা সমস্যা না.

এবং আসুন দেখে নেওয়া যাক সাধারণ পারফরম্যান্স কী হবে। উদাহরণস্বরূপ, আমাদের কাছে Yandex.Metrica ডেটা সহ একটি টেবিল রয়েছে। আঘাত. 105 কিছু কলাম। 700 বাইট আনকম্প্রেস। এবং আমরা একটি ভাল উপায়ে XNUMX মিলিয়ন লাইন ব্যাচ সন্নিবেশ করা হবে.

আমরা MergeTree টেবিলে সন্নিবেশ করি, প্রতি সেকেন্ডে অর্ধ মিলিয়ন সারি পাওয়া যায়। দারুণ। একটি প্রতিলিপি করা টেবিলে - এটি একটু কম হবে, প্রতি সেকেন্ডে প্রায় 400 সারি।

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

* 2020 সালের হিসাবে, ইতিমধ্যে নথিভুক্ত.

ভুল করলে কি হবে? আমরা MergeTree টেবিলে একটি সারি সন্নিবেশ করি এবং আমরা প্রতি সেকেন্ডে 59টি সারি পাই। এটি 10 গুণ ধীর। ReplicatedMergeTree-এ - প্রতি সেকেন্ডে 000টি সারি। এবং যদি কোরাম চালু হয়, তাহলে প্রতি সেকেন্ডে 6 লাইন পাওয়া যায়। আমার মতে, এটা একধরনের ফালতু কথা। কিভাবে আপনি যে মত ধীর করতে পারেন? এমনকি এটি আমার টি-শার্টে বলে যে ক্লিকহাউসের গতি কমানো উচিত নয়। কিন্তু তা সত্ত্বেও মাঝে মাঝে এমনটা হয়।

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

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

এবং প্রশ্ন উঠছে: "কিভাবে এটি ঠিক করবেন?" যদি এমন পরিস্থিতি থাকে তবে আপনাকে এখনও ক্লিকহাউসে ডেটা লিখতে হবে।

পদ্ধতি 1. এটি সবচেয়ে সহজ উপায়। কিছু ধরণের বিতরণ করা সারি ব্যবহার করুন। যেমন কাফকা। আপনি শুধু কাফকা থেকে ডেটা বের করে নিন, আমরা একে সেকেন্ডে একবার ব্যাচ করি। এবং সবকিছু ঠিক থাকবে, আপনি রেকর্ড করুন, সবকিছু ঠিকঠাক কাজ করে।

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

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

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

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

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

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

যাইহোক, এই ক্ষেত্রে, ডেটা অবিলম্বে ক্লিকহাউসে পাঠানো হবে। এবং ক্লিকহাউস নিজেই তাদের বাফার করবে।

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

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

*2020 সালের হিসাবে, এছাড়াও বিবেচনায় যোগ করা উচিত বিড়ালছানা ঘর.

পদ্ধতি 6. আরেকটি উপায় হল বাফার টেবিল ব্যবহার করা। এই পদ্ধতির সুবিধা হল এটি ব্যবহার করা শুরু করা খুব সহজ। একটি বাফার টেবিল তৈরি করুন এবং এতে সন্নিবেশ করুন।

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

এবং বাফার টেবিলের একটি লগ নেই. এবং যদি আপনার সার্ভারে কিছু ভুল হয়, তবে ডেটা হারিয়ে যাবে।

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

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

* 2020 হিসাবে, এর জন্য অনুরূপ সমর্থন রয়েছে RabbitMQ.

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

* এই মুহুর্তে, সমস্যাটি সম্পূর্ণরূপে সমাধান করা হয়েছে, VALUES-এ এক্সপ্রেশন ব্যবহার করার সময় আর কোনও কর্মক্ষমতা রিগ্রেশন নেই৷

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

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

এখন দ্বিতীয় ধরণের সমস্যাটি বিবেচনা করুন - ডেটা টাইপিং।

ডেটা টাইপিং কঠোর হতে পারে, এবং কখনও কখনও স্ট্রিং। স্ট্রিং - এটি হল যখন আপনি সবেমাত্র নিয়েছেন এবং ঘোষণা করেছেন যে আপনার টাইপ স্ট্রিং এর সমস্ত ক্ষেত্র রয়েছে। এটা sucks. তোমাকে সেটা করতে হবে না।

চলুন বের করা যাক যে ক্ষেত্রে আপনি বলতে চান যে আমাদের কাছে কিছু ক্ষেত্র, একটি স্ট্রিং আছে এবং ক্লিকহাউসকে এটি নিজে থেকে বের করতে দিন, কিন্তু আমি বাষ্প স্নান করব না। তবে এটি এখনও কিছু প্রচেষ্টা করা মূল্যবান।

উদাহরণস্বরূপ, আমাদের একটি আইপি ঠিকানা আছে। একটি ক্ষেত্রে, আমরা এটি একটি স্ট্রিং হিসাবে সংরক্ষণ করেছি। উদাহরণস্বরূপ, 192.168.1.1। অন্যথায়, এটি UInt32* ধরনের একটি সংখ্যা হবে। একটি IPv32 ঠিকানার জন্য 4 বিট যথেষ্ট।

প্রথমত, অদ্ভুতভাবে যথেষ্ট, ডেটা একই সম্পর্কে সংকুচিত হবে। একটি পার্থক্য হবে, নিশ্চিত, কিন্তু বড় নয়। তাই ডিস্ক I/O এর সাথে কোন বিশেষ সমস্যা নেই।

কিন্তু CPU সময় এবং ক্যোয়ারী এক্সিকিউশন সময়ের মধ্যে একটি গুরুতর পার্থক্য রয়েছে।

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

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

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

আসুন বিভিন্ন ক্ষেত্রে বিবেচনা করা যাক।

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

উদাহরণস্বরূপ, আপনার একটি অঞ্চল আছে। এবং আপনি একটি স্ট্রিং হিসাবে এটি সংরক্ষণ করার চেষ্টা করছেন. এবং সেখানে লেখা থাকবে: মস্কো এবং মস্কো অঞ্চল। এবং যখন আমি দেখি যে "মস্কো" সেখানে লেখা আছে, তখন এটি এখনও কিছুই নয়, এবং যখন এটি MO হয়, এটি একরকম সম্পূর্ণ দুঃখজনক হয়ে ওঠে। যে কত বাইট.

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

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

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

* ClickHouse-এর সাম্প্রতিক সংস্করণে, ALTER সম্পূর্ণরূপে অ-ব্লকিং করা হয়েছে।

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

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

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

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

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

আরেকটি উপায় যখন আপনি জানেন না কোথায় আপনার স্ট্রিংগুলির জন্য শনাক্তকারী পাবেন। আপনি শুধু হ্যাশ করতে পারেন। এবং সবচেয়ে সহজ বিকল্প হল একটি 64-বিট হ্যাশ নেওয়া।

একমাত্র সমস্যা হল যদি হ্যাশ 64-বিট হয়, তাহলে আপনার প্রায় অবশ্যই সংঘর্ষ হবে। কারণ যদি এক বিলিয়ন লাইন থাকে, তাহলে সম্ভাব্যতা ইতিমধ্যে বাস্তব হয়ে উঠছে।

আর বিজ্ঞাপন কোম্পানিগুলোর নাম এভাবে হ্যাশ করা খুব একটা ভালো হবে না। বিভিন্ন কোম্পানির বিজ্ঞাপনী প্রচার যদি মিশে যায়, তাহলে অবোধ্য কিছু হবে।

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

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

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

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

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

এবং যদি ডেটা জায়গায় সংরক্ষণ করা হয়, তবে সেগুলি ফাইল সিস্টেম থেকে সঠিক ক্রমে পড়া হয় এবং সবকিছু ঠিক থাকে।

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

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

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

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

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

এবং আপনি যদি ডিস্কে ডেটার পরিমাণ দেখেন তবে দেখা যাচ্ছে যে URLটি 126 মেগাবাইট এবং ডোমেনটি মাত্র 5 মেগাবাইট। এটা 25 গুণ কম সক্রিয় আউট. যাইহোক, ক্যোয়ারী এখনও মাত্র 4 গুণ দ্রুত। কিন্তু এর কারণ ডেটা গরম। এবং যদি এটি ঠান্ডা হয় তবে ডিস্ক I/O এর কারণে এটি সম্ভবত 25 গুণ দ্রুত হবে।

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

এবং, অবশ্যই, সঠিক ডেটা টাইপগুলি ব্যবহার করা মূল্যবান যা বিশেষভাবে সঠিক মানগুলির জন্য ডিজাইন করা হয়েছে বা উপযুক্ত। আপনি যদি IPv4 তে থাকেন তাহলে UInt32* স্টোর করুন। যদি IPv6 হয়, তাহলে FixedString(16), কারণ একটি IPv6 ঠিকানা হল 128 বিট, অর্থাৎ সরাসরি বাইনারি বিন্যাসে সংরক্ষণ করুন।

কিন্তু আপনার যদি কখনও কখনও IPv4 ঠিকানা থাকে এবং কখনও কখনও IPv6 থাকে? হ্যাঁ, দুটোই রাখতে পারেন। IPv4 এর জন্য একটি কলাম, IPv6 এর জন্য আরেকটি। অবশ্যই, IPv4 থেকে IPv6 ম্যাপ করার একটি বিকল্প রয়েছে। এটিও কাজ করবে, তবে আপনার অনুরোধে যদি প্রায়ই একটি IPv4 ঠিকানার প্রয়োজন হয়, তাহলে এটি একটি পৃথক কলামে রাখা ভালো হবে।

* এখন ClickHouse এর আলাদা IPv4, IPv6 ডাটা টাইপ আছে যেগুলো সংখ্যার মত দক্ষতার সাথে ডেটা সঞ্চয় করে, কিন্তু স্ট্রিং এর মত সুবিধাজনকভাবে উপস্থাপন করে।

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

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

সুতরাং এই ক্ষেত্রে এটি 4 কলামে বিভক্ত করা আরও সঠিক হবে। এখানে ভয় পাবেন না, কারণ এটি ক্লিকহাউস। ক্লিক হাউস একটি কলাম ডাটাবেস। এবং আরো ঝরঝরে ছোট কলাম, ভাল. ৫টি ব্রাউজার ভার্সন থাকবে, ৫টি কলাম তৈরি করুন। এই জরিমানা.

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

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

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

* এখন ক্লিক হাউসের একটি ডেটা টাইপ আছে নিম্ন কার্ডিনালিটি যা আপনাকে কম প্রচেষ্টায় দক্ষতার সাথে স্ট্রিং সংরক্ষণ করতে দেয়।

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

এখানে আমরা এক হাজার টেবিল দেখতে পাচ্ছি, যার প্রতিটিতে বিভাজনের অবশিষ্টাংশ রয়েছে এটি হাজার দ্বারা কী তা পরিষ্কার নয়।

নীতিগতভাবে, আমি অন্যান্য লোকের অভিজ্ঞতাকে সম্মান করি, এই অভিজ্ঞতাটি কী ধরনের কষ্ট পেতে পারে তা বোঝা সহ।

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

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

অথবা, উদাহরণস্বরূপ, মাইক্রোশার্ডিং, কিন্তু পরবর্তীতে আরও বেশি।

ক্লিকহাউসে, আপনাকে এটি করতে হবে না, কারণ, প্রথমত, প্রাথমিক কী ক্লাস্টার করা হয়, ডেটা প্রাথমিক কী দ্বারা অর্ডার করা হয়।

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

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

ক্লিক হাউসে অল্টার অ্যাড/ড্রপ কলাম পরিবর্তন করলে বিনামূল্যে।

এবং আপনার ছোট টেবিল তৈরি করা উচিত নয়, কারণ আপনার টেবিলে যদি 10টি সারি বা 10 সারি থাকে, তাহলে এটি মোটেও কোন ব্যাপার না। ClickHouse হল এমন একটি সিস্টেম যা থ্রুপুট অপ্টিমাইজ করে, লেটেন্সি নয়, তাই 000টি লাইন প্রসেস করার কোন মানে হয় না।

একটি বড় টেবিল ব্যবহার করা সঠিক। পুরানো স্টেরিওটাইপগুলি থেকে মুক্তি পান, সবকিছু ঠিক হয়ে যাবে।

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

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

* এখন ClickHouse আরো আছে টেবিল ফাংশন ইনপুট.

আরেকটি অ্যান্টি-প্যাটার্ন হল মাইক্রোশার্ডিং। উদাহরণস্বরূপ, আপনাকে ডেটা শার্ড করতে হবে এবং আপনার 5টি সার্ভার রয়েছে এবং আগামীকাল 6টি সার্ভার থাকবে। এবং আপনি কিভাবে এই তথ্য পুনরায় ভারসাম্য চিন্তা. এবং পরিবর্তে, আপনি 5 ভাগে বিভক্ত হচ্ছেন না, কিন্তু 1 ভাগে বিভক্ত হচ্ছেন। এবং তারপর আপনি একটি পৃথক সার্ভারে এই microshards প্রতিটি ম্যাপ. এবং আপনি একটি সার্ভারে সফল হবেন, উদাহরণস্বরূপ, 000 ক্লিকহাউস, উদাহরণস্বরূপ। পৃথক পোর্ট বা পৃথক ডাটাবেসে পৃথক উদাহরণ।

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

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

এবং আরেকটি কারণ হল যে আপনার TCP এর মাধ্যমে আন্তঃপ্রসেসর যোগাযোগ থাকবে। ডেটা সিরিয়ালাইজ করতে হবে, ডিসিরিয়ালাইজ করতে হবে এবং এটি একটি বিশাল সংখ্যক মাইক্রোশার্ড। এটা শুধু কাজ করবে না.

আরেকটি অ্যান্টিপ্যাটার্ন, যদিও এটিকে খুব কমই অ্যান্টিপ্যাটার্ন বলা যেতে পারে। এটি একটি বড় পরিমাণ প্রাক-সমষ্টি।

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

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

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

এবং বিশেষ করে ভাল কি? যে পরবর্তী বিভাগের এই লোকেরা, যান এবং মাঝে মাঝে প্রাথমিক কীতে আরও একটি কলাম যুক্ত করতে বলুন। অর্থাৎ, আমরা এইভাবে ডেটা একত্রিত করেছি, এবং এখন আমরা একটু বেশি চাই। কিন্তু ClickHouse এ কোন অল্টার প্রাইমারি কী নেই। অতএব, আপনাকে C++ এ কিছু স্ক্রিপ্ট লিখতে হবে। এবং আমি স্ক্রিপ্ট পছন্দ করি না, এমনকি যদি সেগুলি C++ এ থাকে।

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

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

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

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

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

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

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

যাইহোক, কিছু অসুবিধা আছে. উদাহরণস্বরূপ, একটি subquery সহ IN সূচী ব্যবহার করে না। কিন্তু এটি আমাদের সমস্যা এবং আমাদের এটি ঠিক করতে হবে। এখানে মৌলিক কিছু নেই। চল এটা করি*.

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

* ইতিমধ্যে ব্যবহার করা হচ্ছে; প্রতিশ্রুতি অনুযায়ী সবকিছু ঠিক করা হয়েছিল।

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

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

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

এখন আরেকটি মজার বিষয়। এটি ম্যানুয়াল প্রতিলিপি।

আমি এমন অনেক ক্ষেত্রে জানি যেখানে ক্লিকহাউসের অন্তর্নির্মিত প্রতিলিপি সমর্থন থাকা সত্ত্বেও, লোকেরা ক্লিকহাউসকে ম্যানুয়ালি প্রতিলিপি করে।

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

এবং পর্যায়ক্রমে আপনাকে এখনও ম্যানুয়ালি সিঙ্ক করতে হবে। উদাহরণস্বরূপ, মাসে একবার অ্যাডমিনরা rsync করে।

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

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

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

একটি MergeTree টেবিলে, আপনার কোন তারিখ এবং সময় থাকতে হবে না। আপনি এখনও ব্যবহার করতে পারেন. যদি কোন তারিখ এবং সময় না থাকে তবে লিখুন যে ডিফল্ট 2000। এটি কাজ করবে এবং সম্পদের প্রয়োজন হবে না।

এবং সার্ভারের নতুন সংস্করণে, আপনি এমনকি নির্দিষ্ট করতে পারেন যে পার্টিশন কী ছাড়াই আপনার কাস্টম পার্টিশনিং আছে। এটা একই হবে.

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

অথবা মধ্যবর্তী প্রক্রিয়াকরণের জন্য ছোট ভলিউম সংরক্ষণ করা হল স্ট্রাইপলগ বা টিনিলগ।

মেমরি ব্যবহার করা যেতে পারে যদি অল্প পরিমাণে ডেটা থাকে এবং র‌্যামে কিছু টুইস্ট করা যায়।

ক্লিকহাউস রিনরমালাইজড ডেটা খুব একটা পছন্দ করে না।

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

যদি ডেটা উচ্চ কার্ডিনালিটি হয়, তাহলে চিন্তা করবেন না, এটিকে একটি অস্বাভাবিক আকারে সংরক্ষণ করুন, URLগুলি সরাসরি মূল টেবিলে স্থাপন করা হয়েছে৷

* এবং এখন ClickHouse-এর একটি মার্জ জয়েনও রয়েছে এবং এটি এমন পরিস্থিতিতে কাজ করে যেখানে মধ্যবর্তী ডেটা RAM-এর সাথে খাপ খায় না। কিন্তু এটি অকার্যকর এবং সুপারিশ বৈধ থাকে।

আরও কয়েকটি উদাহরণ, কিন্তু আমি ইতিমধ্যেই সন্দেহ করছি যে তারা বিরোধী নিদর্শন কিনা।

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

* ব্যাচ মোডে আপডেট এবং মুছে ফেলার জন্য সমর্থন দীর্ঘদিন যোগ করা হয়েছে।

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

ক্লিকহাউসে বিতরণ করা যোগদানগুলি - এটিও কোয়েরি প্ল্যানার দ্বারা খারাপভাবে পরিচালনা করা হয়।

খারাপ, কিন্তু কখনও কখনও ঠিক আছে.

ক্লিক হাউস ব্যবহার করে ডাটা আবার সিলেক্ট* দিয়ে পড়তে।

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

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

প্রশ্ন

প্রতিবেদনের জন্য ধন্যবাদ! ClickHouse ক্র্যাশ সম্পর্কে অভিযোগ কোথায়?

আপনি এখনই ব্যক্তিগতভাবে আমার কাছে অভিযোগ করতে পারেন।

আমি সম্প্রতি ক্লিকহাউস ব্যবহার শুরু করেছি। অবিলম্বে cli ইন্টারফেস বাদ.

তুমি ভাগ্যবান.

একটু পরে, আমি একটি ছোট নির্বাচন সঙ্গে সার্ভার ড্রপ.

আপনার প্রতিভা আছে।

আমি একটি GitHub বাগ খুললাম, কিন্তু এটি উপেক্ষা করা হয়েছে।

আমরা দেখতে হবে।

আলেক্সি আমাকে রিপোর্টে যোগ দেওয়ার জন্য প্রতারিত করেছিল, আমাকে বলার প্রতিশ্রুতি দিয়েছিল যে আপনি কীভাবে তথ্যটি ভিতরে নিচ্ছেন।

এটা খুব সহজ।

এটা আমি গতকাল বুঝতে পেরেছি। আরো সুনির্দিষ্ট.

কোন ভয়ানক কৌশল আছে. এটা শুধু ব্লক-বাই-ব্লক কম্প্রেশন। ডিফল্ট হল LZ4, আপনি ZSTD* সক্ষম করতে পারেন। 64 কিলোবাইট থেকে 1 মেগাবাইট পর্যন্ত ব্লক।

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

ব্লক কি শুধু কাঁচা তথ্য?

ঠিক কাঁচা নয়। অ্যারে আছে. আপনার যদি একটি সাংখ্যিক কলাম থাকে, তাহলে একটি সারিতে সংখ্যাগুলি একটি অ্যারেতে স্ট্যাক করা হয়।

আমি দেখি।

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

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

এবং যদি আমরা আরও আদিম ডেটা টাইপ নিই? উদাহরণ স্বরূপ, তারা আমাদের যে ইউজার আইডিতে আছে তা লিখে, লাইন হিসাবে লিখে, তারপর কাস্ট করে, এটা কি আরও মজাদার হবে নাকি?

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

আলেক্সি, রিপোর্টের জন্য আপনাকে অনেক ধন্যবাদ! এবং ClickHouse জন্য আপনাকে অনেক ধন্যবাদ! আমার পরিকল্পনা সম্পর্কে একটি প্রশ্ন আছে. অসম্পূর্ণভাবে অভিধান আপডেট করার জন্য পরিকল্পনার একটি বৈশিষ্ট্য আছে?

যেমন আংশিক রিবুট?

হ্যা হ্যা. সেখানে একটি MySQL ক্ষেত্র সেট করার ক্ষমতার মতো, অর্থাৎ এর পরে আপডেট করুন যাতে অভিধানটি খুব বড় হলে শুধুমাত্র এই ডেটা লোড হয়।

খুব আকর্ষণীয় বৈশিষ্ট্য. এবং, এটা আমার মনে হয়, কিছু ব্যক্তি আমাদের চ্যাট এটি প্রস্তাব. হয়তো এটা এমনকি আপনি ছিল.

আমি তাই মনে করি না.

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

হ্যাঁ, কিন্তু দুর্ভাগ্যবশত C++ এ নয়।

আপনার সহকর্মীরা কি C++ এ লিখতে পারে?

আমি কাউকে খুঁজে বের করব।

দারুণ*।

* প্রতিবেদনের দুই মাস পরে বৈশিষ্ট্যটি যোগ করা হয়েছিল - এটি প্রশ্নের লেখক দ্বারা বিকাশ করা হয়েছিল এবং তার দ্বারা জমা দেওয়া হয়েছিল অনুরোধ টান.

ধন্যবাদ!

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

হ্যাঁ, এটা সম্ভব এবং খুব সহজ। আপনি যদি কম কোর ব্যবহার করতে চান, তাহলে শুধু লিখুন set max_threads = 1. এবং যে সব, এটি একটি কোর মধ্যে অনুরোধ চালানো হবে. তাছাড়া, আপনি বিভিন্ন ব্যবহারকারীর জন্য বিভিন্ন সেটিংস নির্দিষ্ট করতে পারেন। তাই কোন সমস্যা নেই। এবং Luxoft থেকে আপনার সহকর্মীদের বলুন যে তারা ডকুমেন্টেশনে এই সেটিংটি খুঁজে পায়নি তা ভাল নয়।

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

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

* ClickHouse-এর সাম্প্রতিক সংস্করণগুলিতে, "অ্যাডাপ্টিভ ইনডেক্স গ্রানুলারিটি" সক্ষম করা হয়েছে, যা বেশিরভাগ অংশের জন্য দীর্ঘ স্ট্রিং সংরক্ষণের সমস্যা দূর করে।

কিলোবাইট কি স্বাভাবিক?

এটা স্বাভাবিক

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

এখনো না. WITH বিভাগটি কিছুটা অসার। এটা আমাদের জন্য একটি সামান্য বৈশিষ্ট্য মত.

আমি বুঝেছি. ধন্যবাদ!

প্রতিবেদনের জন্য ধন্যবাদ! অনেক আগ্রহব্যাঞ্জক! বিশ্বব্যাপী প্রশ্ন। এটি কি পরিকল্পনা করা হয়েছে, সম্ভবত কিছু ধরণের স্টাব আকারে, ডেটা মুছে ফেলার পরিবর্তন?

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

* কীবোর্ডের বোতাম টিপুন এবং সবকিছু হয়ে গেছে।

এটা কি কোনোভাবে সিস্টেমের কর্মক্ষমতা প্রভাবিত করবে বা না? সন্নিবেশ এখন হিসাবে হিসাবে দ্রুত হবে?

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

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

হ্যাঁ।

একটি প্রশ্ন. যদি আমরা কোন প্রাথমিক কী নির্বাচন করতে না পারি, তাহলে "তারিখ" ক্ষেত্রের দ্বারা এটি ঠিক করা কি ঠিক যাতে পটভূমিতে এই ডেটার একটি ছোট পুনর্গঠন হয় যাতে সেগুলি আরও সুশৃঙ্খলভাবে ফিট হয়? আপনার যদি পরিসরের প্রশ্ন না থাকে এবং আপনি এমনকি কোনো প্রাথমিক কী নির্বাচন করতে না পারেন, তাহলে প্রাথমিক কীতে একটি তারিখ দেওয়া কি মূল্যবান?

হ্যাঁ।

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

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

উত্স: www.habr.com