Wie sollte ich meine Daten speichern? Ein Vergleich von Datenbank, Solr, …

 

Als Entwickler stehen wir immer wieder vor der Frage, wohin nur mit den Daten? Zur Auswahl stehen da eine ganze Reihe von Möglichkeiten, zum Beispiel Volltext-Suchmaschinen wie Lucene mit seinen Derivaten Elastic Search und Apache Solr, oder die Datenbankvarianten SQL, NoSQL und GraphDB. Im folgenden möchte ich eine Entscheidungshilfe zu diesem Thema geben.

Zu Beachten: Interessant wird es erst, wenn eine bestimmte Menge an Daten erreicht wird. Wer nur 100.000 Datensätze verwalten muss, der kann mit jedem System alle Fragestellungen in erträglicher Zeit lösen.

Relationale Datenbank

Kennen wir vor allem in Form einer SQL-Datenbank, wie beispielsweise MySQL. Die Merkmale solcher Systeme sind:

  • Tabellen mit festem Schema
  • Indexbasierte Suche
  • Beziehungen (Relationen) der Daten zueinander durch Fremdschlüssel

Da hier ein festes Schema definiert wird, haben wir im PHP-Code Objekte, die diese Struktur exakt nachbilden. Es ist also jederzeit bekannt welche Daten vorhanden sind. Auf der anderen Seite müssen wir beim Erstellen auch alle Daten liefern, oder uns mit Standardwerten aushelfen.

Durch das feste Schema, ist von Anfang an bekannt wie viel Speicher jeder Datensatz maximal benötigt, was sich vorteilhaft auf Speicherverbrauch sowie Lese- und Schreibgeschwindigkeit auswirkt.

Suchen gestaltet sich schwierig bis unmöglich. Der Zugriff auf die Daten muss über einen vorher festgelegten Schlüssel erfolgen, damit die Datenbank weiß welcher Datensatz zu unserem Suchwort gehört. Andernfalls müssen alle Datensätze durchsucht werden, was in relationalen Systemen äußert ineffizient ist. Können wir allerdings einen eindeutigen Schlüssel verwenden, ist es völlig egal wie groß die Tabelle ist, die Suche wird extrem schnell sein.

Skalierung der Systeme auf mehrere Cluster-Server (horizontal) gestaltet sich hier schwieriger. Daten, die eigentlich zusammen gehören, sind prinzipbedingt über mehrere Tabellen verteilt. Ein Sharding auf verschiedene Server muss also für alle Tabellen nach einem für alle gleichen Schlüssel erfolgen. Diesen zu finden und zu verwalten stellt in der Praxis einen erheblichen Aufwand dar.

Gründe dagegen

  • Keine (wenigstens über eine gewisse Zeit) starren Datensätze/Schema
  • Für den häufigsten Use-Case keine eindeutigen Schlüssel möglich
  • Volltextsuche
  • So viele Daten, dass ein Server sie nicht verwalten kann

Weiter mit schemalosen Datenbanken >>