Дано:
Огромное количество мелких (< 1мб) файлов вроде *.doc, *pdf. Общий объем терабайты и будет прирастать терабайтами. Вопрос, какое хранилище лучше использовать? Hadoop, объединенная на несколько машин файловая система и т.д. Как это вообще делается правильно?

Serguei, это склад документов банка с версиями этих документов. Write-Once, Read Many. Есть база данных, которая ведет учет этих версий. Здесь все ясно, реляционный Oracle справится со всем этим замечательно.
А вот сами файлы. Понятно, что десятки терабайт складывать на один раздел просто не выйдет. Да и доступ по скорости будет ужасный. Значит, нужен кластер или что-то вроде.

Dimitry SibiryakovЩичеПонятно, что десятки терабайт складывать на один раздел просто не выйдет. Да и доступ по
скорости будет ужасный.

И вот собрат выше ткнутого Даниила по разуму, которому сразу всё "понятно". На уровне
классового чутья, очевидно.

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


Не поверю. :) В конкурентном доступе головка будет метаться как бешеная. С предсказуемым исходом. Может быть RAID решил бы проблему, но вы не уточняли. Меня как раз и интересует то, что вы держите в себе.

Щичекачестве сервера какой-нибудь телефон.
Причем здесь сравнение файловых систем? Вы видели диск на 50TB? Я нет.

Andy_OLAP, "нормального вертикального масштабирования" - вы не дадите ссылочку? Я с темой не сталкивался, поэтому вертикальное масштабирование мне незнакомо.

skyANA, спасибо, похоже на то что нужно.

Sergei.AgalakovВообще непонятно, почему этот вопрос в проектировании баз данных, это вопрос по системам хранения. Недостаточно данных для подробного совета. Сколько одновременных читателей, прирастание данных постепенное или сразу много добавляют, и, самое главное, бюджет. Необходимо обеспечить избыточность хранения данных и бэкапы, опционально кэширование. Можно сразу купить железку с софтом, которая всё это умеет из коробки, типа NetApp, можно купить сервер с хорошим железным RAID, можно поставить софтовый RAID или использовать файловые системы типа ZFS. Можно даже на облако все это выбросить. Терабайты сейчас не пугают, если их все сразу не надо читать. Распределенное хранилище самому делать смысла нет никакого, разве что оно в компании уже есть, и можно присоседиться. Если есть деньги, то звоните в NetApp, HP или IBM, опишите им задачу, и они подберут вам железо.

Мне не надо решать задачу полностью. Мне уже четко сказали - Hadoop (HDFS). Просто у меня большие сомнения в оправданности подхода. Хочу знать какие лучше. Только для самообразования, не более.

Andy_OLAPЩичепропущено...

Мне не надо решать задачу полностью. Мне уже четко сказали - Hadoop (HDFS). Просто у меня большие сомнения в оправданности подхода. Хочу знать какие лучше. Только для самообразования, не более.

"Огромное количество мелких (< 1мб) файлов вроде *.doc, *pdf. Общий объем терабайты и будет прирастать терабайтами " и The current namespace limit is 100 million files . Давайте посчитаем. Файл 100 кбайт - в 1 Гбайт получается 10 000 таких файлов. В 1 Тбайт получается 10 миллионов таких файлов. 100 миллионов файлов - это 10 Тбайт.

Вывод - скоро Ваш хадуп таки встанет. Напишите Вашему начальнику докладную записку по электронной почте и распечатайте себе бумажную копию. Как говорили в Союзе - чем больше бумаги, тем чище задница.

Наши мысли сходятся. Мало того, они сходятся у всей рабочей группы. Это ТРЕБОВАНИЕ банка, не наше решение. Потому я и задал вопрос, что их требование показалось неадекватным задаче.

PizzaPizzaЯ тогда тоже для саморазвития спрошу.

Может быть стоит посмотреть в сторону ФС с маленькой стоимостью хранения (видимо возможность настройки блока и минимальные метаданные)?

Если у вас ЩичеWrite-OnceЩичереляционный Oracle справится со всем этим замечательно то в чем подводный камень простого многодискового массива? Вроде доставлять серверов можно пока денег хватает, ссылки на файлы лежат в базе - ничего искать не надо.

Реляционный Oracle предназначается только для хранения метаданных. Здесь 100-500млн. записей должен выдержать. Большинство будут просто лежать годами без доступа, можно делить по разным устройствам. Боюсь, простой многодисковый не выдержит. Здесь ведь и требования к объему велики и к надежности, к скорости доступа. Есть какие-то примеры решений на такой объем?

Alibek B.ЩичеНе поверю. :) В конкурентном доступе головка будет метаться как бешеная.
Это представления примерно 15-летней давности.
У меня вот уже почти 5 лет каждый день записывается 5-8 ТБ.
И как-то головка справляется.

Речь идет о чтении. Запись понятно, идет последовательно. А как быть, когда версии одного файла размазаны по диску? Или доступ идет доступ тысячи пользователей к разным документам. Вы меня обмануть хотите, однако. Физику никто не отменял.

Alibek B.ЩичеРечь идет о чтении. Запись понятно, идет последовательно.
Ну-ну. Вам виднее.

Да, вы правы.