二人のヤコヅナの戦い、または Cassandra 対 HBase。 ズベルバンクのチーム経験

これは冗談ではなく、この特定の図がこれらのデータベースの本質を最も正確に反映しているようで、最終的にはその理由が明らかになるでしょう。

DB-Engines ランキングによると、NoSQL 列型データベースで最も人気のある XNUMX つは、Cassandra (以下、CS) と HBase (HB) です。

運命の意志により、ズベルバンクのデータ読み込み管理チームはすでに 長いです HBと緊密に連携しています。 この間、私たちはその長所と短所をよく研究し、調理方法を学びました。 しかし、CS という代替案の存在により、私たちは常に疑念を抱いて自分自身を少し苦しめざるを得ませんでした。「私たちの選択は正しかったのだろうか?」 さらに、結果は、 比較DataStax が実行した結果では、CS がほぼ圧倒的なスコアで HB を簡単に破ったと言われています。 一方、DataStax は利害関係者であるため、その言葉を鵜呑みにするべきではありません。 また、テスト条件に関する情報がかなり少なくて混乱したため、誰が BigData NoSql の王者なのかを自分たちで調べてみることにしました。得られた結果は非常に興味深いものでした。

ただし、実行されたテストの結果に進む前に、環境構成の重要な側面を説明する必要があります。 実際、CS はデータ損失が許容されるモードで使用される可能性があります。 それらの。 これは、XNUMX つのサーバー (ノード) だけが特定のキーのデータを担当する場合であり、何らかの理由で失敗すると、このキーの値は失われます。 多くのタスクでは、これは重要ではありませんが、銀行部門では、これは原則ではなく例外です。 私たちの場合、信頼性の高い保管のためにデータのコピーをいくつか用意することが重要です。

したがって、トリプル レプリケーション モードの CS 動作モードのみが考慮されました。 ケーススペースの作成は、次のパラメーターを使用して実行されました。

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

次に、必要なレベルの一貫性を確保するには XNUMX つの方法があります。 原則：
北西 + NR > RF

つまり、書き込み時のノードからの確認数 (NW) と読み取り時のノードからの確認数 (NR) の合計がレプリケーション係数より大きくなければなりません。 この場合、RF = 3 です。これは、次のオプションが適切であることを意味します。
2 + 2> 3
3 + 1> 3

データをできるだけ確実に保存することが基本的に重要であるため、3+1 スキームが選択されました。 さらに、HB も同様の原理で動作します。 そのような比較はより公平になります。

DataStax は調査では逆のことを行い、CS と HB の両方に RF = 1 を設定したことに注意してください (後者の場合は HDFS 設定を変更しました)。 この場合の CS パフォーマンスへの影響は非常に大きいため、これは非常に重要な側面です。 たとえば、以下の図は、CS へのデータのロードに必要な時間の増加を示しています。

ここでは、次のことがわかります。競合するスレッドがデータを書き込むほど、時間がかかります。 これは当然のことですが、RF=3 のパフォーマンス低下が大幅に大きいことが重要です。 つまり、4 つのスレッドをそれぞれ 5 つのテーブル (合計 20) に書き込むと、RF=3 は約 2 倍の損失になります (RF=150 では 3 秒、RF=75 では 1 秒)。 しかし、それぞれ 8 つのスレッドを持つ 5 つのテーブル (合計 40) にデータをロードして負荷を増やすと、RF=3 の損失はすでに 2,7 倍になります (375 秒対 138)。

おそらくこれが、DataStax for CS によって実行された負荷テストが成功した秘密の一部です。なぜなら、私たちのスタンドの HB では、レプリケーション係数を 2 から 3 に変更しても効果がなかったからです。 それらの。 この構成では、ディスクは HB ボトルネックではありません。 ただし、ここには他にも多くの落とし穴があります。なぜなら、私たちのバージョンの HB にはわずかにパッチと微調整が加えられていること、環境が完全に異なることなどに注意する必要があるからです。 おそらく私が CS を正しく準備する方法を知らないだけで、CS を使用するより効果的な方法がいくつかあることも注目に値します。コメントで見つけられることを願っています。 しかし、まず最初に。

すべてのテストは、それぞれ次の構成を持つ 4 台のサーバーで構成されるハードウェア クラスター上で実行されました。

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 スレッド。
ディスク: 12 個の SATA HDD
Java バージョン: 1.8.0_111

CSバージョン：3.11.5

cassandra.ymlのパラメータトークン数: 256
hinted_handoff_enabled: true
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
ヒントディレクトリ: /data10/cassandra/hints
hint_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
バッチログ_リプレイ_スロットル_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
ディスク障害ポリシー: 停止
commit_failure_policy: 停止
prepare_statements_cache_size_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
キーキャッシュ保存期間: 14400
row_cache_size_in_mb: 0
行キャッシュ保存期間: 0
counter_cache_size_in_mb:
カウンタキャッシュ保存期間: 7200
保存されたキャッシュディレクトリ: /data10/cassandra/saved_caches
commitlog_sync: 定期的
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
シードプロバイダー:
- クラス名: org.apache.cassandra.locator.SimpleSeedProvider
パラメータ：
— シード: "*,*"
concurrent_reads: 256 # 試行回数 64 - 違いは認められませんでした
concurrent_writes: 256 # 試行回数 64 - 違いは認められませんでした
concurrent_counter_writes: 256 # 試行回数 64 - 違いは認められませんでした
concurrent_materialized_view_writes: 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
リッスンアドレス: *
ブロードキャストアドレス: *
listen_on_broadcast_address: true
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: true
ネイティブトランスポートポート: 9042
start_rpc: true
rpc_アドレス: *
rpc_ポート: 9160
rpc_keepalive: true
rpc_server_type: 同期
thrift_framed_transport_size_in_mb: 15
増分バックアップ: false
スナップショット前の圧縮: false
auto_snapshot: true
kb の列インデックス サイズ: 64
column_index_cache_size_in_kb: 2
concurrent_compactors: 4
圧縮スループット_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
low_query_log_timeout_in_ms: 500
クロスノードタイムアウト: 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
サーバー暗号化オプション:
ノード間暗号化: なし
client_encryption_options:
有効: false
ノード間圧縮: DC
inter_dc_tcp_nolay: false
トレースタイプ_クエリ_ttl: 86400
トレースタイプ_修復_ttl: 604800
ユーザー定義関数を有効にする: false
スクリプト化されたユーザー定義関数を有効にする: false
ウィンドウタイマー間隔: 1
透明データ暗号化オプション:
有効: false
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 100000
バッチサイズ警告閾値in_kb: 200
バッチサイズフェイル閾値in_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
圧縮_大規模パーティション_警告_しきい値_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: false
Enable_materialized_views: true
Enable_sasi_indexes: true

GC 設定:

### CMS 設定-XX:+UseParNewGC
-XX:+UseConcMarkSweatGC
-XX:+CMSParallelRemarkEnabled
-XX:生存率=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX：+ CMSClassUnloadingEnabled

jvm.options メモリには 16 GB が割り当てられました (32 GB も試しましたが、違いは認められませんでした)。

テーブルは次のコマンドで作成されました。

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 では、RegionServer 上のリージョン数が 1000 を超えたときに GC を引き起こす MetricsRegion を除外しました)

デフォルト以外の HBase パラメータ動物園キーパー.セッション.タイムアウト: 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.期間: 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: 1 日
hbase-site.xml の HBase サービス詳細構成スニペット (安全バルブ):
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
HBase RegionalServer の Java 構成オプション:
-XX:+UseParNewGC -XX:+UseConcMarkSoupGC -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 MiB
HBase REST サーバーの最大ログ ファイル バックアップ: 5
HBase Thrift サーバーの最大ログ サイズ: 100 MiB
HBase Thrift Server の最大ログ ファイル バックアップ: 5
マスター最大ログ サイズ: 100 MiB
マスターログファイルの最大バックアップ数: 5
リージョンサーバーの最大ログサイズ: 100 MiB
RegionalServer の最大ログ ファイル バックアップ: 5
HBase アクティブ マスター検出ウィンドウ: 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
クライアント Java ヒープ サイズ (バイト単位): 1 GiB
HBase REST サーバーのデフォルト グループ: 3 GiB
HBase Thrift サーバーのデフォルト グループ: 3 GiB
HBase マスターの Java ヒープ サイズ (バイト単位): 16 GiB
HBase RegionalServer の Java ヒープ サイズ (バイト単位): 32 GiB

