Я занимаюсь разработкой системы, предназначенной для архивирования, поиска, загрузки, распространения мультимедиа и, следовательно, для обработки больших двоичных объектов.
В настоящее время я пытаюсь найти наилучший способ обработки BLOB-объектов. У меня ограниченные ресурсы для высокопроизводительных серверов с большим объемом памяти и огромными дисками, но я могу получить доступ к большому массиву готовых компьютеров средней производительности и подключить их к Интернету.
Поэтому я решил не хранить большие двоичные объекты в центральной реляционной базе данных, потому что тогда в худшем случае у меня был бы один очень тяжелый экземпляр базы данных, возможно, на одной средней машине. Не вариант.
Хранение больших двоичных объектов как файлов непосредственно в файловой системе и сохранение их пути в базе данных также несколько уродливо, и распределением придется управлять вручную, отслеживая различные копии самостоятельно. Я даже не хочу приближаться к этому.
Я посмотрел на CouchDB, и мне действительно нравится их одноранговый дизайн. Это позволило бы мне запустить распределенный кластер машин через Интернет, подразумевает:
- Низкая стоимость оборудования
- Распределение для резервирования и отработки отказа из коробки
- Легкий интерфейс REST
Так что, если я правильно понял, можно подытожить это следующим образом: Облако, как API и самоуправляемая, распределенная, реплицируемая система
Остальная часть системы выполняет обычные функции, которые выполняет любое обычное веб-приложение: обработка сеанса, безопасность, пользователи, поиск и тому подобное. Для этой части я все еще хочу использовать реляционную модель данных. (CouchDB заявляет , а не как замену реляционным базам данных).
Таким образом, у меня были бы все стандартные данные, включая метаданные BLOB в реляционной базе данных, но сами BLOB в CouchDB.
Видите ли вы проблему с этим подходом? Я что-то упустил? Можете ли вы придумать лучшие решения?
Спасибо!