Какую ООБД выбрать?

Question

[Anton]

Доброго времени суток!

Возник один проект в голове с использованием больших данных. Понял, что реляционная база данных мне не подойдет, так как основной информацией будут картинки и начал смотреть в сторону объектных БД. Так и не смог определиться какую выбрать для работу. Посоветуйте какую БД выбрать (нашел информацию только по casandra и jasmine), чтобы по производительности она была хорошая и существовали механизмы подключения к ней из приложение (думаю написать приложение на Java).

Comments

[Алексей Уколов]

Вы понимаете, что вы просите посоветовать БД для сферического проекта в вакууме?

[AlikDex]

мускульная бд с 15млн картинок очень даже хорошо себя чувствует. Правда занимает почти 6гб, но это мелочи, правда? ;)

[Oleg Shevelev]

Чем файловая система для ханения файлов не подходит? А мета-информация в любой удобной для вас базе.

[Fixid]

Что в Вашем понимании большие данные? Это сколько?
Присоединяюсь к хранению в mysql (хорошо работало на 15гб) или в фс.

[Oleg Shevelev]

AlikDex: база данных занимает 6 гигабайт? Так это не много. Тут есть что и как пошардировать. Вот если бы проблема была такой: 600 гигабайт и индексы не влезают в оперативку - было бы интересней.

[AVKor]

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

Не прослеживается никакой связи. Ну, картинки - и что? При чём тут RDBMS vs OODBMS?

[Anton]

AVKor: Предполагается, что приложение будет использоваться в прикладной задаче, например, поиск дубликатов картинок к примеру.

[AVKor]

Антон: Ну так и что? RDBMS тоже созданы для решения прикладных задач, как и вообще все СУБД.

Answer 1

[tex0]

посмотрите в сторону Berkeley DB , может подойдет.

Comments

[Oleg Shevelev]

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

Подходит как маленький кирпичик большой системы, но работает шустро, это да. Если на то пошло можно обратить внимание на LevelDB, правда там уже несколько далеко не одинаковых реализаций.

[tex0]

Oleg Shevelev: Вообще для неё чаще всего пишется обёртка с необходимым функционалом. То что она голая изначально - да, но если грамотно подойти к делу, можно получить неслабую производительность своей системы

[Oleg Shevelev]

tex0: разве я как-то по другому сказал?:) Сможете написать своё решение - это ведь отлично:)

[tex0]

Oleg Shevelev: "разве я как-то по другому сказал?:)"
я просто обозначил автору выбор - либо вложить силы и запилить собственную обёртку для юзания berkeley, либо искать дальше уже готовое. Это раз.
Второе - сразу что-то не полез смотреть про LevelDB. Посмотрел. Почитал её основные фичи. Возник вопрос - в чем её преимущество перед berkeley, кроме как "Data is automatically compressed using the Snappy compression library" ?

[Oleg Shevelev]

tex0: по своей сути они в одной категории, levelDB пока не использовал, поэтому по описаниям это тот же Berkeley DB + N функциональности в комплекте, более коммерческий расчёт на больший объём данных с большей сложностью. В любом случае - это надо на практике выяснять, читать код, читать документацию, ну в общем... читать и думать.

Answer 2

[Пума Тайланд]

Хранить картинки в БД идиотизм

Comments

[Oleg Shevelev]

Смотря какая база данных. Представьте N миллионов мелких изображений, каждое очень маленькое.
В файловой системе:
1. есть разумный лимит на количество файлов в одной директории - способ бороться: разбивать на вложенные подкаталоги по хеш-функции
2. сложность в горячем дублировании - либо всё в RAID либо копии каталогов с частью горячих файлов, особенностью является - необходимость за всем уследить, а так не проблема
3. накладные расходы на хранение действительно мелких файлов (читаем про блоки, сектора файловой системы)
4. всё равно нужна какая-то база которая знает о файлах
5. нужно время от времени удалять и синхронизировать файлы если есть несколько копий горячих файлов
6. нужен алгоритм горячих файлов, встроенного в файловую систему вроде бы нет:)

В базе данных заточенных под файлы (их ещё иногда объектными базами называют):
1. файлы хранятся в больших блобах
2. индексирование мета-инфорации о файлах в классическом БД виде
3. простое удаление, перемещение, обновление
4. часто быстрый и распределённый доступ (если бд это позволяет)
5. проще дописывать дополнительный функционал

Но сферически картинки в базе - это конечно да, идиотизм.

[Пума Тайланд]

1)Это все равно дешевле чем в базе это делать и читать из неё.
2)Это легче чум дублировать бд.
3)В мире где 4 ТБ диски стоят уже в почти самых дешевых серверах , я уже забыл про это думать, вот лет 10 назад стоило об этом думать.
4)Нужна и пусть знает.
5)Ну надо и что как будто если они в бд это делать не надо.
6)Какие нахрен горячие файлы.

Это какие именно базы то ? Поименно пожалуйста.

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