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 Adattárház táplálása Valós időben épülő adattörténet 2 3 Érzékeny adatok és Siebel audit logok kezelése Éles Siebel tehermentesíté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 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 OLTP és Analitikus terhelés Bevezetés az alkalmazás változtatása nélkül 100x
Adatbázis tárolási módok Buffer Cache ORDER Row Format ORDER Column Store ORDER Column Format 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!