2015-05-29 3 views
1

Я пишу программное обеспечение на C, на Linux, работающем на AWS, которое должно обрабатывать 240 терабайт данных, в 72 миллионах файлов.Linux: огромные файлы и огромное количество файлов

Данные будут распределены по 24 или более узлам, поэтому на каждом узле будет всего 10 терабайт и 3 миллиона файлов на узел.

Поскольку я должен добавлять данные к каждому из этих трех миллионов файлов каждые 60 секунд, самым простым и быстрым способом было бы сохранить каждый из этих файлов одновременно.

Я не могу хранить данные в базе данных, потому что производительность при чтении/записи данных будет слишком медленной. Мне нужно очень быстро прочитать данные.

Мои вопросы:

1) является даже можно держать открытыми 3 миллиона файлов

2), если это возможно, сколько памяти будет это потреблять

3), если это возможно , будет ли производительность ужасной

4) если это невозможно, мне нужно будет объединить все отдельные файлы в несколько десятков больших файлов. Максимальный размер файла в Linux?

5) Если это невозможно, какую технику я должен использовать для добавления данных каждые 60 секунд и отслеживать их?

+7

«Я не могу хранить данные в базе данных, потому что производительность при чтении/записи данных будет слишком медленной» - на чем вы основываетесь? –

+2

Создайте свое программное обеспечение, чтобы вы могли легко использовать распределенные файловые системы, таким образом он будет масштабируемым. Увеличение вашей пропускной способности означает только ссылку на другой сервер. Я предполагаю, что единственный способ узнать, может ли ваш сервер обрабатывать поток данных, - это попробовать, я думаю. – ShellFish

+0

@Mitch, я основываю это на огромной конкурентной точке, чтобы как можно быстрее считывать данные. Таким образом, все, что угодно, кроме необработанного чтения/записи на диск, поставит нас в невыгодное положение против наших конкурентов. – PaeneInsula

ответ

0

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

Во-первых, посмотрите на это:

https://aws.amazon.com/blogs/aws/amazon-elastic-file-system-shared-file-storage-for-amazon-ec2/

https://aws.amazon.com/efs/

EFS обеспечивает общее хранилище, вы можете смонтировать как файловую систему.

Вы можете хранить ВСЕ ваши файлы в одном блоке хранения EFS. Затем вам понадобится набор из N рабочих машин, работающих на полную мощность файловых манипуляторов. Затем вы можете использовать очередь Redis для распространения обновлений. Каждый работник должен удалить набор обновлений из Redis, а затем открыть необходимые файлы и выполнить обновления.

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

Это масштабируемое, хотя я не уверен, что это самый дешевый способ решить вашу проблему.

+0

Чтобы ответить на ваш предыдущий вопрос, каждые 60 секунд мы добавляем крошечный объем данных, менее 1 к каждому файлу. – PaeneInsula

+0

Ничего себе, EFS звучит идеально. Похоже, это было сделано специально для наших нужд. – PaeneInsula

Смежные вопросы