В CouchDB я должен использовать _id для отношения и _changes? - PullRequest
Новая
       5

В CouchDB я должен использовать _id для отношения и _changes?

0 голосов
/ 21 января 2019

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

В настоящее время у меня есть около 50 тыс. Документов на базу данных. Прошло всего несколько месяцев с интенсивным использованием. Я ожидаю, что это вырастет много. Я делаю много .find() запросов манго, не много индексации; и быть честным, работая над структуризацией документов в реляционном стиле.

Например:

  • Сначала получите Project из ID.
  • Затем выполните запрос поиска, который:
    • захватывает все type:signature, где project_id: X.
    • захватывает все type:revisions, где project_id: X.

Причина этого в том, что я ОЧЕНЬ стараюсь не обновлять документы. Многие из этих документов создаются в автономном режиме, поэтому для меня очень важно избежать однократной записи рабочего процесса.

Сейчас я нахожусь в точке, откуда нет возврата, поскольку планирование становится довольно интенсивным. Если я хочу изменить то, как я делаю вещи сейчас, это лучшее время, пока это не стало слишком сумасшедшим.

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

Возможность сделать один звонок с захватом _all_docs, как это звучит для меня привлекательно: 

{
  "include_docs": true,
  "startkey": "project:{ID}",
  "endkey": "project:{ID}:\ufff0"
}

Пример того, как установлен ОДИН тип моих документов, выглядит так:

Основной документ 

{
    _id: {COUCH_GENERATED_1},
    type: "project",
    ..
    .
}

Подпись документа 

{
    _id: {COUCH_GENERATED_2},
    type: "signature",
    project_id: {COUCH_GENERATED_1},
    created_at: {UNIX_TIMESTAMP}
}

Изменить на основной документ 

{
    _id: {COUCH_GENERATED_3},
    type: "revision",
    project_id: {COUCH_GENERATED_1},
    created_at: {UNIX_TIMESTAMP}
    data: [{..}]
}

Мне было интересно, должен ли я сделать что-то вроде этого:

Основной документ : _id: project:{kuuid_1}

Подпись документа : _id: project:{kuuid_1}:signature:{kuuid_2}

Изменить на основной документ : _id: project:{kuuid_1}:rev:{kuuid_3}

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

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

1 Ответ

0 голосов
/ 22 января 2019

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

  1. Если в интересующих вас документах есть поле с именем project_id, вы можете создать индекс на project_id, который позволит вам получить все документыотносящиеся к известному project_id дешево.см. CouchDB Find
  2. Создание индекса MapReduce с ключом project_id например if (doc.project_id) { emit(doc.project_id)}.Индекс, который он создает, позволит вам извлекать документы по известному project_id с разумным использованием start_key & end_key при запросе представления.см. Введение в представления
  3. Как вы говорите, упаковка дополнительной информации в поле _id позволяет выполнять запросы диапазона в конечной точке _all_docs.

Если вы выберете ключевой дизайн: 

project{project_id}:signature{kuuid}

, то в первичном индексе базы данных будут сгруппированы все документы одного проекта.Помещение project_id перед символом «:» является подготовкой к будущей функции CouchDB, называемой «многораздельные базы данных», которая группирует логически связанные документы в своем собственном разделе, ускоряя и упрощая выполнение запросов в одном разделе.В твоем случае проект.Эта функция еще не готова, но, скорее всего, она будет иметь формат {partition_key}:{document_key} для поля _id, поэтому нет ничего плохого в том, чтобы подготовить документ _ids для него, когда он появится (см. Список рассылки CouchDB ! А пока будет работать запрос диапазона для _all_docs.

...