Продуктивність DSS в середовищі Oracle Database 10g R2, Інші СУБД, Бази даних, статті

Зміст


РЕЗЮМЕ
Сьогодні в якості основної опори для сховищ даних потрібні системи управління базами даних високої продуктивності. В Oracle Database 10g R2 пропонуються нові опції і удосконалення, що забезпечують істотне підвищення продуктивності для задоволення зростаючих вимог, що виникають при роботі з сховищами даних. Підвищення продуктивності має місце автоматично після проведення оновлення до рівня Oracle Database 10g R2 без яких-небудь змін в коді додатків або додаткових витрат на розгортання. У пропонованому технічному документі описуються ці нові опції та удосконалення, а також демонструється забезпечується ними підвищення показників продуктивності.

ВСТУП
Кожен день організації накопичують мільярди байтів даних про свій бізнес, мільйони індивідуальних фактів про свої замовників, операціях, продуктах і службовців. Найбільший успіх дістанеться на долю тих організацій, які зможуть ефективно використовувати свої дані для поліпшення щоденного процесу операційного управління, будувати сильні відносини з акціонерами і, що найбільш важливо, задовольняти вимоги своїх замовників. Сховища даних та системи аналізу бізнес-інформації стали наріжним каменем для багатьох успішних підприємств.

Так як компанії шукають спосіб домогтися конкурентної переваги, прагнучи отримати все більше від своїх систем аналізу бізнес-інформації, їх сховища даних постійно збільшуються в розмірах. Вибуховою зростання обсягів сховищ даних та їх збільшується складність до межі напружують функціональні можливості систем управління базами даних. Наголос робиться на те, щоб забезпечити більш швидке отримання більш гарною інформації та швидко реагувати на зміну ділових потреб.

Версія Oracle Database 10g R2 приймає виклик, пропонуючи високопродуктивну систему для відповідності сьогоднішнім швидко зростаючим вимогам, пов’язаним з роботою з сховищами даних. З’явилися в цьому випуску нові можливості і удосконалення дозволяють досягти підвищення виробничих показників при роботі зі сховищами даних і системами аналізу бізнес-інформації. Після проведення оновлення до Oracle Database 10g R2 ці нові можливості і удосконалення органічно інтегруються з існуючими додатками для сховищ даних без якої-небудь нової реалізації або втручання з боку команди, що займається обслуговуванням сховищ даних.

У запропонованій статті описуються всі ці нові можливості і удосконалення. Підвищення виробничих показників демонструється за допомогою конкретного порівняння продуктивності запитів в середовищах Oracle Database 10g R1 і Oracle Database 10g R2. У наступних розділах спочатку описується середу тестування, після чого йде опис тестів, що характеризують пропоноване новими опціями підвищення виробничих показників, включаючи новий алгоритм сортування в оперативній пам’яті, опцію хеш-агрегування, опцію створення контрольних точок для об’єктів та удосконалення для секціонованих таблиць. Потім буде приведено пояснення двох опцій “видобутку даних” та продемонстровано підвищення продуктивності. І, нарешті, слід закінчення статті.

Середа ТЕСТУВАННЯ
Для проведення наведених у цій Білій книзі тестів використовувалася система з двома процесорами Intel Xeon з частотою 2.8 ГГц, виконаними за технологією “сверхмногопотоковості” (Hyper-Threading). Бази даних були створені у файловій системі OCFS (Oracle Cluster File System) і рознесені по 10 дискам єдиного масиву дисків. Схема бази даних, зображена на Рис. 1, включає схему передісторії продажів (Sales History) з набору стандартних прикладів Oracle (Oracle Sample Schema) і деяке число інших незалежних таблиць, які були додані як результат “видобутку даних” (data mining).
Таблиця SALES заповнена комерційною інформацією за 7 років (дані з січня 1995 до грудня 2001 року), обсяг якої становить близько 10 Гбайт. І таблиця SALES, і таблиця COSTS компресувати і секціонірована за діапазоном ключів (стовпець time_id), а загальне число розділів одно 20. У наведеній нижче таблиці наводиться статистика числа рядків і середньої довжини рядка для кожної таблиці.


У кожній з наступних секцій розглядається будь-яка з нових можливостей Oracle Database 10g R2 з демонстрацією тестів на заявленої схемою.

Рис1. Схема бази даних


 


СОРТУВАННЯ У ОПЕРАТИВНОЇ ПАМ’ЯТІ
В Oracle Database 10g R2 вводиться новий алгоритм сортування в оперативній пам’яті, який сортує швидше і має кращу локальність (locality) системи пам’яті, ніж існуючий алгоритм сортування для Oracle Database 10g R1.
Новий алгоритм сортування в оперативній пам’яті підвищує продуктивність широкого спектру запитів. Він використовується в наступних випадках:



Новий алгоритм сортування в оперативній пам’яті не підтримує стовпці, для яких ведеться збірка сміття (garbage collection), є сегментовані потоки або які мають розмір більш 30 000 байт, навіть якщо вони не є ключовими стовпцями. З ключових стовпців нова сортування в оперативній пам’яті не підтримує стовпці, що вимагають семантичних порівнянь, типу логічних rowid і часу з годинниковим поясом.


