Блог компании Сбербанк
Высокая производительность
Big Data
Хранилища данных
Hadoop
Комментарии 134
+3
Вы хамите. Минусы не дают на это права, если вы не знали.
Во вторых, ни один из поставивших минус не аргументировал. Тогда как это факт очевидности уровня википедии:
«A wide column store can be interpreted as a two-dimensional key-value store.»
en.wikipedia.org/wiki/Wide_column_store
-2

Чем обижаться на правду вы бы лучше разобрались чем эти БД отличаются.


Ну или хотя бы почитали следующий раздел той ссылки которую привели:


Wide column stores such as Bigtable and Apache Cassandra are not column stores in the original sense of the term since their two-level structures do not use a columnar data layout. In genuine column stores, a columnar data layout is adopted such that each column is stored separately on disk.
+1
Чем давать советы, кому чем заниматься, сами бы сели и написали свое исследование.

Ну или хотя бы прочитали дальше следующий раздел той же статьи:

Notable wide column stores include:
Apache Cassandra
Apache HBase
+2
Сдается мне что произошла путаница между Wide Column и Column Oriented.
Топик стартер кажется имел ввиду второе
0

Хуже: он не понимает что это два принципиально разных типа хранения на диске, которые используются для разных целей. И упорствует в своем невежестве :)

+2

Это не разные типы хранения, это вообще перпендикулярные вещи. Ничто не мешает быть СУБД одновременно и wide column, и column oriented. Правда, непонятно, зачем такое, но можно :-)

0

Мне, если честно, сложно представить как можно хранить строки с переменным числом колонок в традиционном Columnar-формате где каждая колонка хранится отдельно. Даже NULLы в том же Кликхаусе уже эдакий хак.


Понятное дело, что придумать какой-то хак можно и для этого случая, но это будет такой изврат что ужас.


Поэтому я и говорю про дисковый формат — принципиальное отличие Columnar DB именно в том что столбцы хранятся и читаются отдельно.

+2

Термин-то устоялся, но "устояли" его маркетологи. Ну или "ушатали" — уж не знаю как точнее/корректнее.


Все эти термины (Wide Column, Column Oriented) подпорчены и размыты маркетологами, из-за этого и путаница. С точки зрения "как оно устроено" логично говорить "Wide Column Store" (key-value с "широким" JSON-like value) и "Multi-Column Store" (колонки хранятся отдельно, в разных файлах и т.п.).


В среднем по-больнице в Multi-Column Store обновления и удаления медленные (на 1-2-3 порядка) или вообще не поддерживаются (хотя есть отрезание данных пачками), зато намного быстрее (на 1-2-3 порядка) обрабатываются сложные запросы (структура хранения позволяет в разы меньше читать с диска).


За изобретения термина "Wide Column Store" я бы наказал, ибо "Column" здесь только путает и позволяет втюхивать "Wide Column Store" как "Column Store, плюс еще и Wide". Вместо "Wide Column Store" логичнее было-бы "Wide key-value" или "key-Value2d" — тогда всё встаёт на свое место.

+4
Сервера мониторили? Во что упираются сервера кассандры, память, диск, паузы GC? Если не во что не упираются, значит вы ее просто не догрузили. Пишите в Кассандру не в 5 а в 50 потоков через 1 коннект.
Сравнение не честное, т.к. про HBase Вы все знаете, а Кассандра, для Вас, черный ящик.
key_cache_size_in_mb — задайте несколько гигов. Он куда более важен для производительности на чтение, чем row_cache, строки и так будут в кеше операционки. И 8 дисков, для данного теста, Кассандре не нужны, она свалит все на один. Много дисков понадобится для множества кейспейсов и таблиц. Писать с CL=ALL, это еще можно понять, но читать смысла нет, достаточно LOCAL_QUORUM.
+2
Спасибо за интерес к теме! Во что именно упирается не очевидно. Утилизация приведена на картинке в посте. При этом нужно иметь в виду, что нагрузка на диски бывает разная. Так как тут пишутся WAL (журналы транзакций), то они часто дергают sync, что замедляет запись. Насчет количества потоков, попробовал удвоить. Ниже результаты первых четырех тестов на запись:

5 потоков (op/sec) -> 10 потоков (op/sec)
137 194 -> 116 983
136 250 -> 114 127
126 346 -> 111 881
119 544 -> 122 323

Получается что Кассандра вполне так себе загружена, удвоение потоков прироста скорости не дает.

>>key_cache_size_in_mb — задайте несколько гигов

Попробовал 4 Гб, тесты на чтение:
Без кэша С кэшом
159 644 153 513
167 698 164 248
134 419 131 751
139 592 141 571

>>И 8 дисков, для данного теста, Кассандре не нужны, она свалит все на один

Не вполне понятно, что имеется в виду. Похоже что данные распределились равномерно по всем дискам:
58M /data1/cassandra/ks/t1-3d82bd70385711eab7c4ed6d0a140d16
58M /data2/cassandra/ks/t1-3d82bd70385711eab7c4ed6d0a140d16

58M /data8/cassandra/ks/t1-3d82bd70385711eab7c4ed6d0a140d16

>>Писать с CL=ALL, это еще можно понять, но читать смысла нет, достаточно LOCAL_QUORUM.

Совершенно верно, чтение во всех тестах осуществлялось CL=ONE
0
вы отключали swap? объём данных записанных у вас очень небольшой, у меня в сек запись была больше, мы за 3 недели записали full storage, при том что половина операций это update, плюс у вас не выставлена оптимизация под hdd, а по дефолту идёт оптимизация под ssd чтения\записи. это указывается в cassandra.yaml. Так же в cassandra-env.sh по дефолту стоит скрипт для оптимизации расходов ресурсов, но при больших нагрузках надо отключать скрипт, и ставить руками значения
MAX_HEAP_SIZE=«80G»
HEAP_NEWSIZE="*M" где за основу берётся кол-во физический ядер -2(если говорим о физ железе)
+1
Своп не отключали, но у нас 700 Гб памяти и он совсем не работает (кроме теста ничего не крутится на стенде). Остальное ок, поправим, спасибо большое!
+1
отключите, это 1 команда в терминале, даже если вам кажется что он не используется.
+6
В заголовке «Битва двух якодзун», а на фотке один бывший якодзуна (http://www.japan-sumo.ru/?q=kisenosato) а второй вообще не якодзуна (http://www.japan-sumo.ru/?q=shohozan)
+4
«Это даже не шутка, похоже, что именно эта картинка наиболее точно отражает...» что о Cassandra уже можно забыть, а HBase «не дотягивает»?
0
Погодите, я думаю рано хоронить CS, в комментах много предложений по оптимизации)
-1
Да как-то практика показывает, что хоронить надо других, а не касандру. Тут с бенчами и конфигами проблемы.
0
Спасибо что напомнили, точно) Менять уже заголовок не стоит наверное, но схватка определенно звучит лучше))
+17
Воскресная статья о том, как в сбербанке искали способ не работать c Cassandra, по-другому статью назвать сложно. Ну а теперь по пунктам.

