ভিক্টোরিয়ামেট্রিক্সে অপ্টিমাইজেশানে যান। আলেকজান্ডার ভ্যায়ালকিন

আমি আলেকজান্ডার ভ্যায়ালকিনের "ভিক্টোরিয়ামেট্রিক্সে অপ্টিমাইজেশানে যান" এর 2019 সালের শেষের প্রতিবেদনের প্রতিলিপি পড়ার প্রস্তাব করছি

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

এই প্রতিবেদনের ভিডিওর লিঙ্ক এখানে- https://youtu.be/MZ5P21j_HLE

স্লাইড

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

আমি বর্তমানে ভিক্টোরিয়ামেট্রিক্সে কাজ করছি। এটা কি এবং আমি সেখানে কি করছি? আমি এই উপস্থাপনায় এই বিষয়ে কথা বলব।

প্রতিবেদনের রূপরেখা নিম্নরূপ:

• প্রথমে, আমি আপনাকে বলব VictoriaMetrics কি।
• তারপর বলবো কোন টাইম সিরিজ।
• তারপর আমি আপনাকে বলব কিভাবে টাইম সিরিজ ডাটাবেস কাজ করে।
• এর পরে, আমি ডাটাবেসের আর্কিটেকচার সম্পর্কে কথা বলব: এটি কী নিয়ে গঠিত।
• এবং তারপরে ভিক্টোরিয়ামেট্রিক্সে থাকা অপ্টিমাইজেশানগুলিতে যাওয়া যাক। এগুলি ইনভার্টেড ইনডেক্সের জন্য একটি অপ্টিমাইজেশান এবং Go-তে বিটসেট বাস্তবায়নের জন্য একটি অপ্টিমাইজেশান৷

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

ভিক্টোরিয়ামেট্রিক্স অন্যান্য টাইম সিরিজ ডেটাবেসের তুলনায় সেরা ডেটা কম্প্রেশন প্রদান করে।

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

এছাড়াও, VictoriaMetrics স্কেল অনুভূমিকভাবে — অর্থাৎ, আপনি VictoriaMetrics ক্লাস্টারে অতিরিক্ত নোড যোগ করতে পারেন এবং এর কার্যক্ষমতা প্রায় রৈখিকভাবে বৃদ্ধি পাবে।

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

সময় সিরিজ কি কে জানে? তিনিও অনেক মানুষকে চেনেন। একটি টাইম সিরিজ হল জোড়ার একটি সিরিজ (timestamp, значение)যেখানে এই জোড়া সময় অনুসারে সাজানো হয়। মানটি একটি ফ্লোটিং পয়েন্ট সংখ্যা - float64।

প্রতিটি সময় সিরিজ অনন্যভাবে একটি কী দ্বারা চিহ্নিত করা হয়। এই চাবি কি? এটি কী-মান জোড়ার একটি অ-খালি সেট নিয়ে গঠিত।

এখানে একটি সময় সিরিজের একটি উদাহরণ. এই সিরিজের মূল হল জোড়ার তালিকা: __name__="cpu_usage" মেট্রিকের নাম, instance="my-server" যে কম্পিউটারে এই মেট্রিক সংগ্রহ করা হয়, datacenter="us-east" - এটি সেই ডেটা সেন্টার যেখানে এই কম্পিউটারটি অবস্থিত।

আমরা তিনটি মূল-মান জোড়া নিয়ে টাইম সিরিজের নাম পেয়েছি। এই কী জোড়ার তালিকার সাথে মিলে যায় (timestamp, value). t1, t3, t3, ..., tN টাইমস্ট্যাম্প, 10, 20, 12, ..., 15 অনুরূপ মান হয়. প্রদত্ত সারির জন্য এটি বর্তমান সিপিইউ-ব্যবহার।

কোথায় সময় সিরিজ ব্যবহার করা যেতে পারে? কেউ কি কোন ধারণা আছে?

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

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

টাইম সিরিজ ডাটাবেস কিসের জন্য? কেন আপনি সময় সিরিজ সঞ্চয় করার জন্য একটি নিয়মিত রিলেশনাল ডাটাবেস ব্যবহার করতে পারবেন না?

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

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

একটি উদাহরণ হিসাবে ভিক্টোরিয়ামেট্রিক্স ব্যবহার করে সময় সিরিজের জন্য একটি আধুনিক ডাটাবেসের আর্কিটেকচার কেমন দেখাচ্ছে তা এখানে।

