How Coralogix cut processing times from 30 seconds to 86 milliseconds with a PostgreSQL to ScyllaDB migration. গতি গুরুত্বপূর্ণ , একটি পর্যবেক্ষণযোগ্য প্ল্যাটফর্ম যা ডেভেলপমেন্ট টিমগুলি সমস্যাগুলির মধ্যে এগিয়ে যাওয়ার আগে ঘটনাগুলি সনাক্ত করতে বিশ্বাস করে. Coralogix একটি বাস্তব সময় স্ট্রিমিং বিশ্লেষণ পাইপলাইন ব্যবহার করে, নজরদারি, দৃশ্যমানকরণ এবং সতর্কতা বৈশিষ্ট্যগুলি সরবরাহ করে যা ইনডেক্সিং প্রয়োজন না। কোরআন Coralogix এর প্রধান পার্থক্যগুলির মধ্যে একটি হল একটি বিতরণীয় চাহিদা ইঞ্জিন যা দূরবর্তী স্টোরেজে গ্রাহকের আর্কাইভ থেকে মানচিত্রিত ডেটা সম্পর্কে দ্রুত চাহিদাগুলির জন্য। এটি প্রাথমিকভাবে ভিত্তিক বস্তু স্টোরেজের উপরে একটি স্ট্যাটাস ছাড়াই চাহিদা ইঞ্জিন হিসাবে ডিজাইন করা হয়েছিল, কিন্তু চাহিদা চালানোর সময় পার্কেট মেটাডেটা পড়া একটি অস্বীকারযোগ্য ল্যাটিনেশন হিট প্রবর্তন করে। পার্কিং মূল মেটাস্টোর বাস্তবায়ন, PostgreSQL উপর ভিত্তি করে, তাদের চাহিদাগুলির জন্য যথেষ্ট দ্রুত ছিল না. সুতরাং, দল একটি নতুন বাস্তবায়ন চেষ্টা করেছিল - এইবার, PostgreSQL এর পরিবর্তে ScyllaDB সঙ্গে. স্পাইলার: এটি কাজ করেছিল. তারা আকর্ষণীয় পারফরম্যান্স বৃদ্ধি অর্জন করেছিল - 30 সেকেন্ড থেকে 86 মিলিসেকেন্ড পর্যন্ত অনুরোধ প্রক্রিয়াকরণের সময় কেটে। ScyllaDB Summit 24 এ আমাদের সাথে যোগ দিন এবং টিমগুলি কীভাবে তাদের সবচেয়ে কঠিন ডাটাবেস চ্যালেঞ্জগুলি মোকাবেলা করছে তা সম্পর্কে আরও প্রাকৃতিক রিপোর্ট শুনুন। ScyllaDB Summit 2024 এখন একটি Wrap! Update: মেটাস্টোরের উদ্দেশ্য ও প্রয়োজনীয়তা মেটাস্টোর বাস্তবায়নের বিস্তারিতগুলিতে প্রবেশ করার আগে, চলুন এক ধাপ পিছিয়ে যাক এবং প্রথমে একটি মেটাস্টোর নির্মাণ করার কারণগুলি দেখি। "আমরা প্রাথমিকভাবে এই প্ল্যাটফর্মটি ভিত্তিক বস্তুর স্টোরেজের উপরে একটি স্ট্যাটাসহ চাহিদা ইঞ্জিন হিসাবে ডিজাইন করেছি - কিন্তু আমরা দ্রুত বুঝতে পেরেছি যে চাহিদা পরিচালনার সময় পার্কেট মেটাডেটা পড়ার খরচ চাহিদাটির সময় একটি বড় শতাংশ হয়," ব্যাখ্যা করেন ড্যান হ্যারিস. তারা বুঝতে পেরেছে যে তারা এটি একটি দ্রুত স্টোরেজ সিস্টেমে স্থাপন করে যা তারা দ্রুত চাহিদা করতে পারে (পার্কেট মেটাডেটা সরাসরি ভিত্তিক বস্তুর স্টোরেজ থেকে পড়া এবং প্রক্রিয়াকরণ করার পরিবর্তে)। তারা এমন একটি সমাধান চিন্তা করে যা: উচ্চ পরিমাপযোগ্যতা এবং পারফরম্যান্সের জন্য একটি বিচ্ছিন্ন ফরম্যাটে পার্কেট মেটাডেটা সঞ্চয় করুন প্রত্যেক প্রশ্নের জন্য স্ক্যান করার জন্য ফাইলগুলি কার্যকরভাবে সনাক্ত করতে bloom ফিল্টারগুলি ব্যবহার করুন ট্রানজিশন কমিশন লগ ব্যবহার করুন ট্রানজিশনগতভাবে অন্তর্ভুক্ত বস্তুর স্টোরেজে বিদ্যমান ডেটা যোগ, আপডেট এবং প্রতিস্থাপন করতে গুরুত্বপূর্ণ প্রয়োজনীয়তাগুলির মধ্যে রয়েছে কম দীর্ঘস্থায়ীতা, পড়া / লিখা ক্ষমতা এবং ভিত্তিক স্টোরেজের দীর্ঘস্থায়ীতা উভয় ক্ষেত্রে স্ক্যালারিযোগ্যতা। প্রতি ঘন্টায় 2,000 পার্কেট ফাইল (50,000 প্রতিদিন) উত্পাদন করে, প্রতিদিন মোট 15 টিবি, শুধুমাত্র পার্কেট মেটাডেটা 20 জিবি ফলাফল . একক গ্রাহক for a single day একক গ্রাহক একদিনের জন্য PostgreSQL প্রারম্ভিক বাস্তবায়ন "আমরা Postgres এ প্রাথমিক বাস্তবায়ন শুরু করেছিলাম, যখন বুঝতে পারলাম যে একটি অ-প্রচারিত ইঞ্জিন দীর্ঘমেয়াদিভাবে যথেষ্ট হবে না," ড্যান স্বীকার করেছিলেন। যে প্রাথমিক বাস্তবায়নটি একটি লাইন গ্রুপ এবং একটি পার্কেট ফাইলের প্রতিনিধিত্ব করে "ব্লকগুলি" মত গুরুত্বপূর্ণ তথ্য সংরক্ষণ করে। Block url: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet Row group: 0, 1, 2 … Min timestamp Max timestamp Number of rows Total size … পাঠের অপ্টিমাইজ করার জন্য, তারা কার্যকরী ডেটা কাটানোর জন্য ফ্লোম ফিল্টার ব্যবহার করে। ড্যান বিস্তারিতভাবে বলেন, "সবশেষে, আমরা পুরো টেক্সট অনুসন্ধানের মতো কিছু সমর্থন করতে চাই। মূলত, যখন আমরা আমাদের সিস্টেমে এই ফাইলগুলি ইনজেকশন করি, তখন আমরা ফাইলটিতে পাওয়া সমস্ত আলাদা টোকেনের জন্য ফ্লোম ফিল্টার তৈরি করতে পারি। উপরন্তু, তারা প্রতিটি পার্কেট ফাইলের জন্য কলাম মেটাডেটা সংরক্ষণ করে। Block URL Row Group Column Name Column metadata (blob) ড্যান ব্যাখ্যা করেন, "আমরা যে ফাইলগুলি লিখছি তা বেশ বিস্তৃত, কখনও কখনও ২০,০০০ কলাম পর্যন্ত। ScyllaDB বাস্তবায়ন পরে, ড্যানের টিম সহকর্মী, সান্ত্বিয়ান ভার্কুইসের দ্বারা বর্ণিত ScyllaDB বাস্তবায়নের দিকে তাকান। ব্লক ডেটা মডেলিং নতুন বাস্তবায়নের জন্য ব্লক মডেলিং পুনরায় পরীক্ষা করা উচিত ছিল. এখানে একটি ব্লক URL এর একটি উদাহরণ: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet সাহসী অংশটি গ্রাহকের শীর্ষ স্তরের বাক্স; বাক্সের ভিতরে, আইটেমগুলি ঘন্টা দ্বারা বিভক্ত হয়। কিন্তু কিছু গ্রাহকদের অন্যান্য গ্রাহকদের তুলনায় অনেক বেশি পার্কেট ফাইল রয়েছে, এবং তারা জিনিসগুলি ভারসাম্য রাখতে চেয়েছিল। ((Block url, row group))? এই এককভাবে একটি নির্দিষ্ট ব্লক চিহ্নিত করে, কিন্তু একটি নির্দিষ্ট দিনের জন্য সমস্ত ব্লকগুলি তালিকাভুক্ত করা কঠিন হবে কারণ টাইমস্ট্যাম্পটি কীতে নেই ((Table url, time))? এটি কাজ করে কারণ যদি আপনি 24 ঘন্টা অনুসন্ধান করতে পারেন, আপনি খুব সহজেই অনুসন্ধান করতে পারেন ((Table url, hour), block url, row group)? এটাই তারা নির্বাচন করেছিলেন. ব্লক url এবং row group clustering keys হিসাবে যোগ করে, তারা একটি ঘন্টার মধ্যে একটি নির্দিষ্ট ব্লক সহজেই পুনরুদ্ধার করতে পারে, যা ব্লক এবং row groups আপডেট বা মুছে ফেলার প্রক্রিয়াকে সহজ করে তোলে। ব্লুম ফিল্টার Chunking এবং ডেটা মডেলিং পরবর্তী চ্যালেঞ্জ: কিভাবে নিশ্চিত করা যায় যে নির্দিষ্ট বিটগুলি সেট করা হয়, যেহেতু ScyllaDB এর জন্য বক্সের বাইরের ফাংশনগুলি অফার করে না। টিমটি ফ্লোম ফিল্টারগুলি পড়তে এবং অ্যাপ্লিকেশনে তাদের প্রক্রিয়াকরণ করার সিদ্ধান্ত নিয়েছে। যাইহোক, মনে রাখবেন যে তারা গ্রাহক প্রতিদিন 50,000 ব্লক পর্যন্ত কাজ করছে, প্রতিটি ব্লকটি ফ্লোম ফিল্টার অংশের জন্য 262 KB অন্তর্ভুক্ত। যা মোট 12 গিগাবাইট - এক চাহিদা জন্য অ্যাপ্লিকেশনে ফিরে আসার জন্য অতিরিক্ত। কিন্তু তাদের প্রতিবার পুরো ফ্লোম ফিল্টারটি পড়তে হবে না; তাদের শুধুমাত্র অংশগুলির প্রয়োজন ছিল ডাটা মডেলিংয়ের জন্য, একটি বিকল্প ছিল ব্যবহার করা প্রাইম কী হিসাবে. যা প্রতিটি ফ্লোম ফিল্টার প্রতি 8192 বাইটের 32 বাইট উত্পাদন করবে, যা প্রতিটি পার্শ্ববর্তী পার্শ্ববর্তী প্রায় 262 KB এর সাথে একটি সমান বিতরণের ফলাফল। একই পার্শ্ববর্তী প্রতিটি ফ্লোম ফিল্টারের সাথে, এটি একটি একক ব্যাচ চাহিদা দিয়ে ডেটা ইনপুট এবং মুছে ফেলতে সহজ হবে। কিন্তু এমন একটি ধরা আছে যা পড়ার দক্ষতা প্রভাবিত করে: আপনি ফ্লোম ফিল্টারটি পড়ার আগে ব্লকটির আইডি জানতে হবে। উপরন্তু, পদ্ধতিটি একটি উল্লেখযোগ্য সংখ্যক পার্শ্ববর্তী অ্যাক্স অন্তর্ভুক্ত করবে; 50K ব্লকগুলি 50K পার্শ্ব ((block_url, row_group, chunk index ) আরেকটি বিকল্প (যা তারা শেষ পর্যন্ত সিদ্ধান্ত নিয়েছে): লক্ষ্য করুন যে এটি ব্লকগুলির সাথে একই পার্টিশন কী, এবং পার্টিশন কীটিতে একটি ইনডেক্স যোগ করা হয় যা অনুসন্ধান ইঞ্জিন দ্বারা প্রয়োজনীয় nth টোকেনকে প্রতিনিধিত্ব করে. এই পদ্ধতিতে, একটি 24 ঘন্টা উইন্ডোতে 5 টোকেন স্ক্যান করে 120 পার্টিশন - পূর্ববর্তী ডেটা মডেলিং বিকল্পের তুলনায় একটি চমৎকার উন্নতি। ((Table url, hour, chunk index), ব্লক url, row group) উপরন্তু, এই পদ্ধতিটি ফ্লোম ফিল্টার পড়ার আগে ব্লক আইডি প্রয়োজন হয় না - দ্রুত পাঠের অনুমতি দেয়। অবশ্যই, সবসময় বাধ্যবাধকতা থাকে। এখানে, ব্লক করা ফ্লোম ফিল্টার পদ্ধতির কারণে, তাদের একক ফ্লোম ফিল্টার 8192 অনন্য পার্টিশনগুলিতে ভাগ করতে হবে। এই শেষ পর্যন্ত পূর্ববর্তী পার্টিশনিং পদ্ধতির তুলনায় ইনজেকশন গতি প্রভাবিত করে যা একই সময়ে সমস্ত ফ্লোম ফিল্টার টুকরা ইনজেকশন করার অনুমতি দেয়। যাইহোক, একটি ঘন্টার মধ্যে একটি নির্দিষ্ট ব্লক দ্রুত পড়ার ক্ষমতা দ্রুত লিখার চেয়ে তাদের জন্য গুরুত্বপূর্ণ - তাই তারা সিদ্ধান্ত নিয়েছে যে ডাটা মডেলিং আশ্চর্যজনকভাবে, SQL থেকে NoSQL-এ স্থানান্তরিত হওয়ায় কিছু পরীক্ষা ও ত্রুটি সহ বেশ কয়েকটি ডেটা মডেলিং পুনরায় কাজ করা হয়েছে. উদাহরণস্বরূপ, সান্ত্বিয়ান ভাগ করেছিলেন, "একদিন, আমি বুঝতে পেরেছিলাম যে আমরা মিন এবং ম্যাক্স টাইমস্ট্যাম্পগুলি বিভ্রান্ত করেছিলাম - এবং আমি জানতাম কিভাবে আমি এটি ঠিক করতে যাচ্ছি। অবশেষে, তারা টেবিলটি কেটে এবং আবার শুরু করার সিদ্ধান্ত নিয়েছে এবং মাইগ্রেশন কোড লিখে। পারফরম্যান্স লাভ ডেটা মডেলিং কাজের প্রয়োজনীয়তা সত্ত্বেও, মাইগ্রেশন ভালভাবে খরচ করে. মেটাস্টোর ব্লক তালিকা জন্য: প্রতিটি নোট বর্তমানে 4-5 টিবি ব্যাবহার করে। তারা বর্তমানে প্রতি সেকেন্ডে প্রায় 10K লিখা প্রক্রিয়াকরণ করছে, P99 ল্যাটিনেশনটি এক মিলিসেকেন্ডের নিচে স্থায়ীভাবে। ব্লক তালিকা একটি ঘন্টায় প্রায় 2000 পার্কেট ফাইল ফলাফল; তাদের ফ্লোম ফিল্টার সঙ্গে, তারা 20 মাইলস সেকেন্ডের মধ্যে প্রক্রিয়াকরণ করা হয়। 50K ফাইলের জন্য, এটি 500 মিলি সেকেন্ডের কম। কিন্তু, 50K পার্কেট ফাইলের জন্য, 500 মিলি সেকেন্ড তাদের চাহিদাগুলির জন্য ভাল। কলাম মেটাডাটা প্রক্রিয়াকরণে, P50 বেশ ভাল, কিন্তু একটি উচ্চ রেকর্ড ল্যাটিনতা আছে. সান্ত্বিয়ান ব্যাখ্যা করেছিলেন: "সবচেয়ে বড় সমস্যা হল যে যদি আমাদের 50K পার্কেট ফাইল থাকে, তাহলে আমাদের প্রয়োগকারীরা সমানভাবে এই সবগুলি পুনরুদ্ধার করছে. এর মানে আমরা অনেক সমস্যা আছে এবং আমরা সেরা ডিস্ক ব্যবহার করি না। ScyllaDB সেটআপ উল্লেখযোগ্যভাবে, Coralogix প্রথম ScyllaDB আবিষ্কার থেকে মাত্র 2 মাসের মধ্যে ডেটা terabytes সঙ্গে উত্পাদন প্রবেশ করতে চলেছে (এটি একটি SQL এ NoSQL মাইগ্রেশন ছিল যা ডেটা মডেলিং কাজ প্রয়োজন, অনেক সহজ Cassandra বা DynamoDB মাইগ্রেশন নয়)। রাস্তার উপরে রাস্তায় লিখেছিলেন। এবং তারা খুঁজে পায় , এবং যেহেতু Coralogix এর জন্য তাদের নিজস্ব গ্রাহকদের একটি সাশ্রয়ী পর্যবেক্ষণযোগ্য বিকল্প অফার করা গুরুত্বপূর্ণ, Coralogix টিম তাদের ScyllaDB অবকাঠামোর সুবিধাজনক মূল্য কর্মক্ষমতা নিয়ে খুশি ছিল: একটি 3-নোড গ্রুপ: ScyllaDB Rust ড্রাইভার Kubernetes জন্য ScyllaDB অপারেটর ScyllaDB নজরদারি ScyllaDB ম্যানেজার 8 ভিপিএল 32 জিবি মেমরি অস্ত্র / গ্র্যাভিটন EBS ভলিউম (gp3) 500 এমবিপিএস ব্যান্ডবাইড এবং 12k IOPS সঙ্গে ARM ব্যবহার করে খরচ কমে যায়, এবং EBS (gp3) ভলিউমগুলি ব্যবহার করার সিদ্ধান্তটি অবশেষে উপলব্ধতা, নমনীয়তা এবং মূল্য কর্মক্ষমতাতে পরিণত হয়. তারা স্বীকার করে, "এটি একটি বিতর্কিত সিদ্ধান্ত - কিন্তু আমরা এটি কাজ করার চেষ্টা করছি এবং আমরা দেখব কতক্ষণ আমরা এটি পরিচালনা করতে পারি। শিখেছি শিক্ষা এখান থেকে শিখেছি মূল শিক্ষাগুলো... ScyllaDB এবং Postgres এর সাথে কাজ করার মধ্যে সবচেয়ে বড় পার্থক্য হল আপনি আপনার পার্টিশন এবং পার্টিশন আকার সম্পর্কে বেশ সাবধানে চিন্তা করতে হবে। Keep an eye on partition sizes: আপনি পড়া / লিখা প্যাটার্ন সম্পর্কে সতর্কভাবে চিন্তা করতে হবে. আপনার কাজের লোডটি পড়া ও লিখা কঠিন? এটি পড়া ও লিখা একটি ভাল মিশ্রণ অন্তর্ভুক্ত করে? অথবা, এটি মূলত লিখা ও লিখা কঠিন? Coralogix এর কাজের লোডগুলি বেশ লিখা ও লিখা কঠিন কারণ তারা ক্রমাগত ডেটা গ্রহণ করে, কিন্তু তাদের পড়া অগ্রাধিকার দিতে হবে কারণ পড়া ল্যাটিনতা তাদের ব্যবসার জন্য সবচেয়ে গুরুত্বপূর্ণ। Think about read/write patterns: টিম স্বীকার করে যে তারা EBS ব্যবহার না করার জন্য সতর্ক করা হয়েছিল: "আমরা শুনিনি, কিন্তু আমরা সম্ভবত করা উচিত. যদি আপনি ScyllaDB ব্যবহারের বিবেচনা করছেন, তবে এটি সম্ভবত একটি ভাল ধারণা হতে পারে যে EBS ভলিউমগুলি ব্যবহার করার চেষ্টা করার পরিবর্তে স্থানীয় এসএসডি রয়েছে। Avoid EBS: ভবিষ্যত পরিকল্পনা: Rust সঙ্গে WebAssembly UDFs ভবিষ্যতে, তারা যথেষ্ট বড় টুকরা লেখার এবং অপ্রয়োজনীয় ডেটা পড়ার মধ্যে মাঝারি জায়গা খুঁজতে চায়। তাদের চূড়ান্ত লক্ষ্য ScyllaDB এর উপর আরো কাজ অপসারণ করা। তাদের বিদ্যমান রাস্ট কোডের সাথে, ইউডিএফগুলি অন্তর্ভুক্ত করা ডেটা অ্যাপ্লিকেশনে ফেরত পাঠানোর প্রয়োজনকে সরিয়ে দেবে, সংশোধন এবং সম্ভাব্য উন্নতিগুলির জন্য নমনীয়তা প্রদান করবে। WebAssembly এর সাথে ব্যবহারকারী সংজ্ঞায়িত ফাংশন (UDFs) সান্ত্বিয়ান শেয়ার করে, "আমরা ইতিমধ্যে সবকিছু রাস্টে লিখেছি. যদি আমরা ইউডিএফ ব্যবহার শুরু করতে পারি তাহলে আমরা অ্যাপ্লিকেশনে কিছুই ফেরত পাঠাতে পারি না। সম্পূর্ণ প্রযুক্তি আলোচনা দেখুন আপনি আমাদের টেকনোলজি লাইব্রেরিতে ডেকের মাধ্যমে সম্পূর্ণ টেকনোলজি আলোচনা এবং স্কিম দেখতে পারেন। সিনথিয়া ডানলপ Cynthia ScyllaDB এর সামগ্রী কৌশল সিনিয়র ডিরেক্টর এবং 20+ বছর ধরে সফটওয়্যার ডেভেলপমেন্ট এবং গুণমান প্রকৌশল সম্পর্কে লিখেছেন।