1) Вы используете deprecated GC, да в кассандре он по default, но проблема в том, default у кассандры не сделан под нагрузки, не говоря уже о bigdata. Необходимо было поставить G1GC, и 60-80 Gbyte Heap, далее начались бы ошибки в gc, в логах пишется, по факту влияет на сильно, и работает лучше чем если часто сбрасывать на диск. Есть лечение ставим www.azul.com/downloads/zulu-community/?&architecture;=x86-64-bit&package;=jdk ставим вот это и получаем отсутствие ошибок у GC, а так же ещё +50-60% к производительности cassandra(графики увы предоставить не могу, работа была для МО).

2) Непонятно как были настроены диски под Cassandra, непонятно как вообще было что настроено, начиная от sysctl.conf заканчивая лимитами. docs.datastax.com/en/dse/5.1/dse-dev/datastax_enterprise/config/configRecommendedSettings.html этой статьи хватает для начала, по мере работы добавится ещё несколько пунктов, а например я ставлю fs.file-max = 1073741824 vm.max_map_count = 1073741824 vm.dirty_bytes = 1073741824 vm.dirty_background_bytes = 10485760 (настройки тестил, ставил меньше, нашёл на github)

3) Для нормальной работы кассандра необходимо вынести на отдельный/е ssd saved_caches, key_cache, row_cache, counter_cache, thrift_prepared_statements_cache они не всегда даже будут использоваться, но вынести их на отдельный от /data накопитель обязательно необходимо.
Необходимо логи системы и cassandra держать на отдельном от data носителе. У меня был nvme под это дело, система+логи+кеши были на отдельном nvme, а data была на 24 hdd sas 7200 128 cache.

4) Cassandra работает существенно лучше на XFS, которую надо специально подготовить, проще всего это сделать через скрипт Scylla_setup, так же этот скрипт сразу настроит нужные для процессора настройки, а их там не мало. При желании можно самому прочесть скрипт и поставить руками настройки.

5) Cassandra не любит hyper-threading его отключение сильно снижает latency на больших нагрузках.
6) Cassandra не имеет под собой HDFS, поэтому её надо ставить на raid 0, в вашем случае вы работали с 1 диском, естественно у вас результаты были гораздо хуже чем с hbase, где это сделал за вас hdfs(образно, понятное дело, что там механизм иной, но суть в том, что нагрузка шла на все диски а не на 1 как в вашем случае).

В заключении, у меня было 3 ноды cassandra, кейс гораздо более сложный, была запись по 300к/с и 160к/с update, тоже rf3, и 3 ноды, запись длилась на показе заказчику 3 недели, и latency был ниже вашего. Да было по 800 мб чтение с data, и запись 500 мб, дисковая подсистема была почти полностью загружена.
+3

Этот комментарий интереснее и полезнее чем вся статья =)

0
2 и 6 — из конфига видно, что у них JBOD конфигурация и комитлог на другом диске. В этом плане все правильно вполне. Проблем там другие, ниже описал.
+1
помимо коммит лога есть ещё логи gc, server и debug, и в дефолте там очень не хилые размеры, не смотря на то что там чисто текст. Судя по 53М на дату, у меня логи эти в день были больше. чем у топикстартера дата на 5 дисках.
0
Это ерунда все равно. Линейная буферизированная запись. Коммит лог пропускает через себя все записи, он наиболее критичен. И то, т.к. там тоже линейная запись, то один hdd вполне справляется.
+1
я просто помню что по iops нагрузка на nvme была половина от data, я выше написал что я вынес, подробнее мне было некогда разбирать что и как грузит. А по iops у меня нагрузка почти фулл нагружала дисковый массив.(если брать iops диска и умножать на кол-во дисков), был сделан raid0 средствами mdraid через scylla_setup.
+1
Вполне уверен, что это был именно коммитлог. В него сохраняются все вставки, чтобы нода могла пережить падение без потери данных. Естественно на него огромная нагрузка. У той же сциллы это вообще доведено до предела — все данные идут в коммитлог и копятся в памяти. В sstable вообще ничего не сохраняется на диск, пока в памяти все помещается. Кэширование очень агрессивное там.
+1
commit log я вынес на nvme, но даже вы выше писали что он пишет потоково, а значит это была бы загрузка просто на запись, а не iops, тем более в ssd. я raid я максимально разгружал от кешей и тп.
+3
Очень полезный комментарий, спасибо!

>>как в сбербанке искали способ не работать c Cassandra
Это не так) Никто не просил тестировать CS, это была чисто наша инициатива для удовлетворения собственного любопытства. И статья на хабр, как отличный способ привлечь грамотных специалистов, например таких как вы, для того чтобы обменяться опытом)

1. — попробуем G1 для CS, результат отпишу. Я пробовал указывать его для HB, но было хуже, однако вполне возможно, что так как HBase по-другому использует память то, для него G1 не дает такого эффекта как для CS.
2. — обязательно прогоним на рекомендованных параметрах. Учитывая, что HB меньше утилизирует диски это может для него не важно, но критично для CS.
3. — ну ssd нет, тут ничего не сделать.
4. — был бы признателен за ссылку на прирост производительности за счет XFS, чтобы понимать соотношение: усилия/польза.
5. — давно была идея проверить как h/t сказывается на производительности всего нашего софта, так что скорее всего так же проверим.
6. Насколько я понимаю у нас все разлеглось по многим дискам:
58M /data1/cassandra/ks/t1-3d82bd70385711eab7c4ed6d0a140d16
58M /data2/cassandra/ks/t1-3d82bd70385711eab7c4ed6d0a140d16

58M /data8/cassandra/ks/t1-3d82bd70385711eab7c4ed6d0a140d16

>>В заключении, у меня было 3 ноды cassandra, кейс гораздо более сложный, была запись по 300к/с

