Хранение миллионов файлов журналов - около 25 ТБ в год

Question

В рамках моей работы мы ежегодно получаем файлы журналов объемом около 25 ТБ, в настоящее время они сохраняются в файловой системе на основе NFS. Некоторые архивируются как в zip / tar.gz, а другие находятся в чистом текстовом формате.

Я ищу альтернативы использованию системы на основе NFS. Я посмотрел на MongoDB, CouchDB. Тот факт, что они являются документно-ориентированной базой данных, кажется, делает ее подходящей. Однако содержимое файлов журнала должно быть изменено на JSON для хранения в БД. Что-то, чего я не желаю делать. Мне нужно сохранить содержимое файлов журнала как есть.

Что касается использования, мы намереваемся установить небольшой REST API и позволить людям получать список файлов, последние файлы и возможность получить файл.

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

Анкур

Answer 1

Поскольку вы не хотите запрашивать функции, вы можете использовать apache hadoop .

Я верю HDFS и HBase отлично подойдет для этого.

Вы можете увидеть множество огромных историй хранения в Hadoop powered by page

Answer 2

Я бы настоятельно рекомендовал использовать хранилище ключей / значений или документов для этих данных (монго, кассандра и т. Д.).Используйте файловую систему.Это потому, что файлы очень большие, и шаблон доступа будет линейного сканирования.Одна проблема, с которой вы столкнетесь, это удержание.Большинство систем хранения «NoSQL» используют логическое удаление, что означает, что вам нужно сжать базу данных, чтобы удалить удаленные строки.У вас также будет проблема, если ваши отдельные записи журнала будут небольшими, и вам придется индексировать каждую из них - ваш индекс будет очень большим.

Поместите ваши данные в HDFS с 2-3 путями репликации в 64Куски МБ в том же формате, что и сейчас.

Answer 3

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

http://www.gluster.org/

Answer 4

Взгляните на Vertica , столбцовую базу данных, поддерживающую параллельную обработку и быстрые запросы.Comcast использовал его для анализа около 15 ГБ / день данных SNMP , работающих со средней скоростью 46 000 выборок в секунду с использованием пяти четырехъядерных серверов HP Proliant.Я слышал, как несколько человек из Comcast бредили Vertica несколько недель назад;им все еще очень нравится это.У него есть несколько хороших методов сжатия данных и «избыточность k-безопасности», поэтому они могут обойтись без SAN.

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

Answer 5

Если вы хотите выбрать базу данных документов:

В CouchDB вы можете использовать API _attachement, чтобы прикрепить файл как есть к документу, сам документ может содержать только метаданные (такие как метка времени, местоположение и т. Д.) Для индексации. Тогда у вас будет REST API для документов и вложений.

Подобный подход возможен с GridFs Mongo, но вы бы сами создали API.

Также HDFS - очень хороший выбор.