Ez nem is vicc, úgy tűnik, hogy ez a kép tükrözi legpontosabban ezen adatbázisok lényegét, és a végén kiderül, miért:
A DB-Engines Ranking szerint a két legnépszerűbb NoSQL oszlopos adatbázis a Cassandra (a továbbiakban CS) és a HBase (HB).
A sors akaratából a Sberbank adatbetöltési menedzsment csapata már megtette és szorosan együttműködik a HB-vel. Ezalatt alaposan tanulmányoztuk erősségeit és gyengeségeit, és megtanultuk főzni. Az alternatíva jelenléte a CS formájában azonban mindig arra kényszerített bennünket, hogy egy kicsit kétségekkel gyötörjük magunkat: vajon jól választottunk? Ráadásul az eredményeket , amelyet a DataStax végzett, azt mondták, hogy a CS könnyedén, szinte zúzós pontszámmal veri a HB-t. Másrészt a DataStax érdekelt fél, és nem szabad szót fogadni. Bennünket is megzavart a meglehetősen kevés információ a tesztkörülményekről, ezért úgy döntöttünk, hogy saját kezűleg kiderítjük, ki a BigData NoSql királya, és a kapott eredmények nagyon érdekesek lettek.
Mielőtt azonban rátérnénk az elvégzett tesztek eredményeire, szükséges ismertetni a környezeti konfigurációk lényeges szempontjait. A tény az, hogy a CS olyan módban használható, amely lehetővé teszi az adatvesztést. Azok. ilyenkor csak egy szerver (csomópont) felelős egy bizonyos kulcs adataiért, és ha ez valamilyen okból meghibásodik, akkor ennek a kulcsnak az értéke elvész. Sok feladatnál ez nem kritikus, de a bankszektor számára ez inkább kivétel, mint szabály. Esetünkben a megbízható tárolás érdekében fontos, hogy több adatmásolat álljon rendelkezésre.
Ezért csak a CS működési módot vettük figyelembe hármas replikációs módban, azaz. Az esettér létrehozása a következő paraméterekkel történt:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Ezután kétféleképpen biztosítható a szükséges konzisztencia. Általános szabály:
ÉNy + NR > RF
Ez azt jelenti, hogy a csomópontoktól írás közbeni megerősítések számának (NW) plusz a csomópontoktól olvasáskor érkező megerősítések számának (NR) nagyobbnak kell lennie, mint a replikációs tényező. Esetünkben RF = 3, ami azt jelenti, hogy a következő lehetőségek megfelelőek:
2 + 2 > 3
3 + 1 > 3
Mivel számunkra alapvetően fontos az adatok minél megbízhatóbb tárolása, ezért a 3+1 sémát választottuk. Ráadásul a HB is hasonló elven működik, pl. igazságosabb lesz egy ilyen összehasonlítás.
Megjegyzendő, hogy a DataStax az ellenkezőjét járta el vizsgálatában, RF = 1-et állított be mind a CS, mind a HB esetében (utóbbinál a HDFS beállítások megváltoztatásával). Ez nagyon fontos szempont, mert ebben az esetben óriási a hatása a CS teljesítményére. Például az alábbi képen az adatok CS-be való betöltéséhez szükséges idő növekedése látható:
Itt a következőket látjuk: minél több versengő szál ír adatot, annál tovább tart. Ez természetes, de fontos, hogy az RF=3 teljesítményromlása lényegesen nagyobb legyen. Más szóval, ha 4 szálat írunk 5-20 táblázatba (összesen 3), akkor az RF=2 körülbelül 150-szer veszít (3 másodperc RF=75 esetén, szemben 1 RF=8 esetén). De ha úgy növeljük a terhelést, hogy 5, egyenként 40 szálas táblába töltjük az adatokat (összesen 3), akkor az RF=2,7 vesztesége már 375-szeres (138 másodperc a XNUMX-hoz képest).
Talán részben ez a titka a DataStax által CS-re végzett sikeres terhelési tesztelésnek, mert a HB számára a standunkon a replikációs faktor 2-ről 3-ra váltása nem volt hatással. Azok. A lemezek nem jelentik a HB szűk keresztmetszetét konfigurációnkban. Azonban sok más buktató is van itt, mert meg kell jegyezni, hogy a HB verziónkat kicsit javították, módosították, teljesen mások a környezetek stb. Azt is érdemes megjegyezni, hogy talán egyszerűen nem tudom, hogyan kell helyesen elkészíteni a CS-t, és van néhány hatékonyabb módszer a munkára, és remélem, a megjegyzésekben megtudjuk. De először a dolgok.
Minden tesztet 4 szerverből álló hardverfürtön hajtottak végre, mindegyik a következő konfigurációval:
CPU: Xeon E5-2680 v4 @ 2.40 GHz, 64 szál.
Lemezek: 12 db SATA HDD
java verzió: 1.8.0_111
CS verzió: 3.11.5
cassandra.yml paramétereitoken_szám: 256
hinted_handoff_enabled: igaz
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
hitelesítő: AllowAllAuthenticator
Authorizer: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
particionáló: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /data1/cassandra/data # minden dataN könyvtár külön lemez
- /data2/cassandra/data
- /data3/cassandra/data
- /data4/cassandra/data
- /data5/cassandra/data
- /data6/cassandra/data
- /data7/cassandra/data
- /data8/cassandra/data
commitlog_könyvtár: /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
saved_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: periodikus
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
seed_provider:
- osztály_neve: org.apache.cassandra.locator.SimpleSeedProvider
paraméterek:
— magok: "*,*"
concurrent_reads: 256 # próbáltam 64 - nem vettem észre különbséget
concurrent_writes: 256 # próbáltam 64 - nem vettem észre különbséget
concurrent_counter_writes: 256 # próbáltam 64 - nem vettem észre különbséget
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # 16 GB-ot próbáltam - lassabb volt
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
tárolási_port: 7000
ssl_storage_port: 7001
listen_address: *
broadcast_address: *
listen_on_broadcast_address: igaz
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: igaz
natív_szállítási_port: 9042
start_rpc: igaz
rpc_address: *
rpc_port: 9160
rpc_keepalive: igaz
rpc_server_type: szinkronizálás
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_before_compaction: false
auto_snapshot: igaz
oszlop_index_mérete_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
dynamic_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: nincs
client_encryption_options:
engedélyezve: hamis
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:
engedélyezve: hamis
tombstone_warn_threshold: 1000
sírkő_meghibásodási_küszöbértéke: 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: false
enable_materialized_views: igaz
enable_sasi_indexes: igaz
GC beállítások:
### CMS-beállítások-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:Túlélőarány=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled
A jvm.options memóriába 16 Gb lett lefoglalva (mi is 32 Gb-tal próbálkoztunk, nem volt különbség).
A táblák a következő paranccsal készültek:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};HB-verzió: 1.2.0-cdh5.14.2 (az org.apache.hadoop.hbase.regionserver.HRegion osztályból kizártuk a MetricsRegiont, amely GC-hez vezetett, amikor a régiók száma meghaladta az 1000-et a RegionServeren)
Nem alapértelmezett HBase paraméterekzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 perc
hbase.client.scanner.timeout.period: 2 perc
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 perc
hbase.regionserver.handler.count: 160
hbase.regionsserver.metahandler.count: 30
hbase.regionsserver.logroll.period: 4 óra
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 nap
HBase szolgáltatás speciális konfigurációs részlete (biztonsági szelep) a hbase-site.xml fájlhoz:
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionsserver.optionalcacheflushinterval18000000
hbase.regionsserver.thread.compaction.large12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
Java konfigurációs beállítások a HBase RegionServer számára:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 perc
hbase.snapshot.region.timeout: 2 perc
hbase.snapshot.master.timeout.millis: 2 perc
HBase REST szerver Max naplóméret: 100 MiB
A HBase REST szerver naplófájljainak maximális biztonsági másolata: 5
HBase Thrift Server Max naplóméret: 100 MiB
A HBase Thrift Server naplófájl-mentések maximális száma: 5
Master Max naplóméret: 100 MiB
A naplófájl maximális biztonsági másolata: 5
RegionServer Max naplóméret: 100 MiB
A RegionServer naplófájljainak maximális biztonsági másolata: 5
HBase aktív mester észlelési ablak: 4 perc
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 ezredmásodperc
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Maximális folyamatfájl-leírók: 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.regionsserver.thread.comaction.small: 6
hbase.ipc.server.read.threadpool.size: 20
Régiómozgató szálak: 6
Kliens Java Heap mérete bájtban: 1 GiB
HBase REST kiszolgáló alapértelmezett csoportja: 3 GiB
HBase Thrift Server alapértelmezett csoport: 3 GiB
Java Heap HBase Master mérete bájtban: 16 GiB
A HBase RegionServer Java kupac mérete bájtban: 32 GiB
+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Táblázatok készítése:
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'}
Itt van egy fontos pont - a DataStax leírása nem mondja meg, hogy hány régiót használtak a HB táblák létrehozásához, bár ez kritikus nagy mennyiségek esetén. Ezért a tesztekhez a mennyiség = 64-et választottuk, ami akár 640 GB tárolást tesz lehetővé, pl. közepes méretű asztal.
A teszt idején a HBase 22 ezer táblával és 67 ezer régióval rendelkezett (ez halálos lett volna az 1.2.0-s verziónál, ha nem a fent említett javítás).
Most pedig a kódért. Mivel nem volt világos, hogy egy adott adatbázishoz mely konfigurációk előnyösebbek, a teszteket különféle kombinációkban végezték el. Azok. egyes teszteknél 4 tábla egyszerre lett betöltve (mind a 4 csomópontot használták a csatlakozáshoz). Más tesztekben 8 különböző táblázattal dolgoztunk. Egyes esetekben a köteg mérete 100, másokban 200 volt (kötegparaméter - lásd lent a kódot). Az érték adatmérete 10 bájt vagy 100 bájt (dataSize). Minden alkalommal összesen 5 millió rekordot írtak és olvastak be minden táblázatba. Ezzel egyidejűleg 5 szálat írtak/olvastak be minden táblába (szál száma - thNum), amelyek mindegyike saját kulcstartományt használt (szám = 1 millió):
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);
}
}
Ennek megfelelően a HB hasonló funkciókat biztosított:
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);
}
}
Mivel a HB-ben a kliensnek kell gondoskodnia az adatok egyenletes elosztásáról, a kulcssó funkció így nézett ki:
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);
}
Most a legérdekesebb rész - az eredmények:
Ugyanez grafikon formájában:
A HB előnye annyira meglepő, hogy felmerül a gyanú, hogy valami szűk keresztmetszet van a CS beállításban. Azonban a Google keresése és a legkézenfekvőbb paraméterek keresése (például a concurrent_writes vagy a memtable_heap_space_in_mb) nem gyorsította fel a dolgokat. Ugyanakkor a rönkök tiszták és nem káromkodnak semmire.
Az adatok egyenletesen oszlanak el a csomópontok között, az összes csomópont statisztikái megközelítőleg azonosak voltak.
Így néz ki a táblázat statisztikája az egyik csomópontbólBillentyűköz: ks
Olvasásszám: 9383707
Olvasási késleltetés: 0.04287025042448576 ms
Írásszám: 15462012
Írási késleltetés: 0.1350068438699957 ms
Függőben lévő öblítések: 0
táblázat: t1
SST-táblák száma: 16
Felhasznált terület (élő): 148.59 MiB
Felhasznált terület (összesen): 148.59 MiB
Pillanatképek által használt terület (összesen): 0 bájt
Felhasznált nem halom memória (összesen): 5.17 MiB
SSTable tömörítési arány: 0.5720989576459437
Partíciók száma (becslés): 3970323
Megjegyezhető sejtszám: 0
Megjegyezhető adatméret: 0 bájt
Memtable off heap memória felhasznált: 0 bájt
Megjegyezhető kapcsolók száma: 5
Helyi olvasottság: 2346045
Helyi olvasási késleltetés: NaN ms
Helyi írásszám: 3865503
Helyi írási késleltetés: NaN ms
Függőben lévő flush: 0
Javított százalék: 0.0
Bloom szűrő hamis pozitív: 25
Bloom szűrő hamis arány: 0.00000
Felhasznált Bloom szűrőterület: 4.57 MiB
Bloom szűrő, felhasznált kupac memória: 4.57 MiB
A felhasznált kupac memória indexösszegzése: 590.02 KiB
Tömörítési metaadatok a kupac memóriájából: 19.45 KiB
A tömörített partíció minimális bájtja: 36
Tömörített partíció maximális bájtja: 42
A tömörített partíció átlagos bájtja: 42
Átlagos élő sejtek száma szeletenként (utolsó öt perc): NaN
Maximális élő sejtek száma szeletenként (utolsó öt perc): 0
Átlagos sírkövek szeletenként (utolsó öt perc): NaN
Maximális sírkövek szeletenként (utolsó öt perc): 0
Eldobott mutációk: 0 bájt
A köteg méretének csökkentésére tett kísérlet (akár egyenként küldve) nem járt eredménnyel, csak rosszabb lett. Lehetséges, hogy valójában ez a maximális teljesítmény a CS-nél, mivel a CS-re kapott eredmények hasonlóak a DataStax-nál kapott eredményekhez - körülbelül több százezer művelet másodpercenként. Ezen kívül, ha megnézzük az erőforrás-kihasználást, látni fogjuk, hogy a CS sokkal több CPU-t és lemezt használ:
Az ábra az összes teszt futása közbeni kihasználtságát mutatja mindkét adatbázis esetében.
Ami a HB erőteljes olvasási előnyét illeti. Itt látható, hogy mindkét adatbázis esetében rendkívül alacsony a lemezhasználat az olvasás során (az olvasási tesztek jelentik az egyes adatbázisok tesztelési ciklusának utolsó részét, például a CS-nél ez 15:20-tól 15:40-ig tart). A HB esetében az ok egyértelmű - az adatok nagy része a memóriában, a memstore-ban lóg, néhány pedig a blokkgyorsítótárban tárolódik. Ami a CS-t illeti, nem nagyon világos, hogyan működik, de a lemez újrahasznosítása sem látható, de minden esetre megpróbálták engedélyezni a row_cache_size_in_mb = 2048 gyorsítótárat, és beállítani a caching = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, de ez még egy kicsit rosszabbá tette a helyzetet.
Érdemes még egyszer megemlíteni egy fontos pontot a HB régióinak számáról. Esetünkben az értéket 64-re adtuk meg. Ha csökkenti, és például 4-gyel egyenlővé teszi, akkor olvasáskor a sebesség 2-szeresére csökken. Ennek az az oka, hogy a memstore gyorsabban megtelik, a fájlok gyakrabban ürülnek ki, és olvasás közben több fájlt kell feldolgozni, ami a HB számára meglehetősen bonyolult művelet. Valós körülmények között ezt egy előfelosztási és tömörítési stratégia átgondolásával lehet kezelni, konkrétan egy saját írású segédprogramot használunk, amely összegyűjti a szemetet és a háttérben folyamatosan tömöríti a HFiles-eket. Elképzelhető, hogy a DataStax tesztekhez csak 1 régiót jelöltek ki táblánként (ami nem helyes), és ez némileg megvilágítaná, hogy a HB miért volt ennyire gyengébb az olvasási tesztjeikben.
Ebből a következő előzetes következtetéseket vonjuk le. Feltéve, hogy a tesztelés során nem követtek el komolyabb hibákat, akkor Cassandra úgy néz ki, mint egy agyagtalpú kolosszus. Pontosabban, miközben egy lábon egyensúlyoz, mint a cikk elején látható képen, viszonylag jó eredményeket mutat fel, de az azonos körülmények között vívott küzdelemben egyenesen veszít. Ugyanakkor, figyelembe véve a hardverünk alacsony CPU-kihasználását, megtanultunk állomásonként két RegionServer HB-t telepíteni, és ezzel megdupláztuk a teljesítményt. Azok. Az erőforrások felhasználását figyelembe véve a CS helyzete még siralmasabb.
Természetesen ezek a tesztek meglehetősen szintetikusak, és az itt felhasznált adatok mennyisége viszonylag szerény. Lehetséges, hogy ha terabájtra váltanánk, más lenne a helyzet, de míg HB-nél tudunk terabájtokat tölteni, addig a CS-nél ez problémásnak bizonyult. Gyakran még ezeknél a köteteknél is dobott OperationTimedOutException-t, bár a válaszvárás paraméterei már többszörösére nőttek az alapértelmezettekhez képest.
Bízom benne, hogy közös erővel megtaláljuk a CS szűk keresztmetszeteit, és ha sikerül felgyorsítani, akkor a poszt végén mindenképpen a végeredményről is beszámolok.
UPD: Az elvtársak tanácsainak köszönhetően sikerült felgyorsítani az olvasást. Volt:
159 644 művelet (4 asztal, 5 stream, 100-as köteg).
Írta:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
És eljátszottam a szálak számával. Az eredmény a következő:
4 asztal, 100 szál, köteg = 1 (darabonként): 301 969 művelet
4 asztal, 100 szál, köteg = 10: 447 608 művelet
4 asztal, 100 szál, köteg = 100: 625 655 művelet
Később más hangolási tippeket is alkalmazok, lefuttatok egy teljes tesztciklust, és az eredményeket a bejegyzés végére adom.
Forrás: will.com