Существует множество способов оптимизировать серверную часть, чтобы минимизировать передачу данных в систему базы данных.
Использование системы кэш-памяти в памяти
Как вы уже упоминали в своем вопросе, кэш-память в памяти может сильно помочь вашему узкому узлу. Использование оптимизированного по производительности хранилища значений ключей, такого как redis , может быть чрезвычайно полезным при правильном использовании. Обновляя кэш-память только тогда, когда вам это нужно, вы можете заставить свою систему кеширования сильно загружать базу данных и намного быстрее выполнять запросы к вашему бэкэнду. Однако реализовать проверку кэша в рабочей системе может быть не так просто. Преимущество redis заключается в том, что благодаря природе No SQL он будет идеально гармонировать с MongoDB. Возможно, вы захотите взглянуть на ha sh таблиц / хранилищ в redis, они очень похожи на JSON документ (хотя они могут иметь глубину только один слой / не иметь вложенных объектов). Вы также можете хранить JSON как строковое значение в ключе, если это лучше соответствует вашим потребностям. Еще одна особенность redis - автоматическое c истечение срока действия кэша, поэтому вы можете установить время истечения для более легкого управления кэшем.
Использование более разумных методов аутентификации
Хотя из вашего вопроса сложно сказать, оптимизируя способ аутентификации пользователей и данные, хранящиеся в клиентских запросах к бэкэнду в целом и, таким образом, traffi c к вашей базе данных может быть значительно сокращено. Например, используя JWT Tokens в качестве механизма аутентификации, вы можете хранить пользовательские данные вместе с токеном, позволяя клиенту хранить данные на разных страницах и, что более важно, без каких-либо дополнительных запросов к бэкэнду. Этими токенами нельзя манипулировать, поскольку они имеют безопасную подпись, которую знает только ваш сервер, но они могут быть прочитаны кем угодно; поэтому, если вы храните конфиденциальные данные, может быть лучше перенести их в другое место. Как и ключи кеширования redis, токены JWT могут истечь через определенное время, но они остаются читаемыми бесконечно.
Использование интегрированной оптимизации кэширования и производительности
MongoDB, как и многие другие системы баз данных, предлагает встроенную оптимизацию кэширования и производительности из коробки, индексируя определенные записи . Хотя Redis может быть лучшим долгосрочным решением, правильная индексация базы данных может существенно повлиять на производительность, поэтому многие компании имеют разработчиков, занимающихся оптимизацией макетов, структур и индексации таблиц.
Используйте правильные запросы
Особенно с базой данных No SQL, такой как MongoDB, эффективные запросы являются ключевыми. Для такой системы баз данных объединения являются довольно тяжелыми рабочими нагрузками, поэтому может быть полезно посмотреть на сделанные вами запросы и на логику c, стоящую за ними. Оптимизируя существующие запросы и обходя лишние, можно также минимизировать загрузку базы данных.
Использовать подходящую структуру документа
, в то время как система хранения документов на основе JSON, такая как MongoDB имеет свои преимущества, злоупотребляя удобством отсутствия руководящих принципов структурирования данных, часто приводит к гораздо большему количеству запросов, поскольку наиболее необходимые данные не являются наиболее доступными. Опять же, трудно сказать по вашему вопросу, но взгляните на ваши запросы и структуру вашего документа (если таковые имеются): запросы кажутся естественными? Они имеют смысл? Или текущая структура мешает?
Pu sh logi c на стороне клиента
Как моя последняя рекомендация, вы должны попытаться переместить как можно больше нечувствительных и неэффективных интенсивные логики c на стороне клиента (тенденция современных фреймворков , кажется, следуют), чтобы избавить от боли в вашей базе данных и позволить клиентам не запрашивать данные снова и снова. Особенно, если вы запускаете веб-приложение, это может быть основным источником ненужного трафика c.