بواسطة سانت بيت
أهلاً بكم! أنا مونس أندرسون، مهندس المنصة ، سأخبرك كيف قمنا ببناء وحدة تخزين S3 الخاصة بنا، وكيف تعمل، وما هي الحلول التي تبين أنها ناجحة، وما هي الحلول التي كانت تستحق التغيير إذا بدأنا نفس المشروع من الصفر الآن.
تم إعداد المقال بناءً على تقرير في بواسطة Mail.ru Cloud Solutions & Tarantool. في المقال سنتحدث:
- كيف تم تصميم تخزين Mail.ru، وقمنا على أساسه ببناء تخزين S3؛
- وما أضفناه لإنشاء Mail.ru Cloud Storage؛
- كيف يعمل نموذج تخزين الكائنات وما هي الخطوات التي تم اتخاذها لدخول الإنتاج؛
- حول التحسينات في نظام القتال: تجاوز الفشل والقياس؛
- وكيف قمنا بتنفيذ عملية التقسيم وإعادة التقسيم؛
- وأيضًا حول العمل مع شهادات SSL.
إذا كنت لا تريد أن تقرأ، يمكنك ذلك .
كيف تم تصميم تخزين Mail.ru، وقمنا على أساسه ببناء تخزين S3
بدأ تطوير S3 الخاص بنا على مساحة التخزين السحابية Mail.ru، لذا من المفيد في البداية معرفة كيفية عمله وما يمكنه فعله.
يتكون التخزين السحابي Mail.ru من خوادم بها أقراص. في المتوسط، يحتوي خادم التخزين الحديث على 36 قرصًا سعة كل منها 12-14 تيرابايت. في السابق، كانت الأقراص أصغر حجمًا، ولكن في غضون ثلاث سنوات زادت أحجام الأقراص، واليوم يبلغ حجمها ما يقرب من نصف بيتابايت من البيانات الأولية.
يتم دمج الأقراص من خوادم تخزين مختلفة فيما يسمى "الأزواج". الزوج عبارة عن وحدة تخزين ملفات واحدة. في الأساس، هو عبارة عن قرص مثبت على قسم معين في مسار محدد، حيث يمكن تحديد موقع الملفات التي تم تحديدها بواسطة التجزئة.
الزوج هو اسم تاريخي، وقد نجا حتى يومنا هذا، على الرغم من أن الزوج لا يحتوي بالضرورة على قرصين فقط. يمكن أن يكون هناك ثلاثة أقراص، ويمكن أن يكون هناك أيضًا العديد من وحدات التخزين الهجينة، على سبيل المثال 3/2.
الأزواج هي وحدات تخزين الكائنات
يتم تخزين جميع الأزواج في PairDB - وهو تطبيق قائم على Tarantool. جميع قواعد البيانات الموجودة في مستودعنا، بدءًا من القواعد الأولى، هي Tarantool، ولا نستخدم قواعد بيانات أخرى.
يقوم PairDB بتخزين جميع الأزواج وحالاتهم والمساحة الحرة واحتمالات الفشل والأخطاء الأخيرة. يمكنها أيضًا الذهاب إلى الفصول الدراسية بنفسها وتحديث حالتها والتحقق مما إذا كانت تعمل أم لا. أي أن PairDB عبارة عن لقطة عامة لحالة جميع الأقراص في نظامنا.
زوج DB: قاعدة بيانات حالة الزوج
يتم تخزين الملفات في أزواج، ولمعرفة أي زوج يحتوي على الملف، تحتاج إلى قاعدة بيانات أخرى - FileDB. يقوم بتخزين التعيين والتعريف المطابق: يتم تخزين ملف كذا وكذا على زوج كذا وكذا، بالإضافة إلى عدد صغير من السمات الضرورية.
قاعدة بيانات الملف: الموقع الذي تم تخزين الملف فيه
رابط مهم آخر هو خدمة النايلون، وهو جهاز توجيه للعمل مع قواعد البيانات. إنها نقطة دخول واحدة وتسمح لك بالعمل من خلال واجهة واحدة مع كل من PairDB وFileDB. هذه خدمة عديمة الحالة، فهي تعمل على موازنة الطلبات وفهم جزء FileDB الذي يجب الانتقال إليه ومعرفة الأزواج النشطة وأيها غير نشطة.
نايلون: جهاز توجيه للعمل مع قواعد البيانات
تحتاج أيضًا إلى تخزين المحتوى بطريقة ما في وحدة التخزين. هناك خدمة لهذا - غاسل. يوفر طريقتين HTTP: طريقة PUT لدفع المحتوى إلى التخزين، وطريقة GET لاسترداده من هناك. يعد HTTP بروتوكولًا شائعًا ومريحًا لنقل البيانات.
عندما نتواصل مع Streamer، فإنه يصل إلى PairDB عبر Nylon، ويكتشف الزوج الذي يمكنه تحميل ملف إليه، ثم ينقل البيانات عبر WebDAV إلى هذا الزوج.
في الأساس، أي خادم تخزين هو nginx بالإضافة إلى الأقراص المثبتة على طول المسارات المحددة. يمكننا تحميل ملف إلى وحدة التخزين من Streamer، أو حذفه، أو إعادة تسميته، أو التحقق من سلامته. أي أنها واجهة ملائمة للتفاعل على مستوى منخفض مع التخزين.
غاسل: نقطة دخول التخزين
ما أضفناه لإنشاء مساحة تخزين S3
لذلك، نظرنا إلى التصميم الأساسي العام للتخزين في الوقت الذي كنا فيه على وشك إطلاق وحدة تخزين S3. باستخدام طريقة PUT، يمكننا وضع محتوى عشوائي هناك والحصول على تجزئة كمعرف لهذه البيانات. باستخدام هذا المعرف، يمكنك الحضور لاحقًا والتقاط الملف الأصلي. ولكن هذا لا يكفي لتنفيذ S3. يحتوي بروتوكول S3، بالإضافة إلى تخزين الكائنات نفسه، على ما يلي:
- تخزين البيانات الوصفية - خصائص إضافية للكائنات؛
- تنظيم الوصول إلى الكائنات عبر HTTP؛
- تجميع الكائنات في مجموعات - الدلاء؛
- نقطة نهاية HTTP-S3. يقوم S3 بتنظيم البيانات في هياكل محددة تسمى الدلاء، كل منها يوفر نقطة دخول لتخزين الملفات.
لتنفيذ هذا المنطق، كانت هناك حاجة إلى خدمة منفصلة. أردت أيضًا توفير بنية فورية لمزيد من النمو للخدمة مع قابلية التوسع الخطي.
المكونات الأولى
برنامج خفي يقوم بتنفيذ S3 API. هذه هي واجهة S3 API القياسية الخاصة بشركة Amazon والتي تدعم XML للبيانات الوصفية وتسمح ببث المحتوى مباشرةً. لم يكن علينا أن نخترع أي شيء، كل شيء تم وصفه وتوثيقه.
لقد قمنا أيضًا بتثبيت Nginx أمام الخدمة. استخدمناها لإنهاء SSL وموازنة التحميل وأيضًا لبعض المنطق في Lua (المقاييس والتسجيل والتتبع).
لقد اخترنا أيضًا Tarantool لتخزين البيانات التعريفية لـ S3. في الإصدار الأول، ذهب البرنامج الخفي S3 إلى قاعدة البيانات هذه للحصول على البيانات الوصفية، وتم تخزين المحتوى نفسه في مساحة تخزين كبيرة عبر Streamer.
Nginx + S3 API + البيانات الوصفية
نموذج تخزين الكائنات
دعونا نرى كيف يعمل S3. يمكن للمستخدم إنشاء دلو - مجموعة من الكائنات. تتم معالجة المجموعة باسم المضيف وهي مجال فرعي للخدمة. داخل دلو، يمكن للمستخدم إنشاء كائنات. سيكون معرف الكائن هو عنوان URL. محتوى الكائن عبارة عن فقاعة، وهي عبارة عن مجموعة من البيانات الثنائية التي سنقوم بتخزينها في وحدة التخزين. يحتوي الكائن أيضًا على سمات: الاسم - نفس عنوان URL، وACL (قائمة التحكم في الوصول)، وسمات إضافية أو تعسفية أخرى - يتم تخزين كل هذا في البيانات الوصفية.
قد يبدو الرسم التخطيطي المعياري لهذه البيانات كما يلي: هناك مشاريع تمتلك مجموعات، والتي تمتلك كائنات، ويمكن أن تكون الكائنات مركبة. نظرًا لأن إحدى الطرق التي يمكن من خلالها تحميل الكائن على أجزاء، يوجد جدولان مساعدان للتحميل: التحميلات والأجزاء. تتمتع المشاريع أيضًا ببيانات اعتماد الوصول والفواتير.
مخطط البيانات
نظرًا لأننا كنا نقدم خدمة b2b مع إمكانية الوصول المدفوعة، فقد تطلب هذا النظام الفوترة.
قمنا أيضًا بتنفيذ خدمة الفوترة على Tarantool.
تحسينات على تخزين S3: خطوات نحو الإنتاج
لقد قمنا بالفعل بإنشاء نموذج عمل يمكن استخدامه: تم تخزين الكائنات والبيانات الوصفية، ولكن كانت هناك عدة نقاط مفقودة لبدء الإنتاج.
أولاً، نظام حدود الأسعار. إذا بدأنا الخدمة بدونها، فعند ذروة التحميل يمكننا أن نثقل كاهل أي جزء من النظام بشكل غير متوقع. يجب أن يعمل حد المعدل على النحو التالي: يأتي أي طلب S3 إلى مضيف معين، وهذا المضيف هو معرف الحاوية، والدلو ينتمي إلى بعض العملاء. نحن بحاجة إلى تحديد بعض الوظائف من المجموعة التي من شأنها أن تسمح لنا بحساب حد المعدل.
بالإضافة إلى ذلك، يجب أن يكون نظام حد المعدل قويًا بما يكفي للتعامل مع الحمل الذي يأتي إلى S3.
هنا استخدمنا Tarantool مرة أخرى. حدود المعدل عبارة عن مجموعة مكونة من 21 مثيلًا، ويتم تقسيم المثيلات إلى مجموعات، وفصلها إلى ثلاث عقد مادية ودمجها في مجموعة طوبولوجية كبيرة. يتم نشر تغييرات التكوين تلقائيًا من خلاله: يتم تعيين حدود المعدل والإعدادات الافتراضية والتكوين. يتم تقديم كل مجموعة بواسطة مثيل واحد فقط. عندما يصل طلب لحاوية معينة، يتم حساب المثيل المسؤول عن هذه الحاوية. داخل هذه العقدة، يتم حساب المعدل الحالي للطلبات باستخدام خوارزمية مشابهة لـ Token Bucket. بعد ذلك، يوضح نظام حد المعدل، استنادًا إلى مؤشرات التحميل الحالية والخصائص المحددة لحاوية معينة، ما إذا كان يمكن تلبية الطلب أم لا. يتم إجراء فحص الحدود في المرحلة الأولى من طلب S3، مما يحمي جميع العناصر الأخرى للنظام من التحميل الزائد.
أيضًا ، من الصعب جدًا الاستغناء عن ذاكرة التخزين المؤقت أثناء التحميل. يتضمن S3 الوصول المتكرر إلى نفس الكائنات، أي أنه مخزن ساخن. في الحالة المعتادة، يتم الوصول إلى ملف واحد من خلال سلسلة كاملة: Streamer، FileDB، PairDB، Storage. ولكن عند الوصول إلى ملف عدة مرات، نقوم بتحسين الوصول إلى هذا المحتوى باستخدام ذاكرة تخزين مؤقت محلية.
ذاكرة التخزين المؤقت متعددة الطبقات ويتم تنفيذها باستخدام أقراص nginx والمحلية وSSD وRAM. هنا لم نستخدم Tarantool، لأنه أكثر ملاءمة لخدمة الكائنات من نظام الملفات، حتى نتمكن من القيام بطبقات ذاكرة التخزين المؤقت. بالإضافة إلى ذلك، لدينا كائنات كبيرة يصل حجمها الأقصى إلى 32 غيغابايت، ويمكن لـ Tarantool تخزين الكائنات الصغيرة فقط.
كان لهذا النظام الأول الذي أطلقناه بعض القدرة المحسوبة، وكانت كافية للبحث وفهم المنتج حتى ينجح.
تحسينات على نظام القتال: تجاوز الفشل والقياس
كان النظام قيد التشغيل بالفعل، ولكن في البداية فاتنا شيئًا ما - كنا بحاجة إلى إضافة تجاوز الفشل وتوسيع نطاقه.
قام برنامج S3 الخاص بنا باسترداد البيانات الوصفية باستخدام بروتوكول Tarantool. بدلاً من قاعدة البيانات الأصلية، قمنا بتثبيت Tarantool، الذي كان بمثابة جهاز توجيه وكيل لطلبات البيانات الوصفية. من وجهة نظر التطبيق الذي ينفذ واجهة برمجة التطبيقات (API)، لم يتغير شيء - فقد استمر في الوصول إلى قاعدة البيانات باستخدام بروتوكول Tarantool، لكن جهاز التوجيه كان قادرًا على توفير تجاوز فشل نشط. أي أننا تمكنا من التحقق من توفر العقدة، والإيقاف المؤقت أثناء التبديل والفشل، وما إلى ذلك. ومع ذلك، لم نقوم بتعديل التطبيق نفسه.
تعرف على المزيد حول كيفية تنفيذنا لعملية التقسيم
كانت المشكلة التالية التي كان علينا القلق بشأنها هي المشاركة. كان النظام ينمو، وكان عدد الكائنات ينمو، وكان من الضروري توفير فرص لمزيد من النمو.
دعنا نعود إلى مخطط البيانات: هناك مشاريع وهناك دلاء وقروض وفواتير. هذه هي الكائنات التي، مع احتمال كبير، في المستقبل المنظور لن تتجاوز حدود مثيل واحد، سواء من حيث الحجم أو من حيث الطلبات. وهذا يعني أنه لا فائدة من تقسيمها، وقمنا بنقلها إلى نسخة منفصلة، والتي ستبقى دون تقسيم. يتيح ذلك إدارة أكثر اتساقًا للمشروعات والدلاء نظرًا لوجود نقطة واحدة غير مجزأة.
يوجد أيضًا في المخطط كائنات تنمو خطيًا - في البداية كان هناك مئات الآلاف منها، والآن يتم قياس عددها بعدة مليارات. كان لا بد من أخذ مثل هذه الأشياء، مع أجزائها، في كتلة مجزأة.
لقد قمنا بتقسيم المخطط، لكن الكائنات تحتاج إلى العمل مع الدلاء: ينتمي الكائن دائمًا إلى دلو محدد، بالإضافة إلى أن قائمة التحكم بالوصول (ACL) تعمل على الدلو. لذلك، بالنسبة لكل جزء من الكائن، نحتفظ بنسخة ظلية من كل مجموعة. بالإضافة إلى ذلك، أثناء تعديل الكائنات وتنفيذ الاستعلامات، تحتاج إلى حساب الحجم لإجراء إعداد الفواتير، بحيث يكون لكل جزء عدادات إعداد فواتير.
أضفنا أيضًا العديد من الجداول والمكونات:
- سلة المهملات لتدمير المشاريع القديمة التي تم حذفها أو تجميدها؛
- قائمة انتظار لمهام الخلفية، أي أن وحدة التخزين الرئيسية يمكنها تنفيذ مهام الخلفية التي يجب القيام بها على المجموعة؛
- دعم دورة الحياة - آلية تسمح لك بالعمل مع الكائنات وإدارة دورة حياتها.
نظرًا لأننا قمنا بنقل بعض البيانات إلى أجزاء، فقد كنا بحاجة إلى وكيل مشاركة. سيكون من الممكن إعادة استخدام جهاز التوجيه لهذا الدور، ولكن وكيل المشاركة المنفصل، المسؤول فقط عن تقسيم البيانات، يسمح لك بجلب البيانات بالكامل من جهاز التوجيه دون التفكير في التجزئة.
سأخبرك بشكل منفصل لماذا لم نتخذ حلاً جاهزًا، ولكننا أردنا إنشاء وظيفة تقسيم مخصصة.
دعونا نرى كيف يعمل. لدينا 256 قطعة متاحة. لكل مجموعة، نختار نطاقًا باستخدام دالة تناسق معينة. الأمر بسيط - تمامًا كما تستخدم دالة الاتساق لتحديد ما إذا كنت تنتمي إلى جزء واحد، فإنك تحدد جزء البداية وتحدد نطاقًا:
f(bucket, shards) = subset
وهذا يعني أنه إذا أخذت دلوًا، فيمكنك القول إنه وبياناته ستقع دائمًا على مجموعة فرعية محددة من جميع الأجزاء. يتيح لك هذا تقليل تأثير بعض المجموعات على مجموعات أخرى وتبسيط عمل استعلامات تقليل الخريطة عندما تحتاج، على سبيل المثال، إلى إدراج كائنات المجموعة. للقيام بذلك، تحتاج إلى استقصاء جميع الأجزاء التي تم تخزين هذه الكائنات فيها. إذا تم تحديد موقع الكائنات في جميع الأجزاء، فإن أي قائمة ستؤثر على النظام بأكمله، ولكنها هنا تؤثر فقط على مجموعة فرعية محددة.
بعد ذلك، ينتمي كل كائن إلى مجموعة محددة، لذلك عندما نصل إلى كائن، فإننا نصل إلى الكائن بالاسم في مجموعة محددة. أي أنه يمكننا تحديد دالة لكائن ما ليس من النطاق الكامل للأجزاء المتاحة، ولكن فقط من مجموعة فرعية من مجموعته:
f(object, subset) = shard
نحن نأخذ كائنًا محددًا، ولا نمرر كل الأجزاء هناك كوسيطات وظيفية، ولكن مجموعة فرعية من دلوها - ونحصل على جزء محدد.
لذلك، يتم تنفيذ التقسيم، ويوجد وكيل للمشاركة. ثم كل ما تبقى هو الانتقال من جهاز التوجيه وقاعدة البيانات التي تحتوي على بيانات التعريف إلى وكيل المشاركة. على سبيل المثال، لإنشاء كائنات نسخة احتياطية - عندما نقوم بإنشاء مجموعة، يجب على وحدة التخزين الرئيسية إنشاء ممثل لهذه المجموعة على جميع الأجزاء التي يجب أن تكون موجودة فيها.
كيف قمنا بتنفيذ إعادة التصميم
أكبر مشكلة في المشاركة هي إعادة المشاركة. وكان من المهم بالنسبة لنا أن نقوم بذلك دون توقف، حيث أن النظام كان قيد الإنتاج بالفعل. سأوضح لك كيف قمنا بحل المشكلة باستخدام مثال لمشكلة مماثلة تتعلق بترحيل البيانات المباشرة من مشروع إلى آخر.
يوجد أدناه رسم تخطيطي لمجموعتنا، والتي ظهرت بعد تقديم التقسيم. لدينا nginx وS3 API وجهاز توجيه وقاعدة بيانات أساسية تحتوي على المشاريع ووكيل المشاركة والأجزاء نفسها
أعلاه، فاتني نقطة أنه في مرحلة معينة من المشروع كانت هناك مهمة منتج: "إطلاق منشأة تخزين أخرى، Icebox، مثل Hotbox، فقط للبيانات الباردة." نفس مساحة التخزين بشكل أساسي، ولكن على عناوين URL مختلفة وبدون ذاكرة تخزين مؤقت.
تم استخدام Icebox بشكل أقل من Hotbox، لذلك استمر لفترة طويلة دون أي تقطيع. في النهاية، قررنا التخلي عنها ودمج Hotbox و Icebox في خدمة واحدة، مع فصل فئات التخزين ببساطة.
لم تتداخل الدلاء الموجودة في المخازن، ويمكن دمجها ونقلها بسهولة، لكن العملاء استخدموا كلا مرافق التخزين، مما يعني أنه كان لا بد من حل مشكلة قلة وقت التوقف عن العمل. لا يمكنك فقط إيقاف تشغيله ونسخه. لقد قمنا بالهجرة على عدة مراحل.
في البداية، قمنا بمزامنة المخازن الأساسية. كان لدينا Tarantool وعند إنشاء كائن يمكننا القيام بذلك:
- يأتي طلب إلى قاعدة البيانات لإنشاء مجموعة، على سبيل المثال في Hotbox؛
- يتحقق Tarantool في قاعدة بيانات أخرى (في هذه الحالة، Icebox) من عدم وجود مثل هذه المجموعة؛
- إذا كان هناك دلو، تقول قاعدة البيانات أنه لا يمكن إنشاؤه، وتتم مزامنته على أنه موجود.
مزامنة دلو
في منشأة التخزين، التي كان من المفترض أن تتلقى جميع البيانات، تم وضع علامة للمشاريع والدلاء تشير إلى مكان تخزين هذا الكائن. يمكن تخزينه محليًا، أي في Hotbox، Icebox - ثم لا توجد بيانات منه في وحدة التخزين الجديدة، أو قد يكون في حالة ترحيل.
إذا كان المشروع أو الحاوية تحتوي على علامة الترحيل، فسيتم تنفيذ الطلب أثناء الترحيل أولاً إلى وحدة التخزين الجديدة التي يجب أن توجد فيها البيانات، وإذا لم تكن موجودة، فسيتم إعادة توجيه الطلبات إلى وحدة تخزين بديلة.
بعد ذلك قمنا بتبديل حركة المرور. نظرًا لأن واجهة برمجة التطبيقات (API) يمكن أن تخدم طلبات Icebox وHotbox، فقد تمكنا من تبديل حركة المرور دون توقف عن العمل ببساطة عن طريق نقل المضيفين وإضافة الإدخالات المناسبة في Nginx.
بمجرد إعادة توجيه حركة المرور، يمكن إزالة Nginx وIcebox API.
ثم قمنا بإزالة Icebox nginx وS3 API - وعمل كل شيء على ما يرام:
بعد ذلك، أطلقنا عملية ترحيل الخلفية التي تعمل داخل قاعدة البيانات - فهي تمر عبر جميع المشاريع ومجموعاتها عنصرًا تلو الآخر، وتعيين علامة الترحيل لها، وتنقل البيانات، وبعد الانتهاء من النقل، تقوم بتعيين العلامة المحلية.
بعد ترحيل البيانات، لم نعد بحاجة إلى التخزين القديم، ونقوم بإزالة الأجزاء المتبقية من النظام القديم، ونزيل أيضًا دعم حالة الترحيل من الكود.
تم تنفيذ إعادة التجزئة من وحدة التخزين القديمة إلى وحدة التخزين المجزأة باستخدام نفس المبادئ:
- تم وضع علامة على جميع الدلاء على أنها
Non-sharded. ذهبت جميع الطلبات المقدمة إليهم إلى وحدة التخزين الأصلية غير المجزأة. - تم إنشاء مجموعات جديدة على الفور في الحالة
Sharded. - أخذوا الدلاء واحدًا تلو الآخر وحددوا الوضع
Migratingونقل البيانات.
تمت تلبية الطلبات وفق المبدأ التالي:
- نقرأ في الجديد ثم في القديم.
- نحن نخلق فقط في الجديد.
- نقوم بالتحديث على مرحلتين: إذا لم يكن في الجديد ننقله من القديم إلى الجديد ثم نقوم بتحديثه.
العمل مع شهادات SSL
في الواجهة الأمامية نستخدم Nginx. في حالتنا، هذا ليس Nginx عاديًا، ولكنه OpenResty وNginx بدعم LuaJIT.
جزء آخر من النظام يعمل مع شهادات SSL. في تخزين S3، يمكنك تعيين المجال الخاص بك للوصول إلى مجموعة معينة، وذلك ببساطة عن طريق استخدام CNAME. لكن اليوم لا يمكنك الاستغناء عن HTTPS: المجال الخاص بك يعني شهادة SSL الخاصة بك.
كما قلت من قبل، Nginx هو المسؤول عن موازنة وإنهاء SSL. في حالتنا، هذا ليس Nginx عاديًا، ولكنه OpenResty وNginx بدعم LuaJIT.
سمح لنا هذا بتعليم Nginx كيفية إصدار شهادات عشوائية بسهولة تامة. علاوة على ذلك، كنا بحاجة إلى إصدار الشهادات ديناميكيًا (دون الحاجة إلى تسجيلها في ملف التكوين). استخدمنا الامتداد ssl_certificate_by_lua، والذي يسمح لك بقراءة شهادة من مصدر عشوائي مباشرة أثناء مصافحة TLS. استخدمنا أيضًا Tarantool كمخزن شهادات: يتيح لك هذا إدارة الشهادات خارجيًا ويوفر نتائج سريعة للغاية.
تم أيضًا تنفيذ برنامج خفي منفصل، وتتمثل مهمته في تحديث الشهادات الصادرة بانتظام باستخدام Let's Encrypt.
ما الذي سأحتفظ به وما الذي سأفعله بشكل مختلف إذا قمت بتطوير المستودع من الصفر؟
ما كان ينبغي استخدامه منذ البداية
التقسيم على الفور. تسبب إعادة التصميم في الكثير من المشاكل. من السهل القيام بذلك، ولكن، مع ذلك، إذا بدأت المشاريع التي تحتاج إلى توسيع نطاقها، فمن الأفضل أن تأخذ على الفور مجموعة مجزأة، حتى مع الحد الأدنى من العقد. يعد تنفيذ التجزئة في البداية مجانيًا تقريبًا مقارنة بإدخال التجزئة في نظام الإنتاج.
العمل مع Tarantool من خلال الموازنات. نقوم الآن بربط جميع قواعد البيانات الجديدة على الفور للعمل من خلال الموازنات. يسمح لك هذا بتوسيع الوظائف وتحقيق قدر أكبر من التسامح مع الأخطاء.
تجاوز الفشل التلقائي. سأقوم بتثبيت جميع الأدوات المطلوبة لتجاوز الفشل التلقائي، حيث أن حالات الفشل الأولى بعد الإطلاق كانت مرتبطة بغيابها. وبعد تجربة S3، تم إطلاق جميع المنتجات اللاحقة مع وضع ذلك في الاعتبار.
ميزة S3 "إصدار". في البداية بدا أن هذه لم تكن وظيفة شائعة جدًا. ومن الصعب للغاية دمج هذه الإمكانية في بنية نظام التشغيل.
فواتير منفصلة. لقد نجحت الطريقة التي قمنا بها في دمج الفوترة في نظامنا بشكل جيد في البداية، لكنها بدأت تتدخل لاحقًا؛ وكان من الأفضل أن تكون بمثابة خدمة منفصلة تمامًا.
ما هو القرار الجيد؟
نموذج البيانات. لقد أظهر التاريخ أنه مع تطور الخدمة، فإننا نطابق بشكل وثيق نموذج بيانات أمازون، حتى نتمكن من تنفيذ الميزات الموجودة هناك.
مخطط المشاركة. سأدعم نفس تقسيم النطاق عبر المجموعات، حيث يسمح ذلك بتوزيع الطلبات من مجموعات مختلفة بشكل جيد عبر مجموعة كبيرة.
باستخدام تارانتوول. لقد ساعد Tarantool كثيرًا في تطوير الخدمة وتعديلها، حيث تعاملنا بسهولة مع البيانات، وقمنا بتحويل مساحة التخزين وتقسيمها، دون الحاجة إلى الانتقال إلى طبقة التطبيق.
تم تقديم هذا التقرير لأول مرة في بواسطة Mail.ru Cloud Solutions & Tarantool. ينظر العروض الأخرى والاشتراك في إعلانات الأحداث في Telegram .
يمكنك أيضًا مشاهدة تقريري القديم عن S3 أو قراءة مقال زميلي حول تخزين الكتل.
- .
- .
المصدر: www.habr.com
