Сети теперь быстрее, чем диски?

Это вопрос разработки программного обеспечения

Я работал над следующим правилом для скорости

cache memory > memory > disk > network

Каждый шаг в 5-10 раз превосходит предыдущий (например, кэш-память в 10 раз быстрее основной памяти).

Теперь кажется, что у гигабитного Ethernet задержка меньше, чем у локального диска. Поэтому, возможно, операции чтения из большой удаленной БД в оперативной памяти выполняются быстрее, чем чтение с локального диска. Это похоже на ересь для старого таймера, как я. (Я просто потратил некоторое время на создание локального кэша на диске, чтобы избежать необходимости выполнять обходы по сети - отсюда и мой вопрос)

У кого-нибудь есть опыт / цифры / советы в этой области?

И да, я знаю, что единственный реальный способ узнать это построить и измерить, но я задавался вопросом об общем правиле.

редактировать :

Это интересные данные из верхнего ответа:

• Туда и обратно в одном центре обработки данных 500 000 нс

• Поиск диска 10 000 000 нс

Это шок для меня; моя ментальная модель заключается в том, что круговая сеть является медленной по своей сути. И его нет - его в 10 раз быстрее, чем диск «туда-обратно».

Джефф Аттвуд опубликовал этот хороший блог на тему http://blog.codinghorror.com/the-infinite-space-between-words/

Вот некоторые цифры, которые вы, вероятно, ищете, по словам Джеффа Дина, сотрудника Google:

Числа, которые должен знать каждый

L1 cache reference                             0.5 ns
Branch mispredict                              5 ns
L2 cache reference                             7 ns
Mutex lock/unlock                            100 ns (25)
Main memory reference                        100 ns
Compress 1K bytes with Zippy              10,000 ns (3,000)
Send 2K bytes over 1 Gbps network         20,000 ns
Read 1 MB sequentially from memory       250,000 ns
Round trip within same datacenter        500,000 ns
Disk seek                             10,000,000 ns
Read 1 MB sequentially from network   10,000,000 ns
Read 1 MB sequentially from disk      30,000,000 ns (20,000,000)
Send packet CA->Netherlands->CA      150,000,000 ns

Это из его презентации под названием « Проекты, уроки и советы по созданию больших распределенных систем», и вы можете получить ее здесь:

• Доктор Джефф Дин Кейнот PDF или на slideshare.net

Доклад был сделан на крупномасштабных распределенных системах и промежуточном программном обеспечении (LADIS) 2009 .

Другая информация

• Совет Google Pro: используйте расчеты на основе конвертов, чтобы выбрать лучший дизайн
• Stanford 295 Talk Software Engineering Советы по созданию крупномасштабных распределенных систем

Говорят, что gcc -O4 отправляет ваш код Джеффу Дину по электронной почте для переписывания.

Существует много переменных, когда речь идет о сети по сравнению с диском, но в целом диск быстрее.

Шины SATA 3.0 и SAS имеют пропускную способность 6 Гбит / с по сравнению с сетью 1 Гбит / с минус издержки протокола. С RAID-10 15k SAS сеть будет казаться очень медленной. Кроме того, у вас есть дисковый кеш, а также возможность использования твердотельных жестких дисков, которые в зависимости от сценария также могут увеличить скорость. Случайный или последовательный доступ к данным играет роль, а также размер блока, в котором данные передаются. Все зависит от приложения, которое используется для доступа к диску.

Теперь я даже не коснулся того факта, что все, что вы транспортируете по сети, собирается или приходит с диска в любом случае ... так что ....... снова, диск быстрее.

Ну, это зависит от того, есть ли у сетевого ресурса данные, которые вы запрашиваете, легкодоступные (в памяти и т. П.) Или просто он, в свою очередь, считывает их с диска.

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

IMX диск все еще быстрее. Теоретическая скорость передачи данных в сети высока, но на практике вы не приближаетесь к этому.

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

Мой опыт работы с гигабитными сетями при наличии правильного сервера позволяет вам повысить производительность на локальном уровне с точки зрения пропускной способности и задержки. См. Сетевые тесты: получаем ли мы гигабитную производительность?

Для всех практических целей я бы рекомендовал рассматривать сетевое и локальное хранилище как эквивалентные и использовать только кеши памяти.

Стандартное предостережение, как вы упомянули, верно в том, что нет общих правил; и что на самом деле большую часть времени следует работать с хорошо настроенными серверами и использовать метрики для оценки наилучшего метода передачи данных.

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

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

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

Я работаю в системах хранилищ данных, и канонический DW-запрос - это сканирование таблицы. Если ваш запрос встречает более нескольких процентов строк в таблице фактов (или разделе), то сканирование таблицы или раздела с использованием последовательного ввода-вывода будет более эффективным, чем план запроса произвольного доступа, использующий поиск и поиск по индексу.

Сетевое хранилище (т. Е. SAN) имеет тенденцию неэффективно работать с потоковыми рабочими нагрузками, если оно не настроено соответствующим образом. Если SAN используется для среды консолидации общего назначения, она почти наверняка будет настроена весьма неоптимально для потоковой, резкой нагрузки, такой как хранилище данных. Я видел, как в официальном документе поставщика указывается, что вам нужно примерно в три раза больше дисков, чтобы получить такую ​​же пропускную способность в сети SAN, которая не настроена для потокового ввода-вывода, как для той, которая есть.

Мой опыт соответствует этому. Фактически, я никогда не развертывал хранилище данных в среде консолидации, где я не смог бы значительно быстрее запустить тот же процесс ETL на своем настольном ПК. У меня также были торговые представители от крупного поставщика оборудования SAN, которые утверждают, что многие их клиенты используют хранилище с прямым подключением для системы DW, потому что SAN недостаточно быстры.

Сетевое хранилище по крайней мере на порядок дороже за IOPS, чем хранилище с прямым подключением для рабочих нагрузок с произвольным доступом, и ближе к двум порядкам дороже для потоковой передачи.

Мой опыт показывает, что когда вы подключены к сети 1 Гбит и пытаетесь загрузить файл, ваш жесткий диск обычно является узким местом. Однако следует помнить, что сначала нужно установить соединение, что также требует времени. Таким образом, для отправки больших кусков данных сеть может быть быстрее, чем диск.

Да, в целом, сети теперь работают быстрее, чем жесткие диски, но это может измениться со временем.

Я думаю, поэтому я

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

Я предпочитаю смотреть на это с точки зрения компромиссов, а не кто самый сильный ...

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

Я думаю, что ваша оригинальная кэш-память> память> диск> сеть все еще остается верным в целом, хотя

Диск связан с процессором через шину SCSI, SAS или IDE. Который является внутренней сетью, выполняющей определенный протокол - SCSI или ATAPI. Ethernet предназначен для работы на больших расстояниях и может работать намного медленнее, чем SAS / SCSI / IDE. То, какой из них быстрее, зависит от того, какие технологии вы сравниваете. Если вы сравните 20-летний жесткий диск ноутбука с 10 Гбит / с в оперативной памяти, победителем всегда будет сеть. А когда вы покупаете хранилище, вы должны сравнить его с ценой и управляемостью.

Ну, есть Light Peak, который стремится к скорости сети 100 Гбит / с, которая приближается к скорости ОЗУ. Конечно, сеть может доставлять данные только с той скоростью, с которой отправитель может сгенерировать данные, т. Е. Если отправитель читает данные с жесткого диска, то получатель получит данные только с той же скоростью, что и с диска, даже если сверхбыстрая сеть.

Нужно иметь в виду, что это зависит от сети. Скажем, например, вы несете ответственность за производительность на веб-сайте. Этот веб-сайт, конечно, подключен к серверу базы данных через локальную сеть, а также подключен к веб-пользователям через Интернет, который также является своего рода сетью.

Во многих случаях выделенная ссылка может быть установлена ​​между веб-сервером и сервером базы данных через статические IP-адреса и перекрестный кабель или automdx, чтобы снизить задержку и предоставить выделенную ссылку для трафика, поскольку вы хотите, чтобы он был очень быстрым. Сервер базы данных выполняет все виды работ, чтобы сохранить как можно большую часть БД в памяти, и во многих случаях это часто удается для всего содержимого плюс несколько индексов. Запросы к этой базе данных будут такими же быстрыми или даже более быстрыми, чем запросы на диск.

С другой стороны, некоторые веб-технологии (я смотрю на вас, asp.net webforms viewstate) любят выдавать большое количество информации в клиентский веб-браузер и из него в виде кэша (своего рода). Если это локальное подключение к локальной сети (и в защите веб-формы asp.net это верно в большинстве случаев), это не так уж и плохо, но в общедоступном интернете это может абсолютно убить производительность, так что вам часто гораздо лучше от этого избавиться. вместо базы данных или локального диска.

Лично я думаю, что есть несколько факторов для рассмотрения. Например, насколько быстро вы обращаетесь к памяти или диску локально по сравнению с тем, к которому вы обращаетесь по сети? Если удаленные данные были на очень быстром SSD и быстрее, чем установленная гигабитная сеть, удаленное устройство могло бы быть быстрее для больших потоковых файлов.

Однако если бы вы случайным образом обращались к небольшим блокам данных, а сеть не была безупречной или имела много переходов и не просто доступ к ней, я бы поспорил, что локальный кеш быстрее, чем его, на вращающемся механическом диске почти на 100%. % времени. Но вы затронули интересный момент, и как долго понадобится локальное хранилище чего-либо, если скорость сети будет расти?