Обойти лимит размера документов в пожарном депо?

Question

Мне нужно хранить большое количество полей, как для системы звездной оценки, но в хранилище разрешено только 20 000 полей на документ. Есть ли известный способ обойти это? Прямо сейчас я собираюсь «осколить» поля в нескольких документах и ​​сохранить размер каждого документа в документе documentSizeTracker, который я использую, чтобы определить, какой документ следует разделить (и добавить к счетчику с помощью транзакции). Это правильный подход? Есть проблемы с этим?

Answer 1

На самом деле, я столкнулся с похожей проблемой с проблемами чтения и записи в Firebase.Итак, вот мой вывод:

# если что-то маленькое нужно писать и читать очень часто, то используйте базу данных Firebase Realtime

• FirebaseБаза данных в реальном времени позволяет выполнять быструю запись, но ограничивает число одновременных пользователей до 100 000
• Firebase Firestore позволяет максимум 1 запись в секунду на документ
• Читать документ, который содержит только оценку, например, очень дорогов Firestore

# если что-то (больше) нужно читать очень часто с записью обычно более 1 секунды, тогда используйте Firestore

• Firestore позволяет использовать до 1 000 000 одновременно работающих пользователей в текущей версии бета-версии (они могут сделать ее больше)
• В Firestore дешевле читать большие документы (не более 1 МБ), чем в базе данных Firebase Realtime

# Если ваша модель не подходит для этих двух вариантов, вам следует изменить модель и разделить их на 2 модели:

• 1 очень маленькая модель для хранения в базе данных Firebase Real (рейтинги, например)
• 1 большая модель для хранения в Firestore

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

Примечание 2: Мне действительно не понравилась идея шардинга в предложенном Firestore решениии работать вокруг

Answer 2

Шардинг, безусловно, может сработать. Трудно сказать, не зная точно, какие данные вам понадобятся в вашем документе и когда, но это, безусловно, разумный вариант. Вы также можете рассмотреть возможность создания родительского «сводного» документа, содержащего поля, по которым вы можете искать, а затем разбить все ваши данные на несколько документов внутри вложенной коллекции этого родителя.

Здесь есть один важный нюанс: ограничение не 20 000 полей, а 20 000 проиндексированных полей. Поэтому, если вы храните кучу данных внутри документа, но знаете, что не будете искать по всем из них, другой альтернативой является пометить некоторые из ваших полей как неиндексированные (что вы можете теперь сделать в Консоль Firebase в разделе «Исключения»).

Однако, если вы имеете дело с тысячами полей, вы, вероятно, не захотите освобождать их все по одному, поэтому лучшей альтернативой может быть размещение ваших данных в виде карты внутри поля контейнера (называемого чем-то например, «allOfMyData»), просто пометьте это поле как неиндексированное. Это автоматически удалит все индексы из любых полей, содержащихся в этой карте.