При деяких обставинах продуктивність старого алгоритму сортування погіршується в міру збільшення розміру доступної пам’яті і досягає деякого порога. Новий алгоритм сортування в оперативній пам’яті вирішує цю проблему, завдяки хорошій локальності системи пам’яті.


У першій групі тестів показано підвищення продуктивності для декількох типових запитів, для яких виявляється корисна нова сортування в оперативній пам’яті. При виконанні цих тестів параметр workarea_size_policy був встановлений на AUTO. У другій групі тестів демонструється локальність системи пам’яті нового алгоритму сортування в оперативній пам’яті шляхом установки параметра workarea_size_policy на MANUAL. Тести виконувалися з мінливими значеннями параметра sort_area_size, причому кожного разу вимірювалося загальне витрачений час для одного запиту.


Для оцінки продуктивності використовувалися наступні запити.

create index sales_cust_id on sales (cust_id) parallel
compute statistics nologging;

Ми позначимо цей запит як “ INDEX “.

Для оператора select було розглянуто наступний запит:

select prod_id, time_id, unit_cost from costs order by unit_cost;

Щоб уникнути виведення на екран 14600000 рядків, фактично виконувався запит:

select count(*) from (select /*+ no_merge */ prod_id,
time_id, unit_cost from costs order by unit_cost);

Підказка NO_MERGE в тексті запиту не дозволяє Oracle злити вбудоване подання з потенційно розміщеним в іншому об’єкті SQL-оператором, так що фактично виконується фраза “order_by unit_cost”.

Ми позначимо цей запит як ” SELECT “.


Кожен з вищезазначених запитів виконувався як в Oracle Database 10 g R1, так і вOracle Database 10 g R2, а статистики виконання їх порівнювалися. План виконання в Oracle Database 10 g R2 є тим же самим, що і в Oracle Database 10 g R1, хоча лежать в їх основі реалізації сортування в оперативній пам’яті будуть різними.


План виконання для запиту INDEX виглядає наступним чином:



У наступній таблиці наводиться порівняння продуктивності запиту INDEX :












 

Загальне
витрачений час (с)

Відсоток використання ЦП


Oracle Databasel0g R1
Oracle Database R2

1432
706

88.54
55.98


Завдяки новому алгоритму сортування, запит INDEX в Oracle Database 10 g R2 виконується удвічі швидше, ніж в Oracle Database 10 g R1. Більше того, відсоток зайнятості центрального процесора при виконанні запиту INDEX в Oracle Database 10 g R2 (55.98%) набагато менше, ніж відсоток зайнятості центрального процесора при виконанні запиту INDEX в Oracle Database 10 g R1 (88.54%), завдяки чому з’являється можливість виконувати більше паралельних запитів.


План виконання для запиту SELECT має наступний вигляд:



У наступній нижче таблиці наводиться порівняння продуктивності запитів SELECT .












 

Загальне
витрачений час (с)

Відсоток використання ЦП


Oracle Databasel0g R1
Oracle Database R2

19
10

83.21
73.33


Запит SELECT з фразою order-by виконується майже вдвічі (на 47%) швидше і споживає менше процесорного часу, ніж еквівалентний запит вOracle Database 10 g R1.


На відміну від алгоритму сортування вOracle Database 10 g R1 новий алгоритм сортування вOracle Database 10 g R2 має гарну локальність системи пам’яті. Він генерує менше “непопадання” в кеш і TLB, ніж алгоритм сортування в Oracle Database 10 g R1. У міру зростання розміру доступною для сортування пам’яті продуктивність запитів з використанням нового алгоритму сортування підвищується.


Використовуючи в якості прикладу запит INDEX , Ми змінювали параметр sort_area_size і порівнювали продуктивність запиту в середовищах Oracle Database 10 g R1 іOracle Database 10 g R2. У наступній нижче таблиці для запиту INDEX зібрані дані про загальний витрачений час у секундах для різних значень параметра sort_area_size .



















SORT_AREA_SIZE

1 Мбайт

10 Мбайт

100 Мбайт


Oracle Database 10g R1

1318

1389

1653


Oracle Database 10g  R2

911

804

715


Створення індексу в жодному з вищезазначених випадків не проходило повністю в пам’яті. Проте через гарну локальності в оперативній пам’яті нового алгоритму сортування швидкість запиту INDEX вOracle Database 10 g R2 збільшується в порівнянні з Oracle Database 10 g R1 від 44% до 131% при збільшенні значення sort_area_size з 1 до 100 Мбайт.


На закінчення повторимо: новий алгоритм сортування в оперативній пам’яті, введений вOracle Database 10 g R2, значно підвищує продуктивність запиту в одиницях загальної витраченого часу, споживаючи менше часу центрального процесора і дозволяючи виконувати більше число паралельних запитів. Через кращою локальності системи пам’яті, забезпечується новим алгоритмом сортування в оперативній пам’яті, продуктивність запитів з використанням цього алгоритму підвищується в міру зростання обсягу доступної пам’яті.


