Пн goose заполнить кеш

Question

У меня есть много различных схем mon goose, ссылающихся друг на друга через строки идентификаторов.

Я использую redis для кэширования документов mon goose.

Например, getUser (id ) вернет ранее кэшированный пользовательский объект, если он существует, в противном случае он вызовет mon goose find.

Было бы более эстетично c иметь вместо этого ссылки mon goose и использовать заполнение.

Однако, насколько я понимаю, это просто syntacti c сахар для поиска и не имеет никакого слоя кэширования.

Основной вопрос

Когда следует использовать mon goose заполнение по сравнению с уровнем кэширования, и каковы лучшие практики в стабильных приложениях с высоким трафиком c, использующих mon goose?

Руководящие подвопросы

1. Действительно ли заполнение mon goose действительно подходит для приложений с высоким трафиком c?
2. Есть ли какая-то польза от использования заполнения для кэширования документов самостоятельно?
3. Является ли кеширование моделей самостоятельно (например, с помощью redis) незначительным с точки зрения производительности?
4. Что лучше? ractice? Что делают крупные компании приложений, использующие mon goose?
5. Вы бы смешали заполненные ссылки mon goose и слой кэширования в зависимости от различных вариантов использования, или вы выбрали бы один и соответствовали ему?

Пример варианта использования

Вот простой пример из моего приложения.

У меня есть 3 коллекции: User, App, Institute.

1. У пользователя есть ссылка на приложение
2. В приложении есть ссылка на институт

Прямо сейчас я:

1. Извлечение Пользователь из слоя кэширования, который содержит app_id
2. Выбор приложения из слоя кэширования, который содержит institute_id
3. Выбор института из слоя кэширования

Для данного пользователя выборка приложение и институт из уровня кэширования практически равны O (1).

Однако, если я решу заполнить только mon goose, потребуется 2 дополнительных вызова поиска для базы данных - для приложения и затем для института.

Мне нужен пользователь с приложением и институт заполнен o В каждом аутентифицированном запросе к серверу.

Конечно, есть более сложные случаи использования, но это наиболее распространенный.

Мои самые простые запросы требуют заполнения в среднем 4 ссылок, тогда как более сложные могут попасть в еще большее число.

Answer 1

Вот мое понимание некоторых плюсов и минусов двух.

Плюсы для заполнения пн goose

• Никаких дополнительных настроек для кэша (более простая инфраструктура)
• Может глубоко заполнять (заполнять на нескольких уровнях)
• Может заполнять из нескольких баз данных.
• Это простой чистый синтаксис
• Синхронизация не требуется между кэшированием и базой данных, потому что это «единственный» источник правды.

Минусы для заполнения понедельника goose

• База данных работает для каждого заполнения и запроса вместо вашего сервера или слоя кэширования. Если в одном и том же экземпляре много записей, это повлияет на производительность некоторых операций записи, если необходимо пересчитать индекс или выполнить запрос с интенсивным использованием процессора.
• Положитесь на внутреннюю работу базы данных mon goose и базы данных MongoDB.
• Требуется контроль, так как глубокое заполнение может выйти из-под контроля с несколькими уровнями.

Плюсы для кэширования слоя

• Может быть несколько уровней кэширования. Некоторые на сервер и глобальное кеширование.
• Используйте спецификацию c силы механизма кеширования.
• Перенесите часть работы в кеш и, возможно, в базу данных.

Минусы для уровня кэширования

• Необходимо синхронизировать c состояние между кэшем и базой данных
• Больше инфраструктуры.
• Больше кода (если вы хотите чистая абстракция)

В целом, чтобы ответить на ваши подвопросы, 1. Заполнить может быть полезно в некоторых приложениях hight traffi c для чего-то, что не может быть кешировано и должно быть активным или выполненным не очень часто.

Использовать заполнение поверх кэширования проще, меньше инфраструктуры, меньше кода, без синхронизации.

По моему опыту, я бы go для кэширования, потому что это будет быстрее на большой базе данных. При масштабировании базы данных, как правило, требуется больше ресурсов процессора и больше денег. Кэширование с другой стороны обходится дешевле и масштабирует скважины. Кроме того, можно кешировать для каждого экземпляра. т. е. мой сервер имеет локальный кеш, прежде чем ударить удаленный кеш. Это делает производительность очень быстрой, но это может повлиять на производительность сервера в зависимости от хостинга.

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

Да, смешивание - хороший вариант в зависимости от варианта использования. Общий совет будет состоять в том, чтобы понять потенциальную горячую точку и попытаться распределить рабочую нагрузку вокруг, чтобы убедиться, что одна часть инфраструктуры не является узким местом.

Последний совет: В случае сомнений убедитесь, что сохранить интерфейс кода между уровнем данных и уровнем кода. Эта абстракция очень полезна, если нужно использовать ElasticSearch вместо Redis или любого другого сервиса кэширования. Интерфейс кода откладывает необходимость принятия обязательства.

Пример: вместо использования App.populate непосредственно в фрагменте кода добавление метода getFullApp() в вашу схему, которая вызывает this.populate()

const AppSchema = new mongoose.Schema({...});

AppSchema.static({
   getFullApp(query) {
      return this.find(query).populate()
   }
})

module.exports = mongoose.model("App", AppSchema);

Если вы хотите избавиться от заполнителя, есть только одно место, чтобы изменить его или избавиться от mon goose getFullApp - это функция интерфейса вашего кода.