In-Memory OLTP ist das Schlagwort im SQL

Transkript

1 Backend SQL Server 2014: Das ist neu, Teil 2 Ent(b)lockungskur Eine der größten Neuerungen im SQL Server 2014 ist In-Memory OLTP. Es soll die Datenbank-Engine im SQL Server revolutionieren, da sämtliche Transaktionen direkt im Hauptspeicher ohne Locking & Blocking durchgeführt werden. Auf einen Blick Klaus Aschenbrenner bietet SQL Server Consulting Services für Unternehmen in ganz Europa an. Er beschäftigt sich seit Jahren mit der Windows- Programmierung und seit 2000 mit dem.net Framework und 2005 wurde er für sein Engagement als Microsoft MVP ausgezeichnet. Nähere Informationen zu seiner Person finden Sie auf Inhalt Warum brauchen wir In- Memory OLTP? Memory Optimized Tables. Native Compiled Stored Procedures. Lock & Latch Free Data Structures. Serie 1. Mehr Platz im Pool 2. Ent(b)lockungskur dnpcode A1405SQLServer2014 In-Memory OLTP ist das Schlagwort im SQL Server 2014: Microsoft versucht mit In- Memory OLTP (OLTP = Online Transaction Processing) die relationale Datenbank-Engine im SQL Server neu zu erfinden und verspricht eine bis zu 100-fache Performance-Verbesserung (daher auch der Codename Hekaton = Griechisch für hundert). Klingt vielversprechend. Aber was verbirgt sich eigentlich hinter In-Memory OLTP, warum brauchen wir eine solche neue Technologie, und mit welchen Fallstricken muss man rechnen? In diesem Artikel werden Sie zunächst sehen, was In-Memory OLTP ist und warum eine solche neue Technologie für eine relationale Datenbank-Engine wie den SQL Server wichtig ist. Anschließend tauchen wir Schritt für Schritt in In-Memory OLTP ein und Sie lernen, wie Sie es gewinnbringend in Ihren eigenen Datenbanken einsetzen können oder auch nicht... Warum In-Memory OLTP? Als Erstes möchte ich Ihnen zeigen, warum eine solche neue Technologie im SQL Server notwendig ist und welches die Hintergründe sind. Relationale Datenbanken können aus verschiedenen Gründen ausgebremst werden: Langsames mechanisches Storage. SSD-Storage ist extrem teuer. CPU-Taktraten sind auf zirka 3 GHz beschränkt. Relationale Datenbanken skalieren nicht unendlich. Sehen wir uns die einzelnen Punkte genauer an. Wenn Sie Storage-Subsysteme im Einsatz haben, die traditionelle mechanische Festplatten nutzen, wissen Sie sehr gut, dass Ihre Performance katastrophal ist. Unsere CPUs sind über die Zeit immer schneller und schneller geworden, Hauptspeicher hat Latenzzeiten von Nanosekunden. Und dann werden unsere Daten auf Festplatten gespeichert, wo mechanisch ein Schreib-/Lesekopf bewegt werden muss und die einzelnen Platten rotieren die Latenzzeiten bewegen sich hier im Millisekundenbereich. Tausende Male langsamer als Zugriff auf den Hauptspeicher... Auf der anderen Seite spricht schon fast jeder über SSD-Storage-Systeme, die auf Flash-Technologie basieren und uns ohne mechanische Komponenten Latenzzeiten im Nanosekundenbereich versprechen. Der einzige Nachteil daran ist der eher hohe Preis. Wenn Sie einen Blick auf Hauptspeichermodule (RAM) werfen, kann damit die gleiche Performance zu einem niedrigeren Preis erzielt werden, als das mit SSDs möglich wäre. Darum ist es auch schon jetzt ganz wichtig, dem SQL Server so viel Hauptspeicher wie möglich zuzuweisen, damit so viele Daten wie möglich gecacht werden können. Können Sie sich noch an Ihre erste CPU erinnern? Bei mir war das ein Intel-486-DX2- Prozessor. Laut Moore's Law sollte sich die Zahl der Transistoren in Mikroprozessoren alle 18 bis 24 Monate verdoppeln. Die derzeit schnellsten Prozessoren (ohne Übertaktung) laufen bei zirka 3 GHz. Früher ging man davon aus, dass sich das immer weiter steigern lässt: 4, 5, 6, 7, 8 GHz und so weiter. Aber die Realität hat uns anderes gelehrt. Denn mit der Zahl der Transistoren nimmt auch die Entwicklung von Wärme zu, die nicht mehr effektiv abgeführt werden kann. Dadurch stehen wir jetzt bei etwa 3 GHz. Mehr geht nicht. Aber auch dieses Problem wurde seitens der Prozessorhersteller (Intel, AMD) fast gelöst: Statt über die Taktrate zu skalieren, wurden einfach mehrere Cores auf einem physischen CPU- Socket verbaut. Anwendungen, die Multithreading unterstützen, können dadurch weiterhin [Abb. 1] CPU-Taktraten skalieren nicht unbegrenzt [1]