Хеш-Агрегація


Агрегування даних – це часто трапляється в середовищах OLAP і сховищ даних операція. Дані або агрегуються “на льоту”, або обчислюються попередньо і зберігаються як матеріалізовані уявлення. У кожному разі, агрегування даних зводить разом записи з однаковими значеннями стовпців group-by (стовпці, по яких проводиться групування) і агрегує їх.


При агрегування даних в Oracle Database 10 g R1 використовується підхід на основі сортувань. В Oracle Database 10 g R2 застосовується метод хешування. Він працює шляхом побудови хеш-таблиці за даними по значенням стовпців group-by і знаходження записів з тими ж самими значеннями стовпців group-by при дослідженні (probing) хеш-таблиці. Хешування значно підвищує продуктивність агрегування даних.


Підвищення продуктивності при хешування ілюструється наступним запитом, в якому обчислюється внесок індивідуальних замовників в дохід. Спочатку перераховуються найбільш великі вкладники.



select c.cust_last_name last_name, s.revenue revenue
        from  customers   c,
             (select  cust_id, sum(amount_sold) revenue
        from sales
        group by cust_id ) s
where s.cust_id = c.cust_id
order by s.revenue desc;


У запиті споживається багато ресурсів центрального процесора. Щоб гарантувати чесне порівняння, вOracle Database 10 g R2 була відключена нова опція сортування в оперативній пам’яті. У наступній нижче таблиці проводиться порівняння продуктивності запиту вOracle Database 10 g R1 і R2.















Загальне витрачений час (с)


Oracle Database 10g R1

395


Oracle Database 10g R2

171


У разі використання хешування для агрегування даних запит в Oracle Database10 g R2 виконується на 57% швидше, ніж запит в Oracle Database10 g R1.


Так як агрегування даних є вельми часто виконуваної завданням у сховищах даних і для аналізу бізнес-інформації, значне підвищення продуктивності в результаті хеш-агрегування вOracle Database 10 g R2 має величезне значення.


Секціонірованние ТАБЛИЦІ


В Oracle Database 10 g R2 з’явилися два основні зміни в секціонуванні. Щоб збільшити масштабованість і гнучкість, кількість розділів таблиці було збільшено з 64 К до 1 мільйона. Друга зміна пов’язано з реалізацією більш ефективних методик відсікання, що гарантують, що ми звертаємося тільки до тих розділів, які задовольняють будь-яким предикатам запиту. Ми проілюструємо методики відсікання в Oracle Database 10 g R2 з двох різних сторін – відсікання розділів для предикатів диз’юнктивного OR і відсікання розділів, використовуючи доступ за індексом.


Щоб продемонструвати удосконалення при відсіканні розділів для предикатів диз’юнктивного OR, використовується наступний запит.



select p.promo_name promo_name,(s.profit – p.promo_cost) profit


from  promotions p,
(Select promo_id, sum (sales.QUANTITY_SOLD * (costs.UNIT_PRICE – сosts.UNIT_COST)) profit


     from sales, costs where
( (sales.time_id BETWEEN TO_DATE(“Ol-JAN-1998″,”DD-MON-YYYY”, “NLS_DATE_LANGUAGE = American”) and TO_DATE(“01-JAN-1999″,”DD-MON-YYYY”, “NLS_DATE_LANGUAGE = American”))
OR
(sales.time_id BETWEEN TO_DATE(“01-JAN-2001″,”DD-MON-YYYY”, “NLS_DATE_LANGUAGE = American”) and TO_DATE(“01-JAN-2002”, “DD-MON-YYYY”, “NLS_DATE_LANGUAGE = American”)) )
AND sales.time id = costs.time id
AND sales.prod_id = costs.prod_id
group by promo_id )  s where
s.promo_id = p.promo_id order by  profit desc;


У запиті виконується з’єднання таблиць SALES і COSTS. Таблиця SALES секціонірована за діапазоном ключів для стовпця TIME_ID. Однією з умов запиту є два предиката для TIME_ID, які об’єднані операцією OR. В Oracle Database 10 g R1 запит перетвориться (з використанням OR-розширення) в два підзапиту, об’єднані конкатенації. У кожному підзапит з’єднуються таблиці SALES і COSTS, використовуючи одну гілку предиката OR. В результаті до таблиці COSTS, на додаток до операції конкатенації, звертаються двічі. Це показано в наступному плані виконання запиту. Частини плану, які мають справу з диз’юнктивними предикатами OR, виділені.







В Oracle Database 10 g R2 предикат OR безпосередньо використовується для відсікання розділів таблиці SALES, а між таблицями SALES і COSTS виконується єдине з’єднання, як показано в наведеному нижче плані виконання запиту. Опція хеш-агрегування в Oracle Database 10 g R2 була відключена, щоб гарантувати чесне порівняння. Частини плану, що мають справу з диз’юнктивними предикатами OR, знову виділені.


