HighLoad++, Yuri Nasretdinov (VKontakte): ভিকে কীভাবে হাজার হাজার সার্ভার থেকে ক্লিকহাউসে ডেটা সন্নিবেশিত করে

হাইলোড++ মস্কো 2018, কংগ্রেস হল। নভেম্বর 9, 15:00

বিমূর্ত এবং উপস্থাপনা: http://www.highload.ru/moscow/2018/abstracts/4066

ইউরি নাসরেটদিনভ (ভিকন্টাক্টে): প্রতিবেদনটি আমাদের কোম্পানিতে ক্লিকহাউস বাস্তবায়নের অভিজ্ঞতা সম্পর্কে কথা বলবে - কেন আমাদের এটি প্রয়োজন, আমরা কতটা ডেটা সঞ্চয় করি, আমরা কীভাবে এটি লিখি ইত্যাদি।

অতিরিক্ত উপকরণ: ELK, Big Query এবং TimescaleDB-এর প্রতিস্থাপন হিসাবে Clickhouse ব্যবহার করা

ইউরি নাসরেদিনভ: - হাই সব! আমার নাম ইউরি নাসরেটদিনভ, যেহেতু আমার পরিচয় আগেই হয়ে গেছে। আমি VKontakte এ কাজ করি। আমরা কিভাবে আমাদের সার্ভার বহর থেকে ক্লিকহাউসে ডেটা সন্নিবেশ করি সে সম্পর্কে আমি কথা বলব (হাজার হাজার)

লগ কি এবং কেন তাদের সংগ্রহ?

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

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

কেন আমরা সিদ্ধান্ত নিলাম? আমরা সম্ভবত লগ সংরক্ষণের জন্য সমাধান ছিল. এখানে - এমন একটি সর্বজনীন "ব্যাকএন্ড ভিকে" রয়েছে। আমি অত্যন্ত এটি সদস্যতা সুপারিশ.

লগ কি? এটি একটি ইঞ্জিন যা খালি অ্যারে ফেরত দেয়। VK-এর ইঞ্জিনগুলিকে অন্যরা মাইক্রোসার্ভিস বলে। এবং এখানে একটি স্মাইলিং স্টিকার (বেশ অনেক লাইক)। কেমন করে? আচ্ছা, আরও শুনুন!

লগ সংরক্ষণ করতে কি ব্যবহার করা যেতে পারে? হাদুপের উল্লেখ না করা অসম্ভব। তারপরে, উদাহরণস্বরূপ, Rsyslog (ফাইলগুলিতে এই লগগুলি সংরক্ষণ করা)। এলএসডি। কে জানে এলএসডি কি? না, এই এলএসডি নয়। সঞ্চয় ফাইল, যথাক্রমে, খুব. ঠিক আছে, ক্লিকহাউস একটি অদ্ভুত বিকল্প।

ক্লিকহাউস এবং প্রতিযোগীরা: প্রয়োজনীয়তা এবং সুযোগ

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

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

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

অন্যান্য অপশন আছে কি? যেমন ‘হাদুপ’। অপারেশন সহজ... কে মনে করে যে Hadup সেট আপ করা সহজ? অবশ্যই, রেকর্ডিং সঙ্গে কোন সমস্যা আছে. পড়ার সময় মাঝে মাঝে প্রশ্ন জাগে। নীতিগতভাবে, আমি বলব সম্ভবত না, বিশেষ করে লগগুলির জন্য। দীর্ঘমেয়াদী সঞ্চয়স্থান - অবশ্যই, হ্যাঁ, ডেটা সংকোচন - হ্যাঁ, দীর্ঘ স্ট্রিং - এটা স্পষ্ট যে আপনি রেকর্ড করতে পারেন৷ কিন্তু বিপুল সংখ্যক সার্ভার থেকে রেকর্ডিং... আপনাকে এখনও কিছু করতে হবে!

