Разрабывается онлайн-система видеонаблюдения для режимного предприятия. Сделана как веб-портал на базе NodeJs в связке с licode. К ней прикручен еще документооборот, связанный с работой охраны (сдача смен, подписывание протоколов, реестры и т.д.). Документооборот довольно небольшой - около 500 тыс. документов в год (PDF, в основном), а вот видео занимает огромное количество места, т.к. по ТЗ обязано хранится 1 год. Встал вопрос, какую БД выбрать для проекта. Разработчик настаивает на PostgreSQL. Я почитал форумы, хвалят MongoDB.
Подскажите, если в плане докуметооборота база будет не нагружена вообще, фактически, но видео будет храниться на десятки терабайт, то потянет ли это Postgre? Или может весь функционал портала и документооборот завести на Postgre, а видео положить отдельно в Mongo?
На stackoverflow некоторые люди хранили само видео в MongoDB.
Вы предлагаете видеофайлы хранить на диске, а в БД только ссылки на них?
У меня размер одного видеофайла = 300-600 МБ.
там хранили в GridFS а не именно в базе, которая в монге позволяет сделать что-то типа распределенного файлового хранилища. Однако я бы не рекомендовал его использовать так как есть более удобные способы организовать хранение файлов на диске. База данных тут не особо влияет.
Разработчик настаивает на PostgreSQL. Я почитал форумы, хвалят MongoDB.
Если у вас нет экспертизы в этом вопросе, доверьтесь разработчику. MongoDB очень хорошо распиарена и не более, PostgreSQL намного более надежная база данных.
GridFS - это (грубо говоря) набор функций которые работают с MongoDB, можно назвать синтаксическим сахаром. В итоге файлы хранятся в самой базе нарезанными на куски. И ими можно оперировать обычными функциями find/update/insert
И вообще это на уровне драйвера, возможно сама монга ничего не знает про GridFS (т.е. в монге нет спец. функционала под GridFS)
lega: не очень правильно сравнивать правильно настроенное что-то с дефолтом. Ну и опять же разница именно в модели хранения данных, документоориентированность это хорошо, но как только в монге появляется создавать связи между документами жизнь превращается в маленький ад. Я за монгой уже года два не слежу, может чего и поменялось, но не думаю.
По поводу шард - шарды нужны очень редко, по сути тогда когда индексы в память уже не помещаются. Для примера у меня сейчас есть проекты где используются сервера с 256 гигоа оперативки и там уже нужны шарды. Но в моем случае нет сложных зависимостей по данными и потому можно спокойно разделить это дело.
Есть масса вариантов как решить проблемы и я отношу шардинг к "последней мере".
lega: вот и я о том же. Для подавляющего большинства проектов я предпочитаю использовать монгу только в качестве хранилища для агрегаций данных, хотя в последнее время больше нравится использовать эластику для этого.
Сергей Протько: А вы не пробовали?, для упрощения миграции, все данные хранить в json(b) поле, а потом когда поле устоится или этих полей накопится - переводить в колонки. При этом orm/mapper должен это учитывать - минимальные правки в проекте.
lega: нет, в этом нет особо смысла. Я использую data mapper (Doctrine2) в качестве ORM, миграции генерируются автоматически (ну мол именно добавление/удаление/переименовывание пропертей), дописывать иногда приходится (если изменения совсем уж ломают BC) но в основном все происходит почти полностью автоматически.
в целом же возможно это специфика конкретных проектов, но как по мне это не очень здоровая ситуация... хотя подход имеет право на жизнь, все же не в jsonb дело а в связях между объектами.
Если структуру базы надо часто менять (например с точки зрения оптимизаций) есть и другие практики, типа того же event sourcing-а. Правда опять же все от задачи зависит.
Простой
Простой
Сложный
Простой