Спасибо за весьма детальную информацию, очень хорошо, когда есть ориентир. Получается, что аппроксимируя 300 к/с для 3х нод на четыре ноды, то это порядка 400 к/с. Т.е. практически совпадает с HB, однако как вы пишите, что диски при этом полностью нагружены. Таким образом, при прочих равных, другие операции с дисками будут выполняться гораздо медленнее, что для нас очень важно, так как в ПРОМ рядом крутится много другого софта.
+1
У меня было много update, это заставляло на много больше работать compaction, что в свою очередь и грузило диски. Во вторых я тоже полностью подводные камни не знаю, может ещё какой то кеш выносить надо было.
без ssd отдельного под систему и кеши смысла ставить cassandra нет. плюс что hbase что cassandra должны жить на отдельном от другого софта железа(за исключением spark, их лучше на одной ноде, если позволяет конфигурация)
SSD стали дешёвые, заказать ssd вполне реально, особенно учитывая сколько потом это будет экономить оборудования. Более того с выходом qlc ssd, можно вообще на них перейти и цена схожа будет с enterprise hdd. Плюс у вас нет update и потому запись у меня могла бы быть сильно больше.
На счёт xfs ссылку вряд ли дам, у scylla в было где то в бенчах, но про xfs я узнал на irc cassandra и из google рассылок.
0

Добавлю, что я не удивлен насчёт рекомендации xfs — та же монга на этой фс работает лучше, чем на ext4

0
Не знаю как у монги (просто поселил на xfs без разбирательств по рекомендации), а у сциллы основная фишка xfs — многопоточность — как раз задействуется во всю, потому что compaction'ы выполняются не смотря ни на что, в т.ч. на пользовательскую нагрузку.
0
>>заставляло на много больше работать compaction
Понял, поставлю грузиться HB на ночь, чтобы пошла компактификация, посмотрим что получится…
0
Поработало не всю ночь, однако компактицикация имела место и несколько увеличила нагрузку на диски:

Однако я думаю пока еще рано делать выводы, хочу применить ваши и другие рекомендации (часть из них уже привела к кратному росту скорости чтения) и позже дополню пост.
НЛО прилетело и опубликовало эту надпись здесь
+2
речь все-таки о грамотных специалистах была, вроде без сарказма
0

По скорости cassandra не вызывает воспросов. Но как-то встретил образную фразу "шлейф записей" который образуется из-за того что вставка происходит с приоритетом по сравнению с обновлением. А поскольку у кассандры нет разницы между вставкой записи и ее обновлением (есть запись с идентификатором — она обновится, нет записи — она добавится) то я лично столкнулся при тестировании небольшого кластера данных с такой аномалией. При массовой вставке записей с одинаковыми (уже существующими) идентификаторами, если запросить селектом количество записей то будет выдана цифра превышающая общее колчиепситво записей. Такое впечатление что кассандра сначала вставляет новую запись и она уже может быть посчитана. В то время когда ее дубликат еще не выявлен и и также существует в базе данных. Потом после окончания массовой вставки это количество приходит в консистентное состояние. Наверное это и называется шлейфом данных и из-за этого какой-то мессенджер (чуть ли не скайп) от нее отказался.
Я думаю это не то поведение которое годится для банковских приложений?

+3
Это называется thumbstones. При каждом изменении, удалении старая запись помечается таким thumbstone. При селектах базе приходится их все прочитать, прежде чем дойти до текущей версии строки. Это страшно лишь одним — это сильно замедляет выборки, если много апдейтов. Через определенное время у thumbstone истекает время жизни и компакшен его удаляет, восстанавливая скорость выборок. Таким образом достигается eventual consistency. При проблемах в кластере есть вероятность получить разные версии одной и той же строки. При CL_ONE так вообще запросто. Но это плата за скорость.
+1
На самом деле у томбстоунов есть ещё проблема. По истечению срока жизни, он удаляется. И вот если запись присутствует, то получается воскрешение старых записей. Под эту процедуру надо обслуживание выполнять не реже, чем раз в x дней. Этим страдают, как я понял, все кассандроподобные базы.
+1
Это да, про это везде и всюду пишут к счастью. Вряд ли пропустишь.
+1
Только вот огорчило, что автоматизации repair за столько лет родилось всего ничего. Ну то есть она идёт. А как долго, сколько ориентировочно осталось, возможность остановить, если пошла нагрузка серьёзная… Многих, насколько понял, вопросы такие не заботят, они руками раз в неделю запускают repair на каждой ноде. И как итог — самописный колхоз ansible + jenkins для хоть какой-то автоматизации. Правда логи о процессе — потфактум. Остаётся только смириться (ну или смотреть коммерческие решения).
+1
Есть cassandra reaper. Правда со сциллой не работает пока. У платной сциллы вроде как в комплекте подобное тоже идет.
+1
Ну до 5 нод scylla manager даже вроде и бесплатна. Но пугает ситуация сесть на него, а потом выйти за 5 нод и всё снова на те же круги возвращается.
+4

Конечно небесполезно знать кто из "динозавров" большие греет атмосферу. Но может всё-таки ScyllaDB вместо Cassandra?

+1
Резонно, судя по тестам что на их сайте, она просто космос. Единственный вопрос, почему она до сих пор на 8 месте того же DB-Engines Ranking (см. вторую картинку в посте) и не видно мощной динамики. Возможно инерция IT-сообщества, возможно тоже есть подводные камни. Видимо как это частенько бывает, пока не попробуешь, не узнаешь…
+2
По моему опыту она работает как drop-in замена. Вообще ничего менять не пришлось за редкими исключениями. Некоторых фич у них когда-то не было (индексы теже и materialized views), но я их и не использовал. Есть свои баги естественно. Есть свои особенности — в каком-то релизе page state имел размер в 50-100КБ, от чего ломались HTTP запросы, у которых он в GET параметре передается. Потом магическим образом исправилось в каком-то релизе, но к этому времени и своими силами обошли проблему. Диагностика хромает в некоторых местах. Недавно проблема с thumbstone кажется была, возможности оценить их количество в сцилле пока нет.

Но это с позиции разработчика так все просто. С devops это абсолютно другая база. Она отдаленно похожа своей концепцией на касандру, но устроена совершенно по-другому. Даже установить ее на сервер это целая наука.
0
Да как по мне, там всё просто. xfs, докер (да, таки можно теперь не заморачиваться и делать посредством докера с небольшой долей настроек и оверхеда на сам докер, к тому же обновления с ним становятся делом пары минут). А что там делать ещё — даже не уверен. Если без докера — чуть больше работы и отсутствие оверхеда (хотя там при правильном подходе это мизер). И с настройками всё проще и сложнее. Проще — их меньше. Сложнее — в файле конфига есть параметры, но они не работают, потому что это файл конфига для кассандры. Т.е. параметр есть, но может выясниться, что не на что не влияет, т.к. у сциллы это автоматический механизм, на который конфигом повлиять и не получится.
+2
Сцилла тюнит под себя машину и что там зачем тоже неплохо понимать. Из докера ее лучше вытащить. Она не случайно в developer mode внутри него запускается. Диски — при старте замеряет характеристики и настраивает все свои внутренности, чтобы держаться у самого предела и не перегружать диски. Это я сам наблюдал — без тюнинга диски перегружены и задержки на IO очень большие. Сеть — очень хочет DPDK, который из официального докер образа не работает. Ну и вот docs.scylladb.com/getting-started/system-configuration Сцилла конечно не содержит тонну настроек сама по себе как касандра, но железо и ОС хочет видеть в очень определенном виде.
+1
который из официального докер образа не работает

Возможно. Там в конфиге в докер-образе есть отличия от обычной установки. Местами я бы даже сказал странные. Когда часть надо загонять как параметры контейнера, а часть — как и прежде, через файлы конфига.

Что же касается определённого вида железа — как по мне, rocket science тут нет. Чуть больше внимания уделяется настройке железа, когда у других баз данных приходится уделять больше внимания просто настройкам. Хотя после того же mssql требования сциллы к настройке железа не выглядят чем-то эдаким необычным.

По DPDK вообще, кстати, материала много не видел. Как-то вскользь упоминается (как и некоторые другие вещи), но без сильных подробностей. При этом по тому же докеру они у себя достаточно обширный пост в блоге накатали в своё время
https://www.scylladb.com/2018/08/09/cost-containerization-scylla/, по которому получается, что сцилла критично вроде бы не просаживается. Здесь не готов сказать. Каких-то негативных эффектов в части производительности при переходе в контейнеры (при сохранении самой версии сциллы) не заметил. По DPDK вообще не уверен в ситуации, когда сцилла и так из ssd выжимает всё, что те могут дать — сеть не самое узкое место. Хотя есть DPDK затрагивает производительность дисковой системы, то тут надо думать, очень хорошо думать. Вдруг чудо действительно произойдёт.
0

теоретически, как я понимаю, docker не мешает работе dpdk…
А вот снижение скорости работы в докере относительно режима без докера я В ПРИНЦИПЕ наблюдал. Есть способы его минимизировать, но your mileage may vary

0
Там скорее идет борьба за латентность. За счет переноса всего сетевого стека в юзерспейс они полностью контролируют очереди, какой шард какие данные обрабатывает. В итоге никаких смен контекста, никакой миграции данных между ядрами. Это все от seastar идет. Все таки когда счет идет уже на миллионы операций на ноду, то каждая микросекунда на счету.
0
Чувствую, надо вернуться к вопросу и ещё раз всё хорошенько просмотреть.
+1
Единственный вопрос, почему она до сих пор на 8 месте того же DB-Engines Ranking.
DB-Engines для рассчёта ранга использует поисковые запросы, вопросы на Stack Overflow, упоминания в вакансиях и т.д..
Однако так как ScyllaDB стремится к полной совместимости, то с точки зрения пользователя они никак не отличаются, и не имеет смысл гуглить синтаксис запросов или лучшие практики создания структуры бд для ScyllaDB, когда такого материала полно для Cassandra.
Специфичные для ScyllaDB вещи гуглят в основном админы и таких запросов на порядки меньше.
Это нормальная практика для drop-in замены.
Например, каждый раз когда мне нужно подсмотреть синтаксис запросов в VictoriaMetrics, я гуглю как это сделать для Prometheus, потому что по нему больше материала, а про VictoriaMetrics я гуглил только один раз, когда её устанавливал.
+2
Ваши запросы по касандре ровненько так укладываются во все антипаттерны:
1. Батчи сами по себе это антипаттерн и очень медленные. Еще хуже, когда, как у вас, они покрывают несколько партишенов, что включает LOGGED режим. Потенциально каждый батч затрагивает все ноды одновременно, т.к. хэширование ключей рабросает их в случайном порядке по всем нодам
2. Выборки с IN тоже захватывают кучу партишенов. Каждая выборка будет ходить за данным на все ноды.

Так что стоит таки по-лучше почитать как датастакс делает подобные измерения или сцилла.
+2
Насчет батчей, тут много зависит от задач и окружения. Например, у нас есть продукты, которые работают с кафкой. Соответственно они вытягивают данные через poll, небольшими батчами (порядка сотни сообщений), это естественным образом приводит к тому, что и обращения к HB выполняются так же батчем, что в разы быстрее, чем поштучно.

На всякий случай пробовал выключить батчи и делать запросы поштучно, но получается в разы медленнее. В частности первый тест на запись вместо 137 тыс. ops показал 54. Аналогично на чтение, вместо 159 стало 56. Но это не значит что CS работает плохо, HB в этой ситуации будет вести себя аналогично.
+2
А запросы вы как, параллельно шлете? Каждый запрос в батче надо посылать параллельно, да еще желательно с token-aware policy у коннектора, чтобы избежать дополнительного хопа из-за координатора.

Тоже самое с IN. Только недавно переписывал его на параллельный запрос всех ключей, которые в IN. Получается заметно быстрее, что не удивительно, т.к. нагрузка размазывается ровно по всем нодам, а не отдается на откуп одном координатору. А параллельность скрывает задержки на round-trip'ы на каждый запрос.

Проблема с батчами из нескольких партишенов в том, что они не скейлятся. Кассандра предназначена для сотен и тысяч нод. Подобный батч означает, что на одного единственного координатора ложится задача этот батч выполнить, что потребует послать запрос, потенциально, на каждую ноду в кластере.

Батчи идеально подходят, когда партишен в запросе один, а строк в него вставить много надо (через clustering key). В этом случае можно делать без всяких опасений UNLOGGED батч и получать серьезный прирост.
0
Круто, благодаря вашим советам удалось повысить скорость чтения в 4 раза! На запись эффекта не оказало. Что касается чтения:
Было: 159 644 ops (4 таблицы, 5 потоков, батч 100).
Добавил:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
И поигрался с количеством потоков. Получилось следующее:
4 таблицы, 100 потоков, батч = 1 (поштучно): 301 969 ops
4 таблицы, 100 потоков, батч = 10: 447 608 ops
4 таблицы, 100 потоков, батч = 100: 625 655 ops

