Добрый день, коллеги.
В этой статье хотелось бы затронуть тему таблиц с типом «Строка».
Для многих администраторов баз данных этот тип таблиц долгое время оставался наиболее естественным типом, так сказать, типом по умолчанию.
Таблицы типа СТОЛБЕЦ в основном встречались в Хранилищах данных, то есть базах данных с преобладающей нагрузкой типа OLAP. Основная идея инженеров SAP при разработке базы данных HANA заключалась в объединении двух миров OLTP и OLAP-приложений.
В результате таблицы столбцов в базе данных HANA стали таблицами по умолчанию, но, несмотря на преимущества таблиц столбцов в большом количестве сценариев, база данных HANA продолжает использовать таблицы строк.
Об особенностях использования такого типа стола пойдет речь в этой статье.
Таблицы типа «Строка» хранятся в специальной области памяти, называемой разделяемой памятью.
При запуске базы данных эта область полностью загружается в память и остается там до тех пор, пока работает база данных.
В таблицах типа «Строка» все данные располагаются в строках друг за другом, что упрощает доступ ко всем строкам таблицы.
А вот доступ ко всем значениям столбца немного сложнее, так как эти значения не могут быть перенесены из основной памяти в ЦП с той же эффективностью, что и в случае со столбчатым хранилищем.
Сжатие данных при использовании этого типа хранилища также менее эффективно.
Классический подход к реляционным базам данных, в которых данные хранятся в табличном формате, заключается в хранении их способом, напоминающим структуру логической таблицы.
Каждая запись хранится как объединенная часть значений каждого столбца таблицы.
Ниже представлена таблица с классическим типом хранения.
Пример таблицы с классическим хранилищем Эта конструкция имеет очевидное преимущество, заключающееся в прямом сопоставлении представления логической таблицы и операций, выполняемых над ней, с реальными манипуляциями с данными, происходящими в памяти.
Это представление проще для разработчиков баз данных и администраторов баз данных.
Представление таблицы в памяти с сохранением строк Такое представление данных также имеет свой недостаток; дело в том, что для многих операций с базой данных этот подход не очень эффективен.
База данных не может напрямую обращаться к определенным столбцам таблицы.
Вместо этого страницы данных должны быть переданы в ЦП для сканирования сохраненных строк по порядку, по идентификатору условия.
где для определенных столбцов.
Пример сканирования строк в таблицах с типом хранилища «Строка» и «Столбец» Поскольку данные перемещаются из основной памяти в кэш ЦП, это влияет на производительность, особенно в приложениях массовой обработки данных, таких как хранилища данных и аналитические запросы.
В то время как для смешанного типа рабочей нагрузки, когда осуществляется доступ к одной или нескольким записям со всеми столбцами, этот метод хранения предпочтителен, поскольку требование преобразования данных из внутреннего хранилища во внешнее представление (также называемое проекцией) для клиента базы данных минимально.
В базе данных HANA таблицы с типом Row-store имеют ряд ограничений:
- таблицы не могут быть секционированы
- нет алгоритма сжатия таблиц
- Столбцу в такой таблице нельзя предоставить отдельный доступ, а также параллельный доступ.
- таблицу невозможно выгрузить из памяти
- если таблицу со строковым типом невозможно полностью загрузить в память, сервер базы данных не сможет запуститься
- Для построения большинства информационных моделей таблицы этого типа нельзя использовать напрямую.
Хотя вы можете выбрать тип используемого индекса, обычно в этом нет необходимости.
SAP HANA будет использовать тип cpb+-дерева, определяемый полем или комбинацией полей строкового, двоичного или десятичного типа.
Для всех остальных типов будет создан классический индекс b-дерева.
Индексы таблиц с хранилищем строк не сохраняются в базе данных постоянно; вместо этого они создаются заново каждый раз, когда таблица загружается в память (запуск базы данных).
Управление многоверсионным параллелизмом
Многоверсионный контроль параллелизма (MVCC) — это концепция, которая обеспечивает согласованность транзакционных данных путем изоляции транзакций, которые одновременно обращаются к одним и тем же данным.Чтобы это реализовывалось параллельно, сохраняется несколько версий записи.
Проблемы с MVCC обычно связаны с большим количеством активных версий записи.
Старые версии время от времени приходится удалять, чтобы освободить память.
Таблицы столбцов и строк реализуют эту функцию совершенно по-разному.
Для таблиц хранилища строк каждая измененная страница сначала копируется и помещается в цепочку версий страниц, где каждая версия имеет состояние данных для конкретной операции фиксации.
Эти цепочки страниц хранятся в виртуальном контейнере в памяти, называемом отменой.
Представление мониторинга M_UNDO_CLEANUP_FILES показывает подробную информацию об этих внутренних файлах виртуального контейнера.
Сборщик мусора отвечает за удаление старых версий записи.
Сбор мусора происходит после операции фиксации, а также периодически (по умолчанию каждый час).
Сборщик мусора может удалять только старые версии записей, для которых были завершены транзакции обновления (выполнена операция фиксации или отката).
Если транзакция изменяет десятки или тысячи строк без фиксации изменений, вы можете оказаться в ситуации, когда большой объем избыточных данных необходимо хранить в основной памяти, поскольку в записях базы данных будут храниться десятки тысяч заблокированных версий.
и новые активные версии пластинки.
Я уже видел картинку, где в памяти больших таблиц хранилось до 8 миллионов версий записей.
Если посмотреть представление с потоками (например M_SERVICE_THREADS), то в поле Thread Type периодическая сборка мусора будет обозначена как «MVCCGarbageCollector».
Чтобы найти транзакции, зафиксировавшие свои изменения, необходимо сделать выборку в представлении потоков, используя условия THREAD_TYPE=’SqlExecutor’ и THREAD_METHOD=’CommitTrans’.
Реорганизация торговой площади
Реорганизация хранилища строк — это процесс дефрагментации сегментов памяти для более компактного хранения.Несмотря на значительные улучшения в самом процессе реорганизации, который претерпел значительные изменения со времен HANA 1.0, сама процедура по-прежнему остается проблематичной.
Об этом я расскажу ниже, а сейчас немного общей информации.
Пространство хранилища строк увеличивается за счет выделения сегментов памяти по 64 МБ.
Сегмент внутренне разделен на страницы фиксированного размера.
Когда таблице с хранением строк требуется больше памяти для хранения записей, свободные страницы выделяются из существующего сегмента.
Если в сегменте больше нет свободных страниц, выделяется новый сегмент. Удаление большого количества записей может привести к появлению разрозненных сегментов.
В этом случае может помочь реорганизация области хранения строк для более компактного хранения в памяти.
Страницы из разбросанных сегментов перемещаются в другие сегменты, освобождая свободное место.
SAP рекомендует реорганизовать пространство Row Store, если его размер превышает 10Гб и имеется более 30% свободных блоков.
В базе данных HANA доступны два режима реорганизации пространства: ONLINE и OFFLINE. ОНЛАЙН-реорганизация стала доступна начиная с версии HANA 1.0 SPS8. С тех пор этот режим постоянно совершенствовался, чтобы снизить влияние на бизнес-процессы и повысить эффективность хранения в зоне магазина «Ряд».
До версии SAP HANA 2.0 SPS3 включительно при проведении онлайн-реорганизации на таблицы, участвующие в реорганизации, устанавливалась монопольная блокировка, в результате чего изменение записей в этих таблицах было невозможным.
Начиная с SAP HANA 2.0 SPS4, в процессе реорганизации произошли изменения; теперь при онлайн-реорганизации блокировка устанавливается на уровне строки, а не всей таблицы.
Согласно онлайн-рекомендациям SAP, для достижения наилучшего результата реорганизацию следует запускать в период минимальной нагрузки.
Именно в этом состоит основная претензия к данному режиму реорганизации; это не позволяет добиться того же результата, что и в случае OFFLINE-реорганизации.
До версии HANA 2.0 SPS4 SAP рекомендовала использовать автономный режим для получения наилучшего результата.
В то же время режим OFFLINE имеет один существенный недостаток, который логично вытекает из его названия.
Никто не остановит работу системы в режиме 24х7 для реорганизации рядового пространства.
Поэтому OFFLINE-реорганизация обычно совмещается с другими работами, требующими остановки системы.
Внимание! АВТОНОМНАЯ реорганизация может значительно увеличить время запуска базы данных HANA. Начиная с версии SAP HANA 2.0 SPS4 стал доступен режим автоматической реорганизации ОНЛАЙН.
По умолчанию проверка на фрагментацию области хранения строк запускается один раз в час.
Если эффективное использование памяти составляет менее 60 % от размера хранилища строк, запускается автоматическая реорганизация.
Порог фрагментации, а также частоту выполнения сканирования можно изменить.
Более подробную информацию об автоматическом режиме можно найти в примечании 2789255 — Автоматическая реорганизация рядного интернет-магазина.
На этом хотелось бы завершить краткий обзор таблиц с типом хранения «Строка».
Несмотря на преимущества таблиц столбцов, таблицы строк продолжают использоваться в базе данных HANA. В основном такие таблицы используются в качестве технических или конфигурационных таблиц с относительно небольшим количеством записей, при этом основная роль отводится таблицам со столбчатым типом хранения.
Теги: #Администрирование базы данных #sap #in-memory #sap hana #sap base #база данных в памяти
-
Хостинг Ipage Против Хостинга Fatcow
19 Oct, 24 -
Автомобильное Крепление Для Ноутбука
19 Oct, 24 -
Вр - Выпуск №46
19 Oct, 24
