Scylladb что это

Укрощение мифического чудовища: реальный опыт промышленного использования ScyllaDB без прикрас

CassandraDB – она же просто Кассандра – хорошо зарекомендовала себя в нише высокопроизводительных NoSQL баз данных. Но вот её активно стала вытеснять ещё более быстрая, надежная и легко масштабируемая ScyllaDB — этакая Кассандра++. Как тут удержаться и не проверить, так ли прекрасна эта зверушка, как про неё говорят её создатели? Тем более вендоры других популярных баз данных того и гляди закроют поддержку для российских пользователей. Нужно иметь под рукой пару-тройку запасных вариантов. Сегодня мы рассмотрим, как одноглазый монстрик приживается в диких условиях кровавого энтерпрайза, и насколько целесообразно его использовать.

Об этом расскажет Илья Орлов, техлид компании STM Labs. Вместе с командой он разрабатывает высоконагруженные решения для всевозможных задач: бизнес-порталов с использованием собственной платформы, мониторинга фискальных данных и прочее. Они любят экспериментировать с разными БД, поэтому статья будет об использовании ScyllaDB на промышленных мощностях.

Зачем нужна другая СУБД?

Представим крупную трек&трейс систему, отслеживающую судьбу каждой единицы товара от момента регистрации до продажи конечному пользователю. В качестве оперативного хранилища была выбрана MongoDB. Объём информации в ней рос неумолимо и стремительно, потому что нельзя было просто так взять и удалить товар из системы, даже если он завершил свой жизненный цикл.

Почему? Да по той же причине, по которой не выкидывается гора ненужных бумажек. Стоит что-то выбросить, как мы тут же с болью осознаём, что там же, к примеру, был гарантийный талон от внезапно сломавшейся посудомойки. Это всё данные, вероятность обращения к которым близка, но не равна нулю. Удалять их нельзя, но и загромождать ими оперативные хранилища — непозволительная роскошь.

Такие данные можно отправлять в архив.

Требования к архиву существенно мягче, чем к основному хранилищу. Читают оттуда, как правило, редко. Скорость записи должна быть сопоставима со скоростью перехода товаров в конечное состояние, то есть 3-4 мегабайта в секунду вполне достаточно. Главное, чтобы данные хранились максимально компактно.

Это и стало хорошим поводом для Ильи и его команды опробовать альтернативную СУБД, чтобы, как гласит народная мудрость, не класть все яйца в одну Mongo. Рассмотрев несколько подходящих СУБД, они наткнулись на ScyllaDB.

Почему ScyllaDB?

Заявленная производительность ScyllaDB (или просто Сциллы) — 12 500 запросов в секунду на физическое ядро. Учитывая, что один запрос предполагает payload в 1 килобайт, на 32-ядерном сервере система получит RPS 400 000, что равно примерно 400 мегабайт в секунду. Понятно, что это как с заявленным расходом бензина у автомобиля в автосалоне. Но у команды, привыкшей к RPS в 40 000, такие цифры вызывали, если не уважение, то профессиональный интерес. Тем более было разумное обоснование такой производительности — реализация на С++.

И хотя на плюсах можно реализовать так, что получится усердный бобер, команда была настроена оптимистично, так как о Сцилле было множество восторженных отзывов (на официальном сайте), причём от известных, в том числе отечественных компаний. В одном из таких отзывов рассказывалось о возможности деплоя Сциллы на HDD-дисках с RPS записи 240 000, а не SDD, как указано в официальной рекомендации. Такой эконом-вариант.

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

И, наконец, у этого монстрика есть открытое сообщество и поддержка в Slack.

Богатый внутренний мир ScyllaDB

ScyllaDB — это колоночная СУБД с собственным алгоритмом утилизации памяти и CPU, на который, как оказалось, повлиять извне особо нельзя, в отличие от Кассандры. Дело в том, что Сцилла рассматривает весь кластер подключённых серверов, как общую совокупность доступных процессорных ядер и распределяет данные именно между ядрами. То есть одно ядро — один шард.

Это позволяет для каждого сервера обеспечить нагрузку, сопоставимую с его мощностью. Конечно, ни о каком ручном перераспределении потоков между задачами речь не идёт. Сцилла, как коробка-автомат, всё знает за вас.

Инфраструктура

Определившись с СУБД, Илья с командой стали готовить инфраструктуру. Развернули кейспейс — логическое объединение данных — в кластере из пяти 32-ядерных серверов, каждый из которых имеет оперативную память в 312 гигабайт. Затем установили фактор репликации 3 и решили начать с эконом-варианта: выбрали HDD диски, а не SSD. Ведь, если что, в любой момент можно переехать на SSD, думали они. Сцилла же легко позволяет добавлять новые мощности на горячую.

Схема данных

Схема данных, которую разработчики планировали архивировать, идеально ложилась на концепцию key-key-value, обозначенную в официальной документации Сциллы в качестве образцовой. Иными словами, словарь словарей. Выглядела эта схема следующий образом:

Первичным ключом записи и по совместительству ключом партиции стал product_id — уникальный идентификатор продукта. По этому ключу располагался набор атрибутов, описывающих состояние продукта на момент его выхода из оборота. Получалась такая таблица – products.

На неключевые поля exec_date — типа дата, owner — типа строка, сразу повесили индексы. Мало ли, вдруг потом по ним придётся поиск выполнять. Лучше уж сразу проиндексировать, чем потом по миллиардам записей с нуля индексы строить.

Алгоритм архивации

Команда решила архивировать в три этапа:

1. Копирование из основного хранилища в архив;

1. Валидация, проверка того, что ранее продукты были скопированы;

1. Удаление из основного хранилища.

Операция удаления сильно тормозила основное хранилище, поэтому выполнять её можно было только в периоды наименьшей нагрузки на систему. Валидацию разработчики добавили, руководствуясь правилом «Доверяй, но проверяй», и ведь, как в воду глядели, пригодился этот этап.

Проблемы

Прежде чем выкатывать решение в прод, разработчики провели множество тестов. В частности, нагрузочное тестирование с использованием стандартной кассандровской утилиты — cassandra-stress-test.

Оно показало, что данные в Сциллу лучше отправлять пачками. Отправили запись размером 10 килобайт и получили производительность 5 000 запросов в секунду, то есть примерно 45 мегабайт в секунду. Это не 400 и даже не 240 мегабайт, но всё равно более чем достаточно для выкатки в прод.

Если бы архивация на production-сервере проходила с такой же скоростью, как в cassandra-stress-test, то получалось бы 400 миллионов записей в сутки. На деле же скорость одного только копирования составила 138 миллионов. А с учётом последующих этапов получалось вообще 20 миллионов записей в сутки. Это меньше скорости перехода товаров в конечное состояние, их выхода из оборота. Разработчики думали, что скорость получится увеличить, отказавшись от этапа валидации, когда система стабилизируется. Но не тут-то было: когда размер архива перевалил за терабайт, всё пошло… совсем не туда:

→ Более 50% операций записи стали завершаться по таймауту.

Во-первых, более 50% операций записи в Сциллу стали завершаться по таймауту. Сцилла не успевала ни записать, ни переварить отправленные в неё данные. Из-за этого скорость копирования деградировала более чем в 5 раз: со 138 до 26 миллионов записей в сутки.

→ Падала скорость копирования, валидации (чтения) и архивации в целом (до 3 млн. записей в сутки).

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

→ Автокомпактификация занимала до 100% CPU и оказалась неуправляемой.

В-третьих, Сцилла, как и многие другие NoSQL СУБД, реализует компактификацию данных. И компактификация эта занимала до 100% ресурсов Сциллы. Разработчики думали вмешаться и ограничить количество потоков под эту операцию, но сделать это оказалось нельзя. Пока чудовище не переварит всё, что съело, пусть весь мир подождёт.

→ Индексирование перестало работать.

В-четвёртых, в логе Сциллы стали появляться многочисленные сообщения об ошибке сохранения партиции со слишком большим количеством записей.

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

Решения

Первым шагом на пути к решению проблемы должен был стать переезд на SSD диски. Но когда разработчики провели архивацию на SSD на тестовых серверах, к их великому разочарованию, число таймаутов практически не уменьшилось, да и особого прироста в скорости копирования не получилось. Более того сам процесс переезда на SSD принёс множество сюрпризов, борьба с которыми вполне заслуживает отдельного доклада. Например, у Сциллы есть конфигурационный параметр auto_bootstrap, от которого во многом зависит, будет ли добавляемая в кластер машина с пустой базой подтягивать данные с других машин кластера (auto_bootstrap = True) или сама станет источником данных (auto_bootstrap = False), что приведёт к затиранию информации на всём кластере. Документация гласила, что по умолчанию, auto_bootstrap = True, но… не уточняла, с какой версии…

Следующим шагом разработчики попробовали отключить автокомпактификацию, но оно помогло лишь отчасти. Число таймаутов чуть сократилось, но сама компактификация стала занимать несколько дней. Это очень напоминало дилемму с отключением автовакуума в PostgreSQL. В итоге пришлось обратно включать автокомпактификацию.

Почему нельзя было просто увеличить время до таймаута? Дело в том, что завершение операции копирования по таймауту вовсе не означало, что отправленные в Сциллу записи не сохранились. Наоборот, как показал весьма пригодившийся этап валидации, большая часть данных успевала записаться. Валидация позволила даже в условиях многочисленных таймаутов продолжать перемещать данные в архив, не увеличивая время операции до таймаута.

Что касается индексов… От них пришлось отказаться. В описываемом эксперименте, по счастью, они действительно были балластом. Но потенциальным пользователям Сциллы стоит иметь в виду, что этот существенный недостаток так и не был исправлен на данный момент.

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

Тут-то и случился прогресс. Число таймаутов сократилось до нуля, возросла скорость копирования (до 200 миллионов записей в сутки) и компактификации. Более того, Сцилла даже позволяла проводить компактификацию параллельно с копированием. Решение проблемы с таймаутами позволило отказаться от этапа валидации, нагружавшего многочисленными запросами на чтение не приспособленную для этого Сциллу.

Новый алгоритм архивации стал значительно проще.

В итоге после применения вышеуказанных действий удалось добиться скорости архивации – 300 миллионов записей в сутки, то есть примерно 34 мегабайта в секунду, что в разы превышало требуемые значения.

Резюме

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

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

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

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

И, наконец, в-пятых, не верьте документации на слово и обязательно проверяйте любое действие на тестовых серверах. Особенно, если это действие связано с изменением инфраструктуры. Даже простое добавление сервера в кластер может привести к потере всех данных.

Таким образом, Илья не стал рекламировать и рекомендовать ScyllaDB, но подчеркнул, что наличие таких решений, особенно опенсорсных, очень важно. Это развивает конкуренцию и ПО. Можно и нужно исследовать новые СУБД и делиться опытом. Илья считает, что такое исследование должно быть предусмотрено в бюджете любого программного продукта. Ведь это же хорошо, когда есть альтернатива.

• Блог компании Конференции Олега Бунина (Онтико)
• Администрирование баз данных
• Хранение данных
• Сжатие данных
• Хранилища данных

ScyllaDB: приручение «лающей» базы данных

Критериям выбора архивного хранилища она соответствовала идеально. Оптимизированная под запись, легко масштабируемая, совместимая с привычной уже Cassandra, только в разы быстрее… Имя же её — Сцилла (греч. Σκύλλα — «лающая») — напоминая о мифологическом чудовище, рисовало в воображении картины молниеносного поглощения гигантских объемов данных. Сложно было устоять и не попробовать.

