Дедупликация, компрессия и I/O Size

Доброго времени суток! Есть задание, по которому одна высоконагруженная база данных используется для ведения складского учёта. Больше никаких вводных не дано. Для этой базы данных на СХД надо выбрать размер одного запроса он может быть 4 KB, 8 KB, 16 KB, 32 KB, 64 KB, or > 64 KB и использовать ли дедупликацию и компрессию.

0

впервые вижу такое понятие

Википедия Дедупликация (также дедубликация; от лат. deduplicatio — устранение дубликатов) — специализированный метод сжатия массива данных, использующий в качестве алгоритма сжатия исключение дублирующих копий повторяющихся данных. Данный метод обычно используется для оптимизации использования дискового пространства систем хранения данных, однако может применяться и при сетевом обмене данных для сокращения объема передаваемой информации. В процессе дедупликации во время анализа идентифицируются и запоминаются уникальные элементы информации фиксированного размера (англ. chunks). По мере выполнения анализа сравниваются все новые и новые элементы. При выявлении дублирующегося элемента, он заменяется ссылкой на уникальное вхождение (или на него перенаправляется уже существующая ссылка), а пространство, занимаемое дубликатом, высвобождается. Таких повторяющихся элементов может попадаться очень много, благодаря чему объём, необходимый для сохранения массива данных, может быть сильно сокращён. Однако дедупликацию не стоит путать с более традиционными алгоритмами сжатия, например LZ77 или LZO. Эти алгоритмы производят поиск в пределах определённого буфера отдельного файла (так называемое «скользящее окно»), тогда как алгоритм дедупликации производит поиск копий по огромному массиву данных.

0

Понимаете в чем дело. Сто процентов, что никто от вас не ждет точного ответа на поставленный вопрос.
А ждут от вас (скорее всего) размышления на тему, каким образом эта база может использоваться (почему она высоконагруженная), каким может быть профиль использования СХД в том или ином режиме, и как зависит размер запрашиваемого пакета от режима использования СХД. Зачем вообще нужна дедупликация, когда её оправдано применять, а когда крайне противопоказано, ваши предположения о пропусконой способности канала между базой и СХД и т.д. и т.п.

Поэтому если вам ответят, что надо выбрать запрос размером 8Kb без дедупликации и компресии, то этот ответ вам ничего не даст абсолютно

0

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

0

По моему опыту дедупликация катастрофически снижает скорость записи на дисковый массив.
Поэтому для ОНЛАЙН данных (база) я бы её включать не стал.

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

Дедупликация нормальна, например, для бэкапов, и то там куча подводных камней в виде скорости бэкапа.
Если вам надо забэкапить 100 Тб базу - то с дедупликацией вы будете неделю бэкап делать.

Размер блока должен как-то коррелировать с размером блока в файлах БАЗЫ. Иначе за один запрос у вас база будет либо перечитывать, либо недочитывать = неэффективно тратиться пропускная способность канала до СХД.

Кароче, без анализа прикладной области (что за база, какой размер базы, какой размер блока в базе, скорость прироста в сутки, объем запросов, количество пользователей, частота отчетности в базе) проще плюнуть в потолок и сказать "ну давайте вот так возьмем".

1

Про дедупликацию я понял. А что с компрессией?

0