Почему бесконечно растущие массивы это плохо?

Question

[Fengol]

Почему бесконечно растущие массивы в mongodb являются плахой практикой?
Если рассматривать пример из документации, то почему считается неприемлемым иметь в документе Autor массив с идентификаторами книг и предлогается документам Book ссылаться на автора? Неужели искать сотню книг, пренадлежащих одному автору, из миллиарда, производелтельней, чем выбрать сто книг по идентификаторам хранящихся в массиве? По логике куда больше вероятности что я все сто книг выбиру раньше, чем перечислю весь миллиард. Или же mongodb как-то оптимизирует этот процесс?

Answer 1

[Dimonchik]

а где там написано, что Монга будет

искать сотню книг, пренадлежащих одному автору, из миллиарда

?

пример вообще об уменьшении избыточности
ну а ответ там же по ссылке

Comments

[Fengol]

Вы меняпростите, вы ответ дали только потому что хотите плюсик заработать? Иначе я не могу понять почему вместо ответа вы задали вопрос и дали ссылку не наответ , а на описание проблемы о решении которой я и спрашиваю. Щас я Вам плюсану и прошу всех кто это читает чтобы тоже наплюсовали. Чуваку нужны плюсики!

[Dimonchik]

прощаю
проблема у Вас в голове, но я выделю, что нужно увидеть по ссылке, картинка:

поясню Вашу проблему - Вы не можете с данным уровнем багажа знаний понять ответ, это нормально, все такими были
проще всего Вам сделать следующее 0) попытаться ответить на мой вопрос, где-то тут Вам должно прийти понимание, что имеете дело с СУБД, а не текстовым файлом 1) вызубрить картинку и научиться составлять отношения ну и 2) дочитать мануал до раздела indexes
после этого ответ будет самоочевидным

[Stalker_RED]

Fengol,

и прошу всех кто это читает чтобы тоже наплюсовали

запросто :)

[Fengol]

dimonchik2013, согласитесь ,что вы показываете картинку иллюстрирующую как связать документы с помощью идентификаторов,а не встраивания (клонирования)?! Верно?

А вот теперь подумайте, как, создав идентификаторы для множества документов, вы сможете сослаться на них на все в одном документе? Ответ очевиден - с помощью массива идентификаторов! Вот тут мы и подошли к моему вопросу! Почему там написано что массив идентификаторов это плохо? И почему в доках к mongoose такой подход называется антипатерном? Теперь поняли? Я тоже могу Вас понять, вечер, воскресьнье,, разум затуманен алкоголем распиваемым в одиночестве. Но сейчас уже утро, надеюсь что выпили немного и разум чистый и ясный.

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

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

И другой пример. У вас сто миллионов юзеров и у каждого по десять по сто контактов. Почему для поиска всех контактов я должен однозначно итерировать количество сто 100М * 100, а не выбирать точно заданное количество по идентификаторам расчитывая при этом, что в большенстве ситуаций итерация будет короче на десятки миллионов?

[АртемЪ]

Fengol,

Зашел спросить ,а вместо этого пришодится разжевывать очевидные вещи

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

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

[АртемЪ]

Почему там написано что массив идентификаторов это плохо?

Вам выше уже объяснили почему плохо.

как, создав идентификаторы для множества документов, вы сможете сослаться на них на все в одном документе? Ответ очевиден - с помощью массива идентификаторов!

Согласен с тем что для вас это удобно.
Но ведь речь идет не об удобстве для вас в конкретном случае, а о том плохо это или хорошо.

Почему для поиска всех контактов я должен однозначно итерировать количество сто 100М * 100, а не выбирать точно заданное количество

Какое это имеет отношение к вопросу?
Это уже проблемы и их решения конкретной DB. Суть в том что DB надо проектировать и на этапе проектирования подсчитывать что будет выгоднее гонять итерации каждый раз или хранить, или может решить это как-то по другому. И при этом помнить что бесконечно растущие массивы это плохо.

[Dimonchik]

Ответ очевиден - с помощью массива идентификаторов!

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

[Fengol]

dimonchik2013, пока не спорю, читаю, прочту и продолжу :)

[Fengol]

dimonchik2013, прочел про индексы. Скажу честно, впервые работаю с БД и просто не знал о таких возможностях. Сложного в этом ничего нет, обычные карты. Вам за их упоминание отдельное спасибо. Но! Они индексация никоим образом неотносятся к моему вопросу.

Вот вы говорите, что массив с индексами будет проиндексирован. Это замечательно! Но этим вы подтверждаете игноририрование моего вопроса, ведь в документации к мнге говорится что массивов вообще не должно быть. И в доках к монгусу тговорится что массивы это антипаттерн монги и при этом иллюстрируется примером с массивом идентификаторов.

То есть независимо от того, индексируемые массивы или нет, это неправильно. Где я или не я туплю?

[Dimonchik]

Fengol, от Рождества до Пасхи - 4 месяца, а от Пасхи до Рождества - 8

[Fengol]

dimonchik2013, думаете я понял что вы имеете ввиду?)

[Fengol]

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

Answer 2

[Wentixon]

Тут все зависит от ситуации. На счёт производительности я так понял вы уже разобрались. БД не такие тупые, чтобы все 100 лямов записей перебирать в поиске нужной. Даже в этом случае, хранение в массиве вам никак бы не помогло, так как данные все равно пришлось бы вытягивать из другой коллекции. Только в этом случае выборка получилась бы гораздо сложнее и медленнее.

Чтобы ответить на свой вопрос, подумайте, как бы вы вытянули из БД книги издательства, в которых более 100 страниц, если бы хранили в массиве? Это первый момент.

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

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

В примере рассмотрена связь one to many, когда к примеру одно издательство имеет много книг, а книга только одно издательство. Но есть связь many to many. Например, рецепт имеет много ингридентов, а каждый ингридиент привязан ко многим рецептам. В этом случае в nosql как раз нужно использовать массив.

Так что все зависит от ситуации. Иногда даже лучше не делать отдельную коллекцию, а записывать документ целиком в массиве, как в первом примере из ссылки.

Comments

[Fengol]

В примере рассмотрена связь one to many, когда к примеру одно издательство имеет много книг, а книга только одно издательство. Но есть связь many to many.

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

Но возникает другой вопрос. Предположим есть тир, в котором у одного оружия могут быть множество стрелков, а у один стрелок может использовать множество оружия. Получается что не обойтись без массива с идентификаторами и для оружия ссылающегося на стрелков и для стрелков ссылающихся на оружие. Кроме того, часть оружия пневматическое, часть огнестрельная. Как теперь мне узнать какое пневматическое оружиеиспользует конкретный стрелок? Как правильно создать такие отношения?

А ещё если у меня будет два документа Пневматика и Огнестрельное, то чтобы получить все оружие конкретного стрелка, мне придется делать выбурку из них -

Пневматика.find([ user.всеПневматическиеИд ])
Огнестрельное.find([ user.всеОгнестрельныеИд ])

А потом я добавлюмеханическое оружие, как например луки и арбалеты и чтобы получить их мне придется менять сам код, саму логику выборки?

Пневматика.find([ user.всеПневматическиеИд ])
Огнестрельное.find([ user.всеОгнестрельныеИд ])
Механическое.find([ user.всеМеханическоеИд ])

Разве это нормально? Как такое решать?

[Станислав]

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

public: 0 - удален
public: 1 - на модерации
public: 2 - одобрен
и т.д.

У меня на одном проекте пользователи собирают коллекции из "постов", так вот там я использую массив, хорошо это или плохо, работает все отлично
Есть скажем посты (db.posts)

[{
_id: 1,
post: "text 1"
},{
_id: 2,
post: "text 2"}]

И есть коллекция которую создал пользователь (db.collections)

{
_id: 1,
name: "Name Collection"
posts: [
ObjectId("1"),
ObjectId("2")
]
}

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

[Fengol]

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

[Wentixon]

Fengol, я тебе скажу так, что если ты не понимаешь зачем монго и nosql нужны, то лучше юзай sql. Все просто лишь на первый взгляд, когда же возникает необходимость в связях и сложных запросах начинаются проблемы. Суть монго в том, что в ней можно хранить данные в денормализованном виде и управлять их целостностью из кода. Порой это полезно, так как не надо создавать схемы. Например запись логов, какой нибудь чат простой, при паркинге очень удобно. Но в твоём примере монго превращается в костыль.

На счёт примера с оружием тебе выше уже сказали, что надо добавить поле с типом, не делать разные коллекции. А десятки миллионов это очень мало.

[Илья Шатохин]

Дело в том, что в даже выдуманом мной примере с оружием, характеристики моделей совершенно не схожи.

Вы выбрали Монгу - schemaless базу данных, значит можно и нужно в одной коллекциии хранить разные, но похожие до степени смешения документы. Читая ваше непонимание, как это все работает, хотелось бы вам порекомендовать реляционную СУБД, возможно, вам с ней будет проще.

Answer 3

[Vladimir Goncharov]

Бесконечно растущие массивы это плохо, потому что вы его храните в документе. При каждом увеличении массива, документ не будет умещаться в то же самое место на диске, поэтому монга перенесёт его полностью в новое место. Для этого ей понадобиться прочитать все эти миллионы элементов массива, добавить к нему один и записать. И так каждый раз. В итоге вместо записи несколько новых байт на диск монге придётся считывать мегабайты/гигабайты и записывать их на диск заново в новом месте. Это ни разу не оптимально. Я уже не говорю про то что рано или поздно документ станет настолько большим, что его невозможно будет прочитать/обновить.

Answer 4

[profesor08]

Ты не можешь гарантировать того, что твоему бесконечно растущему массиву хватит памяти. Память конечна. А раз конечна, то подумай над тем, когда она закончится и что станется с твоим массивом. Крах, беда, потоп, ребут, потеря данных, выстрел в ногу.

Comments

[Илья Шатохин]

Скорее автор упрется в максимальный размер документа - 16мб (это только кажется, что много).