Как стать автором
Обновить

Мёртв ли последовательный ввод-вывод в эпоху накопителей NVMe?

Уровень сложностиСредний
Время на прочтение9 мин
Количество просмотров7.7K
Всего голосов 46: ↑46 и ↓0+46
Комментарии7

Комментарии 7

Очень интересно. А как SSD относятся к MDF и LDF файлам баз? В конце концов, традиционные базы как раз были оптимизированы под последовательный IO куда раньше Кафок

Внутри у них все равно страничная организация и прямой доступ к страницам. Раз речь явно про MS SQL - страницы по 8К. А то, что сервер пытается оптимизировать ввод-вывод пытаясь читать и записывать сразу группу смежных страниц - для SSD только к лучшему.

Но на SSD уже не имеет значение фрагментированность этих файлов. Можно хоть по 64МБ по умолчанию оставлять для прироста.

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

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

Для SSD давно есть специальный протокол TRIM, по которому ему сообщают об удалении файлов. И да, этот протокол нарушает некие логические принципы построения систем снизу вверх...

Пришла в голову интересная мысль, что, помимо SSD и HDD, сейчас появился ещё один, третий класс устройств, которые я назвал бы устройствами с искусственными ограничениями, где реальная производительность не имеет ничего общего с физикой и объектами реального мира, а зависит лишь от SLA облачного провайдера. К примеру, это EBS и S3. Интересно, какие принципы надо закладывать, чтобы оптимизировать софт под них

TLDR: сегодня задача превращения произвольной записи в последовательную лежит на контроллере SSD-диска. Но решается она не бесплатно.

Что в статье толком не рассмотрено: во многих случаях требование последовательной записи исходит из оптимизации процесса чтения. Если, допустим, видеофайл будет разбросан мелкими кусками по всей поверхности HDD диска, при чтении этот самый диск может тупо не успеть шевелить своими головками. У SSD этой проблемы нет и задачи последовательной записи соответственно тоже нет.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий