ভাগ করা: বিপরীত দিক

2.1 কিভাবে N বার ধারালো এবং মন্থর করা যায়?

আপনি এইভাবে ঠিক N বার ধারালো এবং ধীর করতে পারেন:

• docs00...docs15 অনুরোধ ক্রমানুসারে পাঠান , সমান্তরালে নয়।
• সহজ প্রশ্নে, কী দ্বারা নয় , যেখানে কিছু=234 দ্বারা একটি নির্বাচন করুন।

এই ক্ষেত্রে, ক্রমিক অংশ (ক্রমিক) 1% এবং 5% নয়, আধুনিক ডাটাবেসে প্রায় 20% নেয়। আপনি যদি একটি অত্যন্ত দক্ষ বাইনারি প্রোটোকল ব্যবহার করে ডাটাবেস অ্যাক্সেস করেন বা একটি পাইথন স্ক্রিপ্টে একটি ডায়নামিক লাইব্রেরি হিসাবে লিঙ্ক করেন তবে আপনি সিরিয়ালাইজড অংশের 50% পেতে পারেন।

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

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

হঠাৎ, শার্ডিং করার সময় প্রোগ্রামিং ভাষার পছন্দ গুরুত্বপূর্ণ।

প্রোগ্রামিং ভাষার পছন্দ সম্পর্কে মনে রাখবেন, কারণ আপনি যদি ডেটাবেস (বা সার্ভার সার্ভারে) ক্রমানুসারে প্রশ্ন পাঠান, তাহলে ত্বরণ কোথা থেকে আসে? বরং মন্থরতা থাকবে।

2.2 আধা-স্বয়ংক্রিয় সম্পর্কে

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

স্বতন্ত্র ডিবিএ-এর মুখে ভুগছেন মানবতাকে বছরের পর বছর ধরে যন্ত্রণা দেওয়া হয়েছে এবং কিছু না থাকার উপর ভিত্তি করে বেশ কয়েকটি খারাপ শার্ডিং সমাধান লিখেছেন। এর পরে, প্রক্সিএসকিউএল (মারিয়াডিবি/স্পাইডার, PG/pg_shard/Citus, ...) নামে আরও একটি বা কম শালীন শার্ডিং সমাধান লেখা হয়। এটি এই খুব ব্লচের একটি সুপরিচিত উদাহরণ।

সামগ্রিকভাবে প্রক্সিএসকিউএল অবশ্যই ওপেন সোর্স, রাউটিং এবং আরও অনেক কিছুর জন্য একটি পূর্ণাঙ্গ এন্টারপ্রাইজ-শ্রেণির সমাধান। কিন্তু সমাধান করা কাজগুলির মধ্যে একটি হল একটি ডাটাবেসের জন্য শার্ডিং, যা নিজে থেকে মানুষের উপায়ে শার্ড করতে পারে না। আপনি দেখতে পাচ্ছেন, কোনও "শার্ডস = 16" সুইচ নেই, আপনাকে হয় অ্যাপ্লিকেশনটিতে প্রতিটি অনুরোধ পুনরায় লিখতে হবে এবং সেগুলি অনেক জায়গায় রয়েছে, বা অ্যাপ্লিকেশন এবং ডাটাবেসের মধ্যে কিছু মধ্যবর্তী স্তর রাখুন যা দেখায়: "হুম ... নথি থেকে * নির্বাচন করুন? হ্যাঁ, এটি অবশ্যই 16 ছোট SELECT * FROM server1.document1, SELECT * FROM server2.document2 - এই ধরনের লগইন/পাসওয়ার্ড সহ এই সার্ভারে, এটির সাথে আরেকটিতে বিভক্ত করতে হবে। যদি কেউ উত্তর না দেয়, তাহলে ... ", ইত্যাদি। ঠিক এই মধ্যবর্তী blotches দ্বারা করা যেতে পারে. এগুলি সমস্ত ডাটাবেসের তুলনায় সামান্য কম। PostgreSQL এর জন্য, যতদূর আমি বুঝি,

প্রতিটি নির্দিষ্ট প্যাচ কনফিগার করা একটি পৃথক দৈত্য বিষয় যা একটি প্রতিবেদনে মাপসই হবে না, তাই আমরা শুধুমাত্র মৌলিক ধারণাগুলি নিয়ে আলোচনা করব। গুঞ্জন তত্ত্ব সম্পর্কে একটু কথা বলা যাক।

2.3 পরম নিখুঁত অটোমেশন?

এই অক্ষর F() এর শার্ডিংয়ের ক্ষেত্রে উচ্চ হওয়ার পুরো তত্ত্বটি , মূল নীতিটি মোটামুটিভাবে সবসময় একই থাকে: shard_id = F(অবজেক্ট)।

