Блог

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

Я не смог найти в документации много информации о том, как физически хранятся данные. Все ли данные в Firestore хранятся в одном большом двоичном объекте/файле? Если это так, то это может быть проблемой, когда есть сотни арендаторов с миллиардами записей в каждом. В идеальном мире каждая коллекция была бы физически отдельным файлом, а серверная оркестровка разделяла бы коллекции на несколько серверов, чтобы один сервер не распределял нагрузку между очень тяжелым клиентом и очень легким клиентом. Этот сценарий означал бы, что тяжелый арендатор замедлит работу легкого арендатора.

Мой основной вопрос: может ли одна база данных Firestore бесконечно увеличиваться в размерах, если предположить, что ни одна коллекция не превышает нескольких миллиардов записей?

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

Если ответ заключается в том, что Firestore не может масштабироваться бесконечно таким образом, каков альтернативный подход? Должен ли я вместо этого использовать Bigtable? Кассандра? Или есть другой способ физически разделить мою базу данных Firestore, кроме коллекций?

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

Производительность в Firestore не связана с количеством документов, существующих в коллекции. С точки зрения скорости не имеет значения, выполняете ли вы запрос на:

• Коллекция верхнего (корневого) уровня.
• Вложенная коллекция, которая в основном представляет коллекцию, вложенную в документ.
• Группа коллекций, что на самом деле означает запрос коллекций и вложенных коллекций, существующих во всей базе данных.

Скорость всегда будет одинаковой, если запрос возвращает одинаковое количество документов. Это происходит потому, что производительность запроса зависит от количества запрашиваемых документов, а не от количества документов, которые вы ищете. Поэтому на самом деле не имеет значения, если вы запросите коллекцию из 1 МИЛЛИОНА документов или даже 1 МИЛЛИАРДА документов, время получения тех же результатов будет одинаковым.

Я не смог найти в документации много информации о том, как физически хранятся данные. Все ли данные в Firestore хранятся в одном большом двоичном объекте/файле? Если это так, то это может быть проблемой, когда есть сотни арендаторов с миллиардами записей в каждом.

В Cloud Firestore единицей хранения является документ. Документы хранятся в коллекциях, которые являются просто контейнерами для документов. Пожалуйста, обратите внимание, что Firestore оптимизирован для хранения больших коллекций небольших документов. И когда я говорю «большой», я имею в виду «чрезвычайно большой». Таким образом, при выполнении запроса к коллекции из 1 МИЛЛИОНА документов скорость зависит от количества возвращаемых результатов и не зависит от количества документов, в которых выполняется поиск, или от количества документов, существующих в других коллекциях, в которых вы не выполняете поиск.

Может ли одна база данных Firestore бесконечно увеличиваться в размерах, если предположить, что ни одна коллекция не превышает нескольких миллиардов записей?

В то время как при использовании базы данных Firebase в реальном времени вам приходилось масштабироваться с использованием нескольких баз данных, в Firestore эта практика не требуется. Тем не менее, есть некоторые методы, которые действительно хорошо описаны в официальных документах:

• Создание масштабируемых приложений с помощью Firestore

Если ответ заключается в том, что Firestore не может масштабироваться бесконечно таким образом, каков альтернативный подход?

Я определенно могу масштабироваться массово.

Ознакомьтесь с рекомендациями Firestore и правилами безопасности.

Вы можете представить Firestore как один сервис, которым пользуются все клиенты Google. Точно так же, как попытки Google обеспечить, чтобы влияние одного клиента (так называемого «шумного соседа») на сервис не влияло на других, вы не хотите быть шумным соседом для себя.

Вам нужно учитывать не только производительность.

• Безопасность. Например, смотрите правила безопасности как механизм, который вы можете использовать для обеспечения разделения данных ваших арендаторов. Вы захотите полностью понять, как безопасно разделять данные разных клиентов. Ваши клиенты также захотят понять, какие меры вы используете для обеспечения того, чтобы их данные хранились отдельно.
• Многодетность. Облачная платформа Google не имеет встроенных (общеплатформенных) мультитенантных возможностей, и часто способом проявления аренды было использование разных проектов Google для разных клиентов. Это связано с тем, что проекты обеспечивают четко определенный периметр безопасности. Возможно, вам захочется выяснить, выиграет ли (какая-то часть ваших клиентов) от того, что вы будете одним клиентом, одним проектом.
• Квота. Еще одним важным соображением является квота. Каждый метод облачной платформы ограничен некоторой квотой. Вам нужно будет быть осторожным в обеспечении справедливого распределения квот между клиентами, чтобы некоторые клиенты не использовали всю квоту, отказывая другим клиентам в доступе к сервису.