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

Откуда: СПб
Сообщений: 939
Исходные данные
на входе льется:
- поток из видеокамер, аудио и других подобных источников данных, которые по большому счету можно представить как "большие медиа файлы внутри которых СУБД копаться не должно".суммарная скорость порядка 60..80 мегабайт в секунду;
- поток мета информации к указанному выше, и прочие данные, допустим измерения с приборов. скорость до 3 мБ/сек.

все это должно связываться с некими "фактами" (мгновенные либо растянутые во времени события).
суммарный объем хранилища - до 200 терабайт.

на выходе - из клиентского ПО, необходима возможность подгрузить данные либо по "факту", либо за интервал времени.

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


одновременное количество:
- источников данных - до 40
- клиентов отображения/редактирования - до 5

сеть закрытая, среда скорей всего линукс.

варианты которые видятся:
- СУБД + блоб;
- СУБД + файловое хранилище.

лично по мне, писать столько в блоб - извращенство, и, учитывая отсутствия дикой конкурентности, жестких требований к безопасности, сложных моделей данных, сложных запросов - вполне справится Postgre (хранение фактов, связей с файлами) или даже MySQL, + размазанная по нескольким серверам NFS (или ftp или samba) для хранения файлов.
но в коллективе есть мнение, что оракл - "наше все" и ещё не такое переварит.

допускаю что могу всего не знать, и интересует сообщества на тему вариантов:
- Oracle + blob
- Oracle + NFS (samba, ftp)
- Postgre + NFS (samba, ftp)
- MySQL+ NFS (samba, ftp)
- какие-то еще варианты?
в разрезе критериев целесообразности, надежности и требовательности к железу.
25 авг 14, 15:26    [16489037]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 939
очепятка
интересует мнение сообщества на тему...
25 авг 14, 15:29    [16489046]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Dimitry Sibiryakov
Member

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

Кифирчик
но в коллективе есть мнение, что оракл - "наше все" и ещё не такое
переварит.

Не надо идти против коллектива. Особенно если он включает Oracle DBA и менеджера,
оплатившего его лицензии и техподдержку. Если таковых в коллективе нету - тыкать одним
пальцем на их отсутствие, а другим крутить у виска ибо такого размера проект без них не
обойдётся.

Posted via ActualForum NNTP Server 1.5

25 авг 14, 15:36    [16489100]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11473
Даже пророку грех отказываться от "просто файлов" там, где "доктор прописал".
25 авг 14, 16:48    [16489496]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
scf
Member

Откуда:
Сообщений: 1486
80мб/сек - это как бы дофига.
Между этими файлами и СУБД не должно быть ничего общего в принципе. Я не знаю требований к надежности, но самый простой вариант - n обычных машин с nginx + любимый_протокол_для_потоковой_заливки_файлов.

Итого в базе будет храниться только текстовый URL (или несколько URL-ов, если вам нужна надежность и вы будете лить файлы на несколько машин параллельно).

Но, конечно, если руководство богато, если руководству стремно и если руководство хочет купить сановскую (уже оракловую стойку с официальным саппортом - то пишите хранимки для чтения-записи файлов, в оракле есть соответствующий пакет, и переложите весь головняк с IO на DBA.
25 авг 14, 21:04    [16490471]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
scf
80мб/сек - это как бы дофига.

80мб/сек - зависит от того, что иметь в виду.
Если тупо transfer rate, т.е. перекачка какого-нибудь файла, то это на уровне одиночного SATA-диска примерно 8-летней давности (если не старше).
Если нужно лить или читать сразу много "файлов", т.е. потоков, каждый из которых 60-80мб/сек, то это да, будет дофига, потому что sequential read/write будет перебиваться, и получится наполовину random/io. А чтобы получить 600мб/сек потребуется raid 10 из штук 6 SSD, не меньше.
И это если гонять файлы. Если же хранить все это в БД, то наверное, скорость надо поделить как минимум на 1.5, а на практике получится и больше.

В данном случае, да, +1, с базой будет и тормознее, и геморройнее в смысле резервных копий. Файлы можно "резервировать" по частям, это будет гораздо быстрее.
25 авг 14, 22:04    [16490732]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
БЭНДЕРовец
Guest
Кифирчик, если уже есть Oracle - то его + GlusterFS, размазанный по десятку-другому серверов-хранилищ для хранения медиаконтента. Если оракла нету - то Postgres + тот же GlusterFS. Для доступа к медиа - парочка серверов Nginx. Как-то так, думается. Если хочется упороться - то для медиаконтента можно что-то типа GridFS заюзать, там вроде даже нативная интеграция с Nginx имеется
25 авг 14, 23:23    [16491121]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 939
чаша весов в сторону файлов фактически окончательно перевесила )))
отдельного oracle dba - нет.

