Анализ производительности CouchDB

Question

Я разрабатываю дискуссионный форум для моего университета. Для этого для манипулирования данными я использую CouchDB в качестве базы данных.

Я испытываю трудности при проектировании структуры моего БД, чтобы максимизировать производительность моего БД.

Я хочу обсудить, какова хорошая практика проектирования базы данных документов.

1. Либо мы должны сделать только одну базу данных в качестве SQL и сделать 'n' нет. документов в базе данных.
2. Или мы можем сделать больше без базы данных, чтобы сгладить мою структуру базы данных. Это также уменьшит больше нет. документов, которые будут разработаны.

Answer 1

Вопросы, которые вам нужно задать, это просто: "Как вы хотите получить данные из вашей базы данных?"

Дизайн базы данных зависит от выполняемых запросов, а не от того, что доступно для хранения.

Это особенно важно для БД документов, таких как Couch, поскольку, несмотря на гибкую схему, в ней нет гибкой индексации. Под этим я подразумеваю, что из-за гранулярности данных позже, когда вам нужно задать вопрос, на который он не предназначен, ответ на этот вопрос может быть очень дорогим. Намного дешевле проектировать ваши представления и другие конструкции раньше, когда в базе данных мало данных, а не позже, когда у вас есть тысячи или миллионы строк.

СУБД, так как они, как правило, имеют более тонкую детализацию данных, имеют тенденцию быть более ловкими к новым запросам и тому подобным в более позднем возрасте. Документ БД, не так много.

Так что продумайте свои варианты использования заранее, спроектируйте их и спроектируйте на ранних этапах, теперь это гораздо менее безболезненно, чем позже.

Answer 2

Трудно сказать, как правильно подходить к моделированию ваших данных, так как вы не предоставляете много информации. Как правило, хотя вы хотите хранить как можно больше данных в одной базе данных, так как это позволяет индексировать их вместе (индексы не могут охватывать более одной базы данных).

Кроме того, поскольку в базе данных нет принудительного применения схемы, вы можете создавать различные типы записей в каждой базе данных. Например, нет ничего плохого в том, что информация о пользователе и записи форума находятся в одной базе данных.

Наконец, вы, скорее всего, захотите хранить сообщения и их ответы в разных записях. Это старая, но все еще актуальная дискуссия на эту тему: http://www.cmlenz.net/archives/2007/10/couchdb-joins

Приветствия.