নিম্ন দীর্ঘস্থায়ী মেশিন লার্নিং ফিচার স্টোরের চাহিদা আগের চেয়ে বেশি, কিন্তু প্রকৃতপক্ষে একটি স্কেলে বাস্তবায়ন একটি চ্যালেঞ্জ বাকি. ShareChat প্রকৌশলী ইভান Burmistrov এবং Andrei Manakov P99 CONF 23 পর্যায়ে যেভাবে তারা ScyllaDB উপর ভিত্তি করে একটি নিম্ন দীর্ঘস্থায়ী এমএল ফিচার স্টোর তৈরি করেছেন তা শেয়ার করার জন্য স্পষ্ট হয়েছিল। এটি একটি "শিক্ষা" গল্প, অস্থির কর্মক্ষমতা অপ্টিমাইজেশনের মানের একটি দৃষ্টিভঙ্গি - কিছু গুরুত্বপূর্ণ ইঞ্জিনিয়ারিং takeaways সঙ্গে। মূল সিস্টেমের বাস্তবায়ন কোম্পানির স্কেলিংয়ের প্রয়োজনীয়তাগুলির কাছাকাছি ছিল। চূড়ান্ত লক্ষ্যটি প্রতি সেকেন্ডে 1 বিলিয়ন বৈশিষ্ট্যগুলি সমর্থন করা ছিল, কিন্তু সিস্টেমটি মাত্র 1 মিলিয়ন লোডের অধীনে ব্যর্থ হয়েছিল। পারফরম্যান্স অপ্টিমাইজেশান এবং নিম্ন দীর্ঘস্থায়ী প্রকৌশল দ্বারা উত্সাহিত? P99 24 CONF, একটি বিনামূল্যে উচ্চ প্রযুক্তিগত ভার্চুয়াল সম্মেলন "সব জিনিসগুলির পারফরম্যান্স" সম্পর্কে আপনার সহকর্মীদের সাথে যোগ দিন। মাইকেল স্টোনব্র্যাকার, Postgres সৃষ্টিকর্তা এবং MIT অধ্যাপক ব্রায়ান ক্যান্ট্রিল, অক্সাইড কম্পিউটারের যৌথ প্রতিষ্ঠাতা এবং সিটিও Avi Kivity, KVM সৃষ্টিকর্তা, ScyllaDB যৌথ প্রতিষ্ঠাতা এবং সিটিও Liz Rice, eBPF বিশেষজ্ঞদের সঙ্গে প্রধান ওপেন সোর্স অফিসার Isovalent এন্ডি প্যাভলো, CMU প্রফেসর Ashley Williams, Axo প্রতিষ্ঠাতা / সিইও, সাবেক Rust কোর টিম, Rust ফাউন্ডেশন প্রতিষ্ঠাতা Carl Lerche, টোকিও সৃষ্টিকর্তা, Rust সহযোগী এবং AWS এর ইঞ্জিনিয়ার এখন নিবন্ধন করুন - এটি বিনামূল্যে এখন নিবন্ধন করুন - এটি বিনামূল্যে এখন নিবন্ধন করুন - এটি বিনামূল্যে ShareChat থেকে ইভান দ্বারা আরেকটি চমৎকার কথোপকথনের পাশাপাশি, Disney / Hulu, Shopify, Lyft, Uber, Netflix, American Express, Datadog, Grafana, LinkedIn, Google, Oracle, Redis, AWS, ScyllaDB এবং আরো কর্মক্ষমতা অপ্টিমাইজেশন সম্পর্কে 60 টিরও বেশি প্রকৌশলী কথোপকথন আশা করুন। ShareChat: ভারতের নেতৃস্থানীয় সামাজিক মিডিয়া প্ল্যাটফর্ম চ্যালেঞ্জের পরিমাণ বুঝতে, ভারতের নেতৃস্থানীয় সামাজিক মিডিয়া প্ল্যাটফর্ম ShareChat সম্পর্কে কিছুটা জানতে গুরুত্বপূর্ণ. ShareChat অ্যাপ্লিকেশনে, ব্যবহারকারীরা ভিডিও, ইমেজ, গান এবং আরো সহ 15 টিরও বেশি ভাষায় সামগ্রী আবিষ্কার এবং ব্যবহার করতে পারে. ShareChat এছাড়াও একটি TikTok-এর মত একটি সংক্ষিপ্ত ভিডিও প্ল্যাটফর্ম (Moj) হোস্ট করে যা ব্যবহারকারীদের আধুনিক ট্যাগ এবং প্রতিযোগিতার মাধ্যমে সৃজনশীল হতে উৎসাহিত করে। দুটি অ্যাপ্লিকেশনের মধ্যে, তারা একটি দ্রুত বৃদ্ধিযুক্ত ব্যবহারকারীর ভিত্তিতে সেবা দেয় যা ইতিমধ্যে মাসে 325 মিলিয়ন সক্রিয় ব্যবহারকারী রয়েছে এবং তাদের আইটি ভিত্তিক সামগ্রী সুপারিশিং ইঞ্জিন ব্যবহারকারীদের রক্ষণাবেক্ষণ এবং আন্দোলনের জন্য অপরিহার্য। ShareChat এ মেশিন শিক্ষার বৈশিষ্ট্য স্টোর এই গল্পটি ছোট আকারের ভিডিও অ্যাপ্লিকেশনের জন্য ML বৈশিষ্ট্য স্টোরের পিছনে সিস্টেমের উপর দৃষ্টি আকর্ষণ করে। এটি প্রায় 20 মিলিয়ন দৈনিক সক্রিয় ব্যবহারকারীদের, 100 মিলিয়ন মাসিক সক্রিয় ব্যবহারকারীদের সম্পূর্ণরূপে ব্যক্তিগত ফিড সরবরাহ করে। ইভান বার্মিস্ট্রোভ, ShareChat এর প্রধান কর্মী সফটওয়্যার প্রকৌশলী, ব্যাখ্যা করেছেন: “আমরা বিভিন্ন ‘অন্তর্ভুক্তির’ জন্য বৈশিষ্ট্যগুলি গণনা করি. পোস্ট একটি বৈশিষ্ট্য, ব্যবহারকারী অন্য এবং তাই। গণনা দৃষ্টিকোণ থেকে, তারা বেশ অনুরূপ। যাইহোক, গুরুত্বপূর্ণ পার্থক্যটি প্রত্যেক ধরনের বৈশিষ্ট্যগুলির জন্য আমাদের সংগ্রহ করার প্রয়োজনীয় বৈশিষ্ট্যগুলির সংখ্যা। যখন একজন ব্যবহারকারী একটি ফিডের অনুরোধ করে, আমরা সেই একক ব্যবহারকারীর জন্য ব্যবহারকারীর বৈশিষ্ট্যগুলি সংগ্রহ করি। কী ভুল হয়েছে প্রথমে, মূল মনোযোগ ছিল একটি বাস্তব সময় ব্যবহারকারী বৈশিষ্ট্য স্টোর তৈরি করা, কারণ, সেই সময়ে, ব্যবহারকারী বৈশিষ্ট্যগুলি সবচেয়ে গুরুত্বপূর্ণ ছিল. টিমটি সেই লক্ষ্য নিয়ে বৈশিষ্ট্য স্টোর তৈরি করতে শুরু করে. কিন্তু তারপর অগ্রাধিকার পরিবর্তিত হয়েছিল এবং পোস্ট বৈশিষ্ট্যগুলিও অগ্রাধিকার হয়েছিল. এই পরিবর্তনটি ঘটেছিল কারণ টিমটি একটি সম্পূর্ণরূপে নতুন র্যাংকিং সিস্টেম তৈরি করতে শুরু করেছিল, তার পূর্বপুরুষের তুলনায় দুটি প্রধান পার্থক্য: বাস্তব সময় পোস্ট বৈশিষ্ট্য আরো গুরুত্বপূর্ণ ছিল র ্যাঙ্কিংয়ের জন্য পোস্টগুলির সংখ্যা শত শত থেকে হাজার পর্যন্ত বেড়েছে ইভান ব্যাখ্যা করে বলেন, “যখন আমরা এই নতুন সিস্টেমটি পরীক্ষা করার জন্য গিয়েছিলাম, তখন এটি দুর্ভাগ্যজনকভাবে ব্যর্থ হয়েছিল। অবশেষে, সমস্যাটি সিস্টেমের আর্কিটেকচারের পূর্বে সংগৃহীত ডেটা বুকেটগুলি কিভাবে ব্যবহৃত হয় তা থেকে উত্থাপিত হয়, যাকে টাইলস বলা হয়. উদাহরণস্বরূপ, তারা একটি নির্দিষ্ট মিনিট বা অন্য কোনও সময়ের মধ্যে একটি পোস্টের জন্য পছন্দগুলির সংখ্যা সংগ্রহ করতে পারে. এটি তাদের গত দুই ঘণ্টার মধ্যে একাধিক পোস্টের জন্য পছন্দগুলির সংখ্যা হিসাবে মেট্রিকগুলি গণনা করতে দেয়. এখানে সিস্টেমের আর্কিটেকচারের একটি উচ্চ স্তরের নজর আছে. কয়েকটি রিয়েল-টাইম থিম রয়েছে যেখানে কাঁচা ডেটা (ভালোবাসা, ক্লিক, ইত্যাদি) থাকে. একটি ফ্লিংক কাজগুলি টাইলগুলিতে সংগৃহীত করে এবং ScyllaDB-এ লিখে। প্রাথমিক ডাটাবেস পরিকল্পনা এবং টাইলিং কনফিগারেশন স্ক্যালারিযোগ্যতা সমস্যাগুলি সৃষ্টি করে। ]. টাইলগুলি একটি মিনিট, 30 মিনিট এবং এক দিনের সেগমেন্টগুলির জন্য গণনা করা হয়েছিল. একটি ঘন্টা, এক দিন, সাত দিন বা 30 দিনের জন্য চান, প্রতিটি বৈশিষ্ট্যতে গড় 70 টি টাইল খুঁজে পেতে প্রয়োজন। এই NoSQL ডেটা মডেলিং মাস্টারক্লাসে আরও জানুন আপনি যদি গণিতটি করেন তবে এটি কেন ব্যর্থ হয়েছিল তা স্পষ্ট হয়ে যায়. সিস্টেমটি প্রতি সেকেন্ডে প্রায় 22 বিলিয়ন লাইন পরিচালনা করতে হবে. তবে, ডাটাবেসের ক্ষমতা মাত্র 10 মিলিয়ন লাইন / সেকেন্ড ছিল। প্রাথমিক অপ্টিমাইজেশন সেই সময়ে, দলটি একটি অপ্টিমাইজেশন মিশনে গিয়েছিল। প্রাথমিক ডাটাবেস পরিকল্পনাটি সমস্ত বৈশিষ্ট্য লাইন একসঙ্গে সংরক্ষণ করার জন্য আপডেট করা হয়েছিল, একটি নির্দিষ্ট টাইমস্ট্যাম্পের জন্য প্রোটোকল বুফার হিসাবে সিরিয়াল করা হয়েছিল। কারণ আর্কিটেকচারটি ইতিমধ্যে অ্যাপাচ ফ্লিংক ব্যবহার করেছিল, নতুন টাইলিং পরিকল্পনাটিতে স্থানান্তর করা বেশ সহজ ছিল, ফ্লিংকের ডেটা পাইপলাইন নির্মাণের উন্নত ক্ষমতাগুলির কারণে। টিমটি প্লেটিং কনফিগারেশনকে আরও উন্নত করে, পাঁচ মিনিট, তিন ঘণ্টা এবং পাঁচ দিনের জন্য অতিরিক্ত প্লেটগুলি এক মিনিট, ৩০ মিনিট এবং এক দিনের প্লেটগুলিতে যোগ করে। ডাটাবেস পাশে আরও লাইন / সেকেন্ড পরিচালনা করার জন্য, তারা ScyllaDB সংকোচন কৌশলকে ক্রমবর্ধমান থেকে স্তম্ভিত করে। ]. সেই বিকল্পটি তাদের প্রশ্নের প্যাটার্নগুলি আরও ভালভাবে উপযুক্ত করে, প্রাসঙ্গিক লাইনগুলি একসঙ্গে রাখে এবং পড়া I/O কমিয়ে দেয়. ফলাফল: ScyllaDB এর ক্ষমতা কার্যকরভাবে দ্বিগুণ হয়েছে। কম্প্যাকশন কৌশল সম্পর্কে আরও জানুন বাকি লোডের জন্য সবচেয়ে সহজ উপায় ছিল ScyllaDB 4x স্ক্যালিং করা। তবে, আরো / বড় ক্লাস্টারগুলি খরচ বৃদ্ধি করবে এবং এটি তাদের বাজেটের মধ্যে ছিল না। উন্নত ক্যাশ অবস্থান ScyllaDB উপর লোড হ্রাস করার একটি সম্ভাব্য উপায় ছিল স্থানীয় ক্যাশ হিট হার উন্নত করা, তাই দলটি কীভাবে এটি অর্জন করা যেতে পারে তা গবেষণা করার সিদ্ধান্ত নিয়েছে। স্পষ্ট সিদ্ধান্তটি ছিল একটি সামঞ্জস্যপূর্ণ হ্যাশিং পদ্ধতি ব্যবহার করা, ক্লায়েন্টের কাছ থেকে একটি নির্দিষ্ট রিপ্লেকে একটি অনুরোধ পাঠানোর একটি পরিচিত কৌশল। এই সহজ কনফিগারেশন কাজ করে না. বিশেষ করে: ক্লায়েন্ট সাবসেটটি একটি বিশাল কী remapping এর ফলে পরিচালিত হয়েছিল – সবচেয়ে খারাপ ক্ষেত্রে 100% পর্যন্ত. যেহেতু নোট কীগুলি একটি হ্যাশিং রিংয়ে পরিবর্তন করা যেতে পারে, এটি অটোস্ক্যালিংয়ের সাথে বাস্তব জীবনের পরিস্থিতিগুলি ব্যবহার করা অসম্ভব ছিল। একটি অনুরোধের জন্য একটি হ্যাশ মান সরবরাহ করা কঠিন ছিল কারণ Ingress সবচেয়ে স্পষ্ট সমাধান সমর্থন করে না: একটি gRPC হেডার। দীর্ঘস্থায়ীতা গুরুতর হ্রাস পেয়েছে, এবং দীর্ঘস্থায়ী দীর্ঘস্থায়ীতার কারণ কী ছিল তা স্পষ্ট ছিল না। পডসের একটি সাবসেটকে সমর্থন করার জন্য, দল তাদের পদ্ধতি পরিবর্তন করেছিল। তারা একটি দুটি ধাপের হ্যাশ ফাংশন তৈরি করেছিলেন: প্রথমে একটি সম্পত্তির হ্যাশিং, তারপর একটি র্যান্ডম প্রিফিক্স যোগ করে। যা পডসের ইচ্ছাকৃত সংখ্যা জুড়ে সম্পত্তিকে বিতরণ করেছিল। Ingress একটি পরিবর্তক হিসাবে gRPC হেডার ব্যবহার সমর্থন করে না, কিন্তু দল একটি সমাধান খুঁজে পেয়েছিল: পথ পুনরায় লিখুন এবং পথ নিজেই প্রয়োজনীয় হ্যাশ কী সরবরাহ করে। দুর্ভাগ্যবশত, দীর্ঘস্থায়ীতা হ্রাসের কারণগুলি নির্ধারণ করতে অনেক সময় লাগবে এবং পর্যবেক্ষণযোগ্যতা উন্নতি করতে হবে। তারিখ পূরণের জন্য, টিম ফিচারটি 27 টি ভিন্ন পরিষেবাতে বিভক্ত করে এবং ক্লায়েন্টের উপর তাদের মধ্যে সমস্ত সত্তাগুলি ম্যানুয়ালভাবে বিভক্ত করে। এটি সবচেয়ে আকর্ষণীয় পদ্ধতি ছিল না, তবে, এটি সহজ এবং বাস্তব ছিল - এবং এটি মহান ফলাফল অর্জন করেছিল। যাইহোক, এই "দীর্ঘ স্কুল" বিতরণ-ভিন্নকরণ পদ্ধতিটি এখনও আদর্শ নকশা ছিল না। 27 বিতরণগুলি বজায় রাখা ক্লান্ত এবং অকার্যকর ছিল। পাশাপাশি, ক্যাশ হিট হার স্থিতিশীল ছিল না, এবং স্ক্যালিং প্রতিটি বিতরণে একটি উচ্চ ন্যূনতম পড সংখ্যা বজায় রাখার জন্য সীমাবদ্ধ ছিল। অপ্টিমাইজেশনের পরবর্তী পর্যায়ে: সামঞ্জস্যপূর্ণ হ্যাশিং, বৈশিষ্ট্য পরিষেবা আরেকটি অপ্টিমাইজেশান রুটের জন্য প্রস্তুত, দলটি বৈশিষ্ট্য পরিষেবার সাথে ডেলিভার করা একটি সিডক্যার, এনওয়াই প্রক্সি নামে একটি সিডকিং পদ্ধতি ব্যবহার করে পুনরায় পরীক্ষা করেছিলেন. এনওয়াই প্রক্সি উন্নত পর্যবেক্ষণযোগ্যতা প্রদান করেছিল যা দীর্ঘমেয়াদি শিকার সমস্যার সনাক্ত করতে সহায়তা করেছিল। তারপর দলটি বৈশিষ্ট্য পরিষেবাটি অপ্টিমাইজ করেছে. তারা: ক্যাশিং লাইব্রেরি (VictoriaMetrics থেকে ফাস্ট ক্যাশ) এবং ব্যাচ লিখা এবং উন্নত বহিষ্কারটি বাস্তবায়ন করে যাতে মিউটেক্স কনটেনশন 100x কমে যায়। ফোর্স করা gprc-go এবং উচ্চ সমান্তরালতা সময় বিতর্ক এড়ানোর জন্য বিভিন্ন সংযোগগুলিতে বাফার পুল বাস্তবায়ন করা হয়। Object pooling এবং Tuneed Garbage Collector (GC) প্যারামিটারগুলি ব্যবহার করা হয়েছে অ্যাডলোজিং হার এবং GC চক্রগুলি হ্রাস করার জন্য। তাদের প্রোডাক্ট প্রোডাক্টে 15 শতাংশ ট্র্যাফিক পরিচালনা করার সাথে সাথে, ফলাফলগুলি আশাবাদী ছিল: 98% ক্যাশ হিট হার, যা ScyllaDB উপর লোড হ্রাস করে 7.4 মিলিয়ন লাইন / সেকেন্ড। শিক্ষিত শিক্ষা টাইমলাইন দৃষ্টিকোণ থেকে এই যাত্রাটি কীভাবে দেখতে লাগলো: অবশেষে, অ্যান্ড্রিয়েই এই প্রকল্প থেকে টিমের শীর্ষ শিক্ষাগুলি সংক্ষিপ্ত করেছে (এখন পর্যন্ত): যদিও ShareChat টিম তাদের সিস্টেম নকশা drastically পরিবর্তন করেছে, ScyllaDB, Apache Flink এবং VictoriaMetrics ভাল কাজ চালিয়েছে। প্রতিটি অপ্টিমাইজেশন পূর্বের চেয়ে কঠিন - এবং কম প্রভাব রয়েছে। সহজ এবং বাস্তব সমাধান (যেমন বৈশিষ্ট্য দোকানকে ২৭টি বিতরণে বিভক্ত করা) সত্যিই কাজ করে। সেরা পারফরম্যান্স প্রদানকারী সমাধান সবসময় ব্যবহারকারী বন্ধুত্বপূর্ণ নয়. উদাহরণস্বরূপ, তাদের পুনর্নির্দেশিত ডাটাবেস পরিকল্পনা ভাল পারফরম্যান্স প্রদান করে, কিন্তু এটি রক্ষণাবেক্ষণ এবং বোঝা কঠিন। কখনও কখনও আপনাকে একটি ডিফল্ট লাইব্রেরি ফর্ক করতে হবে এবং সেরা পারফরম্যান্স পেতে আপনার নির্দিষ্ট সিস্টেমের জন্য এটি সংশোধন করতে হবে। তাদের সম্পূর্ণ P99 CONF আলোচনা দেখুন! তাদের সম্পূর্ণ P99 CONF আলোচনা দেখুন! তাদের সম্পূর্ণ P99 CONF আলোচনা দেখুন! সিনথিয়া ডানলপ Cynthia ScyllaDB এর সামগ্রী কৌশল সিনিয়র ডিরেক্টর এবং 20+ বছর ধরে সফটওয়্যার ডেভেলপমেন্ট এবং গুণমান প্রকৌশল সম্পর্কে লিখেছেন।
