Умные механизмы сжатия и дедублирования
Объемы данных сегодня растут лавинообразно. Многие приложения хранят данные за большой период времени, в БД хранятся LOB объекты, документы, видео и т.д. А стоимость дискового пространства до сих пор достаточно высока (до 1000$ за терабайт). Поэтому большинство производителей СУБД реализовало механизмы сжатия данных в БД. Речь идет о том, насколько умные эти механизмы сжатия. Дело в том, что за сжатие, разжатие и изменение сжатых данных приходится платить производительностью работы системы. Поэтому прослеживается тенденция к совершенствованию механизмов сжатия.
Во-первых, для разных данных должны автоматически применяться различные алгоритмы сжатия, а там, где сжатие не дает большого выигрыша, оно производиться не должно. Во-вторых, администратор должен иметь возможность выбирать различные уровни сжатия, понимая, что за экономию места придется платить процессорным временем. В-третьих, сжатие должно быть прозрачно для приложения, т.е. приложение не знает о том, сжаты ли его данные. В-четвертых, иногда для LOB полезен механизм дедублирования, когда система сама выявляет дубли LOB полей и хранит их только в одном экземпляре. В-пятых, сжимать надо уметь все. Не только реляционные, но и неструктурированные данные, backup, данные сетевого трафика, данные экспорта, индексы. А иногда надо, наоборот, сжимать не все данные таблицы, а только редко используемую часть таблицы. И СУБД должна работать со сжатыми данными так же эффективно, как и с несжатыми данными, не тратя время на перестройку таблиц, на разжатие ненужных блоков и т.д.
Традиционные алгоритмы сжатия позволяют сжать данные в 2-3 раза. Некоторые специфические виды сжатия позволяют увеличить эту степень сжатия на порядок, но при этом сильно замедляется выполнение операций DML с этими данными. Например, известно, что сжатие поколоночно хранимых и заранее отсортированных данных обеспечит очень высокий уровень сжатия (иногда в десятки раз). Однако попытки изменения таких таблиц в Oracle 11.2 показали, что время обновления данных значительно увеличивается. Но для хранилищ данных и исторических данных такой подход вполне приемлем.
Администратор должен иметь возможность для различных данных, различных таблиц и даже частей таблиц выбирать те варианты сжатия и хранения (по строкам, по столбцам), которые наиболее подходят с точки зрения бизнес-использования этих данных. Причем, поскольку для приложений способ хранения и сжатия прозрачен, DBA может периодически менять способы хранения и сжатия. Я думаю, этот подход будет очень полезен пользователям больших БД (например, SAP-пользователям), которые сегодня вынуждены постоянно увеличивать свои многотеррабайтные системы хранения. Ну, и умный механизм сжатия позволяет оставлять самые свежие и наиболее активно используемые данные некоторое время несжатыми. Позднее они сжимаются автоматически в фоновом режиме.
