কিভাবে আমরা একাধিক টাইম সিরিজ ডাটাবেস পরীক্ষা করেছি

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

এটা মনে হতে পারে যে 2019 সালে একটি নিবন্ধ যা TSDB ব্যবহার করার জন্য উপযুক্ত তা শুধুমাত্র একটি বাক্যে থাকবে: "শুধু ক্লিকহাউস ব্যবহার করুন।" কিন্তু... সূক্ষ্মতা আছে.

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

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

সমস্যা গঠন

প্রথমত, একটি প্রয়োজনীয় ভূমিকা। কেন আমাদের নিজস্ব মনিটরিং সিস্টেমের আদৌ প্রয়োজন এবং এটি কীভাবে ডিজাইন করা হয়েছিল?

আমরা 2008 সালে সহায়তা পরিষেবা প্রদান করা শুরু করি, এবং 2010 সাল নাগাদ এটি স্পষ্ট হয়ে ওঠে যে ক্লায়েন্ট অবকাঠামোতে ঘটতে থাকা প্রক্রিয়াগুলি সম্পর্কে সেই সময়ে বিদ্যমান সমাধানগুলির সাথে ডেটা একত্রিত করা কঠিন হয়ে পড়ে (আমরা কথা বলছি, ঈশ্বর আমাকে ক্ষমা করুন, Cacti, Zabbix) এবং উদীয়মান গ্রাফাইট)।

আমাদের প্রধান প্রয়োজনীয়তা ছিল:

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

এই নিবন্ধে আমরা শেষ বিন্দু আগ্রহী.

স্টোরেজের কথা বললে, প্রয়োজনীয়তাগুলি নিম্নরূপ ছিল:

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

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

এইভাবে, আমরা ডেটা সম্পূর্ণরূপে রেন্ডার হওয়ার আগে একটি সেকেন্ড 200 ms পর্যন্ত বিস্তারিত সহ নতুন দুই-সপ্তাহের ডেটার একটি নমুনা অর্জন করেছি এবং এই সিস্টেমে বেশ দীর্ঘ সময় ধরে বসবাস করেছি।

এদিকে, সময় কেটেছে এবং ডেটার পরিমাণ বেড়েছে। 2016 সালের মধ্যে, ডেটা ভলিউম দশ টেরাবাইটে পৌঁছেছিল, যা ভাড়া করা SSD স্টোরেজের পরিপ্রেক্ষিতে একটি উল্লেখযোগ্য ব্যয় ছিল।

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

যাইহোক, কোম্পানির মূল সিস্টেমটি স্থিরভাবে কাজ করতে থাকে এবং আমি অন্য কিছুতে স্যুইচ করার সাথে পরীক্ষা করতে চাইনি।

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

ইতিমধ্যে নির্দিষ্ট স্টোরেজ প্রয়োজনীয়তা ছাড়াও, নতুন হাজির হয়েছে:

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

আমরা কি সিস্টেম বিবেচনা শুরু করেছি?

Apache Hive/Apache Impala
একটি পুরানো, যুদ্ধ-পরীক্ষিত Hadoop স্ট্যাক। মূলত, এটি একটি এসকিউএল ইন্টারফেস যা এইচডিএফএস-এ নেটিভ ফরম্যাটে ডেটা সংরক্ষণের উপরে তৈরি করা হয়েছে।

পেশাদাররা।

• স্থিতিশীল অপারেশন সহ, ডেটা স্কেল করা খুব সহজ।
• ডেটা স্টোরেজের জন্য কলাম সমাধান রয়েছে (কম স্থান)।
• সম্পদ উপলব্ধ হলে সমান্তরাল কাজগুলির খুব দ্রুত সঞ্চালন।

কনস।

• এটা Hadoop, এবং এটা ব্যবহার করা কঠিন. যদি আমরা ক্লাউডে একটি রেডিমেড সমাধান নিতে প্রস্তুত না হই (এবং আমরা খরচের ক্ষেত্রে প্রস্তুত নই), পুরো স্ট্যাকটিকে অ্যাডমিনদের হাতে একত্রিত এবং সমর্থন করতে হবে এবং আমরা সত্যিই চাই না এই.
• ডেটা একত্রিত করা হয় আসলেই দ্রুত.

