নিউএসকিউএল = NoSQL+ACID

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

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

এটি কিভাবে কাজ করে এবং কি ঘটেছে - কাটা অধীনে পড়ুন।

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

আমরা 2010 সাল থেকে Cassandra ব্যবহার করছি, সংস্করণ 0.6 দিয়ে শুরু করে। আজ, কয়েক ডজন ক্লাস্টার চালু আছে। দ্রুততম ক্লাস্টার প্রতি সেকেন্ডে 4 মিলিয়নেরও বেশি অপারেশন প্রক্রিয়া করে, যেখানে সবচেয়ে বড়টি 260 টিবি সঞ্চয় করে।

যাইহোক, এই সব সাধারণ NoSQL ক্লাস্টারগুলি সঞ্চয় করার জন্য ব্যবহৃত হয় দুর্বলভাবে সমন্বিত তথ্য আমরা মূল সামঞ্জস্যপূর্ণ স্টোরেজ, মাইক্রোসফ্ট এসকিউএল সার্ভার প্রতিস্থাপন করতে চেয়েছিলাম, যা ওডনোক্লাসনিকি প্রতিষ্ঠার পর থেকে ব্যবহার করা হয়েছে। স্টোরেজটিতে 300 টিরও বেশি SQL সার্ভার স্ট্যান্ডার্ড সংস্করণ মেশিন রয়েছে, যেটিতে 50 TB ডেটা রয়েছে - ব্যবসায়িক সত্তা। এই ডেটা ACID লেনদেনের অংশ হিসাবে সংশোধন করা হয়েছে এবং প্রয়োজন উচ্চ সামঞ্জস্য.

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

শার্ডিংয়ের জন্য এবং এসকিউএলকে গতি বাড়ানোর জন্য ধন্যবাদ:

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

এই পদক্ষেপগুলি আমাদেরকে এসকিউএল সার্ভারের প্রায় সর্বাধিক কার্যকারিতা চেপে দেওয়ার অনুমতি দেয়। তবে সমস্যা আরও বেড়েছে। আসুন তাদের এক নজরে দেখে নেওয়া যাক।

এসকিউএল এর সাথে সমস্যা

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

কিন্তু মূল সমস্যা হল

দোষ সহনশীলতা

ক্লাসিক SQL সার্ভারের ত্রুটি সহনশীলতা দুর্বল। ধরা যাক আপনার শুধুমাত্র একটি ডাটাবেস সার্ভার আছে এবং এটি প্রতি তিন বছরে ব্যর্থ হয়। এই সময়ে, সাইটটি 20 মিনিটের জন্য ডাউন, এটি গ্রহণযোগ্য। আপনার যদি 64টি সার্ভার থাকে, তাহলে সাইটটি প্রতি তিন সপ্তাহে একবার ডাউন হয়। এবং যদি আপনার 200 সার্ভার থাকে, তাহলে সাইটটি প্রতি সপ্তাহে কাজ করে না। এটি সমস্যা.

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

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

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

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

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

সহজ লেনদেন

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

1. আমরা কী দ্বারা অ্যালবাম ব্লক.
2. ছবির টেবিলে একটি এন্ট্রি তৈরি করুন।
3. যদি ফটোটির একটি সর্বজনীন স্থিতি থাকে, তাহলে আমরা অ্যালবামে সর্বজনীন ফটোগুলির কাউন্টারটি বন্ধ করে দিই, রেকর্ডটি আপডেট করি এবং লেনদেন করি৷

অথবা সিউডোকোডে:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

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

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

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

অন্যান্য সমান গুরুত্বপূর্ণ প্রয়োজনীয়তা ছিল:

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

সিদ্ধান্ত সিদ্ধান্ত

সম্ভাব্য সমাধান বিশ্লেষণ করে, আমরা দুটি সম্ভাব্য স্থাপত্য পছন্দ নিয়ে এসেছি:

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

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

ক্যাসান্দ্রা এবং সিকিউএল

সুতরাং, ক্যাসান্দ্রা সম্পর্কে আকর্ষণীয় কী, এতে কী বৈশিষ্ট্য রয়েছে?

প্রথমত, এখানে আপনি বিভিন্ন ধরনের ডেটার সমর্থন সহ টেবিল তৈরি করতে পারেন, আপনি প্রাথমিক কী দ্বারা SELECT বা আপডেট করতে পারেন।

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

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

পদ্ধতি যখন আমরা তিনটি নোড অ্যাক্সেস করি এবং দুটি থেকে একটি প্রতিক্রিয়া পাই তাকে বলা হয় জল্পনা: অতিরিক্ত প্রতিলিপির জন্য একটি অনুরোধ পাঠানো হয় "পড়ে যাওয়ার" আগে।

ক্যাসান্দ্রার আরেকটি সুবিধা হল ব্যাচলগ, এমন একটি প্রক্রিয়া যা নিশ্চিত করে যে আপনি যে পরিবর্তনগুলি করেছেন তা হয় সম্পূর্ণরূপে প্রয়োগ করা হয়েছে বা সম্পূর্ণরূপে প্যাকেজে প্রয়োগ করা হয়নি। এটি আমাদের ACID-তে A-কে সমাধান করতে দেয় - বাক্সের বাইরে পরমাণু।

