קרב שתי יאקוזונה, או קסנדרה נגד HBase. ניסיון בצוות Sberbank

זו אפילו לא בדיחה, נראה שהתמונה הספציפית הזו משקפת בצורה המדויקת ביותר את המהות של מאגרי המידע הללו, ובסופו של דבר יהיה ברור מדוע:

לפי דירוג DB-Engines, שני מסדי הנתונים העמודות הפופולריים ביותר של NoSQL הם Cassandra (להלן CS) ו-HBase (HB).

לפי רצון הגורל, צוות ניהול טעינת הנתונים שלנו ב-Sberbank כבר עשה זאת давно ועובד בשיתוף פעולה הדוק עם HB. במהלך תקופה זו, למדנו היטב את יתרונותיו וחולשותיו ולמדנו כיצד לבשל אותו. עם זאת, נוכחותה של אלטרנטיבה בדמות CS תמיד אילצה אותנו לייסר את עצמנו מעט בספקות: האם בחרנו נכון? יתר על כן, התוצאות השוואות, בביצוע של DataStax, הם אמרו ש-CS מנצח בקלות את HB עם ניקוד כמעט מוחץ. מצד שני, DataStax הוא צד מעוניין, ואתה לא צריך לקבל את המילה שלהם. התבלבלנו גם מכמות המידע הקטנה למדי על תנאי הבדיקה, אז החלטנו לברר לבד מיהו המלך של BigData NoSql, והתוצאות שהתקבלו התבררו כמעניינות מאוד.

עם זאת, לפני המעבר לתוצאות הבדיקות שבוצעו, יש צורך לתאר את ההיבטים המשמעותיים של תצורות הסביבה. העובדה היא שניתן להשתמש ב-CS במצב המאפשר אובדן נתונים. הָהֵן. זה כאשר רק שרת אחד (צומת) אחראי על הנתונים של מפתח מסוים, ואם מסיבה כלשהי הוא נכשל, אז הערך של מפתח זה יאבד. עבור משימות רבות זה לא קריטי, אבל עבור המגזר הבנקאי זה היוצא מן הכלל ולא הכלל. במקרה שלנו, חשוב להחזיק מספר עותקים של נתונים לאחסון אמין.

לכן, רק מצב ההפעלה של CS במצב שכפול משולש נחשב, כלומר. יצירת ה-casespace בוצעה עם הפרמטרים הבאים:

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 שרתים, כל אחד עם התצורה הבאה:

מעבד: Xeon E5-2680 v4 @ 2.40GHz 64 פתילים.
דיסקים: 12 חלקים SATA HDD
גרסת java: 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
מאמת: AllowAllAuthenticator
אישור: AllowAllAuthorizer
role_manager: CassandraRoleManager
תפקידים_תוקף_במשניות: 2000
הרשאות_תוקף_במשניות: 2000
credentials_validity_in_ms: 2000
מחיצה: org.apache.cassandra.dht.Murmur3Partitioner
ספריות_קובץ_נתונים:
- /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: false
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
ספק_זרעים:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
פרמטרים:
— זרעים: "*,*"
concurrent_reads: 256 # ניסו 64 - לא הבחין בהבדל
במקביל_כותבים: 256 # ניסו 64 - לא הבחין בהבדל
concurrent_counter_writes: 256 # ניסו 64 - לא הבחין בהבדל
בו-זמנית_חומר_תצוגת_כותבים: 32
memtable_heap_space_in_mb: 2048 # ניסו 16 GB - זה היה איטי יותר
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: false
trickle_fsync_interval_in_kb: 10240
יציאת_אחסון: 7000
ssl_storage_port: 7001
האזנה_כתובת: *
כתובת שידור: *
האזנה_בשידור_כתובת: נכון
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: שקר
auto_snapshot: נכון
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
concurrent_compactors: 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: false
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
סף_רעות_דינאמי_סניץ': 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: אין
client_encryption_options:
מופעל: שקר
internode_compression: dc
inter_dc_tcp_nodelay: false
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: false
enable_scripted_user_defined_functions: false
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_threshold: 10
compaction_large_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: false
enable_materialized_views: נכון
enable_sasi_indexes: true

הגדרות GC:

### הגדרות CMS-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSIinitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled

לזיכרון jvm.options הוקצה 16Gb (ניסינו גם 32Gb, לא הבחינו בהבדל).

הטבלאות נוצרו עם הפקודה:

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 שאינם ברירת מחדלzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 דקות
hbase.client.scanner.timeout.period: 2 דקות
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 שעות
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: 1 GiB
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: יום(ים)
קטע תצורה מתקדם של שירות 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 עבור 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 Server גודל יומן מקסימלי: 100 MiB
שרת HBase REST גיבויים מקסימליים של קבצי יומן: 5
גודל יומן מקסימלי של HBase Thrift Server: 100 MiB
גיבויים מקסימליים של קבצי יומן של HBase Thrift Server: 5
גודל יומן מרבי מאסטר: 100 MiB
גיבויים מרביים של קבצי יומן: 5
גודל יומן מקסימלי של RegionServer: 100 MiB
RegionServer מקסימום גיבויים של קבצי יומן: 5
חלון HBase Active Master Detection: 4 דקות
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
גודל ערימת ג'אווה של לקוח בבתים: 1 GiB
קבוצת ברירת המחדל של שרת HBase REST: 3 GiB
HBase Thrift Server Group ברירת מחדל: 3 GiB
גודל ערימת Java של HBase Master ב-Bytes: 16 GiB
גודל ערימת Java של HBase RegionServer בבתים: 32 GiB

