Структура базы данных CouchDB - лучшая практика

Question

Будучи новичком в CouchDB, просто хотел обсудить лучшие практики структурирования базы данных и документов. Мой опыт работы с MySQL, поэтому я все еще пытаюсь разобраться с базами данных на основе документов.

Чтобы описать систему, у нас есть несколько клиентов, каждый из которых имеет доступ к отдельному веб-сайту с отдельными данными. Данные каждого клиента будут разбиты на собственную базу данных. В каждую базу данных будут постоянно вставляться данные (каждые 5 минут, как минимум в течение года) для регистрации событий. Новый документ создается каждые 5 минут с отметкой времени и значением. Нам также необходимо хранить некоторую информацию о клиенте, который является единым документом, который никогда не обновляется (если так, очень редко).

Ниже приведен пример того, как выглядит одна клиентская база данных ...

{
    "_id": "client_info",
    "name": "Client Name",
    "role": "admin",
    ....
},
{
    "_id": "1199145600",
    "alert_1_value": 0.150
    "alert_2_value": 1.030
    "alert_3_value": 12.500
    ...
    ...
},
{
    "_id": "1199145900",
    "alert_1_value": 0.150
    "alert_2_value": 1.030
    "alert_3_value": 12.500
    ...
    ...
},
{
    "_id": "1199146200",
    "alert_1_value": 0.150
    "alert_2_value": 1.030
    "alert_3_value": 12.500
    ...
    ...
},
etc...literally millions more of these every 5 minutes...

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

Спасибо!

Answer 1

Используйте метку времени в качестве своего идентификатора, если он гарантированно будет уникальным.Это значительно улучшает способность кушетки поддерживать его b-дерево для таких вещей, как создание и поддержание видов, а также документов, а также сэкономит вам len([_id]) места.

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

Этот тип неизменяемых данных отлично подходит для CouchDB.Когда данные добавляются в кушетку, вы можете периодически запускать обновление представления, и представление будет строить данные запроса заранее.Это означает, что, в отличие от SQL, где вы вычисляете эту агрегированную дату на лету каждый раз, couch будет просто читать эти данные, кэшированные в промежуточных узлах b-дерева представления.Гораздо быстрее.

Таким образом, типичный подход CouchDB: - моделировать ваши транзакции, чтобы минимизировать количество документов (т. Е. Денормализовать) - при необходимости использовать разные представления для фильтрации или сортировки результатов по-разному.

Iдумаю, вы захотите получить статистические данные за этот период времени.Скорее всего, это будет намного эффективнее (с точки зрения процессора) в эрланге;так что взгляните на https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_query_servers.erl#L172-205, чтобы увидеть, как они сделаны.