Каковы последствия использования SSD для фундаментальных предположений базы данных?

SSD теперь обычны; Amazon EBS поддерживается SSD, и поэтому большинство облачных баз данных теперь также работают на SSD (Heroku PostgreSQL и т.д.). Базы данных и связанные с ними архитектуры традиционно были разработаны с идеей о том, что случайный доступ плох - это больше не относится к SSD.

Как работают SSD следующие?

Конструкция базы данных - БД предназначены для минимизации обращений к диску (WAL, B-деревья). Как SSD меняют внутренности и настраивают дизайн БД?
Разработка приложений. Рабочее предположение всегда состояло в том, что (а) вы хотите, чтобы серверные пользователи запрашивали информацию из памяти, а не БД, и (2), что доступ к БД связан с IO. С помощью SSD извлечение данных из БД может быть достаточно быстрым, а доступ к БД часто связан с сетью. Уменьшает ли это необходимость в базах данных в памяти? Очевидно, что вы все еще хотите предварительно вычислить дорогостоящие операции, но вы можете просто сохранить их в DB
Специализированные базы данных. Существует довольно много БД, которые делают вещи, которые, по-видимому, несут реляционные БД (частично из-за случайного доступа к данным). Один из таких примеров - это графы DB (Neo4j), которые хранят узлы и списки смежности на диске в компактном виде. Являются ли эти базы данных полезными, если мы можем развернуть СУБД на SSD и не беспокоиться о случайном доступе?

Ответ 1

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

WAL будет очень дорогим на SSD, если SSD по-настоящему покраснет его на основной носитель, но это не так. Он накапливает его в кэше обратной записи, и периодичность сбрасывает его во всех фрагментах размером с стирание. Таким образом, WAL действительно хорошо работает на SDD, так как никогда не требуется цикл чтения/изменения/записи для частичной записи блока стирания.

Я уверен, что в хранилище древовидной структуры есть возможности для индексов на SSD. Это не то, что мы действительно изучили в PostgreSQL.

Большинство серверов баз данных на базе SSD, с которыми я работаю, остаются полностью привязанными к вводу-выводу диска для нормальной работы. SSD бывают быстрыми, но не волшебными. Даже интегрированные SSD-модули PCI-E не могут конкурировать с ОЗУ, а большие рабочие нагрузки имеют тенденцию к быстрому насыщению кэша обратной записи SSD и очередей.

Аналогично, перемещение списка смежности в СУБД по-прежнему далека от свободного в вычислительных терминах, представление на диске менее компактно, чем в графе DB и т.д. Там, где вам это нужно, многое можно получить от специализации.

Чтобы действительно посмотреть, что делает ультрабыстрое хранилище для БД, вам нужно сделать еще один шаг и посмотреть на устройства хранения на базе PCIe RAM, которые безумно, смешно быстро.

Кстати, SSD не так сильно отличается от SCSI HBA с большим кэшем записи с батареей. Они существуют уже давно. SSD будет иметь тенденцию иметь лучшие случайные чтения, но в остальном это очень похоже.