+שומר גן החיות
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 GB, כלומר. שולחן בגודל בינוני.

בזמן הבדיקה, ל-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 MS
שטיפות בהמתנה: 0
טבלה: t1
ספירת SSTable: 16
שטח שימוש (חי): 148.59 MiB
שטח שימוש (סה"כ): 148.59 MiB
שטח בשימוש על ידי צילומי מצב (סה"כ): 0 בתים
שימוש בזיכרון Off Heap (סה"כ): 5.17 MiB
יחס דחיסה SSTable: 0.5720989576459437
מספר מחיצות (הערכה): 3970323
ספירת תאים זכירה: 0
גודל נתונים מזיכרון: 0 בתים
Memtable מחוץ לזיכרון ערימה בשימוש: 0 בתים
ספירת מתגים לזיכרון: 5
ספירת קריאה מקומית: 2346045
זמן קריאה מקומי: NaN ms
מספר כתובות מקומי: 3865503
זמן כתיבה מקומי: NaN ms
שטיפות בהמתנה: 0
אחוז תיקון: 0.0
מסנן פריחה חיובי שגוי: 25
יחס שווא מסנן פריחה: 0.00000
שטח מסנן פריחה בשימוש: 4.57 MiB
מסנן פריחה של זיכרון ערימה בשימוש: 4.57 MiB
סיכום אינדקס מחוץ לזיכרון הערימה בשימוש: 590.02 KiB
מטא נתונים של דחיסה מחוץ לזיכרון הערימה בשימוש: 19.45 KiB
מינימום בתים של מחיצה דחוסה: 36
מקסימום בתים של מחיצה דחוסה: 42
מחיצה דחוסה ממוצע בתים: 42
ממוצע תאים חיים לפרוסה (חמש דקות אחרונות): NaN
מקסימום תאים חיים לכל פרוסה (חמש דקות אחרונות): 0
מצבות ממוצעות לפרוסה (חמש דקות אחרונות): NaN
מקסימום מצבות לפרוסה (חמש דקות אחרונות): 0
מוטציות שנפלו: 0 בתים

ניסיון להקטין את גודל האצווה (אפילו לשלוח אותה בנפרד) לא השפיע, הוא רק החמיר. יתכן שלמעשה מדובר באמת בביצועים המקסימליים עבור CS, שכן התוצאות המתקבלות עבור CS דומות לאלו המתקבלות עבור DataStax – בערך מאות אלפי פעולות בשנייה. בנוסף, אם נסתכל על ניצול משאבים, נראה ש-CS משתמש בהרבה יותר מעבד ודיסקים:

האיור מציג את השימוש במהלך הריצה של כל הבדיקות ברצף עבור שני מסדי הנתונים.

לגבי יתרון הקריאה החזק של 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 היה כל כך נחות במבחני הקריאה שלהם.

מכאן מוסקות המסקנות המקדימות הבאות. בהנחה שלא נעשו טעויות גדולות במהלך הבדיקה, אז קסנדרה נראית כמו קולוסוס עם רגלי חימר. ליתר דיוק, בזמן שהיא מתאזנת על רגל אחת, כמו בתמונה בתחילת הכתבה, היא מציגה תוצאות טובות יחסית, אבל בקרב באותם תנאים היא מפסידה ישר. במקביל, תוך התחשבות בניצול המעבד הנמוך בחומרה שלנו, למדנו לשתול שני RegionServer HBs לכל מארח ובכך הכפלנו את הביצועים. הָהֵן. אם לוקחים בחשבון את ניצול המשאבים, המצב של CS הוא אפילו יותר מצער.

כמובן, הבדיקות הללו הן די סינתטיות וכמות הנתונים שהיו בה שימוש כאן צנועה יחסית. יתכן שאם נעבור לטרה-בייט המצב היה שונה, אבל בעוד של-HB נוכל לטעון טרה-בייט, ל-CS זה התברר כבעייתי. לעתים קרובות הוא זרק OperationTimedOutException אפילו עם נפחים אלה, למרות שהפרמטרים להמתנה לתגובה כבר הוגדלו מספר פעמים בהשוואה לברירת המחדל.

אני מקווה שבאמצעות מאמצים משותפים נמצא את צווארי הבקבוק של CS ואם נוכל להאיץ אותה, אז בסוף הפוסט בהחלט אוסיף מידע על התוצאות הסופיות.

UPD: הודות לעצות של חברים, הצלחתי לזרז את הקריאה. היה:
159 פעולות (644 טבלאות, 4 זרמים, אצווה 5).
נוסף על ידי:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
ושיחקתי עם מספר השרשורים. התוצאה היא הבאה:
4 טבלאות, 100 שרשורים, אצווה = 1 (חתיכה אחר חתיכה): 301 פעולות
4 טבלאות, 100 שרשורים, אצווה = 10: 447 פעולות
4 טבלאות, 100 שרשורים, אצווה = 100: 625 פעולות

בהמשך אחיל עצות כוונון אחרות, אפעיל מחזור בדיקה מלא ואוסיף את התוצאות בסוף הפוסט.

מקור: www.habr.com