Дано:
Огромное количество мелких (< 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.ЩичеРечь идет о чтении. Запись понятно, идет последовательно.
Ну-ну. Вам виднее.

Да, вы правы.

Dimitry SibiryakovЩичеФизику никто не отменял.

Вы не поверите, но таки да, физику "летающих головок" уже давно отменили.


Таки пруф? Я не верю. Вот мой http://blog.vadmin.ru/2011/08/blog-post.html. Если вы считаете, что флеш отменяет головки, то таки да. А диск устроен также как и ранее.

Dimitry SibiryakovЩичеЕсли вы считаете, что флеш отменяет головки, то таки да. А диск устроен также как и ранее.

Увы, но не так же.
1) Ещё в прошлом веке придумали кэширование, которое уменьшило поток запросов к диску на
1-2 порядка.
2) Потом придумали префетч.
3) Потом диску разрешили самостоятельно менять порядок запросов, решая для своих головок
задачу коммивояжера.
4) Потом пришли дисковые массивы и там, где одной головке надо было слетать 10 раз, десяти
головкам хватит и одного.
5) И таки да, в конце пришли диски совсем без головок.

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


О, перечисление всем известных фактов не отменяет необходимость позиционирования в больших, больших количествах. Кстати, дорогой дедушка, ты так и не привел пруфов. Наверное, у тебя их просто нет? Ты что-то много стал говорить про партизан, вспоминаешь как они тебя гоняли?

Dimitry Sibiryakovпилить свой хадуп.


Я не пойму дедуля, почему ты не вкуриваешь прямую речь? В самом начале было сказано, что мне Hadoop не нравится. Но старый, так сказать, человек почему-то напрочь забывает этот факт. Раз мы не можем понять высказывания доступные детскому саду, то стоит ли на вас обращать внимание в более серьезных вещах? Не стоит.

Leonid KudryavtsevЩиче, разговор ни о чем

Хранилищь данных на рынке - десятки и сотни от кучи именитых вендоров
Плачь про терабайты и головки - это какой-то детский лепит

Вы упрощаете. Меня интересует комплексно: какой софт, какая аппаратура, какая организация дела - чему примерно соответствует. Не кусочно, в стиле Сибирякова: грамм знаний, тонна говна, центнер бреда. Ссылочку дайте, признателен буду.
Пока ничего такого, чего не знают обычные студенты он ухитрился не сказать. Гибридные СХД :) И какие же подходят под какие задачи, какие ОС, технологии при этом используются? Надергал умных фраз и корчит из себя всезнайку.

Leonid Kudryavtsevпросите порекомендовать решение/железо


Персонально для вас повторю: я не принимаю решения, не имею денег в распоряжении, кроме как зарплату. Мне просто интересно как такие вещи делаются грамотно. Про NAS и SAN в вике написано. Но мне неясно что чему адекватно.