На тот момент мы уже использовали MongoDB и некоторые другие решения для реализации высоконагруженной товароучётной системы. Объём информации исчислялся терабайтами и продолжал стремительно расти. Однако значительную его часть составляли данные товаров, завершивших свой жизненный цикл. Появилась идея переносить такие данные в отдельное долговременное хранилище — архив. Вероятность появления запросов на чтение этой информации почти равна нулю. Почти! И всё же нулевой не является, поэтому отправлять такую информацию в /dev/null нельзя. Но и рабочую базу загромождать практически бесполезными данными тоже неправильно. Вот и получается, что архив — самое подходящее для таких данных место. Важно только, чтобы скорость записи в архив была сопоставима со скоростью перехода товаров в конечное состояние в основном хранилище. Что ж, вызов принят!

Изучив отзывы по нескольким популярным NoSQL решениям, мы решили попробовать Сциллу. Слишком уж заманчиво про неё рассказывали пользователи, да и исследовательский азарт прямо-таки требовал попробовать что-то новенькое.

Что-то новенькое

Сцилла — колоночная база данных, написанная на C++, с собственным алгоритмом утилизации памяти и CPU. При этом пользователь, как оказалось, практически не имеет механизмов воздействия на управление этим алгоритмом. К примеру, Сцилла не позволяет варьировать количество потоков под операцию компактификации — в отличие от той же Cassandra, идентичность интерфейсов с которой заявлена в качестве важного преимущества новой базы данных. Иначе говоря, когда чудовище наедается до определённой степени, оно переключает свои силы — зачастую все — на переваривание данных. И пусть весь мир подождёт.

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

Что интересно, хотя Сцилла и написана на С++, основная утилита для работы с ней — nodetool — реализована на Java, поэтому администрирование БД упирается по производительности и памяти в ограничения JVM. С чем мы не раз сталкивались, например, при удалении машины из кластера, когда операция nodetool cleanup не могла доработать до конца по причине нехватки памяти для JVM.

Сцилла, являясь типичным представителем NoSQL семейства, подходит далеко не для всякого набора данных и класса решаемых задач. Описание хранилища как «key-key-value storage» предполагает в упрощенном понимании, что данные должны представляться в виде словаря словарей. Хранить и использовать что-то с большим количеством уровней вложенности неэффективно. Это связано и с ограничением на размер записи, и с существенными проблемами индексирования в Сцилле, которые на момент написания статьи ещё не были решены.

Что будем архивировать и куда

В нашем случае данные, предназначенные для архивации, имели следующий вид:

• product_id (String): «50054c8b6f87f912»
• exec_date (Timestamp): 2022-05-31T00:00:00.000+0000
• owner (String): «12e8ea62818112e8»
• states (Object):

Ключом записи, по которому её можно было однозначно идентифицировать, служил атрибут product_id.

Для развертывания Сциллы была сконфигурирована следующая инфраструктура:

• количество серверов: 5;
• количество CPU на сервере: 32;
• размер ОП на сервере (Гб): 312;
• тип жестких дисков: HDD.

Хотя для достижения максимальной производительности разработчики Сциллы рекомендуют использовать SSD диски, опыт пользователей показал, что и с HDD дисками можно добиться приемлемой скорости записи. Поэтому мы решили начать с HDD-варианта, как более экономичного, рассматривая переход на SSD в качестве резервного решения.
Также, руководствуясь рекомендациями разработчиков Сциллы (и здравым смыслом) и исходя из наличия пяти доступных серверов, установили фактор репликации равный трём. На серверах развернули keyspace — логическое объединение данных (рис. 1).

Для описания структуры данных, а также для манипулирования данными в Сцилле используется CQL (Cassandra Query Language). Команды на нем напоминают аналогичные команды эталонного своей полнотой SQL и выполняются в специальной утилите cqlsh. Чтоб создать keyspace с именем archive и фактором репликации 3, можно воспользоваться следующей командой:

CREATE KEYSPACE archive WITH replication = AND durable_writes = true;

Для хранения направляемых в архив записей мы добавили в keyspace таблицу products, подобрав типы данных из тех, что поддерживаются Сциллой, и указав компрессию. Последняя определяется алгоритмом и степенью сжатия, которые будут применяться к сохраняемым данным. Учитывая запланированную интенсивность архивации и долгий срок хранения данных, решили сразу задать максимальную компрессию (алгоритм Zstandard, уровень сжатия 22). Поскольку Сцилла поддерживает шардирование данных, что называется, «из коробки», для таблицы необходимо задать ключ партиции (partition key). Он используется для расчёта токена и определения шарда для хранения этой партиции. В нашем случае партиция (partition) однозначно соответствовала записи (row), и ключом партиции стал product_id (рис. 2).

Таблица products с указанными характеристиками в keyspace archive создается следующей командой CQL:

CREATE TABLE archive.products (product_id text PRIMARY KEY, exec_date timestamp, owner text, states text) WITH compression = ;

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

CREATE INDEX ON archive.products(exec_date); CREATE INDEX ON archive.products(owner);

Скорость перехода товаров в конечное состояние (т.е. появление данных, пригодных для архивации) составляла порядка 30 млн. единиц в сутки. Ожидалось, что скорость архивации будет не меньше, т.к. уже имелся определенный бэклог, который требовалось разобрать. Разумеется, первым делом мы сделали cassandra-stress тест, чтоб определить, можно ли вообще рассчитывать на приемлемую скорость архивации для получившейся модели данных и записи заданного размера. А заодно проверили, какой эффект может дать отправка записей не поодиночке, а пачками.

Тест для одиночных записей показал такие скорости:

• Op rate (скорость выполнения операций): 2,431 op/s;
• Row rate (скорость добавления записей): 2,431 row/s;
• Latency mean (средняя задержка операции): 9.8 ms.

Для архивации же пачками (по 100 записей за операцию) результат был такой:

• Op rate (скорость выполнения операций): 46 op/s;
• Row rate (скорость добавления записей): 4,634 row/s;
• Latency mean (средняя задержка операции): 516.1 ms.

Хотя во втором случае скорость выполнения операций была существенно ниже (что неудивительно, т.к. каждая операция включала в себя вставку сразу ста записей), записи добавлялись почти вдвое быстрее. Этот вариант мы и выбрали: 4634 записи в секунду (а это порядка 400 млн. записей в сутки) с избытком обеспечивали требуемую скорость архивации, оставляя запас на сбор данных из основного хранилища и отправку данных по сети.

И, главное, как архивировать…

Результаты стресс-теста радовали и мотивировали на продолжение исследований. Через какое-то время был готов алгоритм архивации. Он учитывал три важных аспекта.

1. Поскольку Сцилла хранит записи в неизменяемых файлах SSTables (Sorted Strings Tables), ей необходимо периодически проводить операцию компактификации, в ходе которой актуальные копии записей заносятся в новые SSTables, а старые SSTables удаляются. Компактификация, как уже отмечалось выше, значительно снижает производительность Сциллы. Поэтому после копирования в последнюю ограниченного объема данных, ей нужно дать время на «переваривание».
2. Прежде чем удалять заархивированные данные из основного хранилища, неплохо бы убедиться, что они действительно записались в архив, т.к. Сцилла — для нас база новая, неизученная, и мало ли…
3. Удаление данных из основного хранилища замедляет все остальные операции с этим хранилищем, поэтому выполнять его следует строго в отведенное время, когда запросов к основному хранилищу немного.

С учетом этих аспектов алгоритм архивации разделялся на три этапа: копирование, валидация (от этого шага планировали со временем отказаться) и удаление (рис. 3).

