Scylladb спонсировал этот пост.
Хотя кэши и базы данных были созданы для совершенно разных целей, границы размыты. Механизмы внутреннего кэширования баз данных становятся все более эффективными — и кэши все чаще используют хранение дисков, а не полагаются исключительно на ОЗУ. Так имеет ли смысл заменить ваш кэш на постоянную базу данных? Чтобы расширить пространство памяти кэша на флэш -память? И как далеко вы можете разумно протолкнуть каждое за пределы его первоначальных намерений, учитывая силу и ограничения ее базовой архитектуры?
Недавно я присоединился к усилиям с Memcached Savingerser Аланом Касиндорфом (он же Дормандо), чтобы изучить эти вопросы. Сотрудничество началось с цели теста «яблоки с апельсинами», сравнивающего Scylladb с Memcached, который рассматривается в статье: «Мы сравнили Scylladb и Memcached и… мы проиграли?» Несколько месяцев спустя мы были приятно удивлены, что звезды выровнены для P99 Conf. В последнюю минуту Касиндорф смог присоединиться к нам, чтобы поболтать о проекте-в частности, что все это значит для разработчиков с чувствительными к производительности вариантов использования.
Примечание: P99 Conf-это техническая конференция по производительности и инженерии с низкой задержкой. Это виртуально, бесплатно и очень интерактивно. Повестка дня в этом году охватывает ржавчину, Zig, Go, C ++, Compute/Infrastructure, Linux, Kubernetes и базы данных. Присоединяйтесь к нам, чтобы учиться у инженеров Nvidia, Uber, Pinterest, Netflix, Wayfair, Amazon Prime Video, Paypal, Disney и других.
Вот посмотрите на некоторые из ключевых различий, которые мы обсуждали.
Эффективность кэша
Какой хранилище данных использует память более эффективно? Чтобы проверить это, мы запустили простую рабочую нагрузку на ключевую стоимость в обеих системах. Результаты:
- Memcached кэшировал 101 миллион предметов до начала выселения.
- Scylladb кэшировал всего 61 миллион предметов до выселения.
Сравнение эффективности кэша. Смотрите видео для большего изображения.
Что стоит за разницей? Scylladb также имеет свой собственный наименьший в последнее время используемый (LRU) кэш, который обходит кэш Linux. Но в отличие от Memcached, Scylladb поддерживает ширококонкурентное представление данных: один ключ может содержать много строк. Это, наряду с дополнительными накладными расходом протокола, заставляет одну запись в Scylladb потреблять больше места, чем запись в Memcached.
Бурая в различиях, Memcached имеет очень мало накладных расходов на каждого объекта. В примере из приведенного выше изображения каждый сохраненный элемент потребляет 48 или 56 байтов, в зависимости от того, включено ли сравнение и обмен (CAS). Напротив, Scylladb должен справиться с гораздо большим количеством (в конце концов, это постоянная база данных!). Ему необходимо выделить пространство для своих мемтабли, фильтров цветов и резюме SSTABLE, чтобы оно могло эффективно извлекать данные с диска, когда происходит пропуску кэша. Кроме того, Scylladb поддерживает гораздо более богатую модель данных (широкий столбец).
Другое заметное архитектурное различие выделяется в фронте производительности: Memcached оптимизирован для оправы (например, пакетирование, как в DynamoDB BatchgetiTem), что значительно уменьшило количество обработков по сети для извлечения нескольких ключей. SCYLLADB оптимизирован для одиночных (и смежных) поисков ключей под ширококонкурентным представлением.
Сравнение эффективности в памяти только для чтения. Смотрите видео для большего изображения.
Следуя идеальной модели данных каждой системы, как SCYLLADB, так и Memcached удалось насыщать доступную сеть пропускной способности, обслуживая около 3 миллионов строк/с при одновременном задерже к однозначному миллисекунду Millisecond P99.
Диски и эффективность ввода/вывода
Затем фокус перешел на диски. Мы измерили производительность в разных размерах полезной нагрузки, а также то, как эффективно каждая из систем может максимизировать базовое хранилище.
С Extstore и небольшими (1K) полезными нагрузками Memcached сохранял примерно в 11 раз больше предметов (по сравнению с рабочей нагрузкой в памяти) до начала выселения, оставив значительную часть свободного доступного дискового пространства. Это происходит потому, что в дополнение к регулярным накладным расходам на ключ Memcached хранит еще 12 байт на элемент в оперативной памяти в качестве указателя на хранение. По мере того, как RAM истощается, Extstore больше не эффективен, и пользователи больше не будут наблюдать за экономией за ее пределами.
Производительность диска с сравнением небольших полезных нагрузок. Смотрите видео для большего изображения.
Для фактических испытаний на производительность мы подчеркнули выборы по размерам элементов 1 КБ и 8 КБ. В таблице ниже приведены результаты:
Тип теста
Размер полезной нагрузки
Темы ввода/вывода
Получить ставку
P99 задержка
perfrun_metaget_pipe 1kb 32 188k/s 4 ~ 5 мс perfrun_metaget 1kb 32 182k/s <1ms perfrun_metaget_pipe 1kb 64 261k/s 5 ~ 6 мс perfrun_metaget 1kb 64 256k/s 1 ~ 2m perfrun_metaget 8kb 16 90k/s <1ms perfrun_metaget_pipe 8kb 32 110k/s 3 ~ 4 мс perfrun_metaget 8kb 32 105k/s <1ms
Мы заполнили Scylladb тем же количеством элементов, что и для Memcached. SCYLLADB фактически достиг более высокой пропускной способности — и чуть более высокой задержки — чем Extstore. Я почти уверен, что если бы пропускная способность была уменьшена, задержка была бы ниже. Но даже без настройки производительность довольно сопоставима. Это суммировано ниже:
Тип теста
Размер полезной нагрузки
Получить ставку
Серверная сторона P99
Клиентская сторона P99
1 КБ считывает 1KB 268,8K/с 2 мс 2,4 мс 8 КБ. Читать 8KB 156,8K/с 1,54 мс 1,9 мс.
Несколько примечательных моментов из этих тестов:
- Extore требует значительной настройки для полного насыщения ввода/вывода хранения вспышки.
- Из -за архитектуры Memcached меньшие полезные нагрузки не могут полностью использовать доступное дисковое пространство, обеспечивая меньшие выгоды по сравнению с Scylladb.
- Ставки SCYLLADB были в целом выше, чем MEMCACHED в ориентации на ключевую стоимость, особенно при более высоких размерах полезной нагрузки. Задержки были лучше, чем просьбы, но немного выше, чем человек, получает в Memcached.
Обсуждение методов доступа ввода/вывода
Эти ориентированные на диск тесты не удивительно вызвали дискуссию о различных методах доступа ввода/вывода, используемых Scylladb против Memcached/Extstore.
Я объяснил, что Scylladb использует асинхронный прямой ввод -вывод. Для обширного обсуждения этого прочитайте этот пост нашего блога нашего технического директора и соучредителя Avi Kiant. Вот короткая версия: Scylladb — это постоянная база данных. Когда люди принимают базу данных, они по праву ожидают, что она сохранит их данные. Таким образом, прямой ввод -вывод является преднамеренным выбором. Он обходит кэш страниц ядра, предоставляя Scylladb полный контроль над операциями дисков. Это важно для таких вещей, как уплотнения, журналы с надписью и эффективное чтение данных с диска.
Также участвует планировщик ввода-вывода пользователя. Он живет посередине и решает, какая операция получает, сколько пропускной способности ввода/вывода. Это может быть задача внутреннего уплотнения или запрос, обращенный к пользователю. Это арбитражает между ними. Это то, что позволяет Scylladb сбалансировать постоянство работать с чувствительными к задержкой операций.
Extstore использует совершенно другой подход: держите вещи максимально простыми и избегайте прикосновения к диску, если это не абсолютно необходимо. Как сказал Касиндорф: «Мы почти ничего не делаем». Это полностью намеренно. Большинство операций — например, удаления, обновления TTL или перезаписывание — могут произойти полностью в памяти. Доступ к диску не требуется. Так что Extstore не беспокоит планировщик.
Без планировщика настройка производительности Extstore является ручным. Вы можете изменить количество потоков ввода -вывода Extstore, чтобы улучшить использование. Если вы сверните его и заметите, что ваш диск не выглядит полностью используемым — и у вас все еще есть много запасного процессора — вы можете увеличить количество потоков. Касиндорф упомянул, что в какой-то момент он, вероятно, станет самостоятельной настройкой. Но сейчас это ручка, которую пользователи могут настроить.
Другая важная часть заключается в том, как Extstore наносит на себя на вершину существующего оперативного кеша Memcacched. Это не замена; Это добавка. У вас все еще есть кэш в памяти, а Extresh-только переполнение.
Вот как Касиндорф объяснил это: «Если у вас, скажем, пять концертов оперативной памяти, и один концерт этого посвящен этим маленьким указателям, которые указывают из памяти на диск, у нас все еще остается пара дополнительных концертов для кеша RAM». Это означает, что если пользователь активно нажимает, его данные могут даже не перейти на диск. Единственное время времени, возможно, нужно читать с диска, — это когда кэш простудился (например, пользователь, возвращающийся на следующий день). Затем записи втянуты обратно.
По сути, в то время как Scylladb строится вокруг постоянного, высокопроизводительного ввода-вывода (с планированием, прямого контроля и долговечного хранения), Extstore почти наоборот. Это легкий, минимальный и пытается полностью избежать диска, если это не должно.
Заключение и вынос
В этих и других тестах, которые мы выполнили в полном эталонном этапе, Memcached и Scylladb оба сумели максимизировать базовое использование аппаратного обеспечения и сохранить задержку, как предсказуемо низок. Итак, какой из них вы должны выбрать? Реальный ответ: это зависит.
Если ваша существующая рабочая нагрузка может приспособить простую модель ключевой стоимости, и она выигрывает от трубопровода, то Memcached должен быть более подходящим для ваших потребностей. С другой стороны, если рабочая нагрузка требует поддержки сложных моделей данных, то SCYLLADB, вероятно, лучше подходит.
Другая причина придерживаться Memcached: он легко доставляет трафик далеко за пределы того, что может выдержать карта сетевой интерфейсы. Фактически, в этой хакерской новостной теме Дормандо упомянул, что может масштабировать его за 55 миллионов чтений/секунды для значительно большего сервера. Учитывая это, вы можете использовать более мелкие и/или более дешевые типы экземпляров, чтобы поддерживать аналогичную рабочую нагрузку, при условии, что доступная память и диск соответствуют вашим потребностям рабочей нагрузки.
Другой угол, который следует учитывать, — это размер набора данных. Несмотря на то, что Extstore обеспечивает отличную экономию затрат, позволяя хранить предметы за пределами оперативной памяти, существует ограничение, сколько клавиш может соответствовать на гигабайт памяти. Рабочие нагрузки с очень мелкими предметами должны наблюдать за меньшими успехами по сравнению с тем, что с более крупными предметами. Это не тот случай с Scylladb, который позволяет хранить миллиарды предметов независимо от их размеров.
Также важно подумать о том, требуется ли стойкость данных. Если это так, то запуск SCYLLADB в качестве реплицированного распределенного кэша обеспечивает вам большую устойчивость и безостановочные операции, причем компромисс (и, как правило, правильно утверждает), которые репликация вдвое увеличивает ваш эффективный размер кэша. К сожалению, Extstore не поддерживает теплые перезагрузки, и, следовательно, сбой или поддержание одного узла склонны к повышению коэффициентов пропуска кэша. Является ли это приемлемым, зависит от вашей семантики вашего приложения: если промаха кэша соответствует обращению к базе данных, то сквозная задержка на мгновение будет на мгновение выше.
Независимо от того, выбираете ли вы кэш, такой как Memcached или база данных, такую как Scylladb, я надеюсь, что эта работа вдохновляет вас по -разному думать о тестировании производительности. Как мы видели, базы данных и кэши в корне разные. И в конце концов, просто сравнения номеров производительности недостаточно.
Более того, признайте, что трудно полностью представить реальность вашей системы с помощью простых критериев, и каждая оптимизация имеет некоторые компромиссы. Например, трубопроводы великолепны, но, как мы видели с Extstore, он может легко представить конфликт ввода/вывода. Модель Scylladb Shard-Per-Core и поддержка сложных моделей данных также являются мощными, но они также поставляются с затратами, например, потерять некоторую гибкость трубопровода и добавление накладных расходов на память.
Scylladb разработан для обеспечения предсказуемой производительности в масштабе. Он принят организациями, которые требуют ультра-низкую задержку, даже с рабочими нагрузками, превышающими 1M OPS/SEC. Наша уникальная архитектура использует силу современной инфраструктуры — переводится на меньшее количество узлов, меньшую административную и снижающую затраты. Узнайте больше последних из Scylladb Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Felipe Cardeneti Mendes является ИТ -специалистом с многолетним опытом работы в распределенных системах и технологиях с открытым исходным кодом. Он является соавтором Three Linux Books и является частым оратором на публичных мероприятиях и конференциях для продвижения технологий с открытым исходным кодом …. Подробнее от Felipe Cardeneti Mendes
