🥇Битва двух якодзун, или Cassandra vs HBase. Опыт команды Сбербанка

این حتی یک شوخی نیست، به نظر می رسد که این تصویر خاص به درستی ماهیت این پایگاه های داده را منعکس می کند، و در پایان مشخص خواهد شد که چرا:

بر اساس رتبه بندی موتورهای DB، دو پایگاه داده ستونی NoSQL محبوب ترین، Cassandra (از این پس CS) و HBase (HB) هستند.

به خواست سرنوشت، تیم مدیریت بارگیری داده ما در Sberbank قبلاً انجام شده است مدتها پیش و از نزدیک با 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 حدود 2 برابر می‌بازد (150 ثانیه برای RF=3 در مقابل 75 برای RF=1). اما اگر با بارگذاری داده ها در 8 جدول با 5 رشته (در مجموع 40 رشته) بار را افزایش دهیم، آنگاه از دست دادن RF=3 در حال حاضر 2,7 برابر است (375 ثانیه در مقابل 138).

شاید تا حدودی این راز تست بار موفقیت آمیز انجام شده توسط DataStax برای CS باشد، زیرا برای HB در غرفه ما تغییر ضریب تکرار از 2 به 3 هیچ تاثیری نداشت. آن ها دیسک ها گلوگاه HB برای پیکربندی ما نیستند. با این حال، بسیاری از دام های دیگر در اینجا وجود دارد، زیرا باید توجه داشت که نسخه HB ما کمی وصله و بهینه سازی شده بود، محیط ها کاملاً متفاوت هستند و غیره. همچنین شایان ذکر است که شاید من نمی دانم چگونه CS را به درستی آماده کنم و راه های موثرتری برای کار با آن وجود دارد و امیدوارم در نظرات متوجه شویم. اما اول از همه.

تمام تست‌ها بر روی یک خوشه سخت‌افزاری متشکل از 4 سرور، هر کدام با پیکربندی زیر انجام شد:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 Thread.
Диски: 12 штук SATA HDD
نسخه جاوا: 1.8.0_111

نسخه CS: 3.11.5

پارامترهای cassandra.ymlnum_tokens: 256
hinted_handoff_enabled: درست است
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
hints_directory: /data10/cassandra/hints
hints_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
authenticator: AllowAllAuthenticator
autorizer: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
پارتیشن: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /data1/cassandra/data # هر فهرست dataN یک دیسک جداگانه است
— /data2/cassandra/data
— /data3/cassandra/data
— /data4/cassandra/data
— /data5/cassandra/data
— /data6/cassandra/data
— /data7/cassandra/data
— /data8/cassandra/data
commitlog_directory: /data9/cassandra/commitlog
cdc_enabled: نادرست
disk_failure_policy: توقف
commit_failure_policy: توقف کنید
ready_statements_cache_size_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
key_cache_save_period: 14400
row_cache_size_in_mb: 0
row_cache_save_period: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
saved_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: دوره ای
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
پارامتر:
- دانه: "*،*"
همزمان با خواندن: 256 # سعی شد 64 - تفاوتی مشاهده نشد
concurrent_writes: 256 # пробовали 64 — разницы не замечено
concurrent_counter_writes: 256 # سعی کردم 64 - تفاوتی مشاهده نشد
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # 16 گیگابایت امتحان شد - کندتر بود
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: نادرست
trickle_fsync_interval_in_kb: 10240
storage_port: 7000
ssl_storage_port: 7001
listen_address: *
آدرس_پخش: *
listen_on_broadcast_address: درست است
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: درست است
Native_transport_port: 9042
start_rpc: درست است
rpc_address: *
rpc_port: 9160
rpc_keepalive: درست است
rpc_server_type: همگام سازی
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_before_compaction: false
auto_snapshot: درست است
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
متراکم کننده های همزمان: 4
compaction_throughput_mb_per_sec: 1600
sstable_preemptive_open_interval_in_mb: 50
read_request_timeout_in_ms: 100000
range_request_timeout_in_ms: 200000
write_request_timeout_in_ms: 40000
counter_write_request_timeout_in_ms: 100000
cas_contention_timeout_in_ms: 20000
truncate_request_timeout_in_ms: 60000
request_timeout_in_ms: 200000
slow_query_log_timeout_in_ms: 500
cross_node_timeout: نادرست
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dynamic_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: هیچ
client_encryption_options:
فعال: نادرست
internode_compression: dc
inter_dc_tcp_nodelay: نادرست
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: نادرست
enable_scripted_user_defined_functions: نادرست
windows_timer_interval: 1
transparent_data_encryption_options:
فعال: نادرست
سنگ قبر_آستانه_هشدار: 1000
سنگ قبر_آستانه_شکست: 100000
batch_size_warn_threshold_in_kb: 200
batch_size_fail_threshold_in_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
compaction_large_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: نادرست
enable_materialized_views: درست است
enable_sasi_indexes: درست است

تنظیمات GC:

### تنظیمات CMS-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled

حافظه 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 را حذف کردیم که وقتی تعداد مناطق در RegionServer بیش از 1000 منطقه بود به GC منجر شد)

Параметры non-default HBasezookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 دقیقه
hbase.client.scanner.timeout.period: 2 minute(s)
hbase.master.handler.count: 10
hbase.regionserver.lease.period، hbase.client.scanner.timeout.period: 2 دقیقه
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: 4 hour(s)
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: 1 گیگابایت
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 روز
قطعه پیکربندی پیشرفته سرویس HBase (دریچه ایمنی) برای hbase-site.xml:
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver.optionalcacheflushinterval18000000
hbase.regionserver.thread.compaction.large12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
Java Configuration Options for HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 دقیقه
hbase.snapshot.region.timeout: 2 دقیقه
hbase.snapshot.master.timeout.millis: 2 دقیقه
حداکثر حجم لاگ سرور HBase REST: 100 مگابایت
حداکثر پشتیبان‌گیری از فایل لاگ سرور HBase REST: 5
حداکثر حجم لاگ سرور HBase Thrift: 100 مگابایت
حداکثر پشتیبان‌گیری از فایل لاگ سرور HBase Thrift: 5
Master Max حجم لاگ: 100 مگابایت
حداکثر پشتیبان‌گیری از فایل لاگ اصلی: 5
حداکثر حجم Log RegionServer: 100 مگابایت
حداکثر پشتیبان‌گیری از فایل Log RegionServer: 5
HBase Active Master Detection Window: 4 minute(s)
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 میلی ثانیه
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
حداکثر توصیف کننده فایل فرآیند: 180000
hbase.thrift.minWorkerThreads: 200
hbase.master.executor.openregion.threads: 30
hbase.master.executor.closeregion.threads: 30
hbase.master.executor.serverops.threads: 60
hbase.regionserver.thread.compaction.small: 6
hbase.ipc.server.read.threadpool.size: 20
موضوعات انتقال دهنده منطقه: 6
سایز Client Java Heap در بایت: 1 گیگابایت
گروه پیش فرض سرور HBase REST: 3 گیگابایت
گروه پیش فرض سرور HBase Thrift: 3 گیگابایت
Java Heap حجم HBase Master در بایت: 16 گیگابایت
جاوا Heap حجم سرور HBase RegionServer در بایت: 32 گیگابایت

+zooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
ایجاد جداول:
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 جدول به طور همزمان بارگذاری شد (هر 4 گره برای اتصال استفاده شد). در تست های دیگر با 8 جدول مختلف کار کردیم. در برخی موارد، اندازه دسته 100 و در برخی دیگر 200 بود (پارامتر دسته - کد زیر را ببینید). اندازه داده برای مقدار 10 بایت یا 100 بایت (dataSize) است. در مجموع، هر بار 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 وجود دارد. با این حال، گوگل و جستجو برای مشخص ترین پارامترها (مانند concurrent_writes یا memtable_heap_space_in_mb) سرعت کار را افزایش نداد. در عین حال، سیاهههای مربوط تمیز هستند و به هیچ چیز فحش نمی دهند.

Данные легли по нодам равномерно, статистика со всех нод примерно одинаковая.

Вот как выглядит статистика по таблице с одной из нодفضای کلید: ks
تعداد خوانده شده: 9383707
تأخیر خواندن: 0.04287025042448576 ms
تعداد نوشتن: 15462012
تأخیر نوشتن: 0.1350068438699957 میلی‌ثانیه
فلاش های معلق: 0
Table: t1
SSTable count: 16
فضای استفاده شده (زنده): 148.59 مگابایت
فضای استفاده شده (کل): 148.59 مگابایت
فضای استفاده شده توسط عکس های فوری (کل): 0 بایت
حافظه خاموش استفاده شده (مجموع): 5.17 مگابایت
نسبت فشرده سازی SSTable: 0.5720989576459437
تعداد پارتیشن (تخمین): 3970323
تعداد سلول های Memtable: 0
اندازه داده Memtable: 0 بایت
حافظه Memtable off heap استفاده شده: 0 بایت
تعداد سوئیچ Memtable: 5
تعداد خوانده شده محلی: 2346045
تأخیر خواندن محلی: NaN ms
تعداد نوشتار محلی: 3865503
تأخیر نوشتن محلی: NaN ms
فلاش های معلق: 0
Percent repaired: 0.0
Bloom filter false positives: 25
نسبت کاذب فیلتر بلوم: 0.00000
فضای فیلتر بلوم استفاده شده: 4.57 مگابایت
فیلتر شکن از حافظه پشته استفاده شده: 4.57 مگابایت
Index summary off heap memory used: 590.02 KiB
Compression metadata off heap memory used: 19.45 KiB
حداقل بایت پارتیشن فشرده: 36
حداکثر بایت پارتیشن فشرده: 42
میانگین بایت پارتیشن فشرده: 42
میانگین سلول های زنده در هر برش (پنج دقیقه آخر): NaN
حداکثر سلول زنده در هر برش (پنج دقیقه آخر): 0
میانگین سنگ قبر در هر برش (پنج دقیقه آخر): NaN
حداکثر سنگ قبر در هر برش (پنج دقیقه آخر): 0
Dropped Mutations: 0 bytes