Скорость копирования с учётом всех накладных расходов поначалу составляла 138 млн. записей в сутки — это казалось более чем достаточным результатом, хотя отставание от результатов cassandra-stress теста (400 млн. записей в сутки) было весьма значительным. Но ещё оставались этапы валидации и удаления, которые тоже занимали время, превращая суточный результат в недельный. И по факту получалось ~20 млн. записей в сутки — меньше скорости перехода товаров в конечное состояние (30 млн. в сутки). Однако, мы сохраняли оптимизм, предполагая, что недостаток скорости получится преодолеть путем отказа от этапа валидации, если система окажется стабильной…

Но всё что-то пошло не так

Как только объём заархивированных данных перевалил за терабайт, посыпались проблемы. Во-первых, более 50% операций записи в Сциллу стали завершаться по таймауту. Сцилла не успевала ни записать, ни «переварить» отправленные в неё данные. В итоге скорость копирования деградировала более чем в 5 раз: со 138 до 26 млн. в сутки. А скорость архивации в целом упала даже не до 3 млн. в сутки, а ещё значительней из-за сильного замедления этапа валидации.

Попытка отключения автокомпактификации на время копирования и её обратное включение на этапе простоя Сциллы (удаления из основного хранилища) помогли лишь отчасти, т.к. число таймаутов несколько снизилось, но компактификация стала занимать несколько дней.
Стоит заметить, что завершение операции по таймауту не означало, что ни одна из отправленных в Сциллу записей не сохранилась. Наоборот, как показал весьма пригодившийся здесь этап валидации, большая часть данных успевала записаться. И валидация позволила даже в условиях многочисленных таймаутов перемещать данные в архив и не увеличивать время до таймаута.
Во-вторых, через какое-то время вместе с таймаутами в логе Сциллы стали появляться записи вида

large_data - Writing a partition with too many rows [products /products_exec_date_idx_index:00000000146428] (294334 rows)

для Materialized View, на основе которых были созданы наши индексы для exec_date и owner. К сожалению, «лучшее» решение, предлагаемое разработчиками Сциллы для распространенной, кстати, проблемы — не использовать таблицы с большим числом записей на партицию. Иначе говоря, от индексов, которые нам, по счастью, так и не пригодились, пришлось отказаться. Да, в нашем случае индексы действительно были балластом, но потенциальным пользователям Сциллы стоит учитывать этот существенный недостаток, который так и не был исправлен её разработчиками на момент написания данной статьи.

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

Если в двух словах, то не стоит полагаться на документацию. Например, у Сциллы есть конфигурационный параметр auto_bootstrap, от которого во многом зависит, будет ли добавляемая в кластер машина с пустой базой подтягивать данные с других машин кластера (auto_bootstrap = True) или сама станет источником данных (auto_bootstrap = False), что приведёт к затиранию информации на всём кластере. Документация гласила, что по умолчанию, auto_bootstrap = True, но… не уточняла, с какой версии. Угадайте, повезло ли нам?) Казалось, эксперимент со Сциллой зашёл в тупик.

Но мы не сдались

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

ALTER TABLE archive.products WITH compression = ;

мы заметили определенный прогресс. Число таймаутов при копировании сократилось до нуля, возросла скорость копирования (до ~200 млн. записей в сутки) и компактификации. Теперь Сцилла даже позволяла проводить компактификацию параллельно с копированием.
Отсутствие таймаутов позволило нам отказаться от этапа валидации, нагружавшего запросами на чтение отнюдь не приспособленную для этого Сциллу. Новый алгоритм архивации стал значительно проще (рис. 4).

Однако скорости копирования и удаления данных были ещё далеки от идеала. И профилирование показывало, что проблема теперь уже касалась основного хранилища — MongoDB. Здесь проблема частично решилась с переездом на шардированное хранилище, но это уже совсем другая история. Применение означенных решений позволило нам в итоге добиться скорости архивации (да-да, именно архивации!) ~300 млн. записей в сутки, что значительно превышало требуемые значения (рис.5).

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

