نظرية وممارسة استخدام HBase

مساء الخير اسمي دانيل ليبوفا ، بدأ فريقنا في Sbertech باستخدام HBase كمستودع للبيانات التشغيلية. خلال دراسته ، تم اكتساب الخبرة التي أردت تنظيمها ووصفها (نأمل أن تكون مفيدة للكثيرين). أجريت جميع التجارب أدناه باستخدام إصدارات HBase 1.2.0-cdh5.14.2 و 2.0.0-cdh6.0.0-beta1.

1. العمارة العامة
2. كتابة البيانات إلى HBASE
3. قراءة البيانات من HBASE
4. التخزين المؤقت للبيانات
5. الدفعة معالجة MultiGet / MultiPut
6. استراتيجية تقسيم الجداول إلى مناطق (سكب)
7. التسامح مع الخطأ ، والتضميد ، ومكان البيانات
8. الإعدادات والأداء
9. اختبار الحمل
10. الاستنتاجات

1. العمارة العامة

يستمع المعلم الاحتياطي إلى نبض القلب النشط على عقدة ZooKeeper ، وفي حالة الاختفاء ، يتولى مهام السيد.

2. كتابة البيانات إلى HBASE

أولاً ، ضع في اعتبارك أبسط حالة - كتابة كائن بقيمة مفتاح إلى جدول معين باستخدام put (rowkey). يجب على العميل أولاً معرفة مكان وجود خادم منطقة الجذر (RRS) الذي يقوم بتخزين hbase: meta table. يتلقى هذه المعلومات من ZooKeeper. ثم يلجأ إلى RRS ويقرأ الجدول الفوقي hbase: meta ، الذي يسترجع منه المعلومات التي تكون RegionServer (RS) مسؤولة عن تخزين البيانات لمفتاح الصف المحدد في الجدول الذي يهمه. للاستخدام المستقبلي ، يتم تخزين جدول التعريف مؤقتًا من قبل العميل وبالتالي تسير المكالمات اللاحقة بشكل أسرع ، مباشرة إلى RS.

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

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


عند تنفيذ عملية "حذف" ، لا يتم حذف البيانات الفعلية. يتم تمييزها ببساطة على أنها محذوفة ، ويحدث التدمير نفسه عند استدعاء الوظيفة المدمجة الرئيسية ، والتي تم وصفها بمزيد من التفصيل في القسم 7.

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

بالإضافة إلى عملية التمهيد الموضحة أعلاه ، هناك إجراء أكثر كفاءة ، والذي ربما يكون أقوى جانب من قاعدة البيانات هذه - BulkLoad. وهو يتألف من حقيقة أننا ننشئ HFiles بشكل مستقل ونضعه على القرص ، مما يسمح لنا بالتوسع بشكل مثالي وتحقيق سرعات لائقة للغاية. في الواقع ، القيد هنا ليس HBase ، ولكن إمكانيات الحديد. فيما يلي نتائج التحميل على مجموعة تتكون من 16 RegionServers و 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread) ، الإصدار HBase 1.2.0-cdh5.14.2.



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

يمكنك أيضًا البدء في التحميل في جدولين في نفس الوقت والحصول على مضاعفة السرعة. يمكن أن نرى أدناه أن كتل 10 كيلوبايت تتم كتابتها على جدولين في وقت واحد بسرعة حوالي 600 ميجابايت / ثانية لكل منهما (إجمالي 1275 ميجابايت / ثانية) ، والذي يتزامن مع سرعة الكتابة التي تبلغ 623 ميجابايت / ثانية لجدول واحد (انظر رقم 11 أعلاه)


لكن الإطلاق الثاني بسجلات 50 كيلوبايت يظهر أن سرعة التنزيل تنمو بالفعل بشكل طفيف ، مما يشير إلى تقريب القيم الحدية. يجب أن يوضع في الاعتبار أنه لا يوجد حمل عمليًا على HBASE نفسه ، كل ما هو مطلوب منه هو أولاً إعطاء البيانات من hbase: meta ، وبعد بطانة HFiles ، قم بمسح بيانات BlockCache وحفظ ذاكرة التخزين المؤقت MemStore إلى القرص إذا لم يكن فارغ.

3. قراءة البيانات من HBASE

