القدرة على التخطيط لقواعد البيانات

ملاحظة: هذا المنشور مستوحى من منشور Julia Evans الأخير حول تخطيط السعة.

RDBMS

أولاً ، دعنا نضع بعض القواعد الأساسية. نعم ... هذا المنشور موجه لأولئك منا الذين يستخدمون MySQL مع كاتب واحد في كل مرة ونسختين متماثلتين أو أكثر للقراءة. ينطبق الكثير مما سأتحدث عنه هنا بشكل مختلف ، أو لا ينطبق على الإطلاق ، على مجموعات البيانات العنقودية متعددة الكتاب ، على الرغم من أن هؤلاء يأتيون أيضًا مع مجموعة التنازلات والمحاذير الخاصة بهم. لذلك ... سوف تختلف المسافة المقطوعة الخاصة بك بالتأكيد.

ومع ذلك ، سيتم تطبيق منشور المدونة هذا بغض النظر عما إذا كنت تستخدم مضيفين فعليين مستضافين ذاتيًا أو في AWS حيث يمكنك استخدام مثيلات محجوزة تشبه السحر والتزويد شبه الفوري. لن يمنعك التواجد في "السحابة" من معرفة قدرات وحدود البنية التحتية الخاصة بك ولن يعفيك من هذه المسؤولية تجاه فريقك وعملائك.

التشرذم

لقد قمت بالفعل بتغطية ضربات كبيرة لهذا في إحدى مشاركاتي السابقة ، وركزت في الغالب هناك على فوائد التجزئة الوظيفية أو الأفقية. نعم ، هذا مطلب أساسي مطلق ، لأن ما تستخدمه للوصول إلى طبقة قاعدة البيانات سيقرر مقدار المرونة التي لديك لتوسيع نطاقها.

إذا كنت شركة جديدة تمامًا ، فقد لا تحتاج إلى تجزئة وظيفية في اليوم الأول ، ولكن إذا كنت تأمل (وأظن أنك تفعل ذلك) لتنمو ، فلا تحاصر نفسك باستخدام ORM مفتوح المصدر لا يسمح لك بالتقسيم بياناتك على أساس وظيفي أسفل الخط. نقاط المكافأة إذا لم تبدأ شركتك أيضًا بكل بياناتك العلائقية في مخطط واحد.

القدرة على تقسيم القراءة والكتابة

هذا شيء ستحتاج إلى أن تكون قادرًا على القيام به ، ولكن ليس بالضرورة فرضه كقاعدة ثابتة. ستكون هناك حالات استخدام حيث يلزم قراءة الكتابة بعد فترة وجيزة جدًا وحيث يكون التسامح مع أشياء مثل التأخر / التناسق النهائي منخفضًا. لا بأس في الحصول عليها ، ولكن في نفس التطبيقات ، سيكون لديك أيضًا سيناريوهات للقراءات التي يمكن أن تتسامح مع فترة زمنية أطول من الاتساق النهائي. عندما تكون هذه القراءات كبيرة الحجم ، هل تريد حقًا نقل هذا الحجم إلى كاتبك الوحيد إذا لم يكن مضطرًا لذلك؟ تفضل لنفسك ، وتأكد قريبًا في أيام نموك من أنه يمكنك التحكم في استخدام عنوان IP للقراءة أو الكتابة في التعليمات البرمجية الخاصة بك.

الآن في عملية التفكير لتخطيط السعة الفعلية ... مجموعة قواعد البيانات لا تواكب ، ماذا أفعل؟

تحديد عنق الزجاجة للنظام

• هل تعاني من اختناق في الكتابة أو القراءة؟
• هل المشكلة تظهر على أنها وحدة معالجة مركزية عالية؟
• هل يتم عرضه كقدرة IO؟
• هل هو تأخر متزايد في النسخ المتماثلة بدون وجود استعلام قراءة واضح الجاني؟
• هل هو أقفال؟
• كيف أعرف حتى ما هو؟

كل من هؤلاء يمكن أن يكون منشورًا بمفرده. النقطة التي أحاول توضيحها هي أنه يجب أن تكون على دراية بنظامك والمقاييس الخاصة بقاعدة البيانات لتتمكن من معرفة القطعة التي تمثل عنق الزجاجة.

أنت بحاجة إلى خط الأساس

تأكد دائمًا من توفر مقاييس النظام الأساسية لتصورها لبضعة أسابيع على الأقل. توفر العديد من الأدوات ذلك (الصبار ، مونين ، الجرافيت ... إلخ). بمجرد أن تعرف مقياس النظام الذي تلتزم به في الغالب ، فإنك تحتاج إلى إنشاء قيم أساسية وقيم ذروة. بخلاف ذلك ، فإن تحديد ما إذا كانت مشكلتك الحالية عبارة عن خطأ جديد مصدره تطبيق مقابل النمو الحقيقي سيكون أكثر عرضة للخطأ مما تريد.