Нет предела совершенству

Да, в работе со Сциллой есть свои особенности. Некоторые из них я упомянул в статье, но это лишь вершина айсберга, и большая часть наверняка осталась незатронутой. И если их знать и учитывать, то вполне можно рассматривать Сциллу, как минимум, в качестве более производительной замены Cassandra. А как максимум… Тут всё зависит от конкретной задачи.

Что же касается нашего исследования, то оно, конечно, продолжится, несмотря на то что требуемые проектные показатели достигнуты. Ещё стоит задача по выявлению оптимальной компрессии и переходу к ней, т.к. диски жёсткие, но, увы, не резиновые. Есть что ускорить и в алгоритме архивации. Да и в самой Сцилле можно много чего исправлять и совершенствовать. К примеру, зависимость быстрого плюсового решения от джавовых административных утилит вроде nodetool или dsbulk — да ещё и с урезанным функционалом — постепенно становится, на мой взгляд, тормозящим фактором. Понятно, что схожесть с Cassandra на начальных порах способствовала переходу на новую базу данных во многих компаниях, но если Сцилла всё же стремится перерасти своего ближайшего конкурента, стоит оторваться от него посильнее.

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

• scylla
• cassandra
• nosql
• высокая производительность
• хранилище данных
• bigdata

• Блог компании STM Labs
• Высокая производительность
• Big Data
• Хранение данных
• Хранилища данных

ScyllaDB

22 сентября 2015 года Cloudius Systems представила ScyllaDB. В рамках проекта компания предприняла попытку переписать СУБД Apache Cassandra с Java на C++ [1] .

ScyllaDB обеспечивает полную совместимость с NoSQL СУБД Cassandra, но позволяет добиться значительного роста производительности, демонстрируя скорость обработки запросов и отклик на уровне СУБД Redis. СУБД представили Ави Кивити (Avi Kiviti) и Дор Лаор (Dor Laor), в своё время они создали известные открытые проекты гипервизора KVM и операционную систему OSv с воплощением идеи запуска приложений поверх гипервизора.

Код проекта распространяется под лицензией AGPLv3.

Как заявили разработчики, ScyllaDB обеспечивает десятикратное увеличение пропускной способности обработки запросов на каждом узле по сравнению с оригинальной Apache Cassandra, в 99% случаев успевая обработать запрос менее чем за миллисекунду. Например, на типовом узле ScyllaDB способна обрабатывать около одного миллиона транзакций в секунду. Обработка большего числа запросов на одном узле позволяет существенно снизить затраты на кластер, в котором для достижения заданных характеристик потребуется на порядок меньше узлов, чем при создании кластера на основе классической СУБД Cassandra. ScyllaDB также упрощает создание запаса производительности, необходимой при обработке нетипичных пиков нагрузки.

Таблица сравнения показателей СУБД, 2015

Один из факторов, позволивший достичь таких показателей производительности — использование разработанного авторами фреймворка C++ Seastar, нацеленного на создание сложных серверных приложений, обрабатывающих запросы в асинхронном режиме. Seastar учитывает особенности современного оборудования, таких как распараллеливание на многоядерных системах, учёт попадания данных в процессорный кэш, оптимизация для накопителей SSD, прямой доступ к очереди пакетов на сетевой карте и полная утилизация пропускной способности 10/40-гигабитных сетевых карт.

Сравнение времени задержки, 2015

Система построена на основе архитектуры shared-nothing, подразумевающей, что к каждому ядру CPU привязывается отдельный обособленный обработчик, которому выделена отдельная память (отсутствуют задержки из-за организации блокировок) и привязана отдельная очередь пакетов к сетевой карте. Российский рынок мобильных приложений для бизнеса и госсектора: крупнейшие игроки, тенденции и перспективы. Обзор TAdviser

