Что такое денормализация в Firebase Cloud Firestore?
Посмотрите на это таким образом - эффективнее ли выкидывать кухонный мусор, когда мусор может составлять 10%, или пусть он заполняется, прежде чем вынимать его?
Не пуская его в пополнение , вы тратите свое время на прогулку в мусорный ящик и обратно. Это аналогично тому, что происходит при выполнении потока GC - все управляемые потоки приостанавливаются во время работы. И если я не ошибаюсь, поток GC может делиться между несколькими AppDomains, поэтому сбор мусора влияет на все из них.
Конечно, вы можете столкнуться с ситуацией, когда вы не будете добавлять что-либо к мусор может в ближайшее время - скажем, если вы собираетесь отправиться в отпуск. Тогда было бы неплохо выбросить мусор перед выходом.
Это может быть один раз, когда принудительное использование GC может помочь - если ваша программа простаивает, используемая память не собирает мусор, потому что нет назначений.
1 ответ
Что такое денормализация в Firebase Cloud Firestore?
Денормализация относится не только к Cloud Firestore, это техника, обычно используемая в базах данных NoSQL.
Что на самом деле означает эта денормализация?
Денормализация - это процесс оптимизации производительности баз данных NoSQL путем добавления избыточных данных в других местах базы данных. Что я имею в виду, добавляя избыточные данные, как @FrankvanPuffelen уже упоминал в своем комментарии, это означает, что мы копируем те же самые данные, которые уже существуют в одном месте, в другом месте, чтобы удовлетворить запросы, которые могут быть невозможны в противном случае. Таким образом, денормализация помогает скрыть недостатки, присущие реляционным базам данных.
Как эта денормализация действительно помогает?
Да, это так. Это также довольно распространенная практика, когда дело доходит до Firebase, потому что дублирование данных является ключом для более быстрого чтения. Я вижу, что вы новичок в базе данных NoSQL, поэтому для лучшего понимания я рекомендую вам посмотреть это видео, Денормализация нормальна с базой данных Firebase . Это для базы данных реального времени Firebase, но те же принципы применимы к Cloud Firestore.
Всегда ли это необходимо?
Мы не используем денормализацию только ради ее использования. Мы используем его, только когда это определенно необходимо.
Является ли сглаживание базы данных и денормализация одинаковыми?
Давайте рассмотрим пример. Предположим, у нас есть схема базы данных для приложения для викторин, которая выглядит следующим образом:
Firestore-root | --- questions (collections) | --- questionId (document) | --- questionId: "LongQuestionIdOne" | --- title: "Question Title" | --- tags (collections) | --- tagIdOne (document) | | | --- tagId: "yR8iLzdBdylFkSzg1k4K" | | | --- tagName: "History" | | | --- //Other tag properties | --- tagIdTwo (document) | --- tagId: "tUjKPoq2dylFkSzg9cFg" | --- tagName: "Geography" | --- //Other tag propertiesМы можем сгладить базу данных, просто переместив коллекцию
tagsв отдельную коллекцию верхнего уровня, например: [1121 ]Firestore-root | --- questions (collections) | | | --- questionId (document) | | | --- questionId: "LongQuestionIdOne" | | | --- title: "Question Title" | --- tags (collections) | --- tagIdOne (document) | | | --- tagId: "yR8iLzdBdylFkSzg1k4K" | | | --- tagName: "History" | | | --- questionId: "LongQuestionIdOne" | | | --- //Other tag properties | --- tagIdTwo (document) | --- tagId: "tUjKPoq2dylFkSzg9cFg" | --- tagName: "Geography" | --- questionId: "LongQuestionIdTwo" | --- //Other tag propertiesТеперь, чтобы получить все теги, которые соответствуют конкретному вопросу, вам нужно просто запросить коллекцию
tags, где свойствоquestionIdсодержит желаемый идентификатор вопроса.Или вы можете выровнять и денормализовать базу данных одновременно, как вы можете видеть в следующей схеме:
Firestore-root | --- questions (collections) | | | --- questionId (document) | | | --- questionId: "LongQuestionIdOne" | | | --- title: "Question Title" | | | --- tags (collections) | | | --- tagIdOne (document) //<----------- Same tag id | | | | | --- tagId: "yR8iLzdBdylFkSzg1k4K" | | | | | --- tagName: "History" | | | | | --- //Other tag properties | | | --- tagIdTwo (document) //<----------- Same tag id | | | --- tagId: "tUjKPoq2dylFkSzg9cFg" | | | --- tagName: "Geography" | | | --- //Other tag properties | --- tags (collections) | --- tagIdOne (document) //<----------- Same tag id | | | --- tagId: "yR8iLzdBdylFkSzg1k4K" | | | --- tagName: "History" | | | --- questionId: "LongQuestionIdOne" | | | --- //Other tag properties | --- tagIdTwo (document) //<----------- Same tag id | --- tagId: "tUjKPoq2dylFkSzg9cFg" | --- tagName: "Geography" | --- questionId: "LongQuestionIdTwo" | --- //Other tag propertiesВидите, объекты тегов такие же, как и в
users -> uid -> tags -> tagId, как вtags -> tagId. Таким образом, мы сглаживаем данные, чтобы сгруппировать каким-то образом существующие данные.Для получения дополнительной информации вы также можете взглянуть на:
[ 1126] Поскольку вы говорите, что у вас есть фон SQL, попробуйте подумать о нормализованном дизайне, который часто будет хранить разные, но связанные фрагменты данных в отдельных логических таблицах, которые называются отношениями. Если эти отношения физически хранятся в виде отдельных файлов на диске, выполнение запроса, извлекающего информацию из нескольких отношений (операций соединения), может быть медленным. Если многие отношения объединяются, это может быть слишком медленным. Поскольку в базах данных NoSQL у нас нет предложений «JOIN», мы должны создать разные обходные пути, чтобы получить одинаковое поведение.