Нагрузочное тестирование YCSB: Sirin vs Apache Cassandra

Sirin — плагин для Picodata, реализующий протокол Apache Cassandra. Мы сравнили его производительность с Cassandra 5.0.6 с помощью стандартного бенчмарка YCSB на пяти профилях нагрузки: от интенсивной записи до только чтения. Оба стенда ограничены 6 ядрами CPU.

¹ Для workload F пропускная способность указана в tps (транзакций в секунду по YCSB): одна транзакция — это либо одиночное чтение (READ), либо полный RMW-цикл (READ + UPDATE). Прямое сравнение с rps остальных профилей некорректно.

Введение

Sirin — плагин для распределённой СУБД Picodata, реализующий протокол Apache Cassandra. Благодаря этому плагину приложения, использующие драйверы CQL, могут работать с Picodata без изменения кода.

Целью данного документа является оценка производительности Sirin 1.3.0 в сравнении с Cassandra 5.0.6 на нагрузке, генерируемой инструментом YCSB (Yahoo! Cloud Serving Benchmark). YCSB использует плоскую таблицу usertable: каждая запись содержит ключ и 10 текстовых полей по 100 байт (~1 КБ на строку), запросы обращаются к полному содержимому строки. Это позволяет оценить поведение систем на типовых OLTP-сценариях с разным соотношением операций чтения и записи.

YCSB предоставляет стандартный набор профилей нагрузки (workloads), широко используемых в индустрии для сравнительной оценки NoSQL-систем. Тестирование охватывает профили A, B, C, D и F: от смешанной нагрузки с равными долями чтения и обновления до полностью читающей нагрузки, сценария с вставкой свежих записей и нагрузки типа read-modify-write.

Измеряются пропускная способность, задержки выполнения запросов (p95, p99, min, max), потребление вычислительных ресурсов (CPU, RAM) и нагрузка на дисковую подсистему.

Условия

Стенд

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

Конфигурация ВМ с базами данных:

Конфигурация баз данных

Обе системы тестировались без репликации данных. Лимит CPU в 6 ядер задавался через cgroups одинаково для обеих систем, чтобы обеспечить сравнимые условия.

Схема данных

YCSB использует стандартную схему с таблицей usertable. Каждая запись содержит ключ и 10 текстовых полей по 100 байт, итоговый размер строки — около 1 КБ:

CREATE TABLE usertable (
    y_id   varchar PRIMARY KEY,
    field0 varchar,
    field1 varchar,
    field2 varchar,
    field3 varchar,
    field4 varchar,
    field5 varchar,
    field6 varchar,
    field7 varchar,
    field8 varchar,
    field9 varchar
);

Инструмент нагрузки

Тесты проводились утилитой YCSB с биндингом cassandra-cql. Данные предварительно загружались командой ycsb.sh load, тесты запускались командой ycsb.sh run с параметром -p maxexecutiontime=3600 (1 час на каждый тест).

Набор тестов

YCSB задаёт профиль нагрузки через файл workload, определяющий соотношение операций и распределение ключей. Zipfian — популярные ключи запрашиваются значительно чаще (горячее пятно, характерно для OLTP). Latest — чаще запрашиваются недавно вставленные записи.

Результаты

Workload A — update heavy (50% чтения, 50% обновлений)

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

Команда для запуска теста:

./bin/ycsb.sh run cassandra-cql \
    -P workloads/workloada \
    -p hosts=10.20.1.1 \
    -p recordcount=30000000 \
    -p operationcount=999999999 \
    -p maxexecutiontime=3600 \
    -p cassandra.readconsistencylevel=ONE \
    -p cassandra.writeconsistencylevel=ONE \
    -threads 96 \
    -p cassandra.maxconnections=10 \
    -p cassandra.coreconnections=10

Запросы (prepared statements):

-- Чтение
SELECT * FROM usertable WHERE y_id = ?

-- Обновление
UPDATE usertable SET field0=?,field1=?,field2=?,field3=?,field4=?,
    field5=?,field6=?,field7=?,field8=?,field9=? WHERE y_id = ?

Workload B — read mostly (95% чтения, 5% обновлений)

Профиль моделирует системы с преобладанием операций чтения и редкими мутациями, например, тегирование фотографий: большинство операций — чтение тегов, добавление тега — обновление.

Команда для запуска теста:

./bin/ycsb.sh run cassandra-cql \
    -P workloads/workloadb \
    -p hosts=10.20.1.1 \
    -p recordcount=30000000 \
    -p operationcount=999999999 \
    -p maxexecutiontime=3600 \
    -p cassandra.readconsistencylevel=ONE \
    -p cassandra.writeconsistencylevel=ONE \
    -threads 64 \
    -p cassandra.maxconnections=10 \
    -p cassandra.coreconnections=10

Запросы (prepared statements):

-- Чтение
SELECT * FROM usertable WHERE y_id = ?

