По утверждению авторов, пропускнaя способность на ноду у ScyllaDB в 10 раз выше чем у оригинального кода на Java

Ну это понятно. Тот же jpscp на Java раз в 15 медленнее и жруще PPSSPP на крестах.

Вопрос, насколько стабильна эта реализация.

На фоне оригинального поделия вопрос стабильности не особо актуален. Даже если сабж будет падать, это уже не так страшно. Об этом по ссылке сказано неявно:

Run repairs and compaction without fear

Но пользовавшие apache cassandra знают, что кроется за этой фразой...

Но пользовавшие apache cassandra знают, что кроется за этой фразой...

Не мог бы ребе раскрыть тему? А то мы в поекте над кассандрой задумываемся.

Интересно, почему на плюсах, а не каком нибудь новомодном Go?

grim ★★★☆

C++

Ты ж вроде на дотнет дрочишь?

Ты ж вроде на дотнет дрочишь?

Онани, не судите всех по себе.

Помимо упомянутого по ссылке repair на неск.дней, можно отменить наиболее крупные проблемы:
- Утечку занимаемого пространства со временем. Например, была тестовая база на неск.гигов максимум (вместе с данными), а занято на разделе > 18гб, бОльше половины commitlog, который раньше отчищался при рестарте, а потом тихо перестал. Надо вручную как-то чистить, но есть риск удалить нужное.
- RAM — ноды 8гб RAM, падают с OOM в логах при запуске major compaction особенно при рестарте, крутить -Xmx Xms и т.д. админы пробовали, но суть одна — в базе не было столько данных (не ключей, а данных вообще!), сколько она сжирала.
- Нет операции «не равно» (<>, !=) в CQL и вообще в кассандре — это бесит.
- Черезж#пный бэкап и восстановление.
Проблемы присутствовали в cassandra 2.0.x, 2.1.x.
Если нужна масштабируемая NoSQL СУБД с поиском — посмотрите в сторону elasticsearch. Пожалуй, что-то лучше найти сегодня нельзя. Ну или стать бета-тестером сабжа.

Если масштабируемое хранилище блобов — seaweedfs например.

пропускнaя способность на ноду у ScyllaDB в 10 раз выше чем у оригинального кода на Java

Java

Ну ещё бы.

Спасибо.

Не очень понятно все ли функции поддерживаются. Counter отсутствует. С остальным не ясно — ttl, paxos, cql типы, есть или нет?

Да, это вам не синтетические тесты, где ява чуть ли не обгоняет плюсы.

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

Если нужна масштабируемая NoSQL СУБД с поиском

Тарантул?

не понял, ведь «Java быстрее С и даже ассемблера» (С) где-то-на-лоре

Естественно, что джава-треш будет работать в разы быстрее, если его переписывать на более менее нормальные языки и платформы, что-бы там не лепетали адепты и трешхэды из мира Enterprise Java.

Молодцы, то что Java дерьмо, умным людям уже давно понятно.

«Java быстрее С и даже ассемблера» (С) где-то-на-лоре

а «если с прогревом», то скорость вообще не поддается всякому измерению, высшая энергия.

По утверждению авторов, пропускнaя способность на ноду у ScyllaDB в 10 раз выше чем у оригинального кода на Java, с временем отклика не превышающим 1мс на 99% запросов.

Ну видимо переписан с Java на X, всегда можно получить выйгрыш на порядок.

Странно, что плюсы выбрали.

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

Можно подробней? Просто интересно

Вы почитайте с помощью чего они получили такой прирост. Они используют raw sockets и юзерспейсный мини TCP стек. Работает только на сетевых от Intel, на других используется стандартный ядерный и скорости будут уже не те. А сколько багов может быть в этом юзерспейсном TCP стеке?

Кассандра это про надежную синхронизацию данных. В рамках одной ноды она не имеет смысла. И в рамках двух нод тоже. И в рамках 10 нод тоже. Кассандра это когда я записываю данные в один data center, а в соседнем через несколько секунд/минут получаю repeatable read-ы этих данных не парясь вообще (понятное дело, есть ограничения и баги в ней, но смысл именно такой). Кассандра это когда я записываю данные на одну ноду, а они синхронно пишутся еще на 50 процентов + 1 узел в кластере и считаются записанными только тогда, когда все их этих 50 процентов + 1 ответили об успешной записи (сколько узлов должны ответить, тоже настраивается, но обычно все ставят в режим кворума их). Кассандра, это когда у меня половина кластера легло, но данные все равно не потерялись. Действие этих ребят можно сравнить, если бы кто-то взял колесо от камаза, раскрутил его до миллиона оборотов в секунду и хвастал бы, какой у них крутой камаз.

дык откуда взять 1млн транзакций если на каждый пакет переключаться в ядро? сейчас это направление только начинает взлетать. вангую бум годных сетевых стеков в userspace к 2020-му. так же как сейчас пошёл на спад бум языков, а до этого заглох бум http/tcp-проксей.

в новости зря не упомянули, что библиотека базовых примитивов, позволяющая достигать таких результатов релизится отдельно: http://www.seastar-project.org/

Вопрос, насколько стабильна эта реализация.

Ждем списка из 100500 уязвимостей, после фикса которых производительность сравняется.
Но коммерческий ход хорош. :)

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

Оптимизация когда нужно

ScyllaDB — открытой реализации Apache Cassandra на C++

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

Кассандра это про ...

И чем оно в итоге отличается от elasticsearch? Ну кроме убогой архитектуры, зоопарка равноубогих java-клиентов и кучи by-design косяков. Зато можно перебирать ключи по порядку. Но стоит ли оно того?

не понимает, что такое кассандра и зачем она нужна

Чтобы трудоустраивать убогих джавистов.

за оптимизацию взялись другие

http://db-engines.com/en/system/Cassandra;Elasticsearch Не особо многим. Свой протокол + возможность immediate consistency, M/R, и более настраиваемая репликация.

Я не агитирую тут за кэсси, я говорю что заявление из топика бред и бессмысленно.

Крестоносцы победили жабу! Снова.

M/R

elasticsearch for hadoop же. Там сравнение устарело. + есть сторонние и как минимум одно наколенное решение.

возможность immediate consistency

Согласен, для биллинга, банков и бирж кассандра подходит.

более настраиваемая репликация

Точно, в кассандре это человеческий конфиг. В ES параметров много, можно выкручивать их.

Ещё кстати в кассандре есть массовый update/delete одной строчкой на стороне сервера. В ES нужно запускать search scan (server-side курсор), и проходить по элементам на клиенте. Хотя такое довольно редко нужно.

Нужно нечто с шардингом (ручками то можно и из файлов на разные сервера шардить, хочеться сервер поключить пару команд с консоли дать и чтобы оно само этот сервер заюзало и загрузило) и при этом умеющее атомарную операцию «прочитал и записал» (либо с блокировкой ключа типа BEGIN; SELECT FOR UPDATE; UPDATE; COMMIT, либо с меткой времени типа как в memcached CAS Compare And Swap). В худшем случае нужно просто хранилище ключей и выборка по заранее известным идентификаторам ключей. Посоветуйте кто что знает пожалуйста!

java RIP

Cassandra вроде как зависит от настроек если replication_factor = 1 то всегда храниться одна копия данных (вопрос насколько надежно и насколько легко делать и востанавливать бекапы во всем этом). Если же replication_factor например 2 то храниться уже две копии и главной считается та у которой время обновления больше. Те возможен вариант что клиент покупает товар (X) - он помещается в первую копию (A), а во вторую копию (B) из за проблем сети нет. Соответственно с одного узла у клиента есть товар, с другого нет. Потом клиент покупает еще один товар Y и он попадает в копию (B) где товара еще нет (ожидает синхронизации) и не попадает в копию (A) из за проблем сети. Потом сеть востанавливается, происходит синхронизация и поскольку последнее время изменения в копии (B) выходит что у клиента только товар Y, а товар X потерян. Если я прав (а похоже это так), то не ясно кому вообще может быть нужен такой глюкодром? Может быть все сложнее и для копии храниться не только время последнего изменения но и история времен изменения? Тогда не ясно как все это мержится... Кто нибудь может это прокомментировать как относительно Cassandra так и других баз с хранением множества копий ключа?

ручками то можно и из файлов на разные сервера шардить

Всё должно работать по нажатию одной кнопки.

либо с блокировкой ключа типа

Гарантированная версионизация по ключу в elasticsearch. Возможный конфликт версий нужно отрабатывать на клиенте, повторно накатывая изменения на повторно полученный документ.
Immediate consistency в cassandra.

Чтобы обойтись без сборщика мусора и искусственного интеллекта в управлении памятью.

Не все сразу, видать... Но от родной кассандры я был в ужасе. Если допилят, то будет годно.

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

Хрен то там:

For example, if using a write consistency level of QUORUM with a replication factor of 3, Cassandra will replicate the write to all nodes in the cluster and wait for acknowledgement from two nodes. If the write fails on one of the nodes but succeeds on the other, Cassandra reports a failure to replicate the write on that node. However, the replicated write that succeeds on the other node is not automatically rolled back.

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

НЕ ОТКАТЫВАЕТСЯ КАРЛ!!!

Потом клиент покупает еще один товар Y и он попадает в копию (B) где товара еще нет (ожидает синхронизации) и не попадает в копию (A) из за проблем сети.

Обычно есть одна primary-шарда (чтение + запись), и есть реплики (только чтение). Реплики подтягивают изменения только из primary-шарды.

При наступлении split-brain в кластере из-за проблем сети между дата-центрами, возможен описанный вами сценарий. И конечно же необходимо такой сценарий как-то отрабатывать (в зависимости от задачи), т.к. это нередкое явление.

а тут люди сначала реализовали и проверили алгоритмы на удобном им языке, а потом взялись за оптимизацию.

Те жаба годна только для концептов? Фигово, но наверное и правда только для этого она и может быть использована.

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

Крестоносцы победили жабу! Снова.

Естественно и ожидаемо.

А вот человек выше говорит что ситуация рассинхронизации данных возникает часто и должна обрабатываться на клиенте

Те жаба годна только для концептов?

Откуда ты вывел слово «только», клоун?

Кассандра это про ...

И чем оно в итоге отличается от elasticsearch?

А как вы так лихо сравниваете базу данных и поисковый движок?

т.к. это нередкое явление.

Мы сможем увидеть всю историю изменений или только последние значения ключа? Сможем ли мы корректно смержить рассинхронизированные ключи? Ведь ключи могут быть не только рассинхронизированы из за обрыва связи, они могли быть изменены и умышленно. Положим на примере товаров X и Y человек мог отказаться от товара удалить его в то время когда записи были рассинхронизированы.

Как это все может использоваться в банковской сфере (как вы написали выше) если оно может выкидывать такие финты ушами?

Откуда ты вывел слово «только», клоун?

Потому что ни для чего иного она не годна малыш.

Не верти жопой, ты сделал вывод из конкретного сообщения.

Как это все может использоваться в банковской сфере (как вы написали выше) если оно может выкидывать такие финты ушами?

В чисто-банковской сфере нужен ACID с транзакциями, elasticsearch тут не подходит, об этом и выше писалось, и ранее. В предыдущем комменте про биллинг речь не шла.

Мы сможем увидеть всю историю изменений или только последние значения ключа?

Если нужна вся история изменений, то запили отдельную модель с историей изменений — всё как и везде.

Сможем ли мы корректно смержить рассинхронизированные ключи?

Этой ситуации вообще не должно наступать.