تلاش برای کاهش اندازه دسته (حتی ارسال آن به صورت جداگانه) تأثیری نداشت، فقط بدتر شد. ممکن است که در واقع این حداکثر عملکرد برای CS باشد، زیرا نتایج به دست آمده برای CS مشابه نتایج بدست آمده برای DataStax است - حدود صدها هزار عملیات در ثانیه. علاوه بر این، اگر به استفاده از منابع نگاه کنیم، خواهیم دید که CS از CPU و دیسک های بسیار بیشتری استفاده می کند:

شکل، استفاده در طول اجرای تمام تست‌های پشت سر هم برای هر دو پایگاه داده را نشان می‌دهد.

Что касается мощного преимущества HB при чтении. Тут видно, что для обоих БД утилизация дисков при чтении крайне низкая (тесты на чтение это завершающая часть цикла тестирования каждой БД, например для CS это с 15:20 до 15:40). В случае HB причина понятна — большая часть данных висит в памяти, в memstore и часть закешировалась в blockcache. Что касается CS, то тут не очень ясно как она устроена, однако также утилизации дисков не видно, но на всякий случай была сделана попытка включить кэш row_cache_size_in_mb = 2048 и установлен caching = {‘keys’: ‘ALL’, ‘rows_per_partition’: ‘2000000’}, но от этого стало даже чуть хуже.

همچنین لازم است یک بار دیگر به یک نکته مهم در مورد تعداد مناطق در HB اشاره شود. در مورد ما، مقدار 64 مشخص شده بود. اگر آن را کاهش دهید و آن را به عنوان مثال 4 برابر کنید، در هنگام خواندن، سرعت 2 برابر کاهش می یابد. دلیل آن این است که memstore سریع‌تر پر می‌شود و فایل‌ها اغلب شستشو می‌شوند و هنگام خواندن، فایل‌های بیشتری باید پردازش شوند، که یک عملیات نسبتاً پیچیده برای HB است. در شرایط واقعی، می توان با فکر کردن از طریق یک استراتژی پیش تقسیم و فشرده سازی این مشکل را درمان کرد؛ به ویژه، ما از یک ابزار خودنویس استفاده می کنیم که زباله ها را جمع آوری می کند و HFiles را به طور مداوم در پس زمینه فشرده می کند. کاملاً ممکن است که برای تست های DataStax آنها فقط 1 منطقه را به هر جدول اختصاص دهند (که صحیح نیست) و این تا حدودی روشن می کند که چرا HB در تست های خواندن آنها بسیار پایین است.

Предварительные выводы отсюда получаются следующие. Если допустить, что в ходе тестирования не было допущено грубых ошибок, то Cassandra похожа на колосса на глиняных ногах. Точнее, пока она балансирует на одной ноге, как на картинке в начале статьи, она показывает относительно неплохие результаты, но при схватке в одинаковых условиях проигрывает вчистую. При этом учитывая низкую утилизацию CPU на нашем железе мы научились высаживать по два RegionServer HB на хост и тем самым удвоили производительность. Т.е. с учетом утилизации ресурсов ситуация для CS получается еще более плачевная.

البته این تست‌ها کاملاً مصنوعی هستند و مقدار داده‌هایی که در اینجا استفاده شد نسبتاً کم است. این امکان وجود دارد که اگر به ترابایت تغییر می کردیم، وضعیت متفاوت می شد، اما در حالی که برای HB می توانیم ترابایت را بارگیری کنیم، برای CS این مشکل ساز شد. اغلب حتی با این حجم‌ها یک OperationTimedOutException می‌فرستاد، اگرچه پارامترهای انتظار برای پاسخ قبلاً چندین برابر در مقایسه با پارامترهای پیش‌فرض افزایش یافته بود.

امیدوارم با تلاش مشترک بتوانیم گلوگاه های CS را پیدا کنیم و اگر بتوانیم آن را تسریع کنیم، در پایان پست قطعاً اطلاعاتی در مورد نتایج نهایی اضافه خواهم کرد.

UPD: Благодаря советам камрадов удалось ускорить чтение. Было:
159 644 ops (4 таблицы, 5 потоков, батч 100).
اضافه:
.withLoadBalancingPolicy(New TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
و من با تعداد نخ ها بازی کردم. نتیجه به شرح زیر است:
4 جدول، 100 رشته، دسته = 1 (قطعه به قطعه): 301 عملیات
4 جدول، 100 رشته، دسته = 10: 447 عملیات
4 جدول، 100 رشته، دسته = 100: 625 عملیات

بعداً سایر نکات تنظیم را اعمال می کنم، یک چرخه کامل تست را اجرا می کنم و نتایج را در انتهای پست اضافه می کنم.

منبع: www.habr.com

نبرد دو یاکوزونا یا کاساندرا در مقابل HBase. تجربه تیم Sberbank

اضافه کردن نظر انصراف از پاسخ