Backend Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
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 WindowsProgrammierung und seit 2000 mit dem .NET Framework. 2 004 und 2005 wurde er für sein Engagement als Microsoft MVP ausgezeichnet. Nähere Informationen zu seiner Person finden Sie auf www.SQLpassion.at.
I
n-Memory OLTP ist das Schlagwort im SQL Server 2014: Microsoft versucht mit InMemory 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 ...
Inhalt
Warum In-Memory OLTP?
▸ Warum brauchen wir InMemory OLTP? ▸ Memory Optimized Tables. ▸ Native Compiled Stored Procedures. ▸ Lock & Latch Free Data Structures.
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: ◼ L angsames mechanisches Storage. ◼ S SD-Storage ist extrem teuer. ◼ C PU-Taktraten sind auf zirka 3 GHz beschränkt. ◼ R elationale Datenbanken skalieren nicht unendlich.
Serie 1. Mehr Platz im Pool 2. Ent(b)lockungskur
dnpCode A1405SQLServer2014
60
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-Tech-
nologie 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-DX2Prozessor. 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 CPUSocket verbaut. Anwendungen, die Multithreading unterstützen, können dadurch weiterhin
[Abb. 1] CPU-Taktraten skalieren nicht unbegrenzt [1].
5.2014 www.dotnetpro.de
Backend Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
skalieren und eine enorme Performance liefern. In Abbildung 1 können Sie an der blauen Kurve sehr schön erkennen, dass die Takt raten 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 MultithreadingAnwendungen 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 ei-
nem 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 : ◼ D aten werden ausschließlich im Hauptspeicher gehalten. ◼ A bfragen werden mit den geringstmöglichen CPU-Instructions abgearbeitet. ◼ E liminierung 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 Ta bleim 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 FILESTREAM-Dateigruppe anlegen, die In-
www.dotnetpro.de 5.201461
Backend SQL Server 2014: Das ist neu, Teil 2 Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
Listing 1
Listing 2
Anlegen einer In-Memory-OLTPFilegroup.
Anlegen einer Memory Optimized Table.
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_OPTIMIZED_DATA angeben müssen. Innerhalb der In-Memory-OLTP-Datei gruppe 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 MEMORY_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. 62
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-SQLStatements 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\MSSQL12.MSSQLSERVER\MSSQL\DATA\xtp abgelegt. Die Zahl des Unterverzeichnisses stellt die entsprechende interne Datenbank-ID dar. Wenn Sie das T-SQL-State-
ment 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: ◼ D ie Datensatzlänge ist auf 8 KByte limitiert. ◼ T RUNCATE TABLE und ALTER TABLE werden nicht unterstützt. ◼ K eine Unterstützung für Fremdschlüssel und LOB-Datentypen. ◼ N icht 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 HashIndizes 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-
5.2014 www.dotnetpro.de
Backend Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
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 = 1048576) ) 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 DURABILITY 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.
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. ◼ Z usätzliche, teure CPU-Instructions durch die notwendigen C++-VirtualFunction-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
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.MSSQLSERVER\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 CDLL 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 AssemblerBefehl 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.
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
[Abb. 2] Aus einer C-DLL wird eine T-SQL Stored Procedure [3].
www.dotnetpro.de 5.201463
Backend SQL Server 2014: Das ist neu, Teil 2 Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
Listing 4 Native Compiled Stored Procedure. CREATE PROCEDURE HekatonProcedure ( @Param 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 IsolationLeveln 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ög64
lichkeit, 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 BwTree verwendet zusätzlich noch AtomicCAS-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 HashIndex 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 LastName 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 HashFunktionen 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.
5.2014 www.dotnetpro.de
n e r T
ds
u s ö L
Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
web & mobile
DEVELOPER
präsentieren:
n nge
Kn
o
Ho w
w
Unsere Leser spar en
€ 149,– mit Code DWX14dnp
14.-17. Juli 2014 NCC Ost, Nürnberg
DDC ■
.NET Developer Conference
MDC
3-Tages-Konferenz
– 250 Vorträge – 40 Thementracks – Networking auf Abendveranstaltungen ■
Top-Referenten
über 150 Experten aus den Themenbereichen Web-, Mobile- und .NET-Entwicklung
www.developer-week.de Aussteller & Sponsoren:
Mobile Developer Conference
WDC
Web Developer Conference
10 parallele Workshops am 17. Juli 2014
■
– Ganztägig – Vertiefend
■
Fachausstellung
mehr als 40 Partner präsentieren sich in der begleitenden Fachausstellung vom 14.-16. Juli 2014
DeveloperWeek
Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
Programm Developer Week 2014
Tag 1: Montag, 14. Juli 2014 Architektur
Visual Studio
Webentwicklung
09.00 – 09.15
Begrüßung
09.15 – 10.00
Eröffnungs-Keynote
10.00 – 10.30
Kaffeepause
10.30 – 11.30
Design Patterns sind Naturgesetze, Thomas Mentzel
VisualStudio – Ein Überblick, David Tielke
Die Architektur der ASP.NET Web API, Marius Schulz
Architecting the Cloud, Robert Eichenseer
Rapid Application Development – Nur Spielerei? Constantin Klein
OWIN – der Microsoft Web Stack erfindet sich neu, Robert Mühsig
11.30 – 11.45 11.45 – 12.45
Von den Anforderungen zur Architektur: Leitfaden für einen guten Softwareentwurf
7 Jahre Visual Studio TFS – Tipps & Ausblick, Neno Loje
Flexible verteilte Anwendungen mit Micro-Service, Mike Bild
Visual Studio 2013 – Produktiver werden, David Tielke
ab 19.00
Datenbackends in der Cloud und deren Integration, Peter Kirchner
Erfolgreiche Rewrites, Johann-Peter Hartmann
Enterprise-Webanwendungen mit Ext JS / EXT.NET, Johannes Hoppe
Debugging im Zeichen der Cloud, Robert Eichenseer
‘Triple-E‘ class Continuous Delivery, Werner Keil
Real Time Anbindung an SAP ERP, Rainer Barthels, Otto Neff
Connected Web, Damir Dobric
ALM konkret, Sebastian Rölz
Was ist neu in Windows Azure Mobile Services? Damir Dobric
Sourcingstrategien für nationale und internationale Projekte, Reiner Hörger
Mobile Games mit Windows Azure, Jürgen Gutsch
Zentrales Build & Release Management, Thomas Rümmler, Christian Schlag
Kaffeepause Schnee von gestern – Was ist ein Event Store? Jan Fellien
Visual Studio Online IDE, Patrick Boscolo
17.30 – 17.45 17.45 – 18.45
Continuous Delivery und Deployment in der Praxis, Martin Aschoff
Raumwechsel
16.00 – 16.30 16.30 – 17.30
Einführung in die Windows Azure Plattform, Sascha Dittmann
Mittagspause
14.45 – 15.00 15.00 – 16.00
ALM
Raumwechsel
12.45 – 13.45 13.45 – 14.45
Azure
Eine moderne RESTful basierte Web-Anwendung, Marc André Zhou
Raumwechsel Weißbuch der ArchitekturDokumentation, Stefan Zörner
Testmanagement mit Visual Studio 2013, Nico Orschel
Webanwendungen in Minuten hochskalierbar bereitstellen, Peter Kirchner Abendveranstaltung
Ausführliches Programm, alle Abstracts, Referenten und die Anmeldung online unter:
developer-week.de
Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
JavaScript
Webarchitekturen Web-Frameworks Android
iOS
Begrüßung
09.00 – 09.15
Eröffnungs-Keynote
09.15 – 10.00
Kaffeepause
10.00 – 10.30
Code-Qualität trotz JavaScript, Niko Köbler, Heiko Spindler
Das Märchen vom agilen Architekten, Stefan Zörner
SinglePageApplications mit Ember.js, Christian Ringler, Robert Rieger
JavaScript Debugging und Profiling, Sebastian Springer
REST und RESTful HTTP: Was es ist – und was nicht, Stefan Tilkov
Datenvisualisierung, Martin Walter
Integration von Google+ in iOS- und Android-Apps, Peter Friese
CoreBluetooth in iOS 7, Tammo Freese
Android Builds automatisieren, Janusz Leidgens
iBeacons allüberall und in der Praxis, Ivo Wessel
Raumwechsel
11.30 – 11.45
Mittagspause JavaScript für .NET-Entwickler, Tilman Börner, Golo Roden
Prinzipien für skalierbare Architekturen, Sven Günther, Andreas Havenstein
Tools und Tipps für den modernen Frontend-Workflow, Sven Wolfermann
Autos verkaufen mit CQRS und Event Sourcing, Marco Stechl, Philipp Garbe
Web Services mit Symfony2, Paul Seiffert
Testing mit Robolectric und FEST in Android Studio, Onur Güngören
iOS meets Arduino – Electronics prototyping mit iOS, Jens Meder
Offline-Architekturen für mobile Endgeräte, Christian Pöcher
A Better CSS: LESS is More
Bildbearbeitung für iOS und Android mit OpenCV, Uwe Frieser
Modular iOS-Apps Piet Brauer
High performance websites, Stefan Priebsch Arne Blankerts
Twig – Eine PHP Template Engine, Timo Haberkern
Abendveranstaltung
15.00 – 16.00
16.00 – 16.30 Oberflächendesign für Android Apps
Automatisiertes Testing mit iOS, Felix Schulze
Raumwechsel Mit Angular.js schnell zur Single Page Application
13.45 – 14.45
14.45 – 15.00
Kaffeepause Meteor JS – Eine flexible JavaScript Plattform, Niko Köbler, Heiko Spindler
11.45 – 12.45
12.45 – 13.45
Raumwechsel Überlebenswichtig: Die wichtigsten Frameworks für JavaScript
10.30 – 11.30
16.30 – 17.30
17.30 – 17.45 Modularer Android Code mit Dagger, Onur Güngören
Der einzig wahre Objective-C Stil, Tammo Freese
17.45 – 18.45
ab 19.00 Programmänderung vorbehalten
Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
Programm Developer Week 2014
Tag 2: Dienstag, 15. Juli 2014 ArchitekturPraxis 09.00 – 10.00
Das Event im Mittelpunkt: EDA und CEP, Tobias Richling
.NET-Praxis
Next.NET
Daten
Trends
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
Professionelle Datenbankentwicklung mit den SSDT, Constantin Klein
Internet der Dinge – mit Webtechnologien, Timo Haberkern
Herausforderungen im Datenzeitalter, Constantin Klein
Wearable Android – Developing for Google Glass, Sebastian Kaspari
Twitter insights mit StreamInsight und HDinsight, Olivia Klose, Patric Boscolo
3D-Druck für Entwickler
Entkopplung und Datenqualität in Datenbanken, Thomas Worm
Raspberry Pi für Entwickler
Anwendungsfälle für Elasticsearch, Florian Hopf
Smartwatch Hacking, Robert Virkus
Entity Framework 6.x – Erweiterungsmöglichkeiten ausloten, Thomas Haug
Spaß und Freude mit Kinect, Tam Hanna
10.00 – 10.30 10.30 – 11.30
Kaffeepause Extreme Domain Modelling, Dennis Traub
Code Reviews – Jeder kennts, keiner machts, Boris Wehrle
11.30 – 11.45 11.45 – 12.45
Raumwechsel Die mystische CRUD-3-SchichtenApplikation, Tobias Richling
Prototyping und Entwicklung mit dem SharePoint Designer, Alexander Tews
12.45 – 13.45 13.45 – 14.45
SeekYouRS – Happy Path CQRS Framework, Jan Fellien
CodedUI in der Praxis: Lokalisierung bis Nachhaltigkeit, Nico Orschel
Architecting .NET Solutions for the Enterprise, Dino Esposito
OAuth2 und OpenID Connect, Daniel Basler, André Meier
ab 19.00
Basics of hardware programming in .NET, Marcin Kawalerowicz
Kaffeepause Gießen beliebiger Datenstrukturen mit Events, Ralf Westphal
Reactive Extensions, Mike Bild
17.30 – 17.45 17.45 – 18.45
Roslyn – Compiler as a Service, Christoph Wille
Raumwechsel
16.00 – 16.30 16.30 – 17.30
Cross-Plattform Entwicklung mit C#, Christian Lang, Loek van den Ouweland Mittagspause
14.45 – 15.00 15.00 – 16.00
Erstellung einer prototypischen Windows 8.1 App, Peggy Reuter-Heinrich, Lars Heinrich
Libs, ohne die ich nicht mehr programmieren will, Timothée Bourguignon Raumwechsel
Softwareentwurf Live, Ralf Westphal
Usability praktisch, Bernhard Pichler
Tasks – Wie funktionieren die? Bernd Marquardt
Abendveranstaltung
Ausführliches Programm, alle Abstracts, Referenten und die Anmeldung online unter:
developer-week.de
Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
Node.js Node.js-Anwendungen mit Visual Studio, Peter Hecker
Datenbanken / Datenzugriff
Responsive Webdesign
Cross-Plattform
Mobile Praxis
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
10.00 – 10.30 jQuery Mobile WebApp 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
Entkopplung und Datenqualität in Datenbanken, Thomas Worm
Responsive Design mit Bootstrap, Gregor Biswanger
Plattformübergreifende App Usability, Thorsten Stark, Michal Gralak
Mobile Testing, Felix Schulze
11.45 – 12.45
12.45 – 13.45 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
Worauf kommt es beim Design von Datenbanken an?
Neue Techniken für Responsive Design
Qualität und Sicherheit aus der Cloud, Peter Bruhn, Richard Süselbeck
Cross-Platform Levels, Udo Trappe
Skalieren mit Amazon Web Services
Anbindung an das CMS
Abendveranstaltung
15.00 – 16.00
16.00 – 16.30 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
13.45 – 14.45
14.45 – 15.00
Kaffeepause Node.js versus .NET – Teil 1, Jürgen Gutsch, Golo Roden
10.30 – 11.30
11.30 – 11.45
Mittagspause Richtig arbeiten mit npm
09.00 – 10.00
16.30 – 17.30
17.30 – 17.45 Cross-PlattformEntwicklung mit XAMARIN und .NET, Sebastian Seidel
Copyright für Developer, Claus Volke
17.45 – 18.45
ab 19.00 Programmänderung vorbehalten
Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
Programm Developer Week 2014
Tag 3: Mittwoch, 16. Juli 2014
09.00 – 10.00
.NET-Tools
Craftsmanship
Desktop
Sprachen
Vorgehensmodelle
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
Produktentwicklung für die intelligente Gebäudetechnik, Urs Boehm
Hitchhiker‘s Guide to Functional Programming, Sergey Shishkin, Steffen Forkmann
Srum, Kanban oder doch beides? Ilias Foukis
F# im Web und auf dem Client, Carsten König
Agiles Vorgehen in traditionellen Projekten, Steve Graegert
Die JavaScript Engine V8 in .NETAnwendungen nutzen, Torsten Zimmerman
Football, Poker, PM oder: Wir führen Srum ein! Marcus Jacob
Monaden durch Beispiele begreifen, Carsten König
Definition of almost done, Dominik Jungowski
Noch eine!? – Eine neue Hochsprache für JVM und CLR, Michael Wiedeking
Best Practices für globale Scrum Teams, Jürgen Toth
10.00 – 10.30 10.30 – 11.30
Kaffeepause Päckchen packen mit NuGet, Thomas Schissler
ATDD – Der Weg zur lebenden Dokumentation, Hendrik Lösch
11.30 – 11.45 11.45 – 12.45
Raumwechsel Code Generierung mit .NET, Philip Jander
The Black Art of GUI Testing, Christoph Thelen
12.45 – 13.45 13.45 – 14.45
FAKE: Echt starkes Build für .NET, mit .NET, Philip Jander
Mit agilen Praktiken SOLIDe Systeme bauen, Sven Günther
17.45 – 18.45
Building Rich Media Apps, Robert Eichenseer
Raumwechsel Unit Testing und Mocking mit Microsoft FAKE, Christian Jacob
SOLIDe Prinzipien des objektorientierten Entwurfs, Dennis Traub
16.00 – 16.30 16.30 – 17.30
Missverständnisse bei der WPF Look & Feel Entwicklung, Alexander Keller
Mittagspause
14.45 – 15.00 15.00 – 16.00
WPF – Deep Data Binding, Bernd Marquardt
Die eigene App mit dem Cloud AD verbinden, Robert Mühsig
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
Abschlusskeynote
Ausführliches Programm, alle Abstracts, Referenten und die Anmeldung online unter:
developer-week.de
Created for Ralf Zumbrunn (
[email protected]) - 15322 on 30.07.2014 23:37:17 Please do not make illegal copies!
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 AppEntwicklung, 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
10.00 – 10.30 Windows Phone