Sharding - এটা সব সম্পর্কে কি? আমাদের 2 বিলিয়ন রেকর্ড (বা 64) আছে। আমরা তাদের কয়েকটি টুকরো টুকরো করতে চাই। একটি অপ্রত্যাশিত প্রশ্ন জাগে - কিভাবে? আমার কাছে উপলব্ধ 16টি সার্ভারে আমার 2 বিলিয়ন রেকর্ড (বা 64) ছত্রভঙ্গ করা উচিত কী নীতি অনুসারে?

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

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

shard_func = F1(object); 
shard_id = F2(shard_func, ...); 
shard_id = F2(F1(object), current_num_shards, ...). 

কিন্তু আরও আমরা স্বতন্ত্র ফাংশনগুলির এই বন্যগুলিতে খনন করব না, আমরা কেবল F() কী যাদু ফাংশন সম্পর্কে কথা বলব।

2.4 F() কি?

তারা অনেক ভিন্ন এবং অনেক ভিন্ন বাস্তবায়ন প্রক্রিয়া নিয়ে আসতে পারে। নমুনা সারাংশ:

• F = rand() % nums_shards
• F = somehash(object.id) % num_shards
• F = object.date % num_shards
• F = object.user_id % num_shards
• ...
• F = shard_table [ somehash() |… object.date |… ]

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

একটি পুনরুত্পাদনযোগ্য বা এমনকি সামঞ্জস্যপূর্ণ হ্যাশ ফাংশন, বা কিছু বৈশিষ্ট্য দ্বারা শার্ড করার জন্য সামান্য বেশি বুদ্ধিমান পদ্ধতি রয়েছে। আসুন প্রতিটি পদ্ধতির মাধ্যমে যান।

F = র্যান্ড()

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

F = somehash()

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

কেন আমরা এই করছেন? এবং তারপর, যে আমরা একটি হাইলোড আছে এবং অন্য কিছুই একটি সার্ভারে ফিট করে. এটা মানানসই, জীবন এত সহজ হবে.

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

প্রাকৃতিক শার্ডিং (F = object.date % num_shards)

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

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

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

মনে হচ্ছে আমরা সবকিছুর একটি আদর্শ সমাধান নিয়ে এসেছি, কিন্তু দুটি সমস্যা রয়েছে:

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

এটা বলার অপেক্ষা রাখে না যে এটি একটি খারাপ শার্ডিং স্কিম - আমরা গরম ডেটা কেটে ফেলেছি, তবুও, হটেস্ট শার্ডের সাথে কিছু করা দরকার।

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

2.5 মূল্য পরিশোধ করতে হবে

আনুষ্ঠানিকভাবে, আমরা জানি এখন আমরা "সবকিছু" জানি। সত্য, আমরা একটি বিশাল মাথাব্যথা এবং দুটি ছোট মাথাব্যথা জানি না।

1. সহজ ব্যথা: খারাপভাবে smeared

এটি একটি পাঠ্যপুস্তক থেকে একটি উদাহরণ, যা প্রায় কখনও যুদ্ধে ঘটে না, তবে হঠাৎ করে।

• একটি তারিখ সঙ্গে একটি উদাহরণ হিসাবে, শুধুমাত্র একটি তারিখ ছাড়া!
• অনিচ্ছাকৃত অসম (বোধগম্য) বিতরণ।

তারা শার্ডিং মেকানিজম বেছে নিয়েছে, এবং/অথবা ডেটা পরিবর্তিত হয়েছে, এবং অবশ্যই, PM প্রয়োজনীয়তাগুলি প্রকাশ করেননি (আমাদের কোডে ত্রুটি নেই, PM সর্বদা প্রয়োজনীয়তাগুলি রিপোর্ট করেন না), এবং বিতরণ ভয়ংকরভাবে অসম হয়ে ওঠে। অর্থাৎ তারা মানদণ্ড মিস করেছে।

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

এটি একটি সাধারণ সমস্যা, সত্যি কথা বলতে, আমি মনে করি না যে একশোর মধ্যে অন্তত একজন ব্যক্তি জীবনে এটির মুখোমুখি হবেন, তবে হঠাৎ এটি অন্তত কাউকে সাহায্য করবে।

2. "অজেয়" ব্যথা: একত্রীকরণ, যোগদান

অন্য টেবিল থেকে এক বিলিয়ন রেকর্ডের জন্য এক টেবিল থেকে এক বিলিয়ন রেকর্ডে যোগদান করে এমন নির্বাচন কীভাবে করবেন?

• কিভাবে "দ্রুত" গণনা করা যায়... আএএ এবং বিবিবির মধ্যে র্যান্ডকল কোথায়?
• কিভাবে "স্মার্টলি" করবেন... user_32shads Join posts_1024 shards?

সংক্ষিপ্ত উত্তর: কোন উপায় নেই, কষ্ট!

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

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

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

2.6। জটিল/দীর্ঘ ব্যথা: রিশার্ডিং

প্রস্তুত হন: আপনি যদি আপনার জীবনে প্রথমবার আপনার ডেটা ভাগ করেন, তাহলে গড়ে আপনি এটি আরও পাঁচবার ভাগ করবেন।

আপনি কতগুলি ক্লাস্টার কনফিগার করুন না কেন, আপনাকে এখনও পুনরায় ভাগ করতে হবে৷

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

আমাদের দুটির চমৎকার ক্ষমতা থাকলে ভাল হয়: 16টি সার্ভার শার্ড ছিল, এখন এটি 32। এটি আরও মজাদার যদি এটি 17 হয়, এটি 23 - দুটি ভাসিমালি মৌলিক সংখ্যা। কিভাবে ডাটাবেস এটা করতে পারে, হয়তো তাদের ভিতরে কিছু জাদু আছে?

সঠিক উত্তর হল: না, ভিতরে কোন জাদু নেই, তাদের ভিতরে নরক আছে।

এর পরে, আমরা "হাত দ্বারা" কী করা যেতে পারে তা বিবেচনা করব, সম্ভবত আমরা "একটি স্বয়ংক্রিয় মেশিন হিসাবে" বুঝতে পারব।

কপালে # 1। সবকিছু স্থানান্তর করুন

সমস্ত অবজেক্টের জন্য, আমরা নিউএফ(অবজেক্ট) বিবেচনা করি, একটি নতুন শার্ডে স্থানান্তর করি।

NewF()=OldF() মিলে যাওয়ার সম্ভাবনা কম।

এর প্রায় সবকিছু কভার করা যাক.

উহু.

আমি আশা করি পুরো 2 বিলিয়ন রেকর্ডগুলি পুরানো শার্ডগুলি থেকে নতুনগুলিতে স্থানান্তর করার মতো কোনও নরক নেই৷ নিষ্পাপ পদ্ধতিটি বোধগম্য: 17টি মেশিন ছিল, 6টি মেশিন ক্লাস্টারে যুক্ত করা হয়েছিল, 2 বিলিয়ন রেকর্ডগুলি সাজানো হয়েছিল, সেগুলি 17টি মেশিন থেকে 23টি মেশিনে স্থানান্তরিত হয়েছিল। প্রতি 10 বছরে একবার, আপনি সম্ভবত এটি করতে পারেন। কিন্তু সামগ্রিকভাবে এটি একটি খারাপ পদক্ষেপ।

কপালে #2। অর্ধেক স্থানান্তর করুন

পরবর্তী নিরীহ উন্নতি - আসুন এমন একটি বোকা স্কিম পরিত্যাগ করি - 17টি গাড়িকে 23 তে পুনরায় ভাগ করা নিষিদ্ধ করবে এবং আমরা সর্বদা 16টি গাড়িকে 32টি গাড়িতে পুনরায় ভাগ করব! তারপর, তত্ত্ব অনুসারে, আমাদেরকে ঠিক অর্ধেক ডেটা স্থানান্তর করতে হবে এবং অনুশীলনে আমরা এটিও করতে পারি।

সমস্ত অবজেক্টের জন্য, আমরা নিউএফ(অবজেক্ট) বিবেচনা করি, একটি নতুন শার্ডে স্থানান্তর করি।

এটি কঠোরভাবে 2^N ছিল, এখন এটি কঠোরভাবে 2^(N+1) শার্ড।

NewF()=OldF() মিলে যাওয়ার সম্ভাবনা 0.5।

এর প্রায় 50% ডেটা স্থানান্তর করা যাক।

সর্বোত্তম, কিন্তু শুধুমাত্র দুই ক্ষমতার জন্য কাজ করে।

নীতিগতভাবে, গাড়ির সংখ্যার ক্ষেত্রে দুটির শক্তির সাথে আবদ্ধ হওয়া ছাড়া সবকিছুই ঠিক আছে। এই নিষ্পাপ পদ্ধতি, অদ্ভুতভাবে যথেষ্ট, কাজ করতে পারে.

অনুগ্রহ করে মনে রাখবেন যে এই ক্ষেত্রে দুটির ক্ষমতা দ্বারা ক্লাস্টারের অতিরিক্ত বিভাজনও সর্বোত্তম। যাই হোক না কেন, 16টির ক্লাস্টারে 16টি মেশিন যোগ করলে, আমরা অর্ধেক ডেটা স্থানান্তর করতে বাধ্য - ঠিক অর্ধেক এবং শিফট।

