معركة اثنين Yakozun ، أو كاساندرا ضد HBase. تجربة فريق سبيربنك

هذه ليست مجرد نكتة ، ويبدو أن هذه الصورة بعينها تعكس بدقة أكثر جوهر قواعد البيانات هذه ، وفي النهاية سيكون من الواضح لماذا:



وفقًا لتصنيف DB-Engines ، فإن قاعدتي أعمدة NoSQL الأكثر شيوعًا هما Cassandra (المشار إليها فيما يلي باسم CS) و HBase (HB).



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

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

لذلك ، تم النظر فقط في وضع CS للنسخ المتماثل الثلاثي ، أي تم إنشاء الحالة باستخدام المعلمات التالية:

CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3}; 

علاوة على ذلك ، هناك طريقتان لضمان المستوى المطلوب من الاتساق. القاعدة العامة:
NW + NR> RF

هذا يعني أن عدد التأكيدات من العقد عند الكتابة (NW) بالإضافة إلى عدد التأكيدات من العقد عند القراءة (NR) يجب أن يكون أكبر من عامل النسخ المتماثل. في حالتنا ، RF = 3 وبالتالي فإن الخيارات التالية مناسبة:
2 + 2> 3
3 + 1> 3

نظرًا لأنه من الأهمية بمكان بالنسبة لنا أن نحافظ على موثوقية البيانات قدر الإمكان ، فقد تم اختيار مخطط 3 + 1. بالإضافة إلى ذلك ، يعمل HB على أساس مشابه ، أي مثل هذه المقارنة ستكون أكثر صدقا.

تجدر الإشارة إلى أن DataStax قام بالعكس في أبحاثهم ، فقد قاموا بتعيين RF = 1 لكل من CS و HB (بالنسبة إلى الأخير من خلال تغيير إعدادات HDFS). هذا جانب مهم حقًا ، لأن التأثير على أداء CS في هذه الحالة كبير. على سبيل المثال ، توضح الصورة أدناه الزيادة في الوقت اللازم لتحميل البيانات في CS:



هنا نرى ما يلي ، المواضيع الأكثر تنافسا تكتب البيانات ، كلما طالت المدة. هذا أمر طبيعي ، ولكن من المهم أن يكون تدهور أداء RF = 3 أعلى بكثير. بمعنى آخر ، إذا كتبنا في 4 جداول في كل من 5 تدفقات (المجموع 20) ، فإن RF = 3 تفقد حوالي مرتين (150 ثانية RF = 3 مقابل 75 لل RF = 1). ولكن إذا قمنا بزيادة الحمل عن طريق تحميل البيانات في 8 جداول في كل من 5 تدفقات (إجمالي 40) ، فإن فقدان RF = 3 يكون بالفعل 2.7 مرة (375 ثانية مقابل 138).

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

تم إجراء جميع الاختبارات على مجموعة حديدية تتكون من 4 خوادم ، كل في تكوين:

وحدة المعالجة المركزية: زيون E5-2680 v4 @ 2.40GHZ 64 المواضيع.
الأقراص: 12 قطعة من SATA HDD
نسخة جافا: 1.8.0_111


إصدار CS: 3.11.5


إعدادات GC:


تم تخصيص ذاكرة jvm.options بسرعة 16 جيجا بايت (لا تزال تحاول 32 جيجا بايت ، ولم يلاحظ أي اختلاف).

تم إنشاء الجداول بواسطة الأمر:

 CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64}; 

إصدار HB: 1.2.0-cdh5.14.2 (في الصف org.apache.hadoop.hbase.regionserver.HRegion استبعدنا MetricsRegion مما أدى إلى GC مع أكثر من 1000 منطقة على RegionServer)


إنشاء الجداول:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns: t1 UniformSplit -c 64 -f cf
تغيير 'ns: t1' ، {NAME => 'cf' ، DATA_BLOCK_ENCODING => 'FAST_DIFF' ، COMPRESSION => 'GZ'}