В Oracle Database 10 g R1 були звернення до більшої кількості даних, що пов’язано з менш ефективним відсіканням. Крім того, хеш-з’єднання скидалися на диск, тим самим ще більше збільшуючи число запитів на фізичне зчитування і збільшуючи число запитів на фізичну запис. ВOracle Database 10 g R2 в результаті кращого відсікання і зменшення числа запитів на фізичний введення / виведення продуктивність запитів значно підвищується. Швидкість виконання запиту підвищується на 30%. Швидкість в одиницях використання користувачем процесорного часу (кількість часу, що витрачається центральними процесорами на виконання запиту, підсумувавши по всіх процесорам), підвищується на 24%.
























Загальне витрачений час (с)


Користувацька процесорний час (с)


Запити на фізичне зчитування


Запити на фізичну запис


Oracle Database 10g R1

417

1334

87668

20772


Oracle Database 10g R2

294

1021

17402

72


Oracle Database 10 g R2 робить більш ефективним використання предикатів запиту, в яких для відсікання непотрібних розділів, визначаються несуміжні діапазони розділів. Ми проілюструємо це, розглянувши наступний запит, в якому обчислюється загальна кількість AMOUNT_SOLD для списку замовників протягом двох несуміжних періодів часу. Заради ілюстрації ми створюємо глобальний індекс SALES_GIDX по стовпцю CUST_ID секціонірованние таблиці SALES. Предикат запиту, використовуючи предикат OR, визначає два непересічних діапазону розділів. ВOracle Database 10 g R2 Oracle звертається тільки до рядків, які належать розділів, певним предикатом OR. Для забезпечення такої можливості в Oracle заводиться список допустимих розділів, специфікованих предикатами. ВOracle Database 10 g R1 замість цього для всіх потенційно допустимих розділів заводиться єдиний діапазон, що призводить до менш ефективного відсікання.



select cust_id, sum (amount_sold)
from sales
where
(time_id BETWEEN TO_DATE(“Ol-JAN-1997″,”DD-MON-YYYY”,”NLS_DATE_LANGUAGE = American”) and TO_DATE(“01-JAN-1998″,”DD-MON-YYYY”,”NLS_DATE_LANGUAGE = American”))
OR
 (time_id BETWEEN TO_DATE(“Ol-JAN-2001″,”DD-MON-YYYY”, 1NLS_DATE_LANGUAGE = American”) and TO_DATE(“01-JAN-2002”, “DD-MON-YYYY”, “NLS_DATE_LANGUAGE = American”))
) AND
cust_id in (50, 60, 70, 80, 1000, 1100, 1590, 4500, 80000, 250000, 350000, 400100, 430000)
group by cust_id;


У наступній нижче таблиці підсумовуються результати продуктивності для запитів в середовищах Oracle Database 10 g R1 і Oracle Database 10 g R2.












 

Загальне
витрачений час (с)

Запити на фізичне зчитування


Oracle Databasel0g R1
Oracle Database R2

31
10

75968
25436


В Oracle Database 10 g R2 завдяки більш ефективному відсікання кількість запитів на фізичне зчитування значно зменшується, що призводить до 68%-ому підвищення швидкості.


Як показують ці два наведені вище прикладу, реалізація більш ефективних методик відсікання в Oracle Database 10 g R2 значно підвищує продуктивність запитів, в яких беруть участь секціонірованние таблиці. Такі пов’язані з відсіканнями удосконалення розділів, а також збільшення граничної кількості розділів для таблиці ще більше підвищують масштабованість і гнучкість, дозволяючи ефективно обробляти великі набори даних з великою кількістю розділів.


СТВОРЕННЯ КОНТРОЛЬНИХ ТОЧОК ДЛЯ ОБ’ЄКТІВ


Щоб забезпечити оптимальне використання ресурсів апаратних засобів, Oracle Parallel Query може використовувати прямий режим читання. Читання в прямому режимі дозволяє підлеглим процесам паралельного запиту обходити кеш даних для запитів на читання і видавати запити на зчитування будь-якого розміру, аж до максимального розміру, що допускається операційною системою. Однак перш ніж до об’єкта можна буде звернутися в прямому режимі читання, модифіковані буфери об’єкта повинні бути записані назад на диск за допомогою запиту на створення контрольної точки для об’єкта. В Oracle Database 10 g R1 запит на створення контрольної точки для об’єкта обробляється шляхом видання команди створення контрольної точки табличного простору для того табличного простору, якому належить об’єкт. При цьому виконується перезапис (на диск) всіх модифікованих буферів всього табличного простору. Так як в тому ж самому табличному просторі може резидентно розміщуватися велику кількість об’єктів, подібна реалізація може викликати велике число непотрібних операцій запису на диск. Запит на створення контрольної точки для цільового об’єкта може привести до того, що на додаток до модифікованих буферам цільового об’єкта назад на диск будуть записані модифіковані буфери інших об’єктів, резидентно розміщених в тому ж самому табличному просторі.


