Сжатие данных в целях экономии места и ускорения работы oracle


Содержание

for-ora-dba.ru

Все для Админов Oracle

Сжатие Таблиц: Краткий обзор

Сокращение затрат хранения путем сжатия всех данных:

Базовое сжатие для операций вставки по прямому пути: 10x

Сжатие OLTP для всех операций DML: 2–4x

База данных Oracle поддерживает три метода табличного сжатия:

Базовое табличное сжатие

Табличное сжатие OLTP

Гибридное колоночное сжатие (с Exadata)

Корпорация Oracle рекомендует сжимать все данные, чтобы уменьшить затраты хранения. База данных Oracle может использовать табличное сжатие, чтобы устранить дублированные значения в блоке данных. Для таблиц с очень избыточными данными сжатие сохраняет дисковое пространство и уменьшает использование памяти в буферном кэше базы данных. Табличное сжатие прозрачно для приложений базы данных.

Пункт table_compression допустим только для организованных в «куче» таблиц. Ключевое слово COMPRESS включает табличное сжатие. Ключевое слово NOCOMPRESS отключает табличное сжатие. NOCOMPRESS является значением по умолчанию.

С базовым сжатием база данных Oracle сжимает данные во время выполнения массовой загрузки, используя операции, такие как прямые загрузки или CREATE TABLE AS SELECT.

С COMPRESS FOR OLTP база данных Oracle сжимает данные во время всех операций DML на таблице.

Всё о сжатии данных, изображений и видео

Сравнения кодеков

Проекты

Разделы

Сайт подключен к Orphus. Если вы заметили опечатку, выделите слово и нажмите Ctrl+Enter. Спасибо!

Микел Посс,
Oracle Corporation

СЖАТИЕ ТАБЛИЦ В СУБД Oracle9 i RELEASE 2:
АНАЛИЗ ЭФФЕКТИВНОСТИ

(TABLE COMPRESSION IN Oracle9 i RELEASE 2:
A PERFORMANCE ANALYSIS,
BY MEIKEL POESS, ORACLE CORPORATION)
(ЧАСТЬ I)

Предисловие редакторов русского перевода

В данной работе анализируется эффективность механизма сжатия данных, появившегося в СУБД Oracle9 i, на примере сжатия таблиц схемы типа «звезда» и нормализованной схемы эталонных тестов TPC-H и TPC-R (то есть, типичных схем в системах поддержки принятия решений). Подчеркнем, сжатие данных, в результате которого может быть достигнута значительная экономия дискового пространства и пространства кеша буферов, не является самоцелью. Современные цены за «мегабайт» дисковой или оперативной памяти делают этот вопрос неактуальным. Главное здесь — повышение общей пропускной способности и уменьшение времени реакции больших систем.

Вместе с тем, следует отметить, этот механизм может быть эффективным и в традиционных интерактивных системах с интенсивным выполнением операций чтения данных с диска. Поскольку сжатие таблиц позволяет уменьшить их размер, это приводит к пропорциональному уменьшению времени, требуемому для резервирования и восстановления базы данных. Кроме того, сжатие таблиц будет несомненно эффективным при работе с табличными пространствами только для чтения (READ ONLY). И все это достигается без каких-либо изменений в приложениях, то есть, этим может заниматься администратор базы данных без привлечения разработчиков приложений.

Данная работа была также с незначительными изменениями опубликована как технический документ (white paper) корпорации Oracle — http://otn.oracle.com/products/bi/pdf/o9ir2_compression_performance_twp.pdf. Некоторые опечатки и ошибки в переводимом документе исправлены по данной публикации. Кроме того, на основании данного документа Микел Посс в соавторстве с Германом Баером (Hermann Baer) опубликовал в Oracle Magazine статью «Decision Speed: Table Compression In Action» (скорость принятия решений: сжатие таблиц на практике) — http://otn.oracle.com/oramag/webcolumns/2003/techarticles/poess_tablecomp.htm.

Дополнительно об оптимизации производительности в хранилищах данных можно прочитать в техническом документе «Data Warehouse Performance Enhancements with Oracle9 i«, An Oracle White Paper, April 2001, http://otn.oracle.com/products/Oracle9 i/pdf/o9i_dwperfcomp_dwflow.pdf.

Александр Соколов (ap_sokolov@mail.ru),
Виктор Сусойкин (susoikin@rdtex.ru),
компания РДТЕХ (www.rdtex.ru)

Сжатие таблиц (Table Compression) — новое средство, введенное в СУБД Oracle 9i Release 2, может быть использовано для сжатия целых таблиц, секций таблиц и материализованных представлений. Оно радикально уменьшает потребности в дисковом пространстве и кеше буферов и, во многих случаях, повышает производительность выполнения запросов, особенно в системах с интенсивным вводом-выводом. Сжатие ориентировано на приложения поддержки принятия решений и OLAP-приложения, но и в других областях могут быть также получены большие выгоды. После объяснения работы механизма сжатия таблиц в данной работе вводятся два типа схем, обычно используемых в системах поддержки принятия решений (как в OLAP-системах, так и в хранилищах данных), а именно, схемы типа «звезда» и нормализованные схемы. С помощью этих схем в двух основных разделах данной работы анализируется, как сжатие таблиц может привести к огромной экономии пространства, и исследуется влияние сжатия таблиц на запросы.

Функционирование механизма сжатия таблиц

СУБД Oracle9 i Release2 сжимает данные, устраняя дубликаты значений в блоках базы данных. В алгоритме используется метод сжатия информации без потерь на основе словаря (lossless dictionary-based compression technique) [4]. Сжатые данные, хранимые в блоках базы данных, являются самодостаточными (self-contained). То есть, вся информация, необходимая для восстановления исходных данных в блоке, находится в самом этом блоке. Алгоритм решает, исходя из длины столбца и количества экземпляров значений, будет ли для конкретного столбца создаваться вход в таблице идентификаторов (словаре). Сжимаются только целые столбцы или последовательности столбцов. Все экземпляры таких значений заменяются короткой ссылкой на таблицу идентификаторов. Для коротких значений и значений с небольшим количеством экземпляров входы в таблице идентификаторов не создаются. Чтобы добиться оптимальной производительности, столбцы в блоке могут быть переупорядочены. Тем не менее, это прозрачно для пользователей.

По сравнению с другими методами сжатия, в которых для сжатия целой таблицы используется фиксированное количество входов в таблице идентификаторов, обычно 256, реализация механизма сжатия в СУБД Oracle имеет много преимуществ. Во-первых, чтобы получить оптимальные результаты сжатия, в СУБД Oracle количество входов в таблице идентификаторов выбирается системой на уровне блоков во время загрузки данных. Во-вторых, входы в таблице идентификаторов создаются системой и для них не требуется пользовательская настройка. В-третьих, в СУБД Oracle алгоритм сжатия динамически адаптируется к изменениям распределения данных без компрометации механизма сжатия. Следовательно, для создания сжатой таблицы нужно только включить в определение таблицы ключевое слово COMPRESS.

На рис. 1 показаны различия между хранением данных в сжатом блоке по сравнению с несжатым блоком. Исключая таблицу идентификаторов в начале блока, сжатые блоки базы данных очень похожи на обычные блоки базы данных. Модификации кода, сделанные в СУБД Oracle для реализации механизма сжатия, были существенно локализованы. Были модифицированы только те части кода, которые имеют дело с форматированием блока и доступом к строкам и столбцам. В результате, сжатые блоки полностью прозрачны для пользователей базы данных и любых приложений, а все средства и функции СУБД, которые работают с обычными блоками базы данных, также работают и со сжатыми блоками базы данных.

Рис. 1. Сжатый блок по сравнению с несжатым блоком

Надписи на рисунке:
· Not Compressed — несжатый;
· Compressed — сжатый;
· Block — блок;
· Header Information — информация заголовка;
· Symbol Table — таблица идентификаторов;
· Raw Data — данные строк;
· Free Space — свободное пространство.

Конфигурация тестируемых схем (типа «звезда» и нормализованная)

В моделях схем, проектируемых для хранилищ данных, существует большое разнообразие способов размещения объектов схем. Одна из моделей схем для хранилищ данных — схема типа «звезда» (star schema). Другая схема — схема в третьей нормальной форме (3NF-схема, third normal form schema). Кроме того, некоторые схемы хранилищ данных не являются ни схемами типа «звезда», ни 3NF-схемами, они имеют свойства обеих схем; такие схемы представляются гибридными моделями схем.

СУБД Oracle9 i разработана для поддержки всех схем хранилищ данных наиболее эффективным способом. Некоторые средства могут быть специфическими для одной модели схем (такие, как преобразования запросов типа «звезда», специфические для схем типа «звезда»). Тем не менее, подавляющее большинство средств для хранилищ данных в СУБД Oracle в равной степени применимы для схем типа «звезда», 3NF-схем и гибридных. Основные функциональные возможности для хранилищ данных, такие, как секционирование (включая загрузку данных методом «скользящее окно» — rolling window load technique), параллелизм, материализованные представления и аналитический SQL, реализованы для всех моделей схем. (Прим. ред. С методом «скользящее окно» можно ознакомиться по [5].)

Определение, какую модель схемы следует использовать для хранилища данных, должно быть основано на требованиях и предпочтениях конкретной команды проектировщиков хранилища данных. Сравнение достоинств альтернативных моделей схем выходит за рамки данной работы. Вместо этого, в этой работе для иллюстрации сжатия для различных схем используются примеры схемы типа «звезда» и нормализованной схемы.

На рис. 2 показан пример схемы типа «звезда», подчеркивающий типичную структуру «звезда», в которой таблица фактов DAILY_ SALES (продажи) — центр «звезда», окруженный таблицами измерений: TIME (время), CUSTOMER (клиент), SALES REGION (регион продаж), ITEM (продукт) и PROMOTION (продвижение). Существует две таблицы итогов, определенные на таблице DAILY_SALES (дневные продажи): WEEKLY_SALES (продажи за неделю) и SALES_AGGR (агрегирование продаж). В таблице WEEKLY_SALES агрегируются продажи из таблицы DAILY_SALES по продуктам и клиентам за каждую неделю. Таблица SALES_AGGR строится на таблице DAILY_SALES с дальнейшим агрегированием по регионам продаж.

Рис. 2. Типичная схема типа «звезда»

В нашем втором примере мы показываем сжатие для различного типа нормализованных схем на примере стандартных эталонных тестов (benchmark) для оценки среды поддержки принятия решений TPC-H/TPC-R. (Прим. ред. О тестах TPC см. например, [6].) Схема этих тестов состоит из восьми базовых таблиц, моделирующих хранилище данных типичной среды розничной торговли (см. рис. 3). Таблицы, такие, как PART, SUPPLIER, PARTSUPP и CUSTOMER, содержат относительно статичную информацию о продуктах, которые типичная компания розничной торговли покупает у своих поставщиков (supplier) и продает своим клиентам (customer). Объем этих таблиц составляет примерно 15% от общего объема базы данных. Объем двух самых больших таблиц, LINEITEM и ORDERS, составляет примерно 85% от общего объема базы данных. Они содержат данные об отдельных сделках. В отличие от предыдущего примера эта схема не организована как схема типа «звезда», в ней используется нормализованный [3] подход.

Рис. 3. Нормализованные схемы эталонных тестов TPC-H и TPC-R

Экономия пространства в результате сжатия

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

Если таблица определена как «сжатая» (compressed), она будет использовать меньше блоков данных на диске, уменьшая, следовательно, потребности в дисковом пространстве. Данные из сжатой таблицы читаются в сжатом формате, и они восстанавливаются только во время доступа к ним. Поскольку данные кешируются в своем сжатом формате, то существенно больше данных может быть размещено в одном и том же объеме кеша буферов (см. рис. 4).

Рис. 4. Пути доступа к сжатым данным

Надписи на рисунке:
· Data Access Path with Compression — пути доступа к сжатым данным;
· Parallel Query Slave — подчиненный процесс параллельного запроса;
· Uncompressed when accessed — восстановление сжатых данных при доступе к ним;
· During direct read blocks are uncompressed immediately — во время прямого чтения блоки восстанавливаются немедленно;
· Buffer Cache — кеш буферов;
· Read compressed — чтение в сжатом формате;
· Compressed Database Table — сжатая таблица базы данных.

Перед измерением экономии пространства в результате сжатия двух наших демонстрационных схем мы определим коэффициент сжатия и экономию пространства. Коэффициент сжатия (КС) таблицы определяется как отношение количества блоков, требуемых для хранения несжатого объекта, к количеству блоков, требуемых для сжатого варианта:

Следовательно, экономия пространства (ЭП) определяется следующим образом:

Коэффициент сжатия главным образом зависит от содержимого данных на уровне блоков. Неповторяемые поля (поля с высокой кардинальностью), такие, как первичные ключи, не могут быть сжатыми, тогда как поля с очень низкой кардинальностью могут сжиматься очень хорошо. С другой стороны, более длинные поля позволяют получить больший коэффициент сжатия, поскольку экономия пространства будет большей, чем для более коротких полей. Кроме того, если в последовательности столбцов содержится одно и то же содержимое, алгоритм сжатия объединяет эти столбцы в элементе многостолбцового сжатия, что дает еще более лучшие результаты сжатия.

Таблица идентификаторов, в которой содержатся значения полей с множественными экземплярами, автоматически генерируется СУБД Oracle для каждого блока. В большинстве случаев большие размеры блоков позволяют увеличить коэффициент сжатия таблиц базы данных, поскольку с одной таблицей идентификаторов может быть связано большее количество значений столбцов.

Сортировка данных перед их загрузкой может дополнительно увеличить коэффициент сжатия. Чем больше полей с одинаковым содержимым сосредотачивается в каждом блоке, тем более эффективно работает алгоритм сжатия. Если вы знаете, что одно или несколько полей объекта базы данных имеют одинаковые значения — на это указывает небольшое количество уникальных значений сортировка данных по этим полям, вероятно, приведет к увеличению коэффициента сжатия. Тем не менее, сортировка по полям с очень низкой кардинальностью не обязательно приведет к большому увеличению коэффициента сжатия. В результате низкой кардинальности этого поля строки с одинаковыми значениями уже могут иметь высокую концентрацию в каждом блоке. Следовательно, лучшие результаты могут быть достигнуты сортировкой по полям, которые как длинные, так и имеют среднюю кардинальность.

Схема типа «звезда»


Таблицы фактов и таблицы итогов обычно являются самыми большими таблицами в схеме типа «звезда», занимая 70% или даже больше общего пространства базы данных. Напротив, таблицы измерений имеют очень маленький размер. Следовательно, сжатие таблиц измерений не приводит к большой общей экономии дискового пространства и его нужно рассматривать только при работе с очень большими измерениями. Поэтому мы для нашей конфигурации тестовых схем сжимаем только таблицы фактов и материализованные представления.

Рис. 5. Коэффициенты сжатия для схемы типа «звезда» и нормализованной схемы

Рис. 5 иллюстрирует, как хорошо сжимаются данные схемы типа «звезда» и нормализованной схемы. Коэффициенты сжатия для таблицы фактов DAILY SALES и таблицы итогов WEEKLY SALES в схеме типа «звезда» варьируются от 2.9 до 4.0, что приводит к экономии пространства от 67 до 75 процентов. То есть, для сжатого варианта таблицы WEEKLY SALES требуется только 25% дискового пространства и пространства кеша буферов по сравнению с ее несжатым аналогом, тогда как для сжатых вариантов таблиц DAILY SALES и SALES AGGREGATION требуется только 33% ресурсов по сравнению с их несжатыми аналогами. Общая экономия пространства базы данных при сжатии только таблиц фактов, достигнутая на схеме заказчика типа «звезда» приблизительно составляет 67% с коэффициентом сжатия, равным примерно 3.1.

Нормализованная схема (эталонные тесты TPC-H и TPC-R)

В нормализованных схемах для эталонных тестов TPC-H и TPC-R доминируют две таблицы: LINEITEM и ORDERS. Эти таблицы, в которых хранится информация о заказах, похожи на таблицы фактов в схеме типа «звезда», и они содержат приблизительно 75% всех данных. Сжатие таблицы LINEITEM — наибольшее, с коэффициентом сжатия, равным примерно 1.6, тогда как таблица ORDERS сжимается с коэффициентом сжатия, равным примерно 1.2 (см. рис. 5). Это означает, что для сжатых вариантов таблиц LINEITEM и ORDERS требуется приблизительно 60 и 80 процентов от объема несжатых таблиц. Общий коэффициент сжатия для базы данных эталонного теста TPC-H равен примерно1.4, что приводит к экономии пространства, приблизительно равной 29%.

Почему схема типа «звезда» сжимается лучше нормализованной схемы эталонного теста TPC-H

В двух предыдущих разделах мы рассмотрели коэффициенты сжатия и экономию пространства, которые могут быть получены в реальных схемах: схеме типа «звезда» и нормализованной схеме эталонного теста TPC-H. При сжатии всех таблиц фактов и таблиц итогов коэффициент сжатия для схемы типа «звезда» оказался приблизительно равным 3.1, что позволило сэкономить примерно 67% пространства. То есть, пространство, занимаемое базой данных на диске, сократилось в результате сжатия более чем на половину. С другой стороны, для нормализованной схемы, в которой сжимались две самые большие таблицы, эквивалентные таблицам фактов в хранилище данных, коэффициент сжатия оказался приблизительно равным только 1.4, а экономия пространства — 29%.

Коэффициент сжатия таблиц зависит от избыточности данных в этих таблицах. Данные сжимаются за счет устранения дубликатов значений в каждом блоке базы данных. Более высокая избыточность данных обычно позволяет получить более высокий коэффициент сжатия. Для таблицы, в которой содержится большое количество столбцов с небольшим количеством различающихся значений (на это указывает представление словаря данных DBA_TAB_COL_STATISTICS), автоматически не следует получение высокого коэффициента сжатия. Это скорее зависит от распределения данных и средней длины каждого конкретного столбца. Очевидно, распределение данных определяет количество потенциальных различающихся значений, а средняя длина столбца — количество записей, хранимых в одном блоке.

Рис. 6. Сжатие таблиц схемы типа «звезда» и схемы тестов TPC-H/R