إذا افترضنا أن جميع المعلومات من hbase: meta لديها بالفعل عميل (انظر القسم 2) ، فإن الطلب ينتقل فورًا إلى RS حيث يتم تخزين المفتاح المطلوب. أولاً يتم البحث في MemCache. بغض النظر عما إذا كانت هناك بيانات أم لا ، يتم إجراء البحث أيضًا في مخزن BlockCache المؤقت ، وإذا لزم الأمر ، في HFiles. إذا تم العثور على البيانات في ملف ، فسيتم وضعها في BlockCache وسيتم إرجاعها بشكل أسرع عند الطلب التالي. تعتبر عمليات بحث HFile سريعة نسبيًا بسبب استخدام مرشح Bloom ، أي بعد قراءة كمية صغيرة من البيانات ، يحدد على الفور ما إذا كان هذا الملف يحتوي على المفتاح المطلوب ، وإذا لم يكن كذلك ، فإنه ينتقل إلى التالي.


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

4. التخزين المؤقت للبيانات

تشغل المخازن المؤقتة MemStore و BlockCache ما يصل إلى 80٪ من ذاكرة RS المخصصة في كومة الذاكرة المؤقتة (الباقي محجوز لمهام خدمة RS). إذا كان وضع الاستخدام النموذجي بحيث تقوم العمليات بكتابة وقراءة نفس البيانات على الفور ، فمن المنطقي تقليل BlockCache وزيادة MemStore ، لأن عندما لا تسقط كتابة البيانات إلى ذاكرة التخزين المؤقت للقراءة ، فسيحدث استخدام BlockCache بشكل أقل. يتكون المخزن المؤقت BlockCache من جزأين: LruBlockCache (دائمًا في الكومة) و BucketCache (عادةً خارج الكومة أو على SSD). يجب استخدام BucketCache عندما يكون هناك الكثير من طلبات القراءة ولا تتناسب مع LruBlockCache ، مما يؤدي إلى العمل النشط لـ Garbage Collector. في الوقت نفسه ، يجب ألا تتوقع زيادة جذرية في الأداء من استخدام ذاكرة التخزين المؤقت للقراءة ، ولكننا سنعود إلى ذلك في القسم 8


BlockCache هو واحد لـ RS بأكمله ، و MemStore له جدول خاص به لكل جدول (واحد لكل عائلة عمود).

كما هو موضح في النظرية ، عندما لا تقع كتابة البيانات في ذاكرة التخزين المؤقت ، وبالفعل ، يتم تعيين هذه المعلمات CACHE_DATA_ON_WRITE للجدول و "Cache DATA on Write" لـ RS إلى false. ومع ذلك ، من الناحية العملية ، إذا قمت بكتابة البيانات إلى MemStore ، فقم بتدفقها إلى القرص (تنظيفها بهذه الطريقة) ، ثم قم بحذف الملف الناتج ، ثم من خلال تنفيذ طلب الحصول ، سنتلقى البيانات بنجاح. وحتى إذا قمت بتعطيل BlockCache تمامًا وقمت بملء الجدول ببيانات جديدة ، فقم بإحضار MemStore إلى القرص وحذفها وطلبها من جلسة أخرى ، فسيظل يتم جلبها من مكان ما. لذا لا تقوم HBase بتخزين البيانات فحسب ، بل أيضًا الألغاز الغامضة.

hbase(main):001:0> create 'ns:magic', 'cf' Created table ns:magic Took 1.1533 seconds hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me' Took 0.2610 seconds hbase(main):003:0> flush 'ns:magic' Took 0.6161 seconds hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash hbase(main):002:0> get 'ns:magic', 'key1' cf:c timestamp=1534440690218, value=try_to_delete_me 

تم تعيين بيانات ذاكرة التخزين المؤقت على القراءة على خطأ. إذا كان لديك أي أفكار ، نرحب بمناقشة ذلك في التعليقات.

5. معالجة الدفعات لبيانات MultiGet / MultiPut

تعد معالجة الطلبات الفردية (Get / Put / Delete) عملية مكلفة إلى حد ما ، لذلك يجب عليك دمجها قدر الإمكان في قائمة أو قائمة ، مما يسمح لك بالحصول على تعزيز كبير في الأداء. هذا ينطبق بشكل خاص على عملية الكتابة ، ولكن عند القراءة هناك مأزق التالي. يوضح الرسم البياني أدناه وقت القراءة لـ 50،000 تسجيل من MemStore. تمت القراءة في دفق واحد ويظهر المحور الأفقي عدد المفاتيح في الطلب. يمكن ملاحظة أنه عندما تزيد إلى ألف مفتاح في طلب واحد ، ينخفض ​​وقت التنفيذ ، أي زيادة السرعة. ومع ذلك ، عند تشغيل وضع MSLAB بشكل افتراضي ، بعد هذا الحد ، يبدأ انخفاض كبير في الأداء ، وكلما زاد مقدار البيانات في السجل ، كلما طال الوقت.



