# #firebase #google-cloud-firestore
Вопрос:
Я видел в документации Firestore, что индексировать монотонно увеличивающиеся значения-плохая идея, так как это увеличит задержку. В моем приложении я хочу запрашивать сообщения на основе времени unix, которое удваивается, и это число будет увеличиваться с течением времени, но в моем случае не совсем монотонно, потому что люди не будут публиковать сообщения каждую секунду, кроме того, я не думаю, что мое приложение превысит 4 миллиона пользователей. кто-нибудь со знанием дела думает, что это будет проблемой для меня
Ответ №1:
Это не должно быть проблемой. Просто убедитесь, что вы храните его как число, а не как строку. В противном случае сортировка не будет работать так, как ожидалось.
Комментарии:
1. Это плохая идея. Хранение временных меток unix в виде строк сопряжено с риском нарушения порядка сортировки этих временных меток, поскольку не гарантируется, что все они содержат одинаковое количество цифр. Строки всегда сортируются лексикографически, а не численно.
2. Я не говорил хранить их в виде строк.
3. так ты думаешь, Тарик, что я должен пойти на это? кто-то ниже вас говорит, что это была бы плохая идея, но мое приложение предназначено для нишевой аудитории, а не для 100 миллионов человек
4. кроме того, если вы делали это раньше в firestore, каков был ваш опыт с этим
5. Вы написали там 4 миллиона пользователей. Это немалая сумма, но если @DougStevenson не может предложить реальную альтернативу, я не уверен, что еще вы могли бы использовать. Такие крайние случаи трудно предсказать. Возможно, ключи базы данных в реальном времени не будут иметь такого поведения. Они отсортированы по времени, но не являются добавочными значениями. Просто сгенерируйте ключ и используйте его.
Ответ №2:
Это именно та проблема, о которой вас предупреждает документация Firestore. Ваш код базы данных потребует затрат на «горячую точку» в индексе для метки времени в масштабе. В частности, из этой связанной документации:
Создает новые документы с монотонно увеличивающимся полем, таким как метка времени, с очень высокой скоростью.
Числа не обязательно должны быть чисто монотонными. Выделение горячих точек происходит в диапазонах, которые используются для сегментирования индекса. Документация просто не говорит вам, чего ожидать для этих диапазонов, так как они могут меняться со временем по мере увеличения количества документов в индексе.
Также из документации:
Если вы индексируете поле, которое последовательно увеличивается или уменьшается между документами в коллекции, например метку времени, то максимальная скорость записи в коллекцию составляет 500 записей в секунду. Если вы не выполняете запрос на основе поля с последовательными значениями, вы можете освободить поле от индексации, чтобы обойти это ограничение.
В случае использования интернета вещей с высокой скоростью записи, например, коллекция, содержащая документы с полем метки времени, может приблизиться к пределу 500 записей в секунду.
Если у вас нет ситуации, когда новые документы добавляются быстро, это не краткосрочная проблема. Но вы должны знать, что он просто не масштабируется, как чтение, и запросы будут масштабироваться в соответствии с этим индексом. Обратите внимание, что количество одновременных пользователей вообще не является проблемой — это количество документов, добавляемых в секунду в сегмент индекса, независимо от того, сколько людей вызывает такое поведение.
Комментарии:
1. Что было бы хорошей альтернативой? Он мог бы сохранить метку времени в другом поле, если ему нужны точные данные, но что было бы хорошим альтернативным значением для такого запроса сортировки?
2. что бы вы порекомендовали для сортировки сообщений по времени публикации?
3. кроме того, я не думаю, что пользователи будут публиковать сообщения более 500 раз в секунду, я думаю, может быть, на пике 200
4. Если вас устраивает ограничение, то не беспокойтесь об этом. Но вы должны знать, что ограничение существует, потому что оно начнет масштабировать ваше приложение.