Возник один проект в голове с использованием больших данных. Понял, что реляционная база данных мне не подойдет, так как основной информацией будут картинки и начал смотреть в сторону объектных БД. Так и не смог определиться какую выбрать для работу. Посоветуйте какую БД выбрать (нашел информацию только по casandra и jasmine), чтобы по производительности она была хорошая и существовали механизмы подключения к ней из приложение (думаю написать приложение на Java).
AlikDex: база данных занимает 6 гигабайт? Так это не много. Тут есть что и как пошардировать. Вот если бы проблема была такой: 600 гигабайт и индексы не влезают в оперативку - было бы интересней.
Возник один проект в голове с использованием больших данных. Понял, что реляционная база данных мне не подойдет, так как основной информацией будут картинки и начал смотреть в сторону объектных БД.
Не прослеживается никакой связи. Ну, картинки - и что? При чём тут RDBMS vs OODBMS?
Там проблема со скудностью функционала, например нет возможности вставить данные и получить уникальный ключ - ключ надо вычислять заранее и решать вопрос с колизиями самостоятельно.
Подходит как маленький кирпичик большой системы, но работает шустро, это да. Если на то пошло можно обратить внимание на LevelDB, правда там уже несколько далеко не одинаковых реализаций.
Oleg Shevelev: Вообще для неё чаще всего пишется обёртка с необходимым функционалом. То что она голая изначально - да, но если грамотно подойти к делу, можно получить неслабую производительность своей системы
Oleg Shevelev: "разве я как-то по другому сказал?:)"
я просто обозначил автору выбор - либо вложить силы и запилить собственную обёртку для юзания berkeley, либо искать дальше уже готовое. Это раз.
Второе - сразу что-то не полез смотреть про LevelDB. Посмотрел. Почитал её основные фичи. Возник вопрос - в чем её преимущество перед berkeley, кроме как "Data is automatically compressed using the Snappy compression library" ?
tex0: по своей сути они в одной категории, levelDB пока не использовал, поэтому по описаниям это тот же Berkeley DB + N функциональности в комплекте, более коммерческий расчёт на больший объём данных с большей сложностью. В любом случае - это надо на практике выяснять, читать код, читать документацию, ну в общем... читать и думать.
Смотря какая база данных. Представьте N миллионов мелких изображений, каждое очень маленькое.
В файловой системе:
1. есть разумный лимит на количество файлов в одной директории - способ бороться: разбивать на вложенные подкаталоги по хеш-функции
2. сложность в горячем дублировании - либо всё в RAID либо копии каталогов с частью горячих файлов, особенностью является - необходимость за всем уследить, а так не проблема
3. накладные расходы на хранение действительно мелких файлов (читаем про блоки, сектора файловой системы)
4. всё равно нужна какая-то база которая знает о файлах
5. нужно время от времени удалять и синхронизировать файлы если есть несколько копий горячих файлов
6. нужен алгоритм горячих файлов, встроенного в файловую систему вроде бы нет:)
В базе данных заточенных под файлы (их ещё иногда объектными базами называют):
1. файлы хранятся в больших блобах
2. индексирование мета-инфорации о файлах в классическом БД виде
3. простое удаление, перемещение, обновление
4. часто быстрый и распределённый доступ (если бд это позволяет)
5. проще дописывать дополнительный функционал
Но сферически картинки в базе - это конечно да, идиотизм.
1)Это все равно дешевле чем в базе это делать и читать из неё.
2)Это легче чум дублировать бд.
3)В мире где 4 ТБ диски стоят уже в почти самых дешевых серверах , я уже забыл про это думать, вот лет 10 назад стоило об этом думать.
4)Нужна и пусть знает.
5)Ну надо и что как будто если они в бд это делать не надо.
6)Какие нахрен горячие файлы.
Это какие именно базы то ? Поименно пожалуйста.
Все решения которые были завязаны на хранение файлов в базе были жутко неудачными и жутко тормозными, вспоминается ещё гридфс в одном из последних проектов, конечно давайте на 10 серверов заупстим кластер бд когда на файлухе все и на одном будет прекрасно работать.
Простой
Простой
Простой
Средний