এটি দুটি অংশ নিয়ে গঠিত। এটি ইনভার্টেড ইনডেক্সের স্টোর এবং সময় সিরিজের মানগুলির জন্য স্টোর। এই ভান্ডারগুলো আলাদা করা হয়।

যখন একটি নতুন রেকর্ড ডাটাবেসে আসে, তখন প্রদত্ত সেটের জন্য টাইম সিরিজ শনাক্তকারী খুঁজতে আমরা প্রথমে ইনভার্টেড ইনডেক্স অ্যাক্সেস করি। label=value এই মেট্রিকের জন্য। আমরা এই শনাক্তকারীটি খুঁজে পাই এবং ডেটা স্টোরে মান সংরক্ষণ করি।

যখন TSDB থেকে ডেটা আনার জন্য কিছু অনুরোধ আসে, আমরা প্রথমে ইনভার্টেড ইনডেক্সে উঠি। আমরা সবকিছু পাই timeseries_ids প্রদত্ত সেটের সাথে মেলে এমন রেকর্ড label=value. এবং তারপর আমরা ইনডেক্স করা ডেটা স্টোর থেকে সমস্ত প্রয়োজনীয় ডেটা পাই timeseries_ids.

একটি টাইম সিরিজ ডাটাবেস কিভাবে একটি ইনকামিং সিলেক্ট কোয়েরি পরিচালনা করে তার একটি উদাহরণ দেখা যাক।

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

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

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

আসলে, সবকিছু সহজ। এটি শুধুমাত্র একটি অভিধান যা একটি মান একটি কী মানচিত্র. একটি চাবি কি? এই দম্পতি label=valueযেখানে label и value লাইন হয় এবং মানগুলি একটি সেট timeseries_ids, যা প্রদত্ত জোড়া অন্তর্ভুক্ত করে label=value.

উল্টানো সূচক আপনাকে দ্রুত সবকিছু খুঁজে পেতে অনুমতি দেয় timeseries_ids, যা দিয়েছে label=value.

এটি আপনাকে দ্রুত খুঁজে পেতে অনুমতি দেয় timeseries_ids একাধিক জোড়ার জন্য সময় সিরিজ label=value, অথবা দম্পতিদের জন্য label=regexp. এটা কিভাবে হয়? সেটের ছেদ খুঁজে বের করে timeseries_ids প্রতি জোড়া জন্য label=value.

উল্টানো সূচকের বিভিন্ন বাস্তবায়ন বিবেচনা করুন। চলুন সহজ সরল নিষ্পাপ বাস্তবায়ন সঙ্গে শুরু করা যাক. সে এইরকম দেখাচ্ছে

ক্রিয়া getMetricIDs স্ট্রিং একটি তালিকা পায়. প্রতিটি লাইন ধারণ করে label=value. এই ফাংশন একটি তালিকা প্রদান করে metricIDs.

কিভাবে এটা কাজ করে? এখানে আমরা একটি গ্লোবাল ভেরিয়েবল নামক আছে invertedIndex. এটি একটি সাধারণ অভিধানmap) যা স্ট্রিংকে স্লাইস ইনটস করতে ম্যাপ করবে। লাইন ধারণ করে label=value.

ফাংশন বাস্তবায়ন: পেতে metricIDs প্রথম label=value, তারপর বাকি সব মাধ্যমে যান label=value, আমরা পেতে metricIDs তাদের জন্য. এবং ফাংশন কল intersectInts, যা নীচে আলোচনা করা হবে। এবং এই ফাংশন এই তালিকার ছেদ প্রদান করে।

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

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

এই সমস্যা যেমন রেডিমেড সমাধান ব্যবহার করে সমাধান করা যেতে পারে লেভেলডিবি, বা রকসডিবি.

সংক্ষেপে, আমাদের একটি ডাটাবেস দরকার যা আমাদের দ্রুত তিনটি কাজ করতে দেয়।

• প্রথম অপারেশন হচ্ছে লেখা ключ-значение এই ঘাঁটিতে। সে খুব দ্রুত এই কাজ করে। ключ-значение নির্বিচারে স্ট্রিং হয়
• দ্বিতীয় অপারেশন একটি প্রদত্ত কী দ্বারা একটি মান জন্য একটি দ্রুত অনুসন্ধান.
• এবং তৃতীয় অপারেশনটি একটি প্রদত্ত উপসর্গ দ্বারা সমস্ত মানগুলির জন্য একটি দ্রুত অনুসন্ধান।

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

লেভেলডিবি ব্যবহার করে একটি উল্টানো সূচক প্রয়োগ করা যেতে পারে। এটা কিভাবে করতে হবে? আমরা চাবি হিসাবে সংরক্ষণ করি label=value. এবং একটি মান হিসাবে - সময় সিরিজের সনাক্তকারী, যেখানে একটি জোড়া আছে label=value.

এই জুটির সঙ্গে আমাদের অনেক সময় সিরিজ থাকলে label=value, তাহলে এই ডাটাবেসে একই কী এবং ভিন্ন সহ অনেক সারি থাকবে timeseries_ids. সব একটি তালিকা পেতে timeseries_idsযে এটি দিয়ে শুরু করুন label=prefix, আমরা একটি রেঞ্জ স্ক্যান করি যার জন্য এই ডাটাবেসটি অপ্টিমাইজ করা হয়েছে। অর্থাৎ, আমরা শুরু হওয়া সমস্ত লাইন নির্বাচন করি label=prefix এবং প্রয়োজনীয় পান timeseries_ids.

এটি Go-তে দেখতে কেমন হবে তার একটি উদাহরণ বাস্তবায়ন। আমরা একটি উল্টানো সূচক আছে. এটি লেভেলডিবি।

ফাংশনটি নিষ্পাপ বাস্তবায়নের মতোই। এটি প্রায় লাইন দ্বারা লাইন নিষ্পাপ বাস্তবায়ন পুনরাবৃত্তি. শুধুমাত্র বিন্দু যে উল্লেখ না করে map আমরা উল্টানো সূচক উল্লেখ করি। আমরা প্রথমটির জন্য সমস্ত মান পাই label=value. তারপর আমরা বাকি সব জোড়া মাধ্যমে যেতে label=value এবং তাদের জন্য মেট্রিকআইডিগুলির সংশ্লিষ্ট সেটগুলি পান৷ তারপর আমরা ছেদ খুঁজে.

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

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

LevelDB-তে, প্রতিটি ফাংশন কলে GetValues আপনাকে শুরু হওয়া সমস্ত লাইনের মধ্য দিয়ে যেতে হবে label=value. এবং প্রতিটি লাইনের জন্য মান পান timeseries_ids. যেমন timeseries_ids এই একটি টুকরা সংগ্রহ timeseries_ids. স্পষ্টতই, এটি কেবল কী দ্বারা একটি নিয়মিত মানচিত্র অ্যাক্সেস করার চেয়ে অনেক ধীর।

দ্বিতীয় অসুবিধা হল লেভেলডিবি সি-তে লেখা। Go থেকে C ফাংশন অ্যাক্সেস করা খুব দ্রুত নয়। এটা শত শত ন্যানোসেকেন্ড লাগে. এটি খুব দ্রুত নয়, কারণ গো-তে লেখা একটি নিয়মিত ফাংশন কলের তুলনায়, যা 1-5 ন্যানোসেকেন্ড সময় নেয়, পারফরম্যান্সের পার্থক্য কয়েক ডজন। ভিক্টোরিয়ামেট্রিক্সের জন্য, এটি একটি মারাত্মক ত্রুটি ছিল 🙂

তাই আমি উল্টানো সূচকের আমার নিজের বাস্তবায়ন লিখেছি। এবং তাকে ডাকল মার্জসেট.

Mergeset MergeTree ডেটা কাঠামোর উপর ভিত্তি করে। এই ডেটা স্ট্রাকচারটি ClickHouse থেকে ধার করা হয়েছে। স্পষ্টতই দ্রুত পুনরুদ্ধারের জন্য মার্জেটটিকে অপ্টিমাইজ করা দরকার timeseries_ids প্রদত্ত কী দ্বারা। Mergeset সম্পূর্ণরূপে Go-তে লেখা। তুমি দেখতে পার গিটহাবের ভিক্টোরিয়ামেট্রিক্স সূত্র. মার্জেট বাস্তবায়ন ফোল্ডারে আছে /lib/mergeset. আপনি সেখানে কি ঘটছে তা বের করার চেষ্টা করতে পারেন।

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