2 Backend skalieren und eine enorme Performance liefern. In Abbildung 1 können Sie an der blauen Kurve sehr schön erkennen, dass die Taktraten von CPUs nicht bis ins Unendliche skalieren. Leider skalieren auch traditionelle relationale Datenbanken nicht bis ins Unendliche. Relationale Datenbanken wie der SQL Server basieren intern auf Konzepten, die bereits in den 70er Jahren erfunden wurden. Konzepte, die dem SQL Server hier im Weg stehen, sind das Locking, Blocking und Latching. Schauen wir uns das einmal genauer an. Mit Locking und Blocking sollte jeder vertraut sein, der mit dem SQL Server arbeitet. Damit parallele Transaktionen voneinander isoliert werden können (und somit korrekte Ergebnisse liefern), verwendet der SQL Server intern Locks. Ein Lock im SQL Server ist eine logische Sperre. Lesende Transaktionen (SELECT) fordern immer Shared Locks an, schreibende Transaktionen (INSERT, UPDATE, DELETE) fordern immer Exclusive Locks an. Und die beiden Locks sind inkompatibel, das heißt, lesende Transaktionen blockieren schreibende Transaktionen und umgekehrt. Dadurch entstehen sogenannte Blockaden, die den Durchsatz und somit die Performance der Datenbank minimieren. Abhilfe wurde hier zum Beispiel bereits mit dem SQL Server 2005 geschaffen, indem ein Optimistic Concurrency Model eingeführt wurde. Hier fordern lesende Transaktionen keine Shared Locks mehr an, sondern holen sich eine entsprechend alte gültige Version des betreffenden Datensatzes aus dem Version Store, der zentral in der TempDb gehalten wird. Schreibende Vorgänge müssen allerdings immer noch Exclusive Locks anfordern dies kann nicht beeinflusst werden. Neben den Locks auf Transaktionsebene muss der SQL Server intern auch den parallelen Zugriff auf gemeinsam genutzte Datenstrukturen zwischen unterschiedlichen Threads synchronisieren. Eine solche Datenstruktur ist zum Beispiel der Buffer Pool, in dem alle gelesenen Pages vom Storage zwischengespeichert werden. Wenn Sie schon einmal Multithreading- Anwendungen implementiert haben, werden Sie wissen, dass für die Thread-Synchronisierung unter anderem sogenannte Critical Sections eingesetzt werden. Eine Critical Section ist ein Codeblock, der zu einem gegebenen Zeitpunkt nur von einem einzigen Thread ausgeführt werden darf. Im SQL Server werden diese Critical Sections als Latches bezeichnet. Wenn ein Thread einen lesenden oder schreibenden Zugriff auf Pages im Buffer Pool durchführt, durchläuft dieser ebenfalls Critical Sections, da ansonsten sogenannte Race Conditions entstehen würden. Im Fachjargon des SQL Servers bezeichnet man diese Vorgehensweise als Latching einer Page: Bevor eine Page gelesen werden kann, muss sie mit einem Shared Latch gelatcht werden; bevor eine Page geschrieben werden kann, muss sie mit einem Exclusive Latch gelatcht werden. Daraus folgt, dass der Zugriff auf Pages im Buffer Pool serialisiert, also single-threaded erfolgt! Auch wenn Sie eine perfekte Indizierungsstrategie für Ihre Datenbank gefunden und den schnellsten Storage der Welt im Einsatz haben, werden Sie in Latching-Probleme im Hauptspeicher laufen, da auf gewisse Datenstrukturen kein Multi-threaded-Zugriff erlaubt ist. Ein altbekanntes Problem ist hier die sogenannte Last Page Insert Latch Contention : Sie kann in einem Clustered Index auftreten, wenn Sie einen fortlaufenden Wert wie eine INT IDENTITY-Spalte unter einer sehr hohen Nutzerlast verwenden. Aus alldem ist zu erkennen, dass aktuelle relationale Datenbanken nicht in alle Unendlichkeit skalieren. Wir benötigen daher eine Technologie mit den folgenden Eigenschaften, damit eine relationale Datenbank nahtlos skalieren kann: Daten werden ausschließlich im Hauptspeicher gehalten. Abfragen werden mit den geringstmöglichen CPU-Instructions abgearbeitet. Eliminierung von Locking, Blocking und Latching. Genau hier setzt In-Memory OLTP im SQL Server 2014 an. Diese neue Technologie baut auf drei Säulen auf: Memory Optimized Tables Native Compiled Stored Procedures Lock & Latch Free Data Structures Memory Optimized Tables Die erste der Säulen, auf denen In-Memory OLTP im SQL Server 2014 aufbaut, sind sogenannte Memory Optimized Tables (speicheroptimierte Tabellen). Im Unterschied zu den traditionellen Disk-Based Tables werden die Daten in den In-Memory Tables nur im Hauptspeicher gehalten und nicht in Datenfiles, die physisch im Storage liegen. Damit im Fehlerfall (zum Beispiel bei einem Absturz des SQL Servers) die Daten aus dem Hauptspeicher rekonstruiert werden können, werden periodisch sogenannte Checkpoint-Files geschrieben, die in einem sehr effizienten Format die Daten, die im Hauptspeicher gehalten werden, in einer FILESTREAM-Filegroup abspeichern. Wenn Sie eine Memory Optimized Table im SQL Server 2014 erzeugen, müssen Sie auch mindestens einen Hash -Index anlegen. Ein Hash-Index indiziert die Tabellendaten in einer Hash Table. Traditionelle Clustered und Non-Clustered Indizes werden von Memory Optimized Tables nicht unterstützt, da der intern verwendete B+-Baum auf das ineffiziente Latching angewiesen ist, dessen Probleme wir bereits betrachtet haben. In der finalen Version des SQL Server 2014 werden pro Memory Optimized Table bis zu acht Hash-Indizes unterstützt, weitere sind aktuell nicht vorgesehen. Ab der CTP2 des SQL Server 2014 werden auch sogenannte Range-Indizes unterstützt, die intern auf einem Bw-Baum aufbauen. Mehr dazu später. Memory Optimized Tables bieten Ihnen auch ein vollständiges neues Concurrency Model an, das auf den Prinzipien von Multi Version Concurrency Control (MVCC) aufbaut [2]. Traditionell werden ja beim Lesen und Schreiben von Daten entsprechende Locks angefordert. Beim Einsatz von Optimistic Concurrency, dem optimistischen Locking (ab SQL Server 2005, siehe oben) lässt sich beim Lesen die Vergabe von Shared Locks vermeiden, beim Schreiben der Daten müssen aber immer noch Exclusive Locks angefordert werden. Der Einsatz von MVCC ändert dies vollständig, da hier auch beim Schreiben von Daten keine Exclusive Locks mehr angefordert werden. Bei Datenveränderungen werden nämlich einfach neue Versionen erzeugt, die einen Begin- und End-Timestamp aufweisen. Lesende Transaktionen können dann sehr einfach aufgrund ihres aktuellen Timestamps die für sie gültige Version des Datensatzes zurückliefern. Ältere Versionen eines Datensatzes, die nicht mehr benötigt werden, entfernt später ein Garbage Collector. Damit Sie In-Memory OLTP überhaupt verwenden können, müssen Sie in Ihrer Datenbank im ersten Schritt eine FILE- STREAM-Dateigruppe anlegen, die In

3 Backend SQL Server 2014: Das ist neu, Teil 2 Listing 1 Anlegen einer In-Memory-OLTP- Filegroup. CREATE DATABASE TestDatabase GO ALTER DATABASE TestDatabase ADD FILEGROUP HekatonFileGroup CONTAINS MEMORY_OPTIMIZED_DATA GO USE TestDatabase GO ALTER DATABASE TestDatabase ADD FILE ( NAME = N'HekatonContainer', FILENAME = N'C:\Program Files\ Microsoft SQL Server\ MSSQL12.MSSQLSERVER\MSSQL\ DATA\HekatonContainer' ) TO FILEGROUP [HekatonFileGroup] GO Memory-OLTP-Daten beinhalten kann. Listing 1 zeigt, wie das funktioniert. Wie Sie erkennen können, handelt es sich bei einer In-Memory-OLTP-Filegroup um eine traditionelle FILESTREAM-Filegroup, deren Funktionalität bereits seit dem SQL Server 2008 zur Verfügung steht. Der einzige Unterschied ist, dass Sie hier die Eigenschaft CONTAINS MEMORY_OP- TIMIZED_DATA angeben müssen. Innerhalb der In-Memory-OLTP-Dateigruppe können Sie auch wie gewohnt mehrere FILESTREAM-Container angeben. Das ist zum Beispiel dann von Vorteil, wenn sich die Container auf unterschiedlichen Festplatten befinden: Das Recovery Ihrer Memory Optimized Tables kann beim Startup des SQL Servers dann parallelisiert von allen Containern gleichzeitig durchgeführt werden. Nachdem Sie die Vorbereitungen auf Datenbankebene nun abgeschlossen haben, können Sie im nächsten Schritt Ihre erste Memory Optimized Table anlegen (Listing 2). Um die Tabelle als Memory Optimized Table anzulegen, müssen Sie bei der WITH-Option nur die Eigenschaft MEMO- RY_OPTIMIZED angeben. Zusätzlich ist noch mindestens ein Hash-Index über die Syntax NONCLUSTERED HASH anzulegen. Auf die Eigenschaft BUCKET_COUNT werden wir später noch eingehen. Listing 2 Anlegen einer Memory Optimized Table. CREATE TABLE TestTable ( Col1 INT NOT NULL, Col2 VARCHAR(100) NOT NULL, Col3 VARCHAR(100) NOT NULL CONSTRAINT chk_primarykey PRIMARY KEY NONCLUSTERED HASH (Col1) WITH (BUCKET_ COUNT = 1024) ) WITH (MEMORY_OPTIMIZED = ON) GO Das Interessante ist, was nun im Hintergrund im SQL Server passiert, wenn Sie das CREATE TABLE-Statement ausführen. Der SQL Server erstellt nämlich für Ihre Memory Optimized Table eine eigenständige DLL-Datei, die in den Prozessraum des SQL Servers geladen wird! Im Detail passiert hier Folgendes: 1. Die Tabellen-Definition des T-SQL- Statements CREATE TABLE wird über mehrere Zwischenschritte in C-Code konvertiert. 2. Der C-Code wird über den C++-Compiler (cl.exe) und den Linker (link.exe) zu einer DLL kompiliert. 3. Die generierte DLL schließlich wird zur Laufzeit in den Prozessraum des SQL Servers geladen. Als Resultat wird der komplette Zugriff auf die speicheroptimierte Tabelle über nativ kompilierten Maschinencode durchgeführt und die begrenzt verfügbaren CPU-Zyklen (CPU-Taktraten skalieren nicht unendlich) dadurch so effektiv wie möglich ausgenutzt. Ein Nebeneffekt dabei: Es ist auch nicht mehr möglich, bei einer Memory Optimized Table zu einem späteren Zeitpunkt einen Index zu definieren. Sämtliche Indizes, Tabelleneigenschaften und Constraints müssen Sie direkt im T-SQL-Statement CREATE TABLE definieren, da dieser komplette Codeblock in einem Schritt zu einer DLL kompiliert wird. Den daraus resultierenden C-Code können Sie sich sogar ansehen. Er wird in einem Unterverzeichnis im Ordner C:\ Program Files\Microsoft SQL Server\MS- SQL12.MSSQLSERVER\MSSQL\DATA\xtp abgelegt. Die Zahl des Unterverzeichnisses stellt die entsprechende interne Datenbank-ID dar. Wenn Sie das T-SQL-Statement CREATE TABLE ausgeführt haben, sehen Sie auch in der Dynamic Management View sys.dm_os_loaded_modules, dass die daraus resultierende DLL in den Prozessraum des SQL Servers geladen wurde. Bei all diesen Vorteilen von speicheroptimierten Tabellen gibt es auch Nachteile, da in der finalen Version des SQL Server 2014 nicht sämtliche Funktionalitäten unterstützt werden, die Sie von unseren klassischen Disk-Based Tables kennen: Die Datensatzlänge ist auf 8 KByte limitiert. TRUNCATE TABLE und ALTER TABLE werden nicht unterstützt. Keine Unterstützung für Fremdschlüssel und LOB-Datentypen. Nicht alle Datentypen werden unterstützt. Nachdem Sie eine Memory Optimized Table angelegt haben, können Sie ganz normal Datensätze einfügen, aktualisieren und löschen. Mit dem großen Unterschied, dass sich alles im Hauptspeicher abspielt und Sie mit dem eigentlichen Datenfile nicht mehr interagieren (zum Beispiel im Rahmen des CHECKPOINT-Prozesses). Trotzdem interagiert In-Memory OLTP immer noch mit Ihrem Transaktionslog. Standardmäßig werden hier alle Datenveränderungen in Ihren Memory Optimized Tables mitprotokolliert, da diese für ein mögliches Crash Recovery Ihrer Datenbank benötigt werden. Der große Unterschied zu traditionellen Disk-Based Tables ist, dass hier nicht auf der Granularität der verschiedenen Indizes mitprotokolliert wird, sondern auf der Granularität der Tabelle. Wenn Sie zum Beispiel auf Ihrer Tabelle acht Hash- Indizes definiert haben und Sie fügen einen Datensatz in die Tabelle ein, wird diese Einfüge-Operation genau ein Mal im Transaktionslog mitprotokolliert. Bei traditionellen Tabellen hingegen wird für jeden Index (Clustered/Non-Clustered Index) separat im Transaktionslog mitgeschrieben. Das Transaktionslog lässt sich bei In-Memory OLTP daher um einiges effizienter schreiben und verwenden. Wenn Sie mit In-Memory OLTP den Flaschenhals des Transaktionslogs ebenfalls eliminieren möchten, bieten Ihnen Memory Optimized Tables die Möglichkeit, sogenannte Schema-only Tables zu definieren. Dadurch wird nur die Tabellendefinition selbst in der Datenbank persistiert (das Schema), aber nicht mehr die Daten. Daher müssen Datenverände

