Влияет ли фрагментация данных на скорость random-доступа?

Рубрика: Storages,Новое. Автор: Romx. Понедельник 16 Ноя 2009 в 23:17

Одной из вечных тем FUD-а конкурентов NetApp является «проблема» с фрагментаций данных в WAFL.
Оставим сейчас в стороне вопрос, насколько фрагментация действительно проявляется в практической жизни (я на эту тему уже писал ранее). Рассмотрим только вопрос того, насколько такой эффект вообще имеет место быть в теории.

Алекс Макдональд, инженер NetApp, в своем блоге привел любопытную модель, оценивающую влияние фрагментации на эффективность, в случае случайного (random) по характеру доступа.

Он заполнил таблицу из ста строк сотней случайных чисел, взятых с random.org, в первом столбце, которые изображают фрагментированные данные, затем второй столбец также случайными числами, изображающими то, какой блок программа запросила, в случае рандомного доступа к данным. И наконец он сравнил суммарное расстояние «seek» в случае считывания запрошенных данных (второй столбец) из максимально фрагментированного массива (первый столбец) и упорядоченного (то есть просто от 1 до 100).





Random Placement

Random Requested Block

Matching Block (Random Placement)

Seek Distance (Random Placement)

Seek Distance (Sequential Placement)

67

80

22

0

0

19

37

58

36

43

75

18

61

3

19

23

26

53

8

8

85

57

63

10

31

59

100

14

49

43

14

59

6

8

41

SUM

  

  

3269

3322

С точки зрения «здравого смысла» мы бы ожидали, что фрагментированный столбец даст значительно (или хотя бы заметно) большую величину «seek», по сравнению с упорядоченным, однако этого не произошло! Более того, столбец со случайно заполненными данными, из которого столь же случайно «запрашиваются» числа имел даже чуть меньший «seek» чем полностью упорядоченный! (Впрочем, ясно видно, что на достаточно большом интервале эти числа будут стремиться сравняться, так что можно просто принять их равными).

Несколько неожиданный для «здравого смысла» результат, однако, поразмыслив, нельзя не признать его правильным. «Случайное» помноженное на «случайное»  не дает «случайное в квадрате». :)

Отсюда немного парадоксальный вывод: В случае случайного (random) по характеру доступа к данным, а именно такой тип нагрузки обычно и принято тестировать в первую очередь, так как он наилучшим образом соответствует работе современных многозадачных серверных систем и баз данных OLTP, фрагментация (случайность их размещения) данных на диске практически не увеличивает количество «вредоносного» seek distance по сравнению со случайным чтением упорядоченных данных, и не ухудшает характеристики производительности!

romx

http://blog.aboutnetapp.ru/


 


Версия для печати Версия для печати
3 комментария »

  1. Отзыв от mikas — 17 Ноябрь 2009 в 5:50

    Это вообще про что? Заголовок статьи не информативен.

  2. Отзыв от romx — 17 Ноябрь 2009 в 5:55

    «До Штирлица не дошла шифровка из центра» :)

  3. Отзыв от MaximillianGreat — 17 Ноябрь 2009 в 15:43

    +1 вроде всё понятно.

RSS-лента комментариев. Адрес для трекбека

Ваш отзыв



Я не робот.



Рейтинг@Mail.ru Яндекс цитирования