Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Vovaka
Member

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

№	Класс параметра запроса	Временной интервал
до суток до 1 месяца до 6 месяцев До 1 года до 3 лет
1 К1 < 3 сек. < 5 сек. < 15 сек. < 25 сек. < 50 сек.
2 К2 <1 мин <10 мин <30 мин <1 часа <3 часов
3 К3 < 7 мин

На какой платформе это лучше всего можно реализовать? Чем дешевле в итоге будет стоимость хранения 1 ГБ, тем лучше. Но не в ущерб надежности.
22 апр 13, 18:28    [14214604]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
miksoft
Member

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

Что за прожект? Конкурента ютубу строите?
22 апр 13, 18:37    [14214642]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
lookat
Member

Откуда:
Сообщений: 135
Vovaka,

сейчас Hadapt
через год может быть Pivotal HD
22 апр 13, 18:48    [14214697]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54818

Vovaka
Допустим, что нужно сделать тупое хранилище структурированных данных,
аналитики никакой не планируется.

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

Posted via ActualForum NNTP Server 1.5

22 апр 13, 19:18    [14214854]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
miksoft
А эти 50 Пб откуда берутся? Они уже где-то хранятся или будут откуда-то поступать?

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


Да это пока теория, пока нигде не хранятся, будут поступать. Это очень приблизительная оценка.
22 апр 13, 19:51    [14215007]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Dimitry Sibiryakov
Vovaka
Допустим, что нужно сделать тупое хранилище структурированных данных,
аналитики никакой не планируется.

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


В основном чистые машинногенерируемые данные.
22 апр 13, 19:52    [14215012]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54818

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

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

Posted via ActualForum NNTP Server 1.5

22 апр 13, 20:02    [14215058]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
lookat
Vovaka,

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


Про Pivotal HD даже и не слышал, причем GP в сое время плотно смотрели, интересно ..
22 апр 13, 20:04    [14215067]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Dimitry Sibiryakov
Vovaka
В основном чистые машинногенерируемые данные.

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


Поисковые запросы учитывают время и некий критерий/ID (10-15 типов), которые могут комбинироваться.
Ну а само хранение в файлах как-то не очень, кмк. Во первых хорошо бы их сжимать, во вторых кластер получается в сотни, а то и тысячи серверов и как этим всем рулить, не понятно. Первое, что пришло в голову, что-то типа hbase, но отзывы о надежности практически не оставляют шансов. Второе, все таки использовать mpp субд типа Вертики, это избавит от множества проблем, сильно сократит ресурсы на запуск и поддержку, но по финансам конечно не гуд.
22 апр 13, 20:13    [14215105]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54818

Vovaka
кластер получается в сотни, а то и тысячи серверов

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

Posted via ActualForum NNTP Server 1.5

22 апр 13, 20:22    [14215136]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Dimitry Sibiryakov
Vovaka
кластер получается в сотни, а то и тысячи серверов

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


Ну у меня есть уже пример когда съезжала крыша у высоконадежного сетевого хранилища, так что не все данные с помощью RnD вендора удалось восстановить, поэтому MPP + sharing nothing для надежного и производительного ХД, это как-бы стало парадигмой для меня, но здесь не совсем конечно классика. Ну и про часы - это только для небольшой части запросов, остальные должны укладываться в секунды, причем одновременных может быть много. Но надо конечно подумать и в этом направлении безусловно.
22 апр 13, 20:29    [14215153]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54818

Vovaka
у меня есть уже пример когда съезжала крыша у высоконадежного сетевого
хранилища, так что не все данные с помощью RnD вендора удалось восстановить

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

Posted via ActualForum NNTP Server 1.5

22 апр 13, 20:44    [14215203]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Dimitry Sibiryakov
А бэкапы делать, конечно же, никто не побеспокоился. Ню-ню...


NAS был на сотню ТБ, там было очень много различных баз и систем, не все бекапилось, что-то по странному стечению обстоятельств, бекапилось физически на этот же NAS.
22 апр 13, 20:54    [14215231]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Dimitry Sibiryakov
Vovaka
у меня есть уже пример когда съезжала крыша у высоконадежного сетевого
хранилища, так что не все данные с помощью RnD вендора удалось восстановить

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

А как Вы себе бакуп петтабайтного хранилища и потом если что его восстановления представляете? Это нереально дорого и долго. Тут как раз распределенные файловые системы или MPP сервера как раз и пытаются решать этот вопрос.
22 апр 13, 23:48    [14215936]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
ASCRUS
Dimitry Sibiryakov
пропущено...

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

А как Вы себе бакуп петтабайтного хранилища и потом если что его восстановления представляете? Это нереально дорого и долго. Тут как раз распределенные файловые системы или MPP сервера как раз и пытаются решать этот вопрос.
Распределение и дублирование данных закрывает далеко не все вопросы.
Никто не отменял всякие Human Errors и баги в программном обеспечении.
23 апр 13, 00:00    [14215994]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54818

ASCRUS
А как Вы себе бакуп петтабайтного хранилища и потом если что его
восстановления представляете? Это нереально дорого и долго. Тут как раз распределенные
файловые системы или MPP сервера как раз и пытаются решать этот вопрос.

