Neuer TPC Record für SQL Server 2005

„SQL Server 2005 überschreitet die 1 Million Grenze im TPC-C Benchmark“ und „SQL Server 2005 setzt einen neuen TPC-H Rekord“; dies hat Microsoft vor ein paar wenigen Tagen veröffentlicht. Toll, SQL Server 2005 ist also ein Spitzenprodukt – aber was heisst das nun für unseren Alltag als IT Professional?

Fangen wir von Vorne an. Die Transaction Processing Performance Council (TPC), eine Nonprofit Organisation, wurde gegründet um Hersteller unabhängige Datenbank Performance Vergleichstests zu definieren. TPC Tests sind streng definiert und müssen von den Herstellern selbst durchgeführt werden. TPC übernimmt dabei die Rolle eines unabhängigen Auditors, der die Tests begleitet und die Ergebnisse überprüft. Die Ergebnisse selber werden in einem Bericht zusammengefasst und auf der Website der TPC publiziert (www.tpc.org).

TPC-C ist schlichtweg der Standard Test zur Messung der Performance und Skalierbarkeit von OLTP Systemen. Der durchgespielte Use-Case entspricht einem Bestellsystem in welchem parallel neue Bestellungen erfasst und bestehende abgefragt werden. Gemessen wird die Performance in Transactions per Minute (tpmC).

TPC-H ist ein weiterer Test. Diesmal ist der Use-Case aber an einem OLAP System angelehnt. Hier werden ad-hoc Abfragen parallel zu Datenupdates durchgeführt. Gemessen wird die Performance in Query per Hour (QphH@size). TPC-H Performance wird wesentlich von der Grösse der darunterliegenden Datenmenge bestimmt; daher werden die Tests zu Vergleichszwecken in verschiedene Gruppen (entsprechend der zugrundeliegenden Datenbankgrösse) zusammengefasst. Daher auch das @size.

Genug der Theorie und zurück zur Erfolgsmeldung von Microsoft. Was bedeutet nun mehr als 1 Million tpmC? Ist das viel? Warum soll das so toll sein, wenn Microsoft mit diesem Resultat lediglich an siebter Stelle der Top-10 Rangliste steht und der Spitzenreiter Oracle 10g R2 beinahe 4 mal so viel leistet? Microsofts Testkonfiguration hat sensationelle 1′231′433 tpmC geleistet. Nehmen wir an, dass diese Menge von Bestellungen Mitarbeiter in einem Backoffice erfasst haben, dann ergibt dies bei einer 40 Stunden Woche die schon fast astronomische Zahl von 153′682′838′400 Bestellungen pro Jahr. Im Vergleich dazu: Die Schweizer Luftfahrtgesellschaft SWISS hat im Jahr 2006 gerade mal 10 Millionen Passagiere befördert respektive Ticket verkauft und deren Bestellungen erfasst. Somit lässt sich mit SQL Server 2005 spielend der gesamte Ticketverkauf der SWISS abwickeln; ja wahrscheinlich sogar aller Luftfahrtgesellschaften der grossen weiten Welt zusammen. Genau dies ist die sensationelle Meldung des Tages. Geschehe was will: mein Kunde kann Forderungen bezüglich Skalierbarkeit der Lösung stellen und ich kann beruhigt antworten, dass der SQL Server 2005 dies schon mitmachen wird; Vorausgesetz der Kunde hat das hierfür notwendige Kleingeld. Solch eine Performance hat selbstverständlich seinen Preis. So besteht die Testkonfiguration zum Beispiel aus 64 Prozessoren, 1 TB RAM (ja Terabyte – nicht Gigabyte) sowie ganzen 1′742 Harddisks mit insgesamt 54.8 TB Kapazität. Dass dies auch was kostet, dürfte wohl jedem einleuchten.

