Назад | Перейти на главную страницу

Сети теперь быстрее дисков?

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

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

cache memory > memory > disk > network

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

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

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

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

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

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

Для меня это шок; Моя ментальная модель такова, что круговой обход сети по своей сути медленный. И это не так - это в 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

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

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

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


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


Когда дело доходит до сети и диска, существует множество переменных, но в целом диск быстрее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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