إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
غيرت الحوسبة السحابية بشكل كبير مشهد استضافة قواعد البيانات. يمنح الفرق إمكانية الوصول إلى قابلية التوسع، والمرونة، والوصول العالمي، وقدرات لم تكن متاحة سابقا. بدلا من تحمل تكاليف كبيرة وعبء تشغيلي من خلال التخطيط لأكبر عبء عمل ممكن (وتحمل هذه التكلفة من اليوم الأول)، يمكن للفرق الآن تحسين التكاليف حول النطاق الدقيق الذي تحتاجه، ومتى يحتاجه، والتعديل مع تغير طلباتهم.
مقدمة
المرونة في اختيار التوازن المناسب للموارد ذات قيمة خاصة في عمليات نشر قواعد بيانات PostgreSQL. قد تبدأ أعباء عمل قاعدة بيانات PostgreSQL صغيرة، وتنمو بسرعة، وتتزداد بشكل موسمي، أو تتحول من كثافة القراءة إلى الكتابة الثقيلة، أو تتطور من أعباء عمل المعاملاتية إلى أنظمة تشغيلية وتحليلية هجينة في الوقت الحقيقي. تضمن قاعدة بيانات Azure لـ PostgreSQL تحقيق حلولك أهدافك من خلال تقديم مجموعة واسعة من الخيارات في مجالات الحوسبة، والتخزين، والتوفر، والتكرار، والأمان، والنسخ الاحتياطي، وإدارة العمليات.
لكن مع كل هذه القوة تأتي المسؤولية، خاصة عند التخطيط لنشراتك. لتحقيق أفضل أداء ممكن، يجب أن تتوافق قرارات النشر الخاصة بك مع متطلبات عبء العمل العام لديك.
نجاح نشر قاعدة بيانات Azure لقاعدة بيانات PostgreSQL ليس مجرد اختيار "أكبر عدد من الأنوية والذاكرة التي نحتاجها." بدلا من ذلك، يأتي الأداء التشغيلي الأقصى من فهم سلوكيات تطبيقك، وسلوكيات العملاء، وخصائص الحوسبة، والتخزين، ونمو قاعدة البيانات، وكيفية تداخل هذه الخصائص وتتفاعلها.
أفضل عمارة هي التي يتم فيها محاذاة هذه القطع عمدا.
تخطيط أداء السحابة هو مسؤولية مشتركة
واحدة من الفوائد الرئيسية للانتقال إلى منصة سحابية موثوقة هي نموذج المسؤولية المشتركة. توفر Microsoft البنية التحتية العالمية، والخدمات المدارة، وابتكار الأجهزة، والموثوقية، والأمان، والهندسة التشغيلية. تقدم فرقك خبرة في سياق التطبيق المحدد: أهمية الأعمال، سلوك عبء العمل، تصميم نموذج البيانات، ملف حركة المرور الشبكية، توقعات النمو، أهداف الاسترداد، ومتطلبات تجربة المستخدم النهائي.
أقوى النتائج تظهر عندما تتحد هاتان القوتان.
يوفر Azure بنية تحتية قابلة للتوسع عالية في Postgres، لكن يجب على فريقك أن يقدم رؤى لهذه المجالات:
- كم عدد المستخدمين المتزامنين المتوقع خلال الفترات العادية وذروتها؟
- هل العمليات الأهم تعتمد على القراءة بشكل كبير، أو الكتابة الثقيلة، أم مختلطة؟
- هل يرتفع الطلب خلال نهاية الشهر، أو نهاية الربع، أو العطلات، أو الإطلاقات، أو فترات التقارير؟
- ما مدى سرعة نمو مجموعة البيانات؟
- أي العمليات حساسة لزمن الكمون؟
- أي الاستفسارات أو الوظائف يمكنها تحمل فترات تشغيل أطول؟
- هل عبء العمل يعتمد بشكل أساسي على OLTP أو OLAP أو هجين؟
- هل العملاء موجودون بالقرب من منطقة قاعدة البيانات، أو موزعون عالميا، أم يتركزون في منطقة جغرافية واحدة؟
سجل هذه التفاصيل قبل النشر، وليس بعد حادثة إنتاج. النشر السحابي يجعل التوسع أسهل، لكن التصاميم الأعلى أداء والأكثر كفاءة من حيث التكلفة تبدأ بجمع متطلبات سليم وتخطيط مناسب. في معظم الحالات، يمكن تلخيص هذه الأسئلة إلى العلاقات عبر الاتصالات المتزامنة، وأقصى IOPS، ومعدل النقل المطلوب.
الأداء له طبقات متعددة
نادرا ما يتم تحديد أداء قاعدة البيانات بواسطة إعداد واحد. تعتمد تجارب النشر الناجحة على عدة طبقات تعمل معا:
-
أداء طبقة التطبيق.
تشمل هذه الطبقة كود التطبيق، أنماط الاستعلام، تغطية الفهرس، استخدام المشغلات، تقسيم البيانات، معالجة الاتصال، التخزين المؤقت، منطق إعادة المحاولة، التجميع، سلوك ORM، تصميم المعاملات، وسلوك الوظائف الخلفية. -
أداء طبقة العميل والشبكة.
تشمل هذه الطبقة مواقع وجود العملاء، وكيفية اتصالهم، وما إذا كانت الطلبات تعبر المناطق ومناطق التوفر، وكمون الشبكة، وحمل TLS، وتغير الاتصال، وما إذا كان التطبيق يستخدم تجميع الاتصالات بكفاءة. -
أداء منصة قاعدة البيانات.
تشمل هذه الطبقة تكوين نشر Postgres، حجم الحوسبة، الذاكرة، وحدة المعالجة المركزية، نوع التخزين، حجم التخزين، IOPS للتخزين، معدل نقل التخزين، التوافر العالي، النسخ المقلدة، وعمليات الصيانة.
تركز هذه المقالة بشكل أساسي على الطبقة الثالثة: تخطيط نشر قاعدة بيانات Azure Postgres بحيث تدعم خيارات الحوسبة والتخزين ملف الأداء المطلوب.
توفر قاعدة بيانات Azure لـ PostgreSQL مرونة، لكن التخطيط ضروري
يوفر قاعدة بيانات Azure لـ PostgreSQL Flexible Server مجموعة واسعة من خيارات النشر، بما في ذلك:
| منطقة الانتشار | الخيارات المتاحة |
|---|---|
| Compute | مستويات الحوسبة، أجيال الآلة الافتراضية (VM)، تكوينات الأغراض العامة، وتكوينات الذاكرة المحسنة. |
| Storage | قرص Azure Premium SSD v1، Premium SSD v2، تكبير التخزين، تكوين IOPS، وتكوين معدل النقل. |
| التوافر | توفر العالية، والنسخ الاحتياطي والاستعادة، والنسخ الاحتياطية الجغرافية في التكوينات المدعومة. |
| النسخ المتماثل | اقرأ النسخ المقلدة والنسخ الجغرافية. |
| Security | مفاتيح يديرها العملاء وتكامل أمان المؤسسات. |
هذه المرونة قوية لأن أحمال العمل المختلفة تتطلب قدرات مختلفة. النظام المعاملاتي الذي يعتمد على الكتابة بشكل كبير لا يحتاج إلى نفس الملف الشخصي الذي يحتاج إلى نظام يعتمد على التقارير الثقيلة. تطبيق SaaS العالمي لا يحتاج إلى نفس التصميم مثل التطبيق الإقليمي الداخلي. قاعدة البيانات التي تنمو 5% سنويا لا تحتاج إلى نفس خطة التخزين التي تنمو 200% شهريا.
هدف التخطيط هو تحديد احتياجات ملف أداء عبء العمل الخاص بك، ثم تنفيذ الخيارات الصحيحة عبر خيارات الحوسبة والتخزين لتقديم حلولك الشاملة بنجاح.
ابدأ بملف عبء العمل
قبل اختيار الحوسبة أو التخزين، حدد عبء العمل. تشمل أبعاد التخطيط المفيدة:
| منطقة التخطيط | أسئلة يجب الإجابة عليها |
|---|---|
| الجغرافيا | أين تقع المستخدمون، التطبيقات، النسخ المقلدة، والتكاملات؟ |
| Concurrency | كم عدد الاتصالات المتزامنة والاستعلامات النشطة المتوقعة؟ |
| حجم البيانات | ما هو حجم قاعدة البيانات الحالي، وما هو معدل النمو المتوقع؟ |
| معدل التغير | ما مدى سرعة نمو البيانات شهرا بعد شهر؟ كم من سجل الكتابة المسبقة (WAL) يتم توليده؟ |
| نوع حِمل العمل | هل النظام OLTP أو OLAP يعتمد بشكل كبير على التقارير أم الدفعات أو الهجين؟ |
| مزيج القراءة/الكتابة | ما هي نسبة العمليات التي تكون قراءة وكتابة؟ |
| السلوك الذروي | هل هناك دورات أعمال متوقعة، أو ذروات موسمية، أو نوافذ دفعية؟ |
| حساسية الكمون | ما هي المعاملات التي تواجه المستخدم وتعتبر حرجة في زمن التأخير؟ |
| احتياجات النقل | هل هناك عمليات كبيرة لمسح البيانات، أو الصادرات، والاستيراد، أو عمليات استخراج وتحويل وتحميل (ETL)؟ |
| التوقعات المتوافقة | هل سيحتاج عبء العمل إلى فترات مؤقتة أم أداء أعلى مستمر؟ |
الهدف ليس التنبؤ بالمستقبل بشكل مثالي. الهدف هو تجنب التصميم بشكل أعمى.
فهم المفاهيم الثلاثة الأساسية لأداء التخزين
عادة ما يعتمد تخطيط أداء تخزين Azure على ثلاثة مفاهيم مرتبطة لكنها متميزة: IOPS، معدل النقل، وزمن التأخير. هذه العوامل أساسية لتخطيط أداء التطبيق.
عمليات الإدخال / الإخراج في الثانية (IOPS)
IOPS يعني عمليات إدخال/إخراج في الثانية. يقيس عدد عمليات القراءة أو الكتابة التي يمكن لقاعدة البيانات إرسالها إلى التخزين في كل ثانية.
يعد IOPS مهما بشكل خاص لأعباء عمل OLTP. غالبا ما تقوم هذه الأنظمة بالعديد من عمليات القراءة والكتابة الصغيرة والعشوائية، مثل الإدخالات، والتحديثات، والبحث عن الفهرس، وقراءة النقاط، والمعاملات القصيرة. قد يحتاج عبء العمل المعاملي مع آلاف المستخدمين المتزامنين إلى IOPS مرتفع حتى لو كانت كل عملية صغيرة على حدة.
تشمل السيناريوهات الشائعة الحساسة للIOPS:
- معالجة الأوامر عالية الحجم
- تحديثات ملف المستخدم
- أنظمة الجرد
- ابتلاع الأحداث
- أنظمة الدفع أو الفوترة
- تطبيقات SaaS المتزامنة للغاية
الإنتاجية
معدل النقل، الذي يسمى أحيانا عرض النطاق الترددي، يقيس مقدار البيانات التي يمكن قراءتها أو كتابتها إلى التخزين مع مرور الوقت. يتم التعبير عنها بمقاطعة MB/s.
المعدل مهم عندما تنقل العمليات كميات كبيرة من البيانات. الاستعلامات التحليلية، النسخ الاحتياطية، الاسترجاع، المهام الدفعية، بناءات الفهرس، مسح الجداول، وسير عمل ETL قد تحتاج إلى معدل نقل عالي حتى لو لم تتطلب أعلى IOPS.
السيناريوهات الشائعة الحساسة لمعدل النقل تشمل:
- الإبلاغ عن الاستعلامات عبر جداول كبيرة
- الواردات أو الصادرات بالجملة
- مسح على نمط مستودع البيانات
- عمليات النسخ الاحتياطي واستعادة
- عمليات إنشاء أو إعادة بناء المؤشرات الكبيرة
- المعالجة الدفعية
زمن الاستجابة
التأخير هو الوقت الذي يستغرقه إتمام طلب إدخال/إخراج واحد. الكمون المنخفض ضروري لعمليات قواعد البيانات الموجهة للمستخدم، خاصة عندما تكون العديد من العمليات الصغيرة متصلة معا في معاملة.
يمكن أن يكون لدى النظام IOPS نظري مرتفع لكنه لا يزال يشعر بالبطء إذا كان الكمون مرتفعا. بالنسبة لأحمال عمل Postgres، يمكن أن يؤثر زمن استجابة التخزين بشكل مباشر على أوقات استجابة الاستعلام، وسلوك الالتزام بالمعاملات، وسلوك نقاط التحقق، والاستجابة العامة للتطبيق.
Note
أقراص SSD المميزة v1 مصممة لتأخير ممللي ثانية أحادية الرقم لمعظم عمليات الإدخال/الإخراج، ومن الجدير بالذكر أن تخزين الأقراص يمكن أن يقلل أكثر من زمن الاستجابة للقراءة في تكوينات الأقراص تحت 4 تيرابايت. يوفر قرص SSD Premium v2 وUltra Disk زمن تأخير تحت المللي ثانية.
يجب النظر في IOPS ومعدل النقل والكمون معا
IOPS ومعدل النقل مرتبطان. عبء العمل الذي يصدر عدة عمليات صغيرة بسعة 8 كيلوبايت قد يؤدي إلى إخفاء IOPS مرتفع دون معدل نقل مرتفع. عبء العمل الذي يصدر عمليات متعددة ميجابايت كبيرة قد يؤدي إلى إنتاجية عالية مع IOPS أقل.
طريقة بسيطة للتفكير في الأمر:
IOPS × حجم الإدخال/الإخراج = معدل النقل
بالنسبة ل Postgres، النتيجة العملية هي أن تخطيط تخزين عبء العمل يجب أن يستند إلى سلوك عبء العمل المرصود أو المقدر، وليس حجم قاعدة البيانات فقط. على سبيل المثال:
- قد يحتاج نظام OLTP عالي التزامن إلى المزيد من IOPS وتأخير أقل.
- قد يحتاج النظام الذي يعتمد بشكل كبير على التقارير إلى معدل نقل أكبر.
- قد يحتاج النظام الهجين إلى كلا الأمرين، خاصة خلال دورات الذروة.
- قد يحتاج نظام OLTP عالي التزامن إلى المزيد من IOPS وتأخير أقل.
- قد يحتاج النظام الذي يعتمد بشكل كبير على التقارير إلى معدل نقل أكبر.
- قد يحتاج النظام الهجين إلى كلا الأمرين، خاصة خلال دورات الذروة.
خيارات النشر الخاصة بك تؤثر مباشرة على أداء التخزين
خطأ شائع هو ضبط التخزين لرقم أداء مستهدف دون التفكير الكامل فيما إذا كان جهاز SKU الخاص بالحساب الذي اخترته يمكنه تحقيق نفس مستويات الأداء.
أداء تخزين Azure له اعتبارات متعددة. تشمل هذه التفاصيل:
- مجموعة قدرات الحوسبة (أقصى IOPS للحوسبة وحدود النقل).
- جيل التخزين (SSD v1، SSD v2، Ultra Disk).
- حجم قرص التخزين (أقراص SSD v1 التي تقل عن 4096 جيجابايت تتضمن تخزين مؤقت للمضيف، مما يسمح بدفعات IOPS فوق الخطوط الأساسية القياسية).
- سعة IOPS للتخزين.
- سعة التخزين.
عمليا: سقف الأداء الفعال هو أدنى حد ذي صلة في السلسلة.
إذا كان تكوين التخزين يمكنه توفير 80,000 IOPS بينما يمكن لوحدة التخزين الحسابية تشغيل 20,000 IOPS فقط، فإن النشر لا يوفر 80,000 IOPS. وعلى العكس، إذا دعم جيل الأجهزة الافتراضية عمليات IOPS عالية لكن مستوى التخزين المختار تم تحديده أقل، يصبح مستوى التخزين هو الحد الأقصى.
يجب أن يتم التخطيط للحوسبة والتخزين معا.
قرص SSD بريميوم v1: أداء أساسي قوي مع سلوك تخزين مؤقت مهم
يعد SSD بريميوم v1 خيارا شائعا لأحمال العمل الإنتاجية من Azure Postgres التي تحتاج إلى أداء متوقع ومزود. يدعم Azure تخزين Postgres SSD v1 سعة ، وسرعة نقل
SSD المميز v1 يعمل جيدا مع أعباء العمل التي تستفيد من التخزين المؤقت للمضيف. يدعم Azure Postgres التخزين المؤقت للمضيف لأحجام أقراص SSD v1 أقل من 4,096 جيجابايت. أي قرص مزود بسعة تصل إلى 4,095 جيجابايت يمكن أن يستفيد من التخزين المؤقت للمضيف. بمجرد توفير التخزين بسعة 4,096 جيجابايت أو أكثر، لا يتم دعم التخزين المؤقت للمضيف. هذا الحد مهم. بالنسبة لنشر أقراص SSD المميزة v1 تحت 4 تيرابايت، يمكن للتخزين المؤقت تحسين أداء القراءة وتقليل تأخير القراءة. يوفر هذا التخزين المؤقت كفاءة عالية من حيث التكلفة إلى الأداء للأعباء المختلطة أو التي تتناسب تحت عتبة التخزين المؤقت.
لماذا يهم الحد الأقصى بسعة 4 تيرابايت
عندما يتجاوز نشر SSD بريميوم v1 النطاق المدعوم بالتخزين المؤقت، يمكن أن يتغير ملف الأداء:
- لم تعد Reads تستفيد من ذاكرة التخزين المؤقت للمضيف.
- تأتي عمليات القراءة الإضافية مباشرة من القرص الأساسي.
- القراءة تحتسب مقابل IOPS للقرص وحدود معدل النقل.
- قد تظهر أحباء العمل الحساسة للتأخير سلوكا مختلفا.
- قد يحتاج تكوين كان فعالا سابقا إلى IOPS أكثر مجهزة، أو زيادة معدل الإنتاجية، أو توسيع حجم الحوسبة، أو ضبط الاستعلام، أو خيار تخزين مختلف.
عبور السعة فوق 4 تيرابايت ليس سيئا، لكن يجب أن تخطط له.
إذا كنت تتوقع أن تنمو قاعدة البيانات لأكثر من 4 تيرابايت، فكر في الحالة المستقبلية أثناء تصميم البنية. تصميم يعمل جيدا عند 2 تيرابايت مع التخزين المؤقت قد يحتاج إلى خطة أداء مختلفة عند 5 تيرابايت بدون تخزين مؤقت.
Burst يساعد في تقليل الارتفاعات، لكنه لا يعوض السعة المستدامة
تخصيصات تخزين Azure Postgres Premium SSD v1 تحت 4 تيرابايت تدعم دفعات من التخزين المؤقت للمضيف، والتي يمكن أن تساعد في سيناريوهات مثل:
- نشاط الشركات الناشئة
- وظائف الدفعات القصيرة
- ارتفاعات المرور
- معالجة نهاية الشهر
- ارتفاعات مؤقتة في عبء العمل
بينما الانفجار مفيد، استخدمه بحذر. الانفجار يمكن أن يمتص ارتفاعات مؤقتة، لكنه لا ينبغي أن يكون أساسا للطلب المستمر على عبء العمل. إذا كان عبء العمل غالبا ما يتجاوز الأساسي، فمن الأفضل توفير مستوى أداء أعلى، أو تعديل إعدادات أداء التخزين، أو توسيع حجم الحساب، أو إعادة تصميم نمط عبء العمل.
سؤال تخطيطي جيد هو: هل هذا ارتفاع مؤقت، أم هو الوضع الطبيعي الجديد؟
قد تكون الارتفاعات المؤقتة مرشحة جيدة للانفجار. التعامل مع الطلب المستمر من خلال تخطيط قدرات متعمد.
SSD المميز v2 يفصل بين السعة، وIOPS، ومعدل النقل
يغير Premium SSD v2 نموذج التخطيط عن طريق فصل حجم القرص، وIOPS، ومعدل النقل. قاعدة بيانات Azure لـ PostgreSQL flexible server Premium SSD v2 يدعم:
- السعة من 32 جيجابايت إلى 64 تيرابايت.
- يصل إلى 80,000 IOPS.
- حتى 1,200 ميجابايت/ثانية .
- تعديلات السعة الدقيقة بزيادات 1 جيجابايت.
- إعدادات IOPS مرنة وتكوين معدل النقل.
- زمن استجابة أقل من قرص SSD بريميوم v1.
- لا يوجد تخزين مؤقت للمضيف.
هذا التغيير هو تحول كبير. مع قرص SSD Premium v1، يكون الأداء مرتبطا بشكل أوثق بحجم القرص. مع Premium SSD v2، يمكنك ضبط الأداء بشكل مباشر حول الحاجة إلى عبء العمل.
على سبيل المثال، قد تحتاج قاعدة بيانات ثقيلة المعاملات إلى IOPS عالية دون الحاجة إلى كمية كبيرة من التخزين. يوفر Azure Postgres نظام IOPS ومعدل النقل الأساسي دون تكلفة إضافية، مع توفر IOPS ومعدل نقل بيانات إضافية مقابل رسوم إضافية. يقدم قرص SSD المميز v2:
- تستقبل الأقراص حتى 399 جيجابايت سرعة أساسية تبلغ 3,000 IOPSوسرعة 125 ميجابايت/ثانية.
- تستقبل الأقراص التي تحتوي على 400 جيجابايت أو أكثر خط أساس 12,000 IOPSوسرعة 500 ميجابايت/ثانية.
- يمكن للأقراص أن تصل إلى 80,000 IOPS عند حجمها إلى مساحة متاحة لا تقل عن 160 جيجابايت.
- يمكن أن يصل معدل النقل إلى 1,200 ميجابايت/ثانية.
غالبا ما يكون SSD الفاخر v2 جذابا عندما تحتاج إلى تحكم أكثر دقة في التكلفة والأداء. بدلا من توسيع سعة التخزين فقط لفتح الأداء، يمكنك توفير الأداء بشكل أكثر قصدا.
Ultra Disk (Preview): فئة الأداء عالية المستوى لأقراص Azure
Ultra Disk هو الخيار الأعلى أداء للقرص. يقدم Azure Ultra Disk مستويات أداء تصل إلى:
- 400,000 IOPS
- معدل نقل 10,000 ميجابايت/ثانية
- سعة 64 تيرابايت
- أهداف تصميم زمن استجابة تحت مللي ثانية
- السعة القابلة للتكوين بشكل مستقل، وIOPS، ومعدل النقل
تم تصميم تخزين الأقراص الفائقة لتشغيل أحمال العمل المكثفة على الإخراج الخارجي لقواعد البيانات من الدرجة الأولى، وأنظمة SAP Hana، والأنظمة التي تعتمد على المعاملات الثقيلة. يوفر هذا العرض الجديد للتخزين أداء عالي الجودة لأعباء العمل الحيوية لديك. ومع ذلك، يجب على فريقك أخذ بعض قدرات النشر الرئيسية في الاعتبار، وقيود التوافر الإقليمية، وخيارات التكوين عند التخطيط للنشر:
- نمو التخزين التلقائي غير مدعوم للخوادم التي تستخدم Ultra Disk
- تشفير البيانات باستخدام مفاتيح إدارة العميل غير مدعوم للخوادم التي تحتوي على قرص ألترا
- أقراص Ultra لا تدعم التخزين المؤقت للأقراص
من المهم فهم قدرات Ultra Disk كجزء من مشهد أداء تخزين Azure الأوسع. ومع ذلك، يجب عليك التحقق من توفر الخدمة ودعمها لعبء العمل الخاص بك في Azure Postgres. تحقق مع ممثل Microsoft إذا كان معاينة Ultra Disk متاحة لنشر Azure Postgres الخاص بك.
الخلاصة العملية: Ultra Disk يمثل الطرف الأعلى لأداء التخزين Azure، لكن تصميم Postgres المتكامل يجب أن يتضمن تركيبات مدعومة بنفس القدر لوحدة التخزين المختارة للحوسبة، والمنطقة، ومستوى الإصدار.
جيل الأجهزة الافتراضية مهم: سقوف تخزين الحوسبة في V5 وV6 مختلفة
يمكن أن يؤثر توليد الحوسبة بشكل كبير على أداء التخزين. عندما تستكشف أعلى مستوى من أداء تخزين Azure، تجنب سوء الفهم بأن "الحوسبة الكبيرة" تعني تلقائيا "أقصى حجم تخزين". يجب عليك التحقق من وحدة تخزين الحساب المحددة مقابل مستوى التخزين المقصود. دعونا نوضح هذه النقطة من خلال النظر في جيلين حوسبيين بحجم متشابه، Ddsv5 و Ddsv6:
يدعم Ddsv5توفر سلسلة -أداء تخزين يصل إلى 80,000 IOPSوسرعة 2,600 ميجابايت/ثانية.
توفر سلسلة Ddsv6-مساحة تخزين أعلى، يصل إلى 400,000 IOPSوسرعة 12,000 ميجابايت/ثانية. توفر الحوسبة من سلسلة V6 أيضا قابلية توسع أعلى من الأجيال السابقة، مع ما يصل إلى 192 vCPU وذاكرة 768 جيجابايت.
هذا التغيير الجيلي مهم لتصميم Postgres عالي الأداء. إذا كانت بنية التخزين المستهدفة تتطلب أداء تخزين عالي، فإن اختيار توليد حوسبة بسقف تخزين مجمع أقل يمكن أن يمنع النشر من استخدام كامل قدرة التخزين.
مثال: لماذا المحاذاة من طرف إلى طرف مهمة
تخيل عبء عمل PostgreSQL مع هدف تخزين طموح يبلغ 400,000 IOPS.
في طبقة الأقراص، يدعم Azure Ultra Disk سرعة تصل إلى 400,000 IOPS لكل قرص. يدعم SSD المميز v2 سرعة تصل إلى 80,000 IOPS لكل قرص، وقد تتطلب التصاميم ذات التجميع الأعلى عدة أقراص أو تجريدا على مستوى المنصة حسب دعم الخدمة.
لكن قدرة التخزين وحدها ليست كافية.
قد يكون لتكوين سلسلة V5 سقف تخزين أقل من الهدف. كما ذكر سابقا، تدعم وحدات التخزين من سلسلة V5 سرعة تصل إلى 260,000 IOPS لمعدل نقل البيانات لأقراص SSD البعيدة المميزة. في هذه الحالة، يصبح اختيار طبقة الحوسبة من سلسلة V5 لهذا الهدف هو العامل المحدد قبل الوصول إلى هدف 400,000 IOPS.
على النقيض من ذلك، توفر وثائق سلسلة Ddsv6 سرعة تصل إلى 400,000 IOPS وسرعة 12,000 ميجابايت/ثانية. وهذا يجعل سلسلة V6 والأجيال الأحدث مهمة استراتيجيا للتصاميم التي تحتاج إلى مواءمة الحوسبة والتخزين حول أعلى فئات أداء التخزين.
الدرس بسيط: أقصى أداء لقاعدة البيانات هو خاصية من الطرف إلى الطرف، وليس خاصية تخزين فقط.
خطط لدورات الأعمال، وليس فقط للحالة المستقرة
العديد من الأنظمة لا تمتلك ملف أداء واحد. لديهم عدة منها:
| حركة المرور العادية في أيام الأسبوع. | ساعات الذروة في أوقات العمل. |
| معالجة نهاية الشهر أو نهاية الربع. | الطلب في العطلات أو الموسم. |
| فعاليات إطلاق المنتجات. | نوافذ الإبلاغ عنها. |
| نوافذ الصيانة. | Azure Batch ingestion periods. |
| نسخ احتياطي واستعادة السيناريوهات. | أحداث التعافي من الكوارث. |
قد تواجه قاعدة بيانات بحجم متوسط الاستخدام صعوبة في اللحظات الأكثر أهمية. وعلى العكس، قد تكون قاعدة البيانات ذات الحجم الدائم لذروة مرة واحدة في الشهر مكلفة بشكل غير ضروري.
تسمح مرونة Azure للفرق باتخاذ قرارات أكثر تعقيدا. على سبيل المثال:
- استخدم Premium SSD v2 لضبط IOPS ومعدل النقل مع تطور متطلبات العمل.
- استخدم نسخ القراءة لتحميل أعباء العمل الثقيلة عند الاقتضاء.
- حساب مقياس لفترات الذروة المعروفة.
- قم بتعديل الاستعلامات والفهارس وتجميع الاتصالات قبل توسيع البنية التحتية.
- استخدم الملاحظة لتحديد ما إذا كان عنق الزجاجة هو المعالج المركزي، الذاكرة، IOPS، معدل النقل، نزاع الأقفال، ضغط الاتصال، أو تصميم الاستعلام.
أفضل نشر ليس دائما هو الأكبر في النشر. إنه التصميم الذي يتناسب مع عبء العمل ويمكن أن يتطور بأمان.
الملاحظة جزء من البنية
يجب ألا يتوقف تخطيط الأداء عند النشر. تتغير أعباء العمل بعد القراءة مع مرور الوقت. تنمو البيانات، وتتغير أنماط الاستعلام، وتطلق ميزات جديدة، وتتغير حركة العملاء، وتتراكم الوظائف التشغيلية.
| منطقة المراقبة | إشارات للمراجعة |
|---|---|
| Compute | استخدام المعالج وضغط الذاكرة. |
| الاتصالات | الاتصالات النشطة، الاتصالات الخمولة، وسلوك تجمع الاتصالات. |
| Queries | مدة الاستعلام، تغييرات خطة الاستعلام، واستخدام الفهرس. |
| Storage | نسبة التخزين، زمن استجابة القراءة، زمن الاستجابة للكتابة، استخدام IOPS، وإحصائيات النقل. |
| Maintenance | تضخم الجدول، تضخم الفهرس، خصائص WAL، جداول النسخ الاحتياطي، وجداول الصيانة. |
| النسخ المتماثل | تأخر النسخ حسب الحاجة. |
تسلط وثائق قاعدة بيانات Azure لـ PostgreSQL الضوء على مراقبة استهلاك الإدخال/الإخراج من خلال بوابة Azure أو مقاييس Azure CLI، بما في ذلك حد التخزين، ونسبة التخزين، والتخزين المستخدم، ونسبة الإدخال/الإخراج.
تساعد هذه المقاييس في الإجابة على أهم سؤال تشغيلي: أي طبقة تحد فعليا من الأداء؟
بدون قابلية الملاحظة، قد تقوم الفرق بترقية الشيء الخطأ. قد تبدو مشكلة خطة الاستعلام كمشكلة في التخزين. قد تبدو عواصف الاتصال كضغط المعالج. قد يبدو أن المؤشر المفقود يشبه عدم كفاية IOPS. قد تبدو مشكلة وضع العميل الإقليمي مثل تأخير قاعدة البيانات.
تساعد المراقبة الفرق على إجراء تغييرات مستهدفة بدلا من التخمينات المكلفة.
قائمة التحقق للتخطيط العملي
قبل اختيار قاعدة بيانات قاعدة بيانات Azure لـ PostgreSQL الإنتاجية، قم بجمع المعلومات التالية.
| Category | مدخلات التخطيط |
|---|---|
| نوع حِمل العمل | OLTP، OLAP، الهجين، التقارير، الدفعة، والابتلاع. |
| مزيج القراءة/الكتابة | نسبة القراءات، الكتابات، الإدخال/الإخراج العشوائي، والإدخال/الإخراج المتسلسل. |
| الأداء الحالي | IOPS الأساسي، معدل النقل، زمن الاستجراء، وحدة المعالجة المركزية، الذاكرة، والاتصالات. |
| الأداء الذروة | متطلبات عبء العمل في النسبة المئوية 90 و99. |
| حجم البيانات | الحجم الحالي، النمو المتوقع، استخدام الكائنات الكبيرة، ونمو المؤشر. |
| معدل النمو | توقعات التخزين الشهرية والسنوية السنوية. |
| Concurrency | جلسات نشطة، جلسات خاملة، وسلوك تجمع الاتصالات. |
| دورات الأعمال | يوميا، أسبوعيا، شهريا، موسميا، وذروة مدفوعة بالإطلاق. |
| التوافر | توفر عالي الجودة، نسخ مقلدة، استعادة من الكوارث، النسخ الاحتياطية، الاسترجاع، هدف نقطة الاستعادة (RPO)، وهدف وقت الاسترداد (RTO). |
| اختيار التخزين | أقراص SSD مميزة، وأقراص SSD مميزة v2، والمناطق المدعومة، والميزات المدعومة. |
| تأثير التخزين المؤقت | ما إذا كان التخزين المؤقت لمضيف Premium SSD v1 ينطبق تحت 4 تيرابايت. |
| توليد الحوسبة | هل يمكن للوحدة المختارة المحددة تشغيل IOPS ومعدل النقل المطلوبة. |
| نموذج التوسع | التوسع اليدوي، التعديل المجدول، ضبط الأداء، والنسخ المقلدة. |
| قابلية الرصد | مقاييس، تنبيهات، رؤى الاستعلامات، وعملية مراجعة عبء العمل. |
مبادئ التصميم الموصى بها
استخدم المبادئ التالية عند التخطيط لنشر Azure Postgres لتحقيق الأداء التشغيلي.
-
الحجم بالنسبة لشكل عبء العمل، وليس فقط حجم البيانات.
قاعدة بيانات بسعة 500 جيجابايت قد تحتاج إلى IOPS أكثر من قاعدة بيانات بسعة 5 تيرابايت إذا كانت شديدة المعاملة وحساسية للزمن. الحجم مهم، لكن سلوك عبء العمل أهم. -
التحقق من الحوسبة والتخزين معا.
لا تختار التخزين بناء فقط على حدود القرص. تأكد من أن وحدة المعالجة المختارة يمكنها تشغيل IOPS ومعدل النقل المطلوبة. -
اعتبر حدود التخزين المؤقت لأقراص SSD Premium بسعة 4 تيرابايت علامة تصميمية.
يمكن لنشرات SSD المميزة التي تقل عن 4 تيرابايت الاستفادة من التخزين المؤقت للمضيف. عند سعة 4,096 جيجابايت وما فوق، لا يتم دعم التخزين المؤقت للمضيف. إذا تجاوز النمو هذا العتبة، خطط لنموذج الأداء المستقبلي مبكرا. -
فكر في Premium SSD v2 لضبط أداء مرن.
يتيح قرص SSD Premium v2 تحكما أكثر دقة في السعة، ونظام IOPS، ومعدل النقل. يمكن أن يكون هذا التوافق الجيد عندما لا تتوافق احتياجات الأداء بشكل واضح مع أحجام الأقراص الثابتة. -
استخدم الانفجار للدفعات السريعة، وليس للطلب المستمر.
يمكن أن يساعد الانفجار في تقليل الارتفاعات قصيرة الأمد، لكن الانفجار المتكرر أو المستمر عادة يعني أنه يجب إعادة النظر في التكوين الأساسي. -
مطابقة التوليد مع الطموح.
لتحقيق أهداف الأداء المتقدمة، يمكن لأجيال الحوسبة الحديثة مثل سلسلة v6 أن تكشف عن حدود تخزين عن بعد مجمعة أعلى من الأجيال العامة السابقة. إذا كان الهدف معمارية من فئة 400,000 IOPS، اختر توليد الحوسبة وفقا لذلك. -
قس قبل وبعد التغييرات.
التوسع أسهل في السحابة، لكن القياس هو ما يجعل التوسع فعالا. اجمع مقاييس الأساس والذروة وما بعد التغيير بحيث تكون قرارات الأداء مبنية على الأدلة.
اختبار الواقع: مقارنة تكوينات التخزين تحت الحمل
المبادئ الموضحة في هذا المقال ليست نظرية. لتوضيح كيفية تفاعل الحوسبة والتخزين وعبء العمل عمليا، يلخص pgbench هذا القسم المعايير التي تقارن تكوينات التخزين وتحسب مستويات التخزين تحت ظروف محكومة ومقاسة.
إعداد المعيار والمنهجية
تستخدم pgbenchالمعايير أداة اختبار PostgreSQL القياسية لمحاكاة عبء العمل المعاملي عبر خمسة تكوينات تخزين وحساب مختلفة. يبدأ الاختبار ب 500 اتصال متزامن ويزيد إلى 750 وصلة متزامنة بعد فترة أولية، مما يحافظ على هذا الحمل المرتفع للاتصال لبقية نافذة الاختبار. يحاكي هذا النمط التدريجي مدى زيادة عدد التطبيقات الحقيقية التي تزيد الحمل مع مرور الوقت مع زيادة الحركة، ويقيس كيف تستجيب قاعدة البيانات لكل من الارتفاع الأولي والتزامن العالي المستمر.
جميع معايير الأداء تعمل على قاعدة بيانات Azure لـ PostgreSQL Flexible Server في نفس المنطقة، ضمن نفس منطقة التوافر، باستخدام نفس قاعدة بيانات الاختبار وملف عبء العمل. من خلال عزل التخزين والحوسبة كمتغيرين، تضمن أن اختلافات الأداء تعكس قدرات المنصة الفعلية بدلا من التنوع في الشبكة أو التطبيق أو عبء العمل.
تفاصيل الإعداد
اختبر خمسة تكوينات مميزة، مع تغيير مستوى التخزين وحجم الحوسبة لتوضيح مفاهيم التخطيط الرئيسية.
| Configuration | وحدة SKU الحوسبة | وحدات vCore | الذاكرة | أقصى حساب لنظام IOPS | نوع التخزين | القدرة | عمليات الإدخال / الإخراج في الثانية (IOPS) | الإنتاجية |
|---|---|---|---|---|---|---|---|---|
| التكوين 1 | Standard_D16ds_v5 | 16 | 64 غيغابايت | 25,600 (40,000 انفجار) | قرص SSD بريميوم (P50) | 4,095 غيغابايت | 7,500 | 250 ميغابايت/ثانية |
| التكوين 2 | Standard_D16ds_v5 | 16 | 64 غيغابايت | 25,600 (40,000 انفجار) | قرص SSD بريميوم (P50) | 4,096 جيجابايت | 7,500 | 250 ميغابايت/ثانية |
| التكوين 3 | Standard_D16ds_v5 | 16 | 64 غيغابايت | 25,600 (40,000 انفجار) | قرص SSD بريميوم (P80) | 32 تيرابايت | 20,000 | 900 ميجابايت/ثانية |
| التكوين 4 | Standard_D16ds_v5 | 16 | 64 غيغابايت | 25,600 (40,000 انفجار) | الإصدار 2 من محركات الأقراص ذات الحالة الصلبة المتميزة | 4,095 غيغابايت | 40,000 | 1200 ميجابايت/ثانية |
| التكوين 5 | Standard_D32ds_v5 | 32 | 128 غيغابايت | 51200 | الإصدار 2 من محركات الأقراص ذات الحالة الصلبة المتميزة | 4,095 غيغابايت | 60,000 | 1200 ميجابايت/ثانية |
ملاحظات رئيسية من تصميم التكوين:
- التكوين 1 مقابل التكوين 2: تختلف هذه التكوينات فقط في حجم التخزين، 4095 جيجابايت مقابل 4096 جيجابايت. تختبر هذه المقارنة حدود التخزين المؤقت للمضيف لأقراص SSD Premium v1.
- التكوين 2 مقابل التكوين 3: كلا التكوينين يستخدمان SSD v1، لكن التكوين 3 يتطور إلى سعة 32 تيرابايت لفتح IOPS ومعدل نقل أعلى.
- التكوين 3 مقابل التكوين 4: كلا التكوينين يستخدمان نفس الحاسوبة، لكن التكوين 4 يظهر نظام IOPS مرن ومعدل نقل بيانات Premium SSD v2 مستقل عن السعة.
- التكوين 4 مقابل التكوين 5: يضاعف التكوين 5 وحدة تخزين الحساب ليظهر كيف أن الحوسبة الأعلى المستوى تفتح مساحة أكبر لأداء التخزين.
نتائج الأداء
التكوين 1: قرص SSD Premium v1 بسعة 4,095 جيجابايت مع تخزين مؤقت للمضيف
يستخدم التكوين 1 حجم Premium SSD v1 بسعة 4,095 جيجابايت، والذي يستفيد من التخزين المؤقت للمضيف على Premium SSD v1. خلال عبء العمل، استمر هذا التكوين على:
- أقصى IOPS: 24,773، مع حد أقصى ل 7,500 IOPS موجه على قرص Premium SSD v1، مع تخزين مؤقت يعزز الأداء الفعال.
- أقصى سرعة قراءة IOPS: 21,330، مع الاستفادة من ذاكرة التخزين المؤقت للمضيف للعمليات التي تعتمد على القراءة بشكل كبير.
- أقصى سرعة كتابة IOPS: 7,610.
يوفر التخزين المؤقت للمضيف تضخيم القراءة، بحيث تتجاوز IOPS الفعالة مؤقتا حد IOPS المخصص للقرص البالغ 7,500 وتصل إلى حدود تخزين الحوسبة.
التكوين 2: قرص SSD Premium v1 بسعة 4,096 جيجابايت بدون تخزين مؤقت للمضيف
يستخدم التكوين 2 حجم SSD Premium v1 بسعة 4,096 جيجابايت، مما يتجاوز حدود التخزين المؤقت ويفقد فوائد التخزين المؤقت للمضيف. التأثير واضح:
- أقصى ضغط IOPS: IOPS فعال أقل مقارنة بالتكوين 1 بسبب فقدان التخزين المؤقت.
- ماكس قرأ IOPS: انخفض بشكل كبير بدون ذاكرة تخزين مؤقت للمضيف.
- أقصى عدد من الكتابة IOPS: 7,610، دون تغيير.
هذا التكوين يوضح الأهمية العملية لحدود التخزين المؤقت بسعة 4 تيرابايت. الانتقال من 4,095 جيجابايت إلى 4,096 جيجابايت يغير ملف الأداء عن طريق إزالة القراءات المخزنة. بالنسبة لقواعد البيانات المتنامية التي تقترب من هذا العتبة، خطط مسبقا.
التكوين 3: قرص SSD Premium v1 بسعة 32 تيرابايت مع IOPS أعلى
يعالج التكوين 3 حدود IOPS الأعلى وسرعة النقل في Premium SSD v1 من خلال التوسع إلى سعة 32 تيرابايت. حقق هذا التكوين:
- أقصى ضغط لعملية الإخراج: 20,000.
- ماكس قرأ IOPS: حوالي 12,000.
- أقصى كتابة IOPS: حوالي 5000.
زيادة سعة تخزين Premium SSD v1 تزيد من IOPS ومعدل النقل. لا يزال بإمكانك الوصول إلى الحدود العليا لنطاق تخزين الحوسبة لأحمال العمل المكثفة.
التكوين 4: قرص SSD بريميوم إصدار 2 بسرعة 40,000 IOPS
يظهر التكوين 4 إعداد أداء مرن لقرص SSD بريميوم v2، حيث يوفر 40,000 IOPS وسرعة نقل 1,200 ميجابايت/ثانية على سعة 4,095 جيجابايت:
- أقصى ضغط IOPS: استخدام فعال أعلى بسبب زمن الاستجابة وقدرة الإنتاجية على Premium SSD v2.
- ماكس قرأ IOPS: أداء محسن مقارنة بتكوينات أقراص SSD الممتازة v1.
- أقصى كتابة IOPS: سعة كتابة مستمرة أعلى.
يسمح Premium SSD v2 بتوفير أنظمة IOPS عالية دون الحاجة إلى سعة تخزين كبيرة، مما يجعله فعالا في أعباء العمل الثقيلة بالمعاملات.
التكوين 5: قرص SSD بريميوم إصدار 2 مع سرعة 60,000 IOPS على D32ds_v5 الحوسبة
يضخم التكوين 5 أداء التخزين عند 60,000 IOPS والعمليات الحسابية، مع Standard_D32ds_v5 و32 vCores. هذا التكوين يوضح مبدأ المحاذاة من طرف إلى طرف:
- أقصى ضغط IOPS: أعلى بكثير من جميع التكوينات السابقة.
- ماكس قرأ IOPS: تحسن كبير مع مساحة حوسبة إضافية.
- أقصى كتابة IOPS: استمر في زيادة قدرة الكتابة.
من خلال محاذاة كل من الحوسبة والتخزين لمستويات أداء أعلى، يحقق هذا التكوين أفضل معدل نقل وأقل ضغط في وحدة المعالجة المركزية. يسمح سقف التخزين الأعلى في D32ds_v5 باستخدام قرص SSD Premium v2 بقدرة 60,000 IOPS بشكل أكبر.
دروس من المعايير
توضح هذه التكوينات الخمسة المبادئ الأساسية من هذا المقال:
-
حدود التخزين المؤقت بسعة 4 تيرابايت مهمة.
يظهر التكوين 1 مقابل التكوين 2 أن التخزين المؤقت للمضيف يوفر تضخيم أداء قراءة قابل للقياس أقل من 4 تيرابايت، بينما الانتقال إلى 4096 جيجابايت يزيل هذه الفائدة. -
السعة ليست أداء.
التكوين 3 خصص 32 تيرابايت لكنه لم يحقق أعلى IOPS. سعة التخزين وحدها لا تحدد معدل نقل المعاملات. -
يوفر قرص SSD المميز v2 ضبط أداء مرن.
أظهر التكوين الرابع إضاءات IOPS عالية على سعة متواضعة، مما أكد النموذج المفصول الذي يمكن من SSD Premium v2. -
يجب أن يكون الحساب والتخزين متوافقين.
يظهر التكوين الخامس أن تعظيم أداء التخزين يتطلب مساحة حوسبة كافية. كان من الضروري رفع سقف التخزين D32ds_v5 للاستفادة بشكل أكثر شمولا من توفير 60,000 IOPS.
تؤكد نتائج المعيار المبدأ الأساسي: الأداء الأقصى هو خاصية شاملة من الطرف إلى النهاية. لا توجد طبقة واحدة، مثل التخزين أو الحوسبة أو الشبكات، تحدد النتيجة. يتطلب النجاح محاذاة مقصودة عبر جميع الطبقات، والتحقق المقاس، والملاحظة المستمرة مع تطور أعباء العمل.
خاتمة
يوفر Azure Postgres منصة قوية ومرنة لبناء حلول قواعد بيانات حديثة مستضافة عبر السحابة. تمكن الهندسة عبر Azure Compute، والتخزين، والشبكات، والتوافر العالي، والتكرار، والأمان، والملاحظة بعضا من أكثر معماريات Postgres أداء ومرونة المتاحة.
الأداء الأقصى لا يحدث بالصدفة.
يتطلب الأداء التشغيلي الأقصى فهم التطبيق، والعملاء، وعبء العمل، وملف نمو البيانات، ومزيج القراءة/الكتابة، ودورات الأعمال التي تشكل الطلب. كما يتطلب مواءمة خيارات الحوسبة والتخزين بحيث يتم تحقيق أهداف IOPS ومعدل النقل وزمن الاستجابة من البداية إلى النهاية.
يمكن لقرص SSD المميز إصدار 1 أن يوفر أداء قويا ومتوقعا، خاصة عندما ينطبق التخزين المؤقت للمضيف على البيانات تحت حدود 4 تيرابايت. يضيف Premium SSD v2 تكوين أداء أكثر مرونة من خلال فصل السعة، وIOPS، ومعدل النقل. يمثل Ultra Disk أعلى فئة أداء للأقراص المدارة في Azure، بينما توفر أجيال الحوسبة الحديثة سقوفا أعلى بكثير لتخزين التخزين عن بعد المجمع للبنى عالية الجودة.
أفضل عمليات نشر Azure Postgres تجمع بين قدرات المنصة والتخطيط المتعمد، والمراقبة المستمرة، والملكية التشغيلية الواضحة. مع المتطلبات المناسبة والبنية المعمارية المناسبة، يمكن للفرق تقديم تجارب Postgres عالمية المستوى توفر أعلى أداء ممكن.
المحتوى ذو الصلة
- Azure Premium Storage: تصميم للأداء العالي
- Azure انفجار القرص
- أحجام الآلات الافتراضية من سلسلة Ddv5 وDdsv5
- أحجام الآلات الافتراضية من سلسلة DDSV6
- خيار تخزين SSD بريميوم في قاعدة بيانات Azure لـ PostgreSQL
- ><خيار تخزين SSD بريميوم v2 قاعدة بيانات Azure لـ PostgreSQL<في /c0>
- أنواع الأقراص المدارة من Azure
- Monitor مقاييس في قاعدة بيانات Azure لـ PostgreSQL