ক্যাসান্দ্রায় লেনদেনের সবচেয়ে কাছের জিনিসটি হল তথাকথিত "হালকা লেনদেন" কিন্তু তারা "বাস্তব" ACID লেনদেন থেকে অনেক দূরে: আসলে, এটি করার একটি সুযোগ সি এ এস শুধুমাত্র একটি রেকর্ডের ডেটাতে, প্যাক্সোস হেভিওয়েট প্রোটোকল ঐক্যমত ব্যবহার করে। তাই এ ধরনের লেনদেনের গতি কম।

আমরা ক্যাসান্দ্রায় যা মিস করেছি

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

C*এক

তাই নতুন DBMS এর জন্ম হয়েছিল C*এক, তিন ধরনের সার্ভার নোড নিয়ে গঠিত:

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

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

ক্লায়েন্ট

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

C*এক লেনদেন সমন্বয়কারী

সমন্বয়কারী হল যা আমরা শুরু থেকে C*One এর জন্য প্রয়োগ করেছি। এটি লেনদেন, লক এবং লেনদেন প্রয়োগ করা হয় এমন ক্রম পরিচালনার জন্য দায়ী।

প্রতিটি সার্ভিসড লেনদেনের জন্য, সমন্বয়কারী একটি টাইমস্ট্যাম্প তৈরি করে: প্রতিটি পরবর্তী লেনদেন আগের লেনদেনের চেয়ে বড়। যেহেতু ক্যাসান্দ্রার দ্বন্দ্ব সমাধান ব্যবস্থাটি টাইমস্ট্যাম্পের উপর ভিত্তি করে (দুটি বিরোধপূর্ণ রেকর্ডের, সর্বশেষ টাইমস্ট্যাম্পটি প্রাসঙ্গিক হিসাবে বিবেচিত), তাই দ্বন্দ্ব সর্বদা পরবর্তী লেনদেনের পক্ষে সমাধান করা হবে। এভাবে আমরা বাস্তবায়ন করেছি ল্যামপোর্ট ঘড়ি বিতরণ ব্যবস্থায় দ্বন্দ্ব সমাধানের একটি সস্তা উপায়।

তালা

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

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

যেহেতু আমাদের ক্ষেত্রে ডেটা ইতিমধ্যেই এসকিউএল-এ স্থানীয় লেনদেনের গোষ্ঠীগুলির মধ্যে বিতরণ করা হয়েছে, তাই সমন্বয়কারীদের স্থানীয় লেনদেনের গ্রুপগুলি বরাদ্দ করার সিদ্ধান্ত নেওয়া হয়েছিল: একজন সমন্বয়কারী 0 থেকে 9 পর্যন্ত একটি টোকেন সহ সমস্ত লেনদেন সম্পাদন করে, দ্বিতীয়টি - থেকে একটি টোকেন সহ 10 থেকে 19, এবং তাই। ফলস্বরূপ, সমন্বয়কারীর প্রতিটি উদাহরণ লেনদেন গ্রুপের মাস্টার হয়ে ওঠে।

তারপর লকগুলি সমন্বয়কারীর স্মৃতিতে একটি সাধারণ হ্যাশম্যাপ হিসাবে প্রয়োগ করা যেতে পারে।

সমন্বয়কারীদের অস্বীকৃতি

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

প্রতিটি ডেটা সেন্টার কমপক্ষে দুটি সমন্বয়কারী নোড হোস্ট করে। পর্যায়ক্রমে, প্রতিটি সমন্বয়কারী অন্য সমন্বয়কারীকে একটি হার্টবিট বার্তা পাঠায় এবং তাদের কার্যকারিতা সম্পর্কে অবহিত করে, সেইসাথে ক্লাস্টারে কোন সমন্বয়কারীর কাছ থেকে শেষবার হৃদস্পন্দনের বার্তা পেয়েছিল।

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

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

কিন্তু কোন নোড কাজ করা বন্ধ করে দিয়েছে তা দ্রুত বোঝার জন্য যথেষ্ট নয়। এটা সম্পর্কে কিছু করা প্রয়োজন.

রিজার্ভেশন

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

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

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

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

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

কিভাবে একটি লেনদেন কাজ করে

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

যখন একটি ক্লায়েন্ট একটি লেনদেনে ডেটা পরিবর্তন করতে চায়, তখন এটি সমন্বয়কারীকে সত্তাটি সংশোধন করার জন্য একটি অনুরোধ পাঠায় এবং সমন্বয়কারী মেমরিতে লেনদেনের স্টেট টেবিলে নতুন ডেটা রাখে। এটি রেকর্ডিং সম্পূর্ণ করে - স্টোরেজ লেখা হয় না।

যখন একটি ক্লায়েন্ট একটি সক্রিয় লেনদেনের অংশ হিসাবে তার নিজস্ব পরিবর্তিত ডেটা অনুরোধ করে, তখন সমন্বয়কারী এইভাবে কাজ করে:

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

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

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