4 Backend Listing 3 Schema-only-Tabellen. CREATE TABLE Orders ( OrderID UNIQUEIDENTIFIER NOT NULL, CustomerID INT NOT NULL, ProductID INT NOT NULL, Quantity INT NOT NULL, Price DECIMAL(18, 2) NOT NULL CONSTRAINT chk_primarykey PRIMARY KEY NONCLUSTERED HASH (OrderID) WITH (BUCKET_COUNT = ) ) WITH ( MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY ) GO rungen auch nicht mehr im Transaktionsprotokoll mitgeschrieben werden. Der Nachteil? Sobald Sie Ihren SQL Server neu starten, haben Sie die kompletten Daten der Tabelle verloren und die Tabelle ist leer. Daraus folgt, dass diese Funktionalität nicht für alle denkbaren Szenarien geeignet ist. Sie eignet sich vorwiegend dann, wenn Sie die Daten in der Tabelle reproduzieren können. Denken Sie etwa an einen ETL-Prozess, der Ihr Data Warehouse jede Woche belädt. Die hier involvierten Staging-Tabellen könnten Sie ohne Probleme als Schema-only definieren, weil Sie im Fehlerfall die Daten einfach nochmals aus den Quellsystemen laden können. Listing 3 zeigt, wie Sie eine solche Tabelle erstellen. Sie geben hier bei der Eigenschaft DU- RABILITY einfach SCHEMA_ONLY an. Dadurch werden die Tabellendaten nur mehr im Hauptspeicher gehalten und zu keiner Zeit physisch in den Storage geschrieben. Wie bereits erwähnt, müssen Sie im Hinterkopf behalten, dass die Daten in der Tabelle verloren sind, sobald der SQL Server neu gestartet wird. Native Compiled Stored Procedures Eine weitere Säule von In-Memory OLTP im SQL Server 2014 sind die sogenannten Native Compiled Stored Procedures. Die Namensgebung lässt schon erahnen, welcher Tricks sich der SQL Server hier bedient: Ihre in T-SQL geschriebenen Stored Procedures (gespeicherten Prozeduren) werden zu nativem Maschinencode in Form einer C-DLL kompiliert, die wiederum zur Laufzeit in den Prozessraum des SQL Servers geladen wird. Die Kompilierung zu nativem Maschinencode bringt folgende Performance-Vorteile: T-SQL Stored Procedures werden nicht mehr während ihrer Ausführung interpretiert, sondern laufen mit nativem Maschinencode. Zusätzliche, teure CPU-Instructions durch die notwendigen C++-Virtual- Function-Calls eines traditionell ausgeführten Ausführungsplans können vermieden werden. Abbildung 2 zeigt, wie aus einer normalen in T-SQL geschriebenen Stored Procedure eine C-DLL generiert wird. Der genaue Ablauf der Generierung der C-DLL gestaltet sich wie folgt: 1. Im ersten Schritt wird ein normaler Execution Plan über den SQL Server Query Optimizer erzeugt. 2. Danach wird dieser Ausführungsplan in einen sogenannten Mixed Abstract Tree (MAT) konvertiert. 3. Unter Zuhilfenahme der Tabellen-Metadaten wird der MAT in einen Pure Imperative Tree (PIT) konvertiert. Hier werden zum Beispiel alle T-SQL-Datentypen in die C-Äquivalente transformiert. 4. Der PIT wird anschließend zu C-Code transformiert, der dann wiederum über den C-Compiler und den Linker zu einer DLL kompiliert wird. 5. Die generierte DLL wird in den Prozessraum des SQL Servers geladen. Wenn Sie anschließend Ihre Stored Procedure ausführen, wird nicht Ihre T-SQL [Abb. 2] Aus einer C-DLL wird eine T-SQL Stored Procedure [3]. Stored Procedure interpretiert, sondern Sie führen nativ kompilierten, performanten Maschinencode aus. Dadurch können die CPU-Zyklen so effektiv wie möglich ausgenutzt und die Performance gesteigert werden. Der generierte C-Code der Stored Procedure wird wiederum im Ordner C:\Program Files\Microsoft SQL Server\MSSQL12.MS- SQLSERVER\MSSQL\DATA\xtp abgelegt. Wenn Sie hier einen Blick in die generierte C-Datei werfen, werden Sie feststellen, dass Spaghetticode erzeugt wurde, der sehr viele goto-statements beinhaltet. Was nicht heißt, dass schlechter Code erzeugt wurde goto-statements wurden hier bewusst gewählt, weil sich die generierte C- DLL dadurch klein halten lässt. Aufrufe von gemeinsam genutzten Funktionen kosten entsprechende zusätzliche CPU-Instructions (der Callstack muss gepflegt, Rücksprung-Adressen müssen gespeichert werden et cetera), während ein goto-statement ein einziger Assembler- Befehl ist. Denken Sie also daran, wenn Sie das nächste Mal ein goto in Ihrem eigenen Code verwenden. Eine Native Compiled Stored Procedure wird bereits bei der Erstellung vollständig kompiliert. Das ist einer der großen Unterschiede zu traditionellen gespeicherten Prozeduren, die erst bei der ersten Ausführung kompiliert werden, wodurch der generierte Ausführungsplan für weitere Ausführungen im Plan Cache gecacht wird. Listing 4 zeigt, wie Sie eine Native Compiled Stored Procedure im SQL Server 2014 erstellen

