Kleine Exkursion in die noch relativ unbekannte Welt von Times Ten

Immer mehr Hersteller springen auf den In-Memory Zug auf. Mit der hauseigenen Lösung Times Ten gehört Oracle zu den Big Player in dem Umfeld. Der große Vorteil dieser Technologie: Sie ist schnell, extrem schnell. Während Oracle RDBMS im Millisekunden-Bereich liegt, reagiert Times Ten in Mikrosekunden. Besonders für Anwendungen mit höchster Transaktionslast, User-Sessions oder für Real-Time-Anforderungen, wie sie beispielsweise in der Telekommunikation oder im Finanz- und Versicherungsbereich gebraucht werden, stellt die In-Memory-Technologie eine optimale Lösung dar. Das Release 2 der Version 11g der Times Ten war für die Autoren ein Anlass, eine kleine Exkursion in diese noch relativ unbekannte Welt zu unternehmen.

Abbildung 1: Times Ten Architektur und Prozesse

Abbildung 2: Cache Groups in Times Ten (Quelle: Oracle Technology Network.)

Was kann die Vorteile einer In-Memory-Datenbank besser aufzeigen, als ein Beispiel aus der Praxis?
Stellen Sie sich eine bestehende Oracle-Datenbank vor – ein 4-Knoten Oracle Real Application Cluster (48 CPU Cores und 512 GByte RAM) –, die von der Performance her am Limit lief. Der Hauptgrund hierfür war die hohe Parallelisierung, die mittels eines Java Grid zustande kam. Gearbeitet wurde mit 512 Sessions, die durch die Java Grid-Infrastruktur in der Oracle-Datenbank erstellt wurden. Die Auslastung des Systems lag bei über 80% - natürlich alles andere als ideal. Zudem war eine Erhöhung der Grid Sessions auf 1024 geplant, was zu einem Kollaps geführt hätte.

Mit dem Ziel, die Datenbank zu entlasten, kam Times Ten zum Einsatz. So wurden die Select-Abfragen auf ausgewählte READ-ONLY-Tabellen ausgelagert. Das gleiche geschah mit Tabellen mit Zwischenresultaten: Diese wurden ohne persistente Speicherung in Oracle nach Times Ten ausgelagert. Zudem sollte das Ganze skalieren: Für den Fall, dass die beiden Times Ten-Server nicht genug Durchsatz erreichen würden, wurden weitere Times Ten-Server hinzugefügt.

Klare Performance-Vorteile, eine deutliche Entlastung der Oracle-Datenbank und des Netzwerks sowie eine Skalierung durch den Einsatz von weiteren Times Ten-Instanzen waren das Ergebnis.

Die In-Memory-Technologie: Klare Performance-Vorteile aber bescheidener Sprachumfang

Times Ten ist für den Betrieb in der Anwendungsschicht konzipiert. Im Gegensatz zu einer traditionellen Oracle-Datenbank, die nur bei Bedarf Daten in den Buffer Pool speichert, findet die Datenhaltung bei einer In-Memory-Datenbank im Arbeitsspeicher statt. Die Read Only-Daten sind immer im Speicher vorhanden und der „Query Optimizer“ von Times Ten kann direkt auf alle Daten im Hauptspeicher zugreifen, ohne zusätzlichen I/O-Traffic zu erzeugen. Dadurch vereinfachen sich die Zugriffsalgorithmen um Einiges, was wiederum zu einer erheblich besseren Performance der Anwendung führt, da das synchrone I/O in Transaktionslogs wegfällt. Auch die Datenbanknähe zur Applikation (Direct Connect Driver) bringt einen klaren Performance-Vorteil mit sich, weil kein Netzwerk Overhead zum Einsatz kommt.