Потом применю другие советы по тюнингу, прогоню полный цикл тестирования и добавлю результаты в конце поста.
+1
Еще несколько советов.
1. Как ниже предлагали, используйте биндинг. Судя по коду, TokenAwarePolicy не вытаскивает из строчных запросов ключ, а значит не может корректно направить запрос на нужную ноду.
2. Вкупе с биндингом используйте prepared statements вместо простого execute.
0

Именно! Батчи в Кассандре созданы для обеспечения атомарности запросов, а не для ускорения загрузки.
Для загрузки должны использоваться АСИНХРОННЫЕ операции. Даже при работе с асинхронными запросами есть нюансы: для ожидания надо использовать не get(), а get uninterruptible(), который является не блокирующим, в отличие от первого. В этом случае можно в одном потоке обеспечить максимальную производительность.
По моему опыту, скорость загрузки в базу в асинхронном режиме была в 5 раз выше, чем в батчевом, видимо из-за того, что было 5 узлов.

0
Подскажите пожалуйста, что имеется в виду под get uninterruptible()? Я использовал select, про геты ничего не нашел с ходу…
0
Было бы интересно сравнить с колоночной СУБД Яндекс ClickHouse — пропаганда утверждает, что, как минимум, в ряде случае ClickHouse уделывает и Cassandra, и HBase, и BigTable… ну, по крайней мере, на не террабайтных таблицах!
Да и попробовать отечественный продукт Яндекс ClickHouse было бы весьма патриотично!
+1
ClickHouse насколько мне известно показывает потрясающую производительность, однако у неё нет апдейтов — это ее принципиальное ограничение, к сожалению…
0

Ну, апдейты можно эмулировать ))) вполне успешно. Но дьявол именно в деталях — какие паттерны нагрузки

+1
А смысл? Это принципиально другая БД для других запросов. По той же скорости вставок она запросто проиграет остальным. С обновлениями там проблемы. Сложные запросы она конечно умеет, но это пока хватает памяти.
+1

По скорости вставок Click не проигрывает, примерно совсем. Другое дело, что у него (и в любой append-oriended базе) эти вставки совсем другие.


Сложные запросы Click умеет быстро не "пока памяти хватает" (это не java), а потому что он более-менее оптимально умеет отображать сложный запрос в конвейер чтения и фильтрации чанков колонок с дисков, и всё это в кластере. У клика гораздо больше шансов существенно меньше читать с дисков, если это в принципе возможно для некого запроса. Соответственно, в сценариях для которых сделан клик, на сопоставимом оборудовании, у обсуждаемых БД кране мало шансов конкурировать.


Тем не менее, это сильно разные БД для принципиально разных сфер применения и сравнивать их — как теплое с мягким.

+1
В моем понимании CH ведет себя как любые другие column-store для аналитики — при вставке данные сильно жмутся и хитро раскладываются так, чтобы эффективно дальше делать сложные запросы. От этого страдает скорость вставок и тот же CH хочет очень большие батчи. На одинарных вставках оно умрет.

Я не про быстро, а вообще. Сложные запросы по определению либо требуют дофига памяти, либо скидывать промежуточные результаты на диск. Чудес тут никаких нет и CH умрет с out of memory запросто как любая другая база, которая умеет сложные агрегации делать. Понятное дело, что на касандре той же подобные запросы просто напросто невозможны, но есть всякие спарки и прочие хадупы, которые конечно медленнее, но скейлятся вполне. Правда и там можно помереть, когда все схлопнется до одной ноды и у нее кончится память. Да и никуда от менее эффективного представления данных на диске не уйдешь.
0

В КХ есть распределенные джойны в каком то виде. Ну и вообще данные размазываются по шардам как везде. Поэтому агрегации частично идут локально на всех шардах, а финальная часть уже исполняется там где запрос инициировался. Эдакий мапредьюс.

0
В КХ есть распределенные джойны в каком то виде

весьма ограниченные и все равно можно вылететь по out of memory

+1

Не хочу вступать в непродуктивный спор, ибо базы для разных целей. Но в отношении CH у вас всё-таки немного заниженное мнение:


  • CH предназначен на впитывание данных с одновременной обработкой запросов. В этом режиме одиночные вставки не имеют смысла. Рационально вставлять раз в секунду или по ~100К, а как-то сильно иначе — просто нагрев. CH реализует это очень хорошо и без лишних движений (делит данные на по-колоночные чанки и пушит в LSM).


  • "Плохие" сложные агрегации (и прочие кошмары) потребуют памяти в любой БД. "Спарки и хадупы" имеют те же проблемы (если промежуточный результат не влезет в память, то ой). Хотя и для "спарков" и для CH есть рецепты решения таких задач.


  • Что касается эффективности представления данных на диске, то CH хранит данные по-колоночно со сжатием — придумать что-либо эффективнее сложно. Т.е. в отличие от касанды и спарка, в CH значения, которые с большей вероятностью похожи/близки, в среднем хранятся "ближе" друг к другу и поэтому лучше сжимаются.


0
>Рационально вставлять раз в секунду или по ~100К, а как-то сильно иначе — просто нагрев.

Посмотрите что происходит с КХ в режиме вставки около 1,5 млн/сек в реплицированные таблицы. Как раз верхняя граница буфера чуть больше 1 млн.

>Что касается эффективности представления данных на диске, то CH хранит данные по-колоночно со сжатием — придумать что-либо эффективнее сложно.

Поколоночно и с сжатием хранят все, для спарка аж 2 формата — паркет и орц так хронят. В кх еще есть сортировка.
+1
Посмотрите что происходит с КХ в режиме вставки около 1,5 млн/сек в реплицированные таблицы. Как раз верхняя граница буфера чуть больше 1 млн.

Не совсем понимаю, какую мысль вы хотите выразить? То что параметры по-умолчанию не оптимальны (или не подходят) для сценариев при вставке 1500К — это очевидно. Как в любом OpenSource для эксплуатации в "не ширпотребных" сценариях требуется донастраивать/докручивать продукт (досконально разобравшись в нём), либо покупать поддержку.


На всякий, для понимания — в ClickHouse, как во всех LSM есть проблемы с распределением "полосы пропускания" дисков между слиянием внутри LSM, обслуживанием репликации и чтением для обработки запросов. В своём приватном форке мы более-менее решили эту проблему, но только для нужного нам набора сценариев. А вот насколько эта проблема сейчас решена в upstream я не в курсе.

0
умрет с out of memory запросто как любая другая база, которая умеет сложные агрегации делать.