তবে:

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

ড্রুড/পিনোট

বিশেষভাবে TSDB সম্পর্কে আরও অনেক কিছু আছে, কিন্তু আবার, Hadoop স্ট্যাক।

আছে ড্রুইড এবং পিনোট বনাম ক্লিকহাউসের সুবিধা এবং অসুবিধার তুলনা করে দুর্দান্ত নিবন্ধ .

কিছু কথায়: ড্রুইড/পিনোট ক্লিকহাউসের চেয়ে ভালো দেখায় যেখানে:

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

বিপরীত ক্ষেত্রে, ClickHouse ভাল পারফর্ম করে, এবং এটি আমাদের ক্ষেত্রে।

ক্লিকহাউস

• এসকিউএল-এর মতো
• পরিচালনা করা সহজ।
• মানুষ বলে এটা কাজ করে।

পরীক্ষার জন্য সংক্ষিপ্ত তালিকাভুক্ত হয়.

ইনফ্লাক্সডিবি

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

পরীক্ষার জন্য সংক্ষিপ্ত তালিকাভুক্ত হয়.

কাসান্দ্রা

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

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

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

প্রমিথিউস

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

পরীক্ষার পদ্ধতি এবং ফলাফল

সুতরাং, আমরা নিম্নলিখিত 5টি কনফিগারেশনে 6টি ডাটাবেস পরীক্ষা করেছি: ClickHouse (1 নোড), ClickHouse (3 নোডের জন্য বিতরণ করা টেবিল), InfluxDB, Mysql 8, Cassandra (3 নোড) এবং Prometheus. পরীক্ষার পরিকল্পনা নিম্নরূপ:

1. এক সপ্তাহের জন্য ঐতিহাসিক ডেটা আপলোড করুন (প্রতিদিন 840 মিলিয়ন মান; 208 হাজার মেট্রিক্স);
2. আমরা একটি রেকর্ডিং লোড তৈরি করি (6 লোড মোড বিবেচনা করা হয়েছিল, নীচে দেখুন);
3. রেকর্ডিংয়ের সমান্তরালে, আমরা পর্যায়ক্রমে নির্বাচন করি, চার্টের সাথে কাজ করা ব্যবহারকারীর অনুরোধগুলিকে অনুকরণ করে। জিনিসগুলিকে খুব বেশি জটিল না করার জন্য, আমরা এক সপ্তাহের জন্য 10টি মেট্রিকের জন্য ডেটা নির্বাচন করেছি (এটি ঠিক কতগুলি CPU গ্রাফে রয়েছে)।

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

• মেট্রিক্সের মোট সংখ্যা যাতে ডেটা লেখা হয়;
• একটি মেট্রিকে মান পাঠানোর জন্য ব্যবধান;
• ব্যাচ আকার.

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

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

এবং এখানে, এই সমস্ত কিছু বিবেচনায় নিয়ে, আমাদের 6টি ডাটাবেস লেখা লোড মোড:

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

পরীক্ষার ফলাফল নিম্নরূপ:

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

ফলস্বরূপ,: ClickHouse এবং InfluxDB নিজেদেরকে সেরা হিসেবে দেখিয়েছে, কিন্তু Influx থেকে একটি ক্লাস্টার শুধুমাত্র এন্টারপ্রাইজ সংস্করণের ভিত্তিতে তৈরি করা যেতে পারে, যার জন্য টাকা খরচ হয়, যখন ClickHouse এর কোনো খরচ নেই এবং এটি রাশিয়ায় তৈরি। এটা যৌক্তিক যে মার্কিন যুক্তরাষ্ট্রে পছন্দটি সম্ভবত inInfluxDB-এর পক্ষে, এবং আমাদের দেশে এটি ClickHouse-এর পক্ষে।

উত্স: www.habr.com