Rsyslog. প্রকৃতপক্ষে, আমরা এটিকে একটি ব্যাকআপ বিকল্প হিসাবে ব্যবহার করেছি যাতে আমরা বিনলগ ডাম্প না করে এটি পড়তে পারি, তবে এটি দীর্ঘ লাইন লিখতে পারে না; নীতিগতভাবে, এটি 4 কিলোবাইটের বেশি লিখতে পারে না। আপনাকে একইভাবে ডেটা কম্প্রেশন করতে হবে। রিডিং ফাইল থেকে আসবে।

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

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

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

কিভাবে আমরা এটা সন্নিবেশ করা যাচ্ছে? মার্জট্রি

আপনার মধ্যে কে "ক্লিকহাউস" সম্পর্কে শুনেননি বা জানেন না? আমি তোমাকে বলতে চাই, তাই না? খুব দ্রুত. সেখানে সন্নিবেশ - প্রতি সেকেন্ডে 1-2 গিগাবাইট, প্রতি সেকেন্ডে 10 গিগাবিট পর্যন্ত বিস্ফোরণ আসলে এই কনফিগারেশনটি সহ্য করতে পারে - এখানে দুটি 6-কোর Xeons (অর্থাৎ সবচেয়ে শক্তিশালীও নয়), 256 গিগাবাইট RAM, 20 টেরাবাইট রয়েছে RAID-এ (কেউ কনফিগার করেনি, ডিফল্ট সেটিংস)। আলেক্সি মিলোভিডভ, ক্লিকহাউস ডেভেলপার, সম্ভবত সেখানে বসে কাঁদছেন কারণ আমরা কিছু কনফিগার করিনি (সবকিছু আমাদের জন্য সেরকম কাজ করেছে)। তদনুসারে, ডেটা ভালভাবে সংকুচিত হলে প্রতি সেকেন্ডে প্রায় 6 বিলিয়ন লাইনের স্ক্যানিং গতি পাওয়া যেতে পারে। আপনি যদি একটি পাঠ্য স্ট্রিং-এ % লাইক করেন - প্রতি সেকেন্ডে 100 মিলিয়ন লাইন, অর্থাৎ, এটি বেশ দ্রুত বলে মনে হয়।

কিভাবে আমরা এটা সন্নিবেশ করা যাচ্ছে? আচ্ছা, আপনি জানেন যে ভিকে পিএইচপি ব্যবহার করে। আমরা প্রতিটি পিএইচপি কর্মী থেকে HTTP এর মাধ্যমে প্রতিটি রেকর্ডের জন্য MergeTree টেবিলে “ClickHouse”-এ সন্নিবেশ করব। কে এই স্কিম সঙ্গে একটি সমস্যা দেখে? কিছু কারণে, সবাই তাদের হাত তোলেনি। আমি আপনাকে বলছি.

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

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

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

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

বাফার টেবিলের সাথে কাজ করা

এটা কি? বাফার টেবিলগুলি হল মেমরির একটি টুকরো যা শার্ডেড (অর্থাৎ, এটি ঘন ঘন এটিতে ঢোকানো যেতে পারে)। তারা বেশ কয়েকটি টুকরা নিয়ে গঠিত, এবং প্রতিটি টুকরো একটি স্বাধীন বাফার হিসাবে কাজ করে, এবং সেগুলি স্বাধীনভাবে ফ্লাশ করা হয় (যদি আপনার বাফারে অনেকগুলি টুকরা থাকে, তাহলে প্রতি সেকেন্ডে অনেকগুলি সন্নিবেশ হবে)। এই টেবিলগুলি থেকে পড়া সম্ভব - তারপরে আপনি বাফার এবং প্যারেন্ট টেবিলের বিষয়বস্তুর মিলন পড়েন, তবে এই মুহুর্তে লেখাটি ব্লক করা হয়েছে, তাই সেখান থেকে না পড়াই ভাল। এবং বাফার টেবিলগুলি খুব ভাল QPS দেখায়, অর্থাৎ 3 হাজার QPS পর্যন্ত সন্নিবেশ করার সময় আপনার কোনও সমস্যা হবে না। এটা স্পষ্ট যে সার্ভার যদি শক্তি হারায়, তাহলে ডেটা হারিয়ে যেতে পারে, কারণ এটি শুধুমাত্র মেমরিতে সংরক্ষিত ছিল।

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

