Как организовать хранение больших текстовых данных?

Question

[Zerstoren]

Есть система для парсинга email писем для последующей подачи их в систему. Т.к. с парсингом могут возникать проблемы, мы решили сохранять оригиналы писем.

Еще момент стоит с аттачами в письмах, т.е. размер письма может достигать до 50 и 100мб. Выризать аттачи из письма нельзя.

Файловая система рассматривается в самую последнюю очередь.

Встал вопрос, какой лучше софт использовать для хранения этих данных?
Обязательно чтоб он умел принимать файлы из сети (софт будет на отдельном сервере).
Желательно чтоб были какие-то метки для будущего поиска данных.
Хорошо если будет связь с nodejs.
Отлично, если данные будут еще и архивироваться.

Answer 1

[Тимур Шемсединов]

Файловая система рассматривается в самую последнюю очередь.

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

Выризать аттачи из письма нельзя.

Почему? Вы их что в MIME BASE64 храните? Как раз нужно - делайте папку для каждого письма и сохраняйте все атачи из него в папку. Конечно, нужно держать индекс файлов и писем в СУБД, с дополнительными полями, которых нет в файловой системе. Для этого лучше взять реляционку и хранить там имена файлов в UTF-8, а на диске держать файлы переименованные, например в ID записи в БД, можно в HEX.

Comments

[Дэн Иванов]

Вот подскажите, зачем этот геморой, если данные проблемы решаются (перекладываются) при использовании нормального object storage.
Или у вас предубеждения какие то по работе с HTTP интерфейсами ?
Я так понял у автора не стоит ограничения в виде POSIX filesystem.
На счет "файловые системы для этого и делали", я бы не был так категоричен, все зависит от характера вашей работы с ФС, если данные пишутся в режииме append only, иногда, "ручная" имплементация объектов хранения (читай блобов) может работать быстрее чем  ФС. (поиск и добавление объектов).

[Zerstoren]

@MarcusAurelius Я кажись ясно написал, что нам нужно хранить ОРИГИНАЛЫ писем. Мы их парсим и отдаем в нашу систему. Но если с парсингом будут проблемы, у нас есть исходник письма который мы сможем проверить.

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

[Тимур Шемсединов]

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

Про оригиналы - вопрос - у вас падает парсер? Т.е. он во время парсинга загинается или просто глючит и может неправильно отпарсить и работать дальше? Это уже плохая ситуация, нужно переписывать парсер, спецификация MIME достаточно однозначная, чтобы парсить однозначно и вынимать файлы правильно. А если падает, то нужно хранить оригинал только для тех писем, которые не удалось отпарсить.

[Дэн Иванов]

@MarcusAurelius круто, подскажите пожалуйста вот что...
Представьте что у человека через год будет 1ПБ данных для хранения, которым нужно обеспечить сохранность.
Как вы предлагаете ему с zfs обеспечить горизонтальное масштабирование ?
Самому реализовывать механизмы шардирования на уровне приложения ?
Как реализовывать хотя бы отложенную репликацию как это сделано во всяких там монгах и mysql ?
Как обеспечить обязательную запись в 2 копии при поступлении контента и отложенную запись в 3ю ?
Как обеспечить _доступность_ (читай прозрачный доступ хотя бы к одной копии) к примеру минимум 3х копий данных и периодически проверять их целостность и синхронизировать после возникновения проблем с доступностью той или иной реплики ?

[Тимур Шемсединов]

Так он же не говорит про 1ПБ, если такие дела, тогда ему и mongo с mysql не помогут, нужно брать HDFS (Hadoop Distributed File System).

[grossws]

Спецификация MIME (я так понимаю, что вы имеете ввиду RFC 822-5322 и сопутствующие) вполне однозначна и почтовые сообщения хорошо парсится в теории. В реальном всё совсем не так.
Поэтому хранение оригиналов вполне оправдано.

Answer 2

[zxmd]

Можно конечно попробовать mongo gridfs но... вы таки хотите этого?

Comments

[Zerstoren]

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

[zxmd]

@Zerstoren Какой объем писем нужно обрабатывать в сутки?

[Тимур Шемсединов]

Зачем монговая файловая система? Разве тут распределенное хранение нужно?

[Zerstoren]

Предполагается от 10-20 тыс писем в сутки. В случае успеха можем расчитывать на 100+ тыс в сутки

[Тимур Шемсединов]

HDFS (Hadoop Distributed File System)

Answer 3

[Дэн Иванов]

Elliptics / Casandra

Answer 4

[Ярослав Еремин]

Используйте Mongo