Я пытаюсь понять то, на что просто не могу найти хорошего ответа.
Если я скажу, что кеш REDIS (или какой-то внешний кеш в памяти) находится в центре обработки данных, а сервер приложений находится в том же центре обработки данных, какова будет скорость сетевого подключения (задержка, пропускная способность) для чтения данных между этими двумя машинами?
Например, будет ли «скорость» сети хотя бы на порядок выше, чем скорость оперативной памяти, которая ищет мои данные из кеша на REDIS?
Мой главный вопрос: если все это, хранящееся в памяти на REDIS, действительно дает какие-то полезные функции? В отличие от того, если бы REDIS кэшировал все это на SSD? Память стоит дорого. Если сеть действительно не является узким местом внутри центра обработки данных, тогда память имеет значение. В противном случае это не так.
Я предполагаю, что мой общий вопрос заключается в том, что, несмотря на огромные количества неизвестных в центрах обработки данных и неспособность обобщить, а также на различия, мы говорим о достаточных порядках величины между задержкой памяти в компьютерной системе и даже лучшими внутренними сетями для DC, в которых память сокращение задержек не дает значительного повышения производительности? Я понимаю, что есть много переменных, но насколько это близко? Неужели так близко, что эти переменные имеют значение? Например, возьмем гиперболическую позицию по этому поводу: ленточный накопитель НАМНОГО медленнее, чем сетевой, поэтому лента не идеальна для кэша.
Существует несколько версий «диаграмм задержки, которые должен знать каждый», например:
Дело в том, что на самом деле задержка не ограничивается. Это сочетание факторов.
Итак, какова задержка сети в центре обработки данных? Задержка, я бы сказал, «всегда» ниже 1 мс. Это быстрее ОЗУ? Нет. Это близко к ОЗУ? Я так не думаю.
Но остается вопрос, актуально ли это. Это те данные, которые вам нужно знать? Для меня твой вопрос имеет смысл. Поскольку все имеет свою цену, стоит ли вам получить больше ОЗУ, чтобы все данные могли оставаться в ОЗУ, или время от времени можно читать с диска.
Ваше «предположение» состоит в том, что если сетевая задержка выше (медленнее), чем скорость SSD, вы не выиграете от того, что все данные будут в ОЗУ, так как у вас будет медленная работа в сети.
Так и должно быть. Но вы также должны учитывать параллелизм. Если вы получаете 1000 запросов данных одновременно, сможет ли диск выполнить 1000 одновременных запросов? Конечно, нет, так сколько времени потребуется, чтобы обработать эти 1000 запросов? По сравнению с RAM?
Трудно свести это к одному фактору, например, большим нагрузкам. Но да, если бы у вас была одна операция, задержка сети такова, что вы, вероятно, не заметили бы разницы между SSD и RAM.
Точно так же, как до появления на рынке диска 12 Гбит / с, сетевое соединение 10 Гбит / с не могло быть перегружено одним потоком, поскольку диск был узким местом.
Но помните, что ваш диск выполняет множество других функций, ваш процесс - не единственный процесс на машине, ваша сеть может переносить разные вещи и т. Д.
Кроме того, не вся дисковая активность означает сетевой трафик. Запрос к базе данных, поступающий от приложения на сервер базы данных, требует минимального сетевого трафика. Ответ сервера базы данных может быть очень маленьким (одно число) или очень большим (тысячи строк с несколькими полями). Для выполнения операции серверу (серверу базы данных или нет) может потребоваться выполнить несколько операций поиска, чтения и записи на диск, но при этом отправить по сети только очень небольшой бит. Это определенно не одноразовая сеть-диск-RAM.
Пока я избегал некоторых деталей вашего вопроса, в частности, части Redis.
Redis - это хранилище структур данных в памяти с открытым исходным кодом (под лицензией BSD), используемое в качестве базы данных, кеша и брокера сообщений. - https://redis.io/
ОК, значит, все в памяти. К сожалению, этот быстрый SSD-накопитель здесь не поможет. Redis может сохранять данные на диске, поэтому их можно загрузить в оперативную память после перезапуска. Это только для того, чтобы не «потерять» данные или заново заполнить холодный кеш после перезапуска. Так что в этом случае вам придется использовать оперативную память, несмотря ни на что. У вас должно быть достаточно оперативной памяти для хранения вашего набора данных. Недостаточно оперативной памяти, и я думаю, ваша ОС будет использовать swap - наверное, не лучшая идея.
В компьютерных системах существует множество уровней кеш-памяти. Добавление одного на уровне приложения может быть полезным, поскольку кеширует запросы API и базы данных. И, возможно, временные данные, такие как сеансы пользователя.
Хранилища данных, такие как Redis, предоставляют такую услугу по сети (быстро) или через сокет UNIX (даже быстрее), так же, как вы использовали бы базу данных.
Вам нужно измерить, как на самом деле работает ваше приложение, но давайте составим пример. Допустим, обычный пользовательский запрос выполняет 5 запросов API, каждый из которых занимает 50 мс. 250 мс - задержка, определяемая пользователем. В отличие от кеширования результатов. Даже если кеш находится в другой зоне доступности по городу (не оптимально), время обращения, вероятно, составляет не более 10 мс. Это будет 5-кратное ускорение.
На самом деле базы данных и системы хранения также имеют свои собственные кеши. Однако обычно быстрее получить предварительно выбранный результат, чем снова пройти через уровни ядра базы данных и системы хранения. Кроме того, уровень кеширования может значительно снизить нагрузку на находящуюся за ним базу данных.
В качестве примера такого кеша в производственной среде не ищите ничего, кроме Блог инфраструктуры Stack Overflow об архитектуре. Сотни тысяч HTTP-запросов, генерирующих миллиарды обращений Redis, весьма значительны.
Память стоит дорого.
DRAM со временем доступа 100 нс примерно в 100 раз быстрее, чем твердотельное постоянное хранилище. Это относительно недорого для такого исполнения. Для многих приложений немного больше ОЗУ дает ценную скорость и время отклика.