хранение видимо будет на нескольких сетевых хранилищах, терабайт по 20..50.
и наверно получится размазать по ним нагрузку, например от каждого типа источника писать в физически отдельное хранилище.
с чтением проблем не много... клиент указывает временной интервал, например "сутки", и может покурить с минутку, пока подгрузится гигабайта 2, далее работать с локальными копиями. либо асинхронно тянуть нужные блоки.
5 пользователей не будут постоянно жарить хранилище запросами.

GlusterFS - по описаниям очень заманчиво, но в статье вот пишут что производительность заметно падает, по сравнению с обычным IO (http://habrahabr.ru/post/216461/)
да и клиент может быть на win, а с этим у GlusterFS только через самбу.

GridFS, Nginx - как я понимаю заточка на "много пользователей на чтение". есть сомнения что это актуально в моей задаче.

получается... у сетевых хранилищ стоит либо винда Storage Server, либо unix подобное, то есть либо шара на NetBIOS, либо NFS or samba, от туда же и клиенты читают.
и без блобов, остальные задачи будут пустяковыми для любой СУБД

так?
26 авг 14, 11:00    [16492473]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9892
kdv
scf
80мб/сек - это как бы дофига.

80мб/сек - зависит от того, что иметь в виду.
...

IMHO для Oracle - это все же дофига. Перед выбором решения, я бы тестировал и тестировал....

Может даже на сетевой карте заткнуться. Если клиент будет по сети стучаться. К вопросу "интерконнекта" клиента и сервера тоже нужно ответственно подходить (скорость эзернетов она сильно "бумажная", если на коробке написано 1G/10G, не факт, что Вы сможете их выжать в реальных условиях ))) на конкретном софте).

БД привлекательна тем, что обеспечивает транзакционность, логическую целостность и надежность хранения. Когда "факты" в БД присутствовать будут, а файлы на диске нет (и наоборот) - это будет печалька, которую очень сложно будет разгрести руками.

200 Tb проектируемого объема - тоже сильно не мало.

IMHO & AFAIK. Тестировать и тестировать
26 авг 14, 11:49    [16492879]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9892
kdv
...Если нужно лить или читать сразу много "файлов", т.е. потоков, каждый из которых 60-80мб/сек, то это да, будет дофига, потому что sequential read/write будет перебиваться, и получится наполовину random/io....

Солидарен. Поток/потоку рознь. Если нужно в реал-тайме писать с устройства и оттуда будут приходить небольшие блоки, то задача не так уж и проста.

С точки зрения дисков, как раз БД должна более менее гладкую и предсказуемую нагрузку генерировать IMHO. Но тут не факт, что вообще скорости хватит. Сетевая карта + процессор + потери времени на обработку прерывания от сетевой карты (в том числе и клиент).

IMHO & AFAIK
26 авг 14, 11:56    [16492931]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11473
Leonid Kudryavtsev
БД привлекательна тем, что обеспечивает транзакционность, логическую целостность и надежность хранения
... которые требуют нехилого такого оверхеда.
Когда "факты" в БД присутствовать будут, а файлы на диске нет (и наоборот) - это будет печалька, которую очень сложно будет разгрести руками
Руки должны быть при проектировании, разработке и тестировании. Остальное - забота администратора системы.

