Вопрос пока больше теоретический, но все же. Допустим, что нужно сделать тупое хранилище структурированных данных, аналитики никакой не планируется. Объем сырых данных 50 Петабайт. Требуется высокая надежность. К поиску информации есть такие требования:


На какой платформе это лучше всего можно реализовать? Чем дешевле в итоге будет стоимость хранения 1 ГБ, тем лучше. Но не в ущерб надежности.

miksoftА эти 50 Пб откуда берутся? Они уже где-то хранятся или будут откуда-то поступать?

Что за прожект? Конкурента ютубу строите?

Да это пока теория, пока нигде не хранятся, будут поступать. Это очень приблизительная оценка.

Dimitry SibiryakovVovakaДопустим, что нужно сделать тупое хранилище структурированных данных,
аналитики никакой не планируется.
В зависимости от того что понимается под "структурированными данными" сгодятся и плоские
файлы и файловой системе. На RAID6 будет высокая надёжность.


В основном чистые машинногенерируемые данные.

lookatVovaka,

сейчас Hadapt
через год может быть Pivotal HD

Про Pivotal HD даже и не слышал, причем GP в сое время плотно смотрели, интересно ..

Dimitry SibiryakovVovakaВ основном чистые машинногенерируемые данные.
В таком случае, как я уже сказал, CSV файлы с разделением по нужным критериям (судя по
первому посту это время) будут иметь приемлемые характеристики.


Поисковые запросы учитывают время и некий критерий/ID (10-15 типов), которые могут комбинироваться.
Ну а само хранение в файлах как-то не очень, кмк. Во первых хорошо бы их сжимать, во вторых кластер получается в сотни, а то и тысячи серверов и как этим всем рулить, не понятно. Первое, что пришло в голову, что-то типа hbase, но отзывы о надежности практически не оставляют шансов. Второе, все таки использовать mpp субд типа Вертики, это избавит от множества проблем, сильно сократит ресурсы на запуск и поддержку, но по финансам конечно не гуд.

Dimitry SibiryakovVovakaкластер получается в сотни, а то и тысячи серверов
Зачем кластер-то? Один сервер с хранилищем на 50 петабайт в котором лежат 10е9 файлов по
32 мегабайта каждый. Первичная фильтрация по времени не займёт и секунды, оставишиеся по
регламенту часы можно потратить на полное сканирование нужных файлов на предмет "критериев".


Ну у меня есть уже пример когда съезжала крыша у высоконадежного сетевого хранилища, так что не все данные с помощью RnD вендора удалось восстановить, поэтому MPP + sharing nothing для надежного и производительного ХД, это как-бы стало парадигмой для меня, но здесь не совсем конечно классика. Ну и про часы - это только для небольшой части запросов, остальные должны укладываться в секунды, причем одновременных может быть много. Но надо конечно подумать и в этом направлении безусловно.

Dimitry SibiryakovА бэкапы делать, конечно же, никто не побеспокоился. Ню-ню...


NAS был на сотню ТБ, там было очень много различных баз и систем, не все бекапилось, что-то по странному стечению обстоятельств, бекапилось физически на этот же NAS.

ApexAscrus, Hadoop вам не подойдет из-за требований к времени отклика, в Hadoop один подъем MapReduce Task'ов может занимать секунд 5-15, не говоря уже про связку с Pig или Hive у которых будет еще и свой overhead.
Хотя даже если бы он вам подошел, то стоимость была бы довольно большой. Прикиньте стоимость просто оборудования хотя бы под Hadoop кластер таких объемов, с учетом того, что места нужно будет раза в 3.5 больше (3 копии блока - это дефолт из-за низкой надежности таких кластеров, 0.5 это на ОС, темпы и прочую канитель).

Почитал тут про реальные внедрения, как то грустно пока все

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

Это очень правильная мысль, но пока мы просто рассуждаем в теории, аналитика может понадобиться, но уже в рамках другого, еще более масштабного проекта :)

ApexА вот бэкап как раз таки не проблема, на ext3 вы такое количество файлов не положите, даже не пытайтесь, тут понадобиться нормальная коммерческая файловая система типа Veritas, а все эти открытые поделки можно смело отбросить - не тот калибр. Но в любом случае я бы так не делал.

Ну насчет не проблема, я бы не согласился. Сколько он делаться будет и восстанавливаться? Как увязать восстановление и избежать простоя сервиса в разумных пределах на таких объемах? Проблем тут как раз достаточно на мой взгляд. Система должна обеспечивать постоянную доступность.

ApexЕсли хочется совсем дешево, то вариантов и правда не много, можно смотреть либо в сторону Impala, либо Hadapt. Но продуктам без году неделя.

Эт точно

ApexУ Терадаты для таких случаев есть Teradata 1650 Extreme Data Appliance. Но даже с очень хорошей скидкой и компрессией это будет стоить где-то в районе 2К за терабайт пользовательских данных, т.е. на таких объемах лямов 100. Дохера короче:)

Прикинул Вертику вместе с железом, примерно так же и выходит

ApexМне больше интересно а 50 Пб - это за какой период? Если три года, то это 46 Тб в день. Что нужно искать в этих 46 Тб, чтобы это укладывалось в 3 сек? Одну запись по первичному ключу?

Для одной записи норматив еще жестче - 1 сек :), это поиск в справочниках. А эта временная таблица для фактов, там как уж повезет, может и одна запись, может больше. Но это пока проект, готовят люди, не в полной мере себе представляющие получающиеся объемы данных, цифры возможно изменятся.

vromanovVovaka,

Может мы вам что-то сделаем? Я тоже склоняюсь скорее к файлам ну или к комбинации файлы + что-то другое.

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