Я изучаю различные способы хранения загруженных пользователями файлов (все являются документами MS Office или аналогичными) на нашем высоконагруженном веб-сайте. В настоящее время он предназначен для хранения документов в виде файлов и имеет базу данных SQL, в которой хранятся все метаданные для этих файлов. Меня беспокоит рост производительности сервера хранения и SQL-сервера, когда количество документов достигает сотен миллионов. Я читал много полезной информации о CouchDB, включая его встроенную масштабируемость и производительность, но я не уверен, как хранение файлов в виде вложений в CouchDB будет сравниваться с хранением файлов в файловой системе с точки зрения производительности.
Кто-нибудь использовал кластеры CouchDB для хранения БОЛЬШИХ объемов документов и в среде с высокой нагрузкой?
В ответ Redmumba. Команде разработчиков CouchDB будут интересны сбои, которые вы видите.
Вдобавок ко всему: вся архитектура CouchDB основана на принципе раннего отказа. Все подсистемы, а также главный сервер спроектированы таким образом, чтобы завершать работу и немедленно восстанавливать работу при возникновении ошибки. «сбои» - это просто часть нормальной работы, это делает программное обеспечение более надежным (по иронии судьбы, но в этом вся философия Erlang).
Что касается вопроса, то CouchDB подойдет под требования достаточно хорошо. Потоковая передача вложений CouchDB определенно связана с вводом-выводом, очень близким к скорости файловой системы. Документы CouchDB предоставляют вам все необходимое пространство для метаданных, а вложения документов хранят двоичные данные рядом. Для этого не нужно использовать разные системы.
Опыт, который мы имели с CouchDB в среде с высокой нагрузкой, был не таким уж большим; мы видели много нестабильности (частые сбои), которые, как указывают списки рассылки, можно просто решить, установив демон монитора, чтобы перезапустить его в случае сбоя. Мы не используем большие наборы значений, но мы обращаемся к ним довольно часто, но имейте это в виду, поскольку большие файлы означают более длительное время соединения. Это означает, что снижение скорости передачи будет еще более болезненным в зависимости от пропускной способности и размера файла.
Я бы порекомендовал изучить MongoDB с поддержкой GridFS. MongoDB подойдет вам (в зависимости от вашей спецификации), потому что вы выглядите так, будто у вас есть дополнительные метаданные, которые вы, возможно, захотите сохранить вместе с файлом; поскольку он ориентирован на документы, вы сможете хранить эти метаданные вместе с двоичными файлами. С этой целью, GridFS позволяет хранить большие файлы в базе данных.
BBC вроде бы успешно использует. Я считаю, что на TED есть видео, в котором обсуждают, что они с ним делают.
Я не использовал CouchDB, но у меня есть опыт работы с SQL Server. Если вы храните файлы на SQL-сервере (varbinary (max) физически хранится в файловой системе), я думаю, вам будет лучше. Он будет масштабироваться до миллиардов строк, а производительность, независимо от используемой базы данных (oracle, sql server и т. Д.), Будет зависеть от дизайна приложения и оборудования. Я думаю, это ключ. Проблемы с производительностью почти всегда являются результатом плохо спроектированных приложений или инфраструктуры, а не базовой базы данных корпоративного класса.