Oracle Database Application Optimizations for SAP

Optimizări ale distribuției sarcinii de lucru

SAP obișnuia să se gândească la o bază de date ca la un simplu depozit de date. Ori de câte ori un utilizator dorește să facă ceva util cu datele, acesta trebuie transferat, deoarece informațiile se află în serverul de aplicații SAP.

Dezavantajele acestei abordări sunt evidente: dacă suma de 1 milion de valori trebuie calculată și dacă aceste valori reprezintă bani în monede diferite, 1 milion de valori individuale sunt transferate de pe serverul bazei de date pe serverul aplicației - doar pentru a fi aruncate după efectuarea calculului. Traficul de rețea cauzat de această abordare este responsabil pentru performanțele slabe.

Ca răspuns la această perspectivă, SAP a dezvoltat strategia "Push down": împingerea codului care necesită calcule cu volum mare de date de la nivelul aplicației la nivelul bazei de date. Ei au dezvoltat un model de programare complet nou, care permite codului ABAP să apeleze (implicit sau explicit) procedurile stocate în baza de date. Și au definit o bibliotecă de proceduri standard, denumite SAP NetWeaver Core Data Services (CDS).

Cu 20 de ani înainte, Oracle avusese deja aceeaşi idee şi luase aceeaşi decizie. Începând cu versiunea 7, Oracle Database le permite dezvoltatorilor să creeze proceduri și funcții care pot fi stocate și rulate în baza de date. Prin urmare, a fost posibil ca CDS să fie disponibil şi pentru Oracle Database, iar astăzi dezvoltatorii de aplicaţii SAP îl pot utiliza.

Optimizări ale modelului de date

SAP BW: Flat InfoCubes

Modelele de date SAP (set de tabele pe care o aplicație le utilizează și relațiile dintre ele) au fost definite acum 15 sau 20 de ani și optimizate pentru baze de date orientate pe disc. Dar, după cum s-a dovedit, ceea ce era o optimizare în epoca calculului pe disc este un obstacol în epoca calculului în memorie.

Cel mai cunoscut exemplu este probabil structura internă a unui cub SAP BW. Ceea ce din punct de vedere comercial sau al utilizatorului pare a fi un singur „cub” este, de fapt, un set de mai multe tabele, iar relațiile dintre acestea pot fi descrise ca o ierarhie pe mai multe niveluri (schema „stea” sau „snowflake”). Această structură complexă, care necesită mai multe asocieri la executarea unei interogări sau a unui raport, încetinește considerabil bazele de date în memorie. Prin urmare, SAP a proiectat un model de date nou, mai simplu pentru SAP BW pe HANA și, prin urmare, l-a numit HANA-Optimized InfoCubes. Dar acest nou model de date nu este optimizat numai pentru HANA. Este optimizat pentru calculul în memorie în general. Prin urmare, SAP pe utilizatorii Oracle care au activat Oracle Database In-Memory îl pot implementa şi ei, singura diferenţă fiind numele (Flat InfoCubes sau pur şi simplu Cuburi nestructurate).

Aplicații SAP OLTP: Declusterizarea tabelelor (Table Declustering)

O mai puțin faimoasă, totuși importantă optimizare este Table Declustering. Un tabel de cluster stochează o înregistrare completă (logică) într-o singură coloană de tabel (fizică). O astfel de valoare complexă poate fi interpretată de serverul de aplicații SAP, dar nu de un server de baze de date - ceea ce înseamnă că nu este posibilă împingerea codului, dacă este implicat un tabel de cluster. Prin urmare, SAP acceptă acum Declustering pe tabele, pentru HANA, precum şi pentru Oracle Database.

Optimizări pentru dezvoltarea aplicațiilor

Beneficiile cadrului CDS pe care tocmai l-am descris nu se limitează în niciun caz la aplicațiile SAP (adică aplicațiile standard create de dezvoltatorii SAP). Pentru clienţi, aplicaţiile dezvoltate la domiciliu reprezintă o parte esenţială a peisajului SAP. Multe dintre aceste aplicații ar putea beneficia în mod semnificativ de utilizarea caracteristicilor CDS.

Vizualizările CDS pot fi expuse prin OData. Pe baza expunerii la OData a CDS, este destul de simplu să creați aplicații SAP Fiori folosind cadrul de dezvoltare SAP WEB IDE. Pentru detalii, consultați raportul ABAP Core Data Services pe anyDB.