Представлен (https://groups.google.com/forum/#!topic/scylladb-users/rMEcA...) релиз СУБД ScyllaDB (http://www.scylladb.com/), позиционируемой как полностью совместимый аналог СУБД Apache Cassandra (https://www.opennet.ru/opennews/art.shtml?num=42717), переписанный с Java на C++ и демонстрирующий существенное увеличение производительности. Код проекта распространяется (https://github.com/scylladb/scylla) под лицензией AGPLv3.По сравнению с оригинальной СУБД Apache Cassandra проект ScyllaDB обеспечивает (http://www.scylladb.com/technology/cassandra-vs-scylla-bench.../) увеличение скорости обработки запросов на каждом узле в 10 раз, в 99% случаев успевая обработать запрос менее чем за миллисекунду. Обработка большего числа запросов на одном узле позволяет существенно снизить затраты на кластер (при использовании AWS EC2 в 2.5 раз), в котором для достижения заданных характеристик потребуется на порядок меньше узлов, чем при создании кластера на основе классической СУБД Cassandra. Например, 4-узловой кластер на базе Scylla вполне справляется с нагрузкой для которой потребовалось бы развернуть 40-узловой кластер на базе Cassandra.
Одним из факторов, позволившим добиться высоких показателей производительности, является использование развиваемого теми же авторами C++ фреймворка Seastar (http://www.seastar-project.org/), нацеленного на создание сложных серверных приложений, обрабатывающих запросы в асинхронном режиме. Seastar учитывает особенности современного оборудования, таких как распараллеливание на многоядерных системах, учёт попадания данных в процессорный кэш, оптимизация для накопителей SSD, прямой доступ (http://www.scylladb.com/technology/network/) к очереди пакетов на сетевой карте и полная утилизация пропускной способности 10/40-гигабитных сетевых карт.
Система построена на основе архитектуры shared-nothing (http://www.scylladb.com/technology/architecture/), подразумевающей, что к каждому ядру CPU привязывается отдельный обособленный обработчик, которому выделена отдельная память (отсутствуют (http://www.scylladb.com/technology/memory/) задержки из-за организации блокировок) и привязана отдельная очередь пакетов к сетевой карте. Каждый процесс-обработчик ScyllaDB включает в себя собственный оптимизирванный TCP/IP-стек, работающий в пространстве пользователя, прикреплённый к отдельному ядру CPU и напрямую взаимодействующий с сетевой картой.
Другие особенности ScyllaDB:
- Поддержка работы в качестве прозрачной замены Apache Cassandra;
- Возможность применения существующих клиентских драйверо от Apache Cassandra для подключения к ScyllaDB;
- Поддержка модели хранения данных на базе семейства столбцов (ColumnFamily, хэши с несколькими уровнями вложенности);
- Возможность использования SQL-подобного язык структурированных запросов CQL (Cassandra Query Language);
- Исключение задержек при проведении упаковки и восстановления целостности БД;
- Отсутствие сборщика мусора;
- Возможность переконфигурации кластера (удаление/добавление узлов) без остановки работы;
- Линейная масштабируемость, при которой производительность находится в прямой зависимости от числа процессорных ядер;
- Наличие средств для пакетной загрузки и выгрузки больших объёмов данных из хранилищ Hadoop и Spark.
Выпуск СУБД ScyllaDB 3.0 по функциональности соответствует ветке Apache Cassandra 3 и примечателен следующими улучшениями (https://www.scylladb.com/2019/01/17/scylla-open-source-3-0-o.../):
- Поддержка материализованных представлений, позволяющих сформировать виртуальную таблицу на основе произвольного CQL-запроса, содержимое которой не генерируется на лету как в обычных представлениях, а кэшируется между запросами в форме индекса;- Добавлена поддержка глобальных для всего кластера вторичных индексов (GSI, Global Secondary Indexes), реализованных через материализованные представления и позволяющих более эффективно индексировать запросы по ключам с агрегированием данных на одном узле;
- Предложен новый формат хранения данных на диске, совместимый с Apache Cassandra 3.0 и требующий для хранения до 66% меньше места в хранилище по сравнению со старым форматом при активном использовании операций удаления записей. Применение нового формата отключено по умолчанию и может быть активировано через настройку "enable_sstables_mc_format";
- Добавлен новый механизм хранения информации о репликах для сбойных узлов ("hinted handoff"), вместо одного файла system.hints хинты теперь записываются в отдельные файлы, в разрезе один файл на один узел и реплицированный поток;- Существенно улучшена работа операций полного (мульти-секционнного) сканирования БД, при которых данные перебираются без выборки по конкретному ключу;
- Добавлена поддержка фильтрации сложных запросов с возвращением только подмножества результатов. Фильтрация производится на стороне сервера и позволяет существенно снизить размер передаваемых по сети данных между кластером и приложением;- Осуществлён переход на штатные утилиты Cassandra, включая nodetool, cassandra-stress и node_exporter 0.17;
- Увеличена производительность потоковой отправки данных при добавлении нового узла или восстановлении после сбоя.URL: https://groups.google.com/forum/#!topic/scylladb-users/rMEcA...
Новость: https://www.opennet.ru/opennews/art.shtml?num=50005
> работающий в пространстве пользователя, прикреплённый к отдельному ядру CPU и напрямую взаимодействующий с сетевой картой.А так можно было? Я всегда думал что только из пространства ядра можно напрямую с периферией работать, в этом и есть одна из основных задач ядра.
можно, работай.только учти, что да, это одна из задач ядра, и оно ее решает достаточно хорошо, в большинстве случаев, это все же писали хорошие программисты, когда-то.
Что там у этих оптимизаторов из сциллы - хз, как-то слабо верится, что получилось - хорошо.
хорошие программисты всё равно не умеют ни нулевые накладные расходы на копирование в userspace и обратно, ни нулевые же накладные расходы на переключение контекста.
> Что там у этих оптимизаторов из сциллы - хз, как-то слабо верится, что получилось - хорошо.Если говорить про zero-copy "из ядра", то там вся прозрачно/понято (Intel DPDK).
Работает действительно просто:
- выделяете кусок памяти в своем приложении.
- через библиотеку просите класть такие-то пакеты в этот буфер (ioctl к драйверу).
- драйвер сетевухи настраивает её так, что пакеты из сети сразу попадают в ваш буфер.
- профит.
ну да, только результат этого зирокопирования надо разобрать обратно на байтики высокоуровневого протокола, не забыть низкоуровневым сгенерить ответы (ну ок, современная карта большую часть возьмет на себя, там оффлоад) и правильно обработать таймауты/потери (вот это она за тебя делать не будет). И не особенно-то это и просто покажется, если на минутку заглянуть в ядерный код.насколько у авторов тазы банных получилось хорошо и тем более - надежно - вопрос, требующий отдельного изучения.
> ну да, только результат этого зирокопирования надо разобрать обратно на байтики высокоуровневого > протокола, не забыть низкоуровневым сгенерить ответы (ну ок, современная карта большую часть возьмет на себя, там оффлоад) и правильно обработать таймауты/потери (вот это она за тебя делать не будет).Действительно, очень проблемно/сложно через java-жoпy что-либо делать DPDK-автогеном :)
> И не особенно-то это и просто покажется, если на минутку заглянуть в ядерный код.
Не нужно, в случае DPDK он не участвует в обработке потока данных.
> насколько у авторов тазы банных получилось хорошо и тем более - надежно - вопрос, требующий отдельного изучения.
нет, это "не вопрос" - работает, давно, и многократно быстрее.
Очень хороший горчичник и butthurt-индикатор для жабистов :)
Вот прям приятно.
>> И не особенно-то это и просто покажется, если на минутку заглянуть в ядерный код.
> Не нужно, в случае DPDK он не участвует в обработке потока данных.я и говорю - ты весь этот код (ну, во всяком случае, изрядную его часть) будешь переписывать - или, что более вероятно, оно будет работать только в локальной сеточке у разработчика, и на соседнем столе в лаборатории - а в других сетапах как-то иногда)
> нет, это "не вопрос" - работает, давно, и многократно быстрее.
есть у меня подозрение, что это не из-за привязки к cpu и обработки tcp в волшебной сиплюсплюсичке, а вопреки этому.
ну просто потому что трудно поверить универсального спеца по базам данных, умеющего low level tcp - причем хорошо, а не абы как.
Обычно это сильно разные ребята.
>>> И не особенно-то это и просто покажется, если на минутку заглянуть в ядерный код.
>> Не нужно, в случае DPDK он не участвует в обработке потока данных.
> я и говорю - ты весь этот код (ну, во всяком случае,
> изрядную его часть) будешь переписывать - или, что более вероятно, оно
> будет работать только в локальной сеточке у разработчика, и на соседнем
> столе в лаборатории - а в других сетапах как-то иногда)Ну переписывать я точно не буду, разве-что поправлю при необходимости, ибо чуток участвовал.
Но начинать надо с RTFM, т.е. с понимания, что оно умеет и как работает в тех или иных случаях.
Если уж совсем кратко, то http://seastar.io/networking/ позволяет выбрать между ядерным TCP и собственным упрощенным TCP-стеком (который дружит и с DPDK и с Virtio).
//offtopic: Но в отличии моего 1Hippeus (сейчас заброшенного) не умеет эффективных очередей в разделяемой памяти (в пределах физического сервера, сквозь все слои виртуализации).Поэтому в теплично-контролируемых условиях одного датацентра, одной стойки с серверами или внутри одного VM-хоста, можно подключаться к ScyllaDB через DPDK и упрощенный TCP без участия ядра), а в остальных случаях через штатный TCP (со всеми фичами и плюшками).
Грубо говоря, ничего не отнимается, а только добавляется.
>> нет, это "не вопрос" - работает, давно, и многократно быстрее.
> есть у меня подозрение, что это не из-за привязки к cpu и
> обработки tcp в волшебной сиплюсплюсичке, а вопреки этому.А земля плоская?
Если серьезно, то благодаря, но далеко не только этому.
Главный тезис - просто не делать лишнего, т.е. избавить машину от ненужных фрикций.> ну просто потому что трудно поверить универсального спеца по базам данных, умеющего
> low level tcp - причем хорошо, а не абы как.
> Обычно это сильно разные ребята.Но не всегда ;)
> Обычно это сильно разные ребята.Движек БД пишут ребята которые как раз понимают low level. Иначе за это и браться не стоит.
>> Обычно это сильно разные ребята.
> Движек БД пишут ребята которые как раз понимают low level. Иначе за
> это и браться не стоит.Движок Сциллы пишет команда которая, помимо прочего, написала OSv и KVM
да, я глянул - впечатлился. Причем команда огромная, не полтора гика, такие и впрямь напишут работающее.Потом их, конечно, купит IBM, но мы успеем порадоваться счастью.
>Я всегда думал что только из пространства ядра можно напрямую с периферией работать, в этом и есть одна из основных задач ядра.Это не то, что вы подумали, это использование SOCK_RAW. Получение через него фреймов Ethernet, а дальше разгребание заголовков уровней в пространстве процесса.
> Например, 4-узловой кластер на базе Scylla вполне справляется с нагрузкой для которой потребовалось бы развернуть 40-узловой кластер на базе Cassandra.
> Промышленные решения на базе Cassandra, хранящие сотни терабайт данных, охватывающие сотни серверов и способные обрабатывать тысячи запросов в секунду, развернуты для обеспечения сервисов таких компаний и организаций, как Adobe, CERN, Cisco, IBM, HP, Comcast, Disney, eBay, Netflix, Sony, Rackspace, Reddit и Twitter.Это вы хотите сказать, что эти компании заигрывая с модными Java-решениями мешки с деньгами всё это время в датацентрах сжигали? И отвечать за это бы надо? Да не, бред какой-то!
Эти компании увеличивали капитализацию и цену акций. За счёт потребителя, разумеется.
Эти решения более обкатаны, а риски некоторых видов багов в них действительно ниже (для отдельных багов близко к нулю).
Поэтому их проще использовать и продавать как сервис, и тут не важно что (на самом деле) они жрут в разы больше ресурсов.В целом, IMHO, дуэль Scylla vs Cassandra очень хорошо показывает соотношение возможностей С++ и Java.
> Seastar учитывает особенности современного оборудования, таких как распараллеливание на многоядерных системах, учёт попадания данных в процессорный кэшДело не в платформе, а в дружбе с железом. Лондонская биржа отлично на Java работает (11 млн заявок в секунду на одном ядре). Просто дружат с железом. кучу наград имеют.
https://martinfowler.com/articles/lmax.html
https://en.wikipedia.org/wiki/LMAX_Exchange
>> 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++ - тогда всё становится на свои места.
Кольцевые буферы - это малая часть. Кстати, все наработки в открытом доступе.
https://www.baeldung.com/lmax-disruptor-concurrencyВ счётчиках они боролись с false sharing и сделали выравнивание на 64 байта. Потом этот приём в Java вошел.
Может оно и имеет низкие задержки, но наверняка под капотом и в ходе эксплуатации выяснится, что ОЗУ надо в разы больше, что надо "греть" кеш, что периодически всё подтупливает на сборке мусора и и протухании кеша, что валится оно целиком при фаталити в треде и т.д. всё то, что присуще jvm-based серверам.
Как и сказано ранее: Cassandra vs Scylla отличный горчичник.
> Может оно и имеет низкие задержки, но наверняка под капотом и в
> ходе эксплуатации выяснится, что ОЗУ надо в разы больше, что
> надо "греть" кеш, что периодически всё подтупливает на сборке мусора и
> и протухании кеша, что валится оно целиком при фаталити в треде
> и т.д. всё то, что присуще jvm-based серверам.
> Как и сказано ранее: Cassandra vs Scylla отличный горчичник.Kэш греть надо везде, кроме баз которые заведомо в памяти сидят. В 3.0 в Сцилле добавили такую фичу, и таблицы можно грузить в память заранее: https://docs.scylladb.com/using-scylla/in-memory/
> Kэш греть надо везде, кроме баз которые заведомо в памяти сидят.Нет. Греть его надо только когда оно действительно нужно. Обычно, на больших наборах, часто запрашиваемых, не активно изменяемых данных. В большинстве СУБД кеш заполняется по требованию.
Фокус в том что, в jvm прогрев кеша, нужен почти всегда, вне зависимости от применения jvm, иначе о сопоставимой производительности с C++ программами и речи быть не может. Тупо даже IDE'шки на jvm начинают нормально, без лагов и фризов работать, только если дать им значительное время на прогрев, потыкав в менюшки, пооткрывав настройки и т.п.
> В 3.0 в Сцилле добавили такую фичу, и таблицы можно грузить в
> память заранее: https://docs.scylladb.com/using-scylla/in-memory/Спасибо, я тоже активно наблюдаю за развитием scylladb, готовлюсь к её внедрению.
> Нет. Греть его надо только когда оно действительно нужно. Обычно, на больших
> наборах, часто запрашиваемых, не активно изменяемых данных. В большинстве СУБД кеш
> заполняется по требованию.Само собой, просто я говорил что в Сцилле нет никакой магии которая отменила бы надобность в прогреве кэша в как раз таком случае.
> Спасибо, я тоже активно наблюдаю за развитием scylladb, готовлюсь к её внедрению.Отлично, будут вопросы - велкам к нам в слак, мы всегда рады помочь новым пользователям
Ну так они работали на том, что позволяло работать, и, вполне возможно, убедившись в работоспособности устоявшегося решения, некоторые из них, решили доплатить за отливку в C++
Всё правильно сделали?
Как раз этот Seastar вроде хотят Ceph-еры себе на борт взять... правда хотят давно, а втащить пока не втащили, ну и код там получается в духе как в ноде на промисах - async/await на стороне языка-то нет
вроде как уже тащат, на Scylla Summit 2018 заявляли официально, показывали наработки
> вроде как уже тащат, на Scylla Summit 2018 заявляли официально, показывали наработкиОчень нужный шаг, тоже жду когда запилят. По идее это должно поднять Ceph выше ScaleIO, который прикарманила Dell.
>переписанный с Java на C++ и демонстрирующий существенное увеличение производительности. Код проекта распространяется под лицензией AGPLv3Ну уважуха же разработчикам.
Java тормозит? Да не, не может быть! Не верю! 😀
Я что-то не понял откуда эти ребята внезапно появились. Кто у них спонсор? На чём хотят зарабатывать?
https://www.scylladb.com/company/раздел Investors
>Java тормозит? Да не, не может быть! Не верю!Ну в статье буквами помельче написано, что реально в пару-тройку раз быстрее.
Главный вопрос: а вне AWS оно работает? AWS и прочие облака это несусветно дорого.
Ну и Кассандру уже обкатали за столько лет, а си это гарантия медленной разработки и большего количества багов. Бизнесу выгоднее сидеть на лидере, пусть и переплачивая за железо. Увы и ах, когда же это наконец поймут борцуны с жабой?
Отлично работает на железе и других платформах
> Бизнесу выгоднее сидеть на лидере, пусть и переплачивая за железо.ага, а кто только что ныл "AWS дорого"? Намек - "в пару тройку раз быстрее" в переносе на AWS - "в пару-тройку раз дешевле".
А за железо хорошо было переплачивать до осени 2008го, когда деньги были бесконечны. Сейчас, с учетом того, сколько надо платить за его обслуживание, электричество, место в стойках, стаю обезьян обслуживающих те стойки и системы в них, с учетом резервирования, в том числе географически разнесенного - что-то косо смотрят на идеи "давайте жрать втрое больше ресурсов".
Смотри как бы тебе в КПИ не воткнули "не меньше 15% экономии" каждый год, не выполнишь - сиди без премии.
Эй, жирный тролляка, причем здесь ява, если основная причина выигрыша - в архитектурных ухищрениях? Ну там всякие работа напрямую с очередью пакетов сетки из юзерспейса (меньше переключений контекста), оптимизации под SSD, архитектура shared-nothing (отсутствие необходимости блокировок и синхронизации доступа для конкурирущих обработчиков), новый формат хранения данных, "требующий для хранения до 66% меньше места в хранилище по сравнению со старым форматом" (ну то есть и с диска данных можно меньше читать). Архитектура и архитектурные ухищрения обычно больше дают профитов, чем выбор языка программирования (если не обращать внимание на такое важное богатство, как багаж библиотек ). Ну то есть, на пальцах, для самых маленьких - ты можешь написать алгоритм пузырьковой сортировки на своих C++ и алгоритм быстрой сортировки на тормозной яве, а потом удивляться, что это твои плюсы сливаются.
> основная причина выигрыша - в архитектурных ухищрениях? Ну там всякие работа напрямую с очередью пакетов сетки из юзерспейса (меньше переключений контекста), оптимизации под SSD, архитектура shared-nothing
> (отсутствие необходимости блокировок и синхронизации доступа для конкурирущих обработчиков),
> новый формат хранения данных, "требующий для хранения до 66% меньше места
> в хранилище по сравнению со старым форматом" (ну то есть и
> с диска данных можно меньше читать).Т.е. все дело в тех вещах, которые жабисты традиционно считают ненужным пережитком прошлого - ведь есть "write once, run everywhere!" и на которые забивают?
Или то-то с ножом у горла не давал использовать более эффективные решения?
> Т.е. все дело в тех вещах, которые жабисты традиционно считают ненужным пережитком прошлого - ведь есть "write once, run everywhere!" и на которые забивают?
> Или то-то с ножом у горла не давал использовать более эффективные решения?И да и нет.
1. По некоторым направлениям развитие Cassandra остановилась.
Например, уплотнение формата на диске.
И многое другое, что может быть отнесено к "нижнему слою", что не все жабисты понимают и чем не хотят заниматься.
Соответствующие изменения очень сложно протащить в mainstream - часто нужно "немножко" поправить какой-нибудь десяток интерфейсов в иерархии классов, предварительно объяснив всем недопонимающим зачем это нужно...2. Далее. Архитектурный тезис share nothing может быть реализован в java, но требует (как правило) некоторой борьбы с самой идеей java и кардинальной переделке кода.
Грубо говоря, меняется весь путь обработки данных/событий, плюс так или иначе нейтрализуется сборка мусора (пулы объектов с привязкой к нативным тредам и NUMA).
Это примерно ад для уже сделанной большой системы, коей является Cassandra.
Другими словами, чтобы получить здесь выигрыш нужно примерно "всё _переписать_" по образцу упомянутого выше LMAX.3. Последнее. Всяческие низкоуровневые оптимизации (например рациональное размещение полей в структурах, локальность данных для кэширования) примерно не совместимы со стилем/традициями java. Используя фабрики фабрик, инроспекцию, рефлексию, примеси и т.п. вы получаете удобства и мощь высокоуровневых фишек, но теряете контроль над тем что делает машина "на самом деле".
Такой контроль можно вернуть, но для этого нужно писать не в стиле java, а условно на "голых массивах" (как LMAX), ещё и понимать как надо для достижения производительности.Вот и получаем, что Cassandra нужно примерно переписать в новый продукт, с новыми багами...
Поэтому никогда не догонит ScillaDB, но и не нужно этого делать - ибо тогда Cassandra превратиться в "неуловимого Джо" :)IMHO, в целом засовывать java-пальцы в high-performance розетку неудобно и дорого, а часто и больно и бесполезно.
Причем LMAX это только подтверждает, если заглянуть в его код и/или попросить условного среднего жаба-сеньера что-нибудь там существенно подкрутить.
Люто плюсую!
>Например, уплотнение формата на диске."Storage is the cheapest resource now" как-то так.
>share nothing может быть реализован в java, но требует
щито? ты вообще в курсе, что есть shared-nothing? Это архитектура узлов. Причём тут java не java?
The Cassandra database is a shared-nothing architecture, as it has no central controller and no notion of master/slave
>IMHO, в целом засовывать java-пальцы в high-performance розетку неудобно и дорого, а часто и больно и бесполезно.
Теоретик-кукаретик? В реале кроме жабки в highload особо никого нет.
Ну, перепутал человек термины share nothing с zero copy. Зачем же его так сразу?
>перепутал человек терминыЧувак перепутал всё, вклучая бредовые выводы, что жабы в хайлоаде нет
> "Storage is the cheapest resource now" как-то так.Причем тут относительная стоимость?
Scylla генерирует меньше данных на дисках, вне зависимости от прочего это означает:
- вдвое меньше оборудования и площадей (вдвое дешевле).
- вдвое меньше электроэнергии и охлаждения (вдвое дешевле).
- вдвое меньше IOPS, вдвое меньше объемов прокачки через шину/SAN и т.п.
- вдвое большое отдачи от кэша внутри дисков и/или контроллера.
- вдвое эффективнее кеширование файлов в памяти.
- вдвое меньше вымывание кэша CPU.Короче, заявленный "аргумент" хорошо демонстрирует понимание жавистов.
> щито? ты вообще в курсе, что есть shared-nothing? Это архитектура узлов. Причём тут java не java?
Как я понимаю вы на википедию ориентируетесь )
У этого термина несколько значений, в том числе http://seastar.io/shared-nothing/
Короче, RTFM c поминками по java.>В реале кроме жабки в highload особо никого нет.
Гора рожающая мышей )
Термин highload загажен, увы, также как и одноименная конференция превратилась в Хайплоад.
Сейчас highload != эффективность.
Греть процессор можно на любом языке, а на java это можно делать еще и с умным видом.
> Scylla генерирует меньше данных на дисках, вне зависимости от прочего это означает:Scylla генерирует ровно столько же данных на диске. Она полностью совместима с SSTables ka/la/mc
> - вдвое меньше оборудования и площадей (вдвое дешевле).
> - вдвое меньше электроэнергии и охлаждения (вдвое дешевле).
> - вдвое меньше IOPS, вдвое меньше объемов прокачки через шину/SAN и
> т.п.
> - вдвое большое отдачи от кэша внутри дисков и/или контроллера.
> - вдвое эффективнее кеширование файлов в памяти.
> - вдвое меньше вымывание кэша CPU.A вот это вполне себе точно. Недавно заменял кластер из 150 кассандр на 19 нод Сциллы, экономия, помимо железа, еще и на админах - их тоже надо меньше, когда парк серверов уменьшается
>Недавно заменял кластер из 150 кассандр на 19 нод Сциллы, экономия, помимо железа, еще и на админахНу, это глупости. Если это единый кластер, то разницы для админа сколько нод нет ВООБЩЕ.
Плюс, у каждой системы свой градус упртости. Я лучше буду обслуживать 100 Монго, чем 1 Oracle.
Постгрес штук 20. итд итп. То, что Сцилла якобы drop in replacement не значит, что там нет своих тараканов.p.s. вы уж, господа, втюхиватели, определитесь, то у вас в два раза меньше нод надо, то чуть ли не в 10. Кто больше? :)
> Ну, это глупости. Если это единый кластер, то разницы для админа сколько
> нод нет ВООБЩЕ.
> Плюс, у каждой системы свой градус упртости. Я лучше буду обслуживать 100
> Монго, чем 1 Oracle.
> Постгрес штук 20. итд итп. То, что Сцилла якобы drop in replacement
> не значит, что там нет своих тараканов.
> p.s. вы уж, господа, втюхиватели, определитесь, то у вас в два раза
> меньше нод надо, то чуть ли не в 10. Кто больше?
> :)Какой смешной жабист. Мне не надо ничего доказывать, достаточно просто посмотреть на интервью с клиентами Сциллы, они сами все рассказывают как есть. И втюхивать ничего не надо, особенно "лютому жабисту", он ведь такой лютый и невтюхабельный :)
>Какой смешной жабист. Мне не надо ничего доказывать,В качестве ответной любезности, скажу, что на одного такого втюхивателя Сциллы (судя по твоим словам ты поставил и свалил, а штатным одминам потом разгребать) всегда будет 100500 инсталляций Кассандры. Ну по крайней мере в ближайшие лет 5-10. Патамучта "vendor reputation, community et c matters"
Ну и жабка никуда не денется ещё долго, что бы там всякие любители Тарантасов не воображали себе ;)
>>Какой смешной жабист. Мне не надо ничего доказывать,
> В качестве ответной любезности, скажу, что на одного такого втюхивателя Сциллы (судя
> по твоим словам ты поставил и свалил,Смешной жабист еще и гадает по юзерпикам? Нет, не свалил.
> а штатным одминам потом разгребать)
Штатные админы идут ко мне если что, так что в моих интересах сделать так чтоб все работало стабильно. Ты споришь на пустом месте, просто не зная о чем говоришь.
> всегда будет 100500 инсталляций Кассандры. Ну по крайней мере в
> ближайшие лет 5-10. Патамучта "vendor reputation, community etc matters"Да пусть будет. Кассандра для Сциллы - как Центос для RHEL. Народ начинает проекты с мелочи, растет, упирается в проблемы кассандры, им надоедает мудохаться с тюнингом JVM и появляется Сцилла.
> Ну и жабка никуда не денется ещё долго, что бы там всякие
> любители Тарантасов не воображали себе ;)У меня нет проблем с жабкой, пусть себе живет.
>Кассандра для Сциллы - как Центос для RHEL.Народ начинает проекты с мелочи, растет, упирается в проблемы кассандрыТолько наоборот, нщеброды берут Сциллу, т.к. огого железа надо в 10 раз меньше.
>У меня нет проблем с жабкой
заметно
> Только наоборот, нщеброды берут Сциллу, т.к. огого железа надо в 10 раз
> меньше.Ладно, я расскажу корпорации из fortune 100 какие они нщеброды :)
>The Fortune 100 list does not include foreign companies, though many of the listed companies have >significant international operations. The Fortune 100 in 1955 was led by General Motors, a company >that held the top position for over 30 years. General Motors had revenues of $9.8 billion to top >the list. The remaining top 10 was rounded out by Exxon, US Steel, General Electric, Esmark, >Chrysler, Armour, Gulf Oil, Mobil and DuPont.Втюхиватели Сцыллы даже наврать убедительно не могут....
>>The Fortune 100 list does not include foreign companies, though many of the listed companies have >significant international operations. The Fortune 100 in 1955 was led by General Motors, a company >that held the top position for over 30 years. General Motors had revenues of $9.8 billion to top >the list. The remaining top 10 was rounded out by Exxon, US Steel, General Electric, Esmark, >Chrysler, Armour, Gulf Oil, Mobil and DuPont.
> Втюхиватели Сцыллы даже наврать убедительно не могут....И где вранье? Я и без цитат из википедии знаю что такое fortune 100
>Я и без цитат из википедии знаю что такое fortune 100Видимо, не знаешь. Переведу тебе, не благодари: fortune 100 это список жирных _пиндосских_ компашек, далеких от ИТ. Привет там Трампу передавай и СЕО General Electric! Расскажи им, что жаба не есть гуд, им это очень интересно.
> Видимо, не знаешь. Переведу тебе, не благодари: fortune 100 это список жирных
> _пиндосских_ компашек, далеких от ИТ. Привет там Трампу передавай и СЕО
> General Electric! Расскажи им, что жаба не есть гуд, им это
> очень интересно.Очень интересно, с чего ты взял что хоть одна из фирм fortune 100 не имеет своего IT? Кстати, General Electric как раз использует Сциллу, и в офигенных объемах. Пруф: https://www.youtube.com/watch?v=7o4W06xAMdU
Ты скатываешься в совсем уж унылый троллинг, придумай что нибудь поинтереснее.
>интересно, с чего ты взял что хоть одна из фирм fortune 100 не имеет своего ITИнтересно, с чего ты взял, что "далеких от ИТ" означает "не имеет своего IT".
Сей невнятный индус с видюшки на должности ИТ директора GE подтверждает мое мнение, что ИТ там либо на аутсорсе, либо в плачевном состоянии с минимальными бюджетами. В ИТ компаниях компетенции повыше и там почему-то от жабы никто не бежит, смотри хотя бы соседнюю новость про хадуп. Сама GE может быть жирной компанией, а ИТ у них при этом может быть в положении бедного родственника.
> Сей невнятный индус с видюшки на должности ИТ директора GE подтверждает мое
> мнение, что ИТ там либо на аутсорсе, либо в плачевном состоянии
> с минимальными бюджетами.Ты не только лютый жабист но еще и лютый расист, да? Чем тебе индусы не угодили? CEO Microsoft тоже индус, или ты думаешь что и его аутсорсят?
> В ИТ компаниях компетенции повыше и там почему-то
> от жабы никто не бежит, смотри хотя бы соседнюю новость про
> хадуп. Сама GE может быть жирной компанией, а ИТ у них
> при этом может быть в положении бедного родственника.GE мониторит самую большую в мире сеть IoT, миллионы сенсоров постоянно пишуших в базу. Может быть они не чисто софтовая контора, но в ИТ есть более чем одно направление, и если ты этого не можешь понять то тебе надо идти доделывать уроки.
Я не говорил что надо бежать от жабы, я говорил что не надо ее использовать под такими нагрузками. Для высокоуровневых языков есть свою ниша, и движок для базы данных - не она.
Кстати, сии индусы пишут что Кассандра крутилась на 75 нодах i3.2xl , Сциллу перенесли в 15 i3.8xlСмотрим:
i3.2xl это 8core 61GB RAM
i3.8xl это 32core 244GB RAMвпариватели сцыллы ну такие впариватели...
сухой остаток на следующем слайде: reduced cluster footprint by 60%
> сухой остаток на следующем слайде: reduced cluster footprint by 60%ух ты, ты уже выучил арифметику!
теперь покажи мне хоть одного директора ИТ который не будет рад сократить расходы на железо у его обслуживание на 60%.
Если ты хочешь увидеть сравнение с показанными 1000% разницы, то они есть на сайт Сциллы. Никакого вранья, все воспроизводимо, как воспроизвести четко указано.
Но если бы ты хотя бы немного разбирался в вопросе, ты бы знал что точные результаты зависят от нагрузки, и подобранные, абсолютно честные 10х в демке не означают гарантированные 10х в 100% реальных случаев. Где-то будет лучше, где-то хуже.Даже в самом не оптимальном случае, Сцилла в разы лучше справляется с нагрузкой, просто потому что она написана на языке позволяющем максимально приблизить ее к железу, без лишнего оверхеда. GE это кстати показали - переехали на более мощные инстансы и не потеряли при этом производительность. Кассандра не способна масштабироваться линейно при увеличении железных ресурсов, как и любая другая поделка зависящая от JVM. A Сцилле дашь больше памяти и процессоров - она станет еще быстрее. И чем мощнее железо тем мощнее база.
>теперь покажи мне хоть одного директора ИТ который не будет рад сократить расходы на железо у его обслуживание на 60%.Ну, примерно 100% ИТ-директоров, у которых сейчас крутится Кассандра. :)))
У тебя неправильные представления о приоритетах ИТ-директора.
Этот индус мог бы выкинуть AWS и получить ещё 60% удешевления.
В целом, ИТ директора и даже члены СД очень часто делают абсолютно тупейшие оптимизации, которые потом долго аукаются или даже приводят к "конторокапец".>И чем мощнее железо тем мощнее база.
Да, да, знаю, си не течёт. И мусор собирать не надо, надо просто раз в день ноду перезапускать. systemd в помощь :))) Знаю много ПОПУЛЯРНЫХ поделок на си (навроде редиса), которые вообще не масштабируются. Так же полно прожек на жабке, которые спокойно работают с кучами 32++ГБ.
Итого, Сцилла это достаточно иллюзорный буст за вполне неиллюзорный риск, связанный с тем, что это небезопасный язык.
> Ну, примерно 100% ИТ-директоров, у которых сейчас крутится Кассандра. :)))начинаем друг друга понимать, это хорошо :)
> У тебя неправильные представления о приоритетах ИТ-директора.
> Этот индус мог бы выкинуть AWS и получить ещё 60% удешевления.Не факт, содержание собственного парка железа, тем более такого же как эти i3, не дешевое удовольствие.
> В целом, ИТ директора и даже члены СД очень часто делают абсолютно
> тупейшие оптимизации, которые потом долго аукаются или даже приводят к "конторокапец".окей, я даже уверен что ты сможешь найти примеры (я тоже смогу). Означает ли это что в данном случае он сделал тупой выбор? Очень сомневаюсь, так как знаком с внутренней кухней этой фирмы.
> Да, да, знаю, си не течёт. И мусор собирать не надо, надо
> просто раз в день ноду перезапускать. systemd в помощь :))) Знаю
> много ПОПУЛЯРНЫХ поделок на си (навроде редиса), которые вообще не масштабируются.
> Так же полно прожек на жабке, которые спокойно работают с кучами
> 32++ГБ.Хех, в этом вся прелесть Сциллы - они взяли очень хороший дизайн базы (Кассандра на самом деле близка к идеалу для своего юз кейса) и написали этот же продукт. Плюс несколько оптимизаций которые Кассандра наверное попытается догнать в четвертой версии (shard per core и вот это все).
> Итого, Сцилла это достаточно иллюзорный буст за вполне неиллюзорный риск, связанный с
> тем, что это небезопасный язык.Ускорение и сокращение парка серверов в РАЗЫ это иллюзорно?
>теперь покажи мне хоть одного директора ИТ который не будет рад сократить расходы на железо у его обслуживание на 60%Кстати, кто гарантирует, что этому индусу изначально не втюхивали ваше "Сцилла В РАЗЫ лучше справляется с нагрузкой"?
Любые миграции и телодвижения стоят денег. Даже drop-in replacement надо "развернуть рядом" и некоторое время погонять одновременно. Потом сравнивать результаты. Всё это не бесплатно.
А потом бац - в сухом остатке "reduced cluster footprint by 60%".
Возможно вообще тут больше стоимость саппорта влияет, а не затраты на кластер.
И что там будет дальше? Если вылезет какая фатальная проблема? Прокукарекать об успехе можно громко, а сваливают обычно молча.
> Кстати, кто гарантирует, что этому индусу изначально не втюхивали ваше "Сцилла В
> РАЗЫ лучше справляется с нагрузкой"?У него были все возможности все проверить и принять решение. Думаю у директора ИТ в такой фирме есть все возможности и ресурсы для того чтоб принять верное решение.
> Любые миграции и телодвижения стоят денег. Даже drop-in replacement надо "развернуть рядом"
> и некоторое время погонять одновременно. Потом сравнивать результаты. Всё это не
> бесплатно.
> А потом бац - в сухом остатке "reduced cluster footprint by 60%".В сухом остатке - более чем в два раза меньше хостов, масштабирование которое намного легче, и нормальная поддержка продукта (саппорт DSE знаменит тем насколько там все плохо). Тебе это кажется ничем?
> Возможно вообще тут больше стоимость саппорта влияет, а не затраты на кластер.
>
> И что там будет дальше? Если вылезет какая фатальная проблема? Прокукарекать об
> успехе можно громко, а сваливают обычно молча.Кластер уже давно в рабочем режиме под массивной нагрузкой. Если будут проблемы - с ними справятся. Думаешь с Кассандрой проблем не было и не бывает?
>В сухом остатке - более чем в два раза меньше хостов, масштабирование которое намного легчеок, поборол лень, зашёл на aws.
75 x i3.2xl $18270 в месяц
15 x i3.8xl $27406 в месяцне вижу смысла обсуждать с тобой сию шарашкину контору GE.
>>В сухом остатке - более чем в два раза меньше хостов, масштабирование которое намного легче
> ок, поборол лень, зашёл на aws.
> 75 x i3.2xl $18270 в месяц
> 15 x i3.8xl $27406 в месяц
> не вижу смысла обсуждать с тобой сию шарашкину контору GE.Ты бы невежество свое поборол. 75 i3.2xl стоит 34257.75 в месяц
>Ты бы невежество свое поборол.Вообще-то, я в первую очередь показываю на порядок цен. 30килобаксов в месяц это зарплата пары негров в штатах. И сомневаюсь, что GE покупали 75 инстансов on demand.
Ну и 34k vs 27k как 60% выхлопа получили?
Где ваши "в разы рвёт", клованы?
> > Scylla генерирует меньше данных на дисках, вне зависимости от прочего это означает:
> Scylla генерирует ровно столько же данных на диске. Она полностью совместима с SSTables ka/la/mcВиноват. У меня наложилась/смешалась разница между SST 2.0/3.0 и локальные собственные экспериментальные доработки у знакомого.
> "Storage is the cheapest resource now" как-то так.Slow storage is the cheapest resource now
//fixed.
NVMe которые реально ускоряют базу (те же i3 на амазоне например) стоят очень немалых денег
> Т.е. все дело в тех вещах, которые жабисты традиционно считают ненужным пережитком прошлогоЕще раз, для не понявших. Дело не в жабистах. Дело в программистах на любых языках, которые не понимают, что важнее структура данных/алгоритмы/архитектура проектируемой системы/выбор вычислительной платформы, чем выбранный ими язык программирования (кроме клинических случаев выбора самых неадекватных (брэйнфак-like) языков, к которым ява не относится). И да, жабисты, как и программисты на других языках, тоже в широком спектре делятся на умных и не очень, которые забивают на важные вещи.
Хотет!Есть кластер Кассандр, есть некоторые затыки производительности, очень интересно взглянуть, как оно ведет себя под нагрузкой в 100K обращений.
100к это мелочь. Заходи в слак, там помогут
:))) 100k можно в 1 instance Mongo лить... полагаю, что с такими рученьками как у вас, и сцылла не поможет.