Archiv

Posts Tagged ‘Datenbank’

Präsentation “Introducing RavenDB” bei der @dnugbe

22. Oktober 2013 Kommentare aus

Als Vorbereitung für meine Präsentation an der SoftShake 2013 durfte ich am 16. Oktober einen Testlauf bei der .Net User Group Bern machen. Mit über 20 interessierten Teilnehmern hatte ich dafür ein ausgezeichnetes Publikum. Die Fragen und Rückmeldungen zeigten mir wo ich mich noch verbessern kann und welche Teile schon bereit sind.

Da etliche Zuhörer sich RavenDB nun einmal genauer anschauen wollen habe ich die Folien wiederum auf Speakerdeck veröffentlicht:

Folien zu Introducing RavenDB auf SpeakerDeck

Die Beispiele die ich vorgestellt habe sind allesamt aus meinen Beiträgen auf Improve & Repeat, dem englischsprachige Ableger meines Blogs. Dort gibt es nicht nur den Code sondern auch eine Erklärung der man ohne Vorwissen folgen kann.

Auch nach der Präsentation gibt es noch einiges was ich über RavenDB zu berichten habe. Diese Beiträge werden in den nächsten Wochen erscheinen und können über den RSS-Feed abonniert werden.

Als Abschluss möchte ich mich nochmals bei den Teilnehmern bedanken. Ohne interessierte Zuhörer sind solche Testläufe nicht möglich. Merci!

 
PS: Wer die Einführung lieber in Deutsch hat findet hier im Blog mit “RavenDB: Eine Einführung” einen passenden Beitrag.

 

Nachtrag 31. 10. 2013

Die Folien der Soft-Shake Präsentation sind nun ebenfalls auf Speakerdeck abgelegt.
 

Schlagworte: , ,

MS SQL Server: Login mittels Passwort aktivieren

17. Februar 2013 Kommentare aus

Obwohl es kaum etwas Einfacheres gibt stosse ich bei der Arbeit mit dem SQL Server immer wieder auf ein Problem: Wieso kann ich nicht mit dem angegebenen Benutzernamen und Passwort auf die Datenbank zugreifen?

Die Fehlermeldung bleibt ja mit Absicht wage:

SQL Login Error

Schaut man ins Event Log findet man die Ursache:

Login failed for user 'demo'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. [CLIENT: ]

Auch bei diesem Server ist bisher nur ein Login mittels Windows-Authentifizierung erlaubt. Dies lässt sich aber schnell ändern. Dazu genügt es das Microsoft SQL Server Management Studio als Administrator zu starten und mittels Rechtsklick auf den Servernamen die Eigenschaften aufzurufen. Unter Security kann man dem SQL Server erlauben die Benutzer selber zu authentifizieren:

MS SQL Server Properties

Nach einem Neustart des SQL Server funktioniert der Login mittels Benutzername und Passwort wie gewünscht.

Kann man das SQL Server Management Studio verwenden ist diese Option schnell aktiviert – man muss nur daran denken dies auch zu tun. Hat man diese Möglichkeit wegen fehlenden Berechtigungen oder Security-Anforderungen nicht, wird es mühsam. In diesem Fall ist die Anleitung von Sven Schmalle sehr hilfreich.

Schlagworte: ,

RavenDB: Eine Einführung

27. November 2012 5 Kommentare

RavenDB ist eine dokumentenorientierte Datenbank. Dies bedeutet das man nicht einzelne Zeilen speichert, sondern ganze Dokumente (im Sinne von JSON und nicht eines Word-Dokuments).

RavenDB ist nicht die erste solche Datenbank. Ganz bewusst spricht man hier von einer 2. Generation. Die Vorteile von Produkten die den Begriff Dokumentenorientierte Datenbank begründeten (wie MongoDB) wurden aufgenommen und gleichzeitig hat man die grössten Probleme und Unschönheiten behoben.

Mit RavenDB steht einem ein ausgereiftes Produkt zu Verfügung das hervorragend mit .Net zusammen spielt. Mit zahlreichen Strategien hilft einem RavenDB eine performante Anwendung zu schreiben. Das dazu nötige Wissen sammelte der Hauptentwickler Ayende Rahien bei Projekten wie NHibernate und dem NH- und EF-Profiler.