Kittenhouse কি এবং এটি কিভাবে কাজ করে?

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

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

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

nginx যোগ করুন

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

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

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

সমাধান থেকে এক ধাপ দূরে

চূড়ান্ত স্কিমটি এইরকম দেখতে শুরু করে (এই স্কিমের চতুর্থ সংস্করণ): Clickhouse এর সামনে প্রতিটি সার্ভারে nginx (একই সার্ভারে) রয়েছে এবং এটি কেবল 50 এর সংযোগের সংখ্যার সীমা সহ লোকালহোস্টের কাছে প্রক্সি অনুরোধ করে। টুকরা. এবং এই স্কিমটি ইতিমধ্যে বেশ কাজ করছিল, এর সাথে সবকিছু বেশ ভাল ছিল।

আমরা প্রায় এক মাস এভাবেই থাকলাম। সবাই খুশি ছিল, তারা টেবিল যোগ করেছে, তারা যোগ করেছে, তারা যোগ করেছে... সাধারণভাবে, দেখা গেল যে আমরা যেভাবে বাফার টেবিল যুক্ত করেছি তা খুব অনুকূল ছিল না (আসুন এটিকে সেভাবে রাখি)। আমরা প্রতিটি টেবিলে 16 টুকরা করেছি এবং কয়েক সেকেন্ডের একটি ফ্ল্যাশ ব্যবধান; আমাদের 20টি টেবিল ছিল এবং প্রতিটি টেবিল প্রতি সেকেন্ডে 8টি সন্নিবেশ পেয়েছে - এবং এই মুহুর্তে "ক্লিকহাউস" শুরু হয়েছে... রেকর্ডগুলি ধীর হতে শুরু করেছে। শুধুমাত্র তারা পাস করেনি... ডিফল্টরূপে, nginx-এর এমন একটি আকর্ষণীয় জিনিস ছিল যে যদি সংযোগগুলি আপস্ট্রিমে শেষ হয়, তবে এটি সমস্ত নতুন অনুরোধে "502" ফিরিয়ে দেয়।

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

একটি বিপরীত প্রক্সি দিয়ে nginx প্রতিস্থাপন

আমি সিদ্ধান্ত নিয়েছি যে আমাদের এটি নিজেরাই পরিচালনা করতে হবে, আমাদের এটি nginx-এ ছেড়ে দেওয়ার দরকার নেই - nginx জানে না ক্লিকহাউসে কী টেবিল রয়েছে এবং আমি nginx কে একটি বিপরীত প্রক্সি দিয়ে প্রতিস্থাপন করেছি, যা আমি নিজেও লিখেছি।

সে কি করছে? এটি fasthttp লাইব্রেরি "goshnoy" এর উপর ভিত্তি করে কাজ করে, অর্থাৎ দ্রুত, প্রায় nginx এর মতো দ্রুত। দুঃখিত, ইগর, যদি আপনি এখানে উপস্থিত থাকেন (দ্রষ্টব্য: ইগর সিসোয়েভ একজন রাশিয়ান প্রোগ্রামার যিনি nginx ওয়েব সার্ভার তৈরি করেছেন)। এটি বুঝতে পারে এইগুলি কী ধরণের প্রশ্ন - INSERT বা SELECT - সেই অনুযায়ী, এটি বিভিন্ন ধরণের প্রশ্নের জন্য বিভিন্ন সংযোগ পুল ধারণ করে৷

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

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

