The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra, opennews (??), 22-Янв-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


5. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +6 +/
Сообщение от Орк (?), 22-Янв-19, 13:26 
> Например, 4-узловой кластер на базе Scylla вполне справляется с нагрузкой для которой потребовалось бы развернуть 40-узловой кластер на базе Cassandra.
> Промышленные решения на базе Cassandra, хранящие сотни терабайт данных, охватывающие сотни серверов и способные обрабатывать тысячи запросов в секунду, развернуты для обеспечения сервисов таких компаний и организаций, как Adobe, CERN, Cisco, IBM, HP, Comcast, Disney, eBay, Netflix, Sony, Rackspace, Reddit и Twitter.

Это вы хотите сказать, что эти компании заигрывая с модными Java-решениями мешки с деньгами всё это время в датацентрах сжигали? И отвечать за это бы надо? Да не, бред какой-то!

Ответить | Правка | Наверх | Cообщить модератору

6. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +4 +/
Сообщение от Аноним (6), 22-Янв-19, 13:34 
Эти компании увеличивали капитализацию и цену акций. За счёт потребителя, разумеется.
Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +2 +/
Сообщение от erthink (ok), 22-Янв-19, 13:44 
Эти решения более обкатаны, а риски некоторых видов багов в них действительно ниже (для отдельных багов близко к нулю).
Поэтому их проще использовать и продавать как сервис, и тут не важно что (на самом деле) они жрут в разы больше ресурсов.

В целом, IMHO, дуэль Scylla vs Cassandra очень хорошо показывает соотношение возможностей С++ и Java.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

17. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +/
Сообщение от ДяДя (?), 22-Янв-19, 15:46 
> Seastar учитывает особенности современного оборудования, таких как распараллеливание на многоядерных системах, учёт попадания данных в процессорный кэш

Дело не в платформе, а в дружбе с железом. Лондонская биржа отлично на Java работает (11 млн заявок в секунду на одном ядре). Просто дружат с железом. кучу наград имеют.
https://martinfowler.com/articles/lmax.html
https://en.wikipedia.org/wiki/LMAX_Exchange

Ответить | Правка | Наверх | Cообщить модератору

20. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +3 +/
Сообщение от erthink (ok), 22-Янв-19, 16:06 
>> Seastar учитывает особенности современного оборудования, таких как распараллеливание на многоядерных системах, учёт попадания данных в процессорный кэш
> Дело не в платформе, а в дружбе с железом. Лондонская биржа отлично
> на Java работает (11 млн заявок в секунду на одном ядре).
> Просто дружат с железом. кучу наград имеют.
> https://martinfowler.com/articles/lmax.html
> https://en.wikipedia.org/wiki/LMAX_Exchange

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

Однако, там довольно специфичный код.
Грубо говоря, если присмотреться, то там почти нет ничего от java :)

Все очереди - это кольцевые буферы, которые приклеенные через unsafe к массивам в java.
У всех очередей один producer и один consumer, поэтому без блокировок.
Поэтому вся нагруженная обработка "на java" - это чтение/запись и сложение/вычитание элементов массивов.
Это на lua-JIT будет работать также быстро (и работает в tarantool).

В итоге, с одной стороны, вроде-бы действительно написано на java.
С другой стороны, половина кода написана для борьбы с java через unsafe.

---

IMHO логично приравнять использование Java.Unsafe к C++ - тогда всё становится на свои места.

Ответить | Правка | Наверх | Cообщить модератору

21. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +2 +/
Сообщение от ДяДя (?), 22-Янв-19, 16:38 
Кольцевые буферы - это малая часть. Кстати, все наработки в открытом доступе.
https://www.baeldung.com/lmax-disruptor-concurrency

В счётчиках они боролись с false sharing и сделали выравнивание на 64 байта. Потом этот приём в Java вошел.

Ответить | Правка | Наверх | Cообщить модератору

36. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +/
Сообщение от RNZ (ok), 23-Янв-19, 23:32 
Может оно и имеет низкие задержки, но наверняка под капотом и в ходе эксплуатации выяснится, что  ОЗУ надо в разы больше, что надо "греть" кеш, что периодически всё подтупливает на сборке мусора и и протухании кеша, что валится оно целиком при фаталити в треде и т.д. всё то, что присуще jvm-based серверам.
Как и сказано ранее: Cassandra vs Scylla отличный горчичник.
Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +/
Сообщение от Dim (??), 24-Янв-19, 01:10 
> Может оно и имеет низкие задержки, но наверняка под капотом и в
> ходе эксплуатации выяснится, что  ОЗУ надо в разы больше, что
> надо "греть" кеш, что периодически всё подтупливает на сборке мусора и
> и протухании кеша, что валится оно целиком при фаталити в треде
> и т.д. всё то, что присуще jvm-based серверам.
> Как и сказано ранее: Cassandra vs Scylla отличный горчичник.

Kэш греть надо везде, кроме баз которые заведомо в памяти сидят. В 3.0 в Сцилле добавили такую фичу, и таблицы можно грузить в память заранее: https://docs.scylladb.com/using-scylla/in-memory/

Ответить | Правка | Наверх | Cообщить модератору

47. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +/
Сообщение от RNZ (ok), 24-Янв-19, 12:50 
> Kэш греть надо везде, кроме баз которые заведомо в памяти сидят.

Нет. Греть его надо только когда оно действительно нужно. Обычно, на больших наборах, часто запрашиваемых, не активно изменяемых данных. В большинстве СУБД кеш заполняется по требованию.

Фокус в том что, в jvm прогрев кеша, нужен почти всегда, вне зависимости от применения jvm, иначе о сопоставимой производительности с C++ программами и речи быть не может. Тупо даже IDE'шки на jvm начинают нормально, без лагов и фризов работать, только если дать им значительное время на прогрев, потыкав в менюшки, пооткрывав настройки и т.п.

> В 3.0 в Сцилле добавили такую фичу, и таблицы можно грузить в
> память заранее: https://docs.scylladb.com/using-scylla/in-memory/

Спасибо, я тоже активно наблюдаю за развитием scylladb, готовлюсь к её внедрению.

Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +/
Сообщение от Dim (??), 24-Янв-19, 16:58 
> Нет. Греть его надо только когда оно действительно нужно. Обычно, на больших
> наборах, часто запрашиваемых, не активно изменяемых данных. В большинстве СУБД кеш
> заполняется по требованию.

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


> Спасибо, я тоже активно наблюдаю за развитием scylladb, готовлюсь к её внедрению.

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

Ответить | Правка | Наверх | Cообщить модератору

11. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +/
Сообщение от Аноним (11), 22-Янв-19, 13:50 
Ну так они работали на том, что позволяло работать, и, вполне возможно, убедившись в работоспособности устоявшегося решения, некоторые из них, решили доплатить за отливку в C++
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

14. "Выпуск СУБД ScyllaDB 3.0, совместимой с Apache Cassandra"  +/
Сообщение от Борщдрайвен бигдата (?), 22-Янв-19, 15:23 
Всё правильно сделали?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру