Valós idejű megoldások: Realtime ODS és Database In-Memory tapasztalatok Pusztai Péter IT fejlesztési senior menedzser – Magyar Telekom
Sef Dániel Szenior IT tanácsadó– T-Systems Magyarország 2016. április 6.
Amiről szó lesz…
Siebel Replica – ODS rendszer születésének körülményei a Magyar Telekomban A rendszer felhasználási céljai, lehetőségei Oracle Database In-Memory esettanulmány Tapasztalatok, összegzés
A születés körülményei
milyen igények hívták életre a Siebel Replica-t 1
2
3
Adattárház táplálása
Valós időben épülő adattörténet
Érzékeny adatok és Siebel audit logok kezelése
Siebel audit logok biztonságos és elkülönített gyűjtése Meghatározott tulajdonságok alapján történő adatirányítás Érzékeny adatokhoz történő hozzáférés korlátozása
Éles Siebel tehermentesítése
Nagy számításigényű feladatok elvégzése Nagy adattömegű, batch adatszolgáltatások
A születést követően újAbb igények jelentek meg: Több forrásból származó, integrált adatokra épített adatszolgáltatások Online lekérdezések (extrém gyors válaszidővel történő kiszolgálás) Ad-hoc riporting
Felhasználási célok, funkciók Számos felhasználási lehetőség: • valósidejűség kihasználása: online adattörténet építés, perces gyakoriságú batch feldolgozások futtatása • vissza-irányú interfészek: a forrás rendszer egyben az adatbázis replikában feldolgozott adatok fogadó rendszere • teljes adattörténetre épülő adatszolgáltatások: hatósági adatszolgáltatás, ahol minden változás átadása szükséges • front-end-ek felől érkező online lekérdezések kiszolgálása (jobb válaszidővel, mint amire a forrásrendszer képes) • operatív (és ad-hoc) riportok: riporting keretrendszer
miért jó ez a Magyar telekomnak?
• • • • •
• •
Valós idejű ODS lehetősége Tehermentesíti a produktív rendszereket A dobozos CRM rendszer lehetőségeit kiterjeszti A replikált adatbázison közvetlenül lehet fejleszteni Ütemezett batch feldolgozások Webszolgáltatások implementálásának lehetősége Ad-hoc riportolás
A vAlós idejű információ vonzereje
esettanulmány - Performancia javítás Siebel replika felhasználási célok mentén
•
•
•
Index karbantartás • OLTP indexek • Analitikus indexek Batch feldolgozások Riporting Rendszer
OLTP és Analitikus terhelés
Tesztkörnyezet T-Systems szerveren – Generált tesztadatok segítségével
• 1000 GB Diszk • 60 GB Memória • AMD Opteron(tm) Processor 6128 • 8 core CPU • Siebel Replika fejlesztői környezetéhez hasonló struktúra • Generált tesztadatok
Oracle Database In-Memory Célok
Valós idejű elemzés
100x
OLTP és Analitikus terhelés
Bevezetés az alkalmazás változtatása nélkül
Adatbázis tárolási módok Buffer Cache
Column Store
ORDER
ORDER
Row Format
Column Format
ORDER
• Sor és Oszlop alapú elemzés ugyanarra a táblára • Konzisztens adattárolás • Elemzés és Riporting kiszolgálás Oszlop alapú tárolással • OLTP kiszolgálás sor alapú tárolással
Oracle Database In-Memory Beállítás
1. Memória méret konfigurálása:
inmemory_size = XX GB
2. Táblák vagy partíciók konfigurálása:
alter table | partition … inmemory;
3. OLTP gyorsítás: eldobhatóak az analitikus indexek
OLTP és Analitikus Indexek
Tábla
1–3 OLTP Indexek
10 – 20 Analitikus Indexek
• Index nyilvántartás Siebel Replikában: legtöbb index komplex OLTP adatbázisok esetén analitikus lekérdezéseket szolgál ki • Új sor beszúrása a táblába => 10-20 analitikus indexek frissítése =>Lassú! • Ad-hoc analitika támogatása
In-Memory végrehajtási terv
– Strictly confidential, Confidential, Internal –
Author / Presentation title
2016.04.06.
13
Ad-Hoc lekérdezések Oracle Database In-Memory segítségével
Analitikus SQL tesztek
Real Time Analitika
Bevezetés az alkalmazás változtatása nélkül
Analitikus SQL:
8 millió soros lekérdezés 6 percről 7 másodpercre
?
Köszönjük a figyelmet!
