Comments 135
Вы уверены, что эти базы колоночные, а не key-value?
Садись, два.
Во вторых, ни один из поставивших минус не аргументировал. Тогда как это факт очевидности уровня википедии:
«A wide column store can be interpreted as a two-dimensional key-value store.»
en.wikipedia.org/wiki/Wide_column_store
Чем обижаться на правду вы бы лучше разобрались чем эти БД отличаются.
Ну или хотя бы почитали следующий раздел той ссылки которую привели:
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.
Ну или хотя бы прочитали дальше следующий раздел той же статьи:
Notable wide column stores include:
Apache Cassandra
Apache HBase
Топик стартер кажется имел ввиду второе
Хуже: он не понимает что это два принципиально разных типа хранения на диске, которые используются для разных целей. И упорствует в своем невежестве :)
Это не разные типы хранения, это вообще перпендикулярные вещи. Ничто не мешает быть СУБД одновременно и wide column, и column oriented. Правда, непонятно, зачем такое, но можно :-)
Мне, если честно, сложно представить как можно хранить строки с переменным числом колонок в традиционном Columnar-формате где каждая колонка хранится отдельно. Даже NULLы в том же Кликхаусе уже эдакий хак.
Понятное дело, что придумать какой-то хак можно и для этого случая, но это будет такой изврат что ужас.
Поэтому я и говорю про дисковый формат — принципиальное отличие Columnar DB именно в том что столбцы хранятся и читаются отдельно.
Hbase – колоночная база данных, реализующая парадигму BigTable
Просто некоторым людям приятнее и важнее считать, что кругом невежды, чем имеет место банальное несовпадение терминологии)
Термин-то устоялся, но "устояли" его маркетологи. Ну или "ушатали" — уж не знаю как точнее/корректнее.
Все эти термины (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" — тогда всё встаёт на свое место.
Сравнение не честное, т.к. про HBase Вы все знаете, а Кассандра, для Вас, черный ящик.
key_cache_size_in_mb — задайте несколько гигов. Он куда более важен для производительности на чтение, чем row_cache, строки и так будут в кеше операционки. И 8 дисков, для данного теста, Кассандре не нужны, она свалит все на один. Много дисков понадобится для множества кейспейсов и таблиц. Писать с CL=ALL, это еще можно понять, но читать смысла нет, достаточно LOCAL_QUORUM.
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
MAX_HEAP_SIZE=«80G»
HEAP_NEWSIZE="*M" где за основу берётся кол-во физический ядер -2(если говорим о физ железе)
Не битва, а схватка. Воскресная схватка.
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 мб, дисковая подсистема была почти полностью загружена.
Этот комментарий интереснее и полезнее чем вся статья =)
>>как в сбербанке искали способ не работать 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, однако как вы пишите, что диски при этом полностью нагружены. Таким образом, при прочих равных, другие операции с дисками будут выполняться гораздо медленнее, что для нас очень важно, так как в ПРОМ рядом крутится много другого софта.
без ssd отдельного под систему и кеши смысла ставить cassandra нет. плюс что hbase что cassandra должны жить на отдельном от другого софта железа(за исключением spark, их лучше на одной ноде, если позволяет конфигурация)
SSD стали дешёвые, заказать ssd вполне реально, особенно учитывая сколько потом это будет экономить оборудования. Более того с выходом qlc ssd, можно вообще на них перейти и цена схожа будет с enterprise hdd. Плюс у вас нет update и потому запись у меня могла бы быть сильно больше.
На счёт xfs ссылку вряд ли дам, у scylla в было где то в бенчах, но про xfs я узнал на irc cassandra и из google рассылок.
По скорости cassandra не вызывает воспросов. Но как-то встретил образную фразу "шлейф записей" который образуется из-за того что вставка происходит с приоритетом по сравнению с обновлением. А поскольку у кассандры нет разницы между вставкой записи и ее обновлением (есть запись с идентификатором — она обновится, нет записи — она добавится) то я лично столкнулся при тестировании небольшого кластера данных с такой аномалией. При массовой вставке записей с одинаковыми (уже существующими) идентификаторами, если запросить селектом количество записей то будет выдана цифра превышающая общее колчиепситво записей. Такое впечатление что кассандра сначала вставляет новую запись и она уже может быть посчитана. В то время когда ее дубликат еще не выявлен и и также существует в базе данных. Потом после окончания массовой вставки это количество приходит в консистентное состояние. Наверное это и называется шлейфом данных и из-за этого какой-то мессенджер (чуть ли не скайп) от нее отказался.
Я думаю это не то поведение которое годится для банковских приложений?
Конечно небесполезно знать кто из "динозавров" большие греет атмосферу. Но может всё-таки ScyllaDB вместо Cassandra?
Но это с позиции разработчика так все просто. С devops это абсолютно другая база. Она отдаленно похожа своей концепцией на касандру, но устроена совершенно по-другому. Даже установить ее на сервер это целая наука.
который из официального докер образа не работает
Возможно. Там в конфиге в докер-образе есть отличия от обычной установки. Местами я бы даже сказал странные. Когда часть надо загонять как параметры контейнера, а часть — как и прежде, через файлы конфига.
Что же касается определённого вида железа — как по мне, rocket science тут нет. Чуть больше внимания уделяется настройке железа, когда у других баз данных приходится уделять больше внимания просто настройкам. Хотя после того же mssql требования сциллы к настройке железа не выглядят чем-то эдаким необычным.
По DPDK вообще, кстати, материала много не видел. Как-то вскользь упоминается (как и некоторые другие вещи), но без сильных подробностей. При этом по тому же докеру они у себя достаточно обширный пост в блоге накатали в своё время
https://www.scylladb.com/2018/08/09/cost-containerization-scylla/, по которому получается, что сцилла критично вроде бы не просаживается. Здесь не готов сказать. Каких-то негативных эффектов в части производительности при переходе в контейнеры (при сохранении самой версии сциллы) не заметил. По DPDK вообще не уверен в ситуации, когда сцилла и так из ssd выжимает всё, что те могут дать — сеть не самое узкое место. Хотя есть DPDK затрагивает производительность дисковой системы, то тут надо думать, очень хорошо думать. Вдруг чудо действительно произойдёт.
теоретически, как я понимаю, docker не мешает работе dpdk…
А вот снижение скорости работы в докере относительно режима без докера я В ПРИНЦИПЕ наблюдал. Есть способы его минимизировать, но your mileage may vary
Единственный вопрос, почему она до сих пор на 8 месте того же DB-Engines Ranking.DB-Engines для рассчёта ранга использует поисковые запросы, вопросы на Stack Overflow, упоминания в вакансиях и т.д..
Однако так как ScyllaDB стремится к полной совместимости, то с точки зрения пользователя они никак не отличаются, и не имеет смысл гуглить синтаксис запросов или лучшие практики создания структуры бд для ScyllaDB, когда такого материала полно для Cassandra.
Специфичные для ScyllaDB вещи гуглят в основном админы и таких запросов на порядки меньше.
Это нормальная практика для drop-in замены.
Например, каждый раз когда мне нужно подсмотреть синтаксис запросов в VictoriaMetrics, я гуглю как это сделать для Prometheus, потому что по нему больше материала, а про VictoriaMetrics я гуглил только один раз, когда её устанавливал.
1. Батчи сами по себе это антипаттерн и очень медленные. Еще хуже, когда, как у вас, они покрывают несколько партишенов, что включает LOGGED режим. Потенциально каждый батч затрагивает все ноды одновременно, т.к. хэширование ключей рабросает их в случайном порядке по всем нодам
2. Выборки с IN тоже захватывают кучу партишенов. Каждая выборка будет ходить за данным на все ноды.
Так что стоит таки по-лучше почитать как датастакс делает подобные измерения или сцилла.
На всякий случай пробовал выключить батчи и делать запросы поштучно, но получается в разы медленнее. В частности первый тест на запись вместо 137 тыс. ops показал 54. Аналогично на чтение, вместо 159 стало 56. Но это не значит что CS работает плохо, HB в этой ситуации будет вести себя аналогично.
Тоже самое с IN. Только недавно переписывал его на параллельный запрос всех ключей, которые в IN. Получается заметно быстрее, что не удивительно, т.к. нагрузка размазывается ровно по всем нодам, а не отдается на откуп одном координатору. А параллельность скрывает задержки на round-trip'ы на каждый запрос.
Проблема с батчами из нескольких партишенов в том, что они не скейлятся. Кассандра предназначена для сотен и тысяч нод. Подобный батч означает, что на одного единственного координатора ложится задача этот батч выполнить, что потребует послать запрос, потенциально, на каждую ноду в кластере.
Батчи идеально подходят, когда партишен в запросе один, а строк в него вставить много надо (через clustering key). В этом случае можно делать без всяких опасений UNLOGGED батч и получать серьезный прирост.
Было: 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
Потом применю другие советы по тюнингу, прогоню полный цикл тестирования и добавлю результаты в конце поста.
Именно! Батчи в Кассандре созданы для обеспечения атомарности запросов, а не для ускорения загрузки.
Для загрузки должны использоваться АСИНХРОННЫЕ операции. Даже при работе с асинхронными запросами есть нюансы: для ожидания надо использовать не get(), а get uninterruptible(), который является не блокирующим, в отличие от первого. В этом случае можно в одном потоке обеспечить максимальную производительность.
По моему опыту, скорость загрузки в базу в асинхронном режиме была в 5 раз выше, чем в батчевом, видимо из-за того, что было 5 узлов.
Да и попробовать отечественный продукт Яндекс ClickHouse было бы весьма патриотично!
По скорости вставок Click не проигрывает, примерно совсем. Другое дело, что у него (и в любой append-oriended базе) эти вставки совсем другие.
Сложные запросы Click умеет быстро не "пока памяти хватает" (это не java), а потому что он более-менее оптимально умеет отображать сложный запрос в конвейер чтения и фильтрации чанков колонок с дисков, и всё это в кластере. У клика гораздо больше шансов существенно меньше читать с дисков, если это в принципе возможно для некого запроса. Соответственно, в сценариях для которых сделан клик, на сопоставимом оборудовании, у обсуждаемых БД кране мало шансов конкурировать.
Тем не менее, это сильно разные БД для принципиально разных сфер применения и сравнивать их — как теплое с мягким.
Я не про быстро, а вообще. Сложные запросы по определению либо требуют дофига памяти, либо скидывать промежуточные результаты на диск. Чудес тут никаких нет и CH умрет с out of memory запросто как любая другая база, которая умеет сложные агрегации делать. Понятное дело, что на касандре той же подобные запросы просто напросто невозможны, но есть всякие спарки и прочие хадупы, которые конечно медленнее, но скейлятся вполне. Правда и там можно помереть, когда все схлопнется до одной ноды и у нее кончится память. Да и никуда от менее эффективного представления данных на диске не уйдешь.
В КХ есть распределенные джойны в каком то виде. Ну и вообще данные размазываются по шардам как везде. Поэтому агрегации частично идут локально на всех шардах, а финальная часть уже исполняется там где запрос инициировался. Эдакий мапредьюс.
Не хочу вступать в непродуктивный спор, ибо базы для разных целей. Но в отношении CH у вас всё-таки немного заниженное мнение:
CH предназначен на впитывание данных с одновременной обработкой запросов. В этом режиме одиночные вставки не имеют смысла. Рационально вставлять раз в секунду или по ~100К, а как-то сильно иначе — просто нагрев. CH реализует это очень хорошо и без лишних движений (делит данные на по-колоночные чанки и пушит в LSM).
"Плохие" сложные агрегации (и прочие кошмары) потребуют памяти в любой БД. "Спарки и хадупы" имеют те же проблемы (если промежуточный результат не влезет в память, то ой). Хотя и для "спарков" и для CH есть рецепты решения таких задач.
Что касается эффективности представления данных на диске, то CH хранит данные по-колоночно со сжатием — придумать что-либо эффективнее сложно. Т.е. в отличие от касанды и спарка, в CH значения, которые с большей вероятностью похожи/близки, в среднем хранятся "ближе" друг к другу и поэтому лучше сжимаются.
Посмотрите что происходит с КХ в режиме вставки около 1,5 млн/сек в реплицированные таблицы. Как раз верхняя граница буфера чуть больше 1 млн.
>Что касается эффективности представления данных на диске, то CH хранит данные по-колоночно со сжатием — придумать что-либо эффективнее сложно.
Поколоночно и с сжатием хранят все, для спарка аж 2 формата — паркет и орц так хронят. В кх еще есть сортировка.
Посмотрите что происходит с КХ в режиме вставки около 1,5 млн/сек в реплицированные таблицы. Как раз верхняя граница буфера чуть больше 1 млн.
Не совсем понимаю, какую мысль вы хотите выразить? То что параметры по-умолчанию не оптимальны (или не подходят) для сценариев при вставке 1500К — это очевидно. Как в любом OpenSource для эксплуатации в "не ширпотребных" сценариях требуется донастраивать/докручивать продукт (досконально разобравшись в нём), либо покупать поддержку.
На всякий, для понимания — в ClickHouse, как во всех LSM есть проблемы с распределением "полосы пропускания" дисков между слиянием внутри LSM, обслуживанием репликации и чтением для обработки запросов. В своём приватном форке мы более-менее решили эту проблему, но только для нужного нам набора сценариев. А вот насколько эта проблема сейчас решена в upstream я не в курсе.
умрет с out of memory запросто как любая другая база, которая умеет сложные агрегации делать.
Ну зачем же так обобщать? PostgreSQL довольно сложно уронить по OoM. По крайней мере, одним запросом. Т.к он может сбрасывать промежуточные данные на диск. Конечно, и у него бывают промашки, но вроде бы редко.
В КХ тоже есть режим группировки на диске. И даже, что интересно, часто он не вызывает фактического протекания на диск т.к. dirty cache страниц ядра не успевает сброситься на носитель.
Я думаю, что шла речь о том, что запрос отбивается — т.к. то что КХ умирает по ООМ я не видел, а вот запрос — да, сбрасывается
Да, с обновлениями и удалениями записей у ClickHouse не всё радужно (хотя и есть решения) — но эти операции вообще узкое место для колоночных СУБД (и не колоночные СУБД их вообще поддерживают; ClickHouse поддерживаются Join — что для колоночных СУБД так же не частая фишка). Вот поэтому интересно сравнить ClickHouse с колоночными якодзунами — в т.ч. на обновление и удаление (ведь всё-таки оно возможно в ClickHouse — хотя в таких СУБД такие операции используются не часто, зачастую просто заменяясь периодическим перестроением таблицы, с удалением лишнего, и видением версий актуализации).
Патриотичность в таких делах роли не играет (и не должна играть). Сугубо прагматизм.
По факту единственная, у кого на паре серверов и 100к+/сек запросах не скакали максимальные задержки. У Cassandra они до 500мс прыгают(aerospike — 3ms).
Честно скажу, опыт только с кассандрой, с 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...
Я не сварщик, но HBase все-таки не такой уж и тупой.
Мастером для данных является каждый регион сервер (для регионов, за которые он отвечает). Соответственно, при падении регион сервера будет недоступна часть данных, пока эти регионы не назначатся на другие регион сервера.
Мастер кластера отвечает за изменение метаданных. За хранение отвечает Сторож Зоопарка. Соответственно, если упал мастер кластера, то не получится поменять состав кластера или схему данных. Однако читать и писать данные вы сможете.
Конечно, если упал мастер кластера и регион сервер одновременно, то данные не будут доступны пока кого-нибудь из них не поднимете, т.к. без мастера кластера регионы не переедут на другие регион-сервера.
И для мастера кластера и для регион-серверов вроде как в последних версиях можно назначать слейвов, что сильно уменьшает время простоя.
Как долго после падения регион сервера кластер это понимает и как долго переезжает регион мастер?
Как об этом узнают клиенты?
Насколько это автоматически?
(Как вообще это выглядит для клиентов, если не секрет, интересно узнать)
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…
Split time тут лишнее.
Вы сильно раздули MemStore потому у вас при падение RS нужно много данных вычитывать из WAL. У нас после падение RS рекавери за 1-2 минуты проходит.
> На версии 2.1.0 наблюдали как RS упал, а переезд не начался
Как по мне так намного чаще регионы зависают в transition по разным причинам и их приходится в ручном режиме пропихивать.
Насчет дисков, как я понял, у них тут все идентично. Данные легли на все диски равномерно, в комментариях выше это подтвердили. Также WAL пишется в HB как и CS и тоже делает sync.
>>А если сравнивать — пишите в большое кол-во потоков
Поменял схему, вместо записи в 5 потоков батчами по 100 штук писал 100 потоков поштучно. Никакой разницы не было. Однако на чтение вместе с TokenAwarePolicy скорость выросла в 2 раза, с 159 644 до 301 969.
Попозже проведу более полное и тщательное тестирование, с учетом других предложенных оптимизаций и добавлю в конец поста.
"CS может использоваться в режиме допускающем потерю данных. Т.е. это когда только один сервер (нода) отвечает за данные некоего ключа и если он по какой-то причине отвалился, то значение этого ключа будет потеряно."
Если он отвалится, то данные не будут потеряны, они просто не будут доступны пока вы не поднимите эту ноду, а до тех пор вы получите ошибку чтения/записи, логично, ведь… вы сами задали хранение на одной ноде (rf=1).
Cs позволяет делать разные настройки для кейспейса (группы таблиц) и из коробки имеет понятие датацентра и настраиваемой политики реплик между дц. Так же можно задавать разную политику консистенции для каждого отдельного запроса. Так что вы сами настраиваете консистенси и авайлабилити считайте чуть ли не на каждый запрос, естественно, если вы хотите выстрелить себе в ногу, то cs даст вам массу возможностей, однако если вы знаете, что вы делаете, всё можно использовать в соответствующих юзкейсах.
Так же у cs присоединяются (и отсоединяются) ноды без дауниайма и какой-либо латенси.
Наш юзкейс это большое кол-во key=value записей (в основном) и чтений (~10:1) (рандомных по ключу), но все по одно и латенси критично (так что никаких батчей не получится собрать), но благодаря вашей статье я попробую посмотреть в сторону hbase ещё раз (5ть лет назад уже смотрел и тогда выбрал cs).
arheops писал про задержки в 500мс, это не cs, это java gc, если правильно под вашу нагрузку настроить и долгих gc, а тем более stw не будет (а 500мс это возможно оно), то вы даже 5мс никогда не увидите.
(Про scylladb знаю, но с ней были непонятки/проблемы год назад, может тоже посмотрю ещё раз)
Да, я вас понял, просто придрался :) к фразе, что может работать в режиме допускающем потерю данных, она может работать с любым количеством реалик и если копия только одна, то как бы вы ж сами выбрали, то есть это не минус это плюс, есть выбор, возможно вам для определённых таблиц не нужно лишнее дублирование и данные там если что не жалко.
Да, у нас тоже прилично данных, а главное куча изменений и ssd диски регулярно сыпятся, потому очень удобно иметь возможность в любой момент просто вытащить ноду из кластера (просто выключить) и что-то с ней поделать без пенальти.
Сёходзан (тот, что на фото справа — у вас он с подписью HBase) никогда не был ёкодзуной :-)
Зачем нужна cs когда есть scylladb. Автор попробуй с ней сравнить hbase
Для эффективной работы Cassandra надо тонко тюнить Жабомашину. Из коробки она проигрывает в зависимости от типа тестов от 2 до 9 раз (это наши тесты на тестовых контурах 2 реальных систем).
Ноды Scylla гораздо быстрее поднимаются и реже «падают». В кавычках, т.к. сталкиваемся в кластере на Cassandra (33 ноды) в том числе с тем, что нода отвечает на все команды, но при этом не пишет и не отдает данные.
Лицензионная политика примерно одинакова с Datastax. Есть OpenSourse и Enterprise версии.
Для военных Scylla имеет полную совместимость с Astra Linux SE 1.6.
Товарищ подсказывает по Кассандре:
- не используйте батчи для записи во многие партиции. (Об этом даже DataStax пишет)
- используйте параметризованные запросы вместо склейки строк. Тогда и коннектору и кассандре будет проще разбирать запрос, чтобы понять в какой сервер его посылать.
- в коннекторе необходимо указать TokenAwarePolicy (хотя, вроде DataStax коннектор ставит ее по умолчанию)
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 секунды)
Зачем major делать до заливки?
Скиньте исходники для HBase. Прогоню на своем нагрузочном кластере. Интересно что у меня получится.
Тот патч, о котором я писал, играет роль только при кол-во регионов на RS от 800-1000, так что можно не запариваться. Задумал ScyllaDB кстати так же проверить, дам знать что получится)
А так, попробовать конечно можно, но с условием raid0. Она хоть под hdd вообще не писалась, но сама по себе внутри чрезвычайно эффективна. Прирост какой-то это даст. Ну и никуда не деваются принципы работы, которые она переняла от касандры, что сильно помогает на hdd само по себе.
Печально… А есть возможность высадить к примеру две ноды на один сервер? Или там завязано общение на некий порт и по любому нужно поднимать второй ip адрес?
Ну, не идиотизм. Например, для эластика это штатный режим работы. Но факт в том, что это требует отдельной настройки, причем иногда весьма нетривиальной, т.к. любая база по умолчанию считает, что сервер принадлежит только ей. Плюс эффекты конкуренции за page cache
CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text)
При такой схеме кличество "регионов" (разделов) в cassandra совпадает с количеством ключей. Т.е. их очень много. На SSD это не так заметно, но при работе с HDD производительность может сильно проседать.
В этом смысле эквивалентная с hbase конфигурация выглядит так:
CREATE TABLE ks.t1 (region smallint, id bigint, title text, PRIMARY KEY (region, id))
Заполнять надо на клиенте, region = id % NumOfRegions. При чтении, соответственно, region надо тоже указывать.
Битва двух якодзун, или Cassandra vs HBase. Опыт команды Сбербанка