Times Ten ist auf keinen Fall als Alternative zu einer herkömmlichen Datenbank zu verstehen, sondern vielmehr als interessante und zeitgemäße Ergänzung mit großem Potential, das im Zusammenspiel mit einer Oracle-Datenbank ausschöpft werden kann. In den meisten Fällen macht es Sinn, nur gewisse Module der Applikation nach Times Ten auszulagern. Somit wird die Oracle-Datenbank (beziehungsweise das darunterliegende I/O-System) entlastet, ohne auf deren Vorzüge verzichten zu müssen.

Für die Verarbeitung vieler, aber kleiner Transaktionen – wie zum Beispiel Inserts, Updates oder kurze Selects – ist die Times Ten optimal. Wer aber versucht, komplexe SQL-Abfragen anzuwenden, wird schnell merken, dass Times Ten dafür nicht geeignet ist. Bereits JOIN können die Performance massiv verschlechtern.

Wenn DBAs sich für den Einsatz von Times Ten entscheiden, sollten sie die Einarbeitungszeit nicht unterschätzen. Bestehendes DBA-Wissen kann – wenn überhaupt – nur sehr eingeschränkt eins zu eins eingesetzt werden. Der Aufbau von Times Ten und Oracle ist grundverschieden und obwohl die In-Memory-Lösung SQL und PL/SQL unterstützt, ist der Sprachumfang noch relativ bescheiden. Daher müssen oftmals große Teile der Source-Codes umgeschrieben werden.

Weitere Einschränkungen bringen die Data Dictionary Views, die nur teilweise vorhanden sind. Des Weiteren steckt die Performance-Analyse des Systems in den Kinderschuhen und bietet kein Automatic Workload Repository (AWR) an. Auch die Backup/Recovery-Features sind außerdem rudimentär, sodass hierfür neue Strategien entwickelt werden müssen.

Doch für performancekritische Anwendungen bleibt Times Ten trotz alledem ein durchaus interessantes Produkt und wer die Entwicklung von Times Ten beobachtet, weiß anhand der Features, die im Release 11.2.2.2.0 eingeflossen sind, dass Oracle mit Hochdruck daran arbeitet, diese Lücken zu schließen.

Begriffe rund um Times Ten

Times Ten bedient sich teilweise der gleichen Begriffe wie die bekannte Oracle-Datenbank. Doch nicht immer haben diese dieselbe Bedeutung. Folgende Gegenüberstellung gibt einen Überblick der wichtigsten Begriffe.


Times Ten	Oracle
Instance: Times Ten Main Daemon, startet alle weiteren benötigten Times Ten Prozesse (Masterprozess)	n/a
DataStore: Einer oder mehrere laufen unter der gleichen Instanz. Jeder DataStore hat seinen eigenen Sub Daemon Prozess (vom Main Daemon gestartet).	Database/Instance: Es ist kein Main Daemon vorhanden, jedoch hat jede Instanz ihre eigenen Prozesse.
Checkpoint Files: „Dirty Blocks“ werden aus dem Memory durch den Checkpointer Thread in diese Files geschrieben (Speicherabbild).	Datafiles: Der DBWR Prozess schreibt „dirty Blocks“ hier hinein. Es befinden sich aber nur Teile der Daten im Memory.
Transaction Logs: Enthalten alle Transaktions-Daten seit dem letzten Checkpoint. Nach jedem Checkpoint werden diese Logs gelöscht.	Redologs/Archivelogs: Enthalten alle Transaktionsdaten, werden aber nicht automatisch gelöscht.
n/a	Controlfiles: Enthalten Metadaten und Struktur-Informationen zur Datenbank
Parameter Datei: sys.odbc.ini	Parameter Datei: init.ora
n/a	Tablespaces: Container für Daten.
Times Ten Server Process: Nimmt Anfragen des Clients entgegen.	Listener: Nimmt Anfragen des Clients entgegen.

Architektur und Prozesse

