Обычно это зависит от того, сколько у вас есть свободной оперативной памяти, размера вашей базы данных и того, какой набор данных является «популярным».
(Ниже предполагается, что речь идет о кеше уровня приложения, а не о кэшах ввода-вывода, буферных кэшах или другом кэшировании более низкого уровня.)
Если вы выбираете размер кеша для повышения производительности (т. Е. Максимизируете пропускную способность и минимизируете задержку), тогда одной простой формулой будет использование как можно большего количества вашей свободной ОЗУ, что меньше вашего общего размера базы данных. Другой простой формулой было бы начать где-то между 1% и 10% размера вашей базы данных, и расти в зависимости от использования.
Если вы хотите тщательно рассчитать, какой объем кеша вам нужен, то самый надежный способ сделать это - экспериментировать, т. Е. Выполнить нагрузочные тесты с растущими размерами кеша и изобразить частоту обращений (это особенно верно, если характеристики загрузки / использования вашей базы данных сложны.)
Например, у вас может быть график, где ось X представляет собой размер кэша, а ось Y имеет как частоту обращений, так и задержку запросов. Ваша цель состоит в том, чтобы найти минимальное значение X (размер кэша), при котором максимальный коэффициент попадания будет максимальным, а задержка запроса сведена к минимуму (это могут быть разные точки).
Чтобы сделать это правильно, вам нужен реальный нагрузочный тест, т. Е. Если вы ведете журналы своих запросов, вы можете воспроизвести их. Возможно, вы захотите ограничить свое воспроизведение только не неизменяющимися запросами (для простоты).
Обратите внимание, что вместо нагрузочных тестов вы можете упростить этот процесс, добавив кеш (начальный где-то между 1% и 10%) в действующую базу данных, а затем следите за частотой обращений и задержкой запросов с течением времени. Это немного проще сделать, если у вас нет настройки платформы нагрузочного тестирования, но может быть более навязчивым в производственной системе. Если частота обращений слишком мала (или слишком велика задержка запроса), увеличьте кэш. Если нет, то посмотрите, имеет ли уменьшение это заметную разницу.
(Конечно, здесь есть крайние случаи, которые я подчеркиваю, но это общая идея. Например, иногда разные типы запросов могут иметь разные затраты, и вам может потребоваться выделить разные кэши для разных запросов типы.)
Как только у вас есть кеш, вы должны отслеживать его статистику вместе с другими статистическими данными запроса, такими как задержка. Возможно, вам потребуется увеличить его со временем.
Или вы можете обнаружить, что вам нужно прогреть кеш, прежде чем вы сможете получить какую-либо надежную производительность. Например, если вы полагаетесь на то, что кэш-память может обслуживать определенную загрузку запросов, и ваш компонент кэширования падает с нуля, то ваша база данных будет перегружена в течение некоторого периода времени, пока кеш нагревается. *
Как бы то ни было, краткий ответ таков: простого решения не существует, и размер вашего кэша лучше всего сделать экспериментальным путем.