IT Wissen @me

Heute surfen wir im Allgemeinen alle mit dem Webprotokoll HTTP 1.1 bzw. HTTPS via SSL Zertifikat.

In den nächsten Jahren soll ein neuer Standard HTTP/2.0 eingeführt werden. HTTP/2.0 basiert auf Googles Protokoll SPDY. Mittlerweile liegt ein inoffizieller Standard für HTTP/2.0 vor, der ausdrücklich zur Implementierung freigegeben wurde. Dieser neue Standard wurde bereits bei der IETF als HTTP 2.0 eingereicht. Für die großen Big Data Webcontent Vorreiter Google, Facebook, Amazon und Ebay ist dieses Protokoll seit ca. einem halben Jahr Standard.

Die Entwickler von SPDY haben sich die Header eines HTTP-Requests näher angeschaut. In der Regel stehen in diesen Headern Informationen, die bei jedem Request übertragen werden, sich aber nicht ändern. Beispielsweise der User Agent, der die Informationen über den Browser, OS etc. enthält, ändert sich in der Regel nicht innerhalb einer Session.

Eine Komprimierung der HTTP-Header bringt nach Angaben in einem Standard HTTP-Request eine Reduzierung um 52% !!!

Vorteile von SPDY:

• Verbindung immer verschlüsselt
• Stream Multiplexing
• Server-Push Funktion
• Flusskontrolle für Request/Push
• Kopfzeilen Kompression
• Reduktion der Kopfzeilen

Funktionsweise:

Nach der Reduzierung durch Header-Komprimierung ist es den Entwicklern ein Anliegen den TCP-Slowstart zu ändern um mit weniger Paketen den erforderlichen Content downloaden zu können. Das TCP-Flag „initcwnd“ bestimmt dabei die Anzahl der Pakete die bis zum nächsten ACK übertragen werden dürfen. Die Zahl verdoppelt sich nach jeder erfolgreichen Übertragung, bei der es kein Paketverlust gab. Um diesen Slowstart zu umgehen, werden im Moment von den Clients bis zu sechs Verbindungen gleichzeitig aufgebaut. SPDY hingegen macht nur eine Verbindung auf und nutzt multiplexe Streams für den Ressourcen-Download.

Implementierung:

SPDY kann bereits heute produktiv genutzt werden. Viele wissen dies jedoch noch nicht. Um den Integrationsaufwand so einfach wie möglich zu Gestalten, gibt es ein Modul, welches direkt im Apache Kern eingebunden werden kann. Auch für den Ngix Webserver ist bereits ein Implementierungsmodul vorhanden. Die Browser Firefox, Chrome und Internet Explorer 11 unterstützen bereits SPDY. Für den einfachen User ändert sich nichts. Ob eine Webseite SPDY kompatible ist lässt sich durch ein Spezial Tool feststellen, welche den Downstream analysiert. Falls ein Browser kein SPDY unterstützt so wird das Übertragungsprotokoll HTTP bzw. HTTPs verwendet.

Fazit: Leider kennen noch nicht viele Web Developer die Möglichkeiten von SPDY. Sie könnten dadurch ihren Content viel schneller an den User pushen. SPDY bringt einen extremen Performanceschub und sollte heute auf allen größeren Projektpages implementiert werden.

Weitere Informationen und hilfreiche References:
http://dev.chromium.org/spdy/spdy-whitepaper
http://sprachkonstrukt.de/files/2012/08/http2-presentation.pdf 
http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf
https://code.google.com/p/mod-spdy/

http://www.cubrid.org/blog/dev-platform/what-is-spdy-deployment-recommendations/  

Heute hatte ich mal wieder Zeit einen neuen Blog Beitrag zu schreiben. Ich möchte euch mehr über die NoSQL (Not Only SQL) Welt zeigen. Habt ihr euch schon mal gefragt, wie Facebook ihre Big Data speichert ? Wie Amazon ihre Produkte und Einkäufe handelt ? Wie die Google Suche durch mehrere tausend Terrabyte Daten joined – Und im Millisekunden Bereich Ergebnisse liefert ? Mit einer standard relationalen Datenbank ist dies schon lange nicht mehr möglich. Das NoSQL Prinzip ist im Grunde simpel. Diese Datenspeicher benötigen keine festgelegten Tabellenschemata und versuchen, Joins zu vermeiden. Noch dazu skalieren Sie dabei horizontal.

Meine favourite NoSQL Database ist Apache Cassandra. Heute läuft diese Datenbank in mehreren verteilten Facebook Data Centers verteilt in einem Cluster mit über 50000 tausend Servern und ist performant. Der große Vorteil von Apache Cassandra ist

• Eignung für schnelle verteilte und horizontale Skalierung
• keine Single Point of Failures
• Automatische Replikation zwischen Data Centers
• schemafrei oder nur schwache Schemarestriktionen
• Key-Value Stores
• Open Source
• einfache Datenreplikation zur Unterstützung der verteilten Architektur
• direkte REST API – JSON, XML auf Keyspaces (Datenbanken), Column Familys (Tables)

Apache Cassandra hat unterm Strich gegenüber einer relationalen Datenbank like MySQL oder Oracle einen Geschwindigkeitszuwachs von etwa Faktor 1.000 (überprüft auf meinem Server durch 1TB free GEO location data auf einem Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 4 Cores und 16 Gigbyte RAM) !

MySQL vs. Cassandra

Was sollen Unternehmen machen, welche einen enormen Datenzuwachs redundant stand halten müssen ? Was sollen Unternehmen machen, welche direkt mehrere Gigabyte/Terrabyte/Petabyte Daten durch analytische Algorithmen und Funktionen analysieren wollen?

Mir würden zu diesem Use Case 3 intelligent Wege einfallen:

• Direktes Data + Type Mapping mit MariaDB (MySQL Nachfolger – down kompatibel) zum Cassandra Cluster
  Die Keyspaces (=Datenbanken in einem NoSQL System) können als Tabelle (View) in SQL gemappt werden und man kann in Real-Time zwischen den Daten joinen und SQL Funktionen anwenden. Verwendung Cassandra als Storage Engine.
• Direkte Analyse der Daten durch Apache Hadoop, Hive mit direktem Zugriff auf das Cassandra Cluster
• Kopierung der Daten in eine relationale Datenbank MySQL, Oracle (nicht wirklich sinnvoll!)