Исходные данные: в системе нужно сохранитьь огромное число отдельных документов (скорость поступления данных не очень велика — несколько Мб в секунду; документов десятки миллионов; отдельные файлы — очень плохая идея, все тормознутое, хотя бы из-за необходимости удаления, это уже пройденный этап), и желательно ввод-вывод сделать максимально быстрым. В общем надо хранить много бинарных данных. Блобы для этого подойдут (каковы у них издержки) или больше пойдет нечто узкоспецилизированное? Может что-то посоветуете?

Здравствуйте, trophim, Вы писали:

t> Может что-то посоветуете?

MongoDB

On 17.03.2011 00:15, trophim wrote:

> Исходные данные: в системе нужно сохранитьь огромное число отдельных документов (скорость поступления данных не очень велика — несколько Мб в секунду; документов десятки миллионов; отдельные файлы — очень плохая идея, все тормознутое, хотя бы из-за необходимости удаления, это уже пройденный этап), и желательно ввод-вывод сделать максимально быстрым. В общем надо хранить много бинарных данных. Блобы для этого подойдут (каковы у них издержки) или больше пойдет нечто узкоспецилизированное? Может что-то посоветуете?

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

Удаление блобов при удалении записи при этом не производится — лежит
себе блоб и лежит, хранение нынче недорогое.

Также можно посмотреть на SVN — один из вариантов хранения файлов в
репозитории SVN это BerkleyDB

Здравствуйте, trophim, Вы писали:

T>Исходные данные: в системе нужно сохранитьь огромное число отдельных документов (скорость поступления данных не очень велика — несколько Мб в секунду; документов десятки миллионов; отдельные файлы — очень плохая идея, все тормознутое, хотя бы из-за необходимости удаления, это уже пройденный этап), и желательно ввод-вывод сделать максимально быстрым. В общем надо хранить много бинарных данных. Блобы для этого подойдут (каковы у них издержки) или больше пойдет нечто узкоспецилизированное? Может что-то посоветуете?

Использовать FileStream в MS SQL 2008 R2.

Сами файлы лежат на диске, но работу с ними обеспечивает сервер, через обычный sql.

T> Может что-то посоветуете?
в таких объемах — не хранить в базе. она не для этого предназначена

Здравствуйте, mazurkin, Вы писали:

.....

M>Также можно посмотреть на SVN — один из вариантов хранения файлов в
M>репозитории SVN это BerkleyDB

Вот я о готовом решении и спрашиваю (надоели велосипеды, хотя они и могут быть супер-пупер-быстрыми).
Беркли посмотрю. Может какие-либо еще варианты?

Здравствуйте, Anton Batenev, Вы писали:

AB>MongoDB

Это такое тонкое издевательство? MongoDB это документная база данных, хранить в ней бинарники, можно конечно, но не стоит. Если уж двигаться в сторону noSQL, то нужно смотреть на key-value хранилища.

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

Здравствуйте, BlackEric, Вы писали:

разумно только если файлы более менее приличного размера от 1-2 мб

BE>Здравствуйте, trophim, Вы писали:

T>>Исходные данные: в системе нужно сохранитьь огромное число отдельных документов (скорость поступления данных не очень велика — несколько Мб в секунду; документов десятки миллионов; отдельные файлы — очень плохая идея, все тормознутое, хотя бы из-за необходимости удаления, это уже пройденный этап), и желательно ввод-вывод сделать максимально быстрым. В общем надо хранить много бинарных данных. Блобы для этого подойдут (каковы у них издержки) или больше пойдет нечто узкоспецилизированное? Может что-то посоветуете?

BE>Использовать FileStream в MS SQL 2008 R2.

BE>Сами файлы лежат на диске, но работу с ними обеспечивает сервер, через обычный sql.

Здравствуйте, Miroff, Вы писали:

M> Это такое тонкое издевательство? Если уж двигаться в сторону noSQL, то нужно смотреть на key-value хранилища.

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

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

Ну по условию задачи, файлы уже отметаются.

Здравствуйте, rm822, Вы писали:

T>> Может что-то посоветуете?
R>в таких объемах — не хранить в базе. она не для этого предназначена
Вы где-то нашли информацию о предназначении баз? Поделитесь, пожалуйста.

ОС — WinXP. Какую ФС там можно кроме НТФС применить?

Здравствуйте, Anton Batenev, Вы писали:

AB>Ничуть. GridFS вполне неплохо справляется с данной задачей, плюс получаем шардинг и репликацию в одном флаконе — достаточно удобно, когда диск закончится, плюс возможность отдавать файлы напрямую из nginx минуя "толстый слой шоколада".

Спасибо, не подумал про нее. У вас есть опыт использования GridFS в продакшене?

Здравствуйте, Miroff, Вы писали:

M>Спасибо, не подумал про нее. У вас есть опыт использования GridFS в продакшене?

...если б еще кто-либо про hadoop (hdfs) написал отзыв, было бы хорошо.

Здравствуйте, Miroff, Вы писали:

M> Спасибо, не подумал про нее. У вас есть опыт использования GridFS в продакшене?

Как бы это сказать... На тестовом стенде оказалось, что мы укладываемся в лимиты документа по объему. По этому, после тестирования, GridFS признана излишней. А так:

