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

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

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

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

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

Анкур


mongodb storage couchdb distributed logfiles
person Ankur Gupta    schedule 09.10.2010    source источник
comment
Просто посчитайте: это 500 ГБ в неделю или 100 ГБ каждый рабочий день.   -  person egrunin    schedule 09.10.2010
comment
@egrunin Спасибо за математику. У нас уже есть данные за несколько лет. @chaosЭти файлы журнала поступают из массивов хранения, установленных глобально.   -  person Ankur Gupta    schedule 09.10.2010
comment
@Ankur, подошел бы вам формат JSON, если бы у него был один объект для каждого сообщения журнала, причем одно из свойств объекта было бы исходным сообщением журнала, а другие были бы запрашиваемыми полями, извлеченными из этого сообщения журнала? Это увеличивает требования к хранилищу данных, но позволяет рассмотреть MongoDB и CouchDB.   -  person Jim Ferrans    schedule 09.10.2010
comment
@Джим, что за идея? Я не думал об этом. Спасибо. Я думаю, что это делает cockdb и mongodb соперником. Я не хочу запрашивать только файлы журналов и предоставлять REST API сверху.   -  person Ankur Gupta    schedule 09.10.2010
comment
Взгляните и на Vertica, похоже, она неплохо справляется с такими вещами.   -  person Jim Ferrans    schedule 09.10.2010
comment
Итак, все, что вам нужно сделать, это сохранить файлы и получить их по имени файла? Почему файловая система не подходит для этой задачи?   -  person JoshD    schedule 09.10.2010
comment
@JoshD В настоящее время он работает поверх NFS, как я уже упоминал. Я ищу что-то лучше. Более быстрое время поиска, автоматическое сжатие. Да, я всегда могу написать код для этого. Есть готовый продукт для этого? Как и Джим, упомянутый выше, я также мог бы использовать mongoDB и т. Д. Так что просто узнать, какие у меня есть варианты.   -  person Ankur Gupta    schedule 09.10.2010
comment
@Ankur Gupta: Я думал, что если вы просто храните и извлекаете файлы (и печатаете список файлов), база данных - не лучшее решение. Файловые системы - это именно то, что вам нужно, поэтому я бы посоветовал изучить их. Если перечисление файлов занимает слишком много времени, разбейте их на несколько папок (возможно, каждую неделю или каждый месяц).   -  person JoshD    schedule 09.10.2010
comment
Мне кажется, что все, что нужно, это умная структура папок с автоматически генерируемыми подпапками, чтобы предотвратить слишком много файлов в одной папке. И немного кода для сжатия и распаковки. Afaik MongoDB и CouchDB не поддерживают сжатие и распаковку.   -  person TTT    schedule 10.10.2010
comment
mongodb работает с файлами с отображением памяти. Вы не можете хранить больше данных, чем доступное виртуальное адресное пространство. Имейте в виду, что большинство 64-битных машин поддерживают только 48-битное виртуальное адресное пространство, поэтому у вас закончится 281 ТБ :-)   -  person nos    schedule 13.10.2010
comment
Вы рассматривали Logstash? Это сборщик журналов с открытым исходным кодом, который может хранить журналы в распределенном кластере ElasticSearch, который должен иметь возможность горизонтального масштабирования.   -  person Jon Skarpeteig    schedule 21.03.2013

Ответы (5)


arrow_upward
4
arrow_downward

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

Я верю HDFS и HBase.

На странице Hadoop на powered by можно увидеть много историй об огромных хранилищах.

person RameshVel    schedule 11.10.2010
comment
Посмотрите на коннектор лотка для хаупа. У Hadoop есть множество плагинов для управления большими объемами данных. - person Amala; 11.10.2010
comment
@RameshVel, что, если вам нужны функции запроса? - person Mark Evans; 30.05.2014

arrow_upward
3
arrow_downward

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

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

person Jim Ferrans    schedule 09.10.2010

arrow_upward
3
arrow_downward

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

http://www.gluster.org/

person Nauman    schedule 12.10.2010
comment
Забыл упомянуть, что это также с открытым исходным кодом. - person Nauman; 12.10.2010

arrow_upward
3
arrow_downward

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

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

person Spike Gronim    schedule 13.10.2010

arrow_upward
0
arrow_downward

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

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

Аналогичный подход возможен с GridFs Mongo, но вы должны создать API самостоятельно.

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

person diogok    schedule 13.10.2010