S3 против задержки распространения EFS для распределенной файловой системы?
Я работаю над проектом, который использует несколько док-контейнеров, которые все должны иметь доступ к одним и тем же файлам для сравнения. Важно то, что если файл кажется видимым одному контейнеру, то между тем, когда он появляется видимым для других контейнеров, существует минимальное время.
В качестве примера приведу ситуацию, которую я пытаюсь избежать: допустим, у нас есть два файла, A и B, и два контейнера, 1 и 2. Файл A загружен в файловую систему и представлен для сравнения примерно в одно и то же время. Сразу же после этого происходит то же самое с файлом B. Вскоре после того, как файл A становится видимым для контейнера 1, а файл B появляется видимым для контейнера 2. Вследствие того, как файлы распространяются в распределенной файловой системе, файл B не виден для контейнера 1 и файл A не виден контейнеру 2. Контейнеру 1 предписано сравнить файл A со всеми другими файлами, а контейнеру 2 - сравнить B со всеми другими файлами. Из-за задержки распространения A и B никогда не сравнивались друг с другом.
Я пытаюсь выбрать между EFS и S3 для хранения всех этих файлов. Мне интересно, что бы лучше соответствовало моим потребностям (или есть третий вариант, о котором я не знаю).
Характеристики файлов / контейнеров таковы: - Все файлы представляют собой небольшие текстовые файлы, размер которых в среднем составляет 2 КБ (хотя редко они могут составлять 10 КБ) - В настоящее время общее количество файлов составляет 20 МБ, но я ожидаю, что к концу года будет 1 ГБ - Эти контейнеры не находятся в рое. - Результаты каждого сравнения уже загружаются на S3. - Попытка убедиться, что каждый файл сравнивается с любым другим файлом, чрезвычайно важна, поэтому задержка распространения, безусловно, является наиболее важным фактором.
(Последнее замечание: если я буду использовать S3 в конечном итоге, я, вероятно, буду использовать синхронизацию, чтобы выгрузить все новые файлы, помещенные в корзину)
Изменить: Чтобы ответить на вопросы Каннайяна, я пытаюсь добиться, чтобы каждый файл сравнивался с каждым другим файлом хотя бы один раз. Я не могу точно сказать, что я сравниваю, но сравнение происходит путем выполнения бинарного Linux-файла с закрытым исходным кодом, который берет файл, который вы хотите сравнить, и файлы, с которыми вы хотите сравнить его (распределенная файловая система содержит все файлы, с которыми я хочу сравнить). Они должны быть в контейнерах по двум причинам:
- Двоичный файл в значительной степени зависит от конкретной настройки файловой системы, и его контейнеризация гарантирует, что файловая система всегда будет правильной (я знаю, что она тупая, но опять-таки двоичный файл является закрытым исходным кодом, и нет никакого способа обойти это)
- Бинарный файл работает только на Linux, а его контейнеризация облегчает разработку с точки зрения тестирования на локальных машинах.
Наконец, файлы только накапливаются с течением времени, так как мы получаем все больше и больше заявок. Все файлы читаются и никогда не изменяются после добавления в систему.
1 ответ
В конце концов я решил, что подход, к которому я шел, изначально был слишком сложным. Вместо этого я в итоге использовал S3 для хранения всех файлов, а также использовал DynamoDB в качестве кеша для ключей самых последних сохраненных файлов. Ключи добавляются в таблицу DynamoDB только после успешной загрузки на S3. Всякий раз, когда выполняется операция сравнения, контейнеры синхронизируют нужный каталог S3, затем проверяют DynamoDB, чтобы увидеть, отсутствуют ли какие-либо файлы. Из-за согласованности чтения-записи-записи S3, если какие-либо файлы отсутствуют, их можно извлечь из S3, не дожидаясь распространения на все кэши S3. Это позволяет практически мгновенно распространять распределенную файловую систему.