Für OpenSource-Projekte kann man RavenDB kostenlos nutzen. Das Lizenzierungsschema für ClosedSource-Projekte ist recht umfangreich und hilft einem das zum Projekt passende Modell zu finden. Die Preise starten bei moderaten 7$ pro Monat mit die Basic-Version und steigen je nach Funktionsbedarf an.

 

Installation der Datenbank

Um den Server-Teil von RavenDB zu installieren gibt es 2 Wege:

  1. Der Download einer Zip-Datei
  2. Das NuGet-Paket RavenDB.Server

Für den Server ist die Option 1 der bevorzugte Weg. Nach dem Entpacken der Zip-Datei startet man das Programm start.cmd und RavenDB kümmert sich um den Rest. Die webbasierte Administrationsoberfläche ist von nun an über http://localhost:8080 (oder dem ersten freien Port darüber) erreichbar:

Bevorzugt man lieber die Variante mit NuGet muss man für den Server-Teil ein eigenes Projekt anlegen. Dieses Paket ist nicht dazu gedacht mit Visual Studio verwendet zu werden und man braucht dieses separate Projekt einzig als Installationscontainer. Die Startdatei heisst in diesem Fall Raven.Server.exe und liegt im zur Solution gehörenden Verzeichnis packages\RavenDB.Server.1.0.960\. Abgesehen davon gibt es keine Unterschiede zwischen den beiden Ansätzen.

Versucht man den Server im gleichen Projekt zu installieren wie den Client wird dies in nicht auflösbaren Abhängigkeiten enden. Daher die beiden Teile unbedingt trennen!

 

Installation des Clients

Hier sollte man aufs NuGet-Paket setzen. Neben dem Client selber werden so auch gleich alle Abhängigkeiten aufgelöst. Die Installation des Paketes RavenDB.Client erfolgt entweder über die grafische Oberfläche oder mit diesem Befehl in der Package Manager Console:

Install-Package RavenDB.Client

Sofern man keine speziellen Einstellungen machen will ist die Installation damit abgeschlossen.

 

Daten speichern

Mit RavenDB lassen sich Daten ganz einfach speichern. Damit IntelliSense bei Abfragen helfen kann sollte man erst einmal eine Klasse definieren:

public class Book
{
    public string Id { get; set; }
    public string Title { get; set; }
    public string ISBN { get; set; }
    public int Pages { get; set; }

    public override string ToString()
    {
        return String.Format("{0} '{1}' ({2}) has {3} pages", Id, Title, ISBN, Pages);
    }
}

Um Objekte vom Typ Book zu speichern genügt es die Main-Methode einer Konsolenapplikation mit diesem Code zu erweitern:

using (var ds = new DocumentStore { Url = "http://localhost:8081/" }.Initialize())
using (var session = ds.OpenSession())
{
    var book = new Book() { Title = "RavenDB Intro", ISBN = "123-4-5678", Pages = 200 };
    session.Store(book);
    session.SaveChanges();
    Console.WriteLine(book.Id);
// => books/1 'RavenDB Intro' (123-4-5678) has 200 pages
}

Alles was man braucht um mit RavenDB Objekte zu speichern ist eine laufende Datenbank, eine Session und das zu speichernde Objekt. RavenDB nutzt für alle Operationen das Unit of Work Pattern. Bei so kleinen Demo-Anwendungen mag dies übertrieben erscheinen. Will man RavenDB aber produktiv einsetzen wird man sehr schnell die damit verbundenen Vorteile (wie Batch-Operationen) zu schätzen lernen.

 

Abfragen mit LINQ

RavenDB arbeitet sehr gut mit .Net zusammen. Dies wird nicht zu Letzt bei den Abfragen mittels LINQ deutlich. Möchte man alle Bücher die mit „Raven“ beginnen kann man diese ganz gewöhnliche LINQ-Abfrage schreiben:

using (var ds = new DocumentStore { Url = "http://localhost:8081/" }.Initialize())
using (var session = ds.OpenSession())
{
    var book = session.Load<Book>("books/1");
    Console.WriteLine(book);

    var ravenBooks = from books in session.Query<Book>()
            where books.Title.StartsWith("Raven")
            select books;

    foreach (var foundBook in ravenBooks)
    {
        Console.WriteLine(foundBook.Id + ": " + foundBook.Title);
        // => books/1 : RavenDB Intro
    }
}

Die Abfragen können beliebig verfeinert werden. Alles was man sonst so von LINQ kennt und schätzen gelernt hat funktioniert auch mit dem Provider für RavenDB.

Wenn man die ID eines Objektes kennt kann man auf LINQ verzichten und es direkt über die Session laden:

    var book = session.Load<Book>("books/1");

 

Verändern oder Löschen

Daten können ganz einfach verändert werden. Und werden die Daten nicht mehr benötigt lassen sie sich auch ohne grossen Aufwand löschen. Zum Editieren erzeugt man jeweils erst eine Abfrage die einem die gewünschten Objekte holt. Nach dem Verändern müssen die Änderungen der Session bekannt gemacht werden – auch hier nutzt man ja das Unit of Work Pattern.

using (var ds = new DocumentStore { Url = "http://localhost:8081/"}.Initialize())
using (var session = ds.OpenSession())
{
    var book = session.Load<Book>("books/1");
    Console.WriteLine(book);

    book.Title = "Another Book about RavenDB";
    session.Store(book);
    session.SaveChanges();

    var renamedBook = session.Load<Book>("books/1");
    Console.WriteLine(renamedBook);
    // => books/1 'RavenDB Intro' (123-4-5678) has 200 pages
    // => books/1 'Another Book about RavenDB' (123-4-5678) has 200 pages
}

Zum Löschen eines Objektes beginnt man ebenfalls mit einer Abfrage und markiert das Objekt als gelöscht:

using (var ds = new DocumentStore { Url = "http://localhost:8081/" }.Initialize())
using (var session = ds.OpenSession())
{
    var book = session.Load<Book>("books/1");
    Console.WriteLine(book);

    session.Delete(book);
    session.SaveChanges();

    var renamedBook = session.Load<Book>("books/1");
    if (renamedBook == null)
    {
        Console.WriteLine("Book with id 1 not found");    
    }
    // => books/1 'RavenDB Intro' (123-4-5678) has 200 pages
    // => Book with id 1 not found
}

Vergisst man das Objekt erst zu holen wirft RavenDB eine entsprechende Exception. Der Vorteil davon ist man löscht auch wirklich nur das gewünschte einzelne Objekt.

 

Fazit

Mit RavenDB kommt man ohne grosse Vorbereitung schnell zu einer Dokumentendatenbank. Die Standardeinstellungen sind Ideal um sich ins Thema NoSQL einzuarbeiten. Und auch das Unit of Work Pattern kann man ohne grossen Aufwand in Aktion erleben.

Will man RavenDB produktiv einsetzten wird man aber noch ein wenig mehr Aufwand treiben müssen als für diese Demobeispiele. Zu vielen Bedürfnissen einer Produktionsumgebung bietet einem RavenDB eine optimale Unterstützung. Diese Teile werde ich in einem eigenen Blogeintrag genauer beschreiben.

Schlagworte: ,

Buch-Rezension zu “Seven Databases in Seven Weeks”

8. August 2012 Kommentare aus

Seven Databases in Seven Weeks” von Eric Redmond und Jim R. Wilson erschien im Mai 2012 bei The Pragmatic Programmers. Die beiden Autoren liefern mit ihrem Buch eine gute Übersicht zum Thema NoSQL.

Dieses Buch lehnt sich nicht nur beim Titel bei “Sieben Wochen, Sieben Sprachen” an. Beide Bücher erklären in jeweils 3 Tageslektionen die vorgestellten Themen. Bei den Datenbanken wird aber bereits am ersten Tag tief in die Spezialitäten eingestiegen. Um die vorgestellten Übungen selber nachzuvollziehen sollte man wiederum ein UNIX-basiertes Betriebssystem nutzen.

 

Die 7 Datenbanken

PostgreSQL
NoSQL steht für Not only SQL, nicht für No SQL. Daher ist es nicht erstaunlich dass als erste Datenbank mit PostgreSQL ein Vertreter relationaler Datenbanken behandelt wird. Mit PostgreSQL werden Tabellen, Views und die Abfragesprache SQL erklärt. So verfügt jeder über das nötige Grundwissen um die Unterschiede zu den anderen Datenbanken verstehen zu können.

Wer sich bereits mit PostgreSQL beschäftigt hat kann hier aber auch einiges lernen: Window Functions, Hypercubes oder Pivot Tabellen über die Funktion crosstab() sind wohl nichts was man täglich benötigt. Bei einer entsprechenden Problemstellung ist es aber gut zu wissen dass dies auch mit PostgreSQL machbar ist.

 

Riak
Alternativen zur Abfragesprache SQL werden mit der verteilten Key-Value Datenbank Riak eingeführt. Im Buch wird fürs speichern und auslesen der Daten vor allem die HTTP REST Schnittstelle verwendet. So braucht man nicht extra eine zusätzliche Programmiersprache zu lernen. Ob cURL bei komplexen Abfragen und Funktionsdefinitionen die richtige Wahl ist sei aber dahingestellt.

Mit Riak kann man problemlos skalieren und bei Bedarf zusätzliche Server hinzufügen. Muss man seine Daten aber flexibel abfragen können stösst man sehr bald an seine Grenzen.

 

HBase
HBase ist eine spaltenorientierte Datenbank. Dies bedeutet das die Inhalte spaltenweise statt wie bei relationalen Datenbanken zeilenweise gespeichert werden. Speichert man beispielsweise Datensätze mit den Feldern Id und Name, so werden erst alle Ids abgelegt und danach alle Namen. Will man wie bei Data-Warehouse Anwendungen üblich grosse Datenmengen über spezifische Felder verdichten kann man die gewünschten Daten schön aneinandergereiht von der Festplatte lesen. Man liest nur was man braucht und nicht immer noch alle anderen Informationen die den Datensatz bilden.

HBase ist sehr gut geeignet um Terabytes an Daten zu speichern. Alle Daten werden automatisch versioniert und komprimiert. Gemäss den Autoren sollte man eine HBase Installation immer mit mindestens 5 Servern machen. Damit ist HBase für kleine Anwendungen nicht wirklich geeignet.

 

MongoDB
Mit MongoDB wird die erste dokumentenorientierte Datenbank vorgestellt. Als Dokument ist hier keine Word-Datei gemeint sondern eher etwas wie eine XML-Datei die einen beliebigen Inhalt haben kann. Der Name MongoDB kommt vom englischen Humongous und bedeutet so viel wie gigantisch.

Durch die Möglichkeit schemalose Daten zu speichern ist MongoDB äusserst flexibel. Die Performance von MongoDB ist sehr gut, bis die aktiven Daten mehr Platz benötigen als im RAM gespeichert werden kann. Ab dem Moment muss zwingend in die Breite skaliert werden, was nicht ganz so einfach ist wie bei Riak.

 

CoucheDB
CoucheDB ist wie MongoDB eine dokumentenorientierte Datenbank. Auch hier begegnen einem JavaScript und JSON, doch damit enden die Gemeinsamkeiten. Die Implementierung, die Projektphilosophie und die Skalierungsansätze unterscheiden sich grundlegend.

CoucheDB kann vom Smartphone bis zum Enterprise Server überall laufen. Allerdings ist CoucheDB nicht wirklich gemacht für ad hoc Abfragen. MongoDB und CoucheDB zeigen sehr schön wie verschieden man die gleiche Grundidee implementieren kann. Und wie wichtig es ist genau zu schauen ob die gewählte Datenbank auch wirklich für den geplanten Einsatz geeignet ist.

 

Neo4J
Neo4J ist eine Graph-Datenbank und ist besonders geeignet um Beziehungen zwischen einzelnen Elementen abzulegen. Was bei relationalen Datenbanken sehr schnell an die Performance geht ist mit Neo4J sehr einfach abbildbar. Dadurch dass man beliebige Daten verknüpfen kann ist man noch flexibler als bei den dokumentenorientierten Datenbanken.

Im Moment kann Neo4J nur den ganzen Graphen replizieren. Eine Skalierbarkeit wie beim Sharding in MongoDB ist dadurch nicht möglich. Will man Neo4J kommerziell nutzen sollte man die Lizenzgebühren im Auge behalten.

 

Redis
Zum Abschluss wird mit Redis noch einmal ein Key-Value Datenbank behandelt. Im Gegensatz zu Riak kann man bei Redis deutlich komplexere Strukturen (wie Listen, Mengen, Hashes) als Key nutzen. Da Redis oft als eine In-Memory Datenbank verwendet wird kann man sehr schnell auf die Daten zugreifen.

Wenn die Daten nur im RAM liegen verliert man diese bei einem Absturz. Um dem entgegen zu wirken gibt es mehrere Möglichkeiten um Redis zum Speichern der Daten zu bewegen. Auch bei Redis muss man einen Kompromiss zwischen Geschwindigkeit und Datensicherheit finden.

 

CAP Theorem

Mit verteilten Systemen möchte man diese 3 Ziele erreichen:

  • Consistency – alle Teile haben den gleichen Datenstand
  • Availability – alle Anfragen ans System werden immer beantwortet
  • Partition Tolerance – das System arbeitet auch wenn Teile davon nicht erreichbar sind

Das CAP-Theorem von Eric Brewer besagt das man von diesen 3 Anforderungen immer nur 2 umsetzen kann. Auf welche Anforderung man verzichten kann hängt dabei von der Anwendung ab.

Im Buch dient CAP auch zum klassieren der vorgestellten Datenbanken:

  • Redis, PostgreSQL und Neo4J erfüllen C & A, verteilen aber keine Daten.
  • MongoDB und HBase erfüllen C & P, Anfragen können fehlschlagen.
  • CouchDB erfüllt A & P, garantiert aber keine Konsistenz über alle Knoten.
  • Riak ermöglicht dem Benutzer pro Request selber zu wählen welche 2 Anforderungen erfüllt sein sollen.

 

MapReduce

MapReduce ist ein Algorithmus mit dem man grosse Datenmengen in einem verteilten System verarbeiten kann. Mit einer Map-Funktion werden die Ausgangsdaten in ein Format gepackt, das fürs Lösen der Aufgabe besser geeignet ist. (Wie das Aufteilen eines grossen Textes in einzelne Worte). Diese Daten werden an eine Reduce-Funktion übergeben die diese Daten verdichtet.

Mit einer grosszügigen Auslegung kann man dies mit der Group By Funktion relationaler Datenbanken vergleichen. Möchte man dort wissen welche Kunden die meisten Bestellungen gemacht haben könnte man so eine Abfrage machen:

SELECT customerId, count(*) FROM orders GROUP BY customerId;

Von ganzen Informationen die in der Orders-Tabelle sind interessiert uns nur das Feld customerId. Möchte man die Werte selber zählen (also eine eigene Reduce-Funktion machen) könnte man die Daten mit dieser „Map-Funktion“ erhalten:

SELECT customerId, 1 FROM orders;

Bei den NoSQL-Datenbanken wo jeder Datensatz anders aussehen könnte, ist der Hersteller nicht in der Lage Funktionen vorherzuahnen, mit denen man seinen Datenbestand analysieren kann. Stattdessen unterstützen die meisten im Buch vorgestellten Datenbanken MapReduce. So kann man nach diesem Muster selber seine Funktionen schreiben um die gewünschten Resultate zu erhalten.

 

Welche Datenbank soll man nehmen?

Bei all den unterschieden im Funktionsumfang gibt es auf diese Frage keine allgemeine Antwort. Erst wenn man die Anforderungen an die Datenbank kennt ist man in der Lage eine fundierte Entscheidung zu treffen.

Man sollte sich nicht zu sehr darauf fixieren eine einzige Datenbank zu finden die alle Anforderungen erfüllt. Die optimale Lösung für ein Projekt könnte im Zusammenspiel verschiedener Datenbanksysteme liegen. Dieser Ansatz ist unter dem Begriff “Polyglot Persistence” bekannt und erfreut sich einer immer grösseren Beliebtheit.