এবং রোলব্যাকের জন্য, সমন্বয়কারীকে শুধুমাত্র লেনদেনের অবস্থা দ্বারা দখলকৃত মেমরি মুক্ত করতে হবে।

উপরে বর্ণিত উন্নতির ফলস্বরূপ, আমরা ACID এর নীতিগুলি বাস্তবায়ন করেছি:

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

সূচী দ্বারা পড়া

আসুন একটি সাধারণ টেবিল নেওয়া যাক:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

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

SELECT *
WHERE owner=?
AND modified>?

এই ধরনের একটি প্রশ্ন দ্রুত প্রক্রিয়া করার জন্য, একটি ক্লাসিক SQL DBMS-এ, আপনাকে কলামগুলিতে একটি সূচক তৈরি করতে হবে (মালিক, পরিবর্তিত)। আমরা এটি খুব সহজভাবে করতে পারি, যেহেতু আমাদের এখন এসিআইডি গ্যারান্টি রয়েছে!

সি*ওয়ানে সূচক

ফটো সহ একটি প্রাথমিক টেবিল রয়েছে যেখানে রেকর্ড আইডি একটি প্রাথমিক কী।

একটি সূচকের জন্য, C*One একটি নতুন টেবিল তৈরি করে যা মূল টেবিলের একটি অনুলিপি। কীটি ইনডেক্স এক্সপ্রেশনের মতোই, তবে এটি উত্স টেবিল থেকে রেকর্ডের প্রাথমিক কীও অন্তর্ভুক্ত করে:

এখন "গত XNUMX ঘন্টার মালিক" এর জন্য ক্যোয়ারীটি অন্য টেবিল থেকে নির্বাচন হিসাবে পুনরায় লেখা যেতে পারে:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

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

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

কি হলো

আমরা তিন বছর আগে সি*ওয়ান তৈরি করেছি এবং এটিকে বাণিজ্যিকভাবে চালু করেছি।

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

যখন আমরা প্রতিলিপি ফ্যাক্টর = 1 (কিন্তু RAID 10-এ) সহ এসকিউএল ব্যবহার করি, তখন ফটো মেটা-তথ্যটি 32টি মাইক্রোসফ্ট এসকিউএল সার্ভার মেশিনের (প্লাস 11টি অতিরিক্ত) একটি অত্যন্ত উপলব্ধ ক্লাস্টারে সংরক্ষণ করা হয়েছিল। এছাড়াও, ব্যাকআপ সংরক্ষণের জন্য 10টি সার্ভার বরাদ্দ করা হয়েছিল। মোট 50টি দামি গাড়ি। একই সময়ে, সিস্টেমটি মার্জিন ছাড়াই রেট করা লোডে কাজ করেছিল।

একটি নতুন সিস্টেমে স্থানান্তরিত করার পরে, আমরা প্রতিলিপি ফ্যাক্টর = 3 পেয়েছি - প্রতিটি ডেটা সেন্টারে একটি অনুলিপি। সিস্টেমটিতে মোট 63টি সার্ভারের জন্য 6টি ক্যাসান্ড্রা স্টোরেজ নোড এবং 69টি সমন্বয়কারী মেশিন রয়েছে। কিন্তু এই মেশিনগুলি অনেক সস্তা, একটি SQL সিস্টেমের মোট খরচের প্রায় 30%। এই ক্ষেত্রে, লোড 30% স্তরে রাখা হয়।

C*One প্রবর্তনের সাথে সাথে, লেটেন্সিও কমে গেছে: SQL-এ, একটি লেখার ক্রিয়াকলাপ প্রায় 4,5 ms সময় নেয়। সি * ওয়ানে - প্রায় 1,6 এমএস। একটি লেনদেনের সময়কাল গড়ে 40 ms এর কম, প্রতিশ্রুতি 2 ms এ সম্পন্ন হয়, পড়া এবং লেখার সময়কাল গড়ে 2 ms হয়। 99 তম পার্সেন্টাইল হল মাত্র 3-3,1 ms, টাইমআউটের সংখ্যা 100 গুণ কমে গেছে - সবই অনুমানের ব্যাপক ব্যবহারের কারণে।

আজ অবধি, বেশিরভাগ SQL সার্ভার নোড বাতিল করা হয়েছে, নতুন পণ্য শুধুমাত্র C * One ব্যবহার করে তৈরি করা হয়েছে। আমরা আমাদের ক্লাউডে কাজ করার জন্য সি*ওয়ানকে অভিযোজিত করেছি এক-মেঘ, যা নতুন ক্লাস্টার স্থাপনকে ত্বরান্বিত করা, কনফিগারেশনকে সরল করা এবং স্বয়ংক্রিয় অপারেশনকে সম্ভব করেছে। সোর্স কোড ছাড়া, এটি অনেক বেশি কঠিন এবং হ্যাকনিড হবে।

এখন আমরা আমাদের অন্যান্য স্টোরেজগুলিকে ক্লাউডে স্থানান্তর করার জন্য কাজ করছি - তবে এটি সম্পূর্ণ ভিন্ন গল্প।

উত্স: www.habr.com