Ganz ähnlich verhält es sich auch mit den TPC-H Resultaten. Hier ist SQL Server 2005 in den Kategorie 100 GB (19′323 QpH@1ooGB) und 1′000 GB (69′999QpH@1000GB) gar an Erster Stelle. Was bedeutet aber 69′999QpH@1000GB? Angenommen 1000 Business Analysten arbeiten parallel auf einem 1 TB grossen Datawarehouse, dann muss jeder von Ihnen mehr als 1 ad-hoc Abfrage pro Minute an das System stellen. Und selbstverständlich auch begutachten und bewerten, damit er in der Lage ist die nächste Abfrage zu formulieren und abzusetzen. Auch das dürfte wohl kaum eine praktische Limite für unser Daily Business darstellen.

Langer Rede kurzer Sinn: SQL Server 2005 muss sich nicht verstecken! Es wird kaum ein relevantes Szenario geben, bei welchem der SQL Server punkto Performance nicht mitkommt. In einigen Konstellationen ist der SQL Server 2005 gar die leistungsstärkste und kostengünstigste Lösung.

MERGE Statement – ein cooles Feature von Katmai

Beim Durchsehen von Katmai – dem Nachfolger von SQL Server 2005 – bin ich auf eine coole Erweiterung in der DB-Engine gestossen; dem MERGE Statement.

Das MERGE Statement vereint die drei Statements INSERT, UPDATE und DELETE. Neu kann mit nur einem einzigen Statement ein ganzes Datenset in einem Rutsch in die DB geschrieben werden, unabhängig davon, ob einzelne Records bereits erfasst (und demnach ein UPDATE benötigen) , neu sind (und somit ein INSERT benötigen) oder aber aus der DB gelöscht werden müssen (und somit ein DELETE benötigen). Natürlich erwarte ich von so einem neuen MERGE Statement auch eine erhebliche Performance Verbesserung gegenüber der alt hergebrachten Methode mit zwei oder drei separaten Statements (INSERT, UPDATE und DELETE). Ob dem so ist, werde ich dir gleich nachfolgend versuchen zu beweisen. Zuerst aber mal ein Beispiel zum MERGE Statement (dies habe ich mir aus dem BOL von Katmai ausgelehnt).

Szenario: In einem täglichen Prozess soll die ProductInventory Tabelle mit den Einträgen aus SalesOrderDetail aktualisiert werden. Die Spalte Quantity aus ProductInventory soll pro Produkt um die Anzahl der verkauften Produkte reduziert werden. Fällt ein Produkt auf eine Menge Null zurück, muss dieses Produkt aus ProductInventory gelöscht werden.

Lösung mit SQL Server 2005:

WITH Selling(ProductID, OrderQty) AS
(
    SELECT ProductID, SUM(OrderQty)
    FROM Sales.SalesOrderDetail sod
      JOIN Sales.SalesOrderHeader soh ON sod.SalesOrderID = soh.SalesOrderID
                                     AND soh.OrderDate = {d ‘2001-07-03′}
    GROUP BY ProductID
)
DELETE Production.ProductInventory
FROM Production.ProductInventory pi
  JOIN Selling src ON (pi.ProductID = src.ProductID)
WHERE pi.Quantity = src.OrderQty;

WITH Selling(ProductID, OrderQty) AS
(
    SELECT ProductID, SUM(OrderQty)
    FROM Sales.SalesOrderDetail sod
      JOIN Sales.SalesOrderHeader soh ON sod.SalesOrderID = soh.SalesOrderID
                                     AND soh.OrderDate = {d ‘2001-07-03′}
    GROUP BY ProductID
)
UPDATE Production.ProductInventory
SET Quantity = pi.Quantity - src.OrderQty
FROM Production.ProductInventory pi
  JOIN Selling src ON (pi.ProductID = src.ProductID)
WHERE pi.Quantity > src.OrderQty;

Lösung mit Katmai:

MERGE Production.ProductInventory AS pi
USING (SELECT ProductID, SUM(OrderQty)
       FROM Sales.SalesOrderDetail sod
         JOIN Sales.SalesOrderHeader soh ON sod.SalesOrderID = soh.SalesOrderID
                                        AND soh.OrderDate = {d ‘2001-07-03′}
       GROUP BY ProductID) AS src (ProductID, OrderQty)