Внимательное рассмотрение количества различающихся значений в двух столбцах (ADDRESS, REGION_ >

Предположим далее, что среднее количество строк в блоке (Block) равно 4. Тогда отображение строк на блоки будет выглядеть следующим образом:

Как видно, в каждом блоке содержится 4 различающихся значения. Впрочем, данная последовательность была выбрана для демонстрации равномерного распределения данных, она не является общим случаем. Читатель может проверить, что разные последовательности могут приводить к уменьшению количества различающихся значений в блоке.

Для столбцов схемы типа «звезда» измеренное среднее количество различающихся значений существенно меньше вычисленного количества различающихся значений. Это указывает на то, что данные являются не равномерно распределенными, а кластеризованными. Это очень распространенное явление для таблиц фактов и таблиц итогов в хранилищах данных; почти в каждой среде хранилища данных при периодическом обновлении данных происходит какое-то группирование или сортировка новых данных. Например, ETL-процесс (Прим. ред. ETL — Extraction, Transmission, Loading — технология извлечения, преобразования и загрузки данных.), собирающий новую информацию для таблицы фактов из различных источников, должен перед вставкой данных в таблицу фактов сравнивать и агрегировать их, то есть, сортировать данные. Аналогичная кластеризация данных происходит, естественно, и в таблицах итогов, которая выполняется с помощью группирования данных или специализированных OLAP-операций, таких, как операции суперагрегатного группирования rollup и cube.

С другой стороны, в схемах эталонных тестов TPC-H и TPC-R действительное количество различающихся значений в блоке совпадает с вычисленным количеством различающихся значений в блоке, что указывает на строгое равномерное распределение данных. В действительности, генератор данных эталонных тестов TPC-H и TPC-R критиковался за генерацию нормально распределенных данных.

Если данные не кластеризуются, как в случае тестов TPC-H и TPC-R, сортировка данных перед их загрузкой может существенно увеличить сжатие. Выбор столбцов для включения в сортировку зависит от их кардинальности и средней длины. В общем, длинные столбцы обеспечивают большее сжатие по сравнению с короткими столбцами. Что касается кардинальности, то оказалось, что сортировка по столбцам с очень низкой кардинальностью, таким, как GENDER (пол) или MARITAL STATUS (семейное положение), менее эффективна по сравнении с сортировкой по столбцам со средней кардинальностью. Оптимальными столбцами для сортировки представляются те, у которых кардинальность на уровне таблицы равна количеству строк в блоке. Сортировка по столбцам, кардинальность которых меньше количества строк в блоке, менее эффективна, поскольку значения столбца уже имеют большую избыточность. Сортировка по столбцам с каким-либо столбцом с более высокой кардинальностью также приводит к более высокому уровню увеличения сжатия.

Ссылки

  • [1] TPC-H 100 GB published 07/15/02 by HP/Oracle on Alpha Server ES45 and Oracle 9iR2 Executive Summary: http://www.tpc.org/results/individual_results/HP/es45_ 5578_es.pdf FDR http://www.tpc.org/results/FDR/tpch/es45_5578_fdr.pdf.
  • [2] Oracle9 i Data Warehousing Guide Release 2 (9.2) Part Number A96520-01.
  • [3] Date C.J. «An Introduction to Database Systems», Reading, Mass., Addision Wesley Verlag, 1981. (Прим. ред. Имеется русский перевод: Дейт К. «Введение в системы баз данных». 6-е изд. — М: Вильямс, 1999.
  • [4] Ziv J. and Lempel A. «A Universal Algorithm for Sequential Data Compression», IEEE Transactions on Information Theory, Vol. 23, pp. 337—342, 1977.
  • Ссылки к примечаниям редакторов русского перевода

    • [5] Ла Планте Брайан «Турбопривод для витрин данных» — Oracle Magazine/Russian Edition, #7/2000, http://www.olap.ru/basic/news/m001015886.asp.
    • [6] Черняк Л. «Снова о тестах TPC» — Открытые системы, #11/2000, http://www.osp.ru/os/2000/11/034.htm.
    • [7] Query Optimization in Oracle9 i, An Oracle White Paper, February 2002, http://otn.oracle.com/products/bi/pdf/o9i_optimization_twp.pd.
    • [8] Questions and Answers. SQL Optimization — http://www.ixora.com.au/q+a/sqlopt.htm.
    • [9] «TPC BENCHMARK™H (Decision Support)», Standard Specification, Revision 2.0.0 — Transaction Processing Performance Council (TPC), http://www.tpc.org/tpch/spec/tpch2.0.0.pdf.

    наверх

    Сайт подключен к Orphus. Если вы заметили опечатку, выделите слово и нажмите Ctrl+Enter. Спасибо!

    Сжатие данных в целях экономии места и ускорения работы oracle

    Вопрос экономного кодирования информации в системах управления базами данных был поставлен в первой половине 1970-х годов, но не потерял актуальности до сих пор. Многие современные исследователи отмечают недостаточную теоретическую проработку проблемы и неэффективность поддержки сжатия данных.

    Интерес к задаче сжатия данных в СУБД изначально был обусловлен стремлением уменьшить физический объем баз данных. Цена подсистемы ввода-вывода составляла основную часть стоимости аппаратуры. Поэтому при надлежащем интегрировании в СУБД методов безущербного сжатия данных достигалась значительная экономия. Небольшое увеличение числа используемых тактов процессора для кодирования-декодирования более чем компенсировалось снижением затрат на подсистему ввода-вывода. Данный результат применения сжатия востребован и в настоящее время. Действительно, падение относительной стоимости устройств хранения информации на несколько порядков сопровождалось соответствующим увеличением размера типичных баз данных. Тем не менее, в настоящее время фокус интереса все больше смещается на увеличение производительности системы управления данными за счет использования сжатия.

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

    Для применения в СУБД требуются специфические методы и приемы экономного кодирования, поскольку обычные методы не удовлетворяют ряду требований. Практическая ценность реализации достигается только при обеспечении быстрого доступа к произвольной записи или элементу данных. Востребованы так называемые методы сжатия с сохранением упорядоченности, позволяющие выполнять операции сравнения без декодирования данных.

    Проблема реализации сжатия в СУБД имеет также такие аспекты, как оптимизация выполнения запросов к сжатым данным, эффективное сжатие результатов выполнения запросов, экономное кодирование метаданных, оценка целесообразности сжатия отдельных элементов, выбор алгоритма сжатия и его параметров с учетом типовых запросов и характера данных.

    Описание предметной области

    Объект исследования

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

    В данной работе рассматривается одна из них, наука о водной оболочке земли — гидрология. Исключительная роль воды в жизни человека и всего живого на Земле обусловливает большое и постоянно возрастающее внимание к изучению гидросферы и режиму водных объектов. Основная работа по организации и осуществлению наблюдений, сбора и обработки информации о состоянии гидросферы выполняется национальными метеорологическими, гидрологическими, геологическими службами и водохозяйственными организациями стран земного шара.

    Начало создания национальных служб и международного сотрудничества в изучении гидросферы относится к середине XIX века, когда в 1853 году была разработана программа проведения метеорологических наблюдений в океанах с целью повышения безопасности жизни на море. В результате прогресса, достигнутого в различных научных областях, в XX веке были разработаны и быстро усовершенствовались методы наблюдений за компонентами гидросферы в атмосфере, океанах и водных объектах суши. Были приняты меры по обмену данными наблюдений между службами. Разработки в области использования спутников и компьютерной технологии привели к созданию в 1963 году под эгидой Всемирной метеорологической организации (ВМО) комплексной всемирной оперативной системы, названной Всемирной службой погоды, которая включает глобальную систему телесвязи и глобальную систему обработки данных. Создана также глобальная система сбора океанографических данных.

    В настоящее время на земном шаре действуют около 9 тыс. станций на суше, производящих наблюдения за влажностью воздуха, облачностью, количеством выпадающих атмосферных осадков (из них 350 автоматизированы или частично автоматизированы). Около 700 морских судов производят наблюдения за различными параметрами состояния вод Мирового океана (температура, соленость и минеральный состав вод, направление течений). Эти данные дополняются наблюдениями с коммерческих самолетов (около 10 тыс. сводок в сутки). Передают информацию и 300 заякоренных буев или фиксированных платформ, работающих как автоматические морские станции, и около 600 буев, дрейфующих с океанскими течениями. На сегодняшний момент существует огромное количество институтов и организаций, занимающихся гидрологическими исследованиями. Придумано и осуществлено десятки тысяч международных программ и проектов.

    В 2003 году Группа ученых из Японии, США и Европы подготовила программу глобального исследования океана. По всему миру распределили около 3 тысяч самопогружающихся датчиков. На протяжении ближайших 3-4 лет они будут собирать подробные данные о течениях, фиксировать колебания температуры, концентрацию соли и прочие параметры, которые, по мнению специалистов, помогут предсказывать изменения климата на планете. Эксперимент получил название «Арго-программа». Оборудованные специальной аппаратурой датчики цилиндрической формы погружаются на глубину 2-х километров и остаются там в течение десяти часов. После этого приборы длиной около метра и диаметром 20 сантиметров автоматически всплывают на поверхность, связываются с помощью антенн со спутниками и передают собранную информацию на наземные станции, а затем вновь уходят под воду.

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

    Проблема хранения информации

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

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

    Илон Маск рекомендует:  Что такое код domnode >dump_node

    Современной тенденцией развития программ исследования Земли из космоса является создание в ряде стран электронных библиотек космической информации. Эти национальные информационные системы используют потоки спутниковых данных для решения разнообразных задач дистанционного зондирования, определяемых как научным сообществом, так и конкретными отраслями производственной деятельности. Например, в США для информационной поддержки своей национальной системы наблюдения Земли из космоса (EOS) NASA создало EOSDIS — разветвленную инфраструктуру сбора, архивирования и распространения спутниковых данных потребителям. Система EOSDIS сосредоточила огромные массивы геопространственных данных, получаемых со спутников ДЗЗ. Это создает серьезные проблемы при организации хранения и доступа к спутниковым данным, поскольку стандартные пакеты программ баз данных не могут их эффективно перерабатывать. Например, каждый кадр прибора ТМ спутника Ландсат в шести спектральных каналах (разрешение 30 м) и одном тепловом (разрешение 120 м) покрывает площадь 170 х 185 квадратных километров. В результате объем такого кадра спутника Ландсат достигает 400 Мбайт. Ежедневные объемы необработанных спутниковых данных ДДЗ, поступающие в систему EOSDIS, оцениваются в 480-490 Гбайт. Объем обработанных данных ДЗЗ в системе EOSDIS достигает 1600 Гбайт в сутки.

    Роль и важность системы хранения определяются постоянно возрастающей ценностью информации в современном обществе, возможность доступа к данным и управления ими является необходимым условием для выполнения бизнес-процессов. Безвозвратная потеря данных подвергает бизнес серьезной опасности. Утраченные вычислительные ресурсы можно восстановить, а утраченные данные, при отсутствии грамотно спроектированной и внедренной системы резервирования, уже не подлежат восстановлению. По данным Gartner, среди компаний, пострадавших от катастроф и переживших крупную необратимую потерю корпоративных данных, 43% не смогли продолжить свою деятельность.

    Анализ существующих систем сжатия

    Использование сжатых таблиц

    В большинстве систем поддержки принятия решений (СППР) обычно используются большие объемы данных, которые хранятся в нескольких очень больших таблицах. При развитии подобных систем требования к дисковому пространству могут быстро расти. Сейчас хранилища данных объемом сотни терабайт встречаются все чаще.

    При решении проблем с дисковым пространством, появившаяся в Oracle 9i Release 2 возможность сжатия таблицы может существенно сократить объем дискового пространства, используемого таблицами базы данных и, в некоторых случаях, повысить производительность запросов. Возможность сжатия таблиц в Oracle9i Release 2 реализуется путем удаления дублирующихся значений данных из таблиц базы. Сжатие выполняется на уровне блоков базы данных. Когда таблица определена как сжатая, сервер резервирует место в каждом блоке базы данных для хранения одной копии данных, встречающихся в этом блоке в нескольких местах. Это зарезервированное место называют таблицей символов (symbol table). Помеченные для сжатия данные хранятся только в таблице символов, а не в строках данных. При появлении в строке данных, помеченных для сжатия, в строке, вместо самих данных, запоминается указатель на соответствующие данные в таблице символов. Экономия места достигается за счет удаления избыточных копий значений данных в таблице.

    Сжатие таблицы на пользователя или разработчика приложений никак не влияет. Разработчики обращаются к таблице одинаково, независимо от того, сжата она или нет, поэтому SQL-запросы не придется менять, когда вы решите сжать таблицу. Параметры сжатия таблицы обычно устанавливаются и изменяются администраторами или архитекторами базы данных, и участие в этом процессе разработчиков или пользователей минимально.

    Основной причиной использования сжатия таблицы является экономия дискового пространства. Таблица в сжатом виде обычно занимает меньше места. Сжатие таблицы в Oracle9i Release 2 позволяет существенно сэкономить дисковое пространство, особенно в базах данных, содержащих большие таблицы только для чтения. Если учитывать дополнительные требования к загрузке и вставке данных, а также правильно выбрать таблицы-кандидаты для сжатия, сжатие таблиц может оказаться потрясающим способом экономии дискового пространства и, в некоторых случаях, повышения производительности запросов.

    Но существуют свои недостатки:
    1) Поскольку сжатие таблицы выполняется при массовой загрузке, операции загрузки требуют дополнительной обработки — надо выполнять дополнительные действия. Дополнительное время при загрузке в сжатую таблицу требуется для выполнения действий по сжатию загружаемых данных. В реальной ситуации различие во времени загрузки будет зависеть от особенностей таблицы и загружаемых данных.
    2) В системах оперативной обработки транзакций (online transaction processing — OLTP) данные обычно вставляются обычными операторами INSERT. В результате, от использования сжатия для соответствующих таблиц большого преимущества не будет.
    3) Более того, изменение данных в сжатой таблице может потребовать распаковки строк, что сводит на нет все преимущества сжатия. В результате, часто изменяемые таблицы плохо подходят для сжатия.

    Упаковка битов

    Метод упаковки битов (bit packing) заключается в кодировании значения атрибута битовыми последовательностями фиксированной длины. Для каждого сжимаемого столбца требуется хранить соответствующую таблицу перекодировки. Разрядность кодовых последовательностей определяется количеством различных чисел, значения которых реально принимаются атрибутом, или же мощностью области определения атрибута. Очевидно, что требуемая длина кода N равна [ log 2 n ], где n — это мощность множества реальных или допустимых значений атрибута. Данный метод рассматривается в одной из самых ранних статей по сжатию баз данных. Метод упоминается наряду с другими приемами под названием «bit compression».


    Упаковка битов — это простой способ сжатия на уровне значения атрибутов, реализация которого необременительна. Также важно, что при соответствующей реализации сохраняется упорядоченность. Но проблемой при использовании данного метода является обработка появления новых значений атрибута. В этом случае может потребоваться перекодировать все значения столбца, если [ log 2 n ] становится больше исходного N .

    Суть метода: для каждого столбца находится минимальное и максимально значение. Значения, попавшие внутрь этого диапазона, последовательно кодируются. Длина кодового слова постоянна и определяется размером диапазона. Пример: пусть имеется последовательность строк из двух полей = <(100, 21), (98, 24), (103, 29)>. Для первого поля диапазон [98, 103], для второго — [21, 29]. Мощность первого множества значений равна 6, второго — 9. Поэтому будет представлена как: = <(0102, 00002), (0002, 00112), (1012, 10002)>.

    Очевидно, что если сжатие применяется к полям фиксированной длины, то их новая длина также фиксирована. Для каждого столбца необходимо хранить только границы диапазона и, возможно, длину. Перекодирование требуется лишь в случае выхода значения за границы диапазона. Степень сжатия сильнее всего зависит от распределения значений каждого атрибута для записей, хранящихся в одной странице. Можно кардинально улучшить сжатие за счет перераспределения записей по страницам при обработке на файловом уровне.

    Метод упаковки битов не может обеспечить значительной степени сжатия относительно других методов, что, тем не менее, во многих приложениях может компенсировать высокой скоростью обработки данных и сохранением упорядоченности.

    Арифметическое кодирование

    Совершенно иное решение предлагает т.н. арифметическое кодирование. Арифметическое кодирование является методом, позволяющим упаковывать символы входного алфавита без потерь при условии, что известно распределение частот этих символов и является наиболее оптимальным, т.к. достигается теоретическая граница степени сжатия. Предполагаемая требуемая последовательность символов, при сжатии методом арифметического кодирования рассматривается как некоторая двоичная дробь из интервала [0, 1). Результат сжатия представляется как последовательность двоичных цифр из записи этой дроби.

    Идея метода состоит в следующем: исходный текст рассматривается как запись этой дроби, где каждый входной символ является «цифрой» с весом, пропорциональным вероятности его появления. Этим объясняется интервал, соответствующий минимальной и максимальной вероятностям появления символа в потоке. Подробнее о методах кодирования можно прочитать на личной странице Семенова ЮА.

    Выбор направления разработки

    Генетическое программирование как метод сжатия данных

    Идею генетического программирования (ГП) — впервые предложил Коза в 1992 году, опираясь на концепцию генетических алгоритмов (ГА). Эта идея заключается в том, что в отличие от ГА в ГП все операции производятся не над строками, а над деревьями. При этом используются такие же операторы, как и в ГА: селекция, скрещивание и мутация.

    В ГП хромосомами являются программы. Программы представлены как деревья с функциональными (промежуточные) и терминальными (конечные) элементами. Терминальными элементами являются константы, действия и функции без аргументов, функциональными — функции, использующие аргументы. Для того чтобы применить ГП к какой-либо проблеме, необходимо определить:
    · Множество терминальных элементов
    · Множество функциональных элементов
    · Меру приспособленности (fitness)
    · Параметры, контролирующие эволюцию
    · Критерий останова эволюции
    Деревья поколений — кодируют сложную функцию, представляя её в виде дерева расчета (как при разборе выражений из теории трансляции). Используются при решении задачи автоматического определения функций. В генетическом программировании особи из популяции представляют собой программы. Удобно представлять эти программы в виде деревьев, где функции представлены внутренними узлами, к которым в качестве входных параметров присоединены поддеревья. Листьями такого дерева будут константы, входные параметры задачи или директивные команды программы. Пример простой программы-дерева:

    Рис. 1 — Формула (х+3)*7, представленная в виде дерева

    Первый главный шаг в подготовке использования генетического программирования должен идентифицировать множество терминалов. Набор терминалов, наряду с набором функций, представляет собой компоненты, из которых будет создаваться компьютерная программа для полного или частичного решения проблемы.

    Второй шаг заключается в определении функционального множества, элементы которого должны использоваться для генерации математических выражений. Каждая компьютерная программа (то есть, анализируемое дерево, математическое выражение) является композицией функций от множества функций F и терминалов из терминального множества T (в случае программ-функций это константы и переменные).

    Множество возможных внутренних узлов (не листовых), используемых в деревьях синтаксического анализа, используемых в генетическом программировании, называется функциональным множеством:
    F= Каждая функция из функционального множества характеризуется арностью — количеством входящих параметров. Множество листовых узлов в деревьях синтаксического анализа, представляющих программы в генетическом программировании, называются терминальным множеством:
    T= Функциональное и терминальное множества могут быть объединены в однородную группу С, при условии, что терминалы рассматриваются как функции с нулевой арностью:
    C=F U T

    Пространством поиска генетического программирования является множество всех возможных рекурсивных композиций функций множества C. В функциональном множестве могут быть применены арифметические, математические, булевы и другие функции. В терминальное множество могут войти переменные, константы или директивные команды. Множества F и T должны обладать свойствами замыкания и достаточности.

    ЗАМЫКАНИЕ требует, чтобы каждая функция из множества F была способна принять аргументом любые значения и типы данных, которые могут быть возвращены любой функцией из множества C. Это предупреждает ошибки во время выполнения программ, полученных генетическим программированием. Для обеспечения условия замкнутости можно использовать защиту операций — принудительное приведение поступающих данных к диапазону, определяемому конкретной операцией. Например, операцию извлечения корня можно защитить от появления отрицательного аргумента принудительным расчетом модуля от этого аргумента. Альтернативой защите может быть автоматическое исправление ошибок в программе или применение штрафов за ошибки.

    ДОСТАТОЧНОСТЬ требует, чтобы функции из множества C были способны выразить решение поставленной задачи, то есть, чтобы решение принадлежало множеству всех возможных рекурсивных композиций функций из C. Однако доказать, что выбранное множество C достаточно, возможно лишь в редких случаях. Поэтому, при выборе этого множества, как и при выборе основных операций генетического алгоритма, приходится полагаться лишь на интуицию и экспериментальный опыт.

    Обобщенная схема генетического алгоритма:
    1. Отбор особей для репродукции
    2. Образование пар из отобранных особей
    3. Рекомбинация — генерация новых особей из родительских пар
    4. Мутация новых особей
    5. Позиционирование новых особей в популяции

    Рис. 2 — Анимация. Генерация хромосом. Для воспроизведения нажмите кнопку на рисунке

    Шаги 1-5 выполняются циклически. Обычно после завершения каждого цикла проводят сортировку популяции по приспособленности особей, что облегчает выполнение многих операций. Также, до старта самого алгоритма генерируется начальная популяция — она обычно заполняется случайными решениями (особями). Hа шаге 5, кроме расположения особи в популяции выполняется оператор, определяющий приемлемость новой особи а такжи оператор оценивания новой особи (фитнес-функция).

    Обобщение результатов научного поиска и анализа

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

    Если имеется 1000 точек, фиксирующих какие-то параметры, то метод сжатия будет заключаться в подборе 5-6 или более функций, с помощью объединения которых можно будет потом получить весь набор точек. Кроме сжатия данных данная работа предполагает одновременный анализ данных, который может прослеживаться на больших временных отрезках и при этом не обязательно раскодирование. Так например при анализе температуры, видя, что функция температуры имеет приблизительный вид прямой можно сократить измерения на данном участке объекта или сделать их более дискретными.

    Научность работы заключается в составлении самого алгоритма поиска таких функций, определения интервала, в котором могут лежать предполагаемые коэффициенты функций, а также оценки производительности такого алгоритма в зависимости от разных по объъему наборов.

    Таким образом можно выделить следующие задачи и цели магистерской работы:

    ·Одним из методов поиска определить диапазон, в котором будут находиться возможные терминалы
    ·Задаться набором минифункций, на основании которых будет производиться поиск функции или набора функций, кодирующих заданную последовательность параметров
    ·Определить параметры алгоритма, такие как коэфиициент мутации, способ селекции
    ·Реализовать алгоритм сжатия
    ·Провести анализ алгоритма на разных наборах данных при различной точности
    ·Определить недостатки и достоинства данного метода

    Полная версия направления разработки магистерской работы находится в научной статье.

    Этот забавный Oracle

    Узнай первым о самом интересном в продуктах Oracle.

    22 мая 2013 г.

    Сжатие в Oracle Database

    Статья десятилетней давности, но при этом не потерявшая своей актуальности, рассказывает о Basic Compression в СУБД Oracle (требует Oracle Database Enterprise Edition 9.2. и старше). Изложенный материал, с некоторыми оговорками, справедлив и для OLTP Compression в СУБД Oracle (требует опцию Oracle Advanced Compression и Oracle Database Enterprise Edition 11.1 и старше).

    Сжатие в базе данных идёт на уровне блоков, а не всей таблицы. Каждый сжатый блок, содержит локальный словарь («symbol table»). Повторяющиеся данные сохраняются в словаре, а все их вхождения заменяются на короткую ссылку.

    Рассмотрим на примере из статьи как реализовано сжатие в Oracle Database:

    Совершенствование процесса поиска неэффективных SQL-запросов в СУБД Oracle Текст научной статьи по специальности « Автоматика. Вычислительная техника»

    Аннотация научной статьи по автоматике и вычислительной технике, автор научной работы — Алгазали С.М.М., Айвазов В.Г., Кузнецова А.В.

    Рассматриваются пути решения проблемы поиска неэффективных SQL-запросов в больших системах при отсутствии явных причин падения производительности. Для облегчения и ускорения поиска проблемных запросов предлагается осуществлять их предварительную кластеризацию . Каждый SQL-запрос описывается тремя группами статистических параметров, которые можно получить при помощи системных средств СУБД : параметрами выбранного плана исполнения запроса , параметрами плана реального исполнения, характеристиками среды исполнения. Сформулирована задача кластеризации с учётом интеллектуального формирования параметрической модели SQL-запроса и возможностью начального формирования подмножества кластеров, содержащих заранее известные неэффективные запросы-образцы. Предлагаемое решение может быть распространено на другие СУБД , с учётом их особенностей.

    Похожие темы научных работ по автоматике и вычислительной технике , автор научной работы — Алгазали С.М.М., Айвазов В.Г., Кузнецова А.В.,

    Process perfection for searching inefficient SQL-requests in the Oracle

    Introduction: The paper discusses methods to solve the problem of searching inactive queries for Oracle Databases in example. If there are no clear reasons for Deterioration of performance, database managers need to analyze very large amounts of statistical information prov >query to >query is described by three sets of parameters: specified query execution plan parameters, real implementation plan parameters, and the characteristics of the implementation environment. its cons >SQL query model, query execution conditions and data base settings (DBS). Moreover, its depends on fails in the nature of the system for client programs. Problem statements. The problem is formulated by the dynamic formation in the inactive SQL query model from some of sets parameters that already contained identifiers. Conclusion: The proposed of this approach will speed up the search for inactive queries and can be extended to others databases, with consider their characteristics.

    Текст научной работы на тему «Совершенствование процесса поиска неэффективных SQL-запросов в СУБД Oracle»

    Совершенствование процесса поиска неэффективных SQL-запросов в СУБД Oracle

    С.М.М. Алгазали, В.Г.Айвазов, А.В. Кузнецова

    Южно-Российский государственный политехнический университет (Новочеркасский политехнический институт) имени М.И. Платова

    Аннотация: Рассматриваются пути решения проблемы поиска неэффективных SQL-запросов в больших системах при отсутствии явных причин падения производительности. Для облегчения и ускорения поиска проблемных запросов предлагается осуществлять их предварительную кластеризацию. Каждый SQL-запрос описывается тремя группами статистических параметров, которые можно получить при помощи системных средств СУБД: параметрами выбранного плана исполнения запроса, параметрами плана реального исполнения, характеристиками среды исполнения. Сформулирована задача кластеризации с учётом интеллектуального формирования параметрической модели SQL-запроса и возможностью начального формирования подмножества кластеров, содержащих заранее известные неэффективные запросы-образцы. Предлагаемое решение может быть распространено на другие СУБД, с учётом их особенностей.

    Ключевые слова: SQL, запрос, СУБД, Oracle, неэффективный SQL-запрос, кластеризация, группировка.

    Введение. Обычно информация о том, что имеют место проблемы с производительностью программных систем промышленного или коммерческого уровня исходит от пользователей и эта информация представляет собой субъективную оценку, выраженную в свободной форме. В качестве пользователей системы могут выступать как конечные пользователи (англ., End-User — EU), так и разработчики БД и ПО (англ., Data Base Developer — DBD, Software Developer — SD). Большую часть претензий составляют жалобы на длительное исполнение запросов. Проблемы могут проявляться «зависанием» форм конечных приложений, увеличением длительности исполнения неинтерактивных задач, скриптов или программ, работающих с БД. Более явным и серьёзным сигналом могут служить ошибки времени исполнения, появлении которых может сообщаться через графический интерфейс конечных приложений, приложений разработки, консоль СУБД, индивидуальные лог-файлы задач, системные лог-файлы и

    т.д. Наличие таких ошибок возможно только при крайнем ухудшении производительности — они сигнализируют об аварийном завершении запроса при невозможности продолжения его исполнения. При этом завершается с ошибкой не всегда тот запрос, который является причиной ошибки, запрос с плохой производительностью или высоким потреблением ресурсов.

    Для устранения потенциально-неэффективных SQL-запросов и причин их появления специалистам DBD и SD требуется помощь со стороны от администраторов СУБД (англ., Data Base Administrator — DBA), которые имеют доступ к частной и агрегированной информации об исполнении запросов и состоянии среды. По результатам анализа DBA проводят мероприятия по оптимизации производительности, представляя пользователям отчёты о сделанных изменениях, либо дают рекомендации по действиям, которые необходимо произвести со стороны разработчиков. Падение производительности может иметь как случайный, так и системный характер. Причинами случайного характера падения производительности могут служить ситуации, при которых 1) SQL-запросы INSERT, UPDATE ожидают окончания обработки других запросов и освобождения от блокировки тех данных, которые необходимы для собственного исполнения; 2) время исполнения запросов SELECT резко увеличивается из-за мгновенной нагрузки на сервере; 3) имеет место иная занятость дисковой системы сервера. Признаком такой случайности является однократное повторение явления при сравнительно небольшом количестве обрабатываемых данных. Причиной же системных проблем падения производительности являются: неоптимальный код SQL-скриптов, неудачная модель БД и/или её конфигурации, состояние и характеристики среды исполнения, а также устаревание статистической информации о распределении данных [1, 2].

    В первом случае специалистам DBA необходимо определить, что является причиной длительных блокировок, а во втором — изучать планы исполнения запросов и статистические данные (далее просто статистику) результатов реального выполнения большого числа SQL-запросов. И чем крупнее программная система, тем больше кандидатов для изучения. За редким исключением неэффективность запросов прямо бросается в глаза. Такие очевидные показатели как высокая стоимость плана исполнения SQL-запроса, длительное время его исполнения, аварийное завершение с определёнными кодами ошибок далеко не всегда являются прямыми указателями на источник проблем. Определить эффективность плана запроса «на глаз», не имея представлений о задаче, структуре данных и настройках оптимизатора, практически невозможно. Не говоря уж о том, что просто не бывает запросов, одинаково эффективных во всех случаях, точнее даже не столько запросов, сколько их планов. В ряде случаев со второй задачей DBD и SD могут справиться самостоятельно, прибегая к помощи специализированных утилит и имея соответствующий уровень доступа.

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


    Цель. Проблема поиска потенциально-неэффективных запросов приобретает всё большую остроту, требуя изучения такого объёма информации, с которой человек справляется с трудом. Поэтому целесообразно предварительно локализовать те SQL-запросы, которые

    требуют пристального изучения, а потом уже проводить их первоочередной анализ или анализ наиболее типичных представителей выделенного множества. Целью работы является повышение эффективности поиска проблемных SQL-запросов за счёт их предварительной группировки. При этом вектор признаков, описывающий SQL-запрос, формируется из параметров трех типов: оценок плана исполнения запроса, статистических параметров реального исполнения запроса, параметров среды и условий, в которых выполнялся запрос. Формирование вектора признаков должно основываться на интеллектуальных процедурах анализа состояния среды и условий, в которых исполняются запросы, чтобы обеспечить формирование оптимального набора параметров.

    В качестве базовой выбрана СУБД Oracle как лидер среди серверов баз данных на платформах UNIX и Windows.

    Материалы и объекты исследования. Под неэффективным SQL-запросом будем понимать запрос, приводящий к ощутимому замедлению работы клиентских приложений или сервера базы данных и потребляющий при этом значительные ресурсы дискового пространства, машинного времени, и оперативной памяти.

    Работа запроса в любой СУБД состоит из следующих этапов: синтаксического разбора SQL-выражения, его семантической проверки, выработки плана запроса; исполнения запроса по выработанному плану. Соответственно и инструментальные средства, позволяющие получить статистические данные о запросах, можно разделить на две группы: утилиты, позволяющие получить предполагаемый план выполнения запроса; средства, позволяющие получить информацию о реальном исполнении запроса. План SQL-запроса — это упорядоченный набор шагов, согласно которому СУБД будет осуществлять выборку данных. План представляет собой древовидную структуру, содержащую порядок шагов и связь между ними.

    Зачастую возможно большое количество различных путей обработки данных, ведущих к одному и тому же результирующему набору данных, поэтому на основе лексического и синтаксического анализа текста запроса специальный компонент СУБД — оптимизатор — вырабатывает множество планов. В новых версиях СУБД Oracle по умолчанию используется современный оптимизатор «Cost based optimiser» (англ., CBO), в противовес устаревшему «Rule based optimiser» (англ., RBO). В результате преобразований и последующей оценки CBO выбирает наиболее подходящий план.

    Основными показателями, отражающими эффективность плана исполнения запроса, являются стоимость выполнения (Cost) и мощность (Cardinality), которые представляют собой приблизительные оценки объёма работ по извлечению данных и количества возвращаемых строк соответственно [3]. Эти оценки вычисляются для каждой операции, входящей в план исполнения, и впоследствии суммируются для получения оценки производительности всего плана исполнения. Грубо говоря, эффективность запроса обратно пропорциональна суммарной величине этих параметров. Стоит отметить, что эти оценки далеко не всегда соответствуют реальным характеристикам производительности, получаемым при исполнении запроса. Мощность вычисляется с использованием информации о статистическом распределении данных в таблицах-источниках для SQL-выражений. Рассчитанная величина может быть не точной в связи с тем, что при изменении данных в БД информацию об их распределении невозможно поддерживать в полностью актуальном состоянии. Особенно это касается больших таблиц, в которых для сбора статистической информации используется только определённая доля данных. И эта доля может быть недостаточно репрезентативной. В большинстве случаев достаточно, чтобы мощность не отличалась от реального значения больше, чем на один и даже два порядка. Стоимость запроса складывается из стоимости отдельных

    операций. К точности её расчёта предъявляются похожие требования. Поскольку оценка планов исполнения нужна оптимизатору для выбора наиболее эффективного способа исполнения одного и того же запроса, то его абсолютное значение не может напрямую использоваться для оценки реальной эффективности [4, 5].

    Помимо вышеуказанных показателей для оценки SQL-запроса используются и другие параметры плана исполнения. Это: стоимость ресурсов центрального процессора (CPU Cost), стоимость ввода-вывода (IO Cost), показатель использования дискового пространства (Temp Space). Параметр CPU Cost позволяет оценивать количество машинных циклов, необходимых для выполнения всех операций запроса и напрямую зависит от текущей загрузки сервера. Эта величина не является значимой для оценки эффективности запроса если экземпляр запущенной СУБД — инстанс (англ., instance) — не использует чрезмерные ресурсы центрального процессора. Специалисты Oracle рекомендуют учитывать оценку CPU Cost для тех планов исполнения, для которых в качестве цели оптимизации было задано наискорейшее получение всех строк результата запроса (хинт ALL_ROWS в SQL-выражении или параметр сессии ALL_ROWS). В случае, когда целью оптимизации является наискорейшее получение первых строк результата (хинт или режим оптимизатора FIRST_ROWS), CPU Cost теряет актуальность. В настоящее время СВО не располагает реальной информацией о нагрузке ЦПУ, поэтому величина CPU Cost имеет является приблизительной оценкой плана. Величина параметра IO Cost пропорциональна количеству дисковых (физических) чтений блоков данных, требующихся для выполнения всех операций плана. Однако СВО пока ещё не имеет предварительной информации о доле блоков таблиц, находящихся в буферном кэше, а значит не может достоверно различать затраты логическое и физическое чтение. Значение Temp Space свидетельствует о необходимости

    использования дисковой памяти для проведения сортировок, группировок, сортировок объединений данных, что косвенно указывает на неэффективность SQL-запроса.

    По мнению ряда специалистов-практиков эти и другие параметры плана исполнения являются отправными точками для поиска неэффективных запросов и в совокупности позволяют оценить длительность запроса, его ресурсоёмкость и, в конечном счёте, успешность исполнения. Получить предполагаемый план выполнения специалисты DDB, DS и DBA могут с помощью специальной команды explain plan for, предварительно создав специальную системную таблицу PLAN_TABLE. Для получения наиболее читабельного представления существуют утилиты Toad, SQL Navigator, PL/SQL Developer и др.

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

    SQL-запроса. На достоверность отображения SQL-запроса выбранным для него планом исполнения накладывает отпечаток и несовершенство алгоритмов оптимизатора. СВО — программа, написанная исходя из общих предположений, а БД имеет конкретное наполнение, и поэтому вовсе не факт, что значения параметров плана точно соответствуют реальным характеристикам запроса, который исполняется в динамически изменяющейся среде.

    Более точным вектором оценки SQL-запроса по сравнению с рядом параметров плана исполнения является статистика производительности, которую СУБД собирает во время исполнения запроса. Уровень детализации и подробности этой статистики зависят от настроек системы и от использования режима отладки (трассировка) для исполняющихся запросов. Некоторые значения статистики доступны только при включённой трассировке, но и без неё по умолчанию для каждого запроса собирается базовая информация о ходе его исполнения. Включение трассировки не всегда возможно, хоть и позволяет более подробно изучить проблему производительности запроса. В тех случаях, когда нельзя изолировать определённый запрос, т. е. получить его текст и исполнить его вне приложения в специальной среде разработки или консоли, трассировку можно включить только для приложения в целом. Такой подход вносит дополнительные накладки с точки зрения производительности приложения и последующего анализа полученных объёмов информации. В связи с этим для получения наиболее достоверных параметров SQL-запроса авторами предлагается сделать упор на базовую статистику. Её можно получить как с помощью системных запросов, так и с помощью вспомогательных утилит. И те и другие средства, как правило, находятся в распоряжении DBA.

    Управляющие структуры, справочную информацию, буферы, кеш, области динамического выделения памяти для хранения временных структур

    различного типа, и другие данные СУБД хранит в разделяемой памяти (англ., System Global Area, SGA), доступной как для системных, так и серверных процессов каждого инстанса [6]. Для удобства разработки, администрирования, анализа производительности и отладки СУБД Oracle предоставляет доступ к информации в SGA при помощи специальных реляционных объектов базы данных, хотя сами структуры памяти имеют не реляционную природу — это могут быть хеш-таблицы, индексы, списки, кучи и т.д. Эти объекты, называемые фиксированными базовыми таблицами (англ., fixed base tables, FBT), доступны на чтение для пользователей с определёнными привилегиями. Но любое изменение их содержимого или структуры невозможно. Кроме того, правила консистентности и целостности данных FBT не гарантируются и никакие транзакционные блокировки к ним не применимы. В связи с временной природой структур, находящихся в оперативной памяти, информация доступная через эти фиксированные таблицы, на диск вместе с другими данными БД не сохраняется. Она может существовать только с момента старта инстанса и до момента его остановки. Несмотря на наличие абстракции, позволяющей работать со структурами оперативной памяти инстанса при помощи SQL, эти таблицы не удобны в использовании. Для облегчения работы с FBT в СУБД Oracle существуют так называемые представления, определённые на этих таблицах и называемые динамическими представлениями производительности (англ., dynamic performance views, DPV). Через эти представления DBA может получить доступ к актуальной и хорошо детализированной информации для исследования большинства проблем производительности и возможности её улучшения [6].

    Илон Маск рекомендует:  Что такое код hfree

    Основными динамическими представлениями производительности СУБД Oracle, которые могут представлять интерес для создания параметрической модели SQL-запроса, являются:

    — VSSESSION — содержит информацию обо всех сессиях работы с СУБД Oracle, открытых на данный момент;

    — V$ACTIVE_SESSION_HISTORY — содержит историческую информацию об активных, не находящихся в состоянии простоя сессиях, периодически (по умолчанию с интервалом в 1 секунду) собираемую с момента старта инстанса. По структуре схожа с V$SESSION, с добавлением дополнительных полей, например, sampletime, указывающего на время производства «снимка» информации, отображаемой в V$SESSION;

    — V$SQL — содержит информацию об обрабатываемых на данный момент SQL выражениях и всех объектах, связанных с ними: родительских и дочерних курсорах, планах исполнения, рабочих областей памяти для каждой операции определённых планов исполнения, статистики исполнения и т.д. В ряде случаев через это представление можно получить и информацию об SQL-выражениях, обрабатывавшихся в недавнем прошлом;

    — V$SQLSTATS_PLAN_HASH — содержит базовую статистику для каждого плана исполнения каждого SQL-выражения. Производная от V$SQL;

    — V$SQLAREA_PLAN_HASH — содержит информацию о разделяемых областях памяти для SQL-выражений. Производная от V$SQL;

    — V$SQLTEXT — содержит полные тексты SQL-выражений;

    — V$SQL_PLAN — содержит информацию обо всех планах исполнения, сгенерированных для исполнения SQL-выражений.

    Не смотря на свою подробность и актуальность, все эти представления ограничены в размерах и вся информация, которая становится не нужной для работы СУБД (устаревает), очень быстро освобождается для последующего использования. В целях длительного сохранения диагностической информации и статистики производительности, для преодоления временных ограничений в СУБД Oracle существует специальное хранилище данных (англ., Advanced Workload Repository, AWR) [6]. В это хранилище

    определённой периодичностью, по умолчанию равной одному часу, записывается предварительно отобранная и обработанная информация из динамических представлений производительности и фиксированных базовых таблиц. Доступ к AWR, в частности, можно получить из утилит Toad, SQL Developer, SQL*Plus и других средств работы с СУБД, но только при наличии необходимых привилегий.

    С определённой периодичностью, по умолчанию равной одному часу, СУБД Oracle запускает специальную задачу, которая делает «снимок» (англ. snapshot) — собирает всю появившуюся и изменившуюся за период информацию из DPV и FBT; вычисляет разницу в кумулятивных счётчиках статистики; отбирает по определённым критериям (которые не раскрываются в официальной документации Oracle, хотя и понятны интуитивно) данные о сессиях, SQL-выражениях и других объектах времени исполнения записывает результаты в таблицы базы данных, входящие в состав AWR. Все данные, относящиеся к одному AWR-снимку, помечаются одним идентификационным номером, который затем можно получить из поля snap id любой таблицы, относящейся к AWR. Помимо этого в таблицах AWR хранятся данные со всех вычислительных узлов кластера, обслуживающего отдельную базу данных. Для различия между ними используется порядковый номер узла в поле instance_number, а при настройке AWR для хранения данных с нескольких различных баз данных (окружений) и для различия между данными первичной и клонированной системы используется поле dbid — уникальный идентификационный номер БД. По умолчанию информация в AWR хранится в течение одной недели.

    В AWR, кроме всего прочего, входит ряд таблиц, содержащих данные, аналогичные тем, которые формируются в упомянутых динамических представлениях производительности. Эти таблицы и предлагается использоваться в качестве источника информации для формирования

    параметров исследуемых объектов. Таблица БВА_Н18Т_80Ь_РЬАК содержит информацию о структуре планов исполнения запросов и об оценках производительности, выданных оптимизатором для каждого шага плана исполнения, в том числе, и для исторических планов исполнения, которых на данный момент нет в памяти СУБД. Таблица БВА_Н18Т_8КАР8НОТ содержит информацию о самих А»^^снимках. По этой информации можно определить время начала и окончания интервала для снимка, время старта инстанса и узнать дополнительную информацию об А»^^снимке. Таблица БВА_Н18Т_80ЬТБХТ содержит полные тексты 80Ь-выражений. Основной интерес в вышеперечисленных таблицах представляют столбцы, содержащие непосредственные данные об исполнении запросов. Наибольшее количество такой информации располагается в таблице БВА_Н18Т_80Ь8ТАТ. Не смотря на то, что некоторые данные можно найти в БВА_Н18Т_АСТ1УБ_8Б88_Н18ТОКУ, эта таблица преимущественно содержит данные не об отдельных запросах, а о сессиях базы данных и получение данных об SQL-запросах сопряжено с определёнными сложностями. Последняя таблица остается полезной для получения дополнительной, справочной информации о сессиях: с какого удалённого узла была инициализирована эта сессия; от имени какого пользователя, какая программа на удалённом сетевом узле инициализировала эту сессию; временные метки, по которым можно определить время активности; временной интервал, в котором существовала эта сессия. Вся эта информация оказывает существенную помощь в исследовании проблем производительности и может служить источником дополнительных параметров для SQL-запросов.

    В таблице DBA_HIST_SQLSTAT статистические данные хранятся в двух представлениях: в суммарном для отдельного запроса и в виде изменения за интервал. В имени столбцов с данными первого типа и второго

    типов присутствую соответственно суффиксы TOTAL и DELTA. Анализ статистических данных с суффиксом TOTAL в имени показал, что эти данные не пригодны для решения задачи предварительной группировки SQL-запросов по причине того, что эта статистика всё же иногда сбрасывается. Скорее всего, это происходит из-за устаревания курсора для запроса, но и однозначно — при перезапуске инстанса. В связи с этим для анализа предлагается использовать данные из аналогичных DELTA-столбцов. Они будут группироваться для каждого уникального сочетания sql_id и plan_hash_value, однозначно идентифицирующего SQL-запрос в Oracle, и некоторым образом агрегироваться. Число базовых статистических параметров, представляющих интерес для исследования производительности, составляет около четырёх десятков. Оперируя только этим набором, можно составлять различные комбинации, а значит и различные модели SQL-запроса, позволяющие делать акцент на разных аспектах его работы. Кроме того, в зависимости от конфигурации СУБД и особенностей исполняющихся SQL-выражений Oracle включает так называемое слежение (англ. monitoring) и собирает в указанных таблицах дополнительные статистики. Например, это касается запросов, исполняющихся более 5 секунд, распараллеленных запросов, запросов, явно выбранных пользователем.

    Удаляя из рассмотрения номер инстанса из поля instance_number, можно оценивать производительность запросов на всей системе в целом, без учёта количества отдельных вычислительных узлов, входящих в один кластер. Учёт этого значения, напротив, позволит анализировать производительность одного или нескольких экземпляров запущенной СУБД.

    Объём выборки для анализа может содержать десятки, а то и сотни тысяч единиц информации в зависимости от сложности задачи, стоящей перед DBA. Кроме того, для использования этой информации необходимо знание схемы данных AWR, назначений полей в её таблицах, особенностей

    извлечения необходимой информации. Получение и обработка такого количества данных без применения статистических и/или интеллектуальных методов трудна и малоэффективна [7]. Для повышения качества технологии анализа производительности БД авторами предлагается проведение предварительного анализа и группировки (кластер-анализ) SQL-запросов на основе трёх групп параметров: параметров плана исполнения SQL-запросов, статистических данных о результатах исполнения запросов и характеристик среды, в рамках которой выполнялись запросы. При этом в процессе кластеризации будут использоваться не все, а только часть параметров каждой группы.

    Формальная постановка задачи исследования. Пусть имеется множество SQL-запросов Я = <г1, г2, . гж>, множество номеров (меток) кластеров О = g2, . gNв>. Каждый запрос г характеризуется набором

    трёх множеств предварительно пронормированных и (при необходимости) взвешенных количественных параметров: параметров плана исполнения Р =

    <р^, рI. р^ >, параметров производительности Р = <рС, рС. рсж>, параметров среды РЕ = <рЕ, рЕ. рЕЕ >: Я = Р8 ? РС ? РЕ. При этом параметры

    производительности Р и параметры плана исполнения Р имеют характер неопределённости, связанный, соответственно, со случайным состоянием среды исполнения запроса и настройками оптимизатора. Задана симметричная функция, характеризующая степень близости между объектами р(гь

    Требуется построить отображение Б = Я ^ О такое, чтобы на каждый

    входной элемент г е Я, определяемый подмножествами параметров Р’ ,

    Р’ и Р’ из множеств Р , Р и Р , формировался единственный элемент gj е О.

    Состав подмножеств Р’ , Р’ определяется составом подмножества Р , а он, в

    свою очередь, зависит от характера проблем в работе программной системы, настроек оптимизатора, сетевых нагрузок и активности пользователей.

    Конечным результатом работы искомого отображения F на всём множестве R является формирование непересекающихся подмножеств, называемых кластерами так, чтобы каждый кластер состоял из SQL-запросов, степень близости между которыми больше некоего порогового значения р. Соответственно, для запросов из разных кластеров степень близости должна быть существенно ниже р, а полученное разбиение должно удовлетворять заданному функционалу качества. Отображение F должно допускать эффективную компьютерную реализацию, т.е. представлять собой алгоритм.

    Задача построения отображения F включает в себя анализ и выбор метода кластеризации исходя из особенностей предметной области, определение оптимальных доверительных интервалов его параметров, выбор функции для определения меры близости объектов и кластеров (расстояния), выбор одного или нескольких функционалов качества кластеризации [8]. Дополнением к данной постановке задачи кластеризации является необходимость уточнения общего числа кластеров NG, которое требует привлечения дополнительных процедур либо, решения поставленной задачи для нескольких значений NG с последующим выбором наиболее адекватного результата кластеризации [8, 9].

    При реализации отображения F предлагается предусмотреть возможность принудительного формирования некоторого подмножества кластеров, содержащих заранее известные запросы-образцы, относящиеся к разряду неэффективных. Это позволит улучшить качество кластеризации и гарантированно отыскать запросы со сходными признаками среди десятков тысяч запросов сессии. Задачи кластеризации, в которых незначительная часть объектов распределена по классам, называются задачами с частичным обучением (англ., semisupervised learning). Из-за малого числа

    идентифицированных объектов такие задачи не переходят в разряд классификационных, но и для их решения необходима модификация известных методов кластеризации.

    Заключение. Кластеризация близких по совокупности параметров SQL-запросов позволит ускорить поиск неэффективных экземпляров, за счёт анализа наиболее «типичных представителей» каждой группы и, в первую очередь, анализа запросов, попавших в кластеры с заранее известными проблемными запросами. Предлагаемый подход предусматривает отказ от использования хэш-значений запросов и планов исполнения запросов при формировании кластеров, и основывается на решении задачи с точки зрения совокупного влияния параметров SQL-запроса на общую производительность. Положения, описанные в работе, могут быть распространены и на другие промышленные СУБД со своими алгоритмами создания планов, своими наборами статистик и способами их получения.

    1. Михеичев В. Причины неэффективности SQLзапросов в Oracle. Оптимизация производительности SQLзапросов // Системный администратор. 2015. №6. С. 47-51.

    2. Михеичев В. Опыт и рекомендации по оптимизации SQLзапросов // Интернетжурнал «FORS», 2013, URL: fors.ru/upload/magazine/07/index.html

    3. Using EXPLAIN PLAN // Oracle Help Center URL: docs.oracle.com/cd/B19306_01/server.102/b14211/ex_plan.htm#g42231

    4. Lewis J. Cost-based Oracle fundamentals. Berkeley, CA: Apress, 2006. -506 p.

    5. Fritchey G. SQL Server Execution Plans. Publishing house: Red Gate Books, 2012. — 205 p.


    6. Automatic Performance Statistics // Oracle Help Center URL: docs.oracle.com/cd/B19306_01/server.102/b14211/ex_plan.htm#g42231

    7. Миллсап К., Хольт Д. Oracle. Оптимизация производительности. Пер. с англ. СПб: Символ_Плюс, 2006. — 464 с.

    8. Jadidinejad Amir H., Sadr Hossein Improving Weak Queries using Local Cluster Analysis as a Preliminary Framework Indian Journal of Science and Technology, Vol 8(15), July 2015 — URL: i-scholar.in/index.php/indjst/article/view/75325

    9. Крашенинников А.М., Гданский Н.И., Рысин М.Л. Построение сложных классификаторов для объектов в многомерных пространствах // Инженерный вестник Дона, 2012, №3 URL: ivdon.ru/magazine/archive/n2y2013/1611

    10. Гданский Н.И., Рысин М.Л., Крашенинников А.М. Линейная классификация объектов с использованием нормальных гиперплоскостей. Инженерный вестник Дона, 2012, №4. URL: ivdon.ru/magazine/archive/n4ply2012/1324

    1. Mihei4ev V. Cistemnyj administrator. 2015. №6. pp. 47-51.

    2. Mihei4ev V. Internetzurnal «FORS», 2013. URL: fors.ru/upload/magazine/07/index.html

    3. Using EXPLAIN PLAN. Oracle Help Center URL: docs.oracle.com/cd/B19306_01/server.102/b14211/ex_plan.htm#g42231

    4. Lewis J. Cost-based oracle fundamentals. Berkeley, CA: Apress, 2006. 506 p.

    5. Fritchey G. SQL Server Execution Plans. Publishing house: Red Gate Books, 2012. 205 p.

    6. Automatic Performance Statistics. Oracle Help Center URL: docs.oracle.com/cd/B19306_01/server.102/b14211/ex_plan.htm#g42231

    7. Millsap K., Hol’t D. Oracle. Optimizacija proizvoditel’nosti [Optimizing Performance]. SPb: Simvol_Pljus, 2006. 464 p.

    Таблицы Oracle

    Таблицы — основные единицы хранилища в базе данных Oracle. Таблица (table) — это логическая сущность, которая делает чтение и манипуляции данных интуитивно понятными для пользователя. Таблица состоит из столбцов и строк, причем строка соответствует одиночной записи, которая состоит из набора полей. Когда вы создаете таблицу, то присваиваете ей имя и определяете набор столбцов, относящихся к ней. Каждый столбец имеет имя и определенный тип данных (вроде VARCHAR2 или DATE). Для определенных столбцов можно специфицировать ширину или точность и масштаб (scale), а некоторым из них могут быть установлены значения по умолчанию.

    Оглавление

    Типы таблиц Oracle

    В базах данных Oracle можно создавать таблицы (table) двух типов: реляционные и объектные.

    Реляционные таблицы — это базовые табличные структуры, которые состоят из строк и столбцов, хранящих данные.

    Объектные таблицы используют объектные типы для определений столбцов и служат для хранения экземпляров объектов определенного типа. В этой статье будут использоваться исключительно реляционные таблицы.

    Что такое таблица DUAL?

    Таблица DUAL относится к схеме sys и создается автоматически при создании словаря данных.Таблица DUAL имеет единственный столбец по имени dummy и одну строку. Эта таблица позволяет применять команду Oracle SELECT для вычисления константных выражений. Как уже было показано, все, что есть в Oracle, должно находиться в какой-то таблице. Даже если что-то не находится в таблице, например, вычисляемое арифметическое выражение, запрос, который извлекает это значение, нуждается в какой-то таблице, и таблица DUAL служит таблицей “остальные” (catchall) для таких выражений. Например, для вычисления произведения 9 на 24567, можно воспользоваться следующей командой SQL: SELECT 9*24567 FROM dual.

    Виды таблиц по способу хранения

    Есть четыре основных способа организации таблиц (table) в базе данных Oracle.

    • Таблицы, организованные в куче (heap-organized), или традиционные таблицы. Эти таблицы — не что иное, как обычные таблицы Oracle, в которых данные хранятся без какого-то определенного порядка.
    • Индекс-таблицы. Индекс-таблицы хранят данные в отсортированной индексной структуре — бинарном дереве (B-tree).
    • Кластеризованные таблицы. Кластеризованная таблица является частью группы таблиц, которые разделяют между собой одни и те же блоки данных, поскольку данные из кластеризованных таблиц часто запрашиваются совместно.
    • Секционированные таблицы. Секционированная таблица позволяет делить большие объемы данных на подтаблицы, именуемые разделами (partition), согласно различным критериям. Секционирование особенно полезно в среде хранилища данных.

    В этой статье мы обсудим традиционные (организованные в куче) таблицы Oracle. Прочие типы таблиц будут рассматриваться нами в отдельной статье блога “Специальные таблицы Oracle”.

    Оценка размера таблицы

    Прежде чем создавать новую таблицу, имеет смысл оценить примерный ее размер на начальный момент и размер, которого можно ожидать в будущем. Знание размера таблицы позволяет принимать правильные решения относительно выделения пространства на диске.

    Существуют алгоритмы для вычисления потенциального размера таблиц и индексов — они берут размер строки в байтах и умножают на ожидаемое количество строк в этой таблице. Оценка размера таблиц — скорее искусство, чем точная наука, и вам не стоит очень уж напрягаться, чтобы получить “точное” значение размера. Просто примените здравый смысл, чтобы не слишком отдалиться от реальности.

    Можно упростить оценку размера таблицы, воспользовавшись OEM Database Control или же процедурой CREATE_TABLE_COST из пакета DBMS_SPACE. Оба подхода к установке размера новой таблицы описаны в последующих разделах.

    Использование OEM Database Control для оценки размера таблиц

    Давайте рассмотрим шаги, которые следует предпринять для определения размера новой таблицы с использованием интерфейса Database Control.

    • На домашней странице Database Control щелкните на вкладке Administration (Администрирование).
    • Щелкните на Tables (Таблицы) в списке Schema (Схема).
    • Щелкните на кнопке Create (Создать) в нижнем правом углу.
    • Выберите в качестве типа Standard (Стандартная) или Index Organized (Индекс-таблица).
    • На странице Create Table (Создать таблицу) введите имя новой таблицы и укажите типы данных столбцов в разделе столбцов. Щелкните на кнопке Estimate Table Size (Оценить размер таблицы).

    На странице Estimate Table Size (Оценить размер таблицы) введите ожидаемое количество столбцов вашей таблицы (рис. 1).

    Когда вы проделаете все эти шаги, OEM немедленно сообщит, сколько места следует отвести новой таблице. Он также сообщит о том, сколько места следует выделить табличному пространству, в котором вы собираетесь создавать новую таблицу.

    На заметку! Следующая дискуссия об операциях с таблицей касается “нормальных” или “традиционных” таблиц Oracle, чьи строки не хранятся в таблице в каком-то определенном порядке. Большинство операций с таблицами, о которых пойдет речь, касаются всех типов таблиц Oracle, но с некоторыми модификациями синтаксиса или ограничениями.

    Формат и размер строк Oracle

    База данных Oracle хранит каждую строку таблицы в виде одного или более кусков. Если длина строки больше такого куска, то база данных может хранить строку несколькими кусками. Конечно,если строка таблицы маленькая, блок данных может содержать несколько строк таблицы. Для связывания кусков строк вместе используются идентификаторы ROWID. Каждый кусок строки содержит заголовок строки и данные для всей строки или части ее столбцов.

    Использование пакета DBMS_SPACE для оценки потребностей в пространстве

    Пакет DBMS_SPACE позволяет анализировать рост сегментов и потребность в пространстве. С помощью процедуры из этого пакета можно оценить необходимое место для индексов таблицы. Если известна приблизительная длина строк новой таблицы и ожидаемое их количество, то пакет DBMS_SPACE сообщит предполагаемое место, которое понадобится таблице, с учетом атрибутов хранения табличного пространства, в котором вы собираетесь создавать ее. Чтобы получить ожидаемый размер таблицы, можно использовать как информацию о столбцах таблицы, так и размер строки. В листинге ниже показан простой пример.

    Обратите внимание, что пакет DBMS_SPACE также содержит процедуру SPACE_USAGE,которая поможет вернуть незанятое пространство (в действительности — неиспользованные экстенты), выделенные таблицам, индексам и прочим объектам. Вот как выглядит синтаксис вызова этой процедуры для возврата пространства, выделенного таблице:

    Создание таблицы Oracle

    Для создания таблицы в вашей собственной схеме необходимо иметь системную привилегию CREATE TABLE, а для создания таблицы в схеме другого пользователя понадобится системная привилегия CREATE ANY TABLE. При создании таблицы всегда специфицируйте табличное пространство. Если этого не сделать, таблица будет создана в пользовательском табличном пространстве по умолчанию. Кроме того, необходимо иметь достаточную квоту свободного места в табличном пространстве, где собираетесь создавать свои таблицы, или же обладать системной привилегией UNLIMITED TABLESPACE. В листинге ниже показан синтаксис создания простой таблицы.

    Совет. Если ваша база данных содержит крупные таблицы только для чтения, рассмотрите возможность использования средства сжатия таблиц Oracle, чтобы сэкономить место в хранилище.

    В операторе CREATE TABLE из листинга выше присутствует несколько ограничений целостности, включая первичный ключ и внешний ключ, определенные на разных столбцах таблицы. Ограничения будут описаны далее в моем блоге, в статье “Управление ограничениями целостности базы данных”.

    На заметку! С использованием конструкции ENCRYPT осуществляется прозрачное шифрование данных столбца. Шифровать можно столбцы типа CHAR, VARCHAR2, NUMBER, DATE и RAW. Пользователь, который шифрует столбец, увидит данные в расшифрованном формате. Шифрование включает установку ключа шифрования и некоторые другие детали (за дополнительной информацией о шифровании обращайтесь к руководству по Oracle, озаглавленном “Oracle Advanced Security Administrator’s Guide”, которое доступно по адресу http://tahiti.oracle.com). Вот как можно было бы зашифровать столбец ssn в предыдущем операторе создания таблицы:

    Как только новая таблица создана, ее можно наполнять данными несколькими способами: применять команду INSERT для вставки данных или же загрузить данные с использованием SQL*Loader. Возможно также создать новую таблицу и поместить в нее данные из существующей таблицы из той же либо другой базы данных. Это делается с применением хорошо известной техники CREATE TABLE AS SELECT (CTAS), которую объясняется ниже, в разделе “Создание новой таблицы с помощью CTAS”. Кроме того, можно применять SQL-оператор MERGE для вставки данных их другой таблицы на основе определенных условий. Использование команды MERGE объясняется в приложении.

    На заметку! Если вы создаете объекты базы данных в локально управляемом табличном пространстве, то указывать параметры хранения для каких-либо объектов не нужно.

    Что такое значение null?

    Значение null означает просто пустой столбец в строке. Значение null для столбца определенной строки не означает нулевого значения этого столбца. Вместо этого null указывает на то, что столбец в данной строке не имеет значения. Если данных для столбца нет либо они неизвестны, чтобы указать на это, применяется null. Вставлять в любой столбец таблицы значение null нельзя. Столбец допускает значения null только в том случае, если для него не специфицировано ограничение NOT NULL. Вдобавок, когда вы назначаете столбец первичным ключом этой таблицы, этот столбец также не допускает значений null. Попробуйте вставить все null-значения до конца таблицы, чтобы зарезервировать дисковое пространство. Это связано с тем, как Oracle хранит null-значения. Любые сравнения между null и другими значениям не могут быть истинными или ложными, поскольку null означает неизвестное значение.

    Значения полей (столбцов) по умолчанию

    Можно назначить полям таблицы Oracle значения по умолчанию. При вставке новой строки можно опускать значение для любого столбца, для которого определено значение по умолчанию. Для такого столбца база данных применит указанное значение по умолчанию.Если значение по умолчанию для столбца явно не задано, им будет null. Например, если для таблицы employees в качестве значения по умолчанию для столбца DEPT_NO вы установите 20, то Oracle поместит значение 20 в столбец DEPT_NO, даже если при вставке новых данных этот столбец не будет указан.


    Виртуальные поля (столбцы)

    В выпуске Oracle Database 11g в таблице можно использовать виртуальные поля (столбцы). Виртуальный столбец — это столбец, который определяется вычислением выражения, основанного на одном или более действительных столбцов таблицы, либо функции SQL или PL/SQL. В отличие от обычных столбцов, данные виртуального столбца не хранятся постоянно на диске. База данных вычисляет значения виртуального столбца, когда вы запрашиваете его, оценивая выражения или вызывая соответствующую функцию.

    Виртуальные столбцы можно использовать как в DDL-, так и в DML-операторах.Допускается определять индексы на этих столбцах и собирать статистику по ним.

    Создание виртуального поля таблицы

    При спецификации виртуального поля можно использовать конструкцию GENERATED ALWAYS как часть оператора CREATE TABLE, например:

    Последняя строка предыдущего примера показывает спецификацию виртуального столбца. При желании можно также специфицировать необязательное ключевое слово VIRTUAL:

    В обоих приведенных примерах hrly_rate — виртуальный столбец, генерируемый в результате вычисления выражения sal/2800 для каждой строки. Можно также добавить виртуальный столбец к существующей таблице, выполнив оператор ALTER TABLE,как показано в следующем примере:

    Поскольку здесь тип данных для виртуального столбца не специфицирован, Oracle автоматически назначит тип данных на основе типов данных участвующих в выражении столбцов (salary и commision_pct).

    Ограничения виртуальных столбцов

    На виртуальные столбцы таблицы накладывается ряд ограничений, которые перечислены ниже.

    • Нельзя создавать виртуальные столбцы в индекс-таблицах, внешних таблицах,временных таблицах, объектах или кластерах.
    • Нельзя создавать виртуальный столбец определяемого пользователем типа, типа LOB или типа RAW.
    • Все столбцы, участвующие в выражении, должны принадлежать одной таблице.
    • Выражение столбца должно давать результат — скалярную величину.
    • Выражение столбца в конструкции AS не может ссылаться на другой виртуальный столбец.
    • Нельзя выполнять обновление столбца с использованием конструкции SET оператора UPDATE.
    • Нельзя выполнять операции удаления или вставки на виртуальном столбце.

    Добавление столбца в таблицу

    Добавление столбца в таблицу — очень простая операция. Для этого просто используется команда ALTER TABLE, как показано ниже:

    Удаление столбца из таблицы

    Удалить существующий столбец из таблицы можно с помощью следующей команды:

    Если таблица, из которой удаляется столбец, содержит большой объем данных, можно попросить Oracle просто пометить столбец как неиспользуемый, не пытаясь удалить из него данные. Вы не увидите потом этот столбец в запросах или представлениях, и все зависящие от него объекты, такие как ограничения и индексы, определенные на этом столбце, будут удалены. Для практических целей таким способом “уничтожить” большой столбец можно очень быстро.

    Ниже приведен пример, в котором столбцы hiredate и mgr в таблице emp помечаются как неиспользуемые:

    Когда появится время на обслуживание базы, можно будет окончательно уничтожить эти два столбца с помощью следующей команды:

    Если вы полагаете, что большое количество строк в таблице может потенциально переполнить пространство отмены (undo), можете уничтожить столбец с указанием конструкции CHECKPOINT. Это сократит генерацию данных undo при уничтожении столбца, применяя контрольную точку после определенного количества строк. Ниже показан пример, который заставляет базу данных применять контрольную точку всякий раз,когда она удаляет 10 000 строк из таблицы emp:

    Переименование столбца таблицы

    С помощью команды rename column легко переименовать столбец таблицы. Например, следующая команда переименует столбец retired в таблице emp на non_active.Обратите внимание, что при желании можно также переименовать ограничения столбца.

    Совет. Временные файлы, а также файлы данных и журналов повторного выполнения, переименовываются с использованием команды ALTER DATABASE.

    Переименование таблицы

    Иногда разработчику приложений может понадобиться переименовать таблицу.Переименование выполняется просто:

    Удаление всех данных из таблицы

    Для удаления всех строк из таблицы можно применить команду TRUNCATE, которая,несмотря на название, на самом деле ничего не усекает и не сокращает — она просто очень быстро удаляет все строки. TRUNCATE — команда DDL, поэтому она не может быть отменена командой ROLLBACK.

    Можно также удалить все строки из таблицы командой DELETE * FROM TABLE. , и поскольку это команда DML, то в этом случае при желании возможна отмена удаления.Однако поскольку команда DELETE пишет все изменения в сегменты отмены, на ее выполнение требуется намного больше времени. Команде TRUNCATE не нужно возиться с сегментами отмены, поэтому она выполняется за считанные секунды, даже для очень крупных таблиц.

    Вот пример команды TRUNCATE в действии:

    Создание новой таблицы с помощью CTAS

    Чтобы создать новую таблицу, которая будет идентичной существующей, или же создать новую таблицу, которая включит только некоторые строки и столбцы из другой таблицы, можно воспользоваться командой CREATE TABLE AS SELECT * FROM.С помощью этой команды легко загрузить часть существующей таблицы в новую таблицу, используя условия where, или же загрузить все данные из старой таблицы в новую,применяя конструкцию SELECT * FROM, как показано в следующем фрагменте кода:

    Если таблица содержит миллионы строк, а ваше время слишком ограничено, чтобы использовать метод CTAS, существует пара способов ускорить создание новой таблицы,содержащей большие объемы данных. Если создаваемая таблица должна быть пустой,то время на ее создание беспокоить не должно — она будет создана немедленно. Но если вы загружаете новую таблицу данными из другой таблицы, то можете выиграть от применения опций PARALLEL и NOLOGGING, которые ускоряют загрузку крупных таблиц.

    Опция PARALLEL позволяет осуществлять загрузку данных параллельно несколькими процессами, а опция NOLOGGING инструктирует Oracle о том, что протоколировать изменения, происходящие при загрузке в файлы журналов повторного выполнения и сегменты отката (за исключением очень небольшого объема, необходимого для внутренних потребностей), не требуется. Вот пример:

    Другой метод, который можно применять для экономии времени во время создания таблицы, состоит в перемещении таблицы из одного табличного пространства в другое. Можете воспользоваться преимуществом операции перемещения, чтобы изменить любые параметры хранения. Ниже приведен пример команды ALTER TABLE. MOVE,которая позволяет быстро перемещать таблицы между табличными пространствами.В данном примере таблица employee перемещается из ее текущего табличного пространства в новое:

    При перемещении таблицы идентификаторы ROWID ее строк меняются, а это означает, что база данных не позволит добавлять, удалять или изменять данные каким-либо образом. Например, если есть конфигурационная таблица, которую требуется сохранить от любых изменений любыми пользователями, можно изменить ее статус на “только для чтения”.

    Воспользуйтесь оператором ALTER TABLE для перевода таблицы в режим “только для чтения”:

    После перевода таблицы в режим “только для чтения” база данных не позволит выполнять на ней следующие операции:

    • TRUNCATE TABLE
    • SELECT FOR UPDATE
    • Любые операции DML
    • ALTER TABLE ADD/MODIFY/RENAME/DROP COLUMN
    • ALTER TABLE SET COLUMN UNUSED
    • ALTER TABLE DROP/TRUNCATE/EXCHANGE (SUB)PARTITION
    • ALTER TABLE UPGRADE INCLUDING DATA or ALTER TYPE CASCADE INCLUDING
    • TABLE DATA для типа, от которого зависит таблица “только для чтения”
    • Оперативное переопределение
    • FLASHBACK TABLE

    Перечисленные ниже операции на таблице “только для чтения” выполнять можно:

    • SELECT
    • CREATE/ALTER/DROP INDEX
    • ALTER TABLE ADD/MODIFY/DROP/ENABLE/DISABLE CONSTRAINT
    • ALTER TABLE для изменения физических свойств
    • ALTER TABLE MOVE
    • RENAME TABLE и ALTER TABLE RENAME TO
    • DROP TABLE

    Вернуть таблицу в нормальное состояние “чтение-запись” можно, указав конструкцию READ WRITE в операторе ALTER TABLE:

    Сжатие таблиц

    Сжатие данных в таблице, помимо ускорения производительности запросов, позволяет сэкономить дисковое пространство и сократить затраты памяти. Однако сжатие данных в таблице влечет за собой некоторые накладные расходы при загрузке данных или выполнении операций DML. Применять сжатие таблиц можно как в приложениях хранилищ данных, которые предполагают, в первую очередь, операции чтения, так и в системах OLTP, которые включают интенсивные операции DML. На сжатых таблицах можно выполнять операции вставки, удаления и обновления. Чтобы сократить расходы, попробуйте сжать данные, которые в основном используются только для операций чтения и обновляются редко. Хронологические данные и архивные данные являются подходящими кандидатами на помещение в сжатые таблицы.

    Илон Маск рекомендует:  Моделирование при сжатии текстовых данных lzr

    Когда база данных сжимает таблицу, она исключает дублированные значения в блоке данных. База данных хранит все дублированные значения таблицы в начале блока,в символьной таблице блока. База данных заменяет множественные экземпляры дублированных данных краткой ссылкой на символьную таблицу. Со сжатой таблицей можно выполнять все операции, которые выполняются над обычной таблицей. Допускается сжимать таблицы и материализованные представления. Также возможно сжимать только некоторые разделы секционированных таблиц.

    Oracle предлагает также сжатие табличных пространств. При сжатии табличного пространства все таблицы, которые создаются в нем, будут автоматически сжатыми.

    Определив таблицу как сжатую, автоматическое сжатие данных будет возникать при следующих операциях:

    • загрузка через прямые операции SQL*Loader;
    • загрузка через оператор CTAS;
    • операторы параллельной вставки;
    • операторы последовательной вставки с подсказкой APPEND;
    • однострочные или в виде массивов вставки и обновления.

    Самый большой ущерб производительности, связанный со сжатием данных, происходит при вставке данных с использованием любого из методов, перечисленных выше.Удаление сжатых данных, однако, осуществляется так же быстро, как и несжатых.Вдобавок обновление на сжатых таблицах также выполняется медленнее.

    В дополнение к созданию таблицы с включенным сжатием, можно также сжимать существующие данные в таблице с использованием оператора ALTER TABLE. MOVE.При сжатии данных подобным образом база нуждается в установке исключительной блокировки на таблице, что предотвращает все обновления и вставки до тех пор, пока не завершится операция сжатия. В качестве альтернативы можно воспользоваться пакетом DBMS_REDEFINITION для выполнения оперативного переопределения таблицы,чтобы избежать блокировки всей таблицы.


    Включение сжатия

    Включается сжатие путем указания конструкции COMPRESS в операторе CREATE TABLE или ALTER TABLE. COMPRESS. Если вы изменяете таблицу, то только новые данные будут после этого подвергаться сжатию. Таким образом, таблица может в одно и то же время содержать в себе как сжатые, так и несжатые данные. Отключается сжатие таблицы с использованием оператора ALTER TABLE. UNCOMPRESS. Отключение сжатия не распаковывает уже сжатые ранее данные в таблице; оно лишь гарантирует, что новые данные не будут сжиматься.

    На заметку! Применять сжатие таблиц можно как в средах OLTP, так и в средах хранилищ данных.Лучшие результаты можно получить, сжимая все подлежащие только чтению и хронологические данные, которые редко изменяются.

    Существует пара вариантов конструкции COMPRESS. Конструкция COMPRESS FOR ALL OPERATIONS используется для включения сжатия для всех операций. Чтобы включить ее только для операций прямых вставок (пакетных вставок), специфицируйте конструкцию COMPRESS FOR DIRECT_LOAD OPERATIONS. Сама конструкция COMPRESS эквивалент на COMPRESS FOR DIRECT_LOAD OPERATIONS.

    Обратите внимание, что если включить сжатие только для прямых вставок, позже нельзя будет удалить никаких столбцов. Добавлять столбцы можно, только указывая их значения по умолчанию. Эти ограничения не применяются при включении сжатия для всех операций в таблице.

    Примеры сжатия таблиц

    Следующий пример демонстрирует включение сжатия таблицы для всех операций,что, скорее всего, понадобится при настройке OLTP:

    Для только прямых вставок в таблицу можно использовать любой из приведенных ниже операторов:

    Как видно из этих примеров, конструкция COMPRESS FOR ALL OPERATIONS — это то,что необходимо применять для сжатия таблиц OLTP. С помощью следующего запроса можно узнать, какие таблицы базы данных являются сжатыми:

    Столбец COMPESS_FOR показывает тип сжатия таблицы (для всех операций или только для загрузки в прямом режиме).

    Удаление таблиц

    Для удаления таблицы служит команда DROP TABLE имя_таблицы. Чтобы иметь возможность удалить таблицу, пользователь должен быть ее владельцем (она должна быть в его схеме) или же обладать привилегией DROP ANY TABLE.

    После выдачи команда DROP TABLE таблица не исчезает немедленно — Oracle просто переименовывает таблицу и сохраняет ее в корзине (Recycle Bin), которая на самом деле является таблицей словаря данных. Поэтому можно вернуть нечаянно удаленную таблицу с помощью следующей команды:

    Возможность восстановления удаленной таблицы называется средством Flashback Drop (Ретроспектива удаления).

    Если вы уверены, что таблица никогда более не понадобится, можете окончательно избавиться от нее, указав опцию PURGE в команде DROP TABLE:

    В результате использования приведенной выше команды PURGE таблица emp будет немедленно уничтожена без возможности восстановления!

    На заметку! Команда DROP TABLE имя_таблицы PURGE эквивалентна старой команде DROP TABLE имя_таблицы в версиях, предшествовавших Oracle Database 10g.

    Когда вы удаляете таблицу, все индексы, относящиеся к ней, также удаляются. Если таблица, которую необходимо удалить, содержит первичные или уникальные ключи,на которые ссылаются во внешних ключах другие таблицы, потребуется включить конструкцию CASCADE в оператор DROP TABLE, чтобы одновременно уничтожить эти ограничения:

    Ускорение работы базы данных

    04.04.2009, 12:00

    Ускорение работы Access-SQL Server
    Сабж такой: Имеется некий апгрейд клиент-серверной БД Access-Access на Access-SQL Server следующим.

    Дамп базы данных, место хранения базы (phpmyadmin)
    Здравствуйте, стал знакомиться с денвером как возникло множество вопросов относительно базы данных.

    ускорение работы базы mysql для сайта
    допустим, есть у меня в mysql таблица, куда заносятся все взаимодействия между посетителями сайта.

    Ускорение считывания из базы данных
    Добрый день, подключил базу данных основанную на службах в свою программу, раньше данные были в.

    Ускорение работы макроса (преобразование данных к нужному формату)
    Добрый день! в программировании на VBA недавно, а поэтому подозреваю, что подход к написанию кода.

    Заметки на полях

    PL/SQL. Oracle shrink tablespace — сжатие табличного пространства

    • Получить ссылку
    • Facebook
    • Twitter
    • Pinterest
    • Электронная почта
    • Другие приложения
    • Получить ссылку
    • Facebook
    • Twitter
    • Pinterest
    • Электронная почта
    • Другие приложения

    Комментарии

    Отправить комментарий

    Популярные сообщения из этого блога

    OpenCart 2.1.0.2. Инструкция по установке OpenCart на Windows 7 SP1 + IIS 7.5 + PHP 7.0 + MySql 5.7.11

    Установка PHP
    1.Скачиваем дистрибутив PHP 7.0 VC14 x86 Non Thread Safe, распаковываем содержимое архива в папку C:\STORE\PHP (http://windows.php.net/download)

    4.Редактируем php.ini. убираем “;” перед строками и выставляем следующие значения
    fastcgi.impersonate = 1
    fastcgi.logging = 0
    cgi.fix_pathinfo = 1
    cgi.force_redirect = 0
    extension_dir = «C:\STORE\PHP\ext»
    extension=php_curl.dll
    extension=php_gd2.dll
    extension=php_mysqli.dll
    extension=php_openssl.dll
    date.timezone = Europe/Moscow

    5.Создаем директорию «C:\STORE\www» в нее кладем файл index.php с таким кодом:

    Включаем и настраиваем IIS (Internet Information Services)
    1. Открываем Панель управления, запускаем «Программы и компоненты» > «Включение и отключение компонентов Windows» и подключаем следу…

    T-SQL. Почему пишут WHERE 1=1?

    Новичков часто ставит в тупик конструкция типа: SELECT* FROM [dbo].[bkp_product] WHERE 1=1 AND [model] =’Product 1′ AND [quantity] = 939


    Зачем пишут в коде 1=1? Ответ — для удобства при отладке кода.
    Покажу на примере. Напишем простой селект SELECT* FROM [Table_1] c WHERE [c].[ >’d’ AND [c].[qty] >= 1000
    Допустим при отладке кода, нам нужно из условия WHEREубрать [c].[ >’d’ AND [c].[qty] >= 1000
    А если у нас изначально было написано SELECT* FROM [Table_1] c WHERE 1=1 AND [c].[ >’d’ AND [c].[qty] >= 1000
    То нам нужно будет закомментировать всего одну строку SELECT* FROM

    Сжатие таблицы Oracle

    Мне нужно сжать таблицу. Я использовал alter table tablename compress для сжатия таблицы. После этого размер таблицы остался прежним.

    Как мне сжать таблицу?

    Для сжатия старых блоков таблицы используйте:

    Это приведет к повторному вводу записей в другие блоки, сжатию и удалению старых блоков, поэтому вы получите пространство. И делает недействительным indexex, поэтому вам нужно будет перестроить их.

    Сжатие не влияет на уже сохраненные строки. Пожалуйста, проверьте официальную документацию :

    «Вы указываете сжатие таблицы с помощью предложения COMPRESS В таблице CREATE выражение. Вы можете включить сжатие для существующего таблицу, используя этот раздел в ALTER TABLEstatement. В этом случае, единственными данными, которые сжимаются, являются данные, вставленные или обновленные после сжатие включено. «

    ALTER TABLE t MOVE COMPRESS является действительным ответом. Но если вы используете разные параметры не по умолчанию, особенно с большим объемом данных, делайте регрессионные тесты перед использованием ALTER TABLE. MOVE.
    С историей возникло больше проблем (ухудшение производительности и ошибок). Если у вас есть доступ, посмотрите базу данных Oracle, чтобы узнать, есть ли известные проблемы для функций и версии, которые вы используете.)
    Вы находитесь на более безопасной стороне, если вы:

    • создайте новую таблицу
    • вставьте данные из исходной (старой) таблицы
    • drop old table
    • переименуйте новую таблицу в старое имя таблицы

    Сжатие данных в целях экономии места и ускорения работы oracle

    Вопрос экономного кодирования информации в системах управления базами данных был поставлен в первой половине 1970-х годов, но не потерял актуальности до сих пор. Многие современные исследователи отмечают недостаточную теоретическую проработку проблемы и неэффективность поддержки сжатия данных.

    Интерес к задаче сжатия данных в СУБД изначально был обусловлен стремлением уменьшить физический объем баз данных. Цена подсистемы ввода-вывода составляла основную часть стоимости аппаратуры. Поэтому при надлежащем интегрировании в СУБД методов безущербного сжатия данных достигалась значительная экономия. Небольшое увеличение числа используемых тактов процессора для кодирования-декодирования более чем компенсировалось снижением затрат на подсистему ввода-вывода. Данный результат применения сжатия востребован и в настоящее время. Действительно, падение относительной стоимости устройств хранения информации на несколько порядков сопровождалось соответствующим увеличением размера типичных баз данных. Тем не менее, в настоящее время фокус интереса все больше смещается на увеличение производительности системы управления данными за счет использования сжатия.

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

    Для применения в СУБД требуются специфические методы и приемы экономного кодирования, поскольку обычные методы не удовлетворяют ряду требований. Практическая ценность реализации достигается только при обеспечении быстрого доступа к произвольной записи или элементу данных. Востребованы так называемые методы сжатия с сохранением упорядоченности, позволяющие выполнять операции сравнения без декодирования данных.

    Проблема реализации сжатия в СУБД имеет также такие аспекты, как оптимизация выполнения запросов к сжатым данным, эффективное сжатие результатов выполнения запросов, экономное кодирование метаданных, оценка целесообразности сжатия отдельных элементов, выбор алгоритма сжатия и его параметров с учетом типовых запросов и характера данных.

    Описание предметной области

    Объект исследования

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

    В данной работе рассматривается одна из них, наука о водной оболочке земли — гидрология. Исключительная роль воды в жизни человека и всего живого на Земле обусловливает большое и постоянно возрастающее внимание к изучению гидросферы и режиму водных объектов. Основная работа по организации и осуществлению наблюдений, сбора и обработки информации о состоянии гидросферы выполняется национальными метеорологическими, гидрологическими, геологическими службами и водохозяйственными организациями стран земного шара.

    Начало создания национальных служб и международного сотрудничества в изучении гидросферы относится к середине XIX века, когда в 1853 году была разработана программа проведения метеорологических наблюдений в океанах с целью повышения безопасности жизни на море. В результате прогресса, достигнутого в различных научных областях, в XX веке были разработаны и быстро усовершенствовались методы наблюдений за компонентами гидросферы в атмосфере, океанах и водных объектах суши. Были приняты меры по обмену данными наблюдений между службами. Разработки в области использования спутников и компьютерной технологии привели к созданию в 1963 году под эгидой Всемирной метеорологической организации (ВМО) комплексной всемирной оперативной системы, названной Всемирной службой погоды, которая включает глобальную систему телесвязи и глобальную систему обработки данных. Создана также глобальная система сбора океанографических данных.

    В настоящее время на земном шаре действуют около 9 тыс. станций на суше, производящих наблюдения за влажностью воздуха, облачностью, количеством выпадающих атмосферных осадков (из них 350 автоматизированы или частично автоматизированы). Около 700 морских судов производят наблюдения за различными параметрами состояния вод Мирового океана (температура, соленость и минеральный состав вод, направление течений). Эти данные дополняются наблюдениями с коммерческих самолетов (около 10 тыс. сводок в сутки). Передают информацию и 300 заякоренных буев или фиксированных платформ, работающих как автоматические морские станции, и около 600 буев, дрейфующих с океанскими течениями. На сегодняшний момент существует огромное количество институтов и организаций, занимающихся гидрологическими исследованиями. Придумано и осуществлено десятки тысяч международных программ и проектов.

    В 2003 году Группа ученых из Японии, США и Европы подготовила программу глобального исследования океана. По всему миру распределили около 3 тысяч самопогружающихся датчиков. На протяжении ближайших 3-4 лет они будут собирать подробные данные о течениях, фиксировать колебания температуры, концентрацию соли и прочие параметры, которые, по мнению специалистов, помогут предсказывать изменения климата на планете. Эксперимент получил название «Арго-программа». Оборудованные специальной аппаратурой датчики цилиндрической формы погружаются на глубину 2-х километров и остаются там в течение десяти часов. После этого приборы длиной около метра и диаметром 20 сантиметров автоматически всплывают на поверхность, связываются с помощью антенн со спутниками и передают собранную информацию на наземные станции, а затем вновь уходят под воду.

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

    Проблема хранения информации

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

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

    Современной тенденцией развития программ исследования Земли из космоса является создание в ряде стран электронных библиотек космической информации. Эти национальные информационные системы используют потоки спутниковых данных для решения разнообразных задач дистанционного зондирования, определяемых как научным сообществом, так и конкретными отраслями производственной деятельности. Например, в США для информационной поддержки своей национальной системы наблюдения Земли из космоса (EOS) NASA создало EOSDIS — разветвленную инфраструктуру сбора, архивирования и распространения спутниковых данных потребителям. Система EOSDIS сосредоточила огромные массивы геопространственных данных, получаемых со спутников ДЗЗ. Это создает серьезные проблемы при организации хранения и доступа к спутниковым данным, поскольку стандартные пакеты программ баз данных не могут их эффективно перерабатывать. Например, каждый кадр прибора ТМ спутника Ландсат в шести спектральных каналах (разрешение 30 м) и одном тепловом (разрешение 120 м) покрывает площадь 170 х 185 квадратных километров. В результате объем такого кадра спутника Ландсат достигает 400 Мбайт. Ежедневные объемы необработанных спутниковых данных ДДЗ, поступающие в систему EOSDIS, оцениваются в 480-490 Гбайт. Объем обработанных данных ДЗЗ в системе EOSDIS достигает 1600 Гбайт в сутки.

    Роль и важность системы хранения определяются постоянно возрастающей ценностью информации в современном обществе, возможность доступа к данным и управления ими является необходимым условием для выполнения бизнес-процессов. Безвозвратная потеря данных подвергает бизнес серьезной опасности. Утраченные вычислительные ресурсы можно восстановить, а утраченные данные, при отсутствии грамотно спроектированной и внедренной системы резервирования, уже не подлежат восстановлению. По данным Gartner, среди компаний, пострадавших от катастроф и переживших крупную необратимую потерю корпоративных данных, 43% не смогли продолжить свою деятельность.

    Анализ существующих систем сжатия

    Использование сжатых таблиц

    В большинстве систем поддержки принятия решений (СППР) обычно используются большие объемы данных, которые хранятся в нескольких очень больших таблицах. При развитии подобных систем требования к дисковому пространству могут быстро расти. Сейчас хранилища данных объемом сотни терабайт встречаются все чаще.

    При решении проблем с дисковым пространством, появившаяся в Oracle 9i Release 2 возможность сжатия таблицы может существенно сократить объем дискового пространства, используемого таблицами базы данных и, в некоторых случаях, повысить производительность запросов. Возможность сжатия таблиц в Oracle9i Release 2 реализуется путем удаления дублирующихся значений данных из таблиц базы. Сжатие выполняется на уровне блоков базы данных. Когда таблица определена как сжатая, сервер резервирует место в каждом блоке базы данных для хранения одной копии данных, встречающихся в этом блоке в нескольких местах. Это зарезервированное место называют таблицей символов (symbol table). Помеченные для сжатия данные хранятся только в таблице символов, а не в строках данных. При появлении в строке данных, помеченных для сжатия, в строке, вместо самих данных, запоминается указатель на соответствующие данные в таблице символов. Экономия места достигается за счет удаления избыточных копий значений данных в таблице.

    Сжатие таблицы на пользователя или разработчика приложений никак не влияет. Разработчики обращаются к таблице одинаково, независимо от того, сжата она или нет, поэтому SQL-запросы не придется менять, когда вы решите сжать таблицу. Параметры сжатия таблицы обычно устанавливаются и изменяются администраторами или архитекторами базы данных, и участие в этом процессе разработчиков или пользователей минимально.

    Основной причиной использования сжатия таблицы является экономия дискового пространства. Таблица в сжатом виде обычно занимает меньше места. Сжатие таблицы в Oracle9i Release 2 позволяет существенно сэкономить дисковое пространство, особенно в базах данных, содержащих большие таблицы только для чтения. Если учитывать дополнительные требования к загрузке и вставке данных, а также правильно выбрать таблицы-кандидаты для сжатия, сжатие таблиц может оказаться потрясающим способом экономии дискового пространства и, в некоторых случаях, повышения производительности запросов.

    Но существуют свои недостатки:
    1) Поскольку сжатие таблицы выполняется при массовой загрузке, операции загрузки требуют дополнительной обработки — надо выполнять дополнительные действия. Дополнительное время при загрузке в сжатую таблицу требуется для выполнения действий по сжатию загружаемых данных. В реальной ситуации различие во времени загрузки будет зависеть от особенностей таблицы и загружаемых данных.
    2) В системах оперативной обработки транзакций (online transaction processing — OLTP) данные обычно вставляются обычными операторами INSERT. В результате, от использования сжатия для соответствующих таблиц большого преимущества не будет.
    3) Более того, изменение данных в сжатой таблице может потребовать распаковки строк, что сводит на нет все преимущества сжатия. В результате, часто изменяемые таблицы плохо подходят для сжатия.

    Упаковка битов

    Метод упаковки битов (bit packing) заключается в кодировании значения атрибута битовыми последовательностями фиксированной длины. Для каждого сжимаемого столбца требуется хранить соответствующую таблицу перекодировки. Разрядность кодовых последовательностей определяется количеством различных чисел, значения которых реально принимаются атрибутом, или же мощностью области определения атрибута. Очевидно, что требуемая длина кода N равна [ log 2 n ], где n — это мощность множества реальных или допустимых значений атрибута. Данный метод рассматривается в одной из самых ранних статей по сжатию баз данных. Метод упоминается наряду с другими приемами под названием «bit compression».

    Упаковка битов — это простой способ сжатия на уровне значения атрибутов, реализация которого необременительна. Также важно, что при соответствующей реализации сохраняется упорядоченность. Но проблемой при использовании данного метода является обработка появления новых значений атрибута. В этом случае может потребоваться перекодировать все значения столбца, если [ log 2 n ] становится больше исходного N .

    Суть метода: для каждого столбца находится минимальное и максимально значение. Значения, попавшие внутрь этого диапазона, последовательно кодируются. Длина кодового слова постоянна и определяется размером диапазона. Пример: пусть имеется последовательность строк из двух полей = <(100, 21), (98, 24), (103, 29)>. Для первого поля диапазон [98, 103], для второго — [21, 29]. Мощность первого множества значений равна 6, второго — 9. Поэтому будет представлена как: = <(0102, 00002), (0002, 00112), (1012, 10002)>.

    Очевидно, что если сжатие применяется к полям фиксированной длины, то их новая длина также фиксирована. Для каждого столбца необходимо хранить только границы диапазона и, возможно, длину. Перекодирование требуется лишь в случае выхода значения за границы диапазона. Степень сжатия сильнее всего зависит от распределения значений каждого атрибута для записей, хранящихся в одной странице. Можно кардинально улучшить сжатие за счет перераспределения записей по страницам при обработке на файловом уровне.

    Метод упаковки битов не может обеспечить значительной степени сжатия относительно других методов, что, тем не менее, во многих приложениях может компенсировать высокой скоростью обработки данных и сохранением упорядоченности.

    Арифметическое кодирование

    Совершенно иное решение предлагает т.н. арифметическое кодирование. Арифметическое кодирование является методом, позволяющим упаковывать символы входного алфавита без потерь при условии, что известно распределение частот этих символов и является наиболее оптимальным, т.к. достигается теоретическая граница степени сжатия. Предполагаемая требуемая последовательность символов, при сжатии методом арифметического кодирования рассматривается как некоторая двоичная дробь из интервала [0, 1). Результат сжатия представляется как последовательность двоичных цифр из записи этой дроби.

    Идея метода состоит в следующем: исходный текст рассматривается как запись этой дроби, где каждый входной символ является «цифрой» с весом, пропорциональным вероятности его появления. Этим объясняется интервал, соответствующий минимальной и максимальной вероятностям появления символа в потоке. Подробнее о методах кодирования можно прочитать на личной странице Семенова ЮА.

    Выбор направления разработки

    Генетическое программирование как метод сжатия данных

    Идею генетического программирования (ГП) — впервые предложил Коза в 1992 году, опираясь на концепцию генетических алгоритмов (ГА). Эта идея заключается в том, что в отличие от ГА в ГП все операции производятся не над строками, а над деревьями. При этом используются такие же операторы, как и в ГА: селекция, скрещивание и мутация.

    В ГП хромосомами являются программы. Программы представлены как деревья с функциональными (промежуточные) и терминальными (конечные) элементами. Терминальными элементами являются константы, действия и функции без аргументов, функциональными — функции, использующие аргументы. Для того чтобы применить ГП к какой-либо проблеме, необходимо определить:
    · Множество терминальных элементов
    · Множество функциональных элементов
    · Меру приспособленности (fitness)
    · Параметры, контролирующие эволюцию
    · Критерий останова эволюции
    Деревья поколений — кодируют сложную функцию, представляя её в виде дерева расчета (как при разборе выражений из теории трансляции). Используются при решении задачи автоматического определения функций. В генетическом программировании особи из популяции представляют собой программы. Удобно представлять эти программы в виде деревьев, где функции представлены внутренними узлами, к которым в качестве входных параметров присоединены поддеревья. Листьями такого дерева будут константы, входные параметры задачи или директивные команды программы. Пример простой программы-дерева:

    Рис. 1 — Формула (х+3)*7, представленная в виде дерева

    Первый главный шаг в подготовке использования генетического программирования должен идентифицировать множество терминалов. Набор терминалов, наряду с набором функций, представляет собой компоненты, из которых будет создаваться компьютерная программа для полного или частичного решения проблемы.

    Второй шаг заключается в определении функционального множества, элементы которого должны использоваться для генерации математических выражений. Каждая компьютерная программа (то есть, анализируемое дерево, математическое выражение) является композицией функций от множества функций F и терминалов из терминального множества T (в случае программ-функций это константы и переменные).

    Множество возможных внутренних узлов (не листовых), используемых в деревьях синтаксического анализа, используемых в генетическом программировании, называется функциональным множеством:
    F= Каждая функция из функционального множества характеризуется арностью — количеством входящих параметров. Множество листовых узлов в деревьях синтаксического анализа, представляющих программы в генетическом программировании, называются терминальным множеством:
    T= Функциональное и терминальное множества могут быть объединены в однородную группу С, при условии, что терминалы рассматриваются как функции с нулевой арностью:
    C=F U T

    Пространством поиска генетического программирования является множество всех возможных рекурсивных композиций функций множества C. В функциональном множестве могут быть применены арифметические, математические, булевы и другие функции. В терминальное множество могут войти переменные, константы или директивные команды. Множества F и T должны обладать свойствами замыкания и достаточности.

    ЗАМЫКАНИЕ требует, чтобы каждая функция из множества F была способна принять аргументом любые значения и типы данных, которые могут быть возвращены любой функцией из множества C. Это предупреждает ошибки во время выполнения программ, полученных генетическим программированием. Для обеспечения условия замкнутости можно использовать защиту операций — принудительное приведение поступающих данных к диапазону, определяемому конкретной операцией. Например, операцию извлечения корня можно защитить от появления отрицательного аргумента принудительным расчетом модуля от этого аргумента. Альтернативой защите может быть автоматическое исправление ошибок в программе или применение штрафов за ошибки.

    ДОСТАТОЧНОСТЬ требует, чтобы функции из множества C были способны выразить решение поставленной задачи, то есть, чтобы решение принадлежало множеству всех возможных рекурсивных композиций функций из C. Однако доказать, что выбранное множество C достаточно, возможно лишь в редких случаях. Поэтому, при выборе этого множества, как и при выборе основных операций генетического алгоритма, приходится полагаться лишь на интуицию и экспериментальный опыт.

    Обобщенная схема генетического алгоритма:
    1. Отбор особей для репродукции
    2. Образование пар из отобранных особей
    3. Рекомбинация — генерация новых особей из родительских пар
    4. Мутация новых особей
    5. Позиционирование новых особей в популяции

    Рис. 2 — Анимация. Генерация хромосом. Для воспроизведения нажмите кнопку на рисунке

    Шаги 1-5 выполняются циклически. Обычно после завершения каждого цикла проводят сортировку популяции по приспособленности особей, что облегчает выполнение многих операций. Также, до старта самого алгоритма генерируется начальная популяция — она обычно заполняется случайными решениями (особями). Hа шаге 5, кроме расположения особи в популяции выполняется оператор, определяющий приемлемость новой особи а такжи оператор оценивания новой особи (фитнес-функция).

    Обобщение результатов научного поиска и анализа

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

    Если имеется 1000 точек, фиксирующих какие-то параметры, то метод сжатия будет заключаться в подборе 5-6 или более функций, с помощью объединения которых можно будет потом получить весь набор точек. Кроме сжатия данных данная работа предполагает одновременный анализ данных, который может прослеживаться на больших временных отрезках и при этом не обязательно раскодирование. Так например при анализе температуры, видя, что функция температуры имеет приблизительный вид прямой можно сократить измерения на данном участке объекта или сделать их более дискретными.

    Научность работы заключается в составлении самого алгоритма поиска таких функций, определения интервала, в котором могут лежать предполагаемые коэффициенты функций, а также оценки производительности такого алгоритма в зависимости от разных по объъему наборов.

    Таким образом можно выделить следующие задачи и цели магистерской работы:

    ·Одним из методов поиска определить диапазон, в котором будут находиться возможные терминалы
    ·Задаться набором минифункций, на основании которых будет производиться поиск функции или набора функций, кодирующих заданную последовательность параметров
    ·Определить параметры алгоритма, такие как коэфиициент мутации, способ селекции
    ·Реализовать алгоритм сжатия
    ·Провести анализ алгоритма на разных наборах данных при различной точности
    ·Определить недостатки и достоинства данного метода

    Полная версия направления разработки магистерской работы находится в научной статье.

    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL