Sollte man für Statistiken immer eine Datenbank verwenden

[Quickbeam2k1]

Hallo,

ich glaube ich habe nun endlich mal ein Projekt gefunden mit de ich meine eingerosteten Programmierskills wieder auffrischen kann. Bei dem Projekt möchte ich auch Daten auswerten. Insbesondere möchte ich zu jedem "Wurf" in einer "Session" festhalten welches "Feld" getroffen wurde. Unter bestimmten Annahmen weiss ich auch welches "Feld" versucht wurde zu treffen und ich kann somit (theoretisch) die Trefferquote und eine Heatmap erzeugen und auch die "Sessions" vergleichen

Jetzt stellt sich mir die Frage ob ich das alles in eine Datenbank packen sollte (kann weiss ich dass das geht) oder ob ich dafür nicht auch eine z.B xml oder csv Datei reicht. Das ganze sollte auch später mal auf nem Tablet laufen. Ist da Performance auf einem Tablet ein Problem? Meine SQL-Kentnisse sind auch eingerostet, würde die natürlich auch wieder auffrischen, wenn ihr meint dass das besser ist.

 

[Cool Master]

Du sagst es ja schon selber, du hast mit Daten zu tun somit brauchst du ne DB.

Wer brauch heute noch SQL? Nimm ein gutes Framework und du kannst dir alles zu sammen klicken. z.B. Drupal gepaart mit Views. Da gibt es auch schon schöne Themes/Designs welche per Responsive Design gebaut wurden. ergo läuft es auf Smartphone, Tablet und Computer.

 

[Quickbeam2k1]

Also ich hatte eigentlich vor meien Anwendung in Java zu programmieren. Ich möchte mich halt wieder mit objektorientierter Programmierung beschäftigen. Da ist die Datenanalyse eigentlich nur ein kleineres Teilproblem.

 

[Cool Master]

Das einzige Java was ich mag ist die Insel

Sorry aber da kann ich dir nicht weiter helfen da ich 0 mit Java zu tun habe.

 

[benneq]

XML / CSV ist ja quasi auch 'ne Datenbank, nur ohne ausgefeilte Such-/Filteroperationen. Und es gibt keine Indizes. D.h. wenn du mit XML / CSV arbeitest, wirst du jedes mal alle Datensätze durchsuchen müssen, bis du dein gewünschtes Ergebnis hast.
Also quasi: CSV in Java einlesen, dann hast du 'ne List<MyCSVData> und dann gehst du die komplette Liste durch, bis du hast was du willst.

Mit einer richtigen Datenbank, kannst du Felder indizieren und Sachen machen, wie "gib mir alle Datensätze, wo FeldX = 4 ist", ohne dass alle Datensätze durchsucht werden müssen.

Je nachdem wie groß das ganze wird und ob du mit vielen Generischen Properties arbeitest, könntest du auch noch einen Blick auf MongoDB werfen. Die Datenbank bringt auch gleich ein ziemlich gutes Aggregationsframework mit. Ansonsten tut's natürlich auch jede SQL-Datenbank oder evtl. sogar ein Key-Value Store.

Es hängt maßgeblich von der Art und der Struktur deiner Daten ab, welches Format / Datenbank man bevorzugen sollte.


Bzgl. Java könntest du mal einen Blick auf Spring Boot werfen. Da puzzlet man sich eben eine pom.xml zusammen und kann direkt loslegen. Spring Data bietet dir auch eine Abstraktion für sehr viele verschiedene Datenbanken. Aber im Endeffekt musst du so oder so mit JPA, QueryDSL bzw. dem jeweiligen Datenbank Treiber arbeiten, wenn du alle Features nutzen willst.

 

[Quickbeam2k1]

@benneque, danke für deine Ausführungen.

Eine Frage: wieso müssen in einer richtigen Datenbank nicht alle Felder durchsucht werden? Wenn ich da eine Abfrage starte, werden doch die Schlüssel in der jeweiligen Tabelle durchgegangen und es wird geschaut ob FeldX(key)=4 ist. Dann wird mir eine Liste übergeben. Wie soll das schneller als in linearer Zeit passieren?

Wie dem auch sei, natürlich hat die Datenbank da direkt viele Methoden implementiert. Das muss ich ja bei meiner XML oder CVS Datei ja selber implementieren, was mich aber auch nicht stört.

