- PVSM.RU - https://www.pvsm.ru -
7-8 ноября 2017 на конференции Highload++ исследователи лаборатории «Рэйдикс» представили доклад «Метаданные для кластера: гонка key-value-героев».
В этой статье мы представили основной материал доклада, касающийся тестирования баз данных key-value. «Зачем их тестировать производителю СХД?», — спрóсите вы. Задача возникла в связи с проблемой хранения метаданных. Такие «фичи», как дедупликация, тиринг, тонкое выделение ресурсов (thin provisioning), лог-структурированная запись, идут вразрез с механизмом прямой адресации – возникает необходимость хранить большое количество служебной информации.
Предположим, что всё пространство хранения поделено на страницы размером X байт. У каждой из них есть свой адрес — LBA (8 Байт). Для каждой такой страницы мы хотим хранить Y байт метаданных. Таким образом, получаем набор соответствий lba -> metadata. Сколько таких соответствий у нас будет? Всё зависит от того, сколько данных мы будем хранить.
Рис. 1. Метаданные
Например, при X=4KB, Y=16 байта. Получаем следующую таблицу:
Таблица 1. Соотношение объема хранения и метаданных
Объем данных на узел | Количество ключей на узел | Объем метаданных |
---|---|---|
512ТБ | 137 млрд | 3ТБ |
64ТБ | 17 млрд | 384ГБ |
4ТБ | 1 млрд | 22.3ГБ |
Объём метаданных достаточно большой, поэтому держать метаданные в RAM не представляется возможным (либо это экономически нецелесообразно). В связи с этим возникает вопрос хранения метаданных, причем с максимальной производительностью доступа.
Что такое прямая адресация? Это когда мы просто размещаем на накопителе наши метаданные по порядку, начиная с самого первого сектора накопителя. При этом нам даже не надо записывать, какому lba соответствуют метаданные, так как всё лежит в порядке возрастания lba.
Рис. 2. Принцип работы прямой адресации
На рисунке 2 pba1 — это физический сектор (512Б) накопителя, где мы храним метаданные, а lba1...lba32 (их 32, т.к. 512Б/16Б = 32) — адреса тех страниц, которым эти метаданные соответствуют, и эти адреса нам хранить не надо.
Исходя из нашего опыта рабочих нагрузок, определимся, какие требования по задержкам и пропускной способности нам нужны.
Рабочая нагрузка в медиаиндустрии:
Рабочая нагрузка в сегменте Enterprise:
Рабочая нагрузка в высокопроизводительных вычислениях (High Performance Computing – HPC):
Из представленных рабочих нагрузок в различных отраслях рынка сформируем итоговые требования к производительности All-Flash СХД:
Чтобы выбрать, какая БД из десятков существующих нам подойдёт, надо провести тесты на избранных нагрузках. Так мы сможем понять, как та или иная БД справляется с определённым объёмом данных, какие обеспечивает задержки/пропускную способность.
Какие сложности возникают на старте?
Существует два типа key-value баз данных:
В этой статье мы рассмотрим тестирование встраиваемых key-value БД (далее по тексту будем называть их «движками»).
Первый вариант, который можно найти, — YCSB [1].
Особенности YCSB:
Второй вариант — бенчмарк для движков ioarena [2].
Рис. 3. Варианты тестирований
В итоге для движков выбираем ioarena, а для выделенных – YCSB.
Кроме workload'ов в ioarena нами была добавлена опция (-a), позволяющая указывать при запуске отдельно количество выполняемых операций на поток и отдельно количество ключей в БД.
Все изменения в коде ioarena можно найти на GitHub [3].
Основной workload, который нам интересен, – Mix50/50. Также мы решили посмотреть на RR, Mix70/30 и Mix30/70, чтобы понять, какие БД больше «любят» тот или иной workload.
Тестируем в 3 этапа:
Конфигурация:
CPU: | 2x Intel Xeon E5-2620 v4 2.10GHz |
RAM: | 16GB |
Disk: | [2x] NVMe HGST SN100 1.5TB |
OS: | CentOS Linux 7.2 kernel 3.11 |
FS: | EXT4 |
Здесь важно отметить, что такой малый объем RAM взят не случайно. Таким образом, база не сможет полностью поместиться в кэш на тестах с 1 млрд ключей.
Объем доступной RAM регулировался не физически, а программно — часть заполнялась искусственно скриптом на Python, а остаток был свободен для БД и кэшей.
В некоторых тестах было иное количество доступной памяти — об этом будет сказано отдельно.
NVMe в тестах использовался один.
Важный момент — режим надёжности записи данных на диск. От этого очень сильно зависит скорость записи и вероятность/объём потерь при сбоях.
В целом, можно выделить 3 режима:
По производительности разница примерно такая (на примере движка MDBX):
Цифры здесь ТОЛЬКО для примерного понимания разницы между режимами.
В итоге для тестов был выбран режим lazy как наиболее сбалансированный. Об исключениях будет сказано отдельно.
Для тестирования «движков» мы проводили два варианта тестирования: на 1 млрд ключей и на 17 млрд ключей.
Выбранные «движки»:
Рис. 4.1. Зависимость текущей скорости (IOPS) от количества ключей (ось абсцисс — миллионы ключей).
Здесь все движки в стандартной конфигурации. Режим надёжности Lazy, кроме MDBX. У него слишком медленная запись в Lazy, поэтому для него был выбран режим Nosync, иначе заполнение продлится слишком долго. Однако видно, что с некоторого момента всё равно скорость записи падает примерно до уровня скорости Sync режима.
Что можно увидеть на этом графике?
Первое: с RocksDB что-то случается после 800 млн ключей. К сожалению, не были выяснены причины происходящего.
Рис. 4.2. Зависимость текущей скорости (IOPS) от количества ключей (ось абсцисс — миллионы ключей).
Второе: MDBX плохо перенёс момент, когда данных стало больше, чем доступно памяти.
Рис. 4.3. Зависимость текущей скорости (IOPS) от количества ключей (ось абсцисс — миллионы ключей).
Далее можно посмотреть на график максимальной задержки. Тут также видно, что у RocksDB начались вылеты после 800 млн ключей.
Рис. 5 Максимальная latency
Ниже находится график среднего квадратического значения задержки. Тут также видны те самые границы для RocksDB и MDBX.
Рис. 6.1. RMS Latency
Рис. 6.2. RMS Latency
К сожалению, Sophia показала низкий результат во всех тестах. Скорее всего, она не «любит» много потоков (т.е. 32 и более).
WiredTiger сначала показывал очень низкую производительность — на уровне 30 IOPS. Оказалось, что у него есть важный параметр cache_size, который по умолчанию выставлен на 500МБ. После его установки на 8ГБ (или даже 4ГБ) всё становится намного лучше.
Ради интереса был проведён тест с тем же объёмом данных, но с объёмом доступной памяти > 100ГБ. В этом случае MDBX с отрывом уходит вперёд в тесте на чтение.
Рис. 7. 100% Read
При добавлении записи в workload получаем сильное падение MDBX (что ожидаемо, т.к. при заполнении скорость была низкой). WiredTiger подрос, а RocksDB снизил скорость.
Рис. 8. Mix 70%/30%
Тенденция сохранилась.
Рис. 9. Mix 50%/50%
Когда записи становится довольно много, WiredTiger начинает обгонять RocksDB на малом количестве потоков.
Рис. 10. Mix 30%/70%
Теперь можно посмотреть на графики задержек. Столбцы показывают минимальную и максимальную задержки, оранжевая полоска — средняя квадратическая задержка, а красная полоска — перцентиль 99.99.
Зелёная полоса — это примерно 2 мс. То есть мы хотим, чтобы перцентиль находился не выше зелёной полосы. В данном случае мы этого не получаем (шкала логарифмическая).
Рис. 11. Latency Read
Рис. 12. Latency 50%/50%
Тесты на 17млрд ключей были проведены только на RocksDB и WiredTiger, т.к. они были лидерами в тестах на 1 млрд ключей.
У WiredTiger начались странные выпады, но в целом он довольно неплохо себя показывает на заполнении, плюс не наблюдается деградации при увеличении объёма данных.
А вот RocksDB в итоге спустился ниже 100k IOPS. Таким образом, в тесте на 1 млрд ключей мы не видели всей картины, поэтому важно проводить тесты на объёмах, сравнимых с реальными!
Рис. 13. Производительность 17 млрд ключей
Пунктирной линией изображена средняя квадратическая задержка. Видно, что максимальная задержка у WiredTiger выше, а средняя квадратическая ниже, чем у RocksDB.
Рис. 14. Latency 17 млрд ключей
С WiredTiger'ом случилась та же беда, что и в прошлый раз — он показывал около 30 IOPS на чтение, даже при cache_size=8GB. Было решено ещё увеличить значение параметра cache_size, но и это не помогло: даже при 96ГБ скорость не поднялась выше нескольких тысяч IOPS, хотя выделенная память даже не была заполнена.
При добавлении записи к workload'у WiredTiger традиционно поднимается.
Рис. 15. Производительность 100% Read
Рис. 16. Производительность 70%/30%
Рис. 17. Производительность 30%/70%
Рис. 18. Производительность 50%/50%
Рис. 19. Latency 100% Read
Рис. 20. Latency 50%/50%
Из того, что сказано выше, можно сделать следующие выводы:
Для базы объемом в 1 млрд ключей:
Из чего следует, что:
Для базы объемом в 17 млрд ключей: однозначное лидерство у RocksDB.
Такова ситуация со встраиваемыми движками. В следующей статье мы расскажем о показателях выделенных баз данных key-value и сделаем выводы о бенчмарках.
Автор: raidixteam
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/bazy-danny-h/271117
Ссылки в тексте:
[1] YCSB: https://github.com/brianfrankcooper/YCSB/wiki
[2] ioarena: https://github.com/pmwkaa/ioarena
[3] GitHub: https://github.com/ragruslan/ioarena
[4] RocksDB: http://rocksdb.org/
[5] WiredTiger: http://www.wiredtiger.com/
[6] тут: http://source.wiredtiger.com/2.9.3/architecture.html
[7] Sophia: http://sophia.systems/
[8] тут: http://sophia.systems/v2.2/arch/v12.html
[9] MDBX: https://github.com/leo-yuriev/libmdbx
[10] Источник: https://habrahabr.ru/post/345076/?utm_campaign=345076
Нажмите здесь для печати.