মার্জসেটের অসুবিধাগুলো নিয়ে আমরা পরে কথা বলব। এখন উল্টানো সূচক বাস্তবায়ন করার সময় উৎপাদনে ভিক্টোরিয়ামেট্রিক্সের সমস্যাগুলি সম্পর্কে কথা বলা যাক।

কেন তারা উঠল?

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

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

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

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

একটি মেট্রিক থেকে, আমরা শুধুমাত্র একটি কম্পিউটারের জন্য 40 x 8 = 320 মেট্রিক পেয়েছি। আমরা 100 দ্বারা গুণ করি, আমরা 32 এর পরিবর্তে 000 পাই।

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

এর উচ্চ মন্থন হার একটি ঘনিষ্ঠভাবে কটাক্ষপাত করা যাক. উৎপাদনে উচ্চ মন্থন হারের কারণ কী? কারণ লেবেল এবং ট্যাগের কিছু অর্থ প্রতিনিয়ত পরিবর্তিত হয়।

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

এটা কি নেতৃত্বে? এই সত্য যে প্রতিটি নতুন স্থাপনার সাথে, সমস্ত পুরানো টাইম সিরিজ বাধাপ্রাপ্ত হয়, এবং তাদের পরিবর্তে, নতুন সময় সিরিজ একটি নতুন লেবেল মান দিয়ে শুরু হয় deployment_id. শত সহস্র এমনকি লক্ষ লক্ষ সারি হতে পারে।

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

উচ্চ মন্থন হারের প্রধান সমস্যা হল কিছু সময়ের ব্যবধানের জন্য নির্দিষ্ট লেবেলের সেটের জন্য সর্বকালের সিরিজের জন্য একটি ধ্রুবক অনুসন্ধান গতি প্রদান করা। এটি সাধারণত শেষ ঘন্টা বা শেষ দিনের জন্য সময়ের ব্যবধান।

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

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

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

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

পূর্ববর্তী সমাধানের তুলনায় এই সমাধানটির সুবিধা হল যে আমরা টাইম সিরিজের তথ্য নকল করি না যা সময়ের সাথে সাথে অদৃশ্য হয় না। তারা স্থায়ী এবং পরিবর্তন হয় না.

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

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

আমরা কিভাবে এই সমস্যার সমাধান করেছি? আমরা এটি একটি আসল উপায়ে সমাধান করেছি - একটি শনাক্তকারীর পরিবর্তে ইনভার্টেড ইনডেক্সের প্রতিটি রেকর্ডে একাধিক টাইম সিরিজ শনাক্তকারী সংরক্ষণ করে। অর্থাৎ আমাদের কাছে চাবি আছে label=value, যা প্রতিটি সময় সিরিজে ঘটে। এবং এখন আমরা কয়েকটি সংরক্ষণ করি timeseries_ids একটি এন্ট্রিতে

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

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

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

এবং এখন আমাদের রাম-এ ফিরে আসি - ইন্টারসেকশন ফাংশনে timeseries_ids. এর বাস্তবায়ন কি হতে পারে বিবেচনা করা যাক. এই ফাংশন আপনি খুঁজে পেতে পারবেন timeseries_ids একটি প্রদত্ত সেটের জন্য label=value.

প্রথম বিকল্প একটি নিষ্পাপ বাস্তবায়ন হয়. দুটি নেস্টেড লুপ। এখানে আমরা ফাংশনের ইনপুট পাই intersectInts দুই টুকরা - a и b. আউটপুটে, এটি আমাদের কাছে এই স্লাইসগুলির সংযোগস্থলে ফিরে আসা উচিত।

নিষ্পাপ বাস্তবায়ন এই মত দেখায়. আমরা স্লাইস থেকে সমস্ত মান পুনরাবৃত্তি করি a, এই লুপের ভিতরে আমরা স্লাইসের সমস্ত মান দিয়ে যাই b. এবং আমরা তাদের তুলনা করি। যদি তারা মেলে, তাহলে আমরা একটি ছেদ খুঁজে পেয়েছি। এবং এটি সংরক্ষণ করুন result.

অসুবিধা কি? চতুর্মুখী জটিলতা এর প্রধান ত্রুটি। উদাহরণস্বরূপ, যদি আপনার স্লাইস মাত্রা থাকে a и b প্রতিটি এক মিলিয়ন, তাহলে এই ফাংশনটি কখনই আপনাকে উত্তর দেবে না। কারণ এটিকে এক ট্রিলিয়ন পুনরাবৃত্তি করতে হবে, যা আধুনিক কম্পিউটারের জন্যও অনেক বেশি।

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

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

