Зараз мережі швидші, ніж диски?

Це питання розробки програмного забезпечення

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

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-версія або на слайд-пошта.net

З доповіддю виступили на дистрибуції широкомасштабних систем та середнього програмного забезпечення (LADIS) 2009 року .

Інша інформація

• Порада Google Pro: Використовуйте підрахунки зворотного конверту, щоб вибрати найкращий дизайн
• Stanford 295 Поради щодо інженерії програмного забезпечення від побудови широкомасштабних розподілених систем

Кажуть, що gcc -O4 надсилає ваш код Джеффу Діну для перезапису.

Є багато змінних, коли мова йде про мережу проти диска, але в цілому диск швидший.

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

Зараз я навіть не торкався того факту, що все, що ви перевозите по мережі, все одно збирається з диска або йде з ним ... так що ....... знову ж, диск швидше.

Ну, це залежить від того, чи має мережевий ресурс ті дані, про які ви запитуєте, легко доступні (у пам'яті чи подібних), чи буде він просто, у свою чергу, читати їх з диска.

У будь-якому випадку пропускна здатність в деяких випадках може бути вищою, але я вважаю, що затримка буде вищою.

IMX диск все ще швидший. Теоретична швидкість передачі мережі висока, але на практиці ви не наближаєтесь до цього.

Близько двох років тому у мене виникли проблеми з жорстким диском на ноутбуці, і DMA вийшов. Це зробило жорсткий диск значно повільнішим і, зокрема, повільніше, ніж мережевий. Але коли я перейшов на інший комп'ютер, я повернувся до свого початкового стану жорсткого диска швидше, ніж Інтернет.

Мій досвід роботи з гігабітними мережами полягає в тому, що ви маєте на увазі правильний сервер, що ви можете перемогти локальну продуктивність з точки зору пропускної здатності та затримки. Дивіться мережеві тести: чи отримуємо гігабітну продуктивність?

Для всіх практичних цілей я б рекомендував трактувати мережеві та локальні сховища як еквівалентні та використовувати лише кеші пам'яті.

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

Якщо ви використовуєте апарат низького рівня з повільним жорстким диском, то майже напевно буде швидше використовувати гігабітове мережеве з'єднання з сервером із швидким масивом зберігання даних.

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

Це залежить. Якщо ваш ввід / вивід є в основному випадковим доступом, то його плоска пропускна здатність, мабуть, не така велика порівняно з пропускною здатністю мережі, яка могла б бути доступною. Однак більшість мережевого трафіку в кінцевому рахунку генерується процесами, що включають введення-виведення. Якщо робочий набір будь-якого процесу, що генерує мережевий трафік, вписується в кеш, він не буде обмежений пропускною здатністю диска. Якщо він розтрощить кеш, диск стане вузьким місцем.

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

Мережеве сховище (тобто SAN), як правило, не працює на потокових робочих навантаженнях, якщо воно не налаштоване належним чином. Якщо SAN використовується для середовища консолідації загального призначення, він майже напевно буде налаштований досить неоптимально для потокового, колючого навантаження, як сховища даних. Я бачив, що біла книга постачальника припускає, що вам потрібно приблизно в 3 рази кількість дисків, щоб отримати ту саму пропускну здатність в SAN, яка не налаштована на потокове введення / виведення, як для того, який є.

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

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

Досвід, який я маю з цим, полягає в тому, що коли ви перебуваєте на підключенні 1 Гбіт і намагаєтеся завантажити файл, ваш жорсткий диск зазвичай є вузьким місцем. Однак ви повинні пам’ятати, що спочатку потрібно встановити з'єднання, що також потребує часу. Тож надсилання великих фрагментів мережі передачі даних може бути швидше, ніж диск.

Так, загалом, мережі зараз стають швидшими, ніж жорсткі диски, але це може змінитися з часом.

Я думаю, отже, я

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

Я вважаю за краще дивитися на це з точки зору компромісів, а не хто є найсильнішим ...

Ви повинні описати точний випадок використання для цього порівняння. Harddrives мають час пошуку + швидкість передачі та кеш-пам'ять. Мережі мають затримку, швидкість передачі та накладні витрати протоколу ...

Я думаю, що ваша оригінальна кеш-пам'ять> пам'ять> диск> мережа як і раніше, правда в цілому

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

Ну, є Light Peak, який націлений на швидкість мережі 100 Гбіт / с, що наближається до швидкості оперативної пам'яті. Звичайно, мережа може доставляти дані тільки так швидко, як відправник може генерувати дані, тобто якщо відправник зчитує дані з жорсткого диска, то приймач отримає дані лише з тією ж швидкістю, що і диск зчитується, навіть якщо надшвидка мережа.

Варто пам’ятати, що це залежить від мережі. Скажімо, наприклад, ви несете відповідальність за ефективність роботи на веб-сайті. Цей веб-сайт, звичайно, підключений до сервера баз даних через локальну мережу, а також підключений до веб-серферів через Інтернет, що також є своєрідною мережею.

У багатьох випадках між веб-сервером та сервером баз даних може бути встановлений спеціальний зв’язок за допомогою статичних IP-адрес та кроссовер-кабелю або automdx, щоб зменшити затримку та забезпечити виділене посилання для трафіку, оскільки ви хочете, щоб це було дуже швидким. Сервер бази даних виконує всі види роботи, щоб зберегти якнайбільше db в пам'яті, і в багатьох випадках часто домагається всього вмісту плюс кілька індексів. Запити до цієї бази даних будуть такими ж швидкими або навіть швидшими, ніж запити на диску.

З іншого боку, певні веб-технології (asp.net webforms viewstate, я дивлюся на вас) люблять висувати багато інформації на веб-браузер клієнта і з нього як кеш (на зразок). Якщо це локальне підключення до локальної мережі (а захист веб-форми asp.net - це справді велика частина часу), це не все так погано, але в загальнодоступному Інтернеті це може абсолютно знищити продуктивність, так що вам часто набагато краще натискати на це замість цього в базу даних або локальний диск.

Особисто я думаю, що слід враховувати кілька факторів. Наприклад, наскільки швидкою є пам'ять або диск, до якого ви здійснюєте локальний доступ, порівняно з тим, до якого ви мали б доступ через мережу? Якщо віддалені дані були на дуже швидкому SSD і швидше, ніж встановлена ​​гігабітна мережа, то віддалене може бути швидшим для великих потокових файлів.

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