ঠিক আছে, কিন্তু মানবজাতি কি সত্যিই অন্য কিছু আবিষ্কার করেনি - একটি অনুসন্ধিৎসু মন থেকে প্রশ্ন ওঠে।

আরো মজা #3. ধারাবাহিক হ্যাশিং

অবশ্যই, সামঞ্জস্যপূর্ণ হ্যাশিং সম্পর্কে একটি বৃত্ত সহ একটি ছবি এখানে প্রয়োজন৷

আপনি যদি “সঙ্গতিপূর্ণ হ্যাশিং” গুগল করেন, তাহলে অবশ্যই একটি বৃত্ত বেরিয়ে আসবে, সমস্ত ফলাফল চেনাশোনা দ্বারা পরিপূর্ণ।

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

একটি শার্ড যোগ করার সময়: আমরা সব কিছু দেখি না, শুধুমাত্র 2টি "প্রতিবেশী", আমরা গড় 1/n স্থানান্তর করি।

একটি শার্ড মুছে ফেলার সময়: আমরা কেবল মুছে ফেলা শার্ডের দিকেই তাকাই, আমরা কেবল এটি স্থানান্তর করি। সর্বোত্তম ধরনের.

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

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

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

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

মনোযোগ, প্রশ্ন হল: এটি আরও উন্নত করা যেতে পারে? এবং লোডিং shards এর অভিন্নতা উন্নত? তারা বলে এটা সম্ভব!

আরো মজা #4. মিলনমেলা/HRW

পরবর্তী সাধারণ ধারণা (উপাদানটি শিক্ষামূলক, তাই জটিল কিছু নেই): shard_id = arg max হ্যাশ(object_id, shard_id)।

কেন এটাকে রেন্ডেজভাস হ্যাশিং বলা হয় আমি জানি না, কিন্তু আমি জানি কেন এটাকে হাইয়েস্ট র্যান্ডম ওয়েট বলা হয়। এটি এই মত কল্পনা করা খুব সহজ:

আমরা, উদাহরণস্বরূপ, 16 shards আছে. প্রতিটি বস্তুর (স্ট্রিং) জন্য যা কোথাও রাখতে হবে, আমরা শার্ড নম্বর থেকে অবজেক্টের উপর নির্ভর করে 16 টি হ্যাশ গণনা করি। যার সর্বোচ্চ হ্যাশ মান আছে সে জিতবে।

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

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

আরেকটি সমস্যা হল যে এটি প্রচুর পরিমাণে শার্ড সহ গণনাগতভাবে ভারী।

আরো মজা #5. আরও কৌশল

মজার বিষয় হল, গবেষণা স্থির থাকে না এবং Google প্রতি বছর কিছু নতুন মহাকাশ প্রযুক্তি প্রকাশ করে:

• জাম্প হ্যাশ - গুগল '2014।
• মাল্টি প্রোব—Google '2015।
• Maglev-Google '2016।

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

উপসংহার

গ্যালিয়াস জুলিয়াস সিজারের নামানুসারে শার্ডিং নামে একটি গুরুত্বপূর্ণ মৌলিক কৌশল রয়েছে: "বিভক্ত করুন এবং শাসন করুন, শাসন করুন এবং ভাগ করুন!"। যদি ডেটা একটি সার্ভারে ফিট না হয় তবে এটি 20টি সার্ভারে বিভক্ত করা প্রয়োজন।

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

এটি হাত দিয়ে না করাই ভাল, "বেস" (অনুসন্ধান, ডিএফএস, ...) নিজেই ঝাঁকুনি দিতে পারে। যে কোনও ক্ষেত্রে, শীঘ্রই বা পরে, হাইলোড আসবে এবং কোনওভাবে ডেটা বিভক্ত করতে হবে। এটা এমন নয় যে বেস নিজেই করতে পারলেও আপনি কোন সমস্যায় পড়বেন না। অ্যালগরিদমিক মৌলবাদ সম্পর্কে মনে রাখবেন - আপনাকে বুঝতে হবে কীভাবে সবকিছু ভিতরে কাজ করে।

প্রথমবার শার্ডিং সেট আপ করার সময়, F() সাবধানে নির্বাচন করুন, অনুরোধ, নেটওয়ার্ক ইত্যাদি সম্পর্কে চিন্তা করুন। তবে প্রস্তুত হন, আপনাকে সম্ভবত 2 বার বেছে নিতে হবে এবং অন্তত একবার আপনাকে সবকিছু আবার করতে হবে।