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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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