Эволюция данных: хранение и разделение
В жизненном цикле данных в МОГучем хранилище данных участвуют данные в разных состояниях. Когда некоторый источник данных в первый раз загружается в систему, аналитики обычно часто обращаются к нему, выполняя существенные аналитические и трасформационные операции. Когда для некоторого источника данных преобразования и определения таблиц начинают стабилизироваться, рабочая нагрузка больше напоминает ту, которая свойственна традиционным EDW: частые добавления к большой таблицы "фактов" и редкие обновления таблиц "детальных данных". Эти зрелые данные, наиболее вероятно, используются для эпизодического анализа и решения стандартных задач отчетности. Поскольку данные в таблицах "фактов" со временем стареют, обращения к ним могут происходить менее часто, и они даже могут перемещаться во внешний архив. Заметим, что в одном хранилище данных в любой момент времени могут сосуществовать данные во всех состояниях.
Поэтому в СУБД, хорошо подходящей для MAD-аналитики, требуется поддерживать несколько механизмов хранения данных, ориентированных на различные стадии жизненного цикла данных. На ранней стадии внешние таблицы обеспечивают легковесный подход к экспериментированию с преобразованиями данных. Таблицы детальных данных обычно обладают умеренными размерами и подвергаются периодическим обновлениям; для них хорошо подходят традиционные методы хранения транзакционных данных. В основном только пополняемые таблицы файлов лучше хранить в сжатой форме, позволяющей эффективно выполнять операции вставки и чтения данных за счет замедления операций обновления существующих строк. Должна поддерживаться возможность выгружать эти данные из хранилища данных по мере их старения без прерывания выполняемой обработки.
В Greenplum обеспечивается несколько механизмов хранения данных. Развитые средства спецификации разделения данных языка SQL позволяют применять эти механизмы к таблицам целиком или их частям. Как отмечалось ранее, в Greenplum поддерживаются внешние таблицы.
Также обеспечивается формат хранения вида "кучи" для часто обновляемых данных и возможность хранения таблиц в сильно сжатой форме, оптимизированной для выполнения операций добавления данных ("append-only", AO), для которых не предполагаются операции обновления. Оба эти механизма хранения данных интегрированы в транзакционную инфраструктуру. Для единиц хранения типа AO допускаются различные режимы сжатия. В одном крайнем случае, когда сжатие отключается, очень быстро выполняется загрузка массивных данных. При другой крайности используются наиболее действенные режимы сжатия, позволяющие расходовать как можно меньше пространства области хранения. Имеются и компромиссные режимы "среднего" сжатия, обеспечивающие эффективный просмотр таблиц для счет небольшого замедления загрузки. В последней версии Greenplum также появилось идейно близкое "поколоночное" разделение таблиц, ориентированных на добавление данных. Это способствует повышению уровня сжатия и гарантирует, что при выполнении запросов над крупными архивными таблицами из внешней памяти будут считываться только требуемые столбцы.
Администратор базы данных может гибким образом специфицировать требуемый механизм хранения. В Greenplum поддерживается много способов разделения таблиц с целью повышения производительности выполнения запросов и загрузки данных, а также содействия управлению крупными наборами данных. Самым верхним уровнем разделения является политика распределения (distribution policy), специфицируемая в разделе DISTRIBUTED BY оператора CREATE TABLE и определяющая, каким образом строки таблицы распределяются по отдельным узлам кластера Greenplum. В то время, как у всех таблиц имеется политика распределения, пользователь опционально может специфицировать для таблицы политику разделения (partitioning policy), которая разъединяет данные таблицы в разделы по диапазону или по списку. Политика разделения по диапазону позволяет пользователю специфицировать упорядоченный набор неперекрывающихся разделов для столбца разделения.
У каждого раздела имеются начальное (START) и конечное (END) значения. Политика разделения по списку позволяет пользователю специфицировать набор разделов для некоторой совокупности столбцов, причем каждый раздел соответствует некоторому конкретному значению. Например, таблица sales может быть хэш-распределена по узлам по sales_id. Кроме того, в каждом узле строки могут быть разъединены по диапазону в разделы по месяцам, а строки в каждом из этих разделов могут быть дополнительно разъединены по трем регионам продаж. Заметим, что структура разделения полностью поддается изменениям: в любой момент времени пользователь может добавлять новые разделы или удалять существующие разделы или подразделы.
Разделение таблиц важно по ряду причин. Во-первых, оптимизатор запросов осведомлен о структуре разделения и может анализировать предикаты с целью исключения разделов (partition exclusion): сканировать только некоторый поднабор разделов, а не таблицу целиком. Во-вторых, у каждого раздела таблицы может иметься свой формат хранения в соответствии с ожидаемой рабочей нагрузкой. Типичная схема состоит в разделении таблицы по полю временной метки и хранении старых разделов в сильно сжатом формате, ориентированном только на добавление данных, а более новых ("более горячих") разделов – в формате, в большей степени допускающем обновления данных. В-третьих, становится возможным атомарный обмен разделами (atomic partition exchange). Вместо того, чтобы вставлять в таблицу по одной строке за раз, пользователь может воспользоваться ETL или ELT для размещения своих данных в некоторой временной таблице. После того, как данные очищены и преобразованы, можно воспользоваться командой ALTER TABLE ... EXCHANGE PARTITION для привязки этой временной таблицы в качестве раздела существующей таблицы путем выполнения быстрой атомарной операции. Эта возможность делает разделение особенно полезным для организаций, которые выполняют ежедневные, еженедельные или ежемесячные массивные загрузки данных, и в особенности в тех случаях, когда они удаляют или архивируют старые данные для поддержки в хранилище данных в оперативном режиме некоторого окна данных фиксированного размера.Та же идея позволяет пользователям осуществлять физическую миграцию таблиц и модифицировать форматы хранения, ограждая производственные таблицы от накладных расходов загрузки и преобразования данных.