Die zentralen Elemente von Times Ten sind das „Shared Memory“-Segment und die Prozesse mit ihren Threads. Die obere Hälfte der Abbildung 1 zeigt die Prozesse, die eine Verwaltung der Client-Anfragen ermöglichen, während im unteren Teil die Prozesse/Threads zur Verwaltung des DataStore aufgezeigt werden. Zusätzlich kann Times Ten mit einer Oracle-Datenbank zusammenarbeiten, wofür zwei weitere Agent Prozesse (siehe rechte Seite in Abbildung 1) verfügbar sind.

Jeder Sub Daemon gehört zu einem DataStore. Der Sub Daemon Prozess beinhaltet für die verschiedenen Verwaltungsaufgaben so genannte Threads, deren Zweck sich meistens aufgrund des sprechenden Namens erraten lässt.

Times Ten Setup und Konfiguration

Die Installation gestaltet sich einfach. Unter Windows existiert ein grafischer Installer, während Times Ten für Linux/Unix mit einem Script installiert wird. Nachdem die geforderten Voraussetzungen anhand der Dokumentation geprüft und entsprechend konfiguriert wurden, läuft der Installer problemlos durch. Zudem bietet er auch eine „silent“-Option mittels Response File.

Nach der Installation befindet sich im $TT_HOME/info ein Template der sys.odbc.ini Datei. Die vielen mitgelieferten Beispiele helfen dem DBA dabei, sich einen DataStore zu erstellen. Bei der ersten Verbindung zum DataStore werden die Dateien (Checkpoint und Log Files) erstellt sowie die komplette Datenbank in den Speicher geladen. Eine einfache Definition eines DataStores in der sys.odbc.ini könnte wie folgt aussehen:

SQL>
[DS01]
Driver=/u00/app/Times Ten/product/Times Ten/tt1122/lib/libtten.so
DataStore=/u01/oradata/DS01/DS01
LogDir=/u01/oradata/DS01
PermSize=64
TempSize=32
PLSQL=1
DatabaseCharacterSet=UTF8
OracleNetServiceName=DB02.world

Mit dem Tool ttIsql wird zur Times Ten-Datenbank verbunden. Dieses ist sozusagen das SQLPlus von Times Ten. Nach der ersten erfolgreichen Verbindung sind die Dateien für die Datenbank unter /u01/oradata/DS01 zu finden.

ttIsql DS01

IMDB Cache für Oracle Tabellen

In der aktuellen Version wird von Times Ten IMDB (In-Memory Database) Cache nur das Oracle RDBMS unterstützt. Für einen Oracle-DBA wird es natürlich erst dann richtig spannend wenn Times Ten mit einer Oracle-Datenbank zusammenarbeitet. Also schauen wir uns die Zusammenarbeit mit Oracle-Datenbanken doch etwas genauer an.

Tabellen aus Oracle können innerhalb so genannter Cache Groups in einen Times Ten DataStore geladen werden. Ein Times Ten DataStore kann gleichzeitig mit einer Oracle-Datenbank arbeiten (OracleNetServiceName Property). Ein DataStore ist die eigentliche Datenbank Instanz, die sich zur Oracle-Datenbank verbinden kann. Zudem kann eine Tabelle genau nur einer Cache Group angehören. Eine Cache Group gruppiert jedoch eine oder mehrere Oracle Tabellen. Diese Tabellen sind via Fremdschlüssel miteinander verbunden. Bildlich gesprochen ergeben die Tabellen einer Cache Group eine Baumstruktur mit genau einer Root-Tabelle, an dessen Primary Key sich alle Child-Tabellen orientieren.

Die Abbildung 2 zeigt, dass beliebige Tabellen eines Schemas nach Times Ten geladen werden können. Es können sogar innerhalb einer Tabelle nicht benötigte Spalten bei der Definition einer Cache Group weggelassen werden. Somit existieren diese Spalten nur in der Oracle-Datenbank und belegen keinen Platz im Times Ten DataStore. Eine Cache Group ist eigentlich nur ein logisches Konstrukt in Times Ten und enthält selber keine Daten. Die Daten werden in Times Ten durch die identischen Tabellen bzw. deren Namen repräsentiert und somit erfolgt auch der Zugriff völlig identisch. Ein „select * from scott.emp“ funktioniert in beiden Datenbanken, sofern natürlich die emp Tabelle in eine Cache Group nach Times Ten geladen wurde.

Da Cache Groups das zentrale Element bei der Interaktion mit Oracle darstellen, gehen wir nachfolgend etwas detaillierter darauf ein. Grundsätzlich kennt Times Ten vier verschiedene Cache Group Typen:


Cache Group	Erläuterung
Read Only Cache Group	Alle „committed“ Daten der Oracle-Datenbank werden in Times Ten geladen und sind nur lesend verfügbar. Das heißt: Times Ten kann diese Daten nicht ändern und schreibt somit auch nie etwas in die Oracle-Datenbank zurück. Das Erkennen von Änderungen in der Oracle-Datenbank basiert auf Triggern, während der Cache Agent von Times Ten das eigentliche Nachladen der Daten übernimmt. Read Only Cache Groups sind ideal geeignet für Referenzdaten.
Asynchronous writethrough (AWT) Cache Group	Alle “committed” Updates/Inserts gegen die Times Ten-Tabellen werden asynchron zur Oracle-Datenbank propagiert. Mit anderen Worten: Der Commit in der Oracle-Datenbank erfolgt asynchron zum Commit in Times Ten, so dass die In-Memory-Datenbank nicht ausgebremst wird. Seit dem Release 11gR2 lassen sich mehrere parallele Sessions für den asynchronen Abgleich konfigurieren (CacheAwtParallelism Parameter). Dies war beim Vorgänger teilweise ein Problem, da alle Transaktionen seriell abgearbeitet wurden und es somit zu einem Datenstau auf Times Ten-Seite kommen konnte. Grundsätzlich verwendet Times Ten den Replication Agent Prozess für das Schreiben in die Oracle-Datenbank.
Synchronous writethrough (SWT) Cache Group	Wie bei der asynchronen Variante werden die Updates/Inserts in die Oracle-Datenbank geschrieben. Jedoch passiert dies synchron, wodurch Times Ten in jedem Fall das Commit von der Oracle-Datenbank abwartet. Somit verliert der DBA hier mit Sicherheit keine Daten der Tabellen aus der synchronen Cache Group. Hierfür muss er aber bereit sein entsprechende Performance-Einbussen in Kauf zu nehmen.
User Managed Cache Group	Bei diesem Typ von Cache Groups muss der Abgleich der Daten, egal in welche Richtung, manuell erfolgen. Times Ten spricht hier von „Flush“ und „Load“ Operationen. Ein „Flush“ geht immer in Richtung Oracle-Datenbank, wobei beim „Load“ die Daten nach Times Ten geladen werden.

Die verschiedenen Arten von Cache Groups eröffnen ein breites Anwendungsspektrum. Exemplarisch wird nachfolgend die Definition einer AWT Cache Group in Times Ten gezeigt. Dabei werden die Tabellen dept und emp aus dem Schema scott nach Times Ten geladen.

SQL>
CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP deptartments
FROM
scott.dept (
 deptno number(2) NOT NULL,
 dname varchar2(14),
 loc varchar2(13),
 PRIMARY KEY (deptno)),
scott.emp (
 EMPNO NUMBER(4) NOT NULL,
 ENAME VARCHAR2(10),
 HIREDATE DATE,
 COMM NUMBER(7,2),
 DEPTNO NUMBER(2),
 PRIMARY KEY(empno),
 FOREIGN KEY (deptno) REFERENCES scott.dept(deptno));

Die Spalten JOB, MGR und SAL aus der Tabelle emp werden bewusst weggelassen, da diese für dieses Beispiel in Times Ten nicht von Bedeutung sind.

SQL & PL/SQL Support