> db.stats()
{
    "collections" : 4,
    "objects" : 300367634,
    "avgObjSize" : 160.82417620268635,
    "dataSize" : 48306377296,
    "storageSize" : 53743664384,
    "numExtents" : 66,
    "indexes" : 5,
    "indexSize" : 45671533984,
    "fileSize" : 120134303744,
    "ok" : 1
}

Здесь одна табличка занимает почти 100% объема и количества. В пике около 120 запросов в секунду на выборки (сколько максимум сможет выдержать на боевом сервере не знаю, нет данных).

майкрософтовский террасервер хранит петабайты изображений в базе

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Miroff, Вы писали:

M>>Спасибо, не подумал про нее. У вас есть опыт использования GridFS в продакшене?

А>...если б еще кто-либо про hadoop (hdfs) написал отзыв, было бы хорошо.

В hdfs плохая поддержка кучи мелких файлов. Нужно очень много памяти на namenode,
чтобы все имена файлов в нее влезли.
Если уж хочется hadoop — то стоит смотреть на реализацию хранилища руками на базе hbase
(как сделано в lily, подробнее),
или реализовать хранение нескольких файлов в одном.


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

Здравствуйте, trophim, Вы писали:

T>ОС — WinXP. Какую ФС там можно кроме НТФС применить?

Это на сервере?!

Здравствуйте, trophim, Вы писали:

T>ОС — WinXP. Какую ФС там можно кроме НТФС применить?

Домашняя ОС под хайлоад сервер... Вас ничто "не напрягает"?

Здравствуйте, pansa, Вы писали:

P>Здравствуйте, trophim, Вы писали:

T>>ОС — WinXP. Какую ФС там можно кроме НТФС применить?

P>Домашняя ОС под хайлоад сервер... Вас ничто "не напрягает"?

Эх, не сыпьте соль... Заказчики они такие заказчики... =(

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, trophim, Вы писали:

T>>ОС — WinXP. Какую ФС там можно кроме НТФС применить?

A>Это на сервере?!

Ну, что поделать — жизнь не всегда сахар. Приходиться иметь то, что имеем (или это оно нас имеет)...

Здравствуйте, trophim, Вы писали:

P>>Домашняя ОС под хайлоад сервер... Вас ничто "не напрягает"?
T>Эх, не сыпьте соль... Заказчики они такие заказчики... =(

Бегите о т таких. Она и на вас сэкономят.

Здравствуйте, trophim, Вы писали:

T>Здравствуйте, pansa, Вы писали:

P>>Здравствуйте, trophim, Вы писали:

T>>>ОС — WinXP. Какую ФС там можно кроме НТФС применить?

P>>Домашняя ОС под хайлоад сервер... Вас ничто "не напрягает"?

T>Эх, не сыпьте соль... Заказчики они такие заказчики... =(

T>Исходные данные: в системе нужно сохранитьь огромное число отдельных документов (скорость поступления данных не очень велика — несколько Мб в секунду; документов десятки миллионов; отдельные файлы — очень плохая идея, все тормознутое, хотя бы из-за необходимости удаления, это уже пройденный этап),

Вот тут странный вывод. Удаление файла — операция должна быть весьма быстрой. Во всяком случае, не в нее всё упереться должно. Даже с учетом XP.

T> и желательно ввод-вывод сделать максимально быстрым. В общем надо хранить много бинарных данных. Блобы для этого подойдут (каковы у них издержки) или больше пойдет нечто узкоспецилизированное? Может что-то посоветуете?

Ну если по теме.
Учитывая , видимо, печальный опыт с файлами на WinXP... Не надо сразу его отбрасывать.

1) Поднимаете хороший сервер на Solaris + zfs, либо что-то близкое. По возможности — с хорошей дисковой подсистемой.
2) Файлы храните в ФС, именуя их по их md5/sha и раскладывая на несколько уровней подкаталогов, равномерно, чтобы не создавать подкаталоги с сотнями тыщ файлов. Это важно.
3) mongodb в качестве хранилища метаданных. Храните там оригинальное имя файла и его хэш, по которому именуете файлы в ФС. Плюс еще можете хранить кучу всего, это уже не важно.

Для доступа к файлу — сначала выполняете поиск его в mongo. Это будет очень быстро.
Найдя запись, вы знаете его абсолютный путь, он однозначно вычисляется по sha — это залог более быстрых операций в ФС.

В общих чертах всё. Это рабочая , продакшн, схема. Несколько десятков млн файлов держит пока абсолютно спокойно.

Здравствуйте, pansa, Вы писали:

T>>Исходные данные: в системе нужно сохранитьь огромное число отдельных документов (скорость поступления данных не очень велика — несколько Мб в секунду; документов десятки миллионов; отдельные файлы — очень плохая идея, все тормознутое, хотя бы из-за необходимости удаления, это уже пройденный этап),

P>Вот тут странный вывод. Удаление файла — операция должна быть весьма быстрой. Во всяком случае, не в нее всё упереться должно. Даже с учетом XP.

А между тем все вот так плохо... Например в каталоге лежало 340000 файлов HTM (разбиты по 4000 файлов по подкаталогам). Так вот простой обход всех файлов (можно просто в обычном Total Commander проверить) это какая-то дичайше тормознутая операция (имеется ввиду суммарно затраченное время).
Ну а про то, как сервер два дня удалял зарегистрированные сообщения с диска — даже вспоминать не хочется.