Server2014-Das ist neu(Teil 2)

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­
ble­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 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 CRE­ATE 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 ­
Pro­cedure [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 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ö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 <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
TYPO3 Neos – Next
Generation CMS,
Patrick Lobacher
Mobile Security:
Death to passwords,
Tim Messerschmidt
Vier Stores für eine
App: Entwicklung in
60 Minuten,
Jan Schweda,
Marco Richardson
Mobiles E-Learning
mit Moodle,
Thomas Kraehe,
Tobias Hauser
Lieber generieren
als implementieren
Shops integrieren
Vier Stores für eine
App: Deployment,
Marco Richardson,
Jan Schweda
Der internationale
Markt: Lokalisierung
von Apps,
Daniel Schneller
Neue Techniken
für Webprojekte
einsetzen,
Peter Kröner
Produktionsdaten
anbinden
Abschlusskeynote
13.45 – 14.45
14.45 – 15.00
Cross-Platform
Mobile mit C#,
Kerry W. Lothrop
Vorgehen für die
Tablet-AppEntwicklung,
Patrick Blitz,
Sonja Harrer
Kaffeepause
Das Zen des
Rasenmähens,
Marco Klawonn
11.45 – 12.45
12.45 – 13.45
Raumwechsel
Vom Entwickler zur
Führungskraft,
Johann-Peter
Hartmann
10.30 – 11.30
11.30 – 11.45
Mittagspause
Führungskompetenz
Teamentwicklung
Julia Schüller
09.00 – 10.00
15.00 – 16.00
16.00 – 16.30
Multi Platform Game
Development mit
Unity,
Dariusz Parys
TFS & Java – Ein SDK,
das Türen öffnet
Denny Israel,
Thomas Wilk
16.30 – 17.30
17.45 – 18.45
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 4: Donnerstag, 17. Juli 2014 – Workshops, 09.00-17.00 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.
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.
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 MVVMAnwendung 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.
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.
.NET De
DDC Confere
.NET De
DDC Confere
.NET De
DDC Confere
Mobile
MDC Confere
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!
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.
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 LayoutManagement 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.
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.
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.
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.
Mobile D
MDC Confere
Web De
WDC Confere
Web De
WDC Confere
Web De
WDC Confere
.NET De
DDC Confere
Mobile
MDC Confere
Web De
WDC Confere
Sichern Sie sich Ihr Ticket online unter: developer-week.de
Unsere
Leser spare
Created for Ralf Zumbrunn ([email protected]) - 15322 on 30.07.2014 23:37:17
Please do not make illegal copies!
K
ombi-Ticket
DWX & Workshop
14.-17. Juli 2014
Ticketpreis 1.650,– € zzgl. MwSt.
n
2
-Tages-Ticket
€ 149,–
14. / 15.07.2014 od. 15. / 16.07.2014
Ticketpreis 750,– € zzgl. MwSt.
mit Code
DWX14dnp
(statt 899,– € zzgl. MwSt.)
(statt 1.799,– € zzgl. MwSt.)
3
-Tages-Ticket
1
-Tages-Ticket
W
orkshop-Ticket
14.-16. Juli 2014
Ticketpreis 1.150,– € zzgl. MwSt.
14.07.2014, 15.07.2014 od. 16.07.2014
Ticketpreis 550,– € zzgl. MwSt.
17.07.2014
Ticketpreis 550,– € zzgl. MwSt.
(statt 1.299,– € zzgl. MwSt.)
(statt 699,– € 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, www.IT-Visions.de
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: 28.03.2014):
Veranstalter:
Backend
Created for Ralf Zumbrunn ([email protected]) - 15322 on 30.07.2014 23:37:17
Please do not make illegal copies!
[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 CPUInstructions 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 HashIndex 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 Colli­
sions wirklich sind, können Sie [6] entnehmen. Weiterführende Informationen zu
Hash-Indizes finden Sie auch in [7].
Eine detaillierte Beschreibung von BwTrees, 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 IDENTITY 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ügeOperationen 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 InMemory 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 CPUInstructions 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 2014.
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 InMemory 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] H
erb Sutter, The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software,
www.dotnetpro.de/SL1405SQLServer20141
[2] C
ristian Diaconu u. a., Hekaton: SQL Server’s
Memory-Optimized OLTP Engine,
www.dotnetpro.de/SL1405SQLServer20142
[3] M
SDN Blogs, SQL Server 2014: Inside Hekaton
Natively Compiled Stored Procedures,
www.dotnetpro.de/SL1405SQLServer20143
[4] Wikipedia, Non-blocking algorithm,
www.dotnetpro.de/SL1405SQLServer20144
[5] Wikipedia, Compare-and-swap,
www.dotnetpro.de/SL1405SQLServer20145
[6] K laus Aschenbrenner, Choose your Hash
Bucket Count very wisely in Hekaton!,
www.dotnetpro.de/SL1405SQLServer20146
[7] K laus Aschenbrenner, SQL Server Quickie #8 –
Hash Indexes,
www.dotnetpro.de/SL1405SQLServer20147
[8] J. Levandoski, D. Lomet, S. Sengupta, The BwTree: A B-tree for New Hardware Platforms,
www.dotnetpro.de/SL1405SQLServer20148
www.dotnetpro.de 5.201475