Для усунення подібної неефективності в Oracle Database 10 g R2 запит на створення контрольної точки для цільового об’єкта виконає перезапис на диск модифікованих буферів тільки для цільового об’єкта і не спричинить за собою ніяких додаткових операцій запису для модифікованих буферів інших об’єктів.


Щоб проілюструвати переваги в продуктивності, забезпечувані нової реалізацією Oracle Database 10 g R2, ми припустимо, що до таблиці PRODUCTS_AFFINITY_CARD_A застосований наступний оператор поновлення:



update products_affinity_card_a set home_theater_package=0
where yrs_residence <2;


Оператор поновлення змінює 808760 рядків. Відразу ж після його виконання в буферному кеші міститься близько 84 000 модифікованих сторінок з таблиці PRODUCTS_AFFINITY_CARD_A.


Відразу ж після того, як відбулося оновлення, виконується наступний оператор паралельної вибірки (select), щоб обчислити максимальну середню вартість продуктів.



select max(avg_costs)
from (select avg(unit_cost) avg_costs
from costs
group by prod_id);


Перед виконанням цього оператора Oracle Database 10 g R1 повинен створити контрольну точку для модифікованих буферів таблиці PRODUCTS_AFFINITY_CARD_A, в той час як Oracle Database 10 g R2 в стані виконати оператор select безпосередньо, не записуючи модифіковані сторінки на диск.


Щоб гарантувати чесне порівняння, опції сортування в оперативній пам’яті і хеш-агрегування в Oracle Database 10g R2 були заблоковані, в результаті чого і Oracle Database 10 g R1, і Oracle Database 10 g R2 при виконанні запиту select використовували наступний план виконання:


У середовищі Oracle Database 10 g R1 виконання запиту на паралельний вибір (select) відразу ж після поновлення займає 27 секунд, в той час як в середовищі Oracle Database 10 g R2 ця ж операція займає лише 13 секунд. Це пов’язано з тим, що оператор поновлення поновив таблицю, яка існує в тому ж самому табличному просторі, що й об’єкт, до якого звертається запит select. У середовищі Oracle Database 10 g R1 перед виконанням запиту select додатковий час витрачається на скидання на диск модифікованих буферів таблиці PRODUCTS_AFFINITY_CARD_A.


В результаті вOracle Database 10 g R2 значно підвищується продуктивність паралельного запиту, тому що режим прямого доступу до об’єкта не буде сповільнюватися створенням контрольних точок для модифікованих буферів інших об’єктів в тому ж самому табличному просторі.


ВБУДОВАНІ SQL-ФУНКЦІЇ APPLY ДЛЯ “ВИДОБУТКУ ДАНИХ”


У процесі видобутку даних (data mining) є етап побудови моделі з використанням на першому кроці навчального набору даних. Потім ця модель застосовується до нових наборів даних, щоб генерувати передбачення. Так як існуюча модель може бути застосована до багатьох різних новим наборам даних, операція APPLY часто викликається замовниками для дослідження своїх баз даних. В результаті продуктивність і зручність і простота використання операції APPLY стають дуже важливими.


У термінології видобутку даних функцію APPLY прийнято також називати SCORING, отже, вхідний набір даних (таблиця) для операції APPLY можна назвати даними (таблицею) SCORING. APPLY в Oracle Database 10 g R1, використовуючи API PL / SQL, служить “пакетної” процедурою оцінки, яка на вході приймає таблицю і в якості вихідних даних також пропонує таблицю. APPLY, використовуючи API JAVA, реалізує для записів операцію застосування (apply). Серед недоліків її реалізації в Oracle Database 10 g R1 можна назвати наступні:



У середовищі Oracle Database 10 g R2 функціональні можливості APPLY стандартизуються за допомогою наявності вбудованої SQL-функції для оцінки моделі. Серед переваг реалізації Oracle Database 10 g R2 можна назвати наступні:



Вбудовані в Oracle Database 10 g R2 SQL-функції оцінки можуть застосовувати моделі, побудовані на базі різних алгоритмів видобутку даних. У цій статті для побудови моделі використовується алгоритм адаптивних мереж Байєса (Adaptive Bayes Network – ABN). ABN є алгоритмом класифікації. Модель класифікації, побудована за допомогою алгоритму ABN для навчального набору даних, може використовуватися для класифікації кожного запису в застосовується набір даних (apply dataset), вказуючи, якого класу належить запис. Наприклад, нам треба з’ясувати, чи є у Замовника так звана affinity card (кредитна картка для групи осіб, об’єднаних спільними інтересами – прим. перекладача) на підставі історії його покупок, типу того, скільки великих пакетів DVD-дисків купив Замовник, скільки моніторів з плоским екраном у нього є, скільки бухгалтерських програм їм куплено і т.д. Кожен замовник може бути віднесений до одного з двох класів: мають і не мають групові кредитні карти. Групову карту (скоріше, її наявність або відсутність – прим. перекладача) називають метою, а історії покупок замовників називають провісниками (або прогнозатора). Такі завдання класифікації починаються з навчального набору даних, для якого ми заздалегідь знаємо, чи є у замовника групова карта. Відносини між провісниками і метою в навчальних даних зберігаються в моделі, яка може згодом бути застосована до нових наборам даних для передбачення, наприклад, чи є у замовника групова карта.