Ну зачем же так обобщать? PostgreSQL довольно сложно уронить по OoM. По крайней мере, одним запросом. Т.к он может сбрасывать промежуточные данные на диск. Конечно, и у него бывают промашки, но вроде бы редко.

0

В КХ тоже есть режим группировки на диске. И даже, что интересно, часто он не вызывает фактического протекания на диск т.к. dirty cache страниц ядра не успевает сброситься на носитель.

0

Я думаю, что шла речь о том, что запрос отбивается — т.к. то что КХ умирает по ООМ я не видел, а вот запрос — да, сбрасывается

0
Для разных целей? И тем не менее, СlickHouse часто упоминают в срании с Cassnadra и HBase, и на сайте Яндекса есть «замеры» но вот реальных, независимых тестов нет.
Да, с обновлениями и удалениями записей у ClickHouse не всё радужно (хотя и есть решения) — но эти операции вообще узкое место для колоночных СУБД (и не колоночные СУБД их вообще поддерживают; ClickHouse поддерживаются Join — что для колоночных СУБД так же не частая фишка). Вот поэтому интересно сравнить ClickHouse с колоночными якодзунами — в т.ч. на обновление и удаление (ведь всё-таки оно возможно в ClickHouse — хотя в таких СУБД такие операции используются не часто, зачастую просто заменяясь периодическим перестроением таблицы, с удалением лишнего, и видением версий актуализации).
+2
Кликхаус он скорее для логов подойдёт. Кассандра и базы иже с ней более общего назначения.
Патриотичность в таких делах роли не играет (и не должна играть). Сугубо прагматизм.
+1

КХ это колоночная аналитическая БД с более или менее полноценным SQL. Кассандра и HBase это обычные KV базы. Нормальные запросы там появляются только если обернуть их в Spark и подобное.


Цели у этих БД несколько разные и сравнивать ИМХО не особо корректно.

+1
Угу, после моего сравнения cassandra и HBASE был выбран… aerospike.
По факту единственная, у кого на паре серверов и 100к+/сек запросах не скакали максимальные задержки. У Cassandra они до 500мс прыгают(aerospike — 3ms).
0
Это надо было в сторону сциллы копать. Там схожие результаты.
+1

После того как ераспайкеры кастрировали опенсурсную версию в очередной раз трогать его не хочется больше. А так хорошая БД, да.

+3

Честно скажу, опыт только с кассандрой, с hbase нет.
Сравнение очень странное…
Вы сравниваете cassandra, базу, целью которой является высокая доступность, которая вообще без каких-либо латенси переживает вылет rf/2-1 ноду (то есть при rf=3 и rw=quorum (классика), вылет одной ноды вообще не влияет на работу кластера от слова совсем), с Hbase, которая, насколько мне известно работает через мастера и соответственно в случае его падения… не работает. То есть для high available бд не подходит…
Естественно база пишушая через один мастер всегда будет по умолчанию в выигрышной ситуации, хотя бы потому что у неё локализован весь кэш и индексы…
Но даже при этом вы используете кассандру совсем не по назначению, она по сути key-value база с группировкой колонок по pk. Классическое её использование это read/write (в основном второе) по конкретному ключу, по одной записи (high available риал тайм процессинг), батчи антипаттерн для неё, тем более (и это прям написано в доке) батчи содержащие ключи в разных нодах (что вы и сделали).
Как тут уже заметили кассандра работает с одним диском и ей нужен raid0, плюс она непосредственно через wal + sync заботится о гарантии записи, в то время как hdfs имеет свой мемори кэш.


В общем — сравнивать высокодоступную базу с базой имеющей мастера (point of failure) некорректно иначе надо сравнивать одну ноду cs с одной нодой hb, тогда честнее будет.


А если сравнивать — пишите в большое кол-во потоков (write workers в кассандре) с rf=3, но rw=quorum (классика) при этом по одной записи (один pk) в запросе, либо, чтобы все батчи уходили в одну партицию, иначе вы опять же сравниваете ha базу размазывающую с базой с одним мастером...


P.s.
Hb может и быстрее, но она ж для другого...


P.p.s.
Кстати, что это за кейс такой где нужна high availability и low latency и при этом батч операции? Зачем вы сравниваете cs и hb...

+1

Я не сварщик, но HBase все-таки не такой уж и тупой.


Мастером для данных является каждый регион сервер (для регионов, за которые он отвечает). Соответственно, при падении регион сервера будет недоступна часть данных, пока эти регионы не назначатся на другие регион сервера.


Мастер кластера отвечает за изменение метаданных. За хранение отвечает Сторож Зоопарка. Соответственно, если упал мастер кластера, то не получится поменять состав кластера или схему данных. Однако читать и писать данные вы сможете.


Конечно, если упал мастер кластера и регион сервер одновременно, то данные не будут доступны пока кого-нибудь из них не поднимете, т.к. без мастера кластера регионы не переедут на другие регион-сервера.


И для мастера кластера и для регион-серверов вроде как в последних версиях можно назначать слейвов, что сильно уменьшает время простоя.

0

Как долго после падения регион сервера кластер это понимает и как долго переезжает регион мастер?
Как об этом узнают клиенты?
Насколько это автоматически?
(Как вообще это выглядит для клиентов, если не секрет, интересно узнать)

0
Переезд занимает вот столько времени примерно:
ZooKeeper session timeout + split time + assignment/replay time
На практике это может занять прилично времени, в частности сильно зависит от количества WAL файлов, которые нужно обработать. Все это занимает примерно минут 10-30.

>>Насколько это автоматически
На версии 2.1.0 наблюдали как RS упал, а переезд не начался. Есть информация от человека близкого к разработке HBase что административная часть в первых версиях 2.* не очень написана. Есть вероятность что 2.2.3 уже ок. Однако это исключение, такое было один раз пока что, обычно переезд начинается как надо.

Клиенты узнают так, что получают NotServingRegionException и должны висеть ждать пока не выяснится какой RS подхватил регион. В теореме CAP HBase жертвует availability…
+1
> ZooKeeper session timeout + split time + assignment/replay time

Split time тут лишнее.

Вы сильно раздули MemStore потому у вас при падение RS нужно много данных вычитывать из WAL. У нас после падение RS рекавери за 1-2 минуты проходит.

> На версии 2.1.0 наблюдали как RS упал, а переезд не начался
Как по мне так намного чаще регионы зависают в transition по разным причинам и их приходится в ручном режиме пропихивать.
0
>>Вы сильно раздули MemStore
Да, так как когда вовсю начинали наваливать то ловили Above memstore limit.