5 Backend SQL Server 2014: Das ist neu, Teil 2 Listing 4 Native Compiled Stored Procedure. CREATE PROCEDURE HekatonProcedure INT ) WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER AS BEGIN ATOMIC WITH ( TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = 'us_english' ) INSERT INTO dbo.testtable (Col1, Col2, Col3) VALUES (@param, 'Klaus', 'Aschenbrenner') SELECT Col1, Col2, Col3 FROM dbo. TestTable END GO Sie müssen hier mit dem WITH-Schlüsselwort die Optionen SCHEMABINDING, EXECUTE AS und NATIVE_COMPILATION angeben. Zusätzlich müssen Sie noch einen Atomic-Block definieren, der den gewünschten Isolation Level und die Sprache angibt. Zu beachten ist hierbei, dass die Isolation Level von In-Memory OLTP nicht mit den traditionellen Isolation Leveln des SQL Servers gleichzusetzen sind. In-Memory OLTP unterstützt die Isolation Level SNAPSHOT, REPEATABLEREAD und SERIALIZABLE, wobei SNAPSHOT dem traditionellen Isolation Level Read Committed entspricht. Eine der größten Einschränkungen von Native Compiled Stored Procedures ist, dass Sie damit nur auf Memory Optimized Tables zugreifen können nicht aber auf normale Disk-Based Tables. Native Code kann nur mit Native Code zusammenarbeiten. Ebenso wenig wie bei Memory Optimized Tables können Sie die Implementierung der Stored Procedure durch ein ALTER PROCEDURE ändern, da dieser Befehl nicht unterstützt wird. Sie müssen daher die Native Compiled Stored Procedure löschen und anschließend über CREATE PROCEDURE neu anlegen. Da die Implementierung der T-SQL Stored Procedure zu einer C-DLL kompiliert wird, gibt es derzeit auch keine Möglichkeit, ein Recompile der Stored Procedure während der Laufzeit durchzuführen, wenn sich zum Beispiel die Statistiken geändert haben. Sie können also durchaus Native Compiled Stored Procedures laufen haben, die ineffektiv ausgeführt werden, weil sich in der Zwischenzeit die Datenverteilung in den Tabellen geändert hat. Dadurch ist der generierte C-Code nicht mehr der effektivste. Der einzige Ausweg ist hier ein DROP und anschließendes CREATE der Stored Procedure. Alles im allem gibt es hier noch sehr viele Einschränkungen und Fallstricke, die Sie für einen produktiven Einsatz im Vorfeld beachten und validieren müssen. Lock & Latch Free Data Structures Wie eingangs bereits erwähnt, können traditionell implementierte relationale Datenbanken wie der SQL Server nicht ohne Probleme skalieren, weil der Zugriff auf gemeinsam genutzte Datenstrukturen im Hauptspeicher serialisiert zwischen verschiedenen Threads ausgeführt werden muss. Dieses Problem nennt sich im SQL Server Latch Contention und kann unter sehr hoher Nutzerlast auftreten. Aus diesem Grund gibt es in der Multithreaded-Programmierung den Ansatz der sogenannten Wait & Lock Free Algorithm & Data Structures [4]. Dabei handelt es sich um Programmierprinzipien, die ohne den Einsatz von Critical Sections eine sichere Multithreading-Programmierung erlauben unter Einsatz von Atomic CAS Operations (Atomic Compare-and-Swap Operations) [5]. Auf genau solchen Prinzipien und Datenstrukturen setzt auch In-Memory OLTP im SQL Server 2014 auf. Im Speziellen verwendet hier der SQL Server Hash-Indizes und Range-Indizes für die Datenspeicherung in Memory Optimized Tables. Ein Hash-Index basiert intern auf einer Hash Table; ein Range-Index ist intern über einen Bw-Tree implementiert. Beide Datenstrukturen sind Lock- und Latch-frei; das heißt, sie können für Multithreaded-Anwendungen ohne Critical Sections implementiert werden. Der Bw- Tree verwendet zusätzlich noch Atomic- CAS-Operationen, um Änderungen in der Baumstruktur threadsicher ohne den Einsatz von Latches zu ermöglichen. Sehen wir uns den Hash-Index näher an. Wie schon erwähnt speichert ein Hash-Index die Daten in einer Hash Table ab. Der Zugriff auf die Hash Table kann wiederum ohne Latches erfolgen, wodurch eine hohe Skalierbarkeit erreichbar ist. Wie Sie in Listing 2 gesehen haben, müssen Sie bei der Erstellung eines Hash- Index einen Bucket Count angeben. Intern ist eine Hash Table in sogenannte Hash Buckets unterteilt und der Bucket Count gibt an, wie viele Hash Buckets erzeugt werden sollen. Der Inhalt der Tabellenspalten, wo Sie den Hash-Index definiert haben, wird über eine sogenannte Hash-Funktion gleichmäßig zwischen den verschiedenen Hash Buckets verteilt. Nehmen wir an, wir haben einen Hash-Index auf einer Spalte Last- Name definiert und der SQL Server verwendet eine Hash-Funktion, die aufgrund des ersten Buchstabens definiert, in welches Hash Bucket der entsprechende Datensatz abgespeichert wird. In diesem Fall werden unsere Datensätze über 26 verschiedene Hash Buckets verteilt (A bis Z). Tatsächlich verwendet der SQL Server eine komplexere Hash-Funktion, die auch gewährleistet, dass die Daten zwischen den verschiedenen Hash Buckets gleichmäßig aufgeteilt werden. Welche Hash- Funktionen hier verwendet werden, ist undokumentiert. Natürlich kann es vorkommen, dass Datensätze aufgrund der Spaltenwerte in gleiche Hash Buckets gemappt werden (mehrere Namen, die mit dem gleichen Buchstaben beginnen). Wir sprechen von einer Hash Collision. Bei einer Hash Collision [Abb. 3] Clustered Index: Hotspot durch Latching im Hauptspeicher

6 web & mobile DEVELOPER präsentieren: Trends Lösungen Know-How Unsere Leser sparen 149, mit Code DWX14dnp Juli 2014 NCC Ost, Nürnberg DDC.NET Developer nce MDC Mobile Developer nce WDC Web Developer nce 3-Tages-Konferenz 250 Vorträge 40 Thementracks Networking auf Abendveranstaltungen Top-Referenten über 150 Experten aus den Themenbereichen Web-, Mobile- und.net-entwicklung 10 parallele Workshops am 17. Juli 2014 Ganztägig Vertiefend Fachausstellung mehr als 40 Partner präsentieren sich in der begleitenden Fachausstellung vom Juli DeveloperWeek Aussteller & Sponsoren:

7 Programm Developer Week 2014 Tag 1: Montag, 14. Juli 2014 Architektur Visual Studio Webentwicklung Azure ALM Begrüßung Eröffnungs-Keynote Kaffeepause Design Patterns sind Naturgesetze, Thomas Mentzel VisualStudio Ein Überblick, David Tielke Die Architektur der ASP.NET Web API, Marius Schulz Einführung in die Windows Azure Plattform, Sascha Dittmann Continuous Delivery und Deployment in der Praxis, Martin Aschoff Raumwechsel Architecting the Cloud, Robert Eichenseer Rapid Application Development Nur Spielerei? Constantin Klein OWIN der Microsoft Web Stack erfindet sich neu, Robert Mühsig Datenbackends in der Cloud und deren Integration, Peter Kirchner Erfolgreiche Rewrites, Johann-Peter Hartmann Mittagspause Von den Anforderungen zur Architektur: Leitfaden für einen guten Softwareentwurf 7 Jahre Visual Studio TFS Tipps & Ausblick, Neno Loje Enterprise-Webanwendungen mit Ext JS / EXT.NET, Johannes Hoppe Raumwechsel Flexible verteilte Anwendungen mit Micro-Service, Mike Bild Visual Studio 2013 Produktiver werden, David Tielke Real Time Anbindung an SAP ERP, Rainer Barthels, Otto Neff Debugging im Zeichen der Cloud, Robert Eichenseer Connected Web, Damir Dobric Triple-E class Continuous Delivery, Werner Keil ALM konkret, Sebastian Rölz Kaffeepause Schnee von gestern Was ist ein Event Store? Jan Fellien Visual Studio Online IDE, Patrick Boscolo Eine moderne RESTful basierte Web-Anwendung, Marc André Zhou Was ist neu in Windows Azure Mobile Services? Damir Dobric Sourcingstrategien für nationale und internationale Projekte, Reiner Hörger Raumwechsel Weißbuch der Architektur- Dokumentation, Stefan Zörner Testmanagement mit Visual Studio 2013, Nico Orschel Webanwendungen in Minuten hochskalierbar bereitstellen, Peter Kirchner Mobile Games mit Windows Azure, Jürgen Gutsch Zentrales Build & Release Management, Thomas Rümmler, Christian Schlag ab Abendveranstaltung

8 Ausführliches Programm, alle Abstracts, Referenten und die Anmeldung online unter: developer-week.de JavaScript Webarchitekturen Web-Frameworks Android ios Begrüßung Eröffnungs-Keynote Code-Qualität trotz JavaScript, Niko Köbler, Heiko Spindler Das Märchen vom agilen Architekten, Stefan Zörner Kaffeepause SinglePageApplications mit Ember.js, Christian Ringler, Robert Rieger Integration von Google+ in ios- und Android-Apps, Peter Friese CoreBluetooth in ios 7, Tammo Freese JavaScript Debugging und Profiling, Sebastian Springer REST und RESTful HTTP: Was es ist und was nicht, Stefan Tilkov Raumwechsel Datenvisualisierung, Martin Walter Android Builds automatisieren, Janusz Leidgens ibeacons allüberall und in der Praxis, Ivo Wessel JavaScript für.net-entwickler, Tilman Börner, Golo Roden Prinzipien für skalierbare Architekturen, Sven Günther, Andreas Havenstein Mittagspause Tools und Tipps für den modernen Frontend-Workflow, Sven Wolfermann Testing mit Robolectric und FEST in Android Studio, Onur Güngören ios meets Arduino Electronics prototyping mit ios, Jens Meder Überlebenswichtig: Die wichtigsten Frameworks für JavaScript Autos verkaufen mit CQRS und Event Sourcing, Marco Stechl, Philipp Garbe Raumwechsel Web Services mit Symfony2, Paul Seiffert Bildbearbeitung für ios und Android mit OpenCV, Uwe Frieser Modular ios-apps Piet Brauer Meteor JS Eine flexible JavaScript Plattform, Niko Köbler, Heiko Spindler Offline-Architekturen für mobile Endgeräte, Christian Pöcher Kaffeepause A Better CSS: LESS is More Oberflächendesign für Android Apps Automatisiertes Testing mit ios, Felix Schulze Mit Angular.js schnell zur Single Page Application High performance websites, Stefan Priebsch Arne Blankerts Raumwechsel Twig Eine PHP Template Engine, Timo Haberkern Modularer Android Code mit Dagger, Onur Güngören Der einzig wahre Objective-C Stil, Tammo Freese Abendveranstaltung ab Programmänderung vorbehalten

9 Programm Developer Week 2014 Tag 2: Dienstag, 15. Juli 2014 Architektur- Praxis.NET-Praxis Next.NET Daten Trends Das Event im Mittelpunkt: EDA und CEP, Tobias Richling Standardsoftware Wege aus dem Verwaltungschaos, Boris Wehrle LoB Windows 8 Apps, Lars Heinrich MapReduce in der Praxis, Sascha Dittmann Kommunikation im Internet der Dinge mit MQTT, Christian Götz Kaffeepause Extreme Domain Modelling, Dennis Traub Code Reviews Jeder kennts, keiner machts, Boris Wehrle Erstellung einer prototypischen Windows 8.1 App, Peggy Reuter-Heinrich, Lars Heinrich Professionelle Datenbankentwicklung mit den SSDT, Constantin Klein Internet der Dinge mit Webtechnologien, Timo Haberkern Raumwechsel Die mystische CRUD-3-Schichten- Applikation, Tobias Richling Prototyping und Entwicklung mit dem SharePoint Designer, Alexander Tews Cross-Plattform Entwicklung mit C#, Christian Lang, Loek van den Ouweland Herausforderungen im Datenzeitalter, Constantin Klein Wearable Android Developing for Google Glass, Sebastian Kaspari Mittagspause SeekYouRS Happy Path CQRS Framework, Jan Fellien CodedUI in der Praxis: Lokalisierung bis Nachhaltigkeit, Nico Orschel Roslyn Compiler as a Service, Christoph Wille Twitter insights mit StreamInsight und HDinsight, Olivia Klose, Patric Boscolo 3D-Druck für Entwickler Raumwechsel Architecting.NET Solutions for the Enterprise, Dino Esposito OAuth2 und OpenID Connect, Daniel Basler, André Meier Basics of hardware programming in.net, Marcin Kawalerowicz Entkopplung und Datenqualität in Datenbanken, Thomas Worm Raspberry Pi für Entwickler Kaffeepause Gießen beliebiger Datenstrukturen mit Events, Ralf Westphal Reactive Extensions, Mike Bild Libs, ohne die ich nicht mehr programmieren will, Timothée Bourguignon Anwendungsfälle für Elasticsearch, Florian Hopf Smartwatch Hacking, Robert Virkus Raumwechsel Softwareentwurf Live, Ralf Westphal Usability praktisch, Bernhard Pichler Tasks Wie funktionieren die? Bernd Marquardt Entity Framework 6.x Erweiterungsmöglichkeiten ausloten, Thomas Haug Spaß und Freude mit Kinect, Tam Hanna ab Abendveranstaltung

10 Ausführliches Programm, alle Abstracts, Referenten und die Anmeldung online unter: developer-week.de Node.js Datenbanken / Datenzugriff Responsive Webdesign Cross-Plattform Mobile Praxis Node.js-Anwendungen mit Visual Studio, Peter Hecker Wie halte ich meine Daten synchron? Responsive Webdesign Status Quo, Roberto Bez Vermeiden der Top 10 Entwicklungsfehler, Thomas Gronbach App Marketing: Nobody loves my App, Gregor Biswanger, Alexander Witkowski Kaffeepause Building libraries using Coffee Script, Node.js, Thorsten Hans ArangoDB A different approach to NoSQL, Lucas Dohmen Responsive Webdesign verkaufen, Patrick Lobacher jquery Mobile Web- App an SAP ERP anbinden, Philipp Friberg Lessons Learned: Building a Mobile CRM, Patrick Blitz Raumwechsel Leistungssteigernde Maßnahmen: Streams, Golo Roden Datenbankentwicklung für Webentwickler Fiese Fallstricke und sexy Strategien, Johannes Weber Plattformübergreifende App Usability, Thorsten Stark, Michal Gralak Mobile Testing, Felix Schulze Mittagspause Richtig arbeiten mit npm Entkopplung und Datenqualität in Datenbanken, Thomas Worm Responsive Design mit Bootstrap, Gregor Biswanger Firefox OS A (mobile) Web Developer s dream, Carsten Sandtner Smartere Web-Apps entwickeln, Dr. Michael Nolting Raumwechsel Node.js für Webapplikationen, Sebastian Springer Event Sourcing in der Praxis, Benjamin Reitzammer, Johannes Seitz Responsive Webdesign testen/debuggen, Sven Wolfermann Qualität und Sicherheit aus der Cloud, Peter Bruhn, Richard Süselbeck Cross-Platform Levels, Udo Trappe Kaffeepause Node.js versus.net Teil 1, Jürgen Gutsch, Golo Roden Worauf kommt es beim Design von Datenbanken an? Neue Techniken für Responsive Design Native multiplattform Apps mit Enterprise Scope, Martin Wieschollek, Christopher Klewes Apache Cordova und Frameworks für hybride Apps, Johannes Hoppe Raumwechsel Node.js versus.net Teil 2, Jürgen Gutsch, Golo Roden Skalieren mit Amazon Web Services Anbindung an das CMS Cross-Plattform- Entwicklung mit XAMARIN und.net, Sebastian Seidel Copyright für Developer, Claus Volke Abendveranstaltung ab Programmänderung vorbehalten

11 Programm Developer Week 2014 Tag 3: Mittwoch, 16. Juli 2014.NET-Tools Craftsmanship Desktop Sprachen Codeanalyse Marke Eigenbau, Thomas Haug Clean Code Code als kleinster gemeinsamer Nenner, Ilias Foukis WPF UI Development Unchained, David C.Thömmes, André Lanninger C# Dynamics in freier Wildbahn, Timothée Bourguignon Vorgehensmodelle Produktentwicklung für die intelligente Gebäudetechnik, Urs Boehm Kaffeepause Päckchen packen mit NuGet, Thomas Schissler ATDD Der Weg zur lebenden Dokumentation, Hendrik Lösch WPF Deep Data Binding, Bernd Marquardt Hitchhiker s Guide to Functional Programming, Sergey Shishkin, Steffen Forkmann Srum, Kanban oder doch beides? Ilias Foukis Raumwechsel Code Generierung mit.net, Philip Jander The Black Art of GUI Testing, Christoph Thelen Missverständnisse bei der WPF Look & Feel Entwicklung, Alexander Keller F# im Web und auf dem Client, Carsten König Agiles Vorgehen in traditionellen Projekten, Steve Graegert Mittagspause FAKE: Echt starkes Build für.net, mit.net, Philip Jander Mit agilen Praktiken SOLIDe Systeme bauen, Sven Günther Building Rich Media Apps, Robert Eichenseer Die JavaScript Engine V8 in.net- Anwendungen nutzen, Torsten Zimmerman Football, Poker, PM oder: Wir führen Srum ein! Marcus Jacob Raumwechsel Unit Testing und Mocking mit Microsoft FAKE, Christian Jacob SOLIDe Prinzipien des objektorientierten Entwurfs, Dennis Traub Die eigene App mit dem Cloud AD verbinden, Robert Mühsig Monaden durch Beispiele begreifen, Carsten König Definition of almost done, Dominik Jungowski Kaffeepause Installer bauen leicht gemacht, Marcus Jacob Qualitätsmanagement für kleine und mittlere Unternehmen, Matthis Radke Win 8.1 Apps mit Hardware verbinden, Alexander Witkowski Noch eine!? Eine neue Hochsprache für JVM und CLR, Michael Wiedeking Best Practices für globale Scrum Teams, Jürgen Toth Abschlusskeynote

12 Ausführliches Programm, alle Abstracts, Referenten und die Anmeldung online unter: developer-week.de Softskills Websprachen Schnittstellen Windows Phone Mobile-Tools Überleben im Projektdschungel als Softwareentwickler, Dr. Christian Heiss Das streichzarte Web, Paul Bakaus HTML5 Video: Curing plugin maladies since 2007, Matthew George McClure Windows Phone und Windows App- Entwicklung, Daniel Meixner Mit Touch Develop in die Zukunft, Christian Jacob Kaffeepause Verhaltensmuster in der IT-Systementwicklung, Chris Rupp, Ulrike Friedrich TestDriven Development.php, Dominik Jungowski, Jakob Ketterl Frontend First Development, Mike Bild Windows Phone <3 Unternehmen, Patrick Boscolo, Bernd Mayer Phone Gap and other hybrid tools for mobile development, Dino Esposito Raumwechsel Abenteuer Recruitment, Julia Schüller Endlich neue Software, Martin Ruprecht Maintain your Environment with Puppet, Hans-Christian Otto Vier Stores für eine App: Entwicklung in 60 Minuten, Jan Schweda, Marco Richardson Mobiles E-Learning mit Moodle, Thomas Kraehe, Tobias Hauser Mittagspause Führungskompetenz Teamentwicklung Julia Schüller TYPO3 Neos Next Generation CMS, Patrick Lobacher Mobile Security: Death to passwords, Tim Messerschmidt Vier Stores für eine App: Deployment, Marco Richardson, Jan Schweda Der internationale Markt: Lokalisierung von Apps, Daniel Schneller Raumwechsel Vom Entwickler zur Führungskraft, Johann-Peter Hartmann Lieber generieren als implementieren Shops integrieren Cross-Platform Mobile mit C#, Kerry W. Lothrop Vorgehen für die Tablet-App- Entwicklung, Patrick Blitz, Sonja Harrer Kaffeepause Das Zen des Rasenmähens, Marco Klawonn Neue Techniken für Webprojekte einsetzen, Peter Kröner Produktionsdaten anbinden Multi Platform Game Development mit Unity, Dariusz Parys TFS & Java Ein SDK, das Türen öffnet Denny Israel, Thomas Wilk Abschlusskeynote Programmänderung vorbehalten

13 Programm Developer Week 2014 Tag 4: Donnerstag, 17. Juli 2014 Workshops, Uhr Test Driven Development in der Praxis Workshop 1 Workshopleiter: Hendrik Lösch TDD Dieses unvergleichlich tolle Vorgehen, das Architekturen vereinfacht, die Produktivität steigert und dabei den Spaß an der Entwicklung fördert. Versucht man es dann jedoch in der Praxis einzusetzen, ergibt sich nicht selten Ernüchterung. Aus diesem Grund geht dieser Workshop näher auf die Hintergründe von TDD und agiler Softwareentwicklung ein. Nach einer kurzen Einführungs ins Thema zeigt er unterschiedliche Ausprägungen des Vorgehens, deren Vor- und Nachteile sowie die Praxistauglichkeit. Ziel des Workshops ist es, dass Sie am Ende selbst entscheiden können, wie viel TDD wirklich gut für Ihr Projekt ist. DDC.NET De Eventsourcing: Blackbox im Eigenbau Workshop 2 Workshopleiter: Ralf Westphal Statt nur den Zustand eines Datums festzuhalten, erfasst das Eventsourcing jede Veränderung. Damit ist eine Historie schon eingebaut und eine Undo-Funktion eine Sache von wenigen Zeilen Code. Im Workshop entsteht eine Blackbox, die Daten aufnimmt. Zwei Apps greifen dann auf diese zu. DDC.NET De MVVM Eine Einführung Workshop 3 Workshopleiter: Bernd Marquardt MVVM das ist ein Begriff, den jeder Entwickler einer Benutzerschnittstelle schon einmal benutzt hat. In diesem Workshop lernen Sie an mehreren Bespielen Schritt für Schritt die Grundlagen einer MVVM- Anwendung mit WPF kennen. Nach einer Einführung (DataBinding, INotifyChanged, DataTemplates, ObservableCollection,...) wird das MVVM-Pattern in verschiedenen Ausprägungen besprochen. Hierzu gehören auch Dialoge, Nebenläufigkeit, Parameterübergabe, Unit-Tests usw. DDC.NET De Neue Techniken für Responsive Design Workshop 4 Workshopleiter: Peter Kröner Dass es neben Desktop-PCs auch allerlei Mobilgeräte mit speziellen Designanforderungen gibt, hat sich mittlerweile herumgesprochen. Ebenso ist bekannt, dass sich RWD verschiedenen Formfaktoren automatisch anpasst. Noch nicht so bekannt sind die neuesten Techniken, mit denen man einen Responsive-Design-Workflow heutzutage unterstützen kann. Neue CSS3-Layout-Module lassen komplexe, flexible Layouts zum Kinderspiel werden. In diesem Workshop lernen Sie diese und viele andere Techniken rund um Responsive Design kennen, die über den einfachen Einsatz von Media Queries hinausgehen. MDC Mobile

14 Ausführliches Programm, alle Abstracts, Referenten und die Anmeldung online unter: developer-week.de Backend, Website und App in einem Tag Workshop 5 Workshopleiter: Dr. Lutz Kohl / Philipp Michel Am Beispiel eines Spiels wird im Rahmen des Workshops ein kompletter App/Website Entwicklungsprozess abgearbeitet. Nach einer Schilderung des Problems werden Screens designt. Basierend auf den abzubildenden Daten wird ein objektorientiertes Datenmodell erstellt und unter Verwendung von Backend as a Service umgesetzt. Im Anschluss werden eine Android-App und eine Website (HTML und Javascript) erstellt, die mittels SDKs auf die Daten des Backends zugreifen. MDC Mobile D Enterprise-Webanwendungen mit Ext JS / EXT.NET Workshop 6 Workshopleiter: Johannes Hoppe Lernen Sie im Workshop das universelle Framework Ext JS, den.net Wrapper EXT.NET und die konsequente Umsetzung bekannter Patterns im Ext JS Core kennen. Sehen Sie, wie man mit über 100 Komponenten eine stringente Oberfläche gestalten kann. Im Detail werden die flexible Client-Server Kommunikation über "Proxys" & "Stores", die Möglichkeiten zum Theming und Layout- Management sowie die Entwicklung eigener Plugins und Komponenten behandelt. Es wird ASP.NET MVC, Razor und das Framework EXT.NET, welches Ext JS als Nuget-Paket zur Verfügung stellt, verwendet. WDC Web De High performance websites Workshop 7 Workshopleiter: Stefan Priebsch / Arne Blankerts Kurze Antwortzeiten sind im Web das Wichtigste. Aber was tun, wenn die Performance nicht ausreicht? Mehr und leistungsfähige Hardware kaufen? In die Cloud migrieren? Eine weitere Cache-Schicht einführen oder die Schuld auf die überforderte Datenbank schieben? Es lohnt sich, zuerst die Software-Architektur anzusehen! Im Workshop lernen die Teilnehmer, wie eine hoch-performante Software- und System-Architektur aussehen kann, mit der man vom einzelnen Server bis in die Cloud problemlos skalieren kann. WDC Web De Introduction to Symfony2 Workshop 8 Workshopleiter: Andreas Hucks Die Teilnehmer lernen die Grundlagen von Symfony kennen, um in der Folge ihre ersten eigenen Anwendungen mit dem Framework entwickeln zu können. An einem Tag bieten wir einen Rundgang durch alle gängigen Features, von der Installation und Konfiguration zur Abarbeitung eines Requests. Wir stellen Routing und Templating vor und definieren erste eigene Formulare. Voraussetzungen: Dies ist ein Workshop für Einsteiger in Symfony. Es sind keine Vorkenntnisse im Framework selbst erforderlich. Allerdings sollten die Teilnehmer solide Grundkenntnisse im objektorientierten Arbeiten mit PHP mitbringen. WDC Web De Effektive Kommunikation: Praxis-Workshop Workshop 9 Workshopleiterin: Solveig Grundler Warum versteht mich keiner? Warum hört mir keiner zu? der Praxis-Workshop Effektive Kommunikation geht diesen Fragen auf den Grund und beantwortet vor allem auch die dritte: Wie kann ich das ändern?. Im Zentrum des interaktiv aufgebauten Workshops steht dabei nicht der reine Wissenstransfer zum Thema Konfliktkompetenz sondern die Möglichkeit anhand alltagsbezogener Übungen das Handwerkszeug konstruktiver Kommunikation auszuprobieren und zu üben. DDC MDC WDC.NET De Mobile Web De

