স্ক্র্যাচ থেকে VKontakte বার্তা ডাটাবেস পুনরায় লিখুন এবং বেঁচে থাকুন

আমাদের ব্যবহারকারীরা ক্লান্তি না জেনে একে অপরকে বার্তা লেখেন।

এটা বেশ অনেক. আপনি যদি সমস্ত ব্যবহারকারীর সমস্ত বার্তা পড়তে সেট করেন তবে এটি 150 হাজার বছরেরও বেশি সময় লাগবে। শর্ত থাকে যে আপনি একজন মোটামুটি উন্নত পাঠক এবং প্রতিটি বার্তায় এক সেকেন্ডের বেশি ব্যয় করবেন না।

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

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

রোগীর স্বাস্থ্যাদির বিবরণ

প্রথম বাস্তবায়নে, VKontakte বার্তাগুলি PHP ব্যাকএন্ড এবং MySQL এর সংমিশ্রণে কাজ করেছিল। এটি একটি ছোট ছাত্র ওয়েবসাইটের জন্য একটি সম্পূর্ণ স্বাভাবিক সমাধান। যাইহোক, এই সাইটটি অনিয়ন্ত্রিতভাবে বৃদ্ধি পেয়েছে এবং নিজের জন্য ডেটা স্ট্রাকচারের অপ্টিমাইজেশন দাবি করতে শুরু করেছে।

2009 এর শেষে, প্রথম পাঠ্য-ইঞ্জিন সংগ্রহস্থলটি লেখা হয়েছিল এবং 2010 সালে বার্তাগুলি এতে স্থানান্তরিত হয়েছিল।

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

দুই ব্যবহারকারীর মধ্যে চিঠিপত্রের জন্য এটি যথেষ্ট ছিল। পরে কি হয়েছে অনুমান?

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

"PHP, চ্যাটে একটি বার্তা পাঠাই," ব্যবহারকারী বলেছেন।
"চলো, {username}," পিএইচপি বলে৷

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

2015 এর শেষে, আমরা সম্প্রদায়ের বার্তা চালু করেছি এবং 2016 এর শুরুতে, আমরা তাদের জন্য একটি API চালু করেছি। সম্প্রদায়গুলিতে বড় চ্যাটবটগুলির আবির্ভাবের সাথে, এমনকি লোড বিতরণ সম্পর্কে ভুলে যাওয়া সম্ভব হয়েছিল।

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

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

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

নতুন ধারণা

নতুন পদ্ধতির কেন্দ্রীয় সারমর্ম হল চ্যাট। একটি চ্যাটে এর সাথে সম্পর্কিত বার্তাগুলির একটি তালিকা রয়েছে৷ ব্যবহারকারীর কাছে চ্যাটের একটি তালিকা রয়েছে।

প্রয়োজনীয় ন্যূনতম দুটি নতুন ডাটাবেস:

• চ্যাট ইঞ্জিন এটি চ্যাট ভেক্টরের একটি ভান্ডার। প্রতিটি চ্যাটে এর সাথে সম্পর্কিত বার্তাগুলির একটি ভেক্টর থাকে। প্রতিটি বার্তার একটি পাঠ্য এবং চ্যাটের ভিতরে একটি অনন্য বার্তা সনাক্তকারী থাকে - chat_local_id।
• ব্যবহারকারী ইঞ্জিন এটি ব্যবহারকারীদের ভেক্টরের একটি স্টোরেজ - ব্যবহারকারীদের লিঙ্ক। প্রতিটি ব্যবহারকারীর পিয়ার_আইডি (কথোপকথনকারী - অন্যান্য ব্যবহারকারী, বহু-চ্যাট বা সম্প্রদায়) এবং বার্তাগুলির একটি ভেক্টর রয়েছে। প্রতিটি peer_id এর সাথে সম্পর্কিত বার্তাগুলির একটি ভেক্টর থাকে। প্রতিটি বার্তার একটি চ্যাট_লোকাল_আইডি এবং সেই ব্যবহারকারীর জন্য একটি অনন্য বার্তা আইডি রয়েছে - user_local_id।

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

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

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

নতুন স্কিমে একটি বার্তা পাঠানো এই মত দেখায়:

1. পিএইচপি ব্যাকএন্ড একটি বার্তা পাঠানোর অনুরোধ সহ ব্যবহারকারী-ইঞ্জিনের সাথে যোগাযোগ করে।
2. ব্যবহারকারী-ইঞ্জিন পছন্দসই চ্যাট-ইঞ্জিন উদাহরণের অনুরোধকে প্রক্সি করে, যা ব্যবহারকারী-ইঞ্জিন চ্যাট_লোকাল_আইডি-তে ফিরে আসে - এই চ্যাটের মধ্যে একটি নতুন বার্তার একটি অনন্য শনাক্তকারী। চ্যাট_ইঞ্জিন তারপর চ্যাটে সমস্ত প্রাপকদের কাছে বার্তাটি সম্প্রচার করে।
3. ব্যবহারকারী-ইঞ্জিন চ্যাট-ইঞ্জিন থেকে chat_local_id গ্রহণ করে এবং PHP-তে user_local_id ফেরত দেয় - এই ব্যবহারকারীর জন্য একটি অনন্য বার্তা সনাক্তকারী। এই শনাক্তকারীটি ব্যবহার করা হয়, উদাহরণস্বরূপ, API এর মাধ্যমে বার্তাগুলির সাথে কাজ করার জন্য।

কিন্তু প্রকৃতপক্ষে বার্তা পাঠানোর পাশাপাশি, আপনাকে আরও কয়েকটি গুরুত্বপূর্ণ বিষয় বাস্তবায়ন করতে হবে:

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

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

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

যেহেতু চ্যাট-ইঞ্জিনে র্যান্ডম-অ্যাক্সেস ডিস্কের অনুরোধগুলি সংরক্ষণ করার জন্য চ্যাটের তুলনায় অনেক কম ব্যবহারকারী রয়েছে, আমরা ব্যবহারকারী-ইঞ্জিনে বার্তাগুলি ক্যাশে করি।

বার্তা অনুসন্ধান ব্যবহারকারী-ইঞ্জিন থেকে এই ব্যবহারকারীর চ্যাট ধারণ করে এমন সমস্ত চ্যাট-ইঞ্জিন উদাহরণে একটি তির্যক ক্যোয়ারী হিসাবে প্রয়োগ করা হয়। ফলাফলগুলি ব্যবহারকারী-ইঞ্জিনেই একত্রিত হয়।

ঠিক আছে, সমস্ত বিবরণ বিবেচনায় নেওয়া হয়েছে, যা অবশিষ্ট থাকে তা হল একটি নতুন স্কিমে স্যুইচ করা - এবং বিশেষত ব্যবহারকারীরা এটি লক্ষ্য না করে।

তথ্য স্থানান্তর

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

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

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

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

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

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

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

আমরা আমদানি করা বার্তা সংরক্ষণ করার জন্য একটি বিশেষ ডেটা কাঠামো ব্যবহার করি।

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

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

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

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

Результаты

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

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

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

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

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

উত্স: www.habr.com