ON (pi.ProductID = src.ProductID)
WHEN MATCHED AND pi.Quantity - src.OrderQty = 0
    THEN DELETE
WHEN MATCHED
    THEN UPDATE SET pi.Quantity = pi.Quantity - src.OrderQty;

Also, eleganter ist die Lösung von Katmai allemal; wie sieht es aber mit der Performance aus? OK, ich weiss – Performance Tests mit CTP’s sind nicht gerade besonders fair. Ich bin aber auch nicht an absoluten Zahlen interessiert, sondern vielmehr an Trends. Daher habe ich die IO’s (SET STATISTICS IO ON) der beiden Lösungen miteinander verglichen:

mit SQL Server 2005:

Table ‘ProductInventory’. Scan count 4, logical reads 8, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘SalesOrderDetail’. Scan count 5, logical reads 15, physical reads 3, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘SalesOrderHeader’. Scan count 1, logical reads 703, physical reads 2, read-ahead reads 699, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(0 row(s) affected)

Table ‘ProductInventory’. Scan count 4, logical reads 8, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘SalesOrderDetail’. Scan count 5, logical reads 15, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘SalesOrderHeader’. Scan count 1, logical reads 703, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘ProductInventory’. Scan count 0, logical reads 16, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(8 row(s) affected)

mit Katmai:

Table ‘ProductInventory’. Scan count 4, logical reads 8, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘SalesOrderDetail’. Scan count 5, logical reads 15, physical reads 3, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘SalesOrderHeader’. Scan count 1, logical reads 703, physical reads 2, read-ahead reads 699, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘ProductInventory’. Scan count 0, logical reads 16, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(8 row(s) affected)

Der Effekt des neuen Merge Statements scheint mir offensichtlich zu sein; rund die Hälfte der IO’s. Und das ist schlicht und einfach Super!

SQL Server 2008 CTP – Woow!

Endlich, der erste Community Technology Preview von SQL Server 2008 (bislang Katmai) steht allen zum Download bereit. Zusammen mit weiteren Infos findest du den Downloadlink unter http://connect.microsoft.com/SQLServer/content/content.aspx?ContentID=5395. Der Download ist rund 877 MB gross; es kann also eine ganze Weile dauern, bis du den runter kriegst. Bei mir läuft der Download gerade. Sobald ich ihn installiert habe und einen ersten Augenschein nehmen konnte, werde ich hierhin zurückkehren und dir meine ersten Eindrücke und Erlebnisse mit diesem CTP schildern. Machst du mit? Ich würde mich riesig freuen, wenn wir hier unsere Erfahrungen, Probleme und Hilfestellungen zum brandneuen SQL Server 2008 CTP austauschen könnten. Also, bis bald – mein Download läuft noch immer (19%)!

TDWI Roundtable in Zürich – ein toller Start

Gestern war ich am ersten TDWI Roundtable in Zürich, welchen ich als eine sehr gelungene Veranstaltung betrachte. An diesem ersten Roundtable wurde Business Intelligence nach zwei verschiedenen Blickrichtungen untersucht. Zum einen in Richtung BI und Qualität und zum anderen in Richtung BI und Künstliche Intelligenz. Das waren auch die Themen der beiden Vorträge, welche die anschliessende Diskussion unter allen Anwesenden anregte. Für mich eine gelungene Veranstaltung, insbesondere die Diskussionsrunde, welche auch das Kennenlernen anderer Date Warehouse und Business Intelligence Professionals ermöglichte. Also eine echte kleine „Netzwerk-Party“, die ich dir nur weiter empfehlen kann. Leider ist der nächste Termin und Ort noch nicht bekannt; der letzte soll es aber bestimmt nicht sein!

Solltest du ernsthaft an DW und BI interessiert sein, kann ich dir den TDWI The Data Warehousing Institute empfehlen. TDWI Germany e.V. ist der deutschsprachige Ableger der amerikanischen TDWI und versteht sich als internationaler Verein für Business Intelligence und Data Warehousing Professionals und steht so jedem Interessierten offen. Mehr über den TDWI findest du unter http://www.dw-institute.de.