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