ومع ذلك ، يمكن لمقاييس الخادم الأساسية أن تصل إلى هذا الحد فقط - في مرحلة ما ستجد أنك بحاجة أيضًا إلى مقاييس تستند إلى السياق. سيخبرك أداء الاستعلام والأداء المدرك من جانب التطبيق بما يراه التطبيق على أنه وقت استجابة للاستفسارات. هناك العديد من الأدوات للقيام بهذا التتبع الكثيف للسياق. بعضها مفتوح المصدر مثل مقياس شدة الريح وأدوات تجارية مثل Vivid Cortex (نستخدمها في SendGrid. شاهدنا نتحدث عنها هنا.) حتى مجرد تتبع هذه المقاييس من منظور التطبيق ورميها كمقاييس statsd سيكون خطوة أولى جيدة. ولكن ، في وقت مبكر ، يجب أن تعتاد على حقيقة أن ما يدركه تطبيقك هو ما يدركه عملاؤك. ويجب أن تجد طريقة لتعرف أولاً.

تعرف على أنماط حركة المرور الخاصة بشركتك

هل أنت شركة عرضة لذروة قصوى في أيام الأسبوع المحددة (مثل التسويق)؟ هل لديك عمليات إطلاق منتظمة تضاعف ثلاث مرات أو أربع مرات حركة المرور الخاصة بك مثل الألعاب؟ ستحدد هذه الأنواع من الأسئلة مقدار الارتفاع المحجوز الذي يجب أن تحتفظ به أو ما إذا كنت بحاجة إلى الاستثمار في النمو المرن.

تحديد نسبة أرقام حركة المرور الأولية بالنسبة للسعة المستخدمة

هذه هي الإجابة ببساطة على ، "إذا لم نجري تحسينات على الكود ، فكم عدد رسائل البريد الإلكتروني / المبيعات / المستخدمين عبر الإنترنت / أيًا كان" يمكننا تقديمها مع مثيلات قاعدة البيانات المتوفرة لدينا الآن؟

من الناحية المثالية ، هذه قيمة محددة تجعل الرياضيات نحو التخطيط للنمو لمدة عام معادلة رياضية بسيطة. لكن الحياة ليست مثالية أبدًا وستختلف هذه القيمة وفقًا للموسم أو عوامل السعادة الخارجية تمامًا مثل الاشتراك في عميل رئيسي جديد. في الشركات الناشئة المبكرة ، يعتبر هذا الرقم هدفًا متحركًا بشكل أسرع ، لكن يجب أن يستقر مع انتقال الشركة من الأيام الأولى إلى الأعمال التجارية الأكثر رسوخًا مع أنماط نمو أعمال أكثر قابلية للتنبؤ بها.

هل أحتاج حقًا إلى شراء المزيد من الآلات؟

أنت بحاجة إلى إيجاد طريقة لتحديد ما إذا كانت هذه سعة فعلية - أحتاج إلى تقسيم عمليات الكتابة لدعم تحميل أكثر تزامنًا للكتابة أو إضافة المزيد من النسخ المتماثلة للقراءة - مقابل. عنق الزجاجة القائم على الكود (يمكن لهذا الاستعلام الجديد من نشر حديث أن يتم تخزين نتائجه مؤقتًا في شيء أرخص ولا يتغلب على قاعدة البيانات بنفس القدر).

كيف تفعل ذلك؟ تحتاج إلى التعرف على استفساراتك. الخطوة الصغيرة لذلك هي مزيج من innotop ، والسجل البطيء ، و Percona Toolkit's pt-query-Digest. يمكنك أتمتة ذلك عن طريق شحن سجلات قاعدة البيانات إلى موقع مركزي وأتمتة جزء الملخص.

ولكن هذه ليست الصورة الكاملة أيضًا ، فالسجلات البطيئة تتطلب أداءً مكثفًا إذا خفضت حدها كثيرًا. إذا كان بإمكانك التعايش مع أخذ عينات أقل انتقائية ، فستحتاج إلى اكتشاف المحادثات الكاملة بين التطبيق ومخزن البيانات. في الأراضي مفتوحة المصدر ، يمكنك الانتقال إلى المستوى الأساسي مثل tcpdump أو يمكنك استخدام المنتجات المستضافة مثل Datadog أو New Relic أو VividCortex.

إجراء مكالمة

يمكن أن يكون تخطيط السعة 90٪ علمًا و 10٪ فنًا ، لكن 10٪ لا ينبغي أن تعني أننا لا يجب أن نسعى جاهدين للحصول على أكبر قدر ممكن من الصورة. بصفتنا مهندسين ، يمكننا أحيانًا التركيز على نسبة 10٪ المفقودة وعدم إدراك أنه إذا قمنا بالعمل ، فإن 90٪ يمكن أن يوصلنا بعيدًا إلى فكرة أفضل عن صحة مجموعتنا ، واستخدام أكثر كفاءة لوقتنا لتحسين الأداء ، وقدرة التخطيط بعناية مما يؤدي في النهاية إلى عائد استثمار أفضل لمنتجاتنا.