Может ли RethinkDB содержать более нескольких сотен встроенных массивов?

На http://www.rethinkdb.com/docs/data-modeling/ , состояния:

Из-за предыдущего ограничения размер массива сообщений не должен превышать несколько сотен документов.

Если я намереваюсь вести статистику за 90 дней (3 месяца), вероятно, каждая дата имеет встроенный массив из примерно 10 регионов. Это означает, что 90*10=900. 900 — это не совсем несколько сотен.

Однако связанный с этим вопрос в разделе отношения MongoDB: встраивание или ссылка? предполагает, что MongoDB имеет ограничение из 16 МБ, что означает возможность размещения 30 миллионов твитов или примерно 250 000 типичных вопросов Stackoverflow в виде встроенных документов. Это много!

Однако это MongoDB. RethinkDB имеет ограничение в 10 МБ на документ. Который все еще должен быть значительно высоким. Либо документация RethinkDB может быть ошибочной. Или есть еще одна конкретная причина (не объясненная), почему Rethinkdb предлагает ограничиться несколькими сотнями встроенных массивов, хотя 10 МБ явно могут содержать гораздо больше.

Примерное представление о схеме, о которой я говорил:

DailyStat::Campaign
[
  {
    id: '32141241dkfjhjksdlf',
    days_remaining: 26,
    status: 'running',
    dates: [
      {
        date: 20130926,
        delivered: 1,
        failed: 1,
        clicked: 1,
        top_regions: [
          { region_name: 'Asia', views: 10 },
          { region_name: 'America', views: 10 },
          { region_name: 'Europe', views: 10 },
          { region_name: 'Africa', views: 10 },
          { region_name: 'South East Asia', views: 10 },
          { region_name: 'South America', views: 10 },
          { region_name: 'Northern Europe', views: 10 },
          { region_name: 'Middle East', views: 10 }
        ]
      },
      {
        date: 20130927,
        delivered: 1,
        failed: 1,
        clicked: 1,
        top_regions: [
          { region_name: 'Asia', views: 10 },
          { region_name: 'America', views: 10 },
          { region_name: 'Europe', views: 10 },
          { region_name: 'Africa', views: 10 },
          { region_name: 'South East Asia', views: 10 },
          { region_name: 'South America', views: 10 },
          { region_name: 'Northern Europe', views: 10 },
          { region_name: 'Middle East', views: 10 }
        ]
      },
      ...
    ]
  }
]

nosql mongodb rethinkdb rethinkdb-ruby
person Christian Fazzini    schedule 26.09.2013    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Краткий ответ:

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

Более длинный ответ:

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

person Joe Doliner    schedule 26.09.2013
comment
Иметь ввиду. Кампания рассчитана на 90 дней (встроенный массив). Каждый день может иметь до 10 регионов (встроенный массив внутри дня). Это 90*10. 900 — это размер массивов в документе кампании. Не 10 - person Christian Fazzini; 27.09.2013
comment
Ах, с общим количеством 900 это может оказаться неэффективным. Это зависит от того, как часто вы обновляете значения в документе. - person Joe Doliner; 28.09.2013

arrow_upward
1
arrow_downward

Упомянутое здесь «предыдущее ограничение» относится к следующему:

Недостатки использования встроенных массивов: любая операция с авторским документом требует загрузки всех постов в память. Любое обновление документа требует перезаписи всего массива на диск.

Это не столько ограничение, сколько компромисс производительности.

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

  1. встраивание твитов делает пользовательский документ большим
  2. каждый раз, когда вы вставляете твит, вам нужно обновлять весь пользовательский документ (который большой)
  3. наверное много вставок твитов на пользователя в день
  4. умножьте это на общее количество пользователей

С другой стороны, если хранить твиты в отдельной таблице, каждая вставка будет маленькой и дешевой.

В вашем случае вы ежедневно храните статистику. Обновление одного документа несколько раз в день не должно вызывать проблем с производительностью, даже если он занимает несколько МБ.

person jackbean818    schedule 07.10.2013