Hoc ne iocus quidem videtur, quod haec imago accuratissime referat essentiam horum database, et in fine patebit cur;
Secundum DB-Engines Ranking, duo populares NoSQL databases columnares sunt Cassandra (infra CS) et HBase (HB).
Voluntate fati, nostra notitia loading turmas in Sberbank habet et cum HB. Per hoc tempus vires eius et infirmitates satis bene studuimus et eam coquere didicimus. Attamen praesentia jocus in forma CS semper nos nosmetipsos parum dubiis torquere coegit: num rectam electionem fecimus? Eventus autem a DataStax peracta, dixerunt CS facile verberare HB nomine paene oppresso. Contra, DataStax est cuius interest, nec verbum suum pro eo accipere debes. Confusi sumus etiam per minimas informationes de condicionibus probationis, ita constituimus ex nostris cognoscere quis est rex BigData NoSql, et eventus consecutus evasit valde interesting.
Sed antequam progrediamur ad eventus probationum peractas, oportet notabiles aspectus in ambitu figurarum describere. Ita res est, CS adhiberi potest per modum quo notitia damni admittit. Illae. hoc est cum unus tantum servo (nodi) tenetur pro notitia clavis cuiusdam, et si aliqua de causa deficit, valor huius clavis amittetur. Multis muneribus hoc criticum non est, sed pro nummaria regione haec exceptio magis quam regula est. In nobis, refert varia exemplaria notitiarum pro certis repositionibus habere.
Solus ergo CS operans modus considerabatur in triplici replicationis modo, i.e. Casus creatio cum parametris sequentibus peracta est;
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Deinde ad gradum constantiae requiritur duplex modus. Regula generalis:
NW + NR > RF
Quo significat numerum confirmationum e nodis scribentibus (NW) plus numerum confirmationum e nodis legendis (NR) maiorem esse quam replicationis factor. In casu nostro, RF = 3, id quod sequentia optiones apta sunt;
2 + 2 > 3
3 + 1 > 3
Cum maximi momenti sit nobis notitias quam fidelissime condere, consilium 3+1 electum est. Praeterea HB opera simili principio, i.e. talis comparatio pulchrior erit.
Notandum quod DataStax in suo studio contrarium fecerit, RF = 1 ponunt utrumque CS et HB (hoc enim mutando HDFS occasus). Is est vere maximus aspectus quia hic effectus est impetus in CS ingens. Exempli gratia, imago infra ostendit incrementum temporis ad notitias onerandas in CS;
Hic quae sequuntur videmus: quanto certatim stamina scribunt data, eo longior accipit. Hoc est naturale, sed interest ut RF=3 signanter superior effectus degradationis est. Aliis verbis, si scribemus 4 fila in 5 tabulas singulas (20 in totidem), tunc RF=3 amittit circiter 2 vicibus (150 secundis pro RF=3 versus 75 pro RF=1). Si autem onus augemus, data oneratione in 8 tabulas cum 5 filis singulis (40 in total), tunc iactura RF=3 iam est 2,7 temporibus (375 secundis versus 138).
Forsitan hoc partim est arcanum felicis oneris probationis a DataStax pro CS facta, quia HB in nostro statu mutato factor replicationis ab 2 ad 3 effectum non habuit. Illae. orbis HB bottleneck pro nostra configuratione non sunt. Sed multae aliae hic foveae sunt, quia notandum est versionem nostram HB leviter perantiquam et velatam fuisse, ambitus prorsus diversae, etc. Notatu etiam dignum est quod modo fortasse nescimus quomodo recte CS praeparare et nonnullae modi efficaciores cum eo laborare, et spero nos in commentaria reperiemus. Prima autem.
Omnes probationes fiebant in botro ferramento constans ex 4 ministris, unumquodque cum hac configuratione:
CPU: Xeon E5-2680 v4 @2.40GHz 64 stamina.
Disks: 12 pieces DIABOLUS HDD
Java version: 1.8.0_111
CS Version: 3.11.5
cassandra.yml parametrinum_tokens: 256
hinted_handoff_enabled: verum
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
hints_directory: /data10/cassandra/innuit
hints_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
authenticator: AllowAllAuthenticator
Auctor: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
partitio: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directoria:
- /data1/cassandra/data # inter se dataN directorium est separatum disci
- /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: falsus
disk_failure_policy: stop
commit_failure_policy: stop
prepared_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
save_caches_directory: /data10/cassandra/sav_caches
commitlog_sync: periodica
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parametris:
- seminibus: "*,*"
concurren_reads: 256 # conatus 64 - nulla differentia animadvertit
concurren_writes: 256 # conatus 64 - nulla differentia animadvertit
concurrent_counter_writes: 256 # conatus 64 - nulla differentia animadvertit
concurren_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # conatus 16 GB - tardius erat
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync, falsum
trickle_fsync_interval_in_kb: 10240
storage_port: 7000
ssl_storage_port: 7001
listen_address: *
broadcast_address:
listen_on_broadcast_address: verus
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: verum
native_transport_port: 9042
start_rpc: verum
rpc_address:
rpc_port: 9160
rpc_keepalive: verum
rpc_server_type: sync
thrift_framed_transport_size_in_mb: 15
incremental_backups: falsum
snapshot_before_compaction: falsum
auto_snapshot: verum
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
concurren_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: (XL)
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: falsum
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: nemo
client_encryption_options:
enabled: falsum
internode_compression: dc
inter_dc_tcp_nodelay: falsus
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: falsus
enable_scripted_user_defined_functions: falsus
windows_timer_interval: 1
transparent_data_encryption_options:
enabled: falsum
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 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: falsum
enable_materialized_views: verum
enable_sasi_indexes: verum
Occasus GC:
### CMS Optiones-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
16Gb of jvm.options memoriae datum est (nos etiam probavimus 32 Gb, nulla differentia notata est).
Tabulae cum imperio creatae sunt;
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};HB version: 1.2.0-cdh5.14.2 (in classe org.apache.hadoop.hbase.regionserver.HRegion MetricsRegion exclusimus, quae ad GC perduxit cum numerus regionum plus quam 1000 in Regionis Servo erat)
Non default HBase parametrizookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 minute(s)
hbase.client.scanner.timeout.period: II minute (s)
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: minute II (s)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: IV horae (s)
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: I GiB
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 day(s)
HBase Service Advanced Configuratio Snippet (Safety Valve) pro 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 configurationis Options pro HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=XX -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=70m
hbase.snapshot.master.timeoutMillis: 2 minute(s)
hbase.snapshot.region.timeout: 2 minute(s)
hbase.snapshot.master.timeout.millis: 2 minute(s)
HBase CETERUM Servo Max Log Size: 100 MiB
HBase CETERUM Servo Maximum Stipes File inVisum: 5
HBase Thrift Servo Max Log Size: 100 MiB
HBase Thrift Servo Maximum Log File inVisum: V "
Magister Max Log Size: 100 MiB
Magister Maximum Log File inVisum: 5
RegionServer Max Log Size: 100 MiB
RegionServer Maximum Log File inVisum Tergum: V "
HBase Active Magister Deprehensio Fenestra: 4 minute (s)
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: X millisecond (s)
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Maximum Processus File Descriptors: 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: VI "
hbase.ipc.server.read.threadpool.size: 20
Regio movens Thread: 6
Client Java Acervus Size in Bytes: 1 GiB
HBase CETERA Servo Default Group: III GiB
HBase Thrift Servo Default Group: III GiB
Java Heap Size of HBase Master in Bytes: 16 GiB
Java Tumulus Magnitudo HBase Regionis Servo in Bytes: 32 GiB
+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Tabulas creandas:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf.
alter 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', CONPRESSIO => 'GZ'}
Hic unus momenti locus est - descriptio DataStax non dicit quot regiones ad tabulas HB creandas adhibitae sint, quamquam hoc in magnis voluminibus criticum est. Ideo ad probationes, quantitas = 64 eligitur, quod concedit reponenda usque ad 640 GB, i.e. media magnitudine mensae.
In tempore probationis, HBase habuit 22 milia tabularum et 67 milia regionum (hoc letale fuisset versioni 1.2.0 nisi propter commissuram supra dictam).
Nunc ad codicem. Cum non liqueret quibus schematismi in particulari database utilius essent, probationes in variis compagibus fiebant. Illae. in quibusdam probationibus, 4 tabulae simul oneratae sunt (omnes 4 nodi ad nexum adhibiti). In aliis probationibus cum 8 diversis tabulis laboravimus. In quibusdam batch amplitudo erat 100, in aliis 200 (batch parametri - vide codicem infra). Magnitudo data quantitati pretii est 10 bytes vel 100 bytes (dataSize). In summa, 5 decies centena milia in singulis tabulis scripta et recitata sunt. Eodem tempore 5 stamina ad singulas tabulas scripta / legebantur (numerus filorum - thNum), quarum singulae clavium ambitu suo utebantur (numerant = 1 decies centena millia);
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);
}
}
Ideoque similis officiatis HB provisus est:
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);
}
}
Cum cliens in HB curare debet ut distributio uniformis notitiarum, clavis munus salsurae simile hoc vidi:
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);
}
Nunc maxime interesting pars - eventus:
Idem in graphi forma;
Utilitas HB tam miranda est ut suspicio sit aliqua in parte CS bottleneck. Sed Google et quaerens parametros manifestissimos (sicut concurrent_scribit vel memtable_heap_space_in_mb) non acceleravit res. Eodem tempore omnia munda sunt et nihil iurant.
Notitia per nodos aequaliter distributa, statisticae ab omnibus nodis eadem fere erant.
Hoc est quod mensa mutant speciem ex uno e nodisKeyspace: ks
Lege comiti: 9383707
Lege Latency: 0.04287025042448576 ms
Scribe comiti: 15462012
Scribere Latency: 0.1350068438699957 ms
Eviewray Flushes: 0
Mensa: t1
SSTable count: 16
Spatium adhibitum (vivere): 148.59 MiB
Spatium adhibitum (totum): 148.59 MiB
Space used by snapshots (total): 0 bytes
Tumulus memoriae usus (totalis): 5.17 MiB
SSTable Cogo Ratio: 0.5720989576459437
Numerus partitionum (aestimatio): 3970323
Memtable cellam comitem: 0
Memtable notitia magnitudine: 0 bytes
Memtable off acervus memoria usus est: 0 bytes
Memtable switch comitem: 5
Locus legere comitem: 2346045
Locus legitur latency: NaN ms
Loci scribe comitem: 3865503
Locus scribe latency: NaN ms
Dente rubet: 0
Refecit percent: 0.0
Flore filter positivis falsis: 25
Ratio falsa sparguntur sparguntur: 0.00000
Flos colum spatium usus est: 4.57 MiB
Flosculus filter off cumulus memoriae usus est: 4.57 MiB
Index summary off cumulum memoriae adhibitum: 590.02 KiB
Compressione metadata off tumulus memoria adhibita: 19.45 KiB
Partitio minimum bytes compactum: 36
Partitio maximam bytes compactus: 42
Media bytes coniuncta: 42
Mediocris vivere cellulae per scalpere (ultima quinque minuta): NaN
Maximum vivere cellulis per scalpere (ultima quinque minuta): 0
Mediocris sepulchra per scalpere (quinque minuta tandem): NaN
Maximum sepulchrum per scalpere (quinque minuta tandem): 0
Omissa Mutationes: 0 bytes
Conatum ad magnitudinem massae redigendi (etiam singulatim mittendo) effectum non habuit, tantum ingravescebat. Fieri potest ut revera hic sit maximus effectus pro CS, cum eventus pro CS consecuti sint similes illis quae pro DataStax - circa centum milia operationum per secundam consecuti sunt. Praeterea, si utilium resource spectemus, multo magis CPU ac disco utitur CS videbimus;
Figura ostendit utendo in cursu omnium probationum in ordine ad utrumque database.
Quoad HB's validissima lectio proficiet. Hic videre potes quod pro utroque database, utendo disci utendo in lectione, valde humile est (probationes legere sunt ultima pars cycli probati pro singulis datorum, exempli gratia pro CS hoc est a 15:20 ad 15:40). In HB, ratio patet - maxime notitiarum in memoria pendent, in memstore, et quaedam in clausula condiuntur. Quod ad CS, non satis clarum est quomodo operatur, sed orbis redivivus etiam non visibile est, sed in casu tantum, conatus est factus ut cache row_cache_size_in_mb = 2048 et caching = {claves': 'OMnes' "rows_per_partition": '2000000'}, sed quod etiam paulo peius fecit.
De numero regionum in HB iterum memorabile memorabile est. In casu nostro, valor definitus est 64. Si eam minuis et aequalem fac, exempli gratia 4, tunc legendo, celeritas in 2 vicibus cadit. Ratio est, quia memstore ocius implebit et lima crebrius rubet et cum legendo, plura lima discursum erit, quae operatio HB magis perplexa est. In realibus condicionibus, hoc per consilium praesplitting et compactificationis cogitando tractari potest, nominatim utimur utilitate scripta propria, quae purgamentum colligit et HFiles constanter in curriculo comprimit. Fieri potest ut pro DataStax probationibus unam 1 regionem per mensam (quod minus recte) collocarunt, nonnihil illustraret, cur HB tam inferior esset in lectu testium.
Ex hoc praeliminares conclusiones sumuntur. Posito quod in probatione nulla maiora errata sunt, Cassandra in fictilibus pedibus colossus speciem habet. Accuratius, dum in uno crure librat, sicut in tabula in principio articuli, boni eventus relative ostendit, sed in pugna iisdem condicionibus plane amittit. Eodem tempore, inspecta CPU utilitate nostra in ferramentis humilibus, duas servientes HBs per exercitum serere didicimus et inde effectum duplicavit. Illae. Conspectis opibus utendis, condicio CS magis deploranda est.
Nimirum haec probata sunt satis synthetica et copia notitiarum quae hic adhibita sunt relative modeste. Fieri potest ut, si ad terabytes mutavimus, res alia esset, sed dum pro HB terabytes onerare possumus, hoc enim CS factum esse problematicum. Saepe etiam his voluminibus OperationTimedOutExceptionem deiecit, quamquam parametri exspectationis responsionis iam aliquoties aucti sunt ad defaltam comparati.
Spero per conatum iuncturas CS ampullas inventuros et si accelerare poterimus, in fine tabellae notitias de ultimis eventibus certo adiiciam.
UPD: Consilio comitum, lectionem accelerare potui. Erat;
159, 644 Opis (4 tabulae, 5 rivi, praepostere 100).
missae:
.withLoadBalancingPolicy (nova TokenAwarePolicy (DCAwareRoundRobinPolicy.builder) () aedificate ()))
Et circum lusi numero staminum. Consequens est talis:
4 tabulae, 100 stamina, batch = 1 (fragmentum per partes): 301 ops
4 tabulae, 100 stamina, batch = 10: 447 ops
4 tabulae, 100 stamina, batch = 100: 625 ops
Postea alias apicibus appiigam, cyclum probatum percurram et eventus ad finem cursoris adiciam.
Source: www.habr.com