Ово није чак ни шала, чини се да ова конкретна слика најтачније одражава суштину ових база података, а на крају ће бити јасно зашто:
Према рангирању ДБ-Енгинес, две најпопуларније НоСКЛ колонске базе података су Цассандра (у даљем тексту ЦС) и ХБасе (ХБ).
Вољом судбине, наш тим за управљање учитавањем података у Сбербанци већ јесте и блиско сарађује са ХБ. За то време смо прилично добро проучили његове предности и мане и научили како да га кувамо. Међутим, присуство алтернативе у виду ЦС увек нас је терало да се мало мучимо сумњама: да ли смо направили прави избор? Штавише, резултати , у изведби ДатаСтак-а, рекли су да ЦС лако побеђује ХБ са скоро поразним резултатом. С друге стране, ДатаСтак је заинтересована страна и не би требало да им верујете на реч. Збунила нас је и прилично мала количина информација о условима тестирања, па смо одлучили да сами сазнамо ко је краљ БигДата НоСкл-а, а добијени резултати су се показали веома занимљивим.
Међутим, пре него што пређемо на резултате спроведених тестова, неопходно је описати значајне аспекте конфигурације окружења. Чињеница је да се ЦС може користити у режиму који омогућава губитак података. Оне. ово је када је само један сервер (чвор) одговоран за податке одређеног кључа, а ако из неког разлога не успе, онда ће вредност овог кључа бити изгубљена. За многе послове ово није критично, али за банкарски сектор ово је пре изузетак него правило. У нашем случају, важно је имати неколико копија података за поуздано складиштење.
Стога је разматран само режим рада ЦС у режиму троструке репликације, тј. Креирање простора случаја је обављено са следећим параметрима:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Затим, постоје два начина да се обезбеди потребан ниво доследности. Опште правило:
НВ + НР > РФ
Што значи да број потврда из чворова при писању (НВ) плус број потврда из чворова при читању (НР) мора бити већи од фактора репликације. У нашем случају, РФ = 3, што значи да су следеће опције погодне:
2 + 2 > 3
3 + 1 > 3
Пошто нам је суштински важно да податке чувамо што је могуће поузданије, изабрана је шема 3+1. Поред тога, ХБ ради на сличном принципу, тј. такво поређење ће бити праведније.
Треба напоменути да је ДатаСтак у својој студији урадио супротно, поставили су РФ = 1 и за ЦС и за ХБ (за последње променом ХДФС подешавања). Ово је заиста важан аспект јер је утицај на перформансе ЦС-а у овом случају огроман. На пример, слика испод показује повећање времена потребног за учитавање података у ЦС:
Овде видимо следеће: што више конкурентских нити записује податке, то дуже траје. Ово је природно, али је важно да је деградација перформанси за РФ=3 знатно већа. Другим речима, ако упишемо 4 нити у 5 табеле (укупно 20), онда РФ=3 губи око 2 пута (150 секунди за РФ=3 наспрам 75 за РФ=1). Али ако повећамо оптерећење учитавањем података у 8 табела са по 5 нити (укупно 40), онда је губитак РФ=3 већ 2,7 пута (375 секунди наспрам 138).
Можда је то делимично тајна успешног тестирања оптерећења које је извршио ДатаСтак за ЦС, јер за ХБ на нашем штанду промена фактора репликације са 2 на 3 није имала никаквог ефекта. Оне. дискови нису ХБ уско грло за нашу конфигурацију. Међутим, овде има много других замки, јер треба напоменути да је наша верзија ХБ-а мало закрпљена и дотерана, окружења су потпуно другачија итд. Такође је вредно напоменути да можда једноставно не знам како да правилно припремим ЦС и да постоје неки ефикаснији начини за рад са њим, а надам се да ћемо то сазнати у коментарима. Али прво ствари.
Сви тестови су обављени на хардверском кластеру који се састоји од 4 сервера, сваки са следећом конфигурацијом:
ЦПУ: Ксеон Е5-2680 в4 @ 2.40 ГХз 64 нити.
Дискови: 12 комада САТА ХДД
јава верзија: 1.8.0_111
ЦС верзија: 3.11.5
цассандра.имл параметриброј_жетона: 256
хинтед_хандофф_енаблед: истина
хинтед_хандофф_тхроттле_ин_кб: 1024
мак_хинтс_деливери_тхреадс: 2
хинтс_дирецтори: /дата10/цассандра/хинтс
хинтс_флусх_период_ин_мс: 10000
мак_хинтс_филе_сизе_ин_мб: 128
батцхлог_реплаи_тхроттле_ин_кб: 1024
аутентификатор: АлловАллАутхентицатор
ауторизатор: АлловАллАутхоризер
роле_манагер: ЦассандраРолеМанагер
ролес_валидити_ин_мс: 2000
пермиссионс_валидити_ин_мс: 2000
цредентиалс_валидити_ин_мс: 2000
партиционер: орг.апацхе.цассандра.дхт.Мурмур3Партитионер
директоријуми_датотека_података:
- /дата1/цассандра/дата # сваки датаН директоријум је засебан диск
- /дата2/цассандра/дата
- /дата3/цассандра/дата
- /дата4/цассандра/дата
- /дата5/цассандра/дата
- /дата6/цассандра/дата
- /дата7/цассандра/дата
- /дата8/цассандра/дата
цоммитлог_дирецтори: /дата9/цассандра/цоммитлог
цдц_енаблед: нетачно
диск_фаилуре_полици: стоп
цоммит_фаилуре_полици: стоп
реади_статементс_цацхе_сизе_мб:
тхрифт_препаред_статементс_цацхе_сизе_мб:
кеи_цацхе_сизе_ин_мб:
кеи_цацхе_саве_период: 14400
ров_цацхе_сизе_ин_мб: 0
ров_цацхе_саве_период: 0
цоунтер_цацхе_сизе_ин_мб:
цоунтер_цацхе_саве_период: 7200
савед_цацхес_дирецтори: /дата10/цассандра/савед_цацхес
цоммитлог_синц: периодично
цоммитлог_синц_период_ин_мс: 10000
цоммитлог_сегмент_сизе_ин_мб: 32
сеед_провидер:
- име_класе: орг.апацхе.цассандра.лоцатор.СимплеСеедПровидер
параметри:
— семена: "*,*"
цонцуррент_реадс: 256 # покушао 64 - није примећена разлика
цонцуррент_вритес: 256 # покушао 64 - није примећена разлика
цонцуррент_цоунтер_вритес: 256 # покушао 64 - није примећена разлика
цонцуррент_материализед_виев_вритес: 32
мемтабле_хеап_спаце_ин_мб: 2048 # покушао 16 ГБ - било је спорије
мемтабле_аллоцатион_типе: хеап_буфферс
индек_суммари_цапацити_ин_мб:
индек_суммари_ресизе_интервал_ин_минутес: 60
трицкле_фсинц: нетачно
трицкле_фсинц_интервал_ин_кб: 10240
порт за складиштење: 7000
ссл_стораге_порт: 7001
Адреса_слушања: *
Адреса_емитовања: *
листен_он_броадцаст_аддресс: истина
интерноде_аутхентицатор: орг.апацхе.цассандра.аутх.АлловАллИнтернодеАутхентицатор
старт_нативе_транспорт: тачно
нативе_транспорт_порт: 9042
старт_рпц: истина
рпц_аддресс: *
рпц_порт: 9160
рпц_кеепаливе: истина
рпц_сервер_типе: синц
тхрифт_фрамед_транспорт_сизе_ин_мб: 15
инкременталне_резервне копије: нетачно
снапсхот_бефоре_цомпацтион: нетачно
ауто_снапсхот: истина
величина_индекса_колоне_у_кб: 64
цолумн_индек_цацхе_сизе_ин_кб: 2
истовремени_компактори: 4
цомпацтион_тхроугхпут_мб_пер_сец: 1600
сстабле_преемптиве_опен_интервал_ин_мб: 50
реад_рекуест_тимеоут_ин_мс: 100000
ранге_рекуест_тимеоут_ин_мс: 200000
врите_рекуест_тимеоут_ин_мс: 40000
цоунтер_врите_рекуест_тимеоут_ин_мс: 100000
цас_цонтентион_тимеоут_ин_мс: 20000
трунцате_рекуест_тимеоут_ин_мс: 60000
рекуест_тимеоут_ин_мс: 200000
слов_куери_лог_тимеоут_ин_мс: 500
цросс_ноде_тимеоут: нетачно
ендпоинт_снитцх: ГоссипингПропертиФилеСнитцх
динамиц_снитцх_упдате_интервал_ин_мс: 100
динамиц_снитцх_ресет_интервал_ин_мс: 600000
динамиц_снитцх_баднесс_тхресхолд: 0.1
рекуест_сцхедулер: орг.апацхе.цассандра.сцхедулер.НоСцхедулер
сервер_енцриптион_оптионс:
интерноде_енцриптион: нема
цлиент_енцриптион_оптионс:
омогућено: нетачно
интерноде_цомпрессион: дц
интер_дц_тцп_ноделаи: нетачно
трацетипе_куери_ттл: 86400
трацетипе_репаир_ттл: 604800
енабле_усер_дефинед_фунцтионс: нетачно
енабле_сцриптед_усер_дефинед_фунцтионс: нетачно
виндовс_тимер_интервал: 1
транспарент_дата_енцриптион_оптионс:
омогућено: нетачно
томбстоне_варн_тхресхолд: 1000
томбстоне_фаилуре_тхресхолд: 100000
батцх_сизе_варн_тхресхолд_ин_кб: 200
батцх_сизе_фаил_тхресхолд_ин_кб: 250
унлоггед_батцх_ацросс_партитионс_варн_тхресхолд: 10
цомпацтион_ларге_партитион_варнинг_тхресхолд_мб: 100
гц_варн_тхресхолд_ин_мс: 1000
бацк_прессуре_енаблед: нетачно
енабле_материализед_виевс: истина
енабле_саси_индекес: истина
ГЦ подешавања:
### ЦМС подешавања-КСКС:+УсеПарНевГЦ
-КСКС:+УсеЦонцМаркСвеепГЦ
-КСКС:+ЦМСПараллелРемаркЕнаблед
-КСКС:СурвиворРатио=8
-КСКС:МакТенурингТхресхолд=1
-КСКС:ЦМСИнитиатингОццупанциФрацтион=75
-КСКС:+УсеЦМСИнитиатингОццупанциОнли
-КСКС:ЦМСВаитДуратион=10000
-КСКС:+ЦМСПараллелИнитиалМаркЕнаблед
-КСКС:+ЦМСЕденЦхунксРецордАлваис
-КСКС:+ЦМСЦлассУнлоадингЕнаблед
Меморији јвм.оптионс је додељено 16Гб (пробали смо и 32Гб, разлика није примећена).
Табеле су креиране командом:
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};ХБ верзија: 1.2.0-цдх5.14.2 (у класи орг.апацхе.хадооп.хбасе.регионсервер.ХРегион искључили смо МетрицсРегион што је довело до ГЦ-а када је број региона био већи од 1000 на РегионСерверу)
ХБасе параметри нису подразумеванизоокеепер.сессион.тимеоут: 120000
хбасе.рпц.тимеоут: 2 минута
хбасе.цлиент.сцаннер.тимеоут.период: 2 минута
хбасе.мастер.хандлер.цоунт: 10
хбасе.регионсервер.леасе.период, хбасе.цлиент.сцаннер.тимеоут.период: 2 минута
хбасе.регионсервер.хандлер.цоунт: 160
хбасе.регионсервер.метахандлер.цоунт: 30
хбасе.регионсервер.логролл.период: 4 сат(а)
хбасе.регионсервер.маклогс: 200
хбасе.хрегион.мемсторе.флусх.сизе: 1 ГиБ
хбасе.хрегион.мемсторе.блоцк.мултиплиер: 6
хбасе.хсторе.цомпацтионТхресхолд: 5
хбасе.хсторе.блоцкингСтореФилес: 200
хбасе.хрегион.мајорцомпацтион: 1 дан(а)
Исечак напредне конфигурације услуге ХБасе (сигурносни вентил) за хбасе-сите.кмл:
хбасе.регионсервер.вал.цодецорг.апацхе.хадооп.хбасе.регионсервер.вал.ИндекедВАЛЕдитЦодец
хбасе.мастер.намеспаце.инит.тимеоут3600000
хбасе.регионсервер.оптионалцацхефлусхинтервал18000000
хбасе.регионсервер.тхреад.цомпацтион.ларге12
хбасе.регионсервер.вал.енаблецомпрессионтруе
хбасе.хсторе.цомпацтион.мак.сизе1073741824
хбасе.сервер.цомпацтцхецкер.интервал.мултиплиер200
Опције конфигурације Јава за ХБасе РегионСервер:
-КСКС:+УсеПарНевГЦ -КСКС:+УсеЦонцМаркСвеепГЦ -КСКС:ЦМСИнитиатингОццупанциФрацтион=70 -КСКС:+ЦМСПараллелРемаркЕнаблед -КСКС:РесерведЦодеЦацхеСизе=256м
хбасе.снапсхот.мастер.тимеоутМиллис: 2 минута
хбасе.снапсхот.регион.тимеоут: 2 минута
хбасе.снапсхот.мастер.тимеоут.миллис: 2 минута
Максимална величина дневника ХБасе РЕСТ сервера: 100 МиБ
Максимална резервна копија датотеке дневника ХБасе РЕСТ сервера: 5
Максимална величина дневника ХБасе Тхрифт сервера: 100 МиБ
Максималне резервне копије датотека дневника ХБасе Тхрифт Сервер: 5
Мастер максимална величина дневника: 100 МиБ
Максимална резервна копија датотеке дневника: 5
Максимална величина дневника РегионСервера: 100 МиБ
Максимална резервна копија датотеке дневника РегионСервер: 5
ХБасе Ацтиве Мастер Детецтион Винд: 4 минуте (с)
дфс.цлиент.хедгед.реад.тхреадпоол.сизе: 40
дфс.цлиент.хедгед.реад.тхресхолд.миллис: 10 милисекунди
хбасе.рест.тхреадс.мин: 8
хбасе.рест.тхреадс.мак: 150
Максимални дескриптори датотеке процеса: 180000
хбасе.тхрифт.минВоркерТхреадс: 200
хбасе.мастер.екецутор.опенрегион.тхреадс: 30
хбасе.мастер.екецутор.цлосерегион.тхреадс: 30
хбасе.мастер.екецутор.серверопс.тхреадс: 60
хбасе.регионсервер.тхреад.цомпацтион.смалл: 6
хбасе.ипц.сервер.реад.тхреадпоол.сизе: 20
Теме покретача региона: 6
Величина клијентске Јава гомиле у бајтовима: 1 ГиБ
ХБасе РЕСТ сервер Подразумевана група: 3 ГиБ
ХБасе Тхрифт Сервер Подразумевана група: 3 ГиБ
Величина Јава гомиле ХБасе Мастер-а у бајтовима: 16 ГиБ
Јава Хеап Величина ХБасе РегионСервера у бајтовима: 32 ГиБ
+ЗооКеепер
макЦлиентЦнкнс: 601
макСессионТимеоут: 120000
Прављење табела:
хбасе орг.апацхе.хадооп.хбасе.утил.РегионСплиттер нс:т1 УниформСплит -ц 64 -ф цф
алтер 'нс:т1', {НАМЕ => 'цф', ДАТА_БЛОЦК_ЕНЦОДИНГ => 'ФАСТ_ДИФФ', ЦОМПРЕССИОН => 'ГЗ'}
Овде постоји једна важна тачка - опис ДатаСтак-а не каже колико је региона коришћено за креирање ХБ табела, иако је то критично за велике количине. Због тога је за тестове изабрана количина = 64, што омогућава складиштење до 640 ГБ, тј. стол средње величине.
У време тестирања, ХБасе је имао 22 хиљаде табела и 67 хиљада региона (ово би било смртоносно за верзију 1.2.0 да није горе поменута закрпа).
Сада за код. Пошто није било јасно које су конфигурације повољније за одређену базу података, тестови су спроведени у различитим комбинацијама. Оне. у неким тестовима 4 табеле су истовремено учитане (сва 4 чвора су коришћена за повезивање). У осталим тестовима смо радили са 8 различитих табела. У неким случајевима, величина серије је била 100, у другим 200 (параметар серије - погледајте код испод). Величина података за вредност је 10 бајтова или 100 бајтова (датаСизе). Укупно, 5 милиона записа је сваки пут уписано и прочитано у сваку табелу. Истовремено, 5 нити је уписано/прочитано у сваку табелу (број нити - тхНум), од којих је свака користила свој опсег кључева (број = 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);
}
}
Сходно томе, слична функционалност је обезбеђена за ХБ:
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);
}
}
Пошто у ХБ клијент мора да води рачуна о равномерној дистрибуцији података, кључна функција сољења је изгледала овако:
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);
}
Сада најзанимљивији део - резултати:
Иста ствар у облику графикона:
Предност ХБ-а је толико изненађујућа да постоји сумња да постоји нека врста уског грла у подешавању ЦС-а. Међутим, гуглање и тражење најочигледнијих параметара (као што су цонцуррент_вритес или мемтабле_хеап_спаце_ин_мб) није убрзало ствари. У исто време, трупци су чисти и ништа не псују.
Подаци су равномерно распоређени по чворовима, статистика из свих чворова је била приближно иста.
Овако изгледа табела статистике из једног од чвороваКључни простор: кс
Број читања: 9383707
Латенција читања: 0.04287025042448576 мс
Број писања: 15462012
Кашњење писања: 0.1350068438699957 мс
Флусхес на чекању: 0
Табела: т1
Број ССТ табеле: 16
Искоришћени простор (уживо): 148.59 МиБ
Искоришћени простор (укупно): 148.59 МиБ
Простор који користе снимци (укупно): 0 бајтова
Искоришћена меморија ван гомиле (укупно): 5.17 МиБ
ССТабле степен компресије: 0.5720989576459437
Број партиција (процена): 3970323
Мемтабле број ћелија: 0
Мемтабле величина података: 0 бајтова
Мемтабле искоришћена меморија ван гомиле: 0 бајтова
Мемтабле број прекидача: 5
Локални број читања: 2346045
Локално кашњење читања: НаН мс
Локални број писања: 3865503
Локално кашњење писања: НаН мс
Испирање на чекању: 0
Проценат поправљених: 0.0
Лажни позитивни резултати филтера Блума: 25
Лажни однос филтера за цветање: 0.00000
Искоришћени простор за Блум филтер: 4.57 МиБ
Блум филтер са искоришћене меморије гомиле: 4.57 МиБ
Резиме индекса од коришћене меморије гомиле: 590.02 КиБ
Компресија метаподатака ван меморије гомиле: 19.45 КиБ
Минимални бајтови компактне партиције: 36
Максимални број бајтова сабијене партиције: 42
Сабијени средњи бајтови партиције: 42
Просечан број живих ћелија по резу (последњих пет минута): НаН
Максималан број живих ћелија по комаду (последњих пет минута): 0
Просечан број надгробних споменика по комаду (последњих пет минута): НаН
Максималан број надгробних споменика по комаду (последњих пет минута): 0
Отпуштене мутације: 0 бајтова
Покушај смањења величине серије (чак и слање појединачно) није имао ефекта, само се погоршавао. Могуће је да је ово заиста максимална перформанса за ЦС, пошто су резултати добијени за ЦС слични онима добијеним за ДатаСтак – око стотине хиљада операција у секунди. Поред тога, ако погледамо искоришћеност ресурса, видећемо да ЦС користи много више процесора и дискова:
На слици је приказано коришћење током извођења свих тестова у низу за обе базе података.
Што се тиче ХБ-ове моћне предности читања. Овде можете видети да је за обе базе података искоришћеност диска током читања изузетно ниска (тестови читања су завршни део циклуса тестирања за сваку базу података, на пример за ЦС ово је од 15:20 до 15:40). У случају ХБ, разлог је јасан – већина података виси у меморији, у мемстору, а неки се кеширају у блок кеш меморији. Што се тиче ЦС-а, није баш јасно како то функционише, али рециклажа диска такође није видљива, али за сваки случај је покушано да се омогући кеш ров_цацхе_сизе_ин_мб = 2048 и постави кеширање = {'кеис': 'СВЕ', 'ровс_пер_партитион': ' 2000000'}, али то је још мало погоршало ситуацију.
Такође је вредно још једном поменути важну тачку о броју региона у ХБ. У нашем случају, вредност је наведена као 64. Ако је смањите и учините једнаком, на пример, 4, онда при читању брзина пада за 2 пута. Разлог је тај што ће се мемстор брже пунити и датотеке ће се чешће испирати, а приликом читања ће бити потребно обрадити више датотека, што је прилично компликована операција за ХБ. У стварним условима, ово се може третирати размишљањем о стратегији претходног раздвајања и компактификације; посебно, користимо услужни програм који је сам написао који сакупља смеће и константно компресује ХФилес у позадини. Сасвим је могуће да су за ДатаСтак тестове доделили само 1 регион по табели (што није тачно) и то би донекле разјаснило зашто је ХБ био толико инфериоран у њиховим тестовима читања.
Из овога се извлаче следећи прелиминарни закључци. Под претпоставком да током тестирања нису направљене веће грешке, онда Касандра изгледа као колос са глиненим стопалима. Тачније, док балансира на једној нози, као на слици на почетку чланка, показује релативно добре резултате, али у борби под истим условима губи потпуно. У исто време, узимајући у обзир ниску искоришћеност ЦПУ-а на нашем хардверу, научили смо да поставимо два РегионСервер ХБ-а по хосту и на тај начин удвостручили перформансе. Оне. Узимајући у обзир коришћење ресурса, ситуација за ЦС је још жалоснија.
Наравно, ови тестови су прилично синтетички и количина података која је овде коришћена је релативно скромна. Могуће је да би, када бисмо прешли на терабајте, ситуација била другачија, али док за ХБ можемо учитати терабајте, за ЦС се то показало проблематичним. Често је избацивао ОператионТимедОутЕкцептион чак и са овим волуменима, иако су параметри за чекање одговора већ неколико пута повећани у поређењу са подразумеваним.
Надам се да ћемо заједничким снагама пронаћи уска грла ЦС-а и ако то можемо да убрзамо, онда ћу на крају поста свакако додати податке о коначним резултатима.
УПД: Захваљујући саветима другова, успео сам да убрзам читање. Био:
159 операција (644 табеле, 4 токова, серија 5).
Додато:
.витхЛоадБаланцингПолици(нова ТокенАвареПолици(ДЦАвареРоундРобинПолици.буилдер().буилд()))
И играо сам се са бројем нити. Резултат је следећи:
4 табеле, 100 нити, серија = 1 (комад по комад): 301 операција
4 табеле, 100 нити, група = 10: 447 операција
4 табеле, 100 нити, група = 100: 625 операција
Касније ћу применити друге савете за подешавање, покренути цео циклус тестирања и додати резултате на крају поста.
Извор: ввв.хабр.цом