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

Речь про elasticsearch, а не про lucene.

Речь про elasticsearch, а не про lucene.

Elasticsearch is a search server based on Lucene.
И используется он вместе с Кассандрой тоже.

wikipedia.org

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

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

как я смогу это сделать в обычном SQL

В RDBMS не бывает split-brain? А мужики-то не знают... Транзакции в wall-log'ах просто облегчат разруливание, сути это не меняет.

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

собственно поделие на SQL с ручным шардингом мы сейчас и используем, но интересуют возможные решения с полу- или автошардингом и без новых странных проблем типа описанных выше

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

Fixed.

Решение проблем split-brain — это комплексная задача, очень сильно зависит от обстоятельств, ценности информации и имеющихся ресурсов.

Идеальных решений не бывает. А проблемы все решаемы. Шардинг с event-consistency требует соответствующих решений со стороны программиста, в т.ч. денормализацию некоторых моделей.

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

но разговоры про рассинхронизацию это случай хранения нескольких копий ключа, а так же интересует база с автошардингом и атомарным изменением ключа (select for update либо CAS) с одной копией ключа (без всех этих спец эффектов).

Транзакции в wall-log'ах

wall-log

O_o

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

Не верю! Это как нужно было тяп ляп писать этот ScyllaDB чтобы скорость увеличилась всего лишь в 10 раз.

Автомёржа на уровне elasticsearch не было и не будет. Это практически везде так, т.к. вообще не ясно, как это должно происходить.

В случае наступления split-brain на elasticsearch нужно отказаться от части изменений на части узлов, а потом снова выпавшие ноды подключить к оставшемуся кластеру. (systemctl restart elasticsearch). Всё остальное запиливается на собственное усмотрение.

я спрашиваю вообще не только про cassandra и elasticsearch, возможно есть что-то еще. riak например или еще что-то.

riak

Когда тыкал палочкой, там всё было печально в целом.

возможно есть что-то еще

Автоматом оперативно выявлять split-brain, предотвращать возникновение конфликтующих изменений на уровне DNS и nginx, направляя все запросы в какой-то один дата-центр или возвращать клиентам ошибки на время фейловера, ну и т.д.

ну а без многих копий ключа (без split-brain), но с шардингом и атомарным «прочитал ключ, записал ключ»? что самое быстрое и надежное?

Если нужна масштабируемая NoSQL СУБД с поиском — посмотрите в сторону elasticsearch. Пожалуй, что-то лучше найти сегодня нельзя. Ну или стать бета-тестером сабжа.

elasticsearch сосёт с причмоком на частой записи. И гарантии по консистентности у него на уровне плинтуса. read-your-writes, linearizable reads and writes, eventual consistent counters - нет не слышали. Вообще эластик и кассандра для совсем разных вещей сделаны, их сравнивать некорректно.

Кассандра это когда я записываю данные в один data center, а в соседнем через несколько секунд/минут получаю repeatable read-ы этих данных не парясь вообще

В общем случае без paxos - repeatable read никто не гарантирует, сюрприз.

Числоконцепты

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

Неверный вывод. Скорее «пригодность Java для числодробилок не очевидна». Подавляющее большинство программ никогда не растут до числодробильных объёмов и задач Cassandr'ы.

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

Первая проблема, что вспомнил: Эластик не умеет разделять шарды, поэтому масштабирование ограничивается заранее заданным при создании индекса кол-вом шардов. При этом если заранее создать много шардов, то деградирует производительность. Их в идеале должно быть не больше пары-тройки на машину. В итоге эластик машстабируется без пересоздания индексов максимум на начальное кол-во машин * 4.

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

По теме консистентности кассандры и эластика можно глянуть чумовые посты от aphyr:

• https://aphyr.com/posts/294-call-me-maybe-cassandra
• https://aphyr.com/posts/317-call-me-maybe-elasticsearch
• https://aphyr.com/posts/323-call-me-maybe-elasticsearch-1-5-0

И вся серия: https://aphyr.com/tags/jepsen

Там этот парень поясняет про модели консистентности, мучает много разных распределённых БД split-brain'ами и проверяет, что становится с данными.

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

Pick one. Нет, серьезно, писать серверное ПО на крестах то еще изщвращение, я считаю. ИМХО, на крестах десктопное ПО и игры писать самое то, но никак не сервера.

О хосспаде, не упоминай имя диавола mail.ru всуе! Чем mongo не угодил?

Быстрота кода зависит по большей части от прокладки между стулом и клавиатурой. JVM умеет в JIT, когда в компилируемых языках/плоатформах тебе надо выбирать между «оптимизировать исполняемый файл под определенный CPU» и «чтобы оно везде работало». Естественно, JVM оверхеад добавляет, особенно по памяти, но на крестах легче набыдлокодить так, что память течь будет.

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

пока только бета, но мужики там с руками, нормальные

Не очень понятно все ли функции поддерживаются.

пока там еще много yet to be implemented

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

какие альтернативы предложит благородный дон?

Зато можно перебирать ключи по порядку.

можно подумать в ES нельзя ))

elasticsearch сосёт с причмоком на частой записи.

ко-ко-ко

И гарантии по консистентности у него на уровне плинтуса.

это есть такое

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

«CPL.1: Prefer C++ to C» Дальше можно не читать (c) в соседнем топике... Типа они тоже прочитали досюда.

Ну paxos в ней имплементирован и можно включить. Ну и кворум обычно практически означает repeatable read-ы. Все равно, если твоя система распределенна (а с кэсси она распределенна), значит тебе пора биться над тем, что бы она была идемпотентна.

о, а вот и диванная самка приблудилась в тред. всем тихо слухать

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

Очевидно потому, что для этой задачи Go подходит хуже, чем C++. Странно, что ты не спросил «почему изначально на Java писали?», но это, видимо, немодный ныне наброс, хотя и на него есть рациональный ответ.

Не верю! Это как нужно было тяп ляп писать этот ScyllaDB чтобы скорость увеличилась всего лишь в 10 раз.

В 5 раз быстрее стало из-за сетевого стека в юзерспейсе, ещё в 2 раза - из-за отсутствующих затыков на сборку мусора.

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

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

Даже если сабж будет падать, это уже не так страшно

Да, лишь бы плюсоидам кость кинули

wall-log

Rocket science же. http://i788.photobucket.com/albums/yy165/noobiemovies/wall-eposter.jpg

А чем мыло.ру не угодили?

Откровенно гумусным почтовым сервисом, например.

В 5 раз быстрее стало из-за сетевого стека в юзерспейсе

С галерки требуют пруф.

А с ним-то что не так? Я как раз в нём работал (бэкенд).

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

И это хорошо.

Собственно нет, он ненавидит Java, это похожее, легко спутать, но разница есть

С галерки требуют пруф.

http://www.seastar-project.org/ а точнее вот http://www.seastar-project.org/img/memcache.png

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

Готов поспорить что in-memory дергали парочку ключей

И где там оценка влияния юзерспейсного сетевого стека?

Естественно, что треш будет работать в разы быстрее, если его переписывать

Fixed, это называется редизайн и разработка более современного софта