Im Buch wird eine Anwendung erstellt die auf Redis, CoucheDB und Neo4J setzt. So bekommt man einen sehr schnellen Cache, einen äusserst flexibler Datenspeicher und man kann Beziehungen zwischen den Datensätzen sehr schnell abfragen. So kann man alle Vorteile der einzelnen Systeme nutzen ohne von ihren Einschränkungen gebremst zu werden.

 

Fazit

Dieses Buch ist sehr gut geeignet um sich einen Überblick über verschiedene Konzepte zum Speichern von Daten zu verschaffen. Man wird sich beim Lesen sehr schnell bewusst das jede Datenbank sowohl Vor- wie auch Nachteile mit sich bringt. Je besser man die Anforderungen der eigenen Anwendung an die Datenbank kennt desto einfacher wird es eine fundierte Entscheidung zu fällen.

Man darf aber nicht erwarten nach dem Lesen ein Experte in Sachen NoSQL zu sein. Dafür sind die 350 Seiten zu kurz um 7 verschiedene Datenbanken zu erlernen. Das Buch liefert einem aber einen guten Startpunkt von dem aus man sein Wissen gezielt vertiefen kann.

 

Zum Buch

Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement” von Eric Redmond und Jim R. Wilson, 2012 The Pragmatic Programmers, ISBN 978-1-9343-5692-0, 350 Seiten, Englisch

Schlagworte: ,

Buch-Rezension zu “SQL Server MVP Deep Dives”

22. Dezember 2009 Kommentare aus

“SQL Server MVP Deep Dives” erschien im November 2009 bei Manning. Das Buch wurde von 53 MVPs für den SQL Server von Microsoft geschrieben und ist schon dadurch kein gewöhnliches Buch.

 
Was sind MVP?
MVP steht für Most Valuable Professional. Mit diesem Titel zeichnet Microsoft Experten aus der Community aus, die durch ihre herausragende technische Kompetenz aufgefallen sind. Bei Wikipedia gibt es eine gute Übersicht. Wer es genauer wissen will, sollte sich die offizielle Seite für MVP bei Microsoft anschauen.

 
Vom Design bis zu Business Intelligence
Die Themengebiete des Buches decken alle Aspekte der Datenbank ab:

  • Design und Architektur
  • Entwicklung
  • Administration
  • Tuning und Optimierung
  • Business Intelligence

Egal in welchem Bereich man mit dem SQL-Server arbeitet, man wird sicher Ansätze entdecken, die einem bei der Arbeit helfen. Neben der direkt mit dem SQL-Server zusammenhängenden Themen geht das Buch auch auf XQuerry, LINQ, PowerShell, XCOPY und Hyper-V ein.

Beim Lesen wird einem schnell klar, wieso die MVPs ihren Titel verdienen. Wenn die Themen auch komplex sind, haben diese immer einen Praxisbezug und sind so geschrieben, dass man den Ausführungen folgen kann.

 
Fazit:
Das Buch bietet zu jedem Thema sehr gute Artikel. Da jeder MVP sich zu maximal zwei Themen äusserte, wurde jeweils das Thema gewählt, zudem er/sie sich äussern wollte. Es gibt somit keine Texte die als Lückenfüller hinhalten mussten.
Über 40 Seiten Index macht das finden passender Textstellen sehr einfach. Das Buch ist nicht zuletzt dadurch sehr gut als Nachschlagewerk geeignet.

Das Buch ist allerdings nicht dazu gedacht, um von Anfang bis Ende am Stück durchgelesen zu werden. Auch wenn das Buchcover das Gegenteil verspricht, finde ich es für Einsteiger weniger geeignet. Natürlich kann man auch als Einsteiger viel vom gesammelten Wissen des Buches profitieren, doch wird man nicht um weiterführende Erklärungen herum kommen.

 
Zum Buch
SQL Server MVP Deep Dives, 2009 Manning, ISBN 978-1-935182-04-7, 848 Seiten

Schlagworte: ,
Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 296 Followern an