P.S. "Файловый мусор" - ни разу не трагедия.
26 авг 14, 11:59    [16492953]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 939
какую нагрузку на запись обеспечивают сетевые хранилища, например это dell-powervault-nx3000.html?
если только запись?
если запись/чтение - 60/40?
только чтение?
хотя бы примерно
26 авг 14, 12:14    [16493076]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11473
"Dell+PowerVault+NX3000"+IOPS?
26 авг 14, 12:35    [16493245]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9892
Basil A. Sidorov
... которые требуют нехилого такого оверхеда...

ну или все эти средства разрабатывать самому...
+

1. Транзакционность и так понятно
2. Целостность (логическая)
3. Наличие инструментария для резервного копирования.
4. та же самая масштабируемость и распределение нагрузки. Oracle, вроде (не уверен с BLOB/SecuFiles), все изменения будет накапливать в буфер кэшь и скидывать на диск параллельными процессами. Т.е. получим нехилый такой кэшь на запись (с гарантией транзакционности!). Даже если хранилище заткнется в пике, на буффер кеше можно будет жить дальше (главное, что бы Log Writer не заткнулся).
5. С БД, если сотворить что-то типа RAC'а, можно физически разнести читателей и писателей на разные ноды. Что бы друг другу не мешали.

Хотя, если 400 Tb это чисто данных, мне даже представить себе такое сложно (без относительно к БД/не БД). Это сколько же шпинделей планируется в устройстве хранения? С учетом RAID. И какое будет время восстановления из бекапа всего этого чуда, если упадет.(без относительно к БД/не БД).

Ну и выбор системы хранения и его организация, вообще не тривиально. Как и сеть (в данном форуме сталкивался с людьми, которые на сети 10 G Ethernet обломились по крупному)

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

В общем, задача не простая и творческая. С неплохим бюджетом ))).

Basil A. Sidorov
P.S. "Файловый мусор" - ни разу не трагедия.

На мой взгляд "трагедия". С которой, лично у нас, было вообще не понятно, что делать

Ладно, мы данные обрабатывали не критические, пара десятков-сотен пропавших записей (да еще известно каких) это было решаемо (заказчик руками мог восстановить или начхать).
26 авг 14, 13:00    [16493414]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11473
Leonid Kudryavtsev
ну или все эти средства разрабатывать самому...
XADisk/TrueZIP
Это если кровь из носу нужна транзакционность.
На мой взгляд "трагедия"
Именно файловый мусор - ни разу не трагедия. Ничего, кроме небольшой потери места в хранилище.

P.S. Спойлер даже комментировать не буду.
26 авг 14, 13:48    [16493839]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 939
Basil A. Sidorov
"Dell+PowerVault+NX3000"+IOPS?

ох как не любит производитель такие характеристики выкладывать
удалось найти под одним из хранилищ цифру в 15К IOPS.
но, как я понимаю, без точного знания размера блоков и latency, точность расчетов будет примерно как "на глаз"
26 авг 14, 13:53    [16493882]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11473
Кифирчик
но, как я понимаю, без точного знания размера блоков и latency, точность расчетов будет примерно как "на глаз"
Выбранная вами железка это Windows Storage Server под маркой Dell.
Сколько IOPS выдадут шесть дисков под общецелевой системой? Ничего выдающегося.
26 авг 14, 13:57    [16493920]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Кифирчик
Member

Откуда: СПб
Сообщений: 939
мдя... акцент вопроса сместился в сторону от "выбора СУБД" к подбору дискового хранилища способного гарантированно переварить 80мб/сек
+ подбор методики как это можно посчитать зная характеристики дисков и сетевых интерфейсов
26 авг 14, 14:18    [16494082]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9892
Basil A. Sidorov
XADisk/TrueZIP

Thanks. На будущее почитаю. Не сталкивался

С тера-байтами не работал, было максимум под сотни тысяч записей изображений (TIFF в пару сотен Mb + директория с сотней нарезанных .JPG, суммарный объем сотни Gb).

Поддерживали хранение и в файлах и в БД. Но уже при 10-45 тыс изображений, "файловая помойка" жутко доставала. Т.ч. best practics рекомендовали положить все в БД и не париться. Ситуация, когда приезжаешь на территорию заказчика (и/или присылают копию) и файловое хранилище не сходится с текстовой БД - были почти у всех заказчиков. Толи софт периодически глючил, то ли админы/пользователи шаловливыми ручками баловались, х.з. Положили в БД, данные лежат, черный ящик, дальше вопрос прикладной апликухи. Ну и один протокол доступа на все (Net80) + единая система безопасности для нас было важно.
26 авг 14, 15:34    [16494748]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11473
Leonid Kudryavtsev
Поддерживали хранение и в файлах и в БД. Но уже при 10-45 тыс изображений, "файловая помойка" жутко доставала
У нас - строго наоборот: от хранения в базе отказались ещё до моего устройства, а вот в файлах без особых проблем лежало более двух миллионов файлов и никого особо не беспокоя. Более шести лет и около полутерабайта данных. Некоторое время назад - перенесли с локальных дисков на iSCSI-том хранилища.
26 авг 14, 15:50    [16494885]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
YAMB
Member

Откуда:
Сообщений: 2
Кифирчик,

2 окт 14, 22:38    [16653248]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
YAMB
Member

Откуда:
Сообщений: 2
Кифирчик,

http://www.mysql.com/why-mysql/benchmarks/
2 окт 14, 22:40    [16653254]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
roden
Member

Откуда:
Сообщений: 741
Кифирчик
мдя... акцент вопроса сместился в сторону от "выбора СУБД" к подбору дискового хранилища способного гарантированно переварить 80мб/сек
+ подбор методики как это можно посчитать зная характеристики дисков и сетевых интерфейсов

ИМХО действительно стоит оттолкнуться от возможностей железа, потом посчитать, что же конкретно (и сколько) будет непосредственно храниться в самой СУБД и вопрос с выбором СУБД+... скорее всего упростится
9 окт 14, 11:50    [16680902]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9892
roden
ИМХО действительно стоит оттолкнуться от возможностей железа, потом посчитать, что же конкретно (и сколько) будет непосредственно храниться в самой СУБД и вопрос с выбором СУБД+... скорее всего упростится

IMHO прямо противоположное.

Возможности железа сильно зависят от архитектуры. 80 Mb/s _одним_потоком_последовательной_записью_ переварит даже тормозной дисктопный винт на 5400 об/мин.

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

Если я правильно помню (понимаю), например, в файловой системе ZFS вся запись последовательная. Т.е. при записи нескольких потоков на один шпиндель - теоретически должен быть достаточно большой выигрышный в скорости записи. Хотя, если используются системы хранения данных, как они физически работают сам черт ногу сломит.

Аналогично, насколько я знаю, в задачах загрузки часто делают промежуточное хранилище. Пользователи льют данные в некую промежуточную область. Там они могут как-то дорабатываться. И лишь затем заливаются в основное хранилище.
9 окт 14, 14:02    [16681859]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД и технологии. Много много медиа, среда - юниксподобное.  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
Leonid Kudryavtsev
Basil A. Sidorov
XADisk/TrueZIP

Thanks. На будущее почитаю. Не сталкивался

С тера-байтами не работал, было максимум под сотни тысяч записей изображений (TIFF в пару сотен Mb + директория с сотней нарезанных .JPG, суммарный объем сотни Gb).

Поддерживали хранение и в файлах и в БД. Но уже при 10-45 тыс изображений, "файловая помойка" жутко доставала. Т.ч. best practics рекомендовали положить все в БД и не париться. Ситуация, когда приезжаешь на территорию заказчика (и/или присылают копию) и файловое хранилище не сходится с текстовой БД - были почти у всех заказчиков. Толи софт периодически глючил, то ли админы/пользователи шаловливыми ручками баловались, х.з. Положили в БД, данные лежат, черный ящик, дальше вопрос прикладной апликухи. Ну и один протокол доступа на все (Net80) + единая система безопасности для нас было важно.

Хадууууууууупппппппп
10 окт 14, 10:56    [16685990]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить