Хранилище данных: технология Tiering. Почему не надо?
При закупке оборудования под крупный проект чаще всего для хранения данных СУБД выбирают отдельный сервер хранилища с большим количеством корзин для дисков. Администратор этой инфраструктуры, как правило не работающий напрямую с 1С, сразу же ныряет в море соблазнов. Одной из таких манящих фишек является технология Tiering, он же HSM.
Суть этой технологии довольно проста и понятна: для экономии денежных средств корзина набивается дисками с разными характеристиками, например SATA, SAS HDD и SSD и разными типами RAID. Наибольший объём, например 80%, набирается с помощью "архивных" HDD-дисков, которые самые медленные но и при этом самые дешёвые - за счет них и добиваются экономии. Наименьший объём в такой конфигурации имеют, как правило, SSD-диски класса "энтерпрайз", т.к. они самые дорогие. Даже с учётом их малого количества эти диски могут стоить половину всей системы хранения.
Хранилище может суммировать весь объём этого "винегрета" и представить его в виде единого тома. Таким образом, ваши данные будут автоматически раскиданы по дискам различного типа. Замысел технологии Tiering предполагает, что горячие данные, пользующиеся наибольшей популярностью, будут автоматически располагаться на самых быстрых дисках, а редко используемые данные будут со временем "сосланы" на самые медленные архивные.
У неопытного админа при первом знакомстве с этой технологией сразу же возникает идея расположить базу данных 1С на томе с функцией Tiering. Ведь вроде бы классная задумка: допустим база ERP с годами распухнет до терабайта, но всё старое и ненужное само сливается в архив, а данные текущего месяца будут располагаться на быстрых дисках. Пользователи будут счастливы, а финансисты будут ещё счастливее, т.к. докупать придется только дешёвые архивные диски. Экономия!
Но в этой прекрасной задумке есть один подвох, который рушит всю идею. Дело в том, что современные СУБД являются так называемыми "версионниками". PostgreSQL в первую очередь, в самой лютой его форме - версии строк пишет прямо в таблицу с данными. Microsoft SQL Server тоже, в режиме Is Read Committed Snapshot Isolation On (все современные конфигурации 1С устанавливают этот режим) включает версионирование, правда делает это более разумно - в TempDb. Но при сбросе данных в MDB нет никакой гарантии что измененная страница данных ляжет в тот же самый физический блок откуда он был прочитан. Oracle для версионирования использует журнал транзакций и возможно с ним не всё так плохо - не пробовал. Что касается PostgreSQL, то физический блок может перезаписывается только при осуществлении специальных процедур типа VACUUM. Таким образом, при подсчете "популярности" для функции Tiering, практически все записанные терабайты будут иметь примерно плоский график рейтинга физических блоков, а система при попытке переносить данные на быстрые и медленные диски будет совершать ошибки из-за малой дисперсии этой оценки. Не поможет даже подсчет количества чтений, т.к. во-первых по природе современные конфигурации типа 1С ERP имеет соотношение чтения к записи примерно 1 к 1, во-вторых чтение актуальных данных также будет следовать за новыми записанными блоками.
Также у платформы 1С существует операция "Реструктуризация таблиц", которая будет запускаться, как минимум, при обновлениях, как максимум - при активной разработке программистами, и результат этой операции также полностью обнуляет накопленную статистику по обращениям к физическим блокам, т.к. таблицы при реструктуризации пересоздаются заново.
Не поможет вам и настройка виртуального диска, когда его помечают типом "Performance". По задумке, в этом режиме все новые данные сначала записываются на самые быстрые диски, а затем мигрируют на более медленные. Но в реальности никаким аналогом кэша это не является, т.к. данные в хранилище мигрируют в фоновом режиме крайне медленно, гораздо медленнее чем вы думаете! В том числе и по причинам плоского графика оценки физических блоков. В итоге быстрый диск быстро переполняется и запись новых данных автоматически перенаправляется на более медленные диски, а в запущенном случае уже и на архивные!
Таким образом, включать эту функцию следует лишь для файловых серверов, и то не для всех случаев, так как современые файловые системы, например btrfs или zfs также являются "версионниками"!