>>Как по мне так намного чаще регионы зависают в transition по разным причинам
Хе хе, есть такое дело))
+1
Спасибо за детальный анализ поста и интерес к теме. Базы безусловно имеют ряд отличий, однако в целом занимают одну нишу — позволяют эффективно оперировать действительно большими объемами. При этом в рамках теоремы CAP они позиционируются по разному, как вы верно заметили. CS считается больше AP, но может быть настроена иначе, тогда как HB это практически полный CP. Однако насчет роли мастера для HB это не верное представление. Как ниже правильно отметили, есть возможность дублировать роль мастера (мы так и делаем) и второй момент в работе с данными мастер не принимает участие. Т.е. выпадение мастера не позволяет выполнять административные функции (создание таблиц и т.д.), но не мешает работе RegionServers (RS).

Насчет дисков, как я понял, у них тут все идентично. Данные легли на все диски равномерно, в комментариях выше это подтвердили. Также WAL пишется в HB как и CS и тоже делает sync.

>>А если сравнивать — пишите в большое кол-во потоков
Поменял схему, вместо записи в 5 потоков батчами по 100 штук писал 100 потоков поштучно. Никакой разницы не было. Однако на чтение вместе с TokenAwarePolicy скорость выросла в 2 раза, с 159 644 до 301 969.

Попозже проведу более полное и тщательное тестирование, с учетом других предложенных оптимизаций и добавлю в конец поста.
0

Если так же поштучно (без батчей) работать с HB во много (100+) потоков насколько она у вас получилась быстрее? И на запись и на чтение интересует… Раз уж тестите, может и мой кейс на hb потестите )

0
Да, конечно, я хотел все новые тесты CS прогнать и для HB, чтобы уж полная картинка была)
+1

"CS может использоваться в режиме допускающем потерю данных. Т.е. это когда только один сервер (нода) отвечает за данные некоего ключа и если он по какой-то причине отвалился, то значение этого ключа будет потеряно."


Если он отвалится, то данные не будут потеряны, они просто не будут доступны пока вы не поднимите эту ноду, а до тех пор вы получите ошибку чтения/записи, логично, ведь… вы сами задали хранение на одной ноде (rf=1).


Cs позволяет делать разные настройки для кейспейса (группы таблиц) и из коробки имеет понятие датацентра и настраиваемой политики реплик между дц. Так же можно задавать разную политику консистенции для каждого отдельного запроса. Так что вы сами настраиваете консистенси и авайлабилити считайте чуть ли не на каждый запрос, естественно, если вы хотите выстрелить себе в ногу, то cs даст вам массу возможностей, однако если вы знаете, что вы делаете, всё можно использовать в соответствующих юзкейсах.


Так же у cs присоединяются (и отсоединяются) ноды без дауниайма и какой-либо латенси.


Наш юзкейс это большое кол-во key=value записей (в основном) и чтений (~10:1) (рандомных по ключу), но все по одно и латенси критично (так что никаких батчей не получится собрать), но благодаря вашей статье я попробую посмотреть в сторону hbase ещё раз (5ть лет назад уже смотрел и тогда выбрал cs).


arheops писал про задержки в 500мс, это не cs, это java gc, если правильно под вашу нагрузку настроить и долгих gc, а тем более stw не будет (а 500мс это возможно оно), то вы даже 5мс никогда не увидите.


(Про scylladb знаю, но с ней были непонятки/проблемы год назад, может тоже посмотрю ещё раз)

0

Да, я вас понял, просто придрался :) к фразе, что может работать в режиме допускающем потерю данных, она может работать с любым количеством реалик и если копия только одна, то как бы вы ж сами выбрали, то есть это не минус это плюс, есть выбор, возможно вам для определённых таблиц не нужно лишнее дублирование и данные там если что не жалко.


Да, у нас тоже прилично данных, а главное куча изменений и ssd диски регулярно сыпятся, потому очень удобно иметь возможность в любой момент просто вытащить ноду из кластера (просто выключить) и что-то с ней поделать без пенальти.

0
Справедливости ради, все-таки ёкодзуна или йокодзуна, но никак не якодзуна.

Сёходзан (тот, что на фото справа — у вас он с подписью HBase) никогда не был ёкодзуной :-)
0
Много лет назад имел хождение в интернетах истерический смех ведущего комментирующего схватку двух «якодзун», это была отсылка к нему)
+2
затем что scylla оптимизирована full под ssd, и направление работы с hdd разрабы уже говорили их не очень интересует, и их можно понять, у них мало клиентов на hdd, а большая часть вообще в амазоне.
+1
У вас есть реальный опыт работы со scylla? А до этого была с cassandra? Если можно — кратко минусы (плюсы у них на сайте разрекламированы) и вообще какова реальность? И что насчёт лицензионной политики?
+1
Scylla более требовательна к соотношению CPU-RAMM-HDD, т.к. принципиально не использует swap. В Cassandra это настраивается.
Для эффективной работы Cassandra надо тонко тюнить Жабомашину. Из коробки она проигрывает в зависимости от типа тестов от 2 до 9 раз (это наши тесты на тестовых контурах 2 реальных систем).
Ноды Scylla гораздо быстрее поднимаются и реже «падают». В кавычках, т.к. сталкиваемся в кластере на Cassandra (33 ноды) в том числе с тем, что нода отвечает на все команды, но при этом не пишет и не отдает данные.
Лицензионная политика примерно одинакова с Datastax. Есть OpenSourse и Enterprise версии.
Для военных Scylla имеет полную совместимость с Astra Linux SE 1.6.
0
Для военных Scylla имеет полную совместимость с Astra Linux SE 1.6.

А вот тут по-подробнее, если можно. Нашел презентацию айтеко, но непонятно, как к этому получить доступ и имеет ли оно сертификат.
0
Этим я там как раз занимался. Написали часть модулей для сертификации. Получили сертификат совместимости от Русбиттеха. Я ушел, проект закрыли.
+1

Товарищ подсказывает по Кассандре:


  • не используйте батчи для записи во многие партиции. (Об этом даже DataStax пишет)
  • используйте параметризованные запросы вместо склейки строк. Тогда и коннектору и кассандре будет проще разбирать запрос, чтобы понять в какой сервер его посылать.
  • в коннекторе необходимо указать TokenAwarePolicy (хотя, вроде DataStax коннектор ставит ее по умолчанию)
0
Да, спасибо, есть существенный прогресс производительности. Попробую еще параметризованные запросы, потом отпишусь что вышло.
0