Для Oracle Database 10 g R2 і для Oracle Database 10 g R1 ми використовували один і той же навчальний набір даних для побудови моделі ABN, яка потім була застосована до того ж самому набору даних для оцінки. Ми порівняли продуктивність APPLY для Oracle Database 10 g R2 і Oracle Database 10g R1.


У нашому навчальному наборі даних PRODUCTS_AFFINITY_CARD_B є 250 стовпців і 50000 рядків. Таблиця містить стовпець ідентифікації (CUST_ID), мета (AFFINITY_CARD) і 248 провісників типу YRS_RESIDENCE, BULK_PACK_DVDS і FLAT_PANEL_MONITOR і т.д. Побудова моделі ABN з ім’ям “ABN_Clas” і в Oracle Database 10 g R1, і вOracle Database 10 g R2 займає приблизно 40 хвилин.


Коли модель “ABN_Clas” побудована, її можна використовувати, щоб робити прогнози для робочого набору даних. Робоча таблиця PRODUCTS_AFFINITY_CARD_A містить 2000000 рядків. І в Oracle Database 10 g R1, і в Oracle Database 10 g R2 для застосування моделі “ABN_Clas” до робочої таблиці може використовуватися наступна програма на PL / SQL, яка зберігає свої результати в таблиці APPLY_RESULT.



– Таблиця APPLY (робоча) повинна бути завантажена (binned) тим же чином, що і
навчальна таблиця.
– Abn_num – це bin-таблиця, яку ми згенерували, коли завантажували (binning) навчальну таблицю.
BEGIN
DBMS_DATA_MINING_TRANSFORM.XFORM_BIN_NUM (
bin_table_name  => “abn_num”,
data_table_name => ” PRODUCTS_AFFINITY_CARD_A” ,
xform_view_name => ” abn_apply_prepared” ) ;
END;


– Матеріалізує підготовлену робочу таблицю для підвищення продуктивності.
create table abn_apply_prepared_table as select * from abn_apply_prepared;
alter table abn_apply_prepared_table parallel;


– Застосувати (APPLY) МОДЕЛЬ
BEGIN
DBMS_DATA_MINING. APPLY (
model_name         =>           “ABN_Clas”,
data_table_name    =>         ” abn_apply_prepared_table ” ,
case_id_column_name =>    “CUST_ID”,
result_table_name   =>         ” APPLY_RESULT ” ) ;
END;


Хоча наведений вище код може використовуватися як в Oracle Database 10 g R1, так і в Oracle Database 10 g R2, що лежать в основі реалізації для DBMS_DATA_MINING.APPLY відрізняються. В Oracle Database 10 g R2 при виклику DBMS_DATA_MINING.APPLY викликається вбудована SQL-функція PREDICTION_SET. Крім того, ці вбудовані SQL-функції, що стали доступними в Oracle Database 10 g R2, можуть бути викликані в SQL-операторі, що робить функціональність APPLY дуже зручною для використання. Так, наприклад, наступний SQL-оператор

select cust_id, prediction(ABN_Clas using *) as my_pred from abn_apply_prepared_table;

для кожного замовника, збереженого в таблиці abn_apply_prepared_table, пророкує, чи є у нього групова карта, використовуючи для цієї мети попередньо підготовлену модель класифікації ABN_Clas. Вбудована SQL-функція PREDICTION більш проста, ніж PREDICTION_SET. Вона повертає найкраще передбачення для моделі класифікації за умови завдання набору провісників, в той час як функція PREDICTION_SET повертає масив VARRAY об’єктів, що містить всі класи і ймовірність для кожного класу. Якщо в таблиці abn_apply_prepared_table зберігається інформація про два мільйони замовників, вищезгаданий SQL-запит повертає 2000000 рядків. Щоб уникнути необхідності вимірювати загальний час, витрачений на висновок 2 мільйонів рядків, вищезазначений запит був змінений таким чином, щоб полегшити вимір продуктивності:

select count(distinct prediction(ABN_Clas using *)) from abn_apply_prepared_table;

При застосуванні моделі замовники Oracle Database 10 g R2 можуть вибрати один з трьох методів. У першому методі, як показано вище в згаданому прикладі, використовується PL / SQL-програма. Цей метод ми позначимо як Oracle Database 10 g R2 (PL / SQL). У другому методі повинен використовуватися SQL-запит, типу того, що зображений вище. Цей метод ми позначимо як Oracle Database 10 g R2 (SQL). І, нарешті, можна також використовувати інтерфейс API JAVA, який не брав участь в описаному в цій статті еталонному тестуванні. Подібно API PL / SQL, API JAVA в Oracle Database 10 g R2 утворює рівень поверх вбудованих SQL-функцій APPLY.

У наведеній нижче таблиці підсумовуються результати продуктивності для APPLY в середовищі Oracle Database 10 g R1 і APPLY в середовищі Oracle Database 10 g R2 з використанням описаних PL/SQL- і SQL-методів.





















Загальне витрачений час

Тимчасовий простір


Oracle Database 10 g R1


1:00 59 хв 36.56 сек


10 Гбайт


Oracle Database 10 g R2(PL/SQL)


59.6 сек


0


Oracle Database 10 g R2 (SQL)


10.38 сек


0


Вбудовані SQL-функції оцінки в значній мірі підвищують продуктивність APPLY як в плані загального витраченого часу, так і використання тимчасової дискової пам’яті. Поліпшення використання тимчасової дискової пам’яті означає істотну економію вимагається пам’яті. Використання вбудованих SQL-функцій оцінки безпосередньо в SQL-операторі призводить навіть до більш швидкого функціонуванню APPLY і до появи користувацького інтерфейсу, який набагато більш доступний для розуміння недосвідченими користувачами. Покращена продуктивність і розширені зручність і простота використання для APPLY в Oracle Database 10 g R2 дозволяє легко і ефективно обробляти великі набори даних.

УДОСКОНАЛЕННЯ В Алгоритм методу опорних векторів

Введений вOracle Database 10 g R1 метод опорних векторів (Support Vector Machines – SVM) є сучасним алгоритмом видобутку даних, який підтримує завдання регресії та класифікації. Завдання класифікації пророкують цільової клас, базуючись на ряді провісників. Наприклад, ми можемо передбачити, чи має чи ні людина високий рівень доходу, базуючись на провісників типу вік замовника, рід його занять і т.д. В цьому випадку людина належить одному з двох цільових класів: групі з високим або низьким доходом. Замість того, щоб передбачати цільової клас (дискретне або категорійні значення), завдання регресії пророкують числові / безперервні мети. Наприклад, ми можемо передбачити фактичний розмір доходу, базуючись на даних про освіту, рід занять і т.д.

В SVM-термінології логічні рядки, пов’язані з об’єктами аналізу, наприклад, з замовниками, розглядаються як шаблони (patterns). Кожен шаблон є вектором, що складається зі значень провісників та цільового значення. SVM-алгоритм шукає прогнозують шаблони (опорні вектори). Наприклад, щоб передбачити наявність високого або низького доходу, SVM-класифікатор відокремлює ці два цільових класу по межі рішення. Така межа рішення являє гіперплоскость в просторі високої розмірності. У разі даних низької розмірності для перетворення вхідного простору в простір опцій високої розмірності можуть використовуватися нелінійні ядерні функції (наприклад, гауссови ядра). Простір опцій високої розмірності дає SVM-моделям гнучкість, необхідну для точної відповідності довільно складним нелінійним поверхням рішення. Для даних високої розмірності нелінійне ядерне перетворення до простору опцій більш високої розмірності звичайно не є необхідним, і для них можуть бути використані лінійні ядра.

Як і у випадку з будь-яким іншим алгоритмом класифікації або регресії, процес SVM-видобутку даних пов’язаний з побудовою моделі для виявлення відносин між провісниками і метою. Після того, як модель побудована, тестування моделі оцінює її точність. В процесі тестування модель застосовується до незалежного набору даних, для якого доступні цільові значення. Модель з задовільною точністю може використовуватися для генерації прогнозів для набору даних, де цільове значення невідомо. Цей процес називається APPLY.

Реалізація SVM в Oracle Database 10 g R1 порівнянна з іншими публічно доступними інструментальними SVM-засобами (наприклад, SVMLight, LIBSVM, SVMTorch і SVMFu) в термінах швидкості і точності. Але стандартному SVM-підходу притаманні деякі обмеження. При зростанні кількості записів даних час навчання для SVM-моделі масштабується квадратично або навіть кубічних. Крім того, моделі з нелінійними ядрами, а в деяких випадках і з лінійними ядрами, можуть стати дуже великими за розміром, що призводить до повільного побудови моделі і низької продуктивності при її застосуванні.

Для вирішення проблем, властивих масштабованості стандартного SVM-підходу, в Oracle Database 10 g R2 комбінується активне навчання і стратифікована вибірка. Метод ефективно вибирає самі інформативні приклади для скорочення числа опорних векторів. В результаті час побудови та застосування наявної моделі значно скорочується. Метод активного навчання пропонує наближені рішення, але для більшості випадків точність цих наближених рішень порівнянна (всього лише трохи гірше чим) з точністю стандартних SVM-моделей.

Для ілюстрації удосконалень, досягнутих новим методом, ми спочатку побудуємо SVM-модель, використовуючи навчальний набір даних як вOracle Database 10 g R1, так і в Oracle Database 10 g R2, і порівняємо час побудови, використання тимчасової дискової пам’яті, розмір моделі, а також кількість опорних векторів. Потім ми перевіримо обидві моделі, щоб порівняти точність моделі, використовуючи тестовий набір даних. І, нарешті, ми застосуємо обидві моделі до робочого набору даних і порівняємо загальне витрачений час і використання тимчасової дискової пам’яті.

