LINUX.ORG.RU

Встречайте ScyllaDB (переписанную на С++ Apache Cassandra)

 , ,


8

5

На Cassandra Summit, Avi Kivity и Dor Laor (создатели KVM и OSv) объявили о создании ScyllaDB — открытой реализации Apache Cassandra на C++

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

Они также получили 1 миллион транзакций в секунду на одной ноде.

>>> Подробности

★★★★

Проверено: maxcom ()

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

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

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

EXL ★★★★★ ()
Ответ на: комментарий от EXL

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

Run repairs and compaction without fear

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

shahid ★★★★★ ()
Ответ на: комментарий от shahid

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

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

anonymous ()

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

Nagwal ★★★★ ()

grim ★★★☆

C++

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

grim ★★★★ ()
Ответ на: комментарий от shahid

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

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

shahid ★★★★★ ()
Последнее исправление: shahid (всего исправлений: 2)

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

Java

Ну ещё бы.

Valkeru ★★★★ ()

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

maxcom ★★★★★ ()

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

andreyu ★★★★★ ()

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

DiKeert ★★ ()
Ответ на: комментарий от shahid

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

Тарантул?

DELIRIUM ★★★★★ ()

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

dib2 ★★★★★ ()

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

kep ()

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

anonymous ()
Ответ на: комментарий от dib2

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

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

kep ()

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

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

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

umren ★★★★★ ()
Ответ на: комментарий от DiKeert

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

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

eReSik ★★ ()
Ответ на: комментарий от umren

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

anonymous ()
Ответ на: комментарий от eReSik

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

DiKeert ★★ ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от EXL

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

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

vada ★★★★★ ()
Ответ на: комментарий от umren

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

shahid ★★★★★ ()

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

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

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

Camel ★★★★★ ()
Ответ на: комментарий от DiKeert

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

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

shahid ★★★★★ ()
Ответ на: комментарий от DiKeert

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

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

anonymous ()
Ответ на: комментарий от shahid

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

DiKeert ★★ ()

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

anonymous ()
Ответ на: комментарий от DiKeert

M/R

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

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

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

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

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

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

shahid ★★★★★ ()
Ответ на: комментарий от shahid

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

shahid ★★★★★ ()
Ответ на: комментарий от Nagwal

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

gns ★★★★ ()
Ответ на: комментарий от maxcom

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

gns ★★★★ ()
Ответ на: комментарий от DiKeert

Кассандра это когда я записываю данные на одну ноду, а они синхронно пишутся еще на 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, Кассандра будет повторить запись ко всем узлам в кластере и ждать подтверждения от двух узлов. Если запись не будет работать на одном из узлов, но успешно с другой стороны, Кассандра сообщает об ошибке, чтобы копировать запись на этом узле. Тем не менее, воспроизведены записи, что преуспевает на другой узел автоматически не откатывается.

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

shahid ★★★★★ ()
Ответ на: Оптимизация когда нужно от Camel

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

DiKeert ★★ ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от DiKeert

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

anonymous ()
Ответ на: Re: Оптимизация когда нужно от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от shahid

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

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

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

nixargh ()
Ответ на: комментарий от shahid

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

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

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

anonymous ()
Ответ на: Re: Оптимизация когда нужно от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

shahid ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.