An in-depth look at database and cache internals, and the tradeoffs in each. ScyllaDB хотел бы публично признать dormando (Memcachediner) и Danny Kopping за их вклад в этот проект, а также поблагодарить их за поддержку и терпение. Спящий Дэнни Коппинг Инженеры, стоящие за ScyllaDB – базой данных для предсказуемой производительности в масштабе – объединили усилия с Memcached, чтобы сравнить обе технологии друг с другом, в сотрудничестве с нейтральным поставщиком. Результаты показывают, что: И Memcached, и ScyllaDB максимизировали пропускную способность дисков и сетевой пропускной способности при одновременном стрессе в аналогичных условиях, поддерживая аналогичную производительность в целом. В то время как ScyllaDB требовал изменений в моделировании данных, чтобы полностью насытить пропускную способность сети, Memcached требовал дополнительных нитей IO, чтобы насытить I/O диска. Хотя ScyllaDB показал лучшие задержки по сравнению с Memcached трубопроводных запросов на диск, Memcached задержки были лучше для отдельных запросов. Этот документ объясняет нашу мотивацию для этих тестов, предоставляет резюме проверенных сценариев и результатов, а затем представляет рекомендации для всех, кто может принимать решение между ScyllaDB и Memcached. Есть также с более широким взглядом на тесты и результаты и ссылки на конкретные конфигурации, которые вы можете использовать для выполнения тестов самостоятельно. подробный Gitbook для этого проекта, Бонус: я и dormando недавно обсуждали этот проект на P99 CONF, высокотехнической конференции по производительности и низкой задержке. Следите за спросом Бонус: я и dormando недавно обсуждали этот проект на P99 CONF, высокотехнической конференции по производительности и низкой задержке. Watch on demand Следите за спросом Почему мы это сделали? Прежде всего, ScyllaDB инвестировала много времени и инженерных ресурсов в оптимизацию нашей базы данных, чтобы обеспечить предсказуемые низкие задержки для приложений с большим количеством данных в реальном времени. Архитектура ничего не делится, и (полностью обходить кеш страницы Linux) являются некоторыми заметными примерами таких оптимизаций. Шард-Пер-Кор Расписание пользовательского пространства I/O Внутренняя реализация кеша Во-вторых: производительность с течением времени сближается. Кэши в памяти (в течение длительного времени) считаются одним из самых быстрых компонентов инфраструктуры. Тем не менее, прошло несколько лет с тех пор, как решения кэширования начали рассматривать область флэш-дисков. If an in-memory cache can rely on flash storage, then why can’t a persistent database also work as a cache? В-третьих, мы уже обсуждали и недавно исследовали, насколько конкретные команды успешно . 7 причин не ставить кэш перед базой данных Заменить кеш на ScyllaDB Четвертое: На прошлогодней конференции P99 CONF Дэнни Коппинг дал нам просвещающую речь, , где он объяснил, как Memcached Extstore помог Grafana Labs масштабировать свой кэш-печать в 42 раза, одновременно снижая затраты. Скрывай меня, если сможешь И, наконец, несмотря на (достоверную) критику, которую получают показатели производительности, они по-прежнему играют важную роль в стимулировании инноваций. Теперь перейдем к сравнению. Настройка инстанций Тесты проводились с использованием следующих типов инстанций AWS: Загрузчик: c7i.16xlarge (64 vCPU, 128 ГБ оперативной памяти) Memcached: i4i.4xlarge (16 vCPUs, 128GB RAM, 3.75TB NVMe) ScyllaDB: i4i.4xlarge (16 vCPUs, 128GB RAM, 3.75TB NVMe) Все органы могут доставлять Имейте в виду, что, особенно во время тестов, максимизирующих обещанную сетевую пропускную способность, мы заметили . Вверх Уменьшение пропускной способности до базовой емкости инстанций Оптимизация и настройки Для преодоления потенциальных барьеров были применены следующие оптимизации и настройки: Все инстанции использовали стратегию размещения кластеров, следуя AWS Docs: «Эта стратегия позволяет нагрузкам достигать производительности сети с низкой задержкой, необходимой для тесно связанной связи между узлами, которая характерна для высокопроизводительных вычислительных (HPC) приложений». Memcached: Версия 1.6.25, компилированная с Extstore включен. За исключением того, где обозначено, запускается с 14 нитями, прикрепленными к конкретным процессорам. Остальные 2 vCPU были присвоены CPU 0 (core & HT sibling) для обработки сетевых IRQ, как указано в режиме sq_split в seastar perftune.py. Операции CAS были отключены, чтобы сэкономить место на каждом элементе. Полные аргументы командной строки были:taskset -c 1-7,9-15 /usr/local/memcached/bin/memcached -v -A -r -m 114100 -c 4096 -lock-memory -threads 14 - scylla -C ScyllaDB: настройки по умолчанию, настроенные ScyllaDB Enterprise 2024.1.2 AMI (ami-id: ami-018335b47ba6bdf9a) в i4i.4xlarge. Стрессоры Для загрузочных устройств мы использовали , часть официального комплекта тестов memcached. Применимые профили подчеркивания находятся в Репозитории GitHub. McShredder Фэй-Мендес / Шредеры Для ScyllaDB мы использовали , как отправлен с ScyllaDB, и указал сопоставимые рабочие нагрузки, как те, которые используются для Memcached. Кассандра стресс Тесты и результаты Ниже приведено резюме проведенных нами тестов и их результатов.Если вы хотите более подробное описание и анализ, перейдите на . Расширенный текст этого проекта Эффективность оперативной памяти RAM Чем больше элементов вы можете поместить в оперативную память, тем лучше ваши шансы получить кэш-хиты.Более кэш-хитов приводят к значительно более быстрому доступу, чем к диску. Этот проект начался с измерения количества элементов, которые мы могли бы хранить в каждом хранилище данных. Во время наших тестов ключ составлял от 4 до 12 байтов (key0 .. keyN) для Memcached, и 12 байтов для ScyllaDB. Мемориал Memcached хранил примерно 101 млн предметов, пока не началось выдворение.Это эффективная память.Из присвоенной памяти Memcached 114G это примерно 101G ценностей, не учитывая размер ключа и другие флаги: ScyllaDB Это не удивительно, учитывая, что его протокол требует больше данных для хранения в составе записи (например, временная отметка для записи с эпохи, продолжительность жизни ряда и т.д.). Takeaways Memcached хранит на 65% больше элементов в памяти, чем ScyllaDB. Ряды ScyllaDB имеют более высокую верхнюю часть на элемент для поддержки широкой ориентации колонны. В ScyllaDB Bloom Filters, Index Caching и другие компоненты также хранятся в памяти для поддержки эффективных поисков дисков, что способствует еще одному слою перекрытия. Рабочая нагрузка In-Memory только для чтения ТЭ (Хотя нереалистичная) рабочая нагрузка для кэша - это та, где все данные вписываются в оперативную память - так что чтения не требуют доступа к диску и не возникают отключения или промахивания.И ScyllaDB, и Memcached используют логику LRU (Last Recently Used) для освобождения памяти: когда система работает под давлением, элементы выводятся из хвоста LRU; это, как правило, наименее активные элементы. Идеальный Удаление отключений и пропусков кэша из изображения помогает измерить и установить базовую величину производительности для обоих хранилищ данных. Он фокусируется на том, что самое важное для этих видов нагрузок: пропускная способность и задержка запроса. В этом тесте мы сначала подогрели оба магазина с одинаковыми размерами полезной нагрузки, используемыми во время предыдущего теста. Memcached Memcached достиг впечатляющих 3 миллионов Gets в секунду, полностью максимизируя пропускную способность AWS NIC (25 Гбит/с)! Memcached поддерживает стабильный 3M rps, полностью максимизируя пропускную способность NIC Парсеты показывают, что p99.999 ответов завершенных ниже 1ms: Результаты Статьи в cmd_get: Общий объем операций: 5503513496 Скорость: 3060908/с === Время в мг === 1-10С 0 0 000% 10-99us 343504394 6,238% 100-999us 5163057634 93.762% 1-2 мс 11500 0.00021% ScyllaDB Чтобы читать больше строк в ScyllaDB, нам нужно было разработать лучшую модель данных для запросов клиента из-за особенностей протокола (в частности, без трубопровода).С кластерным ключом мы могли полностью максимизировать кеш ScyllaDB, что привело к значительному улучшению количества кешных строк. В результате количество записей в кэше значительно улучшилось по сравнению с показаными ранее номерами ключевых значений. Как правильно указал dormando (спасибо!), эта конфигурация значительно отличается от предыдущей настройки Memcached.В то время как рабочая нагрузка Memcached всегда попадает на отдельную пару ключевых значений, одно запрос в ScyllaDB приводит к возвращению нескольких строк. Мы объяснили причины этих изменений. Там мы охватывали характеристики протокола CQL (такие как перекрытие на элемент [по сравнению с memcached] и отсутствие поддержки трубопроводов), которые делают широкие разделы более эффективными на ScyllaDB, чем одноключевые сборы. В детальном письме С помощью этих корректировок наши загрузчики выполняли в общей сложности 187 000 операций чтения в секунду в течение 30 минут. Подобно memcached, ScyllaDB также максимизировал пропускную способность NIC. Он обслуживал примерно 3 млн строк в секунду исключительно из данных в памяти: ScyllaDB раскрывает информацию о задержке на стороне сервера, которая полезна для анализа задержки без сети.Во время тестирования, задержка на стороне сервера p99 ScyllaDB оставалась в пределах 1ms: Неудивительно, что процентилы на стороне клиента выше, чем латентность на стороне сервера при прочтении P99 0,9 мс. Takeaways И Memcached, и ScyllaDB полностью насыщали сеть; чтобы предотвратить насыщение максимальных сетевых пакетов в секунду, Memcached полагался на запрашивание трубопроводов, в то время как ScyllaDB переключился на широкую колонну. Кэш ScyllaDB продемонстрировал значительные улучшения в соответствии с широкой колонной схемой, способной хранить больше элементов по сравнению с предыдущей простой ориентацией ключевых значений. На уровне протокола протокол Memcached проще и легче, в то время как CQL ScyllaDB обеспечивает более богатые функции, но может быть более тяжелым. Добавление дисков к изображению Измерение производительности флэш-памяти вводит свой собственный набор задач, что делает практически невозможным полностью реалистично характеризовать данную нагрузку. Для тестов, связанных с дисками, мы решили измерить наиболее пессимистичную ситуацию: сравнить оба решения, обслуживающие данные (в основном) из блок-хранилища, зная, что: Вероятность реалистичных рабочих нагрузок, делающих это, где-то близка к нулю Пользователи должны ожидать цифры между предыдущей оптимистической рабочей нагрузкой кэша и пессимистической рабочей нагрузкой на диске на практике Memcached Extstore ТЭ На высоком уровне он позволяет memcached сохранять свою хеш-таблицу и ключи в памяти, но хранить значения на внешнем хранилище. Экстраординарная страница Wiki Во время наших тестов мы наполнили memcached 1,25B элементами с размером значения 1KB и размером клавиши до 14 байтов: С Extstore мы хранили около 11X количества элементов по сравнению с предыдущей рабочей нагрузкой в памяти, пока не начали запускаться отключения (как показано на панели правой руки на изображении выше). Read-Only Performance Для фактических тестов производительности мы подчеркнули Extstore против размеров элементов 1KB и 8KB. Таблица ниже подводит итоги: Test Type Items per GET Payload Size IO Threads GET Rate P99 perfrun_metaget_pipe 16 1KB 32 188K/s 4~5 ms perfrun_metaget 1 1KB 32 182K/s <1ms perfrun_metaget_pipe 16 1KB 64 261K/s 5~6 ms perfrun_metaget 1 1KB 64 256K/s 1~2ms perfrun_metaget_pipe 16 8KB 16 92K/s 5~6 ms perfrun_metaget 1 8KB 16 90K/s <1ms perfrun_metaget_pipe 16 8KB 32 110K/s 3~4 ms perfrun_metaget 1 8KB 32 105K/s <1ms метеопроцедуры / Metaget_pipe 16 1кб 32 188 к/с 4 - 5 мс Металлург - Металлург 1 1кб 32 182 К/с < 1 мс метеопроцедуры / Metaget_pipe 16 1кб 64 261 К/с 5 - 6 мс Металлург - Металлург 1 1кб 64 256 к/с 1 - 2 мс метеопроцедуры / Metaget_pipe 16 8кб 16 92 к/с 5 - 6 мс Металлург - Металлург 1 8кб 16 90 к/с < 1 мс метеопроцедуры / Metaget_pipe 16 8кб 32 110 к/с 3 - 4 мс Металлург - Металлург 1 8кб 32 105 к/с < 1 мс ScyllaDB Мы наполнили ScyllaDB тем же количеством элементов, что и для memcached.Хотя ScyllaDB показал более высокие ставки GET, чем memcached, он сделал это при немного более высоких задержках хвоста по сравнению с рабочими нагрузками, не связанными с трубопроводами memcached. Test Type Items per GET Payload Size GET Rate Server-side P99 Client-side P99 1KB Read 1 1KB 268.8K/s 2ms 2.4ms 8KB Read 1 8KB 156.8K/s 1.54ms 1.9ms 1кб читать 1 1кб 268 К/с 2 мс 2,4 мс 8кб читать 1 8кб 156.8 К/с 1,45 мс 1.9 МС Takeaways Extstore требовал значительного настройки своих настроек, чтобы полностью насытить I/O флэш-хранилища. Из-за архитектуры Memcached более мелкие платные нагрузки не могут в полной мере использовать доступное дисковое пространство, обеспечивая меньшие выгоды по сравнению с ScyllaDB. Коэффициенты ScyllaDB в целом были выше, чем у Memcached в ориентации ключевых значений, особенно при более высоких размерах полезной нагрузки. Переписывайте рабочую нагрузку Исходя из наших предыдущих результатов Disk, мы затем сравнили оба решения в рабочей нагрузке с большей частью чтения, нацеленной на одинаковую пропускную способность (250K ops/sec). , с 10% случайных переписей. Это считается «полухудшим сценарием». «Основный» тест для Extstore Memcached Memcached достиг скорости чуть ниже 249K во время теста.Хотя скорость записи оставалась стабильной на протяжении всего теста, мы заметили, что показатели немного колебались. : На протяжении всего бега Мы также наблюдали небольшое увеличение метрики, несмотря на пониженные коэффициенты чтения, но задержки по-прежнему оставались низкими. extstore_io_queue Выберите Operation IO Threads Rate P99 Latency cmd_get 64 224K/s 1~2 ms cmd_set 64 24.8K/s <1ms ЦМД - получает 64 224 К/с 1 - 2 мс CMD - набор 64 24,8 К/с < 1 мс ScyllaDB Несмотря на то, что ScyllaDB достиг немного более высокой пропускной способности (259.5K), задержки написания сохранялись низкими на протяжении всего запуска, а задержки чтения были более высокими (подобно memcached): Ниже приведенная таблица подводит итоги выполнения на стороне клиента между двумя загрузчиками: Loader Rate Write P99 Read P99 loader1 124.9K/s 1.4ms 2.6 ms loader2 124.6K/s 1.3ms 2.6 ms Loader1 124,9 К/с 1.4 МС 2.6 МС лоукостер2 124,6 К/с 1.3 МС 2.6 МС Takeaways Как Memcached, так и ScyllaDB были стабильными, с незначительными колебаниями в пробеге. ScyllaDB по-прежнему пишет отчет о commitlog overhead, который сидит в горячей дороге написания Задержки на стороне сервера ScyllaDB были похожи на те, которые наблюдались в результатах Memcached, хотя задержки на стороне клиента были немного выше. Читайте более подробный анализ в Gitbook для этого проекта Вверх Вверх И memcached, и ScyllaDB сумели максимизировать использование основного аппаратного обеспечения во всех тестах и держать задержки предсказуемо низкими. Если ваша существующая рабочая нагрузка может вместить простую модель ключевых значений и она выигрывает от трубопровода, то memcached должен быть более подходящим для ваших потребностей. Еще одна причина придерживаться Memcached: он легко доставляет трафик далеко за пределы того, что может поддерживать NIC. , dormando упомянул, что он может масштабировать его до 55 миллионов прочитанных операций в секунду для значительно большего сервера.Учитывая это, вы можете использовать меньшие и / или более дешевые типы инстанций, чтобы поддерживать аналогичную нагрузку, при условии, что доступная память и отпечаток диска достаточны для ваших потребностей в нагрузке. Хакерские новости thread Другим углом для рассмотрения является размер набора данных. Несмотря на то, что Extstore обеспечивает большую экономию затрат, позволяя вам хранить элементы за пределами оперативной памяти, есть ограничение на то, сколько ключей может поместиться на ГБ памяти. Рабочие нагрузки с очень маленькими элементами должны наблюдать меньшие выгоды по сравнению с теми, с более крупными элементами. Если это так, то запуск ScyllaDB в качестве реплицированного распределенного кэша обеспечивает вам большую устойчивость и бесперебойные операции, с компромиссом быть (и как К сожалению, Extstore не поддерживает теплые перезагрузки и, таким образом, неудача или обслуживание одного узла склонны повышать коэффициент пропущенности кэша.Если это приемлемо или нет, зависит от семантики вашего приложения: Если пропущенный кэш соответствует круглой поездке в базу данных, то задержка от конца до конца будет моментально выше. Правильно зафиксированные государства Что касается последовательного хеширования, memcached-клиенты отвечают за распределение ключей на ваших распределенных серверах. Это может привести к некоторым взломам, так как различные конфигурации клиентов приведут к тому, что ключи будут присваиваться по-разному, а некоторые реализации могут не совместимы друг с другом. ScyllaDB использует другой подход: последовательное хеширование выполняется на уровне сервера и распространяется на клиентов при первом установлении соединения. Memcached's Configuring Клиент wiki Так что кто выиграл (или кто проиграл)? Ну... Это не обязательно должно быть соревнование, а также не исчерпывающий список, описывающий каждое отдельное рассмотрение для каждого решения. И ScyllaDB, и memcached используют различные подходы для эффективного использования основной инфраструктуры. Мы были рады видеть, что ScyllaDB соответствует цифрам индустриально признанного Memcached. Конечно, у нас не было ожиданий, что наша база данных будет «быстрее».
