Уточнение пределов для нового Firestore

Итак, в разделе ограничений (https://firebase.google.com/docs/firestore/quotas) о новом продукте Firestore от Firebase говорится:

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

Мы очень не понимаем, что это на самом деле влечет за собой.

Если у нас есть, скажем, коллекция корневого уровня под названием users с 10 миллионами записей в ней, повлияет ли эта скорость на эту коллекцию таким образом, чтобы только 500 пользователей могли обновить свои данные в любую секунду?

Может кто уточнить?


firebase google-cloud-firestore limits
person DarkNeuron    schedule 04.10.2017    source источник
comment
Я рекомендую вам задать этот вопрос на странице groups.google.com/forum/#!forum / firebase-talk и / или reddit.com/r/Firebase вместо этого. StackOverflow, вы получите лучшее представление об этом. StackOverflow лучше всего подходит для запросов, касающихся конкретного кода. Кроме того, Google планирует снять ограничения, которые они опубликовали, как только они получат больше данных о производительности Firestore в бета-версии.   -  person willbattel    schedule 04.10.2017

Ответы (2)


arrow_upward
8
arrow_downward

Извините за путаницу; пример может помочь.

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

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

Кстати, именно поэтому сгенерированные идентификаторы документов представляют собой случайные строки. Это равномерно распределяет записи по индексу первичного ключа.

Если вы избегаете таких шаблонов, то предел безграничен, хотя во время бета-тестирования вы выйдете за пределы базы данных.

person Gil Gilbert    schedule 04.10.2017
comment
Это немного размыто, поскольку неизвестно, как строятся индексы и создаются горячие точки. Кроме того, любое числовое поле в объектах можно рассматривать как «последовательное», поскольку вы можете выполнять сортировку по этому полю. Я полагаю, что под последовательным вы имели в виду поля обновленных / записанных объектов в течение некоторого периода времени. Представьте, что у меня есть 10000 объектов, и все они имеют числовое поле, которое «перечисляет» все объекты - от 0 до 9999. Предположим, я создал эти объекты в случайном порядке, поэтому не должно быть горячей точки, однако, если я создал все 10K случайным образом за меньшее время чем за 1 секунду это создаст точку доступа? - person frangulyan; 21.02.2018
comment
А как насчет случая, когда эти 10 000 объектов случайным образом пронумерованы от 0 до 1000 000 000? Означает ли обновление всех из них менее чем за секунду касание всех позиций индекса, что означает горячие точки? Означает ли это, что не следует обновлять все объекты в коллекции менее чем за секунду, если их более 500, или я ошибаюсь в идее индексов и горячих точек? Я считаю, что это стоит также подробно объяснить в документации. - person frangulyan; 21.02.2018
comment
Что произойдет, если вы достигнете этого предела скорости? У пользователей просто замедляется работа или запросы отклоняются? - person Hamish Johnson; 23.01.2019
comment
Если вы немного превысили лимит, запись займет немного больше времени. Если вы превысите лимит, вы в конечном итоге начнете видеть, что запись завершается с ошибками конкуренции. Если вы используете наши SDK, они справятся с этим за вас: они повторяют подобные ошибки с экспоненциальной задержкой. - person Gil Gilbert; 31.01.2019
comment
Я предполагаю, что то же самое относится к индексам области групп сбора? - person danielx; 25.06.2019
comment
Верный. Это ограничение скорости записи для индекса, и индексы области группы сбора ничем не отличаются. - person Gil Gilbert; 09.07.2019
comment
@GilGilbert применяется ли ограничение к составным индексам? Например, скажем, у меня есть коллекция событий календаря (содержащая все события для всех пользователей): я отключаю индексирование по одному полю для события start_date, но создаю составной индекс для [user_id, start_date]. Ограничение скорости по-прежнему применяется ко всей коллекции событий или только к конкретному user_id? - person Bradley Mackey; 29.09.2019
comment
Это относится и к составным индексам. Для любого компонента индекса с последовательным значением ограничение будет применяться к префиксу этого компонента в индексе. В вашем примере любой заданный user_id будет видеть предел 500 / сек, а коллекция в целом увидит ограничение пользователей * 500 / сек. - person Gil Gilbert; 05.12.2019
comment
Будет ли добавление исключения индекса для всех последовательных полей для документов в коллекции означать, что нет предела для записи в эту коллекцию? .. мы бы не достигли ограничения в 500 qps? - person fionbio; 22.12.2019
comment
да. Поля с последовательными значениями имеют значение только в том случае, если они являются частью индекса. - person Gil Gilbert; 23.12.2019
comment
@GilGilbert Я храню партитуры в коллекции. Как и ожидалось, я индексирую по количеству баллов. Однажды в конце недели я хочу создать ранги и сохранить их в коллекции, так как она больше не изменится. Если у меня 1 миллион документов с оценками, будет ли это обновляться более 30 минут? (1000000/500 = 2000 секунд)? - person Ayyappa; 12.06.2020
comment
Кроме того, довольно часто каждый документ по умолчанию имеет созданную временную метку или обновленную временную метку. Я не уверен, почему этот предел ни на кого не влияет. - person Ayyappa; 12.06.2020
comment
@Ayyappa re 30 минут на обновление, вы, вероятно, увидите, что он идет быстрее, особенно если данные оценки неоднородны, но да, для сильно кластеризованных значений вы будете бороться с индексом и не сможете писать быстрее, чем 500 / сек. Время обновления не проблема, если вы не индексируете его. Даже в этом случае достичь устойчивой скорости 500 операций записи в секунду не удастся, пока ваше приложение не получит значительный трафик. - person Gil Gilbert; 13.06.2020
comment
Мы видим, что это очень быстро достигается. Рассмотрим случай, когда одному игроку разрешено набирать несколько очков. И довольно часто этот счет будет индексироваться наверняка, поскольку нам нужно упорядочить его на основе таблицы лидеров. Даже если не несколько оценок, разве firestore не подходит для базы пользователей 1Mil? При 1миллионе пользователей я буду ограничен 500 / сек, как только мне понадобится обновить статус игроков, счет или любую массовую операцию: | - person Ayyappa; 13.06.2020
comment
@GilGilbert: Я сделал еще один пост, чтобы подробно объяснить проблему. Пожалуйста, посмотрите - stackoverflow.com/questions/62360116/ - person Ayyappa; 14.06.2020

arrow_upward
6
arrow_downward

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

Однако отключение индекса будет доступно в будущем.

person Alex Dufetel    schedule 04.10.2017