Максимальные узлы в пути со слушателями или запросами в базе данных реального времени firebase?

Question

В документации Firebase для ограничений базы данных в реальном времени вы можете найти этот оператор:

Общее количество узлов в пути с прослушивателями или запросами на нем: 75 миллионов

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

Если у меня есть подобная модель БД с 75 миллионами записей (пользователей) ...

{ 
     users : {
      uid1 : {age: 34, name: 'Tommy', links:{...} },
      uid2 : {age: 78, name: 'Mikel', links:{...} },
      uid3 : {age: 25, name: 'Chris', links:{...} },
      ...
      uid75000000 : {age: 33, name: 'Sam', links:{...} },
}

... и я добавляю одного нового пользователя в список.Означает ли выражение limit:

• Слушатели на users, как onWrite(), перестают работать?
• Запросы на путь users, например usersRef.orderByChild("age").limitToLast(20), перестают работать?

И что здесь означает кумулятивное? Включает ли число в 75 миллионовдочерние узлы дочерних узлов узла пути?Зачем использовать слово кумулятивный в противном случае?

Answer 1

Я считаю, что каждый ключ является узлом, так как база данных Firebase в реальном времени хранится в виде объекта JSON.

База данных Firebase допускает до 32 подузлов!

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

Я не уверен в возможности функции onWrite (), но в целом пользователь будет слушатьподузел списка пользователей, поэтому проблем не будет.

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

Запросы большого списка потребуютнавсегда и будет дорого, если это работает!Опять же, пожалуйста, рассмотрите ограждение ваших данных .