Ага, поставить рядом с петабайтным хранилищем второе такое же это нереально дорого, а
сделать полную копию того же объёма данных на Х других серверах - халява. Ню-ню...

Маркетинг маркетингом, но физику-то забывать не надо.

Posted via ActualForum NNTP Server 1.5

23 апр 13, 00:01    [14216004]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Тут, кстати, поддержу Дмитрия - я бы без наличия бэкап вообще ни на какие SLA не подписывался.
Вон насколько больше Google в сервис Youtube вкладывает - и то периодически не получается проиграть видео в нужном мне разрешении.
23 апр 13, 00:03    [14216015]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
lookat
Member

Откуда:
Сообщений: 135
Dimitry Sibiryakov
ASCRUS
А как Вы себе бакуп петтабайтного хранилища и потом если что его
восстановления представляете? Это нереально дорого и долго. Тут как раз распределенные
файловые системы или MPP сервера как раз и пытаются решать этот вопрос.

Ага, поставить рядом с петабайтным хранилищем второе такое же это нереально дорого, а
сделать полную копию того же объёма данных на Х других серверах - халява. Ню-ню...

Маркетинг маркетингом, но физику-то забывать не надо.


Физика физикой, но и Tape Backup никто не отменял.
Тем более что, начиная с LTO-5, можно монтировать
на ленте свою файловую систему (LFTS называется).
Для Hadoop-Backup -- самое то.
23 апр 13, 00:24    [14216079]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
lookat
Member

Откуда:
Сообщений: 135
lookat


<snip>
... (LFTS называется)...
</snip>



Пардон, LTFS
23 апр 13, 00:29    [14216087]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Dimitry Sibiryakov
ASCRUS
А как Вы себе бакуп петтабайтного хранилища и потом если что его
восстановления представляете? Это нереально дорого и долго. Тут как раз распределенные
файловые системы или MPP сервера как раз и пытаются решать этот вопрос.

Ага, поставить рядом с петабайтным хранилищем второе такое же это нереально дорого, а
сделать полную копию того же объёма данных на Х других серверах - халява. Ню-ню...

Маркетинг маркетингом, но физику-то забывать не надо.

Сделать копию на дешевых серверах с локальными дисками, которая автоматически становится активной при выходе из строя ее источника по любому дешевле чем два дисковых хранилища и работает эта схема в 24 x7 без остановки кластера. В Vertica например при ksafe=2 в кластере из 5 серверов нужно убить 3 сервера в правильной последовательности, чтобы кластер перестал работать. Причем при смерти сервера достаточно поставить новый, чтобы он быстро реплицировал на себя данные взамен убранного с соседей и включился в работу ... все это не прерывая работы. У hadoop немного по другому и скорость восстановления ниже, но смысл похожий. Но по мне для темы данного топика hadoop не подходит - требуется хранить уже изначально структурированные данные и проводить поиск по заданным критериям. Тогда зачем там map и тем более reduce, вот если будет задача хранить для использования оригинальные форматы и файлы данных, тогда он получается интересен, но все равно в связке с каким нибудь MPP, на котором можно хранить индекс для быстрого поиска оригинальных файлов. Все конечно мое imho, на hadoop пока не приводилось проектов делать в продакшн.
23 апр 13, 00:53    [14216108]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Apex
Member

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

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

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

Мне больше интересно а 50 Пб - это за какой период? Если три года, то это 46 Тб в день. Что нужно искать в этих 46 Тб, чтобы это укладывалось в 3 сек? Одну запись по первичному ключу?
23 апр 13, 03:30    [14216200]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Vovaka
Member

Откуда: Москва
Сообщений: 684
Apex
Ascrus, 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 сек :), это поиск в справочниках. А эта временная таблица для фактов, там как уж повезет, может и одна запись, может больше. Но это пока проект, готовят люди, не в полной мере себе представляющие получающиеся объемы данных, цифры возможно изменятся.
23 апр 13, 09:18    [14216437]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Vovka
Сколько он делаться будет и восстанавливаться?

А это уже целиком зависит от политики бэкапирования. Инкрементальный бэкап восстановится быстро.
23 апр 13, 10:00    [14216685]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
По сабжу

1 .Любая БД которая поддерживает RO табличные пространства, с возможность отключения подключения
RO датафайлов на лету.

2. Любая ОС , которая поддерживает LVM, и перемещение данных на лету между томами , незаметно для БД, что бы наращивать обьемы новыми стораджами и перемещать данные между стораджами без остановок.

3. Любой сторадж, на котором с хоста можно поставить и снять RO флажок на датафайлах ( томах)
и раздать нескольким серверам.


Желающие могут озвучить возможных кандидатов по 3 пунктам.
23 апр 13, 12:51    [14217880]     Ответить | Цитировать Сообщить модератору
 Re: ХД на 50 ПБ структурированных данных, выбор платформы  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
4. Мозги архитектора , спроеткировать хранение и загнать данные так ,
что бы система сама себе не наступала на RO хвосты ,
и обеспечивала достаточную производительность.
23 апр 13, 12:53    [14217905]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить