Разве не хорошо использовать огромные «документы» в MongoDB?

Question

Поскольку мы можем структурировать MongoDB любым удобным для нас способом, мы можем сделать это следующим образом

{ products:
  [
    { date: "2010-09-08", data: { pageviews: 23, timeOnPage: 178 }},
    { date: "2010-09-09", data: { pageviews: 36, timeOnPage: 202 }}
  ],
  brands:
  [
    { date: "2010-09-08", data: { pageviews: 123, timeOnPage: 210 }},
    { date: "2010-09-09", data: { pageviews: 61, timeOnPage: 876 }}
  ]
}

, так как мы добавляем к нему данные день за днем, документ products и документ brands будут становиться все больше и больше. Через 3 года в products и brands будет тысяча элементов. Разве это не хорошо для MongoDB? Должны ли мы разбить его еще на 4 документа:

{ type: 'products', date: "2010-09-08", data: { pageviews: 23, timeOnPage: 178 }}
{ type: 'products', date: "2010-09-09", data: { pageviews: 36, timeOnPage: 202 }}
{ type: 'brands', date: "2010-09-08", data: { pageviews: 123, timeOnPage: 210 }}
{ type: 'brands', date: "2010-09-08", data: { pageviews: 61, timeOnPage: 876 }}

Так что через 3 года будет только 2000 "документов"?

Answer 1

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

Что, вероятно, будет для вас лучшей моделью:

class Log
  include Mongoid::Document

  field :type
  field :date
  field :pageviews,    :type => Integer
  field :time_on_page, :type => Integer
end

Это даст вам документы, которые выглядят так:

{_id: ..., date: '2010-09-08', type: 'products', pageviews: 23, time_on_page: 178}

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

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

Log.collection.update({'type' => 'products', 'date' => '2010-09-08'}, {'$inc' => {'pageview' => 1}})

Answer 2

Я не эксперт MongoDB, но 1000 не "огромный".Кроме того, я бы серьезно усомнился в любой разнице между 1 документом верхнего уровня, содержащим 4000 субэлементов, и 4 документами верхнего уровня, каждый из которых содержал 1000 субэлементов, - один из этих вопросов шесть против одного против полдюжины других.1001 *

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

Answer 3

Опять же, это зависит от вашего варианта использования запросов.Если вы действительно заботитесь об одном элементе, например, товарах в день:

{тип: 'товары', дата: "2010-09-08", данные: {просмотров страниц: 23, timeOnPage: 178}}

тогда вы можете включить несколько дней в одну дату.

{тип: 'продукты', {дата: "2010-09-08", данные: {просмотров страниц: 23, timeOnPage: 178}}}

Мы используем что-то вроде этого:

{type: 'products', "2010": {"09": {"08": data: {pageviews: 23, timeOnPage:178}}}}}

Таким образом, мы можем увеличивать по дням: {"$ inc": {"2010.09.08.data.pageviews": 1}}

Может показаться сложным, нопреимущество в том, что вы можете хранить все данные о типе в 1 записи.Таким образом, вы можете извлечь одну запись и получить всю информацию.

Answer 4

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

Таким образом, каждый добавленный документ будет отдельной записью в коллекции, имеющей собственный идентификатор. Хотя размер монго-документа ограничен 4 МБ, его в основном достаточно для размещения текстовых документов. И вам не нужно беспокоиться о количестве растущих документов в монго, в этом суть баз данных на основе документов.

Единственное, о чем вам нужно беспокоиться, это размер коллекции БД. Его ограничено 2 ГБ для 32-битных систем. Потому что MongoDB использует отображенные в память файлы, так как они привязаны к доступной адресации памяти. Это не проблема для 64-битных систем.

Надеюсь, это поможет

Answer 5

Вы говорили о том, как вы собираетесь обновлять данные, но как вы планируете их запрашивать? Это, вероятно, влияет на то, как вы должны структурировать свои документы.

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

Я бы вообще предложил второй вариант, который вы предложили, но это зависит от вопросов, приведенных выше.

Примечание. 4 МБ - произвольный предел, и он скоро будет повышен; вы можете перекомпилировать сервер для любого ограничения, которое вы хотите на самом деле.