هناك نقطة مهمة واحدة - لا يوضح وصف DataStax عدد المناطق التي تم استخدامها لإنشاء جداول HB ، على الرغم من أن هذا أمر مهم بالنسبة للكميات الكبيرة. لذلك ، للاختبارات ، تم اختيار الرقم = 64 ، والذي يسمح بتخزين ما يصل إلى 640 جيجابايت ، أي طاولة متوسطة الحجم.

في وقت الاختبار ، كان لدى HBase 22 ألف طاولة و 67 ألف منطقة (سيكون ذلك قاتلاً بالنسبة للإصدار 1.2.0 ، إن لم يكن للتصحيح المذكور أعلاه).

الآن للرمز. نظرًا لأنه لم يكن من الواضح التكوينات الأكثر فائدة لقاعدة بيانات معينة ، فقد تم إجراء الاختبارات في مجموعات مختلفة. أي في بعض الاختبارات ، ذهب الحمل في وقت واحد إلى 4 جداول (تم استخدام جميع العقد الأربعة للاتصال). في اختبارات أخرى ، عملوا مع 8 طاولات مختلفة. في بعض الحالات ، كان حجم الدُفعات 100 ، وفي حالات أخرى 200 (معلمة الدُفعات - انظر الكود أدناه). حجم البيانات للقيمة 10 بايت أو 100 بايت (حجم البيانات). في المجموع ، تم كتابة 5 ملايين السجلات وطرحها في كل مرة في كل جدول. في الوقت نفسه ، تمت كتابة / قراءة 5 تدفقات في كل جدول (رقم الدفق هو thNum) ، استخدم كل منها نطاقه الرئيسي (عدد = 1 مليون):

 if (opType.equals("insert")) { for (Long key = count * thNum; key < count * (thNum + 1); key += 0) { StringBuilder sb = new StringBuilder("BEGIN BATCH "); for (int i = 0; i < batch; i++) { String value = RandomStringUtils.random(dataSize, true, true); sb.append("INSERT INTO ") .append(tableName) .append("(id, title) ") .append("VALUES (") .append(key) .append(", '") .append(value) .append("');"); key++; } sb.append("APPLY BATCH;"); final String query = sb.toString(); session.execute(query); } } else { for (Long key = count * thNum; key < count * (thNum + 1); key += 0) { StringBuilder sb = new StringBuilder("SELECT * FROM ").append(tableName).append(" WHERE id IN ("); for (int i = 0; i < batch; i++) { sb = sb.append(key); if (i+1 < batch) sb.append(","); key++; } sb = sb.append(");"); final String query = sb.toString(); ResultSet rs = session.execute(query); } } 

وفقًا لذلك ، تم توفير وظيفة مماثلة لـ HB:

 Configuration conf = getConf(); HTable table = new HTable(conf, keyspace + ":" + tableName); table.setAutoFlush(false, false); List<Get> lGet = new ArrayList<>(); List<Put> lPut = new ArrayList<>(); byte[] cf = Bytes.toBytes("cf"); byte[] qf = Bytes.toBytes("value"); if (opType.equals("insert")) { for (Long key = count * thNum; key < count * (thNum + 1); key += 0) { lPut.clear(); for (int i = 0; i < batch; i++) { Put p = new Put(makeHbaseRowKey(key)); String value = RandomStringUtils.random(dataSize, true, true); p.addColumn(cf, qf, value.getBytes()); lPut.add(p); key++; } table.put(lPut); table.flushCommits(); } } else { for (Long key = count * thNum; key < count * (thNum + 1); key += 0) { lGet.clear(); for (int i = 0; i < batch; i++) { Get g = new Get(makeHbaseRowKey(key)); lGet.add(g); key++; } Result[] rs = table.get(lGet); } } 

نظرًا لأن العميل يجب أن يهتم بالتوزيع الموحد للبيانات في HB ، فإن وظيفة التمليح الرئيسية تبدو كما يلي:

 public static byte[] makeHbaseRowKey(long key) { byte[] nonSaltedRowKey = Bytes.toBytes(key); CRC32 crc32 = new CRC32(); crc32.update(nonSaltedRowKey); long crc32Value = crc32.getValue(); byte[] salt = Arrays.copyOfRange(Bytes.toBytes(crc32Value), 5, 7); return ArrayUtils.addAll(salt, nonSaltedRowKey); } 

الآن الأكثر إثارة للاهتمام هي النتائج:



نفس الرسم البياني:



تتميز ميزة HB بأنها مدهشة لدرجة أنه يوجد شك في وجود نوع من عنق الزجاجة في إعدادات CS. ومع ذلك ، فإن googling والتواء المعلمات الأكثر وضوحًا (مثل concurrent_writes أو memtable_heap_space_in_mb) لم يعطيا تسارعًا. في الوقت نفسه ، سجلات نظيفة ، لا أقسم على أي شيء.

تكمن البيانات بالتساوي عبر العقد ، والإحصاءات من جميع العقد هي نفسها تقريبا.


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


يوضح الشكل استخدام جميع الاختبارات على التوالي لكل من قواعد البيانات.

فيما يتعلق بفوائد القراءة القوية لـ HB. يمكن ملاحظة أن استخدام القرص أثناء القراءة منخفض للغاية بالنسبة لكل من قواعد البيانات (اختبارات القراءة هي الجزء الأخير من دورة الاختبار لكل قاعدة بيانات ، على سبيل المثال ، لـ CS من 15:20 إلى 15:40). في حالة HB ، السبب واضح - فمعظم البيانات معلقة في الذاكرة ، في الذاكرة ، وبعضها تم تخزينه في ذاكرة التخزين المؤقت. بالنسبة إلى CS ، ليس من الواضح تمامًا كيف يعمل ، ومع ذلك ، فإن استخدام القرص غير مرئي أيضًا ، ولكن فقط في حالة حدوث محاولة لتشغيل ذاكرة التخزين المؤقت row_cache_size_in_mb = 2048 وتعيين التخزين المؤقت = {'keys': 'ALL'، 'rows_per_partition': ' 2،000،000 '} ، ولكن هذا جعل الأمر أسوأ قليلا.

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

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

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

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

محدث: تم تطبيق الإرشادات التالية على إعداد CS:

disk_optimization_strategy: الغزل
MAX_HEAP_SIZE = "32G"
HEAP_NEWSIZE = "3200M"
-Xms32G
-Xmx32G
-XX: + UseG1GC
-XX: G1RSetUpdatingPauseTimePercent = 5
-XX: MaxGCPauseMillis = 500
-XX: initatingHeapOccupancyPercent = 70
-XX: ParallelGCThreads = 32
-XX: ConcGCThreads = 8

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

في جزء الكود ، يوجد موصل واحد لجميع مؤشرات الترابط التي تكتب إلى الجدول:

 connector = new CassandraConnector(); connector.connect(node, null, CL); session = connector.getSession(); session.getCluster().getConfiguration().getSocketOptions().setConnectTimeoutMillis(120000); KeyspaceRepository sr = new KeyspaceRepository(session); sr.useKeyspace(keyspace); prepared = session.prepare("insert into " + tableName + " (id, title) values (?, ?)"); 

تم إرسال البيانات عبر الربط:

 for (Long key = count * thNum; key < count * (thNum + 1); key++) { String value = RandomStringUtils.random(dataSize, true, true); session.execute(prepared.bind(key, value)); } 

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

2020-01-18 14: 41: 53: 180 315 ثانية: 10،000،000 عملية ؛ 21589.1 العمليات الحالية / ثانية ؛ [CLEANUP: Count = 100 ، Max = 2236415 ، Min = 1 ، Avg = 22356.39 ، 90 = 4 ، 99 = 24 ، 99.9 = 2236415 ، 99.99 = 2236415] [INSERT: Count = 119551، Max = 174463، Min = 273، المتوسط ​​= 2582.71 ، 90 = 3491 ، 99 = 16767 ، 99.9 = 99711 ، 99.99 = 171263]
[بشكل عام] ، RunTime (مللي ثانية) ، 315539
[بشكل عام] ، الإنتاجية (العمليات / ثانية) ، 31691.803548848162
[TOTAL_GCS_PS_Scavenge] ، العدد ، 161
[TOTAL_GC_TIME_PS_Scavenge] ، الوقت (مللي ثانية) ، 2433
[TOTAL_GC_TIME _٪ _ PS_Scavenge] ، الوقت (٪) ، 0.7710615803434757
[TOTAL_GCS_PS_MarkSweep] ، عدد ، 0
[TOTAL_GC_TIME_PS_MarkSweep] ، الوقت (مللي ثانية) ، 0
[TOTAL_GC_TIME _٪ _ PS_MarkSweep] ، الوقت (٪) ، 0.0
[TOTAL_GCs] ، الكونت ، 161
[TOTAL_GC_TIME] ، الوقت (مللي ثانية) ، 2433
[TOTAL_GC_TIME_٪] ، الوقت (٪) ، 0.7710615803434757
[إدراج] ، العمليات ، 1000000
[INSERT] ، AverageLatency (us) ، 3114.2427012
[إدراج] ، MinLatency (لنا) ، 269
[INSERT] ، MaxLatency (us) ، 609279
[INSERT] ، 95thPercentileLatency (us) ، 5007
[INSERT] ، 99 thPercentileLatency (us) ، 33439
[INSERT] ، Return = OK ، 10000000


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

حول قراءة أكثر إثارة للاهتمام. بفضل نصيحة الرفاق ، تمكن من تسريع جذري. أجريت القراءة ليس في 5 تيارات ، ولكن في 100. زيادة إلى 200 لم ينتج عنها تأثير. تمت الإضافة أيضًا إلى المنشئ:
.withLoadBalancingPolicy (TokenAwarePolicy الجديد (DCAwareRoundRobinPolicy.builder (). build ()))

نتيجة لذلك ، إذا أظهر الاختبار في وقت مبكر 159 644 مكتب خدمات المشاريع (5 تدفقات ، 4 جداول ، 100 دفعة) ، الآن:
100 مؤشر ترابط ، 4 جداول ، مجموعة = 1 (بشكل فردي): 301 969 ops
100 مؤشر ترابط ، 4 جداول ، دُفعة = 10: 447 608 ops
100 مؤشر ترابط ، 4 جداول ، دُفعة = 100: 625 655 ops

نظرًا لأن النتائج أفضل مع الدُفعات ، فقد أجريت اختبارات * مماثلة مع HB:

* منذ العمل في 400 مؤشر ترابط ، فإن وظيفة RandomStringUtils ، التي تم استخدامها سابقًا ، قد تم تحميل وحدة المعالجة المركزية بنسبة 100٪ ، وتم استبدالها بمولد أسرع.

وبالتالي ، فإن زيادة عدد مؤشرات الترابط عند تحميل البيانات يعطي زيادة بسيطة في أداء HB.

أما بالنسبة للقراءة ، فإليك نتائج العديد من الخيارات. بناءً على طلب 0x62ash ، تم تنفيذ أمر التدفق قبل القراءة ، كما تتوفر عدة خيارات أخرى للمقارنة:
Memstore - القراءة من الذاكرة ، أي قبل التنظيف على القرص.
HFile + zip - القراءة من الملفات المضغوطة بواسطة خوارزمية GZ.
HFile + upzip - قراءة من الملفات دون ضغط.

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

من أجل الاهتمام ، قمت بتصحيح رمز YCSB للعمل مع دفعات HB من 100 قطعة لقياس الكمون وأكثر من ذلك. فيما يلي نتيجة عمل 4 نسخ مكتوبة على طاولاتها ، ولكل منها 100 موضوع. اتضح ما يلي:


, CS AverageLatency(us) 3114, HB AverageLatency(us) = 1162 (, 1 = 100 ).

— HBase. , SSD . , , , 4 , 400 , . : — . . ScyllaDB , …