Комментарии 10
Это как варить кашу из топора, сначала сделали все на Java, а потом потихоньку заменяют на C*
А есть что-то с выборкой по ключу достаточно быстрой, но не повисающей на 1-2 секунды при чтении всех значений по порядку?
Кассандра выполняет запросы типа select * from tab даже с пустой таблицей просто нереальное время.
Кассандра выполняет запросы типа select * from tab даже с пустой таблицей просто нереальное время.
Для кассандры использование * в select — это anti-pattern.
Если вам нужны все записи, то делайте range запросы, чтобы каждый range целиком убирался на 1 ноду. Есть системная таблица где показаны как диапазоны хешей легли на кольцо. Есть псеводфункция, позволяющая делать выборку по диапазону хеша.
В нашем кластере выборки с "*" идут порядка 200000-300000 записей в секунду. В таблице сотни миллионов записей. Диски SSD.
Если вам нужны все записи, то делайте range запросы, чтобы каждый range целиком убирался на 1 ноду. Есть системная таблица где показаны как диапазоны хешей легли на кольцо. Есть псеводфункция, позволяющая делать выборку по диапазону хеша.
В нашем кластере выборки с "*" идут порядка 200000-300000 записей в секунду. В таблице сотни миллионов записей. Диски SSD.
Та то что это антипатерн — понятно. Интересно, какую базу мне надо поставить, что оно вменяемо делало выборку без условий И быстро по ключу.
Первый вопрос — «а нафига?». Вот зачем на практике нужно получать все записи из таблицы? Допустим, у вас их миллиард, что вы с ними будете делать? Мне кажется, это не такой уж распространенный запрос, который будет идти от _каждого_ клиента.
А в тех редких случаях, когда он действительно нужно используете диапазонные запросы. работают они вменяемо. Мне не известна база, которая могла бы распределенным образом выдать select * без указания диапазонов.
Проблема, как я понимаю, вот в чем:
допустим у вас 8 нод и replication factor 3. Допустим первая нода имеет записи с ключами 1 2 3, вторая 4 5 6, третья 1 2 3 7 8 9, четвертая 1 2 3, пятая 4 5 6, шестая 4 5 6, седьмая 7 8 9, восьмая 7 8 9
С диапазонами это сработает, допустим, так — вы генерируете 1й диапазон и координатор направляет запросы к 1й, 3й и 4й — потому что знает что только там могут быть ключи для этого диапазона. Выдается 1 2 3. Дальше вы посылаете запрос для второго диапазона — координатор отправляет на 2ю, 5ю и 6ю и возвращает вам 4 5 6. Дальше вы отправляете запрос на 3й диапазон и координатор знает что он сидит на 3й, 7й и 8й нодах и возвращает вам 7 8 и 9. Без диапазонов — получается что запросы идут ко всем нодам и результаты всех нод сравниваются опять же со всеми. Это хреново. И это и есть причина лагов.
Если не согласны, что без диапазонов нельзя — предложите свой вариант что б без них всё выдалось как надо — без дублей и без пропусков. И не забудьте про вариант, что у вас мог не пройти repair и часть ключей отсутствует на части нод.
Теоретически, конечно, координатов мог бы сам генерировать range запросы для вас. Он то знает диапазоны не хуже вашего. Но вот это не сделано.
По ключу — абсолютно та же песня. Без диапазонов получаете скан всех со всеми. А если разбить на диапазоны — то массив запросов и каждый вернет какое-то количество записей. Работает гладко и быстро.
А в тех редких случаях, когда он действительно нужно используете диапазонные запросы. работают они вменяемо. Мне не известна база, которая могла бы распределенным образом выдать select * без указания диапазонов.
Проблема, как я понимаю, вот в чем:
допустим у вас 8 нод и replication factor 3. Допустим первая нода имеет записи с ключами 1 2 3, вторая 4 5 6, третья 1 2 3 7 8 9, четвертая 1 2 3, пятая 4 5 6, шестая 4 5 6, седьмая 7 8 9, восьмая 7 8 9
С диапазонами это сработает, допустим, так — вы генерируете 1й диапазон и координатор направляет запросы к 1й, 3й и 4й — потому что знает что только там могут быть ключи для этого диапазона. Выдается 1 2 3. Дальше вы посылаете запрос для второго диапазона — координатор отправляет на 2ю, 5ю и 6ю и возвращает вам 4 5 6. Дальше вы отправляете запрос на 3й диапазон и координатор знает что он сидит на 3й, 7й и 8й нодах и возвращает вам 7 8 и 9. Без диапазонов — получается что запросы идут ко всем нодам и результаты всех нод сравниваются опять же со всеми. Это хреново. И это и есть причина лагов.
Если не согласны, что без диапазонов нельзя — предложите свой вариант что б без них всё выдалось как надо — без дублей и без пропусков. И не забудьте про вариант, что у вас мог не пройти repair и часть ключей отсутствует на части нод.
Теоретически, конечно, координатов мог бы сам генерировать range запросы для вас. Он то знает диапазоны не хуже вашего. Но вот это не сделано.
По ключу — абсолютно та же песня. Без диапазонов получаете скан всех со всеми. А если разбить на диапазоны — то массив запросов и каждый вернет какое-то количество записей. Работает гладко и быстро.
У меня их 10-20тыс.
Нафига? Ну мне надо гарантированно быстрые инсерты без локов, потом в потоке передача в микросервисы.
У меня одна нода. Иногда 3.
Тоесть мне надо какаято бд, которая не блочит паралельную запись и позволяет потом «собрать» результат.
По назначению(как key-value хранилище) я кассандру использую, тут проблем нету. А вот как такой буфер мне приходится использовать mysql, inmemory у него имеет table lock, а innodb для такой задачи както странно.
Потому и спрашиваю, что использовать вместо кассандры. Крайне желательно, чтоб оно понимало odbc хотя бы на уровне инсертов.
Нафига? Ну мне надо гарантированно быстрые инсерты без локов, потом в потоке передача в микросервисы.
У меня одна нода. Иногда 3.
Тоесть мне надо какаято бд, которая не блочит паралельную запись и позволяет потом «собрать» результат.
По назначению(как key-value хранилище) я кассандру использую, тут проблем нету. А вот как такой буфер мне приходится использовать mysql, inmemory у него имеет table lock, а innodb для такой задачи както странно.
Потому и спрашиваю, что использовать вместо кассандры. Крайне желательно, чтоб оно понимало odbc хотя бы на уровне инсертов.
Если это временные данные, а ваше объяснение звучит именно так, — используйте memcached, желательно в режиме множественных insert, когда много записей вставляются за 1 вызов.
Если это persistent данные, используйте RocksDB.
В каких-то случаях, особенно при массивном параллельном чтении и относительно редких вставок, лучше всего работает LMDB. Тут неблокирующее чтение всех читающих потоков, и неблокирующая запись 1 потока. Писатели не блокируются читателями и наоборот. Но есть одна тонкость с SYNC. С включенным SYNC запись относително медленная. Всё-таки это BTree, а не LSM tree.
Для remote случаев — есть обертки, позволяющие прокинуть вызов по tcp и даже по udp, что имеет смысл для, например, операций типа логгирования.
Если нужно распараллелить на множество хостов — используйте хеш ключа и по нему адресуйте целевой хост.
Кассандра, и вообще кольца, совсем о другом. Они об отказоустойчивости в первую очередь. Речь об отказе, если 1 хост, например, недоступен, или два. А вы с 1 нодой ничего такого даже близко не получаете. С тремя — получаете, конечно, в какой-то мере. Но право я не знаю вашу задачу. По мне так и три хоста — это ни о чем.
Если это persistent данные, используйте RocksDB.
В каких-то случаях, особенно при массивном параллельном чтении и относительно редких вставок, лучше всего работает LMDB. Тут неблокирующее чтение всех читающих потоков, и неблокирующая запись 1 потока. Писатели не блокируются читателями и наоборот. Но есть одна тонкость с SYNC. С включенным SYNC запись относително медленная. Всё-таки это BTree, а не LSM tree.
Для remote случаев — есть обертки, позволяющие прокинуть вызов по tcp и даже по udp, что имеет смысл для, например, операций типа логгирования.
Если нужно распараллелить на множество хостов — используйте хеш ключа и по нему адресуйте целевой хост.
Кассандра, и вообще кольца, совсем о другом. Они об отказоустойчивости в первую очередь. Речь об отказе, если 1 хост, например, недоступен, или два. А вы с 1 нодой ничего такого даже близко не получаете. С тремя — получаете, конечно, в какой-то мере. Но право я не знаю вашу задачу. По мне так и три хоста — это ни о чем.
не вижу чем этот их велосипед лучше уже известного другого велосипеда
github.com/Netflix/dynomite
который уже на рынке и уже позволяет использовать разные key-value storages
github.com/Netflix/dynomite
который уже на рынке и уже позволяет использовать разные key-value storages
С интересом жду появления первого боевого key-value на Rust'е, который обещается полностью избавить от stop the world в частности (в рамках избавления от активного GC).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Open-source решение для десятикратного снижения задержек чтения данных с Apache Cassandra