-- Обновление
UPDATE usertable SET field0=?,field1=?,field2=?,field3=?,field4=?,
    field5=?,field6=?,field7=?,field8=?,field9=? WHERE y_id = ?

Workload C — read only (100% чтения)

Профиль моделирует системы, в которых данные формируются внешним процессом (например, Hadoop-пайплайном), а сама БД обслуживает только операции чтения — например, кэш профилей пользователей.

Команда для запуска теста:

./bin/ycsb.sh run cassandra-cql \
    -P workloads/workloadc \
    -p hosts=10.20.1.1 \
    -p recordcount=30000000 \
    -p operationcount=999999999 \
    -p maxexecutiontime=3600 \
    -p cassandra.readconsistencylevel=ONE \
    -p cassandra.writeconsistencylevel=ONE \
    -threads 64 \
    -p cassandra.maxconnections=10 \
    -p cassandra.coreconnections=10

Запрос (prepared statement):

-- Чтение
SELECT * FROM usertable WHERE y_id = ?

Workload D — read latest (95% чтения, 5% вставок)

Профиль моделирует системы, где пользователи в основном читают свежие данные — например, ленту статусов: новые записи добавляются непрерывно, и они же чаще всего читаются. В отличие от workload B, запросы используют распределение latest: недавно вставленные ключи запрашиваются с большей вероятностью.

Команда для запуска теста:

./bin/ycsb.sh run cassandra-cql \
    -P workloads/workloadd \
    -p hosts=10.20.1.1 \
    -p recordcount=30000000 \
    -p operationcount=999999999 \
    -p maxexecutiontime=3600 \
    -p cassandra.readconsistencylevel=ONE \
    -p cassandra.writeconsistencylevel=ONE \
    -threads 64 \
    -p cassandra.maxconnections=10 \
    -p cassandra.coreconnections=10

Запросы (prepared statements):

-- Чтение
SELECT * FROM usertable WHERE y_id = ?

-- Вставка
INSERT INTO usertable (y_id,field0,field1,field2,field3,field4,
    field5,field6,field7,field8,field9) VALUES (?,?,?,?,?,?,?,?,?,?,?)

Workload F — read-modify-write (50% чтения, 50% RMW)

Профиль моделирует системы, где записи читаются и тут же модифицируются пользователем или для фиксации его активности — например, пользовательские базы данных с накопительными счётчиками. В отличие от слепого обновления (workload A), операция RMW всегда предваряется чтением той же строки, что удваивает количество обращений к хранилищу на одну логическую операцию. Пропускная способность для этого профиля измеряется в tps: YCSB считает одной транзакцией либо чистый READ, либо полный RMW-цикл — вне зависимости от числа фактических запросов к БД.

Команда для запуска теста:

./bin/ycsb.sh run cassandra-cql \
    -P workloads/workloadf \
    -p hosts=10.20.1.1 \
    -p recordcount=— \
    -p operationcount=999999999 \
    -p maxexecutiontime=3600 \
    -p cassandra.readconsistencylevel=ONE \
    -p cassandra.writeconsistencylevel=ONE \
    -threads — \
    -p cassandra.maxconnections=10 \
    -p cassandra.coreconnections=10

Запросы (prepared statements):

-- Чтение (в т.ч. первый шаг RMW)
SELECT * FROM usertable WHERE y_id = ?

-- Запись (второй шаг RMW)
UPDATE usertable SET field0=?,field1=?,field2=?,field3=?,field4=?,
    field5=?,field6=?,field7=?,field8=?,field9=? WHERE y_id = ?

Выводы

Архитектурный контекст

В тестах использовалось 30 миллионов записей (~30 ГБ сырых данных при ~1 КБ на строку). Этот объём не помещается как в memtable систем, так и в дисковый кеш linux. В результате чтения обоих систем частично уходят на диск. Однако использование Zipfian подразумевает горячее пятно в данных, к которому обращается большая часть запросов, и, следовательно, эти данные всегда находятся в page cache.

Workload A

Оба стенда показывают постепенное снижение пропускной способности на протяжении всего часа: по графикам RPS Sirin падает с ~52 000 до ~35 000 rps, Cassandra — с ~45 000 до ~25 000 rps. Причина видна на графиках IOPS: по мере накопления обновлений новые LSM-уровни вытесняют горячие данные из буфера, и чтение всё чаще уходит на диск. У Cassandra дисковые чтения монотонно растут с ~12 000 до 29 000 IOPS к концу теста — именно это обеспечивает более резкое падение производительности. У Sirin рост IOPS сдержаннее (~12 000–15 000), а деградация мягче: ~33% против ~44% у Cassandra.

Средний результат за час — Sirin 41 585 против 31 888 rps (+30%). По хвостовым задержкам (tail latency) Sirin значительно лучше: p99 на чтение 3.76 мс против 33.98 мс, p99 на обновление 3.54 мс против 30.77 мс. Максимальная задержка у Cassandra достигает 500 мс против 100 мс у Sirin.

Workload B