По сути, каждый процесс-обработчик ScyllaDB включает в себя собственный оптимизирванный TCP/IP-стек, работающий в пространстве пользователя, прикреплённый к отдельному ядру CPU и напрямую взаимодействующий с сетевой картой. Интегрированный сетевой стек поддерживает работу с сетевыми картами на базе чипов Intel, для систем с другими сетевыми адаптерами предусмотрена возможность использования штатного сетевого стека Linux.

Распределение ресурсов системы, 2015

Свойства ScyllaDB: о

• избавление от задержек при упаковке и восстановлении целостности БД,
• отсутствие сборщика мусора,
• возможность переконфигурации кластера (удаление/добавление узлов) без остановки работы,
• линейная масштабируемость, при которой производительность находится в прямой зависимости от числа процессорных ядер,
• наличие средств для пакетной загрузки и выгрузки больших объёмов данных из хранилищ Hadoop и Spark.

ScyllaDB поддерживает модель хранения данных на основе семейства столбцов (ColumnFamily, хэши с несколькими уровнями вложенности) и позволяет использовать SQL-подобный язык структурированных запросов CQL (Cassandra Query Language). Для подключения к ScyllaDB можно использовать существующие клиентские драйверы для Apache Cassandra. СУБД ScyllaDB можно использовать в качестве прозрачной замены Apache Cassandra.

Примечания

Сцилла (база данных)

Scylla — это распределенное хранилище данных NoSQL с широкими столбцами с открытым исходным кодом . Он был разработан для совместимости с Apache Cassandra , обеспечивая при этом значительно более высокую пропускную способность и меньшие задержки. Он поддерживает те же протоколы, что и Cassandra ( CQL и Thrift ), и те же форматы файлов (SSTable), но представляет собой полностью переписанную реализацию, использующую язык C++20 , заменяющий Cassandra Java, и библиотеку асинхронного программирования Seastar [1] с потоками . , общая память, сопоставленные файлы и другие классические приемы программирования для Linux. Помимо реализации протоколов Cassandra, Scylla также реализует API Amazon DynamoDB . [2]

Scylla использует сегментированную структуру на каждом узле, что означает, что каждое ядро ​​ЦП обрабатывает разное подмножество данных. Ядра не обмениваются данными, а явно взаимодействуют, когда им это необходимо. Авторы Scylla утверждают, что эта конструкция позволяет Scylla добиться гораздо большей производительности на современных машинах NUMA SMP и очень хорошо масштабироваться с количеством ядер. Они измерили до 2 миллионов запросов в секунду на одной машине [3] , а также утверждают, что кластер Scylla может обслуживать столько же запросов, сколько кластер Cassandra в 10 раз больше его размера, и делать это с меньшими задержками. [4] Независимое тестирование не всегда могло подтвердить такое 10-кратное повышение пропускной способности, а иногда измеряло меньшее ускорение, например, 2x. [5] В тесте Samsung 2017 года наблюдалось 10-кратное ускорение на высокопроизводительных машинах — тест Samsung показал, что Scylla превосходит Cassandra на кластере из 24-ядерных машин с разницей в 10–37 раз в зависимости от рабочей нагрузки YCSB . [6]

Scylla доступна либо в виде локального решения, либо у основных поставщиков общедоступных облачных служб, либо в виде DBaaS (Scylla Cloud).

Scylla была запущена в декабре 2014 года стартапом Cloudius Systems (позже переименованным в ScyllaDB Inc.), ранее известным тем, что создал OSv . Scylla была выпущена с открытым исходным кодом в сентябре 2015 года [7] по лицензии AGPL . Сотрудники ScyllaDB Inc. остаются основными кодировщиками Scylla, но ее разработка открыта для общественности и использует общедоступные репозитории GitHub и общедоступные списки рассылки.