To niti ni šala, zdi se, da prav ta slika najbolj natančno odraža bistvo teh baz podatkov in na koncu bo jasno, zakaj:
Glede na DB-Engines Ranking sta dve najbolj priljubljeni stolpčni bazi podatkov NoSQL Cassandra (v nadaljevanju CS) in HBase (HB).
Po volji usode je naša ekipa za upravljanje nalaganja podatkov pri Sberbank že in tesno sodeluje s HB. V tem času smo dodobra preučili njegove prednosti in slabosti ter se ga naučili kuhati. Vendar nas je prisotnost alternative v obliki CS vedno prisilila, da smo se nekoliko mučili z dvomi: ali smo se pravilno odločili? Še več, rezultati , ki ga izvaja DataStax, so rekli, da CS zlahka premaga HB s skoraj poraznim rezultatom. Po drugi strani pa je DataStax zainteresirana stranka in ne bi smeli verjeti njihovi besedi. Zmedlo nas je tudi precej malo podatkov o pogojih testiranja, zato smo se odločili sami ugotoviti, kdo je kralj BigData NoSql, in dobljeni rezultati so se izkazali za zelo zanimive.
Preden pa preidemo na rezultate izvedenih testov, je treba opisati pomembne vidike konfiguracij okolja. Dejstvo je, da je CS mogoče uporabljati v načinu, ki omogoča izgubo podatkov. Tisti. to je takrat, ko je za podatke določenega ključa odgovoren samo en strežnik (vozlišče) in če iz nekega razloga odpove, se vrednost tega ključa izgubi. Za mnoge naloge to ni kritično, za bančni sektor pa je to prej izjema kot pravilo. V našem primeru je za zanesljivo shranjevanje pomembno imeti več kopij podatkov.
Zato je bil upoštevan samo način delovanja CS v načinu trojne replikacije, t.j. Ustvarjanje prostora za primere je bilo izvedeno z naslednjimi parametri:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Nato obstajata dva načina za zagotovitev zahtevane ravni doslednosti. Splošno pravilo:
SZ + NR > RF
Kar pomeni, da mora biti število potrditev iz vozlišč pri pisanju (NW) plus število potrditev iz vozlišč pri branju (NR) večje od faktorja podvajanja. V našem primeru je RF = 3, kar pomeni, da so primerne naslednje možnosti:
2 + 2 > 3
3 + 1 > 3
Ker je za nas bistveno čim bolj zanesljivo shranjevanje podatkov, je bila izbrana shema 3+1. Poleg tega HB deluje na podobnem principu, tj. taka primerjava bo bolj poštena.
Opozoriti je treba, da je DataStax v svoji študiji naredil ravno nasprotno, tako za CS kot HB (za slednjega s spremembo nastavitev HDFS) je nastavil RF = 1. To je res pomemben vidik, ker je vpliv na zmogljivost CS v tem primeru ogromen. Spodnja slika na primer prikazuje povečanje časa, potrebnega za nalaganje podatkov v CS:
Tukaj vidimo naslednje: več konkurenčnih niti piše podatke, dlje traja. To je naravno, vendar je pomembno, da je poslabšanje zmogljivosti za RF=3 znatno večje. Z drugimi besedami, če zapišemo 4 niti v 5 tabele vsako (skupaj 20), potem RF=3 izgubi približno 2-krat (150 sekund za RF=3 v primerjavi s 75 za RF=1). Če pa povečamo obremenitev z nalaganjem podatkov v 8 tabel s po 5 niti (skupaj 40), potem je izguba RF=3 že 2,7-kratna (375 sekund proti 138).
Morda je tudi to delno skrivnost uspešnega obremenitvenega testiranja, ki ga je DataStax izvedel za CS, saj za HB na naši stojnici sprememba replikacijskega faktorja iz 2 na 3 ni imela nobenega učinka. Tisti. diski niso ozko grlo HB za našo konfiguracijo. Je pa tu še veliko drugih pasti, saj je treba opozoriti, da je bila naša različica HB nekoliko popravljena in prirejena, okolja so popolnoma drugačna itd. Omeniti velja tudi, da morda preprosto ne vem, kako pravilno pripraviti CS in obstaja nekaj bolj učinkovitih načinov za delo z njim, in upam, da bomo izvedeli v komentarjih. Ampak najprej.
Vsi testi so bili izvedeni na gruči strojne opreme, sestavljeni iz 4 strežnikov, vsak z naslednjo konfiguracijo:
CPU: Xeon E5-2680 v4 @ 2.40 GHz 64 niti.
Diski: 12 kosov SATA HDD
različica java: 1.8.0_111
Različica CS: 3.11.5
parametri cassandra.ymlštevilo_žetonov: 256
hinted_handoff_enabled: res
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
imenik_namigov: /data10/cassandra/hints
hints_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
avtentifikator: AllowAllAuthenticator
avtorizator: AllowAllAuthorizer
role_manager: CassandraRoleManager
role_validity_in_ms: 2000
dovoljenja_veljavnost_v_ms: 2000
credentials_validity_in_ms: 2000
razdelilnik: org.apache.cassandra.dht.Murmur3Partitioner
imeniki_podatkovnih_datotek:
- /data1/cassandra/data # vsak imenik dataN je ločen 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
pripravljeni_izjave_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
imenik_shranjenih_caches: /data10/cassandra/saved_caches
commitlog_sync: periodično
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
seed_provider:
- ime_razreda: org.apache.cassandra.locator.SimpleSeedProvider
parametri:
— semena: "*,*"
concurrent_reads: 256 # preizkušeno 64 - ni opaziti nobene razlike
concurrent_writes: 256 # poskusil 64 - ni opaziti nobene razlike
concurrent_counter_writes: 256 # poskusil 64 - ni opaziti nobene razlike
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # poskusil 16 GB - bilo je počasneje
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: napačno
trickle_fsync_interval_in_kb: 10240
vrata za shranjevanje: 7000
ssl_storage_port: 7001
poslušaj_naslov: *
oddajni_naslov: *
listen_on_broadcast_address: res
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: res
native_transport_port: 9042
start_rpc: res
rpc_naslov: *
rpc_vrata: 9160
rpc_keepalive: drži
rpc_server_type: sinhronizacija
thrift_framed_transport_size_in_mb: 15
inkrementalne_varnostne kopije: false
snapshot_before_compaction: false
auto_snapshot: res
velikost_indeksa_stolpca_v_kb: 64
column_index_cache_size_in_kb: 2
sočasni_kompaktorji: 4
pretok_zgoščevanja_mb_na_sek: 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
dinamični_snitch_badness_threshold: 0.1
razporejevalnik_zahtev: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: brez
client_encryption_options:
omogočeno: napačno
kompresija_internodija: dc
inter_dc_tcp_nodelay: napačno
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: false
enable_scripted_user_defined_functions: false
windows_timer_interval: 1
transparentne_možnosti_šifriranja_podatkov:
omogočeno: napačno
tombstone_warn_threshold: 1000
nagrobnik_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: false
enable_materialized_views: res
enable_sasi_indexes: res
Nastavitve GC:
### Nastavitve CMS-XX:+UporabiParNewGC
-XX:+Uporabi ConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:Razmerje preživelih=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled
Pomnilniku jvm.options je bilo dodeljenih 16 Gb (poskusili smo tudi 32 Gb, razlike ni bilo opaziti).
Tabele so bile ustvarjene z ukazom:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};Različica HB: 1.2.0-cdh5.14.2 (v razredu org.apache.hadoop.hbase.regionserver.HRegion smo izključili MetricsRegion, kar je vodilo do GC, ko je bilo število regij več kot 1000 na RegionServer)
Parametri HBase, ki niso privzetizookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 minuti
hbase.client.scanner.timeout.period: 2 minuti
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 minuti
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: 4 ure
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 dan(-i)
Izrezek napredne konfiguracije storitve HBase (varnostni ventil) za 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
Možnosti konfiguracije Java za HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 minuti
hbase.snapshot.region.timeout: 2 minuti
hbase.snapshot.master.timeout.millis: 2 minuti
Največja velikost dnevnika strežnika HBase REST: 100 MiB
Največje število varnostnih kopij dnevniških datotek strežnika HBase REST: 5
HBase Thrift Server Največja velikost dnevnika: 100 MiB
HBase Thrift Server Največje število varnostnih kopij dnevniških datotek: 5
Največja velikost glavnega dnevnika: 100 MiB
Glavno največje varnostno kopiranje dnevniških datotek: 5
Največja velikost dnevnika RegionServer: 100 MiB
Največje število varnostnih kopij dnevniških datotek RegionServer: 5
Okno zaznavanja aktivnega glavnega HBase: 4 minute
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 milisekund(e)
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
Največje dovoljeno število deskriptorjev procesnih datotek: 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
Niti za premikanje regij: 6
Velikost odjemalske kopice Java v bajtih: 1 GiB
Privzeta skupina strežnika HBase REST: 3 GiB
Privzeta skupina HBase Thrift Server: 3 GiB
Velikost kopice Java HBase Master v bajtih: 16 GiB
Velikost kopice Java HBase RegionServer v bajtih: 32 GiB
+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Ustvarjanje tabel:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
spremeni 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}
Tukaj je ena pomembna točka - opis DataStax ne pove, koliko regij je bilo uporabljenih za ustvarjanje tabel HB, čeprav je to kritično za velike količine. Zato je bila za teste izbrana količina = 64, ki omogoča shranjevanje do 640 GB, tj. srednje velika miza.
HBase je imel v času preizkusa 22 tisoč tabel in 67 tisoč regij (to bi bilo smrtonosno za različico 1.2.0, če ne bi bilo zgoraj omenjenega popravka).
Zdaj pa koda. Ker ni bilo jasno, katere konfiguracije so za posamezno bazo ugodnejše, so bili testi izvedeni v različnih kombinacijah. Tisti. v nekaterih testih so bile naložene 4 tabele hkrati (vsa 4 vozlišča so bila uporabljena za povezavo). V drugih testih smo delali z 8 različnimi tabelami. V nekaterih primerih je bila velikost serije 100, v drugih 200 (parameter serije - glej kodo spodaj). Velikost podatkov za vrednost je 10 bajtov ali 100 bajtov (dataSize). Skupno je bilo v vsako tabelo vsakič zapisanih in prebranih 5 milijonov zapisov. Istočasno je bilo v vsako tabelo zapisanih/branih 5 niti (številka niti - thNum), od katerih je vsaka uporabljala svoj obseg ključev (štetje = 1 milijon):
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 skladu s tem je bila za HB zagotovljena podobna funkcionalnost:
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);
}
}
Ker mora v HB odjemalec skrbeti za enakomerno porazdelitev podatkov, je ključna funkcija soljenja izgledala takole:
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);
}
Zdaj pa najbolj zanimiv del - rezultati:
Ista stvar v obliki grafa:
Prednost HB je tako presenetljiva, da obstaja sum, da obstaja nekakšno ozko grlo v nastavitvi CS. Vendar googlanje in iskanje najbolj očitnih parametrov (kot so concurrent_writes ali memtable_heap_space_in_mb) stvari nista pospešila. Hkrati so hlodi čisti in ne prisegajo na nič.
Podatki so bili enakomerno porazdeljeni po vozliščih, statistika vseh vozlišč je bila približno enaka.
Tako izgleda statistika tabele iz enega od vozliščTipkovnica: ks
Število branj: 9383707
Zakasnitev branja: 0.04287025042448576 ms
Število zapisov: 15462012
Zakasnitev pisanja: 0.1350068438699957 ms
Čakajoče izpiranja: 0
Tabela: t1
Število tabele SST: 16
Porabljen prostor (v živo): 148.59 MiB
Porabljen prostor (skupaj): 148.59 MiB
Prostor, ki ga uporabljajo posnetki (skupaj): 0 bajtov
Uporabljen pomnilnik izven kopice (skupaj): 5.17 MiB
Kompresijsko razmerje SSTable: 0.5720989576459437
Število particij (ocena): 3970323
Število memtabilnih celic: 0
Velikost pomnilnih podatkov: 0 bajtov
Uporabljen pomnilnik izven kopice memtable: 0 bajtov
Število stikal Memtable: 5
Lokalno število bralcev: 2346045
Lokalna zakasnitev branja: NaN ms
Lokalno število zapisov: 3865503
Lokalna zakasnitev pisanja: NaN ms
Čakajoče splakovanje: 0
Odstotek popravljenega: 0.0
Lažno pozitivni rezultati filtra Bloom: 25
Napačno razmerje filtra Bloom: 0.00000
Uporabljen prostor za filter Bloom: 4.57 MiB
Uporabljen pomnilnik kopice Bloom filter off: 4.57 MiB
Povzetek indeksa izven uporabljenega pomnilnika kopice: 590.02 KiB
Metapodatki o stiskanju iz uporabljenega pomnilnika kopice: 19.45 KiB
Najmanjši bajt stisnjene particije: 36
Največ bajtov stisnjene particije: 42
Srednja vrednost bajtov stisnjene particije: 42
Povprečno število živih celic na rezino (zadnjih pet minut): NaN
Največje število živih celic na rezino (zadnjih pet minut): 0
Povprečno število nagrobnikov na rezino (zadnjih pet minut): NaN
Največje število nagrobnikov na rezino (zadnjih pet minut): 0
Izpuščene mutacije: 0 bajtov
Poskus zmanjševanja velikosti paketa (tudi pošiljanje posamezno) ni imel učinka, bilo je le še slabše. Možno je, da je dejansko to res največja zmogljivost za CS, saj so rezultati, dobljeni za CS, podobni tistim, dobljenim za DataStax - približno sto tisoč operacij na sekundo. Poleg tega, če pogledamo izkoriščenost virov, bomo videli, da CS uporablja veliko več CPU in diskov:
Slika prikazuje izkoriščenost med izvajanjem vseh testov po vrsti za obe podatkovni bazi.
Glede močne bralne prednosti HB. Tukaj lahko vidite, da je za obe bazi podatkov izkoriščenost diska med branjem izjemno nizka (testi branja so zadnji del cikla testiranja za vsako bazo podatkov, npr. za CS je to od 15:20 do 15:40). V primeru HB je razlog jasen - večina podatkov visi v pomnilniku, v memstoreju, nekaj pa je predpomnjenih v blockcacheju. Kar zadeva CS, ni zelo jasno, kako deluje, vendar tudi recikliranje diska ni vidno, a za vsak slučaj je bil poskus omogočiti predpomnilnik row_cache_size_in_mb = 2048 in nastaviti predpomnilnik = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, vendar je bilo to še nekoliko slabše.
Prav tako je treba še enkrat omeniti pomembno točko glede števila regij v HB. V našem primeru je bila vrednost določena kot 64. Če jo zmanjšate in naredite enako, na primer 4, potem pri branju hitrost pade za 2-krat. Razlog je v tem, da se bo memstore hitreje napolnil in datoteke se bodo pogosteje splakovale, pri branju pa bo treba obdelati več datotek, kar je za HB precej zapletena operacija. V resničnih razmerah je to mogoče rešiti tako, da razmislimo o strategiji predrazcepitve in kompaktifikacije; zlasti uporabljamo samonapisani pripomoček, ki v ozadju nenehno zbira smeti in stisne datoteke H. Povsem možno je, da so za teste DataStax dodelili samo 1 regijo na tabelo (kar ni pravilno) in to bi nekoliko pojasnilo, zakaj je bil HB tako slabši v njihovih testih branja.
Iz tega izhajajo naslednji predhodni sklepi. Če predpostavimo, da med testiranjem ni prišlo do večjih napak, je Cassandra videti kot kolos z glinenimi nogami. Natančneje, medtem ko ravnotežje na eni nogi, kot je na sliki na začetku članka, kaže razmeroma dobre rezultate, v boju pod enakimi pogoji pa popolnoma izgubi. Ob istem času, ob upoštevanju nizke izkoriščenosti procesorja na naši strojni opremi, smo se naučili postaviti dva RegionServer HB na gostitelja in s tem podvojiti zmogljivost. Tisti. Glede na izkoriščenost sredstev je položaj ČS še bolj obžalovanja vreden.
Seveda so ti testi precej sintetični in količina uporabljenih podatkov je razmeroma skromna. Možno je, da bi bila situacija drugačna, če bi prešli na terabajte, a medtem ko pri HB lahko nalagamo terabajte, se je pri CS izkazalo, da je to problematično. Tudi pri teh nosilcih je pogosto vrgel izjemo OperationTimedOutException, čeprav so bili parametri za čakanje na odgovor že večkrat povečani v primerjavi s privzetimi.
Upam, da bomo s skupnimi močmi našli ozka grla CS in če ga bomo lahko pospešili, potem bom na koncu objave zagotovo dodal informacijo o končnih rezultatih.
UPD: Zahvaljujoč nasvetom tovarišev mi je uspelo pospešiti branje. je bilo:
159 operacij (644 tabele, 4 tokov, paket 5).
Dodano:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
In igral sem se s številom niti. Rezultat je naslednji:
4 tabele, 100 niti, serija = 1 (kos za kosom): 301 operacij
4 tabele, 100 niti, serija = 10: 447 operacij
4 tabele, 100 niti, serija = 100: 625 operacij
Kasneje bom uporabil druge nasvete za uglaševanje, izvedel celoten preskusni cikel in dodal rezultate na koncu objave.
Vir: www.habr.com