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