Чтение, по идее, тоже лучше параллельными/асинхронными запросами вместо IN, когда много партиций задействовано.

+1
В тесте для HBase добавьте FLUSH на таблицы в конце записи, что бы чтение было не из MemStore, а с диска. Иначе БД в разных условиях сравниваются на чтение.
0
Да, это так, я в посте упоминал об этом, скорость после флаша падает примерно в 2 раза. Я пытался привести CS к подобному поведению, увеличивая memtable_heap_space_in_mb, однако это не дало ускорения. Т.е. с одной стороны все верно, а с другой хотелось бы как-то отметить, что HB эффективнее держит данные в памяти. Думаю для полноты картины в финальной версии сравнений выложить два варианта — чтение с дисков и из памяти.
0
В реальной жизни чтение обычно сильно позже идет после записи, а значит MemStore будет сброшен на диск до чтения. Потому я склоняюсь что тест на чтение должен работать с файлов после принудительного FLUSH что бы зафиксировать скорость чтение в типовом сценарии потребления.
0
Бывает сильно по разному, например у нас очень часто HB используется для сборки полной версии объекта через комбинацию put-get. Это когда мы получаем вектор изменений (только изменившиеся поля от источника), применяем (put) и тут же делаем get, чтобы получить полный экземпляр объекта для отправки дальше. Однако проверить оба варианта действительно интересно.
+1
В get полного экземпляра у вас будут и «новые» данные из MemStore и «старые» из HFile, так что диски будут задействованы. Причем чтение из MemStore + HDFS возможно будет даже медленее чем если бы вы сразу из HDFS считали объект целиком.
0
Звучит логично, конечно, однако многое зависит от множества сложившихся условий на кластере и иногда бывает контр-интуитивное поведение. Вот к примеру записал данные в 4 таблицы, всего 4 млрд записей. Потом сбросил на диск и прочитал случайные 400 млн (т.е. 10%). Это заняло 41 секунду:
tables=4, threads=100, batch=100, count=100000, dataSize=100, opType=select: 41814.

Затем был сделан рестарт HBase, чтобы почистить кэш, сделан major_compact и залиты те же самые 400 млн ключей по новой, чтобы они лежали и в memstore и в HFile.
И тут же прочитал, и как ни странно, это заняло меньше времени, всего 33 секунды:
tables=4, threads=100, batch=100, count=100000, dataSize=100, opType=select: 33326

Причем если сбросить данные на диск и замажорить, то чтение займет все равно 33 секунды)
0
У HBase небольшой кеш, а вот в кеш файловой системы вполне могло все попасть (у вас там вроде по 700GB памяти).

Зачем major делать до заливки?

Скиньте исходники для HBase. Прогоню на своем нагрузочном кластере. Интересно что у меня получится.
+1
Да, МС был лишний, не подумал про кеш. Версия github.com/cloudera/hbase/tree/cdh5-1.2.0_5.14.2
Тот патч, о котором я писал, играет роль только при кол-во регионов на RS от 800-1000, так что можно не запариваться. Задумал ScyllaDB кстати так же проверить, дам знать что получится)
0
нет смысла, scylla оптимизирована под ssd, у вас же чисто hdd и даже под коммит лог и кеши нет ssd, смысла со scylla нет, плюс scylla требует обязательной оптимизации дисковой подсистемы.
0
Думаю диски потюним, это не быстро, но реально. В любом случае хочется посмотреть что будет)
0
сцилла не умеет JBOD от слова совсем. И похоже они не собираются особо возиться с этим режимом, обосновывая это многочисленными сложностями в реализации и эксплуатации (тут понятно), а так же не особой вообще необходимостью (мол, если raid0 теряет один диск, то ввод ноды с нуля в кластер не займет много времени все равно. Тут уже я и некоторые другие совсем не согласны. Все таки куда лучше было бы потерять один диск и только его, при этом нода жива и возможна горячая замена)

А так, попробовать конечно можно, но с условием raid0. Она хоть под hdd вообще не писалась, но сама по себе внутри чрезвычайно эффективна. Прирост какой-то это даст. Ну и никуда не деваются принципы работы, которые она переняла от касандры, что сильно помогает на hdd само по себе.
0

Печально… А есть возможность высадить к примеру две ноды на один сервер? Или там завязано общение на некий порт и по любому нужно поднимать второй ip адрес?

0
сциллу нельзя, она оптимизирует систему под 1 свой процесс, вообще всю систему, иначе производительность будет хуже. вообще идея несколько бд держать на 1 сервере идиотизм.
0

Ну, не идиотизм. Например, для эластика это штатный режим работы. Но факт в том, что это требует отдельной настройки, причем иногда весьма нетривиальной, т.к. любая база по умолчанию считает, что сервер принадлежит только ей. Плюс эффекты конкуренции за page cache

0
эластик не модифицирует настройки ядра чисто под себя и 1 процесс, в отличии от сциллы. плюс эластик не совсем то с чем надо сравнивать большинство бд, плюс у эластика это проблема в его архитектуре и не умении в 2020 году в heap больше 64 гб, плюс у эластика много проблем с производительностью в целом на мощном железе, он просто не умеет его утилизировать. В отличии от той же сциллы, которая наоборот утилизирует железо по максимуму, нет ограничений по памяти, нет jvm.
0
Сцилла тоже это не делает. Все ее твики в конечном итоге сводятся к общим оптимизациям, которые и другим базам будут полезны.
0
Да, скорее всего придется на разных IP поднимать. Насчет проблем с производительностью, достаточно будет разных дисков, разного набора ядер (сцилла и так себя пинит к конкретным ядрам) и достаточно памяти и никаких проблем с производительностью не должно быть.
0
разрабы сциллы крайне не рекомендуют так делать, они делали её именно с расчётом полной утилизации оборудования, большая часть их клиентов сидит на мощных инстансах aws, и на очень мощном железе. и производительность будет существенно ниже у такой конфигурации по сравнению с 1 экземпляром бд.
0
Не будет она существенно ниже. Иначе бы виртуальные машины и докер не работали, на которых эта самая сцилла прекрасно работает. Главное дать каждому экземпляру свою часть ресурсов — процессор, память, диски. Сделать это не сложно. Сложнее банально разрулить конфликты портов.
0
Да, у них это принципиальная позиция. Которую изменить не удалось в ходе дискуссий с их инженерами. Нода вводится быстрее Кассандровской, но не прям быстро.
Только полноправные пользователи могут оставлять комментарии.  , пожалуйста.