2016-04-28 3 views
1

Мой вопрос немного глубже, чем название.Как избежать повторяющихся записей в MongoDB?

В базе данных будут представлены миллионы (возможно, миллиарды в будущем) объектов. Пользователи будут связаны с этими объектами. Пользователи будут владельцами объектов. Объекты будут принадлежать нескольким пользователям (тысячам), и пользователи будут владеть миллионами объектов.

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

Я думал о хранении идентификаторов пользователей в массиве в каждом объектном документе, но я не уверен, что будет наказание за производительность. Кроме того, MongoDB имеет ограничение по 16 МБ для каждого документа, так что это еще один негатив. Поскольку каждый объект ID равен 12 байтам и 1 миллион пользователей, он потребляет 12 МБ документа. Должна быть лучшая структура.

Как я могу свести к минимуму эту запись отношений?

+0

Я считаю, что пользователи достаточно независимы, чтобы посвящать их каждой записи в коллекции. Если вы думаете, что многие из них будут повторяться, попробуйте извлечь что-то общее и создать коллекцию UserGroup, которая соединяет пользователей с их группой и их объектами. –

+0

@FelipeSulser хорошо, обычная вещь - это сам объект.Я могу сгруппировать их как определенного владельца объекта, но это не имеет смысла, поскольку оно просто хранит пользовательский массив в другом месте. – stackyname

+1

Возможный дубликат [MongoDB relations: embed or reference?] (Http://stackoverflow.com/questions/5373198/mongodb-relationships-embed-or-reference) – joao

ответ

0

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

В любом случае, я уверен, что если у меня есть 1000 объектов, просто не имеет смысла видеть все сразу. Я хотел бы видеть на страницах может быть 10 на страницу или неделю за неделей или день за днем.

Учитывая вышеизложенное Давайте рассмотрим этот сценарий.

  • У меня есть много документов.
  • На прошлой неделе мне принадлежало 2, вчера 5, сегодня 10 и список идет самостоятельно.

Предположим, у меня есть следующие документы.

Object1, Object2, Object5, Object6 ...

создам промежуточную коллекцию, где я буду хранить отношения, оно будет иметь одну запись для каждого объекта в день (или в час - Если потребность более зернистая поиск) ,

{ 
    "_id": "someId", 
    "object": "Object1", 
    "year": 2015, 
    "month": 12, 
    "day": 1, 
    "hour": 12, 
    "owned_by": [ 
     "stackyname", 
     "titogeo" 
    ] 
    }, 
    { 
    "_id": "someId", 
    "object": "Object2", 
    "year": 2015, 
    "month": 12, 
    "day": 1, 
    "hour": 12, 
    "owned_by": [ 
     "antman", 
     "titogeo" 
    ] 
    }, 
    { 
    "_id": "someId", 
    "object": "Object2", 
    "year": 2015, 
    "month": 12, 
    "day": 2, 
    "hour": 13, 
    "owned_by": [ 
     "batman", 
     "heman" 
    ] 
    } 

Это означает, что у меня есть документ отношений на объект в час. Когда у меня есть документ, я подталкиваю (повышаю) свой идентификатор пользователя к текущему объекту отношений. Текущий объект отношения

find({ 
    "object": "object6", 
    "year": "currentYear", 
    "month": "currentMonth", 
    "hour" : "currentHour" 
}); 

Если я хочу, чтобы все пользователи, которые владеют объект я могу запросить коллекцию отношения find({"object": "object6"}) (Конечно, с нумерацией страниц).

Если я хочу, чтобы все документы, которые у меня есть, я могу запросить find({'owned_by' : 'titogeo'})

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

+0

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

+0

Документ отношения к объекту находится в течение часа. если вы думаете, что через час миллион пользователей будет любить/иметь документ, вы можете сделать его даже гранулированным? добавьте минутное поле. – titogeo

+0

Я не совсем понимаю. Как вы собираетесь хранить миллионы идентификаторов пользователей в массиве? 1 миллион пользователей (12 байт для каждого пользователя) уже принимает 12 МБ документа 16 МБ. – stackyname

Смежные вопросы