أفضل الممارسات لتحقيق الأداء الأمثل
Azure Managed Instance ل Apache Cassandra هي خدمة مدارة بالكامل لمجموعات Apache Cassandra مفتوحة المصدر فقط. تسمح الخدمة أيضا بتجاوز التكوينات، اعتمادا على الاحتياجات المحددة لكل حمل عمل، ما يسمح بأقصى قدر من المرونة والتحكم عند الحاجة. توفر هذه المقالة تلميحات حول كيفية تحسين الأداء.
الإعداد والتكوين الأمثل
عامل النسخ المتماثل وعدد الأقراص وعدد العقد ووحدات SKU
نظرا لأن Azure يدعم ثلاث مناطق توفر في معظم المناطق، وCassandra Managed Instance يعين مناطق التوفر إلى حوامل، نوصي باختيار مفتاح قسم ذي علاقة أساسية عالية لتجنب الأقسام الساخنة. للحصول على أفضل مستوى من الموثوقية والتسامح مع الخطأ، نوصي بشدة بتكوين عامل النسخ المتماثل من 3. نوصي أيضا بتحديد مضاعف لعامل النسخ المتماثل كعدد العقد، على سبيل المثال 3 و6 و9 وما إلى ذلك.
نستخدم RAID 0 على عدد الأقراص التي توفرها. لذلك للحصول على IOPS الأمثل، تحتاج إلى التحقق من الحد الأقصى IOPS على SKU الذي اخترته مع IOPS لقرص P30. على سبيل المثال، Standard_DS14_v2 يدعم SKU 51,200 IOPS غير المخزن مؤقتا، بينما يحتوي قرص P30 واحد على أداء أساسي يبلغ 5,000 IOPS. لذلك، فإن أربعة أقراص ستؤدي إلى 20000 عملية الإدخال والإخراج في الثانية، وهو ما يقل كثيرا عن حدود الجهاز.
نوصي بشدة بإجراء قياس واسع النطاق لحمل العمل الخاص بك مقابل SKU وعدد الأقراص. يعد قياس الأداء مهما بشكل خاص في حالة وحدات SKU مع ثمانية ذاكرات أساسية فقط. تظهر أبحاثنا أن ثماني وحدات معالجة مركزية أساسية تعمل فقط لأحمال العمل الأقل تطلبا، وتحتاج معظم أحمال العمل إلى 16 نواة كحد أدنى لتكون ذات أداء.
أحمال العمل التحليلية مقابل أحمال العمل الخاصة بالمعاملات
تحتاج أحمال عمل المعاملات عادة إلى مركز بيانات محسن لزمن انتقال منخفض، بينما غالبا ما تستخدم أحمال العمل التحليلية استعلامات أكثر تعقيدا، والتي تستغرق وقتا أطول للتنفيذ. في معظم الحالات، قد تحتاج إلى مراكز بيانات منفصلة:
- واحد محسن لزمن انتقال منخفض
- واحد محسن لأحمال العمل التحليلية
تحسين أحمال العمل التحليلية
نوصي العملاء بتطبيق الإعدادات التالية cassandra.yaml لأحمال العمل التحليلية (انظر هنا حول كيفية التطبيق).
المهلات
| القيمة | Cassandra MI الافتراضي | التوصية لحمل العمل التحليلي |
|---|---|---|
| read_request_timeout_in_ms | 5,000 | 10,000 |
| range_request_timeout_in_ms | 10,000 | 20,000 |
| counter_write_request_timeout_in_ms | 5,000 | 10,000 |
| cas_contention_timeout_in_ms | 1,000 | 2,000 |
| truncate_request_timeout_in_ms | 60,000 | 120,000 |
| slow_query_log_timeout_in_ms | 500 | 1,000 |
| roles_validity_in_ms | 2,000 | 120,000 |
| permissions_validity_in_ms | 2,000 | 120,000 |
ذاكرة تخزين مؤقتة
| القيمة | Cassandra MI الافتراضي | التوصية لحمل العمل التحليلي |
|---|---|---|
| file_cache_size_in_mb | 2,048 | 6,144 |
المزيد من التوصيات
| القيمة | Cassandra MI الافتراضي | التوصية لحمل العمل التحليلي |
|---|---|---|
| commitlog_total_space_in_mb | 8,192 | 16,384 |
| column_index_size_in_kb | 64 | 16 |
| compaction_throughput_mb_per_sec | 128 | 256 |
إعدادات العميل
نوصي بتعزيز مهلات برنامج تشغيل عميل Cassandra وفقا للمهلات المطبقة على الخادم.
تحسين زمن الانتقال المنخفض
إعداداتنا الافتراضية مناسبة بالفعل لأحمال العمل ذات زمن الانتقال المنخفض. لضمان أفضل أداء لزمن انتقال الاستجابة، نوصي بشدة باستخدام برنامج تشغيل عميل يدعم التنفيذ التخميني وتكوين العميل وفقا لذلك. بالنسبة لبرنامج تشغيل Java V4، يمكنك العثور على عرض توضيحي يوضح كيفية عمل هذا وكيفية تمكين النهج هنا.
مراقبة أداء قنينة الرقبة
أداء وحدة المعالجة المركزية
مثل كل نظام قاعدة بيانات، يعمل Cassandra بشكل أفضل إذا كان استخدام وحدة المعالجة المركزية حوالي 50٪ ولا يحصل أبدا على أعلى من 80٪. يمكنك عرض مقاييس وحدة المعالجة المركزية في علامة التبويب Metrics داخل Monitoring من المدخل:
إذا كانت وحدة المعالجة المركزية أعلى من 80٪ بشكل دائم لمعظم العقد، تصبح قاعدة البيانات محملة تحميلا زائدا في مهلات عميل متعددة. في هذا السيناريو، نوصي باتخاذ الإجراءات التالية:
- توسيع نطاق عموديا إلى SKU مع المزيد من الذاكرات الأساسية لوحدة المعالجة المركزية (خاصة إذا كانت الذاكرات الأساسية 8 أو أقل فقط).
- تغيير الحجم أفقيا عن طريق إضافة المزيد من العقد (كما ذكر سابقا، يجب أن يكون عدد العقد متعددة من عامل النسخ المتماثل).
إذا كانت وحدة المعالجة المركزية عالية فقط لعدد قليل من العقد، ولكنها منخفضة للعقد الأخرى، فإنه يشير إلى قسم ساخن ويحتاج إلى مزيد من التحقيق.
إشعار
يتم دعم تغيير SKU عبر مدخل Azure وAzure CLI ونشر قالب ARM. يمكنك نشر/تحرير قالب ARM، واستبدال SKU بأحد الإجراءات التالية.
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
- Standard_L8s_v3
- Standard_L16s_v3
- Standard_L32s_v3
- Standard_L8as_v3
- Standard_L16as_v3
- Standard_L32as_v3
يرجى ملاحظة أننا لا ندعم حاليا الانتقال عبر عائلات SKU. على سبيل المثال، إذا كنت تمتلك Standard_DS13_v2 حاليا وكنت مهتما بالترقية إلى SKU أكبر مثل Standard_DS14_v2، فهذا الخيار غير متوفر. ومع ذلك، يمكنك فتح تذكرة دعم لطلب ترقية إلى SKU الأعلى.
أداء القرص
تعمل الخدمة على أقراص Azure P30 المدارة، والتي تسمح ب "اندفاع IOPS". المراقبة الدقيقة مطلوبة عندما يتعلق الأمر باختناقات الأداء المتعلقة بالقرص. في هذه الحالة، من المهم مراجعة مقاييس IOPS:
إذا أظهرت المقاييس واحدة أو جميع الخصائص التالية، يمكن أن تشير إلى أنك بحاجة إلى توسيع النطاق.
- أعلى باستمرار من أو يساوي IOPS الأساسي (تذكر ضرب 5000 IOPS في عدد الأقراص لكل عقدة للحصول على الرقم).
- أعلى باستمرار من أو يساوي الحد الأقصى IOPS المسموح به ل SKU للكتابات.
- يدعم SKU التخزين المخزن مؤقتا (الكتابة من خلال ذاكرة التخزين المؤقت) وهذا الرقم أصغر من IOPS من الأقراص المدارة (سيكون هذا الحد الأعلى ل IOPS للقراءة).
إذا رأيت فقط IOPS مرتفعة لبضع عقد، فقد يكون لديك قسم ساخن وتحتاج إلى مراجعة بياناتك للحصول على انحراف محتمل.
إذا كان IOPS الخاص بك أقل مما هو مدعوم من قبل SKU المختار، ولكن أعلى أو يساوي IOPS القرص، يمكنك اتخاذ الإجراءات التالية:
- إضافة المزيد من الأقراص لزيادة الأداء. تتطلب زيادة الأقراص رفع حالة دعم.
- توسيع نطاق مركز (مراكز) البيانات عن طريق إضافة المزيد من العقد.
إذا كان IOPS الخاص بك أقصى ما يدعمه SKU الخاص بك، يمكنك:
- توسيع نطاق إلى SKU مختلف يدعم المزيد من عمليات الإدخال والإخراج في الإخراج في الخدمة.
- توسيع نطاق مركز (مراكز) البيانات عن طريق إضافة المزيد من العقد.
لمزيد من المعلومات، راجع أداء الجهاز الظاهري والقرص.
أداء الشبكة
في معظم الحالات، يكون أداء الشبكة كافيا. ومع ذلك، إذا كنت تتدفق البيانات بشكل متكرر (مثل توسيع/تقليص الحجم الأفقي المتكرر) أو كانت هناك حركات بيانات دخول/خروج ضخمة، فقد يصبح هذا مشكلة. قد تحتاج إلى تقييم أداء شبكة SKU. على سبيل المثال، Standard_DS14_v2 يدعم SKU 12,000 ميغابايت/ثانية، وقارن هذا بالبايت في/خارج في المقاييس:
إذا رأيت الشبكة مرتفعة لبضع عقد فقط، فقد يكون لديك قسم ساخن وتحتاج إلى مراجعة توزيع البيانات و/أو أنماط الوصول للحصول على انحراف محتمل.
- توسيع نطاق عموديا إلى SKU مختلف يدعم المزيد من عمليات الإدخال/الإخراج للشبكة.
- توسيع نطاق المجموعة أفقيا عن طريق إضافة المزيد من العقد.
عدد كبير جدا من العملاء المتصلين
يجب تخطيط عمليات النشر وتوفيرها لدعم الحد الأقصى لعدد الطلبات المتوازية المطلوبة لزمن الانتقال المطلوب للتطبيق. بالنسبة إلى نشر معين، يؤدي إدخال المزيد من التحميل على النظام فوق الحد الأدنى إلى زيادة زمن الانتقال الإجمالي. راقب عدد العملاء المتصلين للتأكد من أن هذا لا يتجاوز الحدود المسموح بها.
مساحة القرص
في معظم الحالات، هناك مساحة كافية على القرص حيث يتم تحسين عمليات النشر الافتراضية ل IOPS، ما يؤدي إلى استخدام منخفض للقرص. ومع ذلك، ننصح أحيانا بمراجعة مقاييس مساحة القرص. تقوم Cassandra بتجميع الكثير من الأقراص ثم تقليلها عند تشغيل الضغط. ومن ثم من المهم مراجعة استخدام القرص على مدى فترات أطول لتحديد الاتجاهات - مثل الضغط غير قادر على إعادة حساب المساحة.
إشعار
من أجل ضمان المساحة المتاحة للضغط، يجب الاحتفاظ باستخدام القرص إلى حوالي 50٪.
إذا رأيت هذا السلوك لعدد قليل من العقد فقط، فقد يكون لديك قسم ساخن وتحتاج إلى مراجعة توزيع البيانات و/أو أنماط الوصول للحصول على انحراف محتمل.
- إضافة المزيد من الأقراص ولكن ضع في اعتبارك حدود IOPS المفروضة من قبل SKU الخاص بك
- توسيع نطاق نظام المجموعة أفقيا
ذاكرة JVM
تعين الصيغة الافتراضية نصف ذاكرة الجهاز الظاهري إلى JVM بحد أعلى يبلغ 31 غيغابايت - وهو في معظم الحالات توازن جيد بين الأداء والذاكرة. قد تواجه بعض أحمال العمل، خاصة تلك التي تحتوي على قراءات متكررة عبر الأقسام أو عمليات فحص النطاق تحديا للذاكرة.
في معظم الحالات يتم استعادة الذاكرة بشكل فعال من قبل جامع البيانات المهملة Java، ولكن خاصة إذا كانت وحدة المعالجة المركزية غالبا ما تكون أعلى من 80٪ لا توجد دورات CPU كافية لجامع البيانات المهملة المتبقية. لذلك يجب أن تكون أي مشاكل في أداء وحدة المعالجة المركزية عناوين قبل مشاكل الذاكرة.
إذا مرر وحدة المعالجة المركزية مؤشر الماوس إلى أقل من 70٪، ولم تتمكن مجموعة البيانات المهملة من استعادة الذاكرة، فقد تحتاج إلى المزيد من ذاكرة JVM. هذا هو الحال بشكل خاص إذا كنت تستخدم SKU بذاكرة محدودة. في معظم الحالات، تحتاج إلى مراجعة الاستعلامات وإعدادات العميل وتقليلها fetch_size مع ما يتم اختياره داخل limit استعلام CQL الخاص بك.
إذا كنت في الواقع بحاجة إلى مزيد من الذاكرة، يمكنك:
- تقديم تذكرة لنا لزيادة إعدادات ذاكرة JVM لك
- التحجيم عموديا إلى SKU الذي يحتوي على ذاكرة أكثر توفرا
شواهد القبور
نقوم بتشغيل الإصلاحات كل سبعة أيام مع برنامج ريبر، والذي يزيل الصفوف التي انتهت صلاحية TTL (تسمى "علامة الحذف"). تحتوي بعض أحمال العمل على عمليات حذف أكثر تكرارا وترى تحذيرات كما هو الحال Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) في سجلات Cassandra، أو حتى أخطاء تشير إلى أنه لا يمكن استيفاء استعلام بسبب علامات الحذف الزائدة.
التخفيف على المدى القصير إذا لم يتم تنفيذ الاستعلامات هو زيادة tombstone_failure_threshold في تكوين Cassandra من الافتراضي 100,000 إلى قيمة أعلى.
بالإضافة إلى ذلك، نوصي بمراجعة TTL على مساحة المفاتيح ومن المحتمل أن تقوم بإجراء الإصلاحات يوميا لمسح المزيد من علامات العلامات. إذا كانت TTLs قصيرة، على سبيل المثال أقل من يومين، وتدفق البيانات وحذفها بسرعة، نوصي بمراجعة استراتيجية الضغط وتفضيل Leveled Compaction Strategy. وفي بعض الحالات، قد تكون هذه الإجراءات مؤشرا على أن استعراض نموذج البيانات مطلوب.
تحذيرات الدفعات
قد تواجه هذا التحذير في سجلات Cassandra والفشل المحتمل ذي الصلة:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
في هذه الحالة، يجب عليك مراجعة استعلاماتك للبقاء دون حجم الدفعة الموصى به. في حالات نادرة وكتخفيف قصير المدى يمكنك زيادة batch_size_fail_threshold_in_kb في تكوين Cassandra من الافتراضي 50 إلى قيمة أعلى.
تحذير قسم كبير
قد تواجه هذا التحذير في سجلات Cassandra:
Writing large partition <table> (105.426MiB) to sstable <file>
يشير هذا إلى وجود مشكلة في نموذج البيانات. فيما يلي مقالة تجاوز مكدس الذاكرة المؤقتة التي تدخل في مزيد من التفاصيل. يمكن أن يؤدي هذا إلى مشكلات شديدة في الأداء ويحتاج إلى معالجة.
تحسينات متخصصة
الضغط
يسمح Cassandra بتحديد خوارزمية ضغط مناسبة عند إنشاء جدول (راجع الضغط) الافتراضي هو LZ4، وهو ممتاز لمعدل النقل وCPU ولكنه يستهلك مساحة أكبر على القرص. يوفر استخدام Zstd (Cassandra 4.0 وما فوق) حوالي 12٪ من المساحة مع الحد الأدنى من حمل وحدة المعالجة المركزية.
تحسين مساحة كومة الذاكرة المؤقتة القابلة للتحميل
الافتراضي لدينا هو استخدام 1/4 من كومة JVM ل memtable_heap_space في cassandra.yaml. بالنسبة للتطبيق الموجه للكتابة و/أو على وحدات SKU ذات الذاكرة الصغيرة، يمكن أن يؤدي ذلك إلى تدفق متكرر وثبات مجزأة مما يتطلب ضغطا أكبر. في مثل هذه الحالات المتزايدة، قد تكون مفيدة إلى 4048 على الأقل ولكنها تتطلب قياسا دقيقا للتأكد من عدم تأثر العمليات الأخرى (على سبيل المثال، القراءات).
الخطوات التالية
في هذه المقالة، وضعنا بعض أفضل الممارسات لتحقيق الأداء الأمثل. يمكنك الآن بدء العمل مع نظام المجموعة: