Обзор YDB: что за СУБД и как работает
YDB — Open-Source Distributed SQL Database. Она имеет лицензию Apache 2.0 и найти её можно по ссылке.
Особенности YDB
Обеспечивает строгую консистентность. В CAP-теореме мы выбираем CP, чтобы подчеркнуть наше беспокойство о пользователях и их данных. Кроме того, у нас serializable-уровень изоляции транзакций. Это значит, что вы, как разработчики приложений, не рискуете посадить трудно диагностируемые баги.
Обеспечивает высокую доступность и отказоустойчивость. YDB может работать в нескольких зонах доступности (дата-центрах). И YDB выдерживает параллельный отказ одного дата-центра и стойки серверов в другом дата-центре. При этом сохраняет доступность на чтение и запись без участия человека — всё происходит автоматически.
Подходит для хранения критически важных данных. YDB подходит для проектов, которые требуют доступности 365 дней в году и 24 часа в сутки на протяжении 7 дней. Окно обслуживания при этом не нужно.
OLTP и OLAP в активной разработке. Кроме того, YDB — это ещё и платформа, на базе которой есть YDB Topic Service, сетевые диски в Yandex Сloud и хранение временных рядов.
Performance-цели, которые мы ставим перед собой в работе над YDB:
- Максимизировать throughput и обслуживать большее число запросов
- Минимизировать latency — время ожидания ответа от базы на запрос
- Сократить издержки на содержание базы данных
До выхода в опенсорс мы держали фокус на фичах и масштабируемости. У нас были самодельные бенчмарки, на которых проверяли идеи. И ещё проводили проверку улучшений на testing- и stable-кластерах.
После выхода в опенсорс мы поняли, что не у всех есть возможность иметь такой prestable-кластер и людям интересны более традиционные бенчмарки. Так у нас появились две дополнительные задачи: повышение эффективности и сравнение с другими СУБД.
Для бенчмаркинга мы выбрали два популярных бенчмарка:
- Yahoo! Cloud Serving Benchmark (YCSB) — key-value нагрузка
- TPC-C — золотой стандарт для распределённых транзакций
Тест YDB на YCSB
Yahoo! Cloud Serving Benchmark (YCSB) — популярный key-value бенчмарк. Он простой и поддерживает практически все существующие СУБД. Мы решили использовать его по двум причинам:
- Key-value нагрузка по-прежнему актуальна и проста для аналитики
- Нельзя сделать быстрые распределённые транзакции с плохой производительностью key-value запросов
YCSB по умолчанию состоит из шести workloads.
- Много обновлений: 50% чтений, 50% обновлений.
- Преимущественно чтения: 95% чтений, 5% обновлений.
- Только чтения: 100% чтений, 0% обновлений.
- Чтение свежих записей: 95% чтений, 5% вставок.
- Чтение-изменение-запись: 50% чтений, 50% чтений-обновлений.
- Короткие диапазоны: 95% сканов, 5% вставок.
Везде, кроме четвёртого пункта, по умолчанию установлено zipfian-распределение ключей. Но мы тестируем и с uniform.
Для сравнения YDB с другими СУБД мы взяли CockroachDB и YugabyteDB, потому что эти базы распределённые, реляционные и опенсорсные. И самое главное, зрелые — у них есть продакшен и сравнение производительности в открытых источниках. Так мы можем сверить результаты.
Тестовый сетап был небольшим по меркам Яндекса. Мы задействовали три сервера со следующими конфигурациями:
- 128 логических ядер (2x Intel Xeon Gold 6338 2,00 ГГц)
- 4x NVMe Intel
- 512 ГБ ОЗУ
- Сеть 50 Гбит/с
- Включены transparent huge pages
Во время использования бенчмарков важно учитывать нюансы сравниваемых СУБД и самих бенчмарков.
Например, мы использовали оригинальный бенчмарк YCSB и добавляли туда поддержку YDB. В первом случае мы брали версию YDB на Java, а во втором — использовали версию YDB на GO. Когда сделали сравнение, то получили разные результаты. Это связано с тем, что у каждого языка программирования собственная среда выполнения и собственная эффективность. И эти факторы могут влиять на эффективность самого бенчмарка.
Что мы обнаружили во время тестирования:
Проблемы в YDB на workload E. После тестирования эти проблемы устранили, теперь всё работает быстро.
Невозможность масштабирования YugabyteDB. Из-за проблемы с вертикальным масштабированием YugabyteDB не удалось использовать все доступные ресурсы. А запустить несколько инстансов YugabyteDB на одном сервере не получилось из-за бага. Поэтому ни горизонтально, ни вертикально в нашем сетапе они не масштабируются.
Нюансы в языке SQL. Недостаточно просто запустить бенчмарк, надо понимать, как он реализован: INSERT vs UPDATE vs UPSERT. Бенчмарк YCSB говорит, что нужно использовать именно UPSERT, но оставляет за разработчиками выбор между этими операциями. Разработчики CocroachDB используют INSERT, в отличие от YugabyteDB и YDB, и поэтому получают небольшую деградацию.
Тест YDB на TPC-C
Стандарт TPC-C появился ещё в 1992 году, но до сих пор остаётся актуальным. И мы, и наши конкуренты считаем его самым главным бенчмарком для распределённых транзакций. TPC-C внешне похожа на ecommerce-организацию: есть компания → у компании есть склады → эти склады занимаются торговлей.
Логика работы TPC-C очень простая:
- При запуске задаётся число складов
- Каждый склад обслуживает 10 районов, примерно 100 МБ данных
- В каждом районе есть терминал
- Пользователи через эти терминалы делают заказы и оплачивают их
- Иногда через терминал проверяют статус заказа
- Доставка выполняется тоже через терминал
- Инвентаризация на складах проводится также через терминал
Транзакции TPC-C многошаговые и требуют уровня serializable. Чтение и запись соотносятся друг с другом примерно как два к одному. В качестве метрики бенчмарк использует tpmC — число заказов в минуту.
Для сравнения мы использовали фреймворк CMU Benchbase, потому что это единственная широко известная реализация стандарта TPC-C. Что у нас получилось — смотрите на графике.
Но вот с какими проблемами мы столкнулись:
Долгий импорт данных через INSERT. Для импорта базы предлагают более быстрые операции наподобие bulk upsert в YDB.
Трудности в достижении concurrency. TPC-C, как YCSB, использует синхронные запросы к базе данных. И если вы хотите достигнуть concurrency, вам нужно создать много физических потоков. А много физических потоков на одном сервере создать сложно, когда речь идёт о десятках тысяч складов.
Сложность масштабирования. Бенчмарк хранил всю статистику, даже на старте он использовал 40 мегабайт памяти на один склад. В итоге мы получили следующие требования к запуску TPC-C: 150 000 физических потоков и 600 гигабайт оперативной памяти. И мы это запускали на пяти серверах, у каждого из которых 128 ядер и 512 гигабайт оперативной памяти. При масштабировании такие эксперименты становятся дикими.
Выводы и рекомендации
В результате тестирования мы не только оптимизировали YDB, но и улучшили существующие бенчмарки. Так YDB стала бенчмарком бенчмарков.
Если вы планируете бенчмаркать базы данных, воспользуйтесь нашим опытом и рекомендациями:
- Будьте готовы улучшать опенсорс-бенчмарки или писать свои
- Не стоит писать бенчмарк на Go, если приложение на Java
- Бенчмаркайте на той архитектуре, которую используете
- Старайтесь писать бенчмарки так, чтобы они потребляли существенно меньше ресурсов, чем тестируемые СУБД
- При выборе СУБД смело используйте бенчмарки YCSB и TPC-C