تم إجراء الاختبارات على جهاز افتراضي ، 8 نوى ، الإصدار HBase 2.0.0-cdh6.0.0-beta1.

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


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

6. إستراتيجية تقسيم الجداول إلى مناطق (قطع)

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


يحدث أن يؤدي ذلك إلى تباطؤ حاد إذا كانت البيانات التي تم تحميلها في المستقبل ستبدو ، على سبيل المثال ، القيم الطويلة ، والتي يبدأ معظمها بالرقم نفسه ، على سبيل المثال:

1000001
1000002
...
1100003

نظرًا لأنه يتم تخزين المفاتيح كمجموعة من وحدات البايت ، فستبدأ جميعها بنفس الطريقة وستنتمي إلى نفس المنطقة رقم 1 التي تخزن هذا النطاق من المفاتيح. هناك العديد من الاستراتيجيات المنقسمة:

HexStringSplit - تحويل المفتاح إلى سلسلة بترميز سداسي عشري في النطاق "00000000" => "FFFFFFFF" وملئه بالأصفار على اليسار.

UniformSplit - يحول المفتاح إلى صفيف بايت بترميز سداسي عشري في النطاق "00" => "FF" وملئه بالأصفار على اليمين.

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

التجزئة + مفتاح

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

7. التسامح مع الخطأ وموقع البيانات

نظرًا لأن منطقة واحدة فقط هي المسؤولة عن كل مجموعة من المفاتيح ، فإن حل المشكلات المرتبطة بأعطال RS أو إيقاف التشغيل هو تخزين جميع البيانات الضرورية في HDFS. عندما يتعطل RS ، يكتشف سيد ذلك من خلال عدم وجود ضربات قلب على عقدة ZooKeeper. ثم يقوم بتعيين المنطقة التي تم تقديمها إلى RS آخر ، وبما أن HFiles يتم تخزينها في نظام ملفات موزع ، فإن المضيف الجديد يقرأها ويستمر في خدمة البيانات. ومع ذلك ، نظرًا لأن بعض البيانات قد تكون في MemStore ولم يكن لديها الوقت للوصول إلى HFiles ، يتم استخدام WALs ، المخزنة أيضًا في HDFS ، لاستعادة محفوظات العملية. بعد تمرير التغييرات ، يمكن لـ RS الاستجابة للطلبات ، ومع ذلك ، تؤدي هذه الخطوة إلى حقيقة أن جزءًا من البيانات وعملياتها على عُقد مختلفة ، أي انخفضت المنطقة.

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

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


تم إجراء الاختبار على 3 DataNode و 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). إصدار HBase 1.2.0-cdh5.14.2

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

أيضًا ، لا يؤثر الضغط الرئيسي على حالة MemStore ، ولتدفقه إلى القرص والضغط ، تحتاج إلى استخدام flush (connection.getAdmin (). Flush (TableName.valueOf (tblName))).

8. الإعدادات والأداء

كما ذكرنا من قبل ، يظهر HBase أكبر نجاح حيث لا يحتاج إلى القيام بأي شيء عند تنفيذ BulkLoad. ومع ذلك ، هذا ينطبق على معظم الأنظمة والأشخاص. ومع ذلك ، تعد هذه الأداة أكثر ملاءمة للتراص الجماعي للبيانات في كتل كبيرة ، بينما إذا كانت العملية تتطلب الكثير من طلبات القراءة والكتابة المتنافسة ، فسيتم استخدام أوامر Get and Put الموضحة أعلاه. لتحديد المعلمات المثلى ، تم إجراء عمليات الإطلاق بمجموعات مختلفة من معلمات وإعدادات الجدول:

• تم بدء 10 سلاسل رسائل في نفس الوقت 3 مرات متتالية (دعنا نسميها كتلة من سلاسل الرسائل).
• تم حساب متوسط ​​وقت تشغيل جميع التدفقات في الكتلة وكان النتيجة النهائية لتشغيل الكتلة.
• عملت جميع المواضيع مع نفس الجدول.
• قبل كل بداية كتلة الخيط ، تم تنفيذ ضغط كبير.
• قامت كل كتلة بتنفيذ واحدة فقط من العمليات التالية:

- ضع
- احصل
- احصل + ضع

• نفذت كل كتلة 50000 تكرار لعملياتها.
• حجم التسجيل في الكتلة هو 100 بايت أو 1000 بايت أو 10000 بايت (عشوائي).
• تم إطلاق الكتل مع عدد مختلف من المفاتيح المطلوبة (إما مفتاح واحد أو 10).
• تم إطلاق الكتل في إعدادات الجدول المختلفة. تم تغيير المعلمات:

- BlockCache = تشغيل أو إيقاف
- BlockSize = 65 كيلوبايت أو 16 كيلوبايت
- أقسام = 1 أو 5 أو 30
- MSLAB = قيد التشغيل أو الإيقاف

وبالتالي ، تبدو الكتلة كما يلي:

أ. تشغيل / إيقاف وضع MSLAB.
ب. تم إنشاء جدول تم تعيين المعلمات التالية له: BlockCache = true / none، BlockSize = 65/16 Kb، Partitions = 1/5/30.
ج. ضبط الضغط GZ.
د. تم إطلاق 10 سلاسل رسائل في وقت واحد من خلال إجراء 1/10 من عمليات وضع / الحصول / الحصول على + وضع في هذا الجدول بسجلات 100/1000/10000 بايت ، وتنفيذ 50.000 استفسار على التوالي (مفاتيح عشوائية).
ه. تم تكرار النقطة د ثلاث مرات.
و. تم حساب متوسط ​​وقت تشغيل جميع الخيوط.

تم فحص جميع التركيبات الممكنة. من المتوقع أنه كلما زاد حجم التسجيل ، ستنخفض السرعة أو سيتباطأ تعطيل التخزين المؤقت. ومع ذلك ، كان الهدف هو فهم درجة وأهمية تأثير كل معلمة ، وبالتالي ، تم تغذية البيانات التي تم جمعها لمدخلات وظيفة الانحدار الخطي ، مما يجعل من الممكن تقييم الموثوقية باستخدام إحصاءات t. فيما يلي نتائج الكتل التي تؤدي عمليات البيع. مجموعة كاملة من المجموعات 2 * 2 * 3 * 2 * 3 = 144 خيارات + 72 منذ ذلك الحين تم تنفيذ بعضها مرتين. لذلك ، تم إطلاق ما مجموعه 216 عملية:


تم إجراء الاختبار على مجموعة صغيرة تتكون من 3 DataNode و 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 تيارات). الإصدار HBase 1.2.0-cdh5.14.2.

تم الحصول على أعلى سرعة إدخال تبلغ 3.7 ثانية عند إيقاف تشغيل وضع MSLAB ، على طاولة مع قسم واحد ، مع تمكين BlockCache ، BlockSize = 16 ، تسجيلات 100 بايت من 10 قطع لكل علبة.
تم الحصول على أقل سرعة إدخال 82.8 ثانية عندما تم تمكين وضع MSLAB ، على طاولة مع قسم واحد ، مع تمكين BlockCache ، BlockSize = 16 ، سجلات 10000 بايت لكل منهما.

الآن دعونا نلقي نظرة على النموذج. نرى نموذجًا جيدًا لـ R2 ، ولكن من الواضح أن الاستقراء هو بطلان هنا. لن يكون السلوك الفعلي للنظام عند تغيير المعلمات خطيًا ، وهذا النموذج ليس ضروريًا للتنبؤات ، ولكن لفهم ما حدث داخل المعلمات المحددة. على سبيل المثال ، هنا نرى من خلال معيار الطالب أنه بالنسبة لعملية الوضع ، لا يهم معلمات BlockSize و BlockCache (وهو أمر يمكن التنبؤ به بشكل عام):


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


الآن دعونا نقيم نتائج تنفيذ كتل الحظر:


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


حسنًا ، أخيرًا ، انظر إلى نموذج الكتلة التي تم تنفيذها ، ثم احصل على:


هنا جميع المعلمات مهمة. ونتائج القادة:

9. اختبار الحمل

حسنًا ، أخيرًا ، سنطلق حملًا لائقًا أكثر أو أقل ، ولكنه دائمًا ما يكون أكثر إثارة للاهتمام عندما يكون هناك شيء للمقارنة. يحتوي موقع DataStax ، المطور الرئيسي لـ Cassandra ، على نتائج NT لعدد من مستودعات NoSQL ، بما في ذلك HBase الإصدار 0.98.6-1. تم تحميل 40 تيارات ، حجم البيانات 100 بايت ، أقراص SSD. أظهرت نتائج اختبار عمليات القراءة - التعديل - الكتابة هذه النتائج.


كما أفهمها ، تم إجراء القراءة في كتل من 100 سجل و 16 عقدة HBase ، أظهر اختبار DataStax أداء 10 آلاف عملية في الثانية.

من حسن الحظ أن مجموعتنا تحتوي أيضًا على 16 عقدة ، ولكن ليس من حسن الحظ أن كل منها يحتوي على 64 نواة (خيوط) ، في حين أن اختبار DataStax يحتوي على 4 فقط. من ناحية أخرى ، لديهم أقراص SSD ، ولدينا أقراص صلبة والمزيد لم يزد الإصدار الجديد من استخدام HBase و CPU أثناء الحمل عمليًا بشكل ملحوظ (بشكل مرئي بنسبة 5-10 في المائة). ومع ذلك ، سنحاول البدء في هذا التكوين. إعدادات الجدول بشكل افتراضي ، يتم إجراء القراءة في مجموعة من المفاتيح من 0 إلى 50 مليون عشوائي (أي ، في الواقع ، في كل مرة واحدة جديدة). في الجدول ، تم تقسيم 50 مليون إدخال إلى 64 قسمًا. تم تجزئة مفاتيح crc32. إعدادات الجدول افتراضية ، تم تمكين MSLAB. بدءاً من 40 سلسلة رسائل ، يقرأ كل مؤشر ترابط مجموعة من 100 مفتاح عشوائي ويكتب على الفور 100 بايت التي تم إنشاؤها على هذه المفاتيح مرة أخرى.


الحامل: 16 DataNode و 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 streams). الإصدار HBase 1.2.0-cdh5.14.2.

متوسط ​​النتيجة أقرب إلى 40 ألف عملية في الثانية ، وهو أفضل بكثير من اختبار DataStax. ومع ذلك ، لأغراض التجربة ، يمكن تغيير الشروط قليلاً. من غير المحتمل تمامًا أن يتم تنفيذ جميع الأعمال حصريًا باستخدام جدول واحد ، وكذلك باستخدام مفاتيح فريدة فقط. افترض أن هناك مجموعة مفاتيح "ساخنة" معينة تولد الحمل الرئيسي. لذلك ، سنحاول إنشاء حمولة بسجلات أكبر (10 كيلوبايت) ، أيضًا في حزم من 100 لكل منها ، في 4 جداول مختلفة وتحديد نطاق المفاتيح المطلوبة بـ 50 ألفًا. يوضح الرسم البياني أدناه بداية 40 سلسلة ، ويقرأ كل دفق مجموعة من 100 مفتاح ويكتب على الفور 10 عشوائيًا KB على هذه المفاتيح مرة أخرى.


الحامل: 16 DataNode و 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 streams). الإصدار HBase 1.2.0-cdh5.14.2.

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

القراءة والكتابة على الفور هي واحدة من أصعب سيناريوهات الوظائف لـ HBase. إذا قمت فقط بوضع طلبات بحجم صغير ، على سبيل المثال ، 100 بايت لكل منها ، ودمجها في مجموعات من 10-50 ألف قطعة ، يمكنك الحصول على مئات الآلاف من العمليات في الثانية والوضع مشابه لطلبات القراءة فقط. تجدر الإشارة إلى أن النتائج أفضل جذريًا من تلك التي تم الحصول عليها في DataStax أكثر من أي شيء آخر بسبب الطلبات في كتل من 50 ألف.


الحامل: 16 DataNode و 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 streams). الإصدار HBase 1.2.0-cdh5.14.2.

10. الاستنتاجات

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

إذا لم يتم الكشف عن شيء في رأيك بشكل كافٍ ، فأنا على استعداد لإخبارك بمزيد من التفاصيل. نقترح مشاركة تجربتك أو مناقشتك إذا كنت لا توافق على شيء.