এবং অসুবিধা হল এই মানচিত্র তৈরি করার জন্য এই ফাংশনটি আরও মেমরির প্রয়োজন।

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

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

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

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

উপরন্তু, এটি মানচিত্র বাস্তবায়নের তুলনায় অনেক কম মেমরি ব্যবহার করে। কারণ আমরা এখানে আট-বাইটের মানের পরিবর্তে বিট সংরক্ষণ করি।

এই ধরনের বাস্তবায়নের অসুবিধা হল যে এটি এতটা স্পষ্ট নয়, তুচ্ছ নয়।

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

এই কাঠামোর বাস্তবায়ন বিবেচনা করুন। আপনি যদি এটি দেখতে চান তবে এটি ফোল্ডারে ভিক্টোরিয়ামেট্রিক্স উত্সে রয়েছে৷ lib/uint64set. এটি ভিক্টোরিয়ামেট্রিক্স ক্ষেত্রে বিশেষভাবে অপ্টিমাইজ করা হয়েছে, যেখানে timeseries_id একটি 64-বিট মান, যেখানে প্রথম 32 বিট মূলত ধ্রুবক এবং শুধুমাত্র শেষ 32 বিট পরিবর্তন হয়।

এই তথ্য কাঠামো ডিস্কে সংরক্ষণ করা হয় না, এটি শুধুমাত্র মেমরিতে কাজ করে।

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

ফাংশন আছে add, যা নতুন মান যোগ করে। একটি ফাংশন আছে has, যা নতুন মান পরীক্ষা করে। এবং একটি ফাংশন আছে del, যা মান অপসারণ করে। একটি সহায়ক ফাংশন আছে len, যা সেটের আকার প্রদান করে। ফাংশন clone সেট ক্লোন করে। এবং ফাংশন appendto এই সেটটিকে স্লাইসে রূপান্তরিত করে timeseries_ids.

এই ডাটা স্ট্রাকচারের বাস্তবায়ন কেমন দেখায় তা এখানে। সেটটিতে দুটি উপাদান রয়েছে:

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

• দ্বিতীয় ক্ষেত্র হল buckets. এটি একটি কাঠামো থেকে একটি টুকরা bucket32. প্রতিটি কাঠামো রয়েছে hi ক্ষেত্র এই শীর্ষ 32 বিট হয়. এবং দুটি টুকরা - b16his и buckets থেকে bucket16 কাঠামো

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

Bucket64 একটি অ্যারে নিয়ে গঠিত uint64. এই ধ্রুবকগুলি ব্যবহার করে দৈর্ঘ্য গণনা করা হয়। একটি bucket16 সর্বোচ্চ সংরক্ষণ করা যেতে পারে 2^16=65536 বিট. যদি এটি 8 দ্বারা ভাগ করা হয়, তাহলে এটি 8 কিলোবাইট। আবার 8 দ্বারা ভাগ করুন, এটি 1000 uint64 অর্থ অর্থাৎ Bucket16 - এটি আমাদের 8-কিলোবাইট গঠন।

আসুন বিবেচনা করা যাক কিভাবে একটি নতুন মান যোগ করার জন্য এই কাঠামোর একটি পদ্ধতি প্রয়োগ করা হয়।

সবকিছু দিয়ে শুরু হয় uint64 মান আমরা শীর্ষ 32 বিট গণনা করি, আমরা নীচের 32 বিট গণনা করি। আমরা সব মাধ্যমে যেতে buckets. প্রতিটি বালতিতে শীর্ষ 32 বিটের সাথে তুলনা করুন মান যোগ করা হচ্ছে। এবং যদি তারা মেলে, তাহলে আমরা ফাংশন কল add গঠন b32 buckets. এবং সেখানে নীচের 32 বিট যোগ করুন। আর যদি ফিরে আসে true, তাহলে এর মানে হল যে আমরা সেখানে এমন একটি মান যোগ করেছি এবং আমাদের কাছে এমন একটি মান নেই। যদি ফিরে আসে false, তারপর যেমন একটি মান ইতিমধ্যে বিদ্যমান. তারপর আমরা গঠন উপাদান সংখ্যা বৃদ্ধি.

যদি আমরা সঠিকটি খুঁজে না পাই bucket কাঙ্ক্ষিত হাই-মানের সাথে, তারপর আমরা ফাংশনটিকে কল করি addAlloc, যা একটি নতুন করতে হবে bucket, বালতি কাঠামোতে এটি যোগ করা হচ্ছে।

এই ফাংশন বাস্তবায়ন b32.add. এটি পূর্ববর্তী বাস্তবায়নের অনুরূপ। আমরা উচ্চ 16 বিট, কম 16 বিট গণনা করি।

তারপর আমরা সমস্ত শীর্ষ 16 বিট মাধ্যমে যান. আমরা মিল খুঁজে. এবং যদি একটি মিল থাকে, আমরা যোগ পদ্ধতিকে কল করি, যা আমরা পরবর্তী পৃষ্ঠায় বিবেচনা করব bucket16.

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

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

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

বিটসেট সম্পর্কে আমার একটি প্রশ্ন আছে। ভেক্টর বুলের C++ বাস্তবায়নের অনুরূপ, বিটসেট অপ্টিমাইজ করা হয়েছে। আপনি কি সেখান থেকে বাস্তবায়ন নিয়েছিলেন?

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

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

আমি একটি দ্বিতীয় প্রশ্ন আছে. InfluxDB থেকে মৌলিক পার্থক্য কি?

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

দ্বিতীয় মূল পার্থক্য হল যে InfluxDB-এর অদ্ভুত ক্যোয়ারী ভাষা আছে - Flux এবং InfluxQL। তারা তুলনায় সময় সিরিজ সঙ্গে কাজ করার জন্য খুব সুবিধাজনক নয় PromQL, যা ভিক্টোরিয়ামেট্রিক্স দ্বারা সমর্থিত। PromQL হল প্রমিথিউসের একটি প্রশ্নের ভাষা।

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

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

আমি একটি স্পষ্ট প্রশ্ন আছে. আমি সঠিকভাবে বুঝতে পেরেছি যে আপনি যে বিষয়ে কথা বলেছেন সেখানে কিছু সমস্যা ছিল, যে এই উল্টানো সূচকটি মেমরিতে ফিট করে না, তাই সেখানে পার্টিশন চলছে?

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

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

আমি দ্বিতীয়টির উত্তর দেব। আমরা এখনও সেখানে পাইনি. তবে প্রয়োজন হলে আমরা করব। প্রথম প্রশ্ন কি ছিল?

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

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

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

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

কেন আমরা ডেটা অতিক্রম করতে কার্সার ব্যবহার করি না?

হ্যাঁ।

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

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

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

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

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

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

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

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

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

আরেকটি সুবিধা হল VictoriaMetrics এই ডেটা দক্ষতার সাথে সংকুচিত করে। উৎপাদনের জন্য গড়ে কম্প্রেশন 0,4 থেকে 0,8 বাইট প্রতি পয়েন্ট। প্রতিটি বিন্দু একটি টাইমস্ট্যাম্প + মান। এবং এটি গড়ে এক বাইটের কম সংকুচিত করে।

সের্গেই। আমার একটা প্রশ্ন আছে. নূন্যতম রেকর্ডিং সময় স্লাইস কি?

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

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

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

ধন্যবাদ! এবং আরেকটি প্রশ্ন। PromQL এর সামঞ্জস্য কি?

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

টেলিগ্রাম চ্যানেল ভিক্টোরিয়ামেট্রিক্স.

শুধুমাত্র নিবন্ধিত ব্যবহারকারীরা জরিপে অংশগ্রহণ করতে পারবেন। সাইন ইন করুনকরুন।

প্রমিথিউসের জন্য দীর্ঘমেয়াদী স্টোরেজ হিসাবে ভিক্টোরিয়ামেট্রিক্সে স্যুইচ করা থেকে আপনাকে কী বাধা দিচ্ছে? (মন্তব্যে লিখুন, আমি পোলে যোগ করব))

• 71,4%Prometheus5 ব্যবহার করছেন না

• 28,6%VictoriaMetrics2 সম্পর্কে জানতাম না

7 জন ব্যবহারকারী ভোট দিয়েছেন। 12 জন ব্যবহারকারী বিরত ছিলেন।

উত্স: www.habr.com