স্কিমটি এইরকম দেখতে শুরু করে: "কিটেনহাউস", বিপরীত প্রক্সিগুলি টেবিলে অনেকগুলি অনুরোধ করে এবং ফলস্বরূপ, বাফার টেবিলগুলি সেগুলিকে প্রধানগুলির মধ্যে সন্নিবেশ করে।

হত্যাকারী একটি অস্থায়ী সমাধান, বিড়ালছানা স্থায়ী

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

আমি যা করেছি? আবার, আমি সত্যিই বুঝতে পছন্দ করি না ঠিক কি ঘটেছে। আমি মনে করি এটি বেশ সুস্পষ্ট যে আপনার মেমরিতে বাফার করা উচিত নয়। আমি দ্রুত HTTP প্যাচ করতে পারিনি, যদিও আমি চেষ্টা করেছি। কিন্তু আমি এটি তৈরি করার একটি উপায় খুঁজে পেয়েছি যাতে কিছু প্যাচ করার প্রয়োজন নেই, এবং আমি HTTP-তে আমার নিজস্ব পদ্ধতি নিয়ে এসেছি - আমি এটিকে KITTEN বলেছি। আচ্ছা, এটা যৌক্তিক - "ভিকে", "বিড়ালছানা"... আর কি?...

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

এবং তাই আমি এক সময়ে প্রায় 50 জন ক্লায়েন্টের কাছ থেকে পড়ি (পঞ্চাশ থেকে কারণ পঞ্চাশ অবশ্যই যথেষ্ট হবে, এমনকি যদি অন্য ডিসি থেকেও হার আসে)... এই পদ্ধতির সাথে কমপক্ষে 20 বার খরচ কমেছে, কিন্তু আমি, সত্যি বলতে , আমি ঠিক কোন সময় পরিমাপ করতে পারিনি, কারণ এটি ইতিমধ্যেই অর্থহীন (এটি ইতিমধ্যে ত্রুটির স্তরে পৌঁছেছে)। প্রোটোকলটি বাইনারি, অর্থাৎ এতে টেবিলের নাম এবং ডেটা রয়েছে; কোন HTTP শিরোনাম নেই, তাই আমি একটি ওয়েব সকেট ব্যবহার করিনি (আমাকে ব্রাউজারের সাথে যোগাযোগ করার দরকার নেই - আমি একটি প্রোটোকল তৈরি করেছি যা আমাদের প্রয়োজন অনুসারে)। এবং তার সাথে সবকিছু ঠিক হয়ে গেল।

বাফার টেবিল দু: খিত

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

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

এমন একটি চিহ্নও রয়েছে (হয়তো কেউ এটি লক্ষ্য করেছেন) - এটিকে ক্লিকহাউসের নতুন সংস্করণে query_thread_log বলা হয়। ডিফল্টরূপে, কিছু সংস্করণে একটি ছিল। এখানে আমরা কয়েক মাসে (840 গিগাবাইট) 100 মিলিয়ন রেকর্ড জমা করেছি। এটি এই কারণে যে সেখানে "সন্নিবেশ" লেখা হয়েছিল (হয়তো এখন, যাইহোক, সেগুলি লেখা হয় না)। আমি আপনাকে বলেছি, আমাদের "সন্নিবেশ" ছোট - আমাদের বাফার টেবিলে প্রচুর "সন্নিবেশ" ছিল। এটা স্পষ্ট যে এটি অক্ষম করা হয়েছে - আমি আমাদের সার্ভারে যা দেখেছি তা আপনাকে বলছি। কেন? এটি বাফার টেবিল ব্যবহার করার বিরুদ্ধে আরেকটি যুক্তি! স্পটটি খুব দুঃখিত।

কে জানত যে এই লোকটির নাম স্পটটি? ভিকে কর্মীরা হাত তুললেন। ঠিক আছে.

"কিটেনহাউস" এর পরিকল্পনা সম্পর্কে

