مرحباً ، اسمي فلاديسلاف ، وأنا عضو في فريق تطوير
Tarantool . Tarantool هو DBMS وخادم تطبيق في كل واحدة. اليوم سأحكي قصة كيف قمنا بتطبيق القياس الأفقي في تارانتول عن طريق وحدة
VShard .
بعض المعرفة الأساسية أولا.
هناك نوعان من التحجيم: أفقي وعمودي. وهناك نوعان من القياس الأفقي: النسخ المتماثل والمشاركة. يضمن النسخ المتماثل تحجيمًا حسابيًا بينما يتم استخدام التدرج لتغيير حجم البيانات.
تقسم المشاركة أيضًا إلى نوعين: المشاركة القائمة على النطاق والمشاركة القائمة على التجزئة.
تشير المشاركة المستندة إلى النطاق إلى أن بعض مفاتيح shard يتم حسابها لكل سجل نظام المجموعة. يتم إسقاط مفاتيح القطع على خط مستقيم مفصول إلى نطاقات وتخصيصها لعقد فعلية مختلفة.
تكون عملية التجزئة المستندة إلى التجزئة أقل تعقيدًا: يتم احتساب دالة تجزئة لكل سجل في كتلة. يتم تخصيص السجلات التي لها نفس دالة التجزئة لنفس العقدة الفعلية.
سأركز على التوسع الأفقي باستخدام التقسيم القائم على التجزئة.
تطبيق أقدم
كان Tarantool Shard الوحدة النمطية الأصلية للتحجيم الأفقي. واستخدمت طريقة بسيطة مبنية على أساس التجزئة ومفاتيح شارات محسوبة بواسطة المفتاح الأساسي لجميع السجلات في مجموعة.
function shard_function(primary_key) return guava(crc32(primary_key), shard_count) end
لكن في النهاية أصبح Tarantool Shard غير قادر على معالجة المهام الجديدة.
أولاً ، أصبح أحد متطلباتنا النهائية هو
المكان المضمون
للبيانات ذات الصلة المنطقية . بمعنى آخر ، عندما يكون لدينا بيانات مرتبطة منطقياً ، نريد دائمًا تخزينها على عقدة فعلية واحدة ، بغض النظر عن طبولوجيا الكتلة والتوازن بين التغييرات. لا يمكن أن تضمن Tarantool Shard ذلك. يتم حساب التجزئة فقط مع المفاتيح الأساسية ، وبالتالي يمكن أن تتسبب إعادة التوازن في الفصل المؤقت للسجلات مع نفس التجزئة لأن التغييرات لا يتم تنفيذها ذريًا.
وكان هذا النقص في البيانات المحلية المشكلة الرئيسية بالنسبة لنا. هنا مثال. لنفترض أن هناك بنكًا قام أحد العملاء بفتح حساب فيه. يجب تخزين المعلومات المتعلقة بالحساب والعميل معًا ماديًا حتى يمكن استردادها في طلب واحد أو تغييرها في معاملة واحدة ، على سبيل المثال أثناء تحويل الأموال. إذا استخدمنا التقاسم التقليدي لـ Tarantool Shard ، فستكون هناك قيم دالة تجزئة مختلفة للحسابات والعملاء. قد تنتهي البيانات على عقد فعلية منفصلة. هذا يعقد حقًا كلاً من قراءة ومعالجة بيانات العميل.
format = {{'id', 'unsigned'}, {'email', 'string'}} box.schema.create_space('customer', {format = format}) format = {{'id', 'unsigned'}, {'customer_id', 'unsigned'}, {'balance', 'number'}} box.schema.create_space('account', {format = format})
في المثال أعلاه ، يمكن أن تكون حقول معرف الحسابات والعميل غير متسقة. إنهم متصلون بواسطة الحقل customer_id الخاص بالحساب وحقل معرف العميل. ينتهك حقل المعرّف نفسه قيد التفرد للمفتاح الأساسي للحساب. ولا يمكن لشارد أداء التظليل بأي طريقة أخرى.
هناك مشكلة أخرى تتمثل في إعادة
بطيئة لإعادة التوزيع ، وهي المشكلة الأساسية لجميع شظايا التجزئة. خلاصة القول هي أنه عند تغيير مكونات الكتلة ، تتغير وظيفة shard لأنها تعتمد عادة على عدد العقد. لذلك عندما تتغير الوظيفة ، من الضروري استعراض جميع السجلات في المجموعة وإعادة حساب الوظيفة. قد يكون من الضروري أيضًا نقل بعض السجلات. وأثناء نقل البيانات ، لا نعرف حتى إذا كان السجل المطلوب؟ في الطلب تم بالفعل نقل البيانات أو يتم نقلها في الوقت الحالي. وبالتالي ، أثناء إعادة المشاركة ، من الضروري تقديم طلبات قراءة مع كل من وظائف shard القديمة والجديدة. تتم معالجة الطلبات مرتين أبطأ ، وهذا غير مقبول.
هناك مشكلة أخرى مع Tarantool Shard وهي قلة توفر القراءات في حالة فشل العقدة في مجموعة النسخ المتماثلة.
حل جديد
لقد أنشأنا
Tarantool VShard لحل المشكلات الثلاثة المذكورة أعلاه. يتمثل الاختلاف الرئيسي في أن مستوى تخزين البيانات الخاص به يكون ظاهريًا ، أي أن المستودعات الفعلية تستضيف مخازن افتراضية ، ويتم تخصيص سجلات البيانات على المستودعات الافتراضية. تسمى هذه المستودعات
الدلاء . ليس لدى المستخدم ما يدعو للقلق بشأن ما هو موجود على عقدة فعلية معينة. الجرافة عبارة عن وحدة بيانات غير قابلة للتجزئة الذرية ، مثل مجموعة في التقسيم التقليدي. يقوم VShard دائمًا بتخزين مجموعة كاملة على عقدة فعلية واحدة ، وخلال إعادة المشاركة ، تقوم بترحيل كافة البيانات من مجموعة واحدة تلقائيًا. هذه الطريقة تضمن البيانات المحلية. نحن فقط نضع البيانات في مجموعة واحدة ، ويمكننا دائمًا التأكد من عدم فصلها أثناء تغييرات الكتلة.
كيف نضع البيانات في دلو واحد؟ دعنا نضيف حقل معرف جديد للجدول إلى الجدول لعميلنا المصرفي. إذا كانت قيمة هذا الحقل هي نفسها بالنسبة للبيانات ذات الصلة ، فستكون جميع السجلات في مجموعة واحدة. الميزة هي أنه يمكننا تخزين السجلات بنفس معرف الجرافة في مسافات مختلفة ، وحتى في محركات مختلفة. يتم ضمان مكان البيانات استنادًا إلى معرف الجرافة بغض النظر عن طريقة التخزين.
format = {{'id', 'unsigned'}, {'email', 'string'}, {'bucket_id', 'unsigned'}} box.schema.create_space('customer', {format = format}) format = {{'id', 'unsigned'}, {'customer_id', 'unsigned'}, {'balance', 'number'}, {'bucket_id', 'unsigned'}} box.schema.create_space('account', {format = format})
لماذا هذا مهم جدا؟ عند استخدام التقاسم التقليدي ، ستمتد البيانات لتشمل العديد من المستودعات المادية الحالية. على سبيل المثال ، لدينا بنك ، يتعين علينا الاتصال بكل عقدة عند طلب جميع الحسابات لعميل معين. إذن ، نحصل على تعقيد قراءة O (N) ، حيث N هو عدد المستودعات المادية. انها بطيئة بجنون.
يتيح استخدام الجرافات والمحلية بمعرف الجرافات قراءة البيانات الضرورية من عقدة واحدة باستخدام طلب واحد - بغض النظر عن حجم الكتلة.
في VShard ، يمكنك حساب معرف الجرافة وتعيينها. بالنسبة لبعض الأشخاص ، هذه ميزة ، بينما يعتبرها الآخرون عيبًا. أعتقد أن القدرة على اختيار الوظيفة الخاصة بك لحساب معرف الجرافة تعد ميزة.
ما هو الفرق الرئيسي بين التقاسم التقليدي والمشاركة الافتراضية مع الجرافات؟
في الحالة الأولى ، عندما نغير مكونات نظام المجموعة ، فلدينا حالتان: الحالة الحالية (القديمة) والأخرى الجديدة التي سيتم تنفيذها. في عملية الانتقال ، من الضروري ليس فقط ترحيل البيانات ، ولكن أيضًا لإعادة حساب وظيفة التجزئة لكل سجل. هذا ليس ملائمًا جدًا لأننا في أي لحظة لا نعرف ما إذا كانت البيانات المطلوبة قد تم ترحيلها بالفعل أم لا. علاوة على ذلك ، هذه الطريقة غير موثوقة ، والتغييرات ليست ذرية ، لأن الترحيل الذري لمجموعة السجلات التي لها نفس قيمة دالة التجزئة قد يتطلب تخزينًا دائمًا لحالة الترحيل في حالة الحاجة إلى استرداد. نتيجة لذلك ، هناك تعارضات وأخطاء ، ويجب إعادة تشغيل العملية عدة مرات.
التقاسم الافتراضي أبسط بكثير. ليس لدينا حالتان عنقوديتان مختلفتان ؛ ليس لدينا سوى حالة دلو. الكتلة أكثر مرونة ، فهي تنتقل بسلاسة من حالة إلى أخرى. هناك أكثر من دولتين الآن؟ (غير واضح). مع الانتقال السلس ، من الممكن تغيير الموازنة السريعة أو إزالة المخازن المضافة حديثًا. وهذا يعني أن التحكم في الموازنة زاد بشكل كبير وأصبح أكثر حبيبة.
الاستخدام
دعنا نقول أننا اخترنا وظيفة لمعرف الجرافات وقمنا بتحميل الكثير من البيانات في المجموعة بحيث لا يتبقى فراغ. نود الآن إضافة بعض العقد ونقل البيانات إليها تلقائيًا. هذه هي الطريقة التي نقوم بها بها في VShard: أولاً ، نبدأ عقدًا جديدة وندير Tarantool هناك ، ثم نقوم بتحديث تهيئة VShard الخاصة بنا. أنه يحتوي على معلومات حول كل مكون الكتلة ، كل نسخة طبق الأصل ، مجموعات النسخ المتماثلة ، الماجستير ، URIs المعينة وأكثر من ذلك بكثير. نضيف الآن عقدنا الجديدة إلى ملف التكوين ، ونطبقها على جميع عقد نظام المجموعة باستخدام VShard.storage.cfg.
function create_user(email) local customer_id = next_id() local bucket_id = crc32(customer_id) box.space.customer:insert(customer_id, email, bucket_id) end function add_account(customer_id) local id = next_id() local bucket_id = crc32(customer_id) box.space.account:insert(id, customer_id, 0, bucket_id) end
كما تتذكر ، عند تغيير عدد العقد في التقاسم التقليدي ، تتغير وظيفة shard نفسها أيضًا. هذا لا يحدث في VShard. لدينا هنا عددًا ثابتًا من المخازن أو الدلاء الافتراضية. هذا ثابت تختاره عند بدء تشغيل الكتلة. قد يبدو أن قابلية التوسع قابلة للتقييد ، لكنها في الحقيقة ليست كذلك. يمكنك تحديد عدد كبير من الجرافات وعشرات ومئات الآلاف. الشيء المهم الذي يجب معرفته هو أنه يجب أن يكون هناك على الأقل ترتيبان بحجم أكبر من الدلائل من العدد الأقصى لمجموعات النسخ المتماثلة التي سيكون لديك في المجموعة.
نظرًا لأن عدد المخازن الظاهرية لا يتغير ، وتعتمد وظيفة shard فقط على هذه القيمة ، يمكننا إضافة العديد من المخازن المادية كما نود دون إعادة حساب وظيفة shard.
فكيف يتم تخصيص الدلاء للمستودعات المادية؟ إذا تم استدعاء VShard.storage.cfg ، تستيقظ عملية إعادة التوازن على إحدى العقد. هذه عملية تحليلية تحسب التوازن المثالي للكتلة. تنتقل العملية إلى كل عقدة فعلية وتسترجع عدد المجموعات ، ثم تقوم بإنشاء مسارات لتحركاتها من أجل تحقيق التوازن بين التخصيص. ثم يرسل rebalancer الطرق إلى المخازن المحملة ، والتي تبدأ بدورها في إرسال الدلاء. في وقت لاحق إلى حد ما ، الكتلة متوازنة.
في المشروعات الواقعية ، قد لا يتم الوصول إلى توازن مثالي بهذه السهولة. على سبيل المثال ، يمكن أن تحتوي مجموعة النسخ المتماثلة على بيانات أقل من المجموعة الأخرى لأنها تحتوي على سعة تخزين أقل. في هذه الحالة ، قد يعتقد VShard أن كل شيء متوازن ولكن في الواقع التخزين الأول على وشك التحميل الزائد. للتصدي لهذا ، قمنا بتوفير آلية لتصحيح قواعد التوازن عن طريق الأوزان. يمكن تعيين وزن لأي مجموعة النسخ المتماثلة أو التخزين. عندما يقرر rebalancer عدد الجرافات التي يجب إرسالها وأين ، فإنه يأخذ في الاعتبار
العلاقات بين جميع أزواج الأوزان.
على سبيل المثال ، إذا كان وزن وحدة تخزين واحدة 100 والآخر 200 ، فسوف يقوم التخزين الثاني بتخزين ضعف عدد الجرافات مثل الأولى. يرجى ملاحظة أنني أتحدث تحديدا عن
علاقات الوزن. القيم المطلقة ليس لها أي تأثير على الإطلاق. اخترت الأوزان بناءً على توزيع 100٪ في كتلة: لذا فإن 30٪ من وحدة تخزين واحدة ستنتج 70٪ للمجموعة الأخرى. يمكنك أن تأخذ سعة التخزين بالجيجابايت كأساس ، أو يمكنك قياس الوزن في عدد المجموعات. الشيء الأكثر أهمية هو الحفاظ على النسبة اللازمة.
هذه الطريقة لها تأثير جانبي مثير للإهتمام: إذا تم تخصيص وحدة تخزين بدون وزن ، فسوف تقوم وحدة إعادة التوازن بإعادة توزيع كل وحدات التخزين الخاصة بها. بعد ذلك ، يمكنك إزالة مجموعة النسخ المتماثلة بالكامل من التكوين.
هجرة الجرافة الذرية
لدينا دلو. يقبل بعض القراءة والكتابة ، وفي لحظة معينة ، يطلب rebalancer ترحيله إلى وحدة تخزين أخرى. يتوقف الدلو عن قبول طلبات الكتابة ، وإلا سيتم تحديثه أثناء الترحيل ، ثم يتم تحديثه مرة أخرى أثناء ترحيل التحديث ، ثم يتم تحديث التحديث ، وما إلى ذلك. لذلك ، يتم حظر طلبات الكتابة ، ولكن القراءة من المجموعة ما زالت ممكنة. يتم الآن نقل البيانات إلى الموقع الجديد. عند اكتمال الترحيل ، يبدأ الجرافة في قبول الطلبات مرة أخرى. لا يزال موجودًا في الموقع القديم ، ولكن تم وضع علامة عليه كقمامة ، وبعد ذلك يقوم جامع البيانات المهملة بحذفه قطعة قطعة.
هناك بعض البيانات الأولية المخزنة فعليًا على القرص المقترنة بكل مجموعة. يتم تخزين جميع الخطوات الموضحة أعلاه على القرص ، وبغض النظر عما يحدث للتخزين ، سيتم استعادة حالة الجرافة تلقائيًا.
قد يكون لديك بعض الأسئلة التالية:
- ماذا يحدث للطلبات التي تعمل مع المجموعة عندما تبدأ عملية الترحيل؟
يوجد نوعان من المراجع في البيانات الوصفية لكل مجموعة: RO و RW. عندما يقدم المستخدم طلبًا إلى مجموعة ، يشير إلى ما إذا كان يجب أن يكون العمل في وضع للقراءة فقط أو في وضع القراءة والكتابة. لكل طلب ، يتم زيادة عداد المرجع المقابل.
لماذا نحتاج عدادات مرجعية لطلبات الكتابة؟ لنفترض أنه يتم ترحيل دلو ، وفجأة يريد جامع البيانات المهملة حذفه. يتعرف أداة تجميع مجمعي البيانات المهملة على أن عداد المرجع أعلى من الصفر وبالتالي لن يتم حذف الجرافة. عند اكتمال جميع الطلبات ، يستطيع جامع البيانات المهملة القيام بعمله.
يضمن عداد المرجع للكتابة أيضًا عدم بدء ترحيل المجموعة إذا كان هناك طلب كتابة واحد على الأقل قيد المعالجة. ولكن بعد ذلك مرة أخرى ، يمكن أن تأتي طلبات الكتابة واحدة تلو الأخرى ، ولن يتم ترحيل المجموعة. لذلك إذا رغب rebalancer في نقل المجموعة ، فسيحظر النظام طلبات الكتابة الجديدة أثناء انتظار استكمال الطلبات الحالية خلال فترة زمنية محددة. إذا لم يتم إكمال الطلبات خلال المهلة المحددة ، سيبدأ النظام في قبول طلبات الكتابة الجديدة مرة أخرى أثناء تأجيل ترحيل المجموعة. بهذه الطريقة ، سيحاول rebalancer ترحيل المجموعة إلى أن تنجح عملية الترحيل.
يحتوي VShard على API bucket_ref منخفض المستوى في حالة احتياجك إلى أكثر من مجرد قدرات عالية المستوى. إذا كنت تريد فعل شيء ما بنفسك ، فيرجى الرجوع إلى واجهة برمجة التطبيقات هذه. - هل من الممكن ترك السجلات غير محظورة؟
رقم إذا كان الدلو يحتوي على بيانات مهمة ويتطلب وصولًا دائمًا للكتابة ، فسيتعين عليك حظر الترحيل تمامًا. لدينا وظيفة bucket_pin للقيام بذلك. إنه يربط الجرافة بمجموعة النسخ المتماثلة الحالية بحيث لا يمكن لرابط الموازنة ترحيل الجرافة. في هذه الحالة ، ستكون الدلاء المجاورة قادرة على التحرك دون قيود.
يعد تأمين مجموعة النسخ المتماثلة أداة أقوى من bucket_pin. هذا لم يعد يتم في التعليمات البرمجية ولكن في التكوين. يؤدي قفل مجموعة النسخ المتماثلة إلى تعطيل ترحيل أي مجموعة داخل / خارج مجموعة النسخ المتماثلة. لذلك ستكون جميع البيانات متاحة بشكل دائم للكتابة.
VShard.router
يتكون VShard من وحدتين فرعيتين: VShard.storage و VShard.router. يمكننا إنشاء وتوسيع نطاق هذه بشكل مستقل على مثيل واحد. عند طلب نظام مجموعة ، لا نعرف مكان وجود دلو معين ، وسيقوم VShard.router بالبحث عنه بواسطة معرف الجرافة بالنسبة لنا.
دعونا ننظر إلى الوراء في مثالنا ، المجموعة المصرفية مع حسابات العملاء. أود أن أكون قادرًا على الحصول على جميع حسابات عميل معين من المجموعة. هذا يتطلب وظيفة قياسية للبحث المحلي:
يبدو لجميع حسابات العميل من قبل هويته. الآن يجب أن أقرر أين يجب أن أقوم بتشغيل الوظيفة. لهذا الغرض ، أقوم بحساب معرف الجرافة بواسطة معرف العميل في طلبي ، وأطلب من VShard.router استدعاء الوظيفة في وحدة التخزين حيث يوجد الجرافة ذات معرف الجرافة المستهدفة. تحتوي الوحدة الفرعية على جدول توجيه يصف مواقع المجموعات في مجموعات النسخ المتماثلة. يعيد VShard.router توجيه طلبي.
بالتأكيد قد يحدث أن يبدأ التقسيم في هذه اللحظة بالضبط ، وأن الدلاء تبدأ في التحرك. يقوم الموجه الموجود في الخلفية بتحديث الجدول تدريجيًا في مجموعات كبيرة عن طريق طلب جداول الجردل الحالية من المستودعات.
قد نطلب حتى دلوًا تم ترحيله مؤخرًا ، حيث لم يقم جهاز التوجيه بعد بتحديث جدول التوجيه الخاص به. في هذه الحالة ، ستطلب وحدة التخزين القديمة ، والتي إما ستعيد توجيه جهاز التوجيه إلى وحدة تخزين أخرى ، أو ستستجيب ببساطة أنه لا يحتوي على البيانات اللازمة. بعد ذلك ، سوف يمر جهاز التوجيه من خلال كل وحدة تخزين بحثًا عن المجموعة المطلوبة. ولن نلاحظ خطأً في جدول التوجيه.
قراءة الفشل
دعونا نتذكر مشاكلنا الأولية:
- لا محلية البيانات. حل عن طريق الدلاء.
- إعادة المشاركة في عملية التعثر وإيقاف كل شيء. قمنا بتنفيذ نقل البيانات الذرية عن طريق الدلاء وتخلصنا من إعادة حساب وظيفة قشرة.
- قراءة الفشل.
تتم معالجة المشكلة الأخيرة بواسطة VShard.router ، المدعومة من النظام الفرعي لتجاوز قراءة تلقائية.
من وقت لآخر ، يرسل جهاز التوجيه الأصوات المخزنة في التكوين. قل على سبيل المثال ، لا يمكن للموجه اختبار اتصال واحد منهم. يحتوي جهاز التوجيه على اتصال نسخ احتياطي ساخن لكل نسخة متماثلة ، لذلك إذا كانت النسخة المتماثلة الحالية لا تستجيب ، فإنه يتحول فقط إلى نسخة أخرى. ستتم معالجة طلبات القراءة بشكل طبيعي لأنه يمكننا قراءة النسخ المتماثلة (ولكن ليس الكتابة). ويمكننا تحديد أولوية النسخ المتماثلة كعامل لجهاز التوجيه لاختيار تجاوز الفشل للقراءات. ويتم ذلك عن طريق تقسيم المناطق.
نقوم بتعيين رقم منطقة لكل نسخة متماثلة وكل موجه وتحديد جدول حيث نشير إلى المسافة بين كل زوج من المناطق. عندما يقرر الموجه المكان الذي يجب أن يرسل فيه طلب قراءة ، فإنه يحدد نسخة متماثلة في أقرب منطقة.
هذا هو ما يبدو في التكوين:
بشكل عام ، يمكنك طلب أي نسخة متماثلة ، ولكن إذا كانت الكتلة كبيرة ومعقدة وموزعة بشكل كبير ، فإن تقسيم المناطق يمكن أن يكون مفيدًا للغاية. يمكن تحديد رفوف الخادم المختلفة كمناطق بحيث لا يتم تحميل الشبكة بشكل زائد بواسطة حركة المرور. بدلاً من ذلك ، يمكن تحديد نقاط معزولة جغرافيا.
يساعد تقسيم المناطق أيضًا عند إظهار النسخ المتماثلة سلوكيات مختلفة. على سبيل المثال ، تحتوي كل مجموعة متماثلة على نسخة متماثلة احتياطية واحدة لا ينبغي أن تقبل الطلبات ولكن يجب فقط تخزين نسخة من البيانات. في هذه الحالة ، نضعها في منطقة بعيدة عن جميع أجهزة التوجيه في الجدول حتى لا يقوم الموجه بمعالجة هذه النسخة المتماثلة ما لم يكن ذلك ضروريًا تمامًا.
اكتب الفشل
لقد تحدثنا بالفعل عن قراءة الفشل. ماذا عن الكتابة الفشل عند تغيير السيد؟ في VShard ، الصورة ليست وردية كما كانت من قبل: لم يتم تنفيذ الاختيار الرئيسي ، لذا سيتعين علينا القيام بذلك بأنفسنا. عندما يتم تعيين سيد بطريقة أو بأخرى ، يجب أن يتولى المثيل المعين دور المعلم. بعد ذلك نقوم بتحديث التكوين عن طريق تحديد master = false للسيد القديم ، و master = true للتطبيق الجديد ، وتطبيق التكوين عن طريق VShard.storage.cfg ومشاركته مع كل وحدة تخزين. كل شيء آخر يتم تلقائيا. توقف المعلم القديم عن قبول طلبات الكتابة ويبدأ المزامنة مع الجديد ، لأنه قد تكون هناك بيانات تم تطبيقها بالفعل على الرئيسي القديم ولكن ليس على الجديد. بعد ذلك ، سيد جديد هو المسؤول ويبدأ في قبول الطلبات ، والسيد القديم هو نسخة طبق الأصل. هذه هي الطريقة التي يعمل بها فشل الكتابة في VShard.
replicas = new_cfg.sharding[uud].replicas replicas[old_master_uuid].master = false replicas[new_master_uuid].master = true vshard.storage.cfg(new_cfg)
كيف يمكننا تتبع هذه الأحداث المختلفة؟
VShard.storage.info و VShard.router.info كافية.
يعرض VShard.storage.info المعلومات في عدة أقسام.
vshard.storage.info() --- - replicasets: <replicaset_2>: uuid: <replicaset_2> master: uri: storage@127.0.0.1:3303 <replicaset_1>: uuid: <replicaset_1> master: missing bucket: receiving: 0 active: 0 total: 0 garbage: 0 pinned: 0 sending: 0 status: 2 replication: status: slave Alerts: - ['MISSING_MASTER', 'Master is not configured for ''replicaset <replicaset_1>']
القسم الأول مخصص للنسخ المتماثل. هنا يمكنك رؤية حالة مجموعة النسخ المتماثلة حيث يتم استدعاء الوظيفة: تأخر النسخ المتماثل لها ، اتصالاتها المتاحة وغير المتاحة ، التكوين الرئيسي ، إلخ.
في قسم الجرافة ، يمكنك أن ترى في الوقت الفعلي عدد الجرافات التي يتم ترحيلها إلى / من مجموعة النسخ المتماثلة الحالية ، وعدد الجرافات العاملة في الوضع العادي ، وعدد الجرافات المحددة كقمامة ، وعدد الجرافات المثبتة.
يعرض قسم التنبيهات المشكلات التي كان بإمكان VShard تحديدها بنفسه: "لم يتم تكوين الرئيسي ،" "يوجد مستوى غير كافٍ للتكرار" ، "الرئيسي موجود ، ولكن فشلت جميع النسخ المتماثلة" ، إلخ.
والقسم الأخير (ف: هل هذا "الوضع"؟) هو ضوء يتحول إلى اللون الأحمر عندما تسوء الأمور. إنه رقم من صفر إلى ثلاثة ، حيث يكون الرقم الأعلى أسوأ.
يحتوي VShard.router.info على نفس الأقسام ، لكن معناها مختلف إلى حد ما.
vshard.router.info() --- - replicasets: <replicaset_2>: replica: &0 status: available uri: storage@127.0.0.1:3303 uuid: 1e02ae8a-afc0-4e91-ba34-843a356b8ed7 bucket: available_rw: 500 uuid: <replicaset_2> master: *0 <replicaset_1>: replica: &1 status: available uri: storage@127.0.0.1:3301 uuid: 8a274925-a26d-47fc-9e1b-af88ce939412 bucket: available_rw: 400 uuid: <replicaset_1> master: *1 bucket: unreachable: 0 available_ro: 800 unknown: 200 available_rw: 700 status: 1 alerts: - ['UNKNOWN_BUCKETS', '200 buckets are not discovered']
القسم الأول مخصص للنسخ المتماثل ، على الرغم من أنه لا يحتوي على معلومات حول تأخر النسخ المتماثل ، ولكنه يحتوي على معلومات حول التوفر: اتصالات جهاز التوجيه بمجموعة النسخ المتماثلة ؛ اتصال ساخن واتصال النسخ الاحتياطي في حالة فشل سيد. السيد المحدد ؛ وعدد دلاء RW المتاحة ودلو RO في كل مجموعة النسخ المتماثلة.
يعرض قسم الجرافة العدد الإجمالي لدلائل القراءة والكتابة للقراءة فقط المتوفرة حاليًا لهذا الموجه ؛ عدد الجرافات مع موقع غير معروف ؛ وعدد المجموعات مع موقع معروف ولكن بدون اتصال بمجموعة النسخ المتماثلة الضرورية.
يصف قسم التنبيهات بشكل رئيسي الاتصالات وأحداث تجاوز الفشل والجرافات غير المحددة.
وأخيرا ، هناك أيضا حالة بسيطة؟ مؤشر من صفر إلى ثلاثة.
ماذا تحتاج لاستخدام VShard؟
يجب عليك أولاً تحديد عدد ثابت من الجرافات. لماذا لا تقوم فقط بتعيينها على int32_max؟ نظرًا لأنه يتم تخزين البيانات الوصفية مع كل مجموعة ، و 30 بايت في التخزين و 16 بايت على جهاز التوجيه. كلما زاد عدد الجرافات المتوفرة لديك ، سيتم شغل مساحة أكبر بواسطة البيانات الوصفية. ولكن في نفس الوقت ، سيكون حجم الجرافة أصغر ، مما يعني دقة أعلى في الكتلة وسرعة ترحيل أعلى لكل مجموعة. لذلك عليك أن تختار ما هو أكثر أهمية بالنسبة لك ومستوى قابلية التوسع اللازمة.
ثانيًا ، يجب عليك تحديد وظيفة شارب لحساب معرف الجرافة. القواعد هي نفسها عند اختيار وظيفة shard في التقاليد التقليدية ، حيث أن الجرافة هنا هي نفس عدد ثابت من المستودعات في التقاليد التقليدية. يجب أن تقوم الوظيفة بتوزيع قيم المخرجات بالتساوي ، وإلا فلن يكون توازن حجم الجرافة متوازناً ، ويعمل VShard فقط مع عدد المجموعات. إذا لم توازن بين وظيفة shard ، فستضطر إلى ترحيل البيانات من مجموعة إلى أخرى ، وتغيير وظيفة shard. وبالتالي ، يجب أن تختار بعناية.
ملخص
يضمن VShard:
- محلية البيانات
- إعادة الذري
- مرونة الكتلة العليا
- قراءة الفشل التلقائي
- وحدات تحكم دلو متعددة.
VShard قيد التطوير النشط. بعض المهام المخططة يجري تنفيذها بالفعل. المهمة الأولى هي
موازنة تحميل جهاز التوجيه . إذا كانت هناك طلبات قراءة كثيفة ، فليس من المستحسن دائمًا توجيهها إلى المعلم. يجب أن يوازن جهاز التوجيه بين طلبات النسخ المتماثلة للقراءة المختلفة من تلقاء نفسه.
المهمة الثانية هي
الهجرة دلو خالية من قفل . تم بالفعل تنفيذ خوارزمية تساعد في الحفاظ على إلغاء حظر المجموعات حتى أثناء الترحيل. سيتم حظر المجموعة فقط في النهاية لتوثيق الترحيل نفسه.
المهمة الثالثة هي
التطبيق الذري للتكوين . من غير المناسب أو الذري تطبيق التكوين بشكل منفصل لأن بعض السعة التخزينية قد لا تكون متاحة ، وإذا لم يتم تطبيق التكوين ، فماذا نفعل بعد ذلك؟ هذا هو السبب في أننا نعمل على آلية لنقل التكوين التلقائي.