Der Sprachumfang von SQL und PL/SQL in der Oracle-Datenbank und in Times Ten sind leider noch nicht identisch. Das bedeutet, dass existierender Source-Code nicht eins zu eins übernommen werden kann. Dies haben die Autoren am eigenen Leibe erfahren und mussten entsprechend viel Zeit in die Portierung investieren. Zum Beispiel wurde die WITH Funktionalität nicht unterstützt. Daher mussten alle mit WITH geschriebenen Views oder Selects im Code überarbeitet werden. Oracle arbeitet jedoch mit Hochdruck daran, dass Times Ten den ganzen Sprachumfang der Oracle-Datenbank unterstützt.

Daher bringt das neue Release 11.2.2.2.0 die folgenden Neuerungen mit sich:

Implizite Datenkonversion
SELECT 1 + '1' FROM dual
WITH Klausel
Analytische Funktionen: AVG, SUM, COUNT, MAX, MIN, DENSE_RANK, RANK, ROW_NUMBER, FIRST_VALUE und LAST_VALUE
Analytische Klauseln: OVER PARTITION BY, OVER ORDER BY
sowie noch weitere Funktionalitäten (nachzulesen in der Oracle Times Ten Dokumentation für Release 11.2.2.2.0)

Dennoch fehlen gewisse Teile immer noch:

Foreign Keys, welche auf die gleiche Tabelle referenzieren werden nicht unterstützt, z.B: Vorgesetzter/Mitarbeiter
in SQL kann eine selbst geschriebene Funktion nicht verwendet werden

SQL>CREATE FUNCTION my_func RETURN VARCHAR2 IS
BEGIN
RETURN 'a';
END;
/
FUNCTION created.
 
SELECT my_func FROM dual;
2211: Referenced COLUMN MY_FUNC NOT found
 
The command failed

Das Ergebnis eines SELECT Statements kann nicht mittels INSERT in die gleiche Tabelle geschrieben werden

SQL>CREATE TABLE emp (a VARCHAR2(30));
INSERT INTO emp (SELECT * FROM emp);
2377: Target TABLE of INSERT cannot be IN the FROM clause
The command failed.

Diese hier begonnene Liste erhebt leider keinen Anspruch auf Vollständigkeit. Eine weitere wichtige Einschränkung gegenüber der Oracle-Datenbank ist die Parallelität. In Times Ten ist SQL nicht parallel ausführbar. In der Oracle-Datenbank kann ein SQL allerdings sehr wohl parallel ausgeführt werden, was vor allem bei großen Datenmengen enorme Vorteile haben kann, z.B. bei der Batch–Verarbeitung.

Fazit

Neben den Vorteilen, die Times Ten mit sich bringt, sind folgende Punkte zu beachten:

Die Grenzen von In-Memory Technologie im Auge behalten (z.B. SQL)
Grundsätzlich Direct Driver Connect verwenden,
Times Ten und Applikation auf dem gleichen Server installieren
Performance-Analyse nur erschwert möglich und daher aufwändiger als in Oracle
DBA Know-how der Oracle-Datenbank gilt nicht eins zu eins in Times Ten, daher ist ein Know-how-Aufbau zwingend erforderlich

Oracle arbeitet kontinuierlich daran, die Einarbeitungszeit zu kürzen, indem der Hersteller Features aus der Oracle-DAtenbank nach Times Ten portiert. Unabhängig davon ist die Einarbeitungszeit essentiell wichtig und gehört definitiv zu einem guten Projektplan. Auch Themen wie Maintenance sowie Backup und Recovery müssen neu betrachtet werden, da Times Ten sich anders als die Oracle-Datenbank verhält. Beim Tuning der Abfragen zeigt sich dann schlussendlich, ob die In-Memory Technologie verstanden wurde. Aufgrund der häufig erforderlichen Portierung von SQL gelangt wohl nahezu jedes Projekt früher oder später beim Tuning. Da lässt sich der Performance-Vorteil von Times Ten eindrucksvoll messen.

04.04.2012 Datenbank
Von: Jan Ott, Roland Stirnimann

Zurück