При снижении доли обновлений с 50% до 5% картина меняется. По графикам IOPS у обеих систем дисковые чтения не растут, а постепенно снижаются к концу теста (Sirin: ~23 000→17 000 IOPS, Cassandra: ~22 000→18 000 IOPS) — кэш OS постепенно прогревается на читающей нагрузке. Несмотря на это, RPS обеих систем незначительно снижается к концу теста, что указывает на CPU как на основное ограничение в данном профиле.

Преимущество Sirin сокращается до 11% (37 612 против 33 866 rps). Хвостовые задержки (tail latency) остаются значительно лучше: p99 на чтение 8.26 мс против 29.6 мс, p99 на обновление 7.44 против 29.2 мс.

Workload C

Единственный профиль, на котором обе системы выходят на стабильный режим с первых минут и удерживают его без деградации до конца теста. Отсутствие записи исключает рост LSM-уровней и давление компакции, поэтому тест демонстрирует «чистую» читающую производительность при установившемся кэше. На графике RPS у Sirin кривая практически горизонтальна на протяжении всего часа.

Sirin опережает Cassandra на 9% (44 540 против 40 919 rps). P99 на чтение: 5.60 мс против 25.02 мс.

Workload D

Обе системы работают при сопоставимой дисковой нагрузке на чтение (~15 480 и ~15 330 IOPS соответственно), однако Sirin опережает Cassandra: 63 591 против 53 396 rps (+19%) при меньшем потреблении CPU (79% против 82%). Cassandra при этом читает с диска значительно больше байт — 306 МБ/с против 188 МБ/с у Sirin — при практически одинаковом числе операций: это означает, что Cassandra читает более крупными блоками и «подтягивает» больше лишних данных за один IOPS.

На стороне записи картина обратная: Sirin активнее пишет на диск (80 против 36 write IOPS, 72 против 33 МБ/с) — следствие более частых фоновых компакций Vinyl при поступлении новых вставок. Несмотря на это, на графике RPS Sirin держит стабильный уровень ~62–65 000 с характерными кратковременными просадками от компакций, а у Cassandra RPS ровный, но на ~19% ниже.

P99 на чтение: 4.64 мс против 14.6 мс; p99 на вставку: 4.69 мс против 16.1 мс.

Workload F

Sirin опережает Cassandra на 24%: 24 805 против 19 930 tps. Это наименьший абсолютный показатель пропускной способности среди всех профилей — закономерный результат: RMW-цикл требует двух последовательных обращений к БД (SELECT, затем UPDATE), и пока не завершится чтение, поток не может начать запись. Это увеличивает эффективную задержку на транзакцию по сравнению со слепым обновлением в workload A.

Хвостовые задержки (tail latency) отражают двухфазную природу RMW: p99 на RMW у Sirin составляет 16.77 мс против 41.63 мс у Cassandra (разрыв ×2.5). P99 на чистое чтение — 10.19 мс против 36.38 мс. Максимальные задержки у Cassandra достигают 443–448 мс против 127–137 мс у Sirin.

Картина дисковых операций близка к workload D: Cassandra читает с диска больше байт при большем числе IOPS — 446 МБ/с при 27 590 IOPS против 247 МБ/с при 19 340 IOPS у Sirin. Та же закономерность — Cassandra считывает более крупные блоки и «подтягивает» лишние данные, тогда как Sirin читает эффективнее. На стороне записи Sirin активнее пишет на диск (63.6 IOPS / 58.7 МБ/с против 15.5 IOPS / 12.6 МБ/с), что характерно для фоновых компакций Vinyl.

Потребление ресурсов

Sirin стабильно потребляет 3.6–4.0 ГБ оперативной памяти во всех тестах. Cassandra — 11.7–12.1 ГБ, то есть втрое больше. Разница принципиальна: при совместном размещении узлов или сервисов на одной машине это существенно влияет на допустимую плотность. По CPU обе системы в смешанных тестах выходят на ~80%, то есть вычислительное ядро нагружено сопоставимо.

Итог

Sirin опережает Cassandra по пропускной способности во всех пяти протестированных профилях: ×1.30 (A), ×1.11 (B), ×1.09 (C), ×1.19 (D), ×1.24 (F). На нагрузках со значительной долей записи (A, B) основным ограничивающим фактором для обеих систем является рост дисковых чтений при накоплении LSM-уровней; Sirin деградирует медленнее. На чисто читающей нагрузке (C), при вставках с latest-распределением (D) и при RMW-нагрузке (F) Sirin показывает более высокую эффективность при аналогичном числе дисковых операций: Cassandra читает с диска заметно больше байт за тот же IOPS, что снижает итоговую пропускную способность.

По задержкам Sirin стабильно лучше: p99 в 2.5–9 раз ниже, максимальные задержки у Cassandra достигают 198–500 мс против 93–137 мс у Sirin. Потребление RAM у Sirin втрое ниже при сопоставимой загрузке CPU.