15 Sichern Sie sich Ihr Ticket online unter: developer-week.de Kombi-Ticket DWX & Workshop Juli 2014 Ticketpreis 1.650, zzgl. MwSt. (statt 1.799, zzgl. MwSt.) 2-Tages-Ticket 14. / od. 15. / Ticketpreis 750, zzgl. MwSt. (statt 899, zzgl. MwSt.) Unsere Leser sparen 149, mit Code DWX14dnp 3-Tages-Ticket Juli 2014 Ticketpreis 1.150, zzgl. MwSt. (statt 1.299, zzgl. MwSt.) 1-Tages-Ticket , od Ticketpreis 550, zzgl. MwSt. (statt 699, zzgl. MwSt.) Workshop-Ticket Ticketpreis 550, zzgl. MwSt. (statt 699, zzgl. MwSt.) Die Referenten der Developer Week: Aschoff, Martin, AGNITAS AG Barthels, Rainer, NovaTec GmbH Bakaus, Paul, Google Germany GmbH Basler, Daniel, deltra Business Software GmbH & Co. KG Bez, Roberto Bild, Mike Biswanger, Gregor, CleverSocial.de Blankerts, Arne, The PHP Consulting Company Blitz, Patrick, Weptun GmbH Boehm, Urs, Noser Engineering AG Börner, Tilman, Neue Mediengesellschaft Ulm mbh Boscolo, Patric, Microsoft Deutschland GmbH Bourguignon, Timothée, Mathema Software GmbH Brauer, Piet, Xing AG Bruhn, Peter, Deutsche Telekom AG Dittmann, Sascha, Ernst & Young GmbH Dobric, Damir, DAENET GmbH Dohmen, Lucas, triagens GmbH Eichenseer, Robert, Microsoft Deutschland GmbH Esposito, Dino, JetBrains s.r.o Fellien, Jan, devcrowd GmbH Forkmann, Steffen, msu solutions GmbH Foukis, Ilias, AutoScout24 GmbH Freese, Tammo, FlockOfBirds UG (haftungsbeschränkt) Friberg, Philipp, itelligence Schweiz AG Friedrich, Ulrike, SOPHIST GmbH Friese, Peter, Google UK Frieser, Uwe, adorsys GmbH & Co. KG Garbe, Philipp, AutoScout24 GmbH Götz, Christian, dc-square GmbH Graegert, Steve, Ciber AG Gralak, Michal, schöngeist UG (haftungsbeschränkt) Gronbach, Thomas, Keynote Europe Ltd. Grundler, Solveig, mediation-moderation.de Güngören, Onur, schöngeist UG (haftungsbeschränkt) Günther, Sven, It-agile GmbH Hamburg Gutsch, Jürgen, YooApplications AG Haberkern, Timo, Kaufland Informationssysteme GmbH & KG. Hanna, Tam, Tamoggemon Holding k.s. Hans, Thorsten, ExpertsInside GmbH, Harrer, Sonja, Weptun GmbH Hartmann, Johann-Peter, Mayflower GmbH Haug, Thomas, Mathema Software GmbH Hauser, Tobias, Arrabiata Solutions GmbH Havenstein, Andreas, It-agile GmbH Hamburg Hecker, Peter, GFU Cyrus AG Heinrich, Lars, Heinrich & Reuter Solutions GmbH Heiss, Dr. Christian, Performance Entwicklung Hörger, Reiner, Pentalog Deutschland GmbH Hopf, Florian Hoppe, Johannes, HAUS HOPPE - IST Hucks, Andreas, SensioLabs Deutschland Israel, Denny, Saxonia Systems AG Jacob, Christian, TOP TECHNOLOGIES CONSULTING GmbH Jacob, Marcus, TOP TECHNOLOGIES CONSULTING GmbH Jander, Philip, Jander IT Jungowski, Dominik, inovex GmbH Kaspari, Sebastian, Quartett mobile GmbH Kawalerowicz, Marcin, CODEFUSION Sp. z o.o. Keil, Werner, Creative Arts & Technologies Keller, Alexander, Centigrade GmbH Ketterl, Jakob Kirchner, Peter, Microsoft Deutschland GmbH Klawonn, Marco, Portaltech Reply GmbH Klein, Constantin, Freudenberg Forschungsdienste SE & Co. KG Klewes, Christopher, QuinScape GmbH Klose, Olivia, Microsoft Deutschland GmbH Köbler, Niko, Niko Köbler IT-Beratung Kohl, Dr. Lutz, Apinauten GmbH König, Carsten, Wiegand-Glas GmbH Kraehe, Thomas, Arrabiata Solutions GmbH Kröner, Peter, Brainfire Design Lanninger, André, Ergosign GmbH Lang, Christian, 6 Wunderkinder GmbH Leidgens, Janusz, Kupferwerk GmbH community experts Lobacher, Patrick, lobacher.de Loje, Neno, Ingo Rammer und Christian Weyer GBR Lösch, Hendrik, Saxonia Systems AG Lothrop, Kerry W., Zühlke Engineering GmbH Marquardt, Bernd, Mayer, Bernd, Microsoft Deutschland GmbH McClure, Matthew George, Brightcove Inc. Meder, Jens Meier, André Meixner, Daniel, Microsoft Deutschland GmbH Mentzel, Thomas, CGI (Germany) GmbH & Co. KG Messerschmidt, Tim, PayPal (Europe) S.à r.l. et Cie, S.C.A. Michel, Philipp, Apinauten GmbH Mühsig, Robert, OneOffixx AG Neff, Otto, NovaTec GmbH Nolting, Dr. Michael, Toughenough Orschel, Nico, AIT GmbH & Co. KG Otto, Hans-Christian, crosscan GmbH Parys, Dariusz, Microsoft Deutschland GmbH Pichler, Bernhard, Informare Consulting GmbH Pöcher, Christian, QuinScape GmbH Priebsch, Stefan, The PHP Consulting Company Radke, Matthis, ma design GmbH & Co. KG Reitzammer, Benjamin, Vaamo Finanz AG Reuter-Heinrich, Peggy, Heinrich & Reuter Solutions GmbH Richardson, Marco, conplement AG Richling, Tobias, meta-objects.net IT Solutions GmbH Rieger, Robert, GfK Retail & Technology GmbH Ringler, Christian, GfK Retail & Technology GmbH Roden, Golo, the native web UG (haftungsbeschränkt) Rölz, Sebastian, conplement AG Rümmler, Thomas, AIT GmbH & Co. KG Rupp, Chris, SOPHIST GmbH Ruprecht, Martin, Mayflower GmbH Sandtner, Carsten, Mediaman GmbH Schissler, Thomas, artiso AG Schlag, Christian, AIT GmbH & Co. KG Schneller, Daniel, CenterDevice GmbH Schüller, Julia, Triumph International AG Schulz, Marius, 69 Grad GmbH Schulze, Felix, AutoScout24 GmbH Schweda, Jan, conplement AG Seidel, Sebastian, Cayas Software Seiffert, Paul, SensioLabs Deutschland GmbH Seitz, Johannes, Vaamo Finanz AG Shishkin, Sergey, shishkin.org Spindler, Heiko Springer, Sebastian, Mayflower GmbH Stark, Thorsten, Beuth Hochschule für Technik Berlin Stechl, Marco, Autoscout24 GmbH Süselbeck, Richard, Deutsche Telekom AG Tews, Alexander, Ciber AG Thelen, Christoph, Technische Hochschule Mittelhessen Thömmes, David C., Ergosign GmbH Tielke, David, david-tielke.de Tilkov, Sebastian, innoq Deutschland GmbH Toth, Jürgen, Novartis Pharma AG Trappe, Udo, oput GmbH Traub, Dennis, Holisticon AG van den Ouweland, Loek, 6 Wunderkinder GmbH Virkus, Robert, Enough Software GmbH & Co.KG Volke, Claus, volke2.0 Intellectual Property and Information Technology Walter, Martin, Deutsche Welle Weber, Johannes, Mayflower GmbH Wehrle, Boris, AIT GmbH & Co. KG Wessel, Ivo, icodecompany Westphal, Ralf, One Man Think Tank Wiedeking, Michael, MATHEMA Software GmbH Wieschollek, Martin, QuinScape GmbH Wille, Christoph Wilk, Thomas, Saxonia Systems AG Witkowski, Alexander, Heinrich & Reuter Solutions GmbH Wolfermann, Sven, maddesigns Wondratschek, Ralf, adorsys GmbH & Co. KG Worm, Thomas, DATEV eg Zhou, Marc André, dev-sky.net Zimmermann, Torsten Zörner, Stefan, embarc Software Consulting GmbH Kooperationspartner (Stand: ): Veranstalter:

16 Backend [Abb. 4] Durchsatz eines SQL Servers unter Einsatz von In-Memory OLTP. wird in einem Hash Bucket mehr als ein Datensatz abgespeichert. Intern wird hier eine entsprechende Linked List angelegt. Da In-Memory OLTP auf MVCC basiert, müssen Sie auch berücksichtigen, dass bei Datensatzänderungen neue Versionen ebenfalls im gleichen Hash Bucket abgelegt werden. Hash Collisions sind extrem teuer hinsichtlich der benötigten CPU-Instructions. Und mit In-Memory OLTP sollen ja CPU- Instructions eingespart werden. Daraus folgt, dass Hash Collisions so weit wie möglich in einem Hash-Index vermieden werden. Aus diesem Grund ist es auch sehr wichtig, sich genaue Gedanken über den Bucket Count eines Hash-Index zu machen. Als Empfehlung sollten Sie hier mindestens die Anzahl der eindeutigen Werte in der Schlüsselspalte des Hash- Index wählen lieber einige Buckets mehr als zu wenig. Wählen Sie allerdings zu viele Hash Buckets, verschenken Sie wiederum kostbaren Hauptspeicher. Wie teuer Hash Collisions wirklich sind, können Sie [6] entnehmen. Weiterführende Informationen zu Hash-Indizes finden Sie auch in [7]. Eine detaillierte Beschreibung von Bw- Trees, die von Range-Indizes im SQL Server 2014 verwendet werden, würde den Rahmen dieses Artikels sprengen. Daher verweise ich Sie hier auf ein entsprechendes Whitepaper von Microsoft Research [8]. Einsatzmöglichkeiten Bevor Sie nun anfangen, Ihre kompletten Datenbanken auf In-Memory OLTP umzustellen, möchte ich Ihnen zum Schluss noch einige Tipps mitgeben, in welchen Szenarien In-Memory OLTP überhaupt sinnvoll ist. Die wichtigste Empfehlung ist, dass niemals eine komplette Datenbank umgestellt werden sollte! Sie müssen sich nämlich auf die Datenbanktabellen und Stored Procedures konzentrieren, bei denen Sie spezifische Probleme haben, die sich mit klassischen Bordmitteln des SQL Servers nicht lösen lassen. Was sind aber solche spezifischen Probleme? Wenn Sie Schwierigkeiten mit langsamen Storage-Subsystemen haben oder mit Ihrer Indizierungsstrategie, wenn Blockaden aufgrund von Locking und Blocking in Ihrer Datenbank auftreten, dann sollten Sie zunächst diese Probleme lösen. In-Memory OLTP setzt erst danach an, wenn Sie all dies bereits gelöst haben. Ein klassisches Problem, das zum Beispiel In-Memory OLTP adressiert, ist die sogenannte Last Page Insert Latch Contention sie kann in einem Clustered Index auftreten, wenn Sie einen fortlaufenden Clustered Key wie etwa eine INT IDEN- TITY verwenden. Einfüge-Operationen finden hier immer nur am Ende des Clustered Index statt, wodurch im Hauptspeicher durch das Latching ein Hotspot entsteht (Abbildung 3). Ein solches Problem lässt sich klassisch mit einem Random Clustered Key entschärfen, weil dadurch die Einfüge- Operationen im Clustered Index verteilt werden. Alternativ lässt sich hier auch In-Memory OLTP einsetzen, weil dadurch ebenfalls kein Latching im Hauptspeicher mehr durchgeführt werden muss. Interessant kann der Einsatz von In- Memory OLTP auch für Staging-Tabellen beim Beladen eines Data Warehouse sein: Hier lässt sich ebenfalls das Schreiben des Transaktionslogs unterdrücken, da Sie im Fehlerfall den ETL-Prozess einfach nochmals starten können und somit keine Daten verlieren. Der Einsatz von Native Compiled Stored Procedures ist aus meiner Sicht schon etwas kontroverser. Durch diese lässt sich die Anzahl der benötigten CPU- Instructions minimieren, wodurch Sie die verfügbaren CPU-Zyklen ebenfalls effektiver ausnutzen können. Nur müssen Sie bedenken, dass der SQL Server eine Datenbank ist und kein Application Server. Wenn Sie hier die Lizenzierungskosten betrachten, kann es durchaus Sinn machen, CPU-intensive Businesslogik, die in Stored Procedures implementiert ist, nicht im SQL Server auszuführen, sondern auf einem Application Server. Den SQL Server müssen Sie auf CPU-Core-Ebene lizenzieren, für einen Application Server benötigen Sie nur eine Windows-Betriebssystem-Lizenz. Eine Migration auf In-Memory OLTP ist daher nicht immer die erste Wahl und muss sorgfältig überlegt und evaluiert werden. Und natürlich ist In-Memory OLTP auch nur Bestandteil der Enterprise Edition vom SQL Server Abschließend zeigt Abbildung 4 den Durchsatz, den ein SQL Server mit In-Memory OLTP erreichen kann. Diese Performance-Tests wurden auf einer 32-Core-Maschine mit 256 GByte RAM durchgeführt. Fazit Eingangs haben Sie gesehen, welche Probleme bei relationalen Datenbanken aufgrund spezifischer Hardware-Eigenschaften auftreten können. Im SQL Server 2014 sollen durch In- Memory OLTP diese Probleme umgangen und vermieden werden. Die drei wichtigsten Säulen sind Memory Optimized Tables, Native Compiled Stored Procedures und Lock/Latch Free Data Structures. Ich hoffe, dass Sie in puncto In-Memory OLTP auf den Geschmack gekommen sind. In der nächsten Ausgabe der dotnetpro werden wir uns einem Thema widmen, das ebenfalls neu im SQL Server 2014 ist: Clustered-ColumnStore-Indizes. [sb] [1] Herb Sutter, The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software, [2] Cristian Diaconu u. a., Hekaton: SQL Server s Memory-Optimized OLTP Engine, [3] MSDN Blogs, SQL Server 2014: Inside Hekaton Natively Compiled Stored Procedures, [4] Wikipedia, Non-blocking algorithm, [5] Wikipedia, Compare-and-swap, [6] Klaus Aschenbrenner, Choose your Hash Bucket Count very wisely in Hekaton!, [7] Klaus Aschenbrenner, SQL Server Quickie #8 Hash Indexes, [8] J. Levandoski, D. Lomet, S. Sengupta, The Bw- Tree: A B-tree for New Hardware Platforms,