পরিকল্পনা সাধারণত ভাগ করা হয় না, তাই না? হঠাৎ আপনি সেগুলি পূরণ করবেন না এবং অন্য লোকেদের চোখে খুব ভাল দেখাবেন না। কিন্তু আমি ঝুঁকি নেব! আমরা নিম্নলিখিত কাজ করতে চাই: বাফার টেবিল, এটা আমার মনে হয়, এখনও একটি ক্রাচ এবং আমাদের নিজেদেরকে সন্নিবেশ বাফার করতে হবে। কিন্তু আমরা এখনও এটি ডিস্কে বাফার করতে চাই না, তাই আমরা মেমরিতে সন্নিবেশ বাফার করব।

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

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

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

পড়ার কথা বলি

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

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

এবং এটি দেখতে অনেকটা সিক্যুয়েল প্রো-এর মতোই, তবে শুধুমাত্র টুইটারের বুটস্ট্র্যাপে তৈরি এবং দ্বিতীয় সংস্করণে। আপনি জিজ্ঞাসা করেন: "ইউরি, কেন দ্বিতীয় সংস্করণে?" কোন বছর? 2018? সাধারণভাবে, আমি "পেশী" (MySQL) এর জন্য এটি অনেক আগে করেছিলাম এবং সেখানে ক্যোয়ারীতে কয়েকটি লাইন পরিবর্তন করেছি এবং এটি "ক্লিকহাউস" এর জন্য কাজ শুরু করেছে, যার জন্য বিশেষ ধন্যবাদ! কারণ পার্সারটি "পেশী" এর সাথে খুব মিল, এবং প্রশ্নগুলি খুব অনুরূপ - খুব সুবিধাজনক, বিশেষ করে প্রথমে।

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

একজন সম্পাদকও আছেন। আমি সত্যই Tabix থেকে সম্পূর্ণ সম্পাদক চুরি করার চেষ্টা করেছি, কিন্তু আমি পারিনি। কিন্তু একরকম এটি কাজ করে। নীতিগতভাবে, যে সব.

"ক্লিকহাউস" dens জন্য উপযুক্ত

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

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

আমি হাইলোড সাইবেরিয়াতে "কিটেনহাউস" এবং "লাইটহাউস" পোস্ট করার প্রতিশ্রুতি দিয়েছিলাম যদি সবাই আমাদের পাবলিক "ভিকে ব্যাকএন্ড"-এ সদস্যতা নেয়... এবং আপনি জানেন, সবাই সাবস্ক্রাইব করেনি... অবশ্যই, আমি আপনাকে আমাদের সাবস্ক্রাইব করার দাবি করব না। পাবলিক আপনি এখনও অনেক আছে, কেউ এমনকি বিক্ষুব্ধ হতে পারে, কিন্তু তবুও, সাবস্ক্রাইব করুন (এবং এখানে আমাকে একটি বিড়ালের মত চোখ করতে হবে)। যে উপায় দ্বারা এটি লিঙ্ক. আপনাকে অনেক ধন্যবাদ! Github আমাদের ঠিক এখানে. ক্লিকহাউসের সাহায্যে আপনার চুল হবে নরম ও সিল্কি।

মডারেটর: - বন্ধুরা, এখন প্রশ্নের জন্য। আমরা প্রশংসার শংসাপত্র এবং VHS এ আপনার প্রতিবেদন উপস্থাপন করার ঠিক পরে।

ইউরি নাসরেটদিনভ (এখন থেকে YN হিসাবে উল্লেখ করা হয়েছে): - আপনি VHS-এ আমার রিপোর্ট রেকর্ড করতে পারলেন যদি এটি সবেমাত্র শেষ হয়?

মডারেটর: - আপনি "ক্লিকহাউস" কীভাবে কাজ করবে বা না তা সম্পূর্ণরূপে নির্ধারণ করতে পারবেন না! বন্ধুরা, প্রশ্ন করার জন্য 5 মিনিট!

প্রশ্ন

শ্রোতাদের কাছ থেকে প্রশ্ন (এর পরে Q হিসাবে উল্লেখ করা হয়েছে): - শুভ অপরাহ্ন. প্রতিবেদনের জন্য আপনাকে অনেক ধন্যবাদ. আমার দুটি প্রশ্ন আছে। আমি কিছু ফালতু দিয়ে শুরু করব: ডায়াগ্রামে (3, 4, 7...) "কিটেনহাউস" নামের t অক্ষরের সংখ্যা কি বিড়ালদের সন্তুষ্টিকে প্রভাবিত করে?

YN: - কি পরিমাণ?

জেড: - চিঠি টি. কোথাও তিনটা আছে, কোথাও তিনটা।

YN: - আমি কি ঠিক করিনি? ওয়েল, অবশ্যই এটা করে! এগুলি বিভিন্ন পণ্য - আমি আপনাকে এই সমস্ত সময় কেবল প্রতারণা করছিলাম। ঠিক আছে, আমি মজা করছি - এটা কোন ব্যাপার না. আহ, ঠিক এখানে! না, এটা একই জিনিস, আমি একটি টাইপো করেছি.

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

YN: - হ্যাঁ.

জেড: - এবং একই সময়ে, আপনার ক্লায়েন্ট ডিস্কে বাফার করে, যা এই একই লগগুলির সরবরাহের কিছু গ্যারান্টি বোঝায়। কিন্তু ক্লিকহাউসে এটি কোনোভাবেই নিশ্চিত নয়। ব্যাখ্যা করুন কিভাবে গ্যারান্টি বাহিত হয়, কি কারণে?.. এখানে আরো বিস্তারিতভাবে এই প্রক্রিয়া আছে

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

জেড: - অর্থাৎ, "কিটেনহাউস" জানালাটিকে বেশিক্ষণ ধরে রাখে এবং পড়ে গেলে, এটি চিনতে পারে এবং এটিকে রিওয়াইন্ড করতে পারে?

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

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

YN: - আমরা কি TCP ব্যবহার করি?

জেড: - মূলত হ্যাঁ।

YN: - না।

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

YN: - কিসের সাথে?

জেড: - দীর্ঘ বার্তাগুলির সাথে, যেহেতু এটি MTU এর সাথে খাপ খায় না, অন্য কিছু... ঠিক আছে, তাদের নিজস্ব সমস্যা থাকতে পারে। প্রশ্ন হল: কেন UDP নয়?

YN: – আমি বিশ্বাস করি যে লেখক যারা TCP/IP তৈরি করেছেন তারা আমার চেয়ে অনেক বেশি স্মার্ট এবং আমার থেকে ভালো জানেন কিভাবে প্যাকেটগুলিকে সিরিয়ালাইজ করতে হয় (যাতে তারা চলে যায়), একই সাথে সেন্ডিং উইন্ডো সামঞ্জস্য করুন, নেটওয়ার্ক ওভারলোড করবেন না, কী বিষয়ে প্রতিক্রিয়া জানান পড়া হয় না, অন্য দিকে গণনা করা হয় না... এই সমস্ত সমস্যা, আমার মতে, UDP-তে বিদ্যমান থাকবে, শুধুমাত্র একই জিনিস বাস্তবায়ন করার জন্য আমি ইতিমধ্যেই লিখেছিলাম তার থেকেও বেশি কোড লিখতে হবে এবং সম্ভবত দুর্বল. আমি সি-তে লিখতেও পছন্দ করি না, সেখানেই থাকুক...

জেড: - শুধু সুবিধাজনক! ঠিক আছে পাঠানো হয়েছে এবং কিছুর জন্য অপেক্ষা করবেন না - এটি সম্পূর্ণরূপে অ্যাসিঙ্ক্রোনাস। একটি বিজ্ঞপ্তি ফিরে এসেছে যে সবকিছু ঠিক আছে - তার মানে এটি পৌঁছেছে; যদি এটি না আসে তবে এর অর্থ এটি খারাপ।

