Какова задержка в центре обработки данных? Я спрашиваю это, предполагая, что есть разности величин

Я пытаюсь понять что-то, на что просто не могу найти хороший ответ.

Если я скажу кеш REDIS (или какой-нибудь внешний кэш в памяти), расположенный в центре обработки данных, и сервер приложений, расположенный в том же центре обработки данных, то какова будет скорость сетевого подключения (задержка, пропускная способность) для чтения данных? между этими двумя машинами?

Будет ли, например, "скорость" сети, по крайней мере, на порядок выше скорости ОЗУ, которое ищет мои данные из кэша в REDIS?

Мой окончательный вопрос - это все, что находится в памяти REDIS, на самом деле предоставляет какую-либо полезность? В отличие от того, если REDIS кеширует все это вместо SSD? Память дорогая. Если сеть действительно не является узким местом В ЦОД, то память имеет значение. В противном случае это не так.

Я предполагаю, что мой общий вопрос заключается в том, что, несмотря на огромные неизвестные в центрах обработки данных и неспособность обобщать, а также на различия, мы говорим о достаточных порядках величины между задержкой памяти в компьютерной системе и даже лучшими внутренними сетями постоянного тока, чем память сокращение задержек не обеспечивает значительного улучшения производительности? Я понимаю, что есть много переменных, но насколько это близко? Это так близко, что эти переменные имеют значение? Например, возьмем гиперболическую позицию: ленточный накопитель НАМНОГО медленнее, чем сеть, поэтому лента не идеальна для кэша.

cache

— Neeraj Murarka
источник

Это также зависит от количества обращений за транзакцию, часто это реальная проблема, которую вы сериализуете в последовательности запросов. Более сложный интерфейс запросов, процедура на стороне сервера или кэш denormalizwd могут уменьшить влияние.

— Eckes

Ответы:

Существует несколько версий «графиков задержки, которые должен знать каждый», таких как:

Дело в том, что на самом деле задержка не ограничивается. Это сочетание факторов.

Итак, какова задержка сети в центре обработки данных? Задержка, ну я бы сказал, что это «всегда» ниже 1 мс. Это быстрее чем RAM? Нет. Это близко к оперативной памяти? Я так не думаю.

Но остается вопрос, актуально ли это. Это то, что вам нужно знать? Ваш вопрос имеет смысл для меня. Поскольку все имеет свою стоимость, вы должны получить больше оперативной памяти, чтобы все данные могли оставаться в оперативной памяти, или время от времени можно будет читать с диска.

Ваше «предположение» состоит в том, что если задержка в сети выше (медленнее), чем скорость SSD, вы не выиграете, имея все данные в ОЗУ, поскольку у вас будет медленная работа в сети.

И это будет выглядеть так. Но вы также должны учитывать параллелизм. Если вы получаете 1000 запросов данных одновременно, может ли диск выполнить 1000 одновременных запросов? Конечно, нет, так сколько времени потребуется для обслуживания этих 1000 запросов? По сравнению с оперативной памятью?

Трудно свести это к одному фактору, такому как тяжелые нагрузки. Но да, если бы вы выполняли одну операцию, задержка сети такова, что вы, вероятно, не заметите разницу между SSD и RAM.

Так же, как пока на рынке не появился диск 12 Гбит / с, сетевое соединение 10 Гбит / с не было бы перегружено одним потоком, поскольку диск был узким местом.

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

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

До сих пор я избегал некоторых деталей вашего вопроса, в частности, части Redis.

Redis - это хранилище структуры данных в памяти с открытым исходным кодом (лицензировано BSD), используемое в качестве базы данных, кэша и посредника сообщений. - https://redis.io/

ОК, значит, все в памяти. Извините, этот быстрый SSD-накопитель здесь вам не поможет. Redis может сохранять данные на диске, поэтому он может быть загружен в ОЗУ после перезагрузки. Это только для того, чтобы не «потерять» данные или не заполнить холодный кеш после перезагрузки. Так что в этом случае вам придется использовать оперативную память, несмотря ни на что. У вас должно быть достаточно оперативной памяти для хранения вашего набора данных. Недостаточно ОЗУ, и я думаю, что ваша ОС будет использовать swap- вероятно, не очень хорошая идея

