Преимущества подколлекций firestore

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

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

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

Люди -> человек: {семья: 'Смит'}

против

Семьи -> семья: {name: 'Smith'} -> Люди -> человек

Я ожидал, что последний будет более эффективным, но правильно ли это? Есть ли какие-нибудь оценки для каждого? Какие-либо другие преимущества субколлекций (например, для транзакций)?


google-cloud-firestore collections tradeoff
person pwray    schedule 09.11.2017    source источник
comment
Пока что от того, что я видел, пользы от использования подколлекций нет. В настоящее время это дает гораздо меньшую гибкость по сравнению с плоскими коллекциями верхнего уровня. Однако меня также очень интересует, каковы будут запланированные выгоды от подколлекций. Это может сэкономить нам много времени от тяжелой миграции в будущем.   -  person Ivan Wang    schedule 23.11.2017
comment
У кого-нибудь есть мысли по этому поводу? Я пытаюсь решить, хранить ли вложенные коллекции или верхний уровень. Кажется, что если у вас есть ссылка на коллекцию, вы можете запрашивать одинаково, независимо от того, где она находится   -  person Felipe    schedule 23.12.2017

Ответы (4)


arrow_upward
12
arrow_downward

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

1 - Подколлекции дают вам более структурированную базу данных.

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

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

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

person Mateus Forgiarini da Silva    schedule 01.02.2018
comment
В примере чата в документе Firstore используется структура подколлекции с документом для каждого сообщения. Я думаю, это будет дорого. Может лучше было бы использовать вложенный массив? - person b-fg; 25.04.2018
comment
Это может быть дорого, если вы не используете пагинацию. Вложенный массив будет работать некоторое время, но его нельзя масштабировать, учитывая тот факт, что у вас есть максимальный размер 1 МБ на документ. - person Mateus Forgiarini da Silva; 28.04.2018
comment
Правда что. Спасибо за совет. - person b-fg; 29.04.2018
comment
OP спросил о коллекциях верхнего уровня и подгруппах. Пункт 1 является субъективным, 2 указывает на то, что подгруппы не имеют никакой выгоды, а 3 и 4 относятся к массивам и подгруппам. Мне, честно говоря, интересно то же самое, но в вашем ответе нет явных преимуществ. 1 может восприниматься как преимущество, но подгруппы также имеют недостатки, которые здесь не обсуждаются. - person Thijs Koerselman; 16.08.2019

arrow_upward
10
arrow_downward

Чтобы ответить на исходный вопрос об эффективности:

Запрос всех людей с family 'Smith' из people коллекций верхнего уровня на самом деле не медленнее, чем запрос всех people в 'Smith' family вложенной коллекции < / сильный>.

Это объясняется в эпизоде ​​Как структурировать данные серии видео "Знакомство с Cloud Firestore".

Следует помнить о некоторых компромиссах между коллекциями верхнего уровня и вложенными коллекциями. В зависимости от конкретных запросов, которые вы собираетесь использовать, вам может потребоваться создать composite indexes для запроса коллекций верхнего уровня или collection group indexes для запроса вложенных коллекций. Оба этих типа индекса учитываются при 200 исключениях для индекса.

Эти компромиссы подробно обсуждаются в нижней части Общие сведения о коллекции Групповые запросы и в эпизоде ​​Карты, массивы и вложенные коллекции, Oh My! серия видео "Знакомство с Cloud Firestore".

Я дал ссылки на соответствующие части обоих видео.

person matthew    schedule 30.03.2020
comment
Сообщение в блоге, на которое вы ссылаетесь, - это именно то, что искали OP (и я). Как вы сказали, внизу буквально обсуждаются компромиссы, один абзац даже начинается с So when should you store things in a separate top level collection vs. using subcollections? Спасибо !! - person steve; 26.04.2020

arrow_upward
3
arrow_downward

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

Вот некоторые преимущества обоих подходов:

Подколлекция:

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

Коллекция верхнего уровня:

  • Документы удалить проще. При использовании вложенных коллекций необходимо сначала удалить все документы вложенных коллекций, прежде чем удалять родительский документ. Для этого нет API, поэтому вам может потребоваться свернуть свои собственные вспомогательные функции.
  • Наличие родительского идентификатора непосредственно в каждом (под) документе может упростить обработку результатов запроса в зависимости от приложения.
person Thijs Koerselman    schedule 16.08.2019

arrow_upward
2
arrow_downward

Тодд ответил на это в введите здесь описание изображения

1) Существует ограничение на количество документов, которые вы можете создать в минуту в одной коллекции, если документы имеют постоянно увеличивающееся значение (например, временную метку).

2) Очень большие коллекции не так хороши с точки зрения производительности, когда вы не в сети. Но это, как правило, хорошие варианты.

person tylim    schedule 02.04.2020