YN: – আমার দুটোই দরকার – আমি ডেলিভারির গ্যারান্টি সহ এবং ডেলিভারির গ্যারান্টি ছাড়াই দুটোই পাঠাতে পারব। এই দুটি ভিন্ন দৃশ্যকল্প. আমার কিছু লগ হারাতে হবে না বা কারণের মধ্যে সেগুলি হারাতে হবে না।

জেড: - আমি সময় নষ্ট করব না। এই বিষয়ে আরো আলোচনা করা প্রয়োজন. ধন্যবাদ.

মডারেটর: - কার প্রশ্ন আছে - আকাশের দিকে হাত!

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

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

জেড: "কিন্তু শেষ পর্যন্ত এটি যেভাবেই হোক না কেন।"

YN: - না, কোন হোস্ট নেই! এই সব ক্লিকহাউস হোস্ট কাজ করে.

জেড: - আচ্ছা, এবং "কিটেনহাউস", যা বিপরীত - তিনি কোথায় থাকেন?

YN: - ক্লিকহাউস হোস্টে, এটি ডিস্কে কিছু লেখে না।

জেড: - ধরা যাক।

মডারেটর: - তুমি কি সন্তুষ্ট? আমরা কি আপনাকে বেতন দিতে পারি?

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

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

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

YN: - অনুগ্রহ করে পরামর্শ দিন কি সারি ব্যবহার করা যেতে পারে?

জেড: - যে কোনো, এমনকি একটি গ্যারান্টি ছাড়াই যে তারা শৃঙ্খলাবদ্ধ। কিছু ধরণের রেডিস, আরএমকিউ...

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

মডারেটর: - ইউরি, আপনাকে অনেক ধন্যবাদ। আমি প্রশ্নোত্তর এখানেই শেষ করার প্রস্তাব করছি এবং বলব যারা প্রশ্ন করেছেন তাদের মধ্যে কাকে বইটি দেব।

YN: - আমি প্রথম ব্যক্তিকে একটি বই দিতে চাই যিনি একটি প্রশ্ন করেছিলেন।

মডারেটর: -আশ্চর্য! দারুণ! কল্পিত! অনেক ধন্যবাদ!

কিছু বিজ্ঞাপন 🙂

আমাদের সাথে থাকার জন্য আপনাকে ধন্যবাদ. আপনি আমাদের নিবন্ধ পছন্দ করেন? আরো আকর্ষণীয় বিষয়বস্তু দেখতে চান? অর্ডার দিয়ে বা বন্ধুদের সুপারিশ করে আমাদের সমর্থন করুন, $4.99 থেকে বিকাশকারীদের জন্য ক্লাউড ভিপিএস, এন্ট্রি-লেভেল সার্ভারগুলির একটি অনন্য অ্যানালগ, যা আমাদের দ্বারা আপনার জন্য উদ্ভাবিত হয়েছে: VPS (KVM) E5-2697 v3 (6 কোর) 10GB DDR4 480GB SSD 1Gbps থেকে $19 বা কিভাবে একটি সার্ভার শেয়ার করবেন সম্পর্কে সম্পূর্ণ সত্য? (RAID1 এবং RAID10 এর সাথে উপলব্ধ, 24 কোর পর্যন্ত এবং 40GB DDR4 পর্যন্ত)।

আমস্টারডামের ইকুইনিক্স টায়ার IV ডেটা সেন্টারে ডেল R730xd 2x সস্তা? শুধু এখানে 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 টিভি $199 থেকে নেদারল্যান্ডে! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 থেকে! সম্পর্কে পড়ুন কিভাবে ইনফ্রাস্ট্রাকচার কর্পোরেশন তৈরি করা যায়। এক পয়সার জন্য 730 ইউরো মূল্যের Dell R5xd E2650-4 v9000 সার্ভার ব্যবহার করে ক্লাস?

উত্স: www.habr.com