+動物園の飼育員
maxClientCnxns: 601
maxSessionTimeout: 120000
テーブルの作成:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
alter 'ns:t1'、{NAME => 'cf'、DATA_BLOCK_ENCODING => 'FAST_DIFF'、COMPRESSION => 'GZ'}

ここで重要な点が 64 つあります。DataStax の説明には、HB テーブルの作成に使用されたリージョンの数が記載されていませんが、これは大容量の場合には重要です。 したがって、テストでは数量 = 640 が選択され、最大 XNUMX GB、つまり XNUMX GB までの保存が可能になります。 中くらいの大きさのテーブル。

テストの時点で、HBase には 22 のテーブルと 67 のリージョンがありました (これは、上記のパッチがなければバージョン 1.2.0 にとって致命的でした)。

さて、コードです。 特定のデータベースに対してどの構成がより有利であるかが明確ではなかったため、テストはさまざまな組み合わせで実行されました。 それらの。 一部のテストでは、4 つのテーブルが同時にロードされました (4 つのノードすべてが接続に使用されました)。 他のテストでは、8 つの異なるテーブルを使用しました。 バッチ サイズが 100 の場合もあれば、200 の場合もありました (バッチ パラメーター - 以下のコードを参照)。 valueのデータサイズは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 セットアップに何らかのボトルネックがあるのではないかと疑われるほどです。 ただし、Google で最も明白なパラメータ (concurrent_writes や memtable_heap_space_in_mb など) を検索しても速度は上がりませんでした。 同時に、ログはクリーンであり、何も悪口を言っていません。

データはノード全体に均等に分散され、すべてのノードからの統計はほぼ同じでした。

これは、ノードの XNUMX つからのテーブル統計がどのように見えるかです。キースペース: ks
読み取り数: 9383707
読み取りレイテンシ: 0.04287025042448576 ミリ秒
書き込み数: 15462012
書き込みレイテンシ: 0.1350068438699957 ミリ秒
保留中のフラッシュ: 0
テーブル: t1
SSTテーブル数：16
使用容量 (ライブ): 148.59 MiB
使用容量 (合計): 148.59 MiB
スナップショットによって使用されるスペース (合計): 0 バイト
使用されているオフヒープ メモリ (合計): 5.17 MiB
SSTable圧縮率: 0.5720989576459437
パーティション数（推定）：3970323
Memtable セル数: 0
Memtable データサイズ: 0 バイト
使用されている Memtable オフヒープ メモリ: 0 バイト
Memtable スイッチ数: 5
ローカル読み取り数: 2346045
ローカル読み取りレイテンシー: NaN ミリ秒
ローカル書き込み数: 3865503
ローカル書き込みレイテンシ: NaN ミリ秒
保留中のフラッシュ: 0
修復率: 0.0
ブルームフィルターの誤検知: 25
ブルームフィルター偽率：0.00000
使用されるブルーム フィルター スペース: 4.57 MiB
ブルーム フィルター オフ ヒープ メモリ使用量: 4.57 MiB
インデックスの概要オフヒープ メモリ使用量: 590.02 KiB
使用されるヒープ メモリからの圧縮メタデータ: 19.45 KiB
圧縮されたパーティションの最小バイト数: 36
圧縮されたパーティションの最大バイト数: 42
圧縮されたパーティションの平均バイト数: 42
スライスあたりの平均生細胞 (最後の XNUMX 分間): NaN
スライスあたりの最大生細胞数 (最後の 0 分間): XNUMX
スライスごとの平均トゥームストーン (過去 XNUMX 分間): NaN
スライスごとの最大トゥームストーン (過去 0 分間): XNUMX
ドロップされた突然変異: 0 バイト

バッチのサイズを減らそうとしても (個別に送信しても) 効果はなく、状況は悪化するだけでした。 CS で得られる結果は、XNUMX 秒あたり約数十万回の操作という DataStax で得られる結果と似ているため、実際にはこれが CS の最大パフォーマンスである可能性があります。 さらに、リソース使用率を見ると、CS がより多くの CPU とディスクを使用していることがわかります。

この図は、両方のデータベースのすべてのテストを連続して実行したときの使用率を示しています。

HBの強力な読みのアドバンテージについて。 ここでは、どちらのデータベースでも、読み取り中のディスク使用率が非常に低いことがわかります (読み取りテストは各データベースのテスト サイクルの最後の部分です。たとえば、CS の場合、これは 15:20 から 15:40 までです)。 HB の場合、理由は明らかです。ほとんどのデータはメモリ内、memstore 内でハングし、一部はブロックキャッシュにキャッシュされます。 CS に関しては、仕組みがよくわかりませんが、ディスクのリサイクルも表示されませんが、念のため、キャッシュ row_cache_size_in_mb = 2048 を有効にして、caching = {'keys': 'ALL', を設定してみました。 'rows_per_partition': ' 2000000'} ですが、それがさらに状況をさらに悪化させました。

HB のリージョンの数に関する重要な点ももう一度言及する価値があります。 この例では、値は 64 に指定されました。これを減らして、たとえば 4 にすると、読み取り時の速度が 2 倍低下します。 その理由は、memstore がより早くいっぱいになり、ファイルがより頻繁にフラッシュされ、読み取り時により多くのファイルを処理する必要があるためです。これは HB にとってかなり複雑な操作です。 実際の状況では、これは事前分割と圧縮戦略を検討することで対処できます。特に、ガベージを収集し、バックグラウンドで常に HFile を圧縮する自作のユーティリティを使用します。 DataStax テストでは、テーブルごとに 1 つのリージョンのみが割り当てられた可能性が高く (これは正しくありません)、これにより、HB が読み取りテストでそれほど劣っていた理由がある程度明確になります。

これから以下の暫定的な結論が導き出されます。 テスト中に大きなミスがなかったと仮定すると、カサンドラは粘土の足を持つ巨像のように見えます。 正確に言うと、記事冒頭の写真のように片足でバランスをとっている間は比較的良い成績を収めているのですが、同じ条件で戦うと完敗してしまいます。 同時に、ハードウェアの CPU 使用率が低いことを考慮して、ホストごとに XNUMX つの RegionServer HB を配置することを学習し、それによりパフォーマンスが XNUMX 倍になりました。 それらの。 リソースの活用を考慮すると、CS の状況はさらに悲惨です。

もちろん、これらのテストはかなり総合的なものであり、ここで使用されたデータの量は比較的控えめです。 テラバイトに切り替えれば状況は変わる可能性がありますが、HB ではテラバイトを読み込むことができますが、CS ではこれが問題であることが判明しました。 これらのボリュームでも、応答を待機するためのパラメーターがデフォルトのパラメーターと比較してすでに数倍増加しているにもかかわらず、OperationTimedOutException がスローされることがよくありました。

共同の努力でCSのボトルネックを見つけ、それを早めることができれば、最終結果については記事の最後に必ず追記したいと思います。

UPD: 仲間のアドバイスのおかげで、なんとか読むスピードを上げることができました。 だった：
159 オペレーション (644 テーブル、4 ストリーム、バッチ 5)。
追加者：
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
そしてスレッドの数をいじってみました。 結果は次のとおりです。
4 テーブル、100 スレッド、バッチ = 1 (ピースごと): 301 ops
4 テーブル、100 スレッド、バッチ = 10: 447 オペレーション
4 テーブル、100 スレッド、バッチ = 100: 625 オペレーション

後で、他のチューニングのヒントを適用し、完全なテスト サイクルを実行して、結果を投稿の最後に追加します。

出所： habr.com