Автор: Curt Monash
Дата публикации оригинала: 2008-09-01
Перевод: Олег Кузьменко
Источник: Блог Курта Монаша

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

  • Индексы и временное рабочее пространство. Это то, о чем я уже писал пару лет назад в моем посте о коэффициентах расширения.
  • Сжатие данных. Я много писал о компрессии данных.
  • Избыточные диски. Я обычно обхожу этот вопрос стороной, но в этом посте я постараюсь реабилитироваться.
  • Репликация - отличающаяся от той, что была разработана, главным образом, для целей резервирования. Я также обхожу молчанием этот аспект, и, я думаю, что лучше поступать так и дальше. Это потому, что репликация в хранилищах данных – по крайней мере, в большинстве архитектур, с которыми я знаком – обычно подразделяется на три категории:

    • что-то очень похожее на резервирование
    • что-то очень похожее на индекс
    • что-то второстепенное (например, когда небольшие таблицы-факты реплицируются по всем узлам MPP-кластера)

Люк Лонерган (Luke Lonergan), технический директор компании Greenplum, недавно познакомил меня с арифметикой использования дисков для самой часто встречающейся конфигурации (серверы хранения Sun Thor, сконфигурированные в RAID 10). Мне его рассказ показался довольно интересным, и, я думаю, что он является хорошим руководством по учету факторов, которые также воздействуют на системы других поставщиков.

* Я так думаю, что “Thor” является преемником “Thumper” (Thumper – сервер хранения данных SunFire X4500 компании Sun - прим. переводчика), поскольку их имена образуют аллитерацию (аллитерация – специальный прием, происходит тогда, когда в ряду слов несколько из них начинаются с одинаковых согласных звуков - прим. переводчика). Кроме того, бог Тор, как известно, крушил все (игра слов: в оригинале стоит “Thor thumped things”; Тор – бог молнии и грома в германо-скандинавской мифологии, глагол “thump” означает «наносить тяжелый удар, дубасить, стучать» - прим. переводчика).

Итак, приступим.

  • В корпусе Thor имеется 48 дисков.
  • 2 диска используются операционной системой, а не данными.
  • Еще 2 диска отведены под горячее резервирование.
  • Следовательно, остаются 44 диска, которые могут хранить данные.
  • Поделите это число на 2 (из-за RAID 10) .
  • При форматировании теряется 10% или около этого.
  • На место для временного хранения уходит одна треть (0.33) от пользовательских данных. Зеркалирование между узлами также уменьшает доступный объем. Взятые вместе, эти два фактора уменьшают место еще в 2.33 раза.

Таким образом, перед тем, как мы вовлечем в процесс сжатие данных, объем, доступный для данных пользователя в системе из 48 дисков, составляет 8.5 * номинальную емкость одного диска (который может составлять ¼, ½, или 1 терабайт). Однако, для пущей верности, Greenplum заявляет, что этот коэффициент равен 6, т.е. своего рода «коэффициент потерь» составляет 8:1.

И чтобы запутать окончательно, скажем, что сжатие может вернуть все или почти все это назад. Например, для клиента, у которого объем хранилища равен нескольким петабайтам и который сейчас загружает данными свои системы Greenplum/Thor (статья написана 1 сентября с.г. – прим. переводчика), ранние оценки показывают, что коэффициент сжатия составляет 7.5. (На самом деле, я не спрашивал, но полагаю, что это с учетом индексов, что является общепринятым при обсуждении показателей суммарного сжатия. Тем более что, насколько я понял те приложения, для которых используется система, там все равно нет большого числа индексов).

Итак, после всех этих вычислений получается, что объем пользовательских данных почти равен объему системы хранения. (Для поставщика или СУБД, у которых другой коэффициент сжатия, это примерное равенство, конечно же, не выполняется).

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

Ссылки на статьи Курта по следующим категориям (на английском языке):
Data warehousing, Database compression, Greenplum, Theory and architecture


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

Читайте также: