Являются ли тома docker лучшим вариантом для записи тяжелых операций, чем привязка каталогов напрямую?

Question

Прочитав docker документацию, я нашел этот отрывок (расположен здесь ):

Драйверы хранилища уровня блока, такие как devicemapper, btrfs и zfs работают лучше для тяжелых рабочих нагрузок при записи (хотя и не так, как Docker тома).

Значит ли это, что всегда следует использовать тома docker, когда ожидаете много настойчивых писем?

Answer 1

всегда должны использовать docker тома, когда ожидают много постоянных записей?

Это зависит.

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

Будет ли это привязка хоста или именованный том, зависит от того, как вам нужно управлять этими данными. Том хоста - это привязка к файловой системе хоста. Он дает вам прямой доступ к этим данным, но этот прямой доступ также сопровождается проблемами с правами доступа uid / gid и приводит к потере возможности инициализации именованных томов.

Именованные тома со всеми значениями по умолчанию - это просто привязка к папке в / var / lib / docker, поэтому производительность будет такой же, как у тома основной файловой системы. При этом указанный том можно настроить для подключения практически всего, что можно сделать с помощью команды mount.

Поскольку каждый из этих параметров может иметь различную базовую файловую систему, а разница в производительности обусловлена ​​выбором этой базовой файловой системы, существует нет никакого способа ответить на этот вопрос в каком-либо общем смысле. Следовательно, это зависит.

Answer 2

Локальная файловая система контейнера никогда не хранит постоянные данные, поэтому у вас нет выбора, кроме как монтировать что-либо в контейнер, если вы хотите, чтобы данные жили после выхода из контейнера. «Драйверы хранилища на уровне блоков», которые вы цитируете, обсуждают конкретные параметры времени установки для хранения образов и контейнеров и не связаны с каким-либо конкретным томом или реализацией привязки.

Что касается производительности мое общее ожидание состоит в том, что задержка дискового ввода-вывода намного перевесит любые издержки любой конкретной реализации. Без бенчмаркинга какой-либо конкретной реализации на собственном хосте Linux я бы ожидал, что именованный том, монтирование с привязкой и записи в файловую систему контейнера будут более или менее похожи.

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

Единственное заметное исключение - это то, что монтирование на MacOS, как известно, очень медленное , и вам следует избегать их, если ваша рабочая нагрузка требует значительного доступа к диску. (Это включает в себя как чтение, так и запись, и включает в себя некоторые интерпретируемые языки, которые хотят читать во всех возможных исходных файлах во время запуска.) Если вы управляете чем-то вроде хранилища базы данных, где вы в любом случае не можете получить прямой доступ к файлам, используйте названный объем Для кода вашего приложения COPY он превращается в изображение в Dockerfile и не перезаписывает его во время выполнения.