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

Question

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

Мне трудно найти структуру моего db, чтобы максимизировать производительность моего db.

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

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

Answer 1

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

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

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

Cheers.

Answer 2

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

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

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

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

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