Наша задача класифікації полягає в тому, щоб прийняти рішення, має чи ні людина високий дохід, базуючись на наступних провісників: AGE, WORKCLASS, FNLWGT, EDUCATION, EDUCATION_NUM, MARITAL_STATUS, OCCUPATION, RELATIONSHIP, RACE, SEX, CAPITAL_GAIN, CAPITAL_LOSS, HOURS_PER_WEEK і NATIVE_COUNTRY.

У навчальному наборі даних SUPPLEMENTARY_DEMOGRAPHICS_B міститься 32 561 рядок. Ми будуємо SVM-модель з гауссових ядрами в середовищах Oracle Database 10 g R1 і R2. У наведеній нижче таблиці показана продуктивність моделей, побудованих для обох версій.
























Загальне витрачений час


Тимчасова пам’ять (Мб)


Розмір моделі (Мбайт)


К-сть опорних векторів


Oracle Database10gR1

10 хв 47.40 сек

3

6

11,756


Oracle Database10gR2

9.82 сек

1

.5625

300


На побудову SVM-моделі в Oracle Database 10 g R2 витрачається набагато менше часу, ніж в Oracle Database 10 g R1. Крім того, в Oracle Database 10 g R2 потрібно набагато менший обсяг тимчасового табличного простору, що вказує на те, що новий метод скорочує потребу в пам’яті. Значне скорочення загального витраченого часу і використання тимчасової дискової пам’яті в Oracle Database 10 g R2 стало результатом зменшення розміру моделі.

Щоб підтвердити зменшення розміру моделі, ми протестували обидві моделі, використовуючи тестові дані SUPPLEMENTARY_DEMOGRAPHICS_T з 16 281 рядками, і порівняли точність моделей.


















Точність, обчислена по матриці неточностей


Площа під кривою ROC


Oracle Database 10g R1


.8469


.8935


Oracle Database 10g R2


.8227


.8673


Є різні показники точності моделі. Точність, обчислена по матриці неточностей для Oracle Database 10 g R1, становить 0.8469. Це означає, що число раз, коли модель SVM, побудована вOracle Database 10 g R1, правильно пророкує цільової клас, так само 0.8469 * 16281, де 16 281 – це повне число рядків в тестовому наборі даних. Число випадків, коли клас цільового атрибута передбачений неправильно, одно (1-0.8469) * 16281.

Ще одним корисним показником для оцінки моделі класифікації є так звана експлуатаційна характеристика приймача (Receiver Operating Characteristic – ROC). Площа під кривою ROC (Area Under ROC – AUC) вимірює дискримінує здатність дворівневої моделі класифікації. Чим більше AUC, тим вище ймовірність, що фактично позитивному нагоди (високий дохід) буде призначена вища ймовірність наявності високого доходу, чим фактично негативному випадку (низький дохід). Показник AUC особливо корисний для наборів даних з незбалансованим розподілом цілей (тобто таких, де один цільовий клас домінує над іншим).

Як ми можемо бачити з вищезгаданої таблиці, приблизна модель призводить лише до невеликої втрати точності моделі.
Нарешті, щоб порівняти продуктивність APPLY, ми використовуємо набір даних SUPPLEMENTARY_DEMOGRAPHICS_A з 97 684 записами. У наведеній нижче таблиці показані результати продуктивності APPLY в середовищах Oracle Database 10 g R1 і R2.


















Загальне витрачений час


Тимчасова пам’ять (Мбайт)


Oracle Database 10g R1


6 хв 6.29 сек


7


Oracle Database 10g R2


36.51 сек


0


В результаті зменшення розміру моделі продуктивність APPLY в Oracle Database 10 g R2 в десять разів перевищує продуктивність в Oracle Database 10 g R1. Модель не тільки виконується швидше, але і вимагає меншої кількості пам’яті, на що вказує показник використання тимчасової дискової пам’яті. Недавно введені вбудовані SQL-функції для APPLY вOracle Database 10 g R2, про які йшла мова в попередньому розділі цієї статті, також вносять свій внесок у це підвищення продуктивності.

Методологія SVM в Oracle Database 10 g R2 значно підвищує продуктивність SVM-алгоритму і при побудові, і при застосуванні з малою втратою точності моделі. Вона також дозволяє використовувати SVM-моделі для наборів даних великих розмірів, які не могли бути оброблені в Oracle Database 10 g R1.

ВИСНОВОК


Результати говорять за себе. З удосконаленнями і новими опціями, спроектованими для того, щоб відповідати і навіть перевищувати вимоги додатків для сховищ даних, Oracle Database 10 g R2 забезпечує значно вищу продуктивність. Прозоре підвищення виробничих показників досягається без додаткових витрат на розгортання, а просто за допомогою апгрейда до рівня Oracle Database 10 g R2. Останній випуск Oracle дає працюють з сховищами даних командам можливість ефективно і легко використовувати постійно збільшуються обсяги даних для збільшення інтелектуальних ресурсів підприємства.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*