To nie je ani vtip, zdá sa, že tento konkrétny obrázok najpresnejšie odráža podstatu týchto databáz a nakoniec bude jasné, prečo:
Podľa hodnotenia DB-Engines Ranking sú dve najobľúbenejšie stĺpcové databázy NoSQL Cassandra (ďalej len CS) a HBase (HB).
Náš tím riadenia načítania údajov v Sberbank už podľa vôle osudu urobil a úzko spolupracuje s HB. Počas tejto doby sme celkom dobre študovali jeho silné a slabé stránky a naučili sme sa ho variť. Prítomnosť alternatívy v podobe CS nás však vždy nútila trochu sa potrápiť pochybnosťami: rozhodli sme sa správne? Navyše výsledky , v podaní DataStax, povedali, že CS ľahko porazí HB s takmer zdrvujúcim skóre. Na druhej strane je DataStax zainteresovanou stranou a nemali by ste ich brať za slovo. Zmätilo nás aj pomerne malé množstvo informácií o podmienkach testovania, preto sme sa rozhodli na vlastnej koži zistiť, kto je kráľom BigData NoSql a získané výsledky sa ukázali byť veľmi zaujímavé.
Predtým, ako prejdeme k výsledkom vykonaných testov, je však potrebné popísať významné aspekty konfigurácií prostredia. Faktom je, že CS možno použiť v režime, ktorý umožňuje stratu údajov. Tie. vtedy je za údaje určitého kľúča zodpovedný iba jeden server (uzol) a ak z nejakého dôvodu zlyhá, hodnota tohto kľúča sa stratí. Pre mnohé úlohy to nie je kritické, ale pre bankový sektor je to skôr výnimka ako pravidlo. V našom prípade je dôležité mať niekoľko kópií údajov pre spoľahlivé uloženie.
Preto sa uvažovalo iba o prevádzkovom režime CS v režime trojitej replikácie, t.j. Vytvorenie casespace sa uskutočnilo s nasledujúcimi parametrami:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Ďalej existujú dva spôsoby, ako zabezpečiť požadovanú úroveň konzistencie. Všeobecné pravidlo:
SZ + NR > RF
Čo znamená, že počet potvrdení z uzlov pri zápise (NW) plus počet potvrdení z uzlov pri čítaní (NR) musí byť väčší ako faktor replikácie. V našom prípade RF = 3, čo znamená, že sú vhodné nasledujúce možnosti:
2 + 2 > 3
3 + 1 > 3
Keďže je pre nás zásadne dôležité ukladať dáta čo najspoľahlivejšie, bola zvolená schéma 3+1. HB navyše funguje na podobnom princípe, t.j. takéto porovnanie bude spravodlivejšie.
Treba poznamenať, že DataStax vo svojej štúdii urobili opak, nastavili RF = 1 pre CS aj HB (pre druhé menovaním nastavení HDFS). Toto je skutočne dôležitý aspekt, pretože vplyv na výkon CS je v tomto prípade obrovský. Napríklad obrázok nižšie ukazuje predĺženie času potrebného na načítanie údajov do CS:
Tu vidíme nasledovné: čím viac konkurenčných vlákien zapisuje dáta, tým dlhšie to trvá. Je to prirodzené, ale je dôležité, aby degradácia výkonu pre RF=3 bola výrazne vyššia. Inými slovami, ak napíšeme 4 vlákien do 5 tabuliek (celkovo 20), potom RF=3 stratí približne 2-krát (150 sekúnd pre RF=3 oproti 75 pre RF=1). Ale ak zvýšime zaťaženie načítaním údajov do 8 tabuliek s 5 vláknami (celkovo 40), strata RF=3 je už 2,7-násobná (375 sekúnd oproti 138).
Možno je to čiastočne tajomstvo úspešného testovania záťaže, ktoré vykonal DataStax pre CS, pretože pre HB v našom stánku zmena replikačného faktora z 2 na 3 nemala žiadny vplyv. Tie. disky nie sú prekážkou HB pre našu konfiguráciu. Je tu však mnoho iných úskalí, pretože si treba uvedomiť, že naša verzia HB bola mierne zaplátaná a upravená, prostredia sú úplne iné atď. Za zmienku tiež stojí, že možno len neviem, ako správne pripraviť CS a existuje niekoľko efektívnejších spôsobov, ako s tým pracovať, a dúfam, že sa to dozvieme v komentároch. Ale prvé veci.
Všetky testy boli vykonané na hardvérovom klastri pozostávajúcom zo 4 serverov, každý s nasledujúcou konfiguráciou:
CPU: Xeon E5-2680 v4 @ 2.40 GHz 64 vlákien.
Disky: 12 kusov SATA HDD
verzia java: 1.8.0_111
Verzia CS: 3.11.5
parametre cassandra.ymlpočet_tokenov: 256
hinted_handoff_enabled: true
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
adresár_hints: /data10/cassandra/hints
hints_flush_period_in_ms: 10000 XNUMX
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
autentifikátor: AllowAllAuthenticator
autorizér: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
oprávnenia_platnosť_in_ms: 2000
credentials_validity_in_ms: 2000
partitioner: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directory:
- /data1/cassandra/data # každý adresár dataN je samostatný disk
- /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: stop
commit_failure_policy: stop
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
uložený_adresár_caches: /data10/cassandra/saved_caches
commitlog_sync: periodický
commitlog_sync_period_in_ms: 10000 XNUMX
commitlog_segment_size_in_mb: 32
seed_provider:
- názov_triedy: org.apache.cassandra.locator.SimpleSeedProvider
parametre:
— semená: "*,*"
concurrent_reads: 256 # vyskúšaných 64 - žiadny rozdiel
concurrent_writes: 256 # vyskúšaných 64 - žiadny rozdiel
concurrent_counter_writes: 256 # vyskúšaných 64 - nezaznamenali sme žiadny rozdiel
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # vyskúšaných 16 GB - bolo to pomalšie
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: nepravda
trickle_fsync_interval_in_kb: 10240
storage_port: 7000
ssl_storage_port: 7001
Adresa_počúvania: *
vysielacia_adresa: *
listen_on_broadcast_address: true
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: true
native_transport_port: 9042
start_rpc: true
rpc_address: *
rpc_port: 9160
rpc_keepalive: true
rpc_server_type: synchronizácia
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_before_compaction: false
auto_snapshot: true
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
súbežné zhutňovače: 4
compaction_throughput_mb_per_sec: 1600
sstable_preemptive_open_interval_in_mb: 50
read_request_timeout_in_ms: 100000 XNUMX
range_request_timeout_in_ms: 200000 XNUMX
write_request_timeout_in_ms: 40000 XNUMX
counter_write_request_timeout_in_ms: 100000 XNUMX
cas_contention_timeout_in_ms: 20000 XNUMX
truncate_request_timeout_in_ms: 60000 XNUMX
request_timeout_in_ms: 200000 XNUMX
slow_query_log_timeout_in_ms: 500
cross_node_timeout: nepravda
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000 XNUMX
dynamic_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: žiadne
client_encryption_options:
povolené: nepravda
internode_compression: dc
inter_dc_tcp_nodelay: nepravda
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:
povolené: nepravda
tombstone_warn_threshold: 1000
Tombstone_failure_threshold: 100000 XNUMX
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: nepravda
enable_materialized_views: true
enable_sasi_indexes: true
Nastavenia GC:
### Nastavenia CMS-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:Pomer prežitia=8
-XX:MaxTenuringThreshold=1
-XX:CMSIitiatingOccupancyFraction=75
-XX:+UseCMSIitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSCclassUnloadingEnabled
Bolo pridelených 16 Gb pamäte jvm.options (skúsili sme aj 32 Gb, rozdiel nebol zaznamenaný).
Tabuľky boli vytvorené príkazom:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};Verzia HB: 1.2.0-cdh5.14.2 (v triede org.apache.hadoop.hbase.regionserver.HRegion sme vylúčili MetricsRegion, čo viedlo ku GC, keď bol počet regiónov na RegionServeri viac ako 1000)
Nepredvolené parametre HBasečasový limit.schôdze.zookeepera: 120000 XNUMX
hbase.rpc.timeout: 2 minúty
hbase.client.scanner.timeout.period: 2 minúty
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 minúty
hbase.regionserver.handler.count: 160
hbase.regionserver.metahhandler.count: 30
hbase.regionserver.logroll.period: 4 hod.
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.majorkompakt: 1 dní
HBase Service Advanced Configuration Snippet (Safety Valve) pre hbase-site.xml:
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver.voliteľnécacheflushinterval18000000
hbase.regionserver.thread.compaction.large12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
Možnosti konfigurácie Java pre HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSIitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 minúty
hbase.snapshot.region.timeout: 2 minúty
hbase.snapshot.master.timeout.millis: 2 minúty
Maximálna veľkosť protokolu servera HBase REST: 100 MiB
Maximálne zálohy protokolových súborov servera HBase REST: 5
Maximálna veľkosť protokolu HBase Thrift Server: 100 MiB
Maximálny počet záloh protokolových súborov servera HBase Thrift: 5
Maximálna veľkosť protokolu Master: 100 MiB
Hlavné maximálne zálohy protokolových súborov: 5
Maximálna veľkosť denníka RegionServer: 100 MiB
Maximálny počet záloh súborov denníka RegionServer: 5
Okno aktívnej hlavnej detekcie HBase: 4 minúty
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 milisekúnd
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Maximálny počet deskriptorov procesných súborov: 180000 XNUMX
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
Vlákna na presun regiónu: 6
Veľkosť klientskej Java haldy v bajtoch: 1 GiB
Predvolená skupina servera HBase REST: 3 GiB
Predvolená skupina servera HBase Thrift Server: 3 GiB
Veľkosť Java haldy HBase Master v bajtoch: 16 GiB
Veľkosť Java haldy HBase RegionServer v bajtoch: 32 GiB
+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000 XNUMX
Vytváranie tabuliek:
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'}
Je tu jeden dôležitý bod – popis DataStax nehovorí o tom, koľko regiónov bolo použitých na vytvorenie tabuliek HB, aj keď je to kritické pre veľké objemy. Preto bolo pre testy zvolené množstvo = 64, čo umožňuje uložiť až 640 GB, t.j. stredne veľký stôl.
V čase testu mal HBase 22 67 tabuliek a 1.2.0 XNUMX oblastí (to by bolo pre verziu XNUMX smrteľné, keby nebolo vyššie spomínaného patchu).
Teraz kód. Keďže nebolo jasné, ktoré konfigurácie sú pre konkrétnu databázu výhodnejšie, testy sa robili v rôznych kombináciách. Tie. v niektorých testoch boli načítané 4 tabuľky súčasne (na pripojenie boli použité všetky 4 uzly). V ďalších testoch sme pracovali s 8 rôznymi tabuľkami. V niektorých prípadoch bola veľkosť dávky 100, v iných 200 (parameter dávky – pozri kód nižšie). Veľkosť údajov pre hodnotu je 10 bajtov alebo 100 bajtov (dataSize). Celkovo bolo do každej tabuľky zakaždým zapísaných a prečítaných 5 miliónov záznamov. Súčasne sa do každej tabuľky zapísalo/načítalo 5 vlákien (číslo vlákna - thNum), z ktorých každé používalo svoj vlastný rozsah kľúčov (počet = 1 milión):
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);
}
}
V súlade s tým bola podobná funkcia poskytnutá pre 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);
}
}
Keďže v HB sa musí klient postarať o rovnomernú distribúciu dát, funkcia solenia kľúčov vyzerala takto:
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);
}
Teraz najzaujímavejšia časť - výsledky:
To isté vo forme grafu:
Výhoda HB je taká prekvapivá, že existuje podozrenie, že v nastavení CS existuje nejaké úzke miesto. Avšak vyhľadávanie na Googli a vyhľadávanie najzrejmejších parametrov (ako concurrent_writes alebo memtable_heap_space_in_mb) veci nezrýchlilo. Zároveň sú polená čisté a na nič nenadávajú.
Dáta boli distribuované rovnomerne medzi uzlami, štatistiky zo všetkých uzlov boli približne rovnaké.
Takto vyzerá tabuľková štatistika z jedného z uzlovKeyspace: ks
Počet prečítaní: 9383707
Latencia čítania: 0.04287025042448576 ms
Počet zápisov: 15462012
Latencia zápisu: 0.1350068438699957 ms
Čakajúce splachovania: 0
Tabuľka: t1
Počet SSTtables: 16
Využitý priestor (naživo): 148.59 MiB
Využitý priestor (celkom): 148.59 MiB
Priestor použitý snímkami (celkom): 0 bajtov
Využitá pamäť mimo haldy (celkom): 5.17 MiB
Kompresný pomer SSTable: 0.5720989576459437
Počet priečok (odhad): 3970323
Počet zapamätateľných buniek: 0
Veľkosť zapamätateľných údajov: 0 bajtov
Použitá pamäť mimo haldy: 0 bajtov
Počet pamäťových spínačov: 5
Miestny počet prečítaní: 2346045
Lokálna latencia čítania: NaN ms
Miestny počet zápisov: 3865503
Lokálna latencia zápisu: NaN ms
Čakajúce splachovania: 0
Percento opravených: 0.0
Falošne pozitívne výsledky filtra Bloom: 25
Nepravdivý pomer filtra Bloom: 0.00000
Použitý priestor Bloom filtra: 4.57 MiB
Použitá pamäť haldy Bloom filter off: 4.57 MiB
Súhrn indexu mimo použitej pamäte haldy: 590.02 KiB
Metadáta kompresie z použitej pamäte haldy: 19.45 kB
Minimálny počet bajtov zhutnenej oblasti: 36
Maximálny počet bajtov zhutnenej oblasti: 42
Stredné bajty zhutnenej oblasti: 42
Priemer živých buniek na plátok (posledných päť minút): NaN
Maximálny počet živých buniek na plátok (posledných päť minút): 0
Priemerný počet náhrobkov na plátok (posledných päť minút): NaN
Maximálny počet náhrobných kameňov na plátok (posledných päť minút): 0
Vynechané mutácie: 0 bajtov
Pokus o zmenšenie veľkosti dávky (aj odosielanie jednotlivo) nemal žiadny účinok, iba sa to zhoršilo. Je možné, že v skutočnosti ide skutočne o maximálny výkon pre CS, pretože výsledky získané pre CS sú podobné tým, ktoré sa získali pre DataStax – približne stovky tisíc operácií za sekundu. Okrem toho, ak sa pozrieme na využitie zdrojov, uvidíme, že CS využíva oveľa viac CPU a diskov:
Na obrázku je znázornené vyťaženie počas behu všetkých testov za sebou pre obe databázy.
Čo sa týka silnej čitateľskej výhody HB. Tu môžete vidieť, že pre obe databázy je využitie disku počas čítania extrémne nízke (testy čítania sú záverečnou časťou testovacieho cyklu pre každú databázu, napríklad pre CS je to od 15:20 do 15:40). V prípade HB je dôvod jasný – väčšina dát visí v pamäti, v memstore a časť je cache v blockcache. Pokiaľ ide o CS, nie je veľmi jasné, ako to funguje, ale recyklácia disku tiež nie je viditeľná, ale pre každý prípad bol urobený pokus povoliť vyrovnávaciu pamäť row_cache_size_in_mb = 2048 a nastaviť vyrovnávaciu pamäť = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, ale tým sa to ešte trochu zhoršilo.
Za zmienku ešte raz stojí dôležitý bod o počte krajov v HB. V našom prípade bola hodnota špecifikovaná ako 64. Ak ju znížite a rovnáte napríklad 4, potom pri čítaní rýchlosť klesne 2 krát. Dôvodom je, že memstore sa bude rýchlejšie zapĺňať a súbory sa budú častejšie preplachovať a pri čítaní bude potrebné spracovať viac súborov, čo je pre HB pomerne komplikovaná operácia. V reálnych podmienkach sa to dá riešiť premyslením stratégie predbežného rozdeľovania a zhutňovania; konkrétne používame samonapísaný nástroj, ktorý zbiera odpadky a neustále komprimuje HFiles na pozadí. Je celkom možné, že pre testy DataStax pridelili iba 1 región na tabuľku (čo nie je správne) a to by trochu objasnilo, prečo bol HB taký horší v testoch čítania.
Z toho vyplývajú nasledujúce predbežné závery. Za predpokladu, že sa pri testovaní neurobili žiadne zásadné chyby, potom Cassandra vyzerá ako kolos s hlinenými nohami. Presnejšie, kým balansuje na jednej nohe, ako na obrázku na začiatku článku, vykazuje relatívne dobré výsledky, no v súboji za rovnakých podmienok prehráva na plnej čiare. Zároveň, berúc do úvahy nízke využitie CPU na našom hardvéri, sme sa naučili osadiť dva RegionServer HB na hostiteľa a tým zdvojnásobili výkon. Tie. S ohľadom na využitie zdrojov je situácia pre CS ešte žalostnejšia.
Samozrejme, tieto testy sú dosť syntetické a množstvo dát, ktoré tu bolo použité, je pomerne skromné. Je možné, že ak by sme prešli na terabajty, situácia by bola iná, no kým pri HB vieme načítať terabajty, pri CS sa to ukázalo ako problematické. Často to aj pri týchto zväzkoch vyhodilo OperationTimedOutException, hoci parametre čakania na odpoveď boli už niekoľkonásobne zvýšené oproti predvoleným.
Dúfam, že spoločným úsilím nájdeme úzke miesta CS a ak to dokážeme urýchliť, tak na konci príspevku určite doplním informáciu o konečných výsledkoch.
UPD: Vďaka radám súdruhov sa mi podarilo urýchliť čítanie. bol:
159 644 ops (4 tabuľky, 5 streamov, dávka 100).
Pridané:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
A pohral som sa s počtom vlákien. Výsledok je nasledujúci:
4 tabuľky, 100 vlákien, dávka = 1 (kus po kuse): 301 969 ops
4 tabuľky, 100 vlákien, dávka = 10: 447 608 operácií
4 tabuľky, 100 vlákien, dávka = 100: 625 655 operácií
Neskôr použijem ďalšie tipy na ladenie, spustím celý testovací cyklus a výsledky pridám na koniec príspevku.
Zdroj: hab.com