S3 против задержки распространения EFS для распределенной файловой системы?

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

В качестве примера приведу ситуацию, которую я пытаюсь избежать: допустим, у нас есть два файла, A и B, и два контейнера, 1 и 2. Файл A загружается в файловую систему и отправляется для сравнения примерно в одно и то же время. Сразу после этого то же самое происходит с файлом B. Вскоре после того, как файл A становится видимым для контейнера 1, а файл B становится видимым для контейнера 2. Из-за того, как файлы распространяются в распределенной файловой системе, файл B не виден для контейнера 1 и файл A не виден контейнеру 2. Теперь контейнеру 1 приказано сравнить файл A со всеми другими файлами, а контейнеру 2 — сравнить B со всеми другими файлами. Из-за задержки распространения А и В никогда не сравнивались друг с другом.

Я пытаюсь выбрать между EFS и S3 для хранения всех этих файлов. Мне интересно, что лучше соответствует моим потребностям (или если есть третий вариант, о котором я не знаю).

Характеристики файлов/контейнеров: - Все файлы представляют собой небольшие текстовые файлы размером в среднем 2 КБ (хотя редко они могут быть 10 КБ) - В настоящее время общий размер файлов составляет 20 МБ, но я ожидаю, что к концу года будет 1 ГБ. - Эти контейнеры не находятся в рое - Результаты каждого сравнения уже загружаются в S3 - Попытка убедиться, что каждый файл сравнивается с каждым другим файлом, чрезвычайно важна, поэтому задержка распространения, безусловно, является наиболее важным фактором.

(Последнее примечание: если я в конечном итоге использую S3, я, вероятно, буду использовать синхронизацию для извлечения всех новых файлов, помещенных в корзину)

Редактировать: Чтобы ответить на вопросы Каннайяна, я пытаюсь добиться, чтобы каждый файл файла сравнивался с каждым другим файлом хотя бы один раз. Я не могу точно сказать, что я сравниваю, но сравнение происходит путем выполнения бинарного файла Linux с закрытым исходным кодом, который принимает файл, который вы хотите сравнить, и файлы, с которыми вы хотите его сравнить (распределенная файловая система содержит все файлы, с которыми я хочу сравнить). Они должны быть в контейнерах по двум причинам:

  1. Двоичный файл в значительной степени зависит от конкретной настройки файловой системы, и его контейнеризация гарантирует, что файловая система всегда будет правильной (я знаю, что это глупо, но опять же, двоичный файл имеет закрытый исходный код, и нет никакого способа обойти это)
  2. Бинарный файл работает только на Linux, и его контейнеризация упрощает разработку с точки зрения тестирования на локальных машинах.

Наконец, файлы со временем накапливаются только по мере того, как мы получаем все больше и больше заявок. Все файлы только считываются и никогда не изменяются после добавления в систему.


person SirPonkcelot    schedule 11.07.2018    source источник
comment
Можете ли вы также объяснить, чего вы пытаетесь достичь? Зачем вам сравнивать? Зачем они нужны в контейнерах? Что вы собираетесь делать с этими файлами?   -  person Kannaiyan    schedule 11.07.2018
comment
@Kannaiyan Я добавил несколько правок, чтобы ответить на ваш вопрос!   -  person SirPonkcelot    schedule 11.07.2018
comment
Я чувствую, что, вероятно, будет правильный ответ, но он будет связан с размером и количеством рассматриваемых объектов, а также с тем, как часто вы их читаете. У EFS есть два тесно связанных компонента: размер хранилища и общая пропускная способность с течением времени. Она становится все быстрее и быстрее по мере того, как вы добавляете в нее данные, поэтому чем меньше вы храните, тем медленнее она работает (прочитайте это еще раз , совершенно верно). О каком объеме данных мы говорим и как часто они считываются?   -  person Michael - sqlbot    schedule 11.07.2018


Ответы (1)


В конце концов я решил, что подход, к которому я стремился изначально, слишком сложен. Вместо этого я использовал S3 для хранения всех файлов, а также использовал DynamoDB в качестве кэша для ключей самых последних сохраненных файлов. Ключи добавляются в таблицу DynamoDB только после успешной загрузки в S3. Всякий раз, когда выполняется операция сравнения, контейнеры синхронизируют нужный каталог S3, а затем проверяют DynamoDB на предмет отсутствия каких-либо файлов. Благодаря согласованности S3 с чтением после записи, если какие-либо файлы отсутствуют, их можно извлечь из S3, не дожидаясь распространения во все кэши S3. Это позволяет практически мгновенно распространять распределенную файловую систему.

person SirPonkcelot    schedule 18.07.2018