— ETL
источник

Благодарю. Это действительно полезно. Здесь действительно много контекстуальных различий, которые имеют отношение к этому. Если мы на мгновение проигнорируем большие нагрузки, то из вашего ответа станет очевидным, что задержка сети является узким местом, поэтому дополнительная задержка SSD по сравнению с ОЗУ просто не имеет существенного значения. Но теперь, если мы примем во внимание большие нагрузки, различия в задержке SSD относительно ОЗУ начнут увеличиваться, и теперь ОЗУ будет светиться. Это то, к чему все сводится?

— Neeraj Murarka

Трудно свести это к одному фактору тяжелых нагрузок. Но да, если бы вы выполняли одну операцию, задержка сети такова, что вы, вероятно, не заметите разницу между SSD и RAM. Так же, как пока на рынке не появился диск 12 Гбит / с, сетевое соединение 10 Гбит / с не было бы перегружено одним потоком, поскольку диск был узким местом. Но помните, что ваш диск делает много других вещей, ваш процесс - не единственный процесс на машине и т. Д.

— ETL

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

— Хрилис - на забастовке -

Но 10-граммовая сетевая связь - низкий конец. Мои серверы подключены к моей магистрали с 200 гигабитами (да, 2x100g ссылки).

— TomTom

В компьютерных системах существует много уровней кэширования. Вставка одного на прикладном уровне может быть полезной, кешируя API и запросы к базе данных. И, возможно, временные данные, такие как пользовательские сессии.

Хранилища данных, такие как Redis, предоставляют такую услугу по сети (быстро) или через сокет UNIX (даже быстрее), как если бы вы использовали базу данных.

Вам нужно измерить, как на самом деле работает ваше приложение, но давайте сделаем пример. Скажем, обычный пользовательский запрос выполняет 5 запросов API, каждый из которых занимает 50 мс. 250 мс - обнаруживаемая пользователем задержка. Контраст с кэшированием результатов. Даже если кэш находится в другой зоне доступности по всему городу (не оптимально), попадания, вероятно, не более 10 мс. Что будет в 5 раз быстрее.

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

В качестве примера такого кэша в производственном процессе вы можете найти не что иное, как блог об архитектуре Stack Overflow . Сотни тысяч HTTP-запросов, генерирующих миллиарды хитов Redis, весьма значительны.

Память дорогая.

DRAM при времени доступа 100 нс примерно в 100 раз быстрее, чем твердотельное постоянное хранилище. Это относительно недорого для этого представления. Для многих приложений немного больше оперативной памяти покупает ценную скорость и время отклика.

— Джон Маховальд
источник

Не могли бы вы уточнить, как вы рассчитали, что каждый из этих 5 запросов API занимает 50 мс каждый? Является ли это тем, что приложение работает с базой данных, выполняет запрос и вычисляет результирующий набор, по сравнению с простым попаданием в кеш по всему городу, в котором кеширована сама строка запроса в качестве ключа, и есть кэшированная копия этого результата устанавливать?

— Neeraj Murarka

Я сделал эти цифры, но да. Выполнение запроса и вычисление результата снова, вероятно, будет медленнее, чем получение предварительно вычисленного результата. Такие реализации, как Redis, как правило, находятся в памяти для простоты и скорости. Обход IP-сети или транспорта сокетов UNIX также может быть довольно быстрым. Тем не менее, этот материал для кеширования не требуется для каждого дизайна.

— Джон

Понял. Я думаю, что я более или менее понимаю. Кажется, что во многих случаях, но не всегда, даже перемещение из центра обработки данных в соседний кеш, который, возможно, находится в одном и том же штате США (или в канадской провинции и т. Д.) (Возможно, регион - хорошая семантика), часто может быть большим преимуществом перед процессом, пытающимся пересчитать значение алгоритмически из его собственной локальной базы данных, если это действительно приводит к попаданию в кэш. Но затем, кэш, который может быть удаленным, не имеет большой ценности, будучи в памяти. Это может быть также на основе SSD.

— Neeraj Murarka

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

— Джон