Zuguterletzt. Die Struktur der Daten wird sehr einfach. Ich denke da an n-Tupel der Form (Wurf_k, Ziel_k, Getroffen_k) Das Wurf_k kann ich dabei ja sogar weglassen da ich hier ja das k-te Tripel behandel.

 

[Zweipunktnull]

Ein beliebiger balancierter Suchbaum über dem Schlüssel führt zu logarithmischer Anfragezeit.

Oder genauer: O(log n + k), wobei n die Gesamtanzahl der Datensätze und k die Anzahl der ausgegebenen Datensätze ist.

 

[Quickbeam2k1]

Ah ja, da war ja was mit schnellerer Suche auf sortierten Mengen . Wie wird denn die Sortierung erzeugt? Hält die Datenbank dann intern für jeden Parameter eine Sortierung vor?

 

[asdfman]

Red-Black Trees korrigieren sich selbst. Eine sortierte Liste kann man mit binärer Suche durchgehen, aber man muss sie selber sortiert halten, also sind Einfügen und Löschen kostspieliger, weil man im Durchschnitt 50% der Liste angucken muss.

 

[Quickbeam2k1]

Einfügen ist natürlich ein Problem. Zumal ja auch (falls ein sortierter Baum für jeden Parameter vorgehalten wird) die Einfügeoperation mit der Anzahl der Parameter skaliert. Stimmt denn der Teil in Klammern für Datenbanken? Oder gibts da irgendwie ne neue Datenstruktur welche die Sortierungen nach allen Parametern enthält?

 

[asdfman]

Hashtabellen müssen nicht sortiert sein.

€: Wobei Einfügen und Löschen bei Red-Black-Trees natürlich eben nicht teuer sind. Das ist ja der Grund für deren Existenz.

 

[Quickbeam2k1]

Ja natürlich müssen Hashtabellen nicht sortiert sein. Aber wie hilft das bei der Fragestellung?

 

[benneq]

Nimm einfach eine Datenbank Damit hast du viele viele viele viele viele Vorteile.

1. Ganz vorne natürlich (für dich) das Auffrischen von Wissen. SQL (oder was auch immer)
2. Viele vorhandene Funktionen, z.B. SUM, COUNT, AVG, etc. (gibt's natürlich auch in so ziemlich jeder NoSQL Datenbank)
3. Skalierbarkeit. Die meisten NoSQL Datenbanken kann man einfach auf mehreren Servern installieren und dann die Querys mit verteilter Last berechnen lassen.
4. ACID (zumindest bei Relationalen DBs und z.B. auch bei Neo4j)
4.1. Integrität. Die Datenbank sorgt dafür, dass die Daten vollständig rein und wieder raus gehen und auch genau vom gewünschten Typ sind.
4.2. Typisierung: In CSV sind alles erstmal nur Strings. In anderen Datenbanken kannst du direkt den passenden Datentyp angeben.
5. (Query-)Caching.
6. Eine Datenbank ist genau für solche Anwendungsfälle spezialisiert. Eine CSV Datei dient im Grunde nur als Datenpaket, zum Datenaustausch.
7. Weil man es halt so macht In professionellen Umfeld wird dich jeder töten, wenn du mit einer CSV Lösung für Persistenz und Querys ankommst.

Natürlich kannst du auch mittels CSV + Java quasi deine eigene Datenbank schreiben und dir auch selbst Algorithmen zusammenbauen, um z.B. Indizes erstellen und für schnellere Suchen zu benutzen.

Es kommt halt sehr darauf an WAS du lernen willst. Wenn's um Gehirntraining geht und nur zum Spaß ist, dann wäre CSV + eigene Indizierungslösung sicherlich interessant. Wenn es einfach nur funktionieren soll und schnell gehen soll: Datenbank.

 

[asdfman]

Möglicherweise war das ein Missverständnis. Habe den Thread nicht komplett lesen können und jetzt auch keine Zeit das nachzuholen und ggf. eine ausführlichere Antwort zu geben. Deshalb sieh mein Post vorerst einfach mal als hinfällig an.

 

[Quickbeam2k1]

@ benneque. Also ich denke es ist erstmal nur fürs Gehirntrainign und zum Spaß Werde dann wohl bei der xml oder csv variante bleiben. Mal shauen was sich noch daraus entwickelt.

@Zweipunktnull. Sind die Daten in einer Datenbank denn bezüglich jedem Parameter in einem Balancierten Baum vorhanden?

 

[Zweipunktnull]

Also mal ganz grob und vereinfacht: Für jede Tabelle gibt es einen Primärindex oder clustered index. Dieser bestimmt die Ordnung, in der die Datensätze physisch gespeichert sind. Es ist klar, dass nun effizient über den clustered index auf die Datensätze zugegriffen werden kann (eben z. B. Lokalisierung in logarithmischer Zeit).

Es ist aber auch klar, dass jede Tabelle nur genau einen clustered index haben kann. Die Datensätze können schließlich nur in einer Reihenfolge gespeichert sein. Dennoch soll evtl. auch über andere Zugriffsmuster effizient auf die Datensätze zugegriffen werden können. Deswegen kann eine Tabelle zusätzlich noch eine beliebige Anzahl an Sekundärindizes haben. Im Wesentlichen entspricht jeder Sekundärindex einem balancierten Suchbaum. Dieser Suchbaum enthält aber nicht die gesamten Datensätze, sondern nur die jeweiligen Werte der Datensätze aus der Spalte, für die der Index erzeugt wurde. In den Blättern des Suchbaums sind schließlich Zeiger zu den eigentlichen Datensätzen gespeichert.

Zur Lokalisation eines Datensatzes über einen Sekundärindex absteigen wir also im entsprechenden Suchbaum bis zu dem Blatt ab, dass dem gesuchten Datensatz entspricht. Dort folgen wir dem Zeiger und kommen zum eigentlichen Datensatz. Es ist klar, dass wir beliebig viele Sekundärindizes parallel zum eindeutigen clustered index erzeugen können.

Beim Einfügen neuer Datensätze müssen wir natürlich nicht nur den Datensatz an sich speichern, sondern auch in jeden Sekundärindex für die jeweilige Tabelle ein Blatt mit einem Zeiger auf den neu gespeicherten Datensatz einfügen. Für gewöhnlich wird diese Mehrarbeit aber in Kauf genommen, da viel, viel häufiger lesend als schreibend auf eine Datenbank zugegriffen wird. Sprich, unsere Sekundärindizes machen unsere wenigen Schreibzugriffe zwar langsamer, im Gegenzug machen sie aber unsere vielen Lesezugriffe wesentlich schneller.

 

[Daaron]

...und wenn man tatsächlich mal größere INSERT- oder UPDATE-Operationen plant, dann kapselt man die in eine Transition. Würde man 10 Inserts nacheinander ausführen, müssten die Sekundär-Indizes 10x neu aufgebaut werden. Kapselt man den Kram, ist es trotzdem nur ein Re-Indexing.

 

[Quickbeam2k1]

Vielen Dank für eure Ausführungen. Das ganze sieht dann ja aus wie eine Art Gebirge das man in ein Paar(viele) Streifen schneidet. (Gut, glatt muss das Gebirge dann natürlich nicht sein)

Als Datenbankalternative für meine primitiven Aufgaben scheint sich auch noch SQLite anzubieten. Da findet man auch ausreichend viele Anleitungen zu. Vielleicht wähle ich das.

 

[Limit]

So wie du das beschreibst, lohnt es sich nicht eine "große" Datenbank extra dafür aufzusetzen. Es bliebe also die Wahl zwischen einer einfachen Datenbank wie SQLite oder eigenen Datenstrukturen + CSV / XML / JSON.

Das würde ich hauptsächlich von der Menge der Daten und der Art der Zugriffe abhängig machen. Eine Datenbank erlaubt es recht einfach komplexe und dennoch effiziente Abfragen zu erzeugen. Wenn es nicht zuviele Daten sind, kann man die Datenbank auch im RAM ablegen.
Wenn du diese Flexibilität nicht brauchst und die Daten in den RAM passen, benutze einfach CSV und lege die Daten direkt in dem Format ab, das du in deinem Programm sowieso schon benutzt. Das hat dann den geringsten Overhead.

[Ergänzung]
SQLite ist nicht Multi-User fähig – sollten also parallele Zugriffe auf die Datenbank vorkommen, musst du sie synchronisieren.

 

[AlbertLast]

Du könntest auch die Datenbank nicht nur als quelle für Daten sehen,
sondern auch SQL als Analystische Sprache dir eigen machen( und ja sql ist in der analytic standard).
Was aus meiner sicht ein sinnvoller ansatz wäre.