Хранилище с ключевыми значениями с низкой задержкой для SSD

Мы работаем над решением ключевого значения с поддержкой SSD со следующими свойствами:

  • Пропускная способность: 10000 TPS; 50/50 ставит/получает;
  • Задержка: 1 мс, 99,9% процентиль 10 мс
  • Объем данных: ~ 1 млрд. значений, ~ 150 байт каждый; 64-битные ключи; произвольный доступ, 20% данных соответствует ОЗУ.

Мы попробовали KyotoCabinet, LevelDB и RethinkDB на товарных SSD, с различными планировщиками IO Linux, файловыми системами ext3/xfs; сделал ряд тестов, используя Rebench; и обнаружил, что во всех случаях:

  • Доступность только для чтения/задержка очень хорошие.
  • Запись/обновление только во всех случаях умеренная, но есть много высокоуровневых выбросов
  • Смешанная рабочая нагрузка чтения/записи приводит к катастрофическим колебаниям в пропускной способности/задержке даже в случае прямого доступа к блочному устройству (в обход файловой системы).

На приведенном ниже рисунке показано такое поведение для KyotoCabinet (горизонтальная ось - это время, три периода четко видны - только для чтения, смешанные, только обновление).

Возникает вопрос: возможно ли достичь низкой латентности для описанных SLA с использованием SSD и какие хранилища значений ключа рекомендуется?

enter image description here

ОТВЕТЫ

Ответ 1

Высокий вариант задержки записи является общим атрибутом SSD (особенно потребительских моделей). Существует довольно хорошее объяснение, почему в этом обзоре AnandTech.

Резюме состоит в том, что производительность записи SSD ухудшает сверхурочную работу, так как увеличивается накладные расходы на износ. По мере уменьшения количества свободных страниц на диске контроллер NAND должен начать дефрагментацию страниц, что способствует задержке. NAND также должен построить LBA для блокировки карты для отслеживания случайного распределения данных по различным блокам NAND. По мере роста этой карты операции на карте (вставки, удаления) будут замедляться.

Вы не сможете решить проблему HW низкого уровня с помощью подхода SW, вам нужно либо перейти на SSD на уровне предприятия, либо уменьшить ваши требования к задержке.

Ответ 2

Aerospike - это новое хранилище ключей/значений (строк), которое может полностью отходить от SSD с < 1 мс для чтения/записи и очень высокого TPS (до миллиона).

У SSD есть большой случайный доступ для чтения, но ключ к уменьшению дисперсии при записи - это использование последовательного ввода-вывода (это похоже на обычные жесткие диски). Он также значительно снижает уровень износа и затухания, что может произойти при большом количестве записей на SSD.

Если вы создаете свою собственную систему ценностей, используйте подход, основанный на логике (например, Aerospike), чтобы записи были навалом и добавлены/написаны большими кусками. Индекс в памяти может поддерживать правильные местоположения данных для значений, в то время как фоновый процесс очищает устаревшие/удаленные данные с диска и файлы дефрагментации.

Ответ 3

Это своего рода загадочная идея, но она МОЖЕТ работать. Предположим, что ваш SSD составляет 128 ГБ.

  • Создайте раздел подкачки 128 ГБ на SSD
  • Настройте свой компьютер для использования в качестве свопа
  • Настроить memcached на компьютере и установить ограничение на 128 ГБ памяти
  • Benchmark

Может ли ядро ​​быстро входить и выгружать страницы? Не знаю. Это больше зависит от вашего оборудования, чем от ядра.

Poul-Henning Kamp делает что-то очень похожее на это в Varnish, заставляя ядро ​​отслеживать вещи (виртуальную или физическую память) для Varnish, а не делать лак. https://www.varnish-cache.org/trac/wiki/ArchitectNotes

Ответ 4

NuDB специально разработан для вашего случая использования. Он имеет O (1) вставку и поиск, независимо от размера базы данных. В настоящее время он отвечает потребностям файла данных объемом 9 ТБ (9 терабайт). Библиотека с открытым исходным кодом, только заголовки и требует только С++ 11 https://github.com/CPPAlliance/NuDB