Realtime Statistiken

[Tyralcori]

Hallo Community,

ich hoffe, ich bin im richtigen Forum gelandet. In einem neueren Projekt von mir habe ich vor, Realtime Statistiken in meiner Seite einzubinden. Die momentanen Besucher auf der Seite, durchschnittliche Klickrate der Benutzer, etc.

Um das ganze ein wenig abstrahierter zu betrachten:
Die Kommunikation erfolgt über einen Ajax Request an meinen Handle, der die jeweilige Statistik Response (JSON) zurück an das Frontend in einen bestimmten Intervall zurückgibt. Derzeit wird dafür im Service jedes Mal die Datenbank (bzw. eine Replikation / Slave eines Masters belastet) jedoch glaube ich, das geht allemal auch viel schöner.

Die Datenbank basiert derzeit noch auf MySQL, die Engine auf InnoDB (Indexes sind gesetzt). Die Statements für die aktiven User und andere Statistiken sind auch regelrecht kleine, wenig aufwendige Selects.

Dennoch würde ich gerne eure Meinung hören, wie ihr solch Realtime Statistiken erstellen / behandeln würdet, da es sicherlich besser gehen wird.

[j.durini]

Naja..es gibt schon vorgefertigte Sachen wie z.B. Google Analytics und für etwas Geld bekommst du eTracker. Das wäre für dich optimal. Einfach und so sparrst du zeit. Wenn du aber was eigenes willst. Suche doch eine solche Vorlage.

[Tyralcori]

Es geht ja vielmehr darum, den Traffic nicht ins unendliche zu treiben, damit die Server nicht belastet werden. Natürlich gibt es Alternativen wie Google Analytics, jedoch sind deren Metriken nicht das, was ich suche. Daher soll etwas eigenes ran, was auch kein Problem ist. Es geht in diesem Topic regelrecht um Optimierungen des Designs, da ich nicht unbedingt alles auf die Datenbank abwälzen möchte.

[HappyHippie]

Hi Tyralcori,

Also wie sieht das genau aus? Werden die Daten in der Datenbank mit anderen Daten aus MySQL verknüpft? Oder geht es schlicht weg darum die Daten schnell zu speichern (ohne Verknüpfung) und abzufragen?

Nun wenn du massenhaft Daten speichern und auswerten willst ist natürlich MySQL/MariaDB nicht das richtige. Du solltest wohl eher je nach Anforderung auf eine NoSQL Datenbank setzen. Wenn du mehre Millionen evtl. sogar Milliarden Daten hast empfehle ich dir ElasticSearch da hast du eine hochbelastbare Datenbank kannst super schnell neue Nodes zu deinem Cluster (falls vorhanden) hinzufügen und wie der Name schon sagt hast du sehr effiziente Such/Statistik-Werkzeuge.

Ich selbst habe was Tracking angeht mit ElasticSearch gute Erfahrungen gemacht, habe derzeit 112 Millionen Einträge/Objekte in einem Index fürs Tracking über 2 Nodes, Performance-Technisch hatte ich bis jetzt noch keine Probleme.

[Tyralcori]

Hallo HappyHippie,

die Auswertung selbst findet ja in der Replikation statt, also dem Slave. Daher wird die "richtige" Master Datenbank erstmal nicht belastet. Ich habe auch schon überlegt auf NOSQL umzusteigen, jedoch würde mich ElasticSearch mehr ansprechen, da ich damit viel weniger bis jetzt gearbeitet habe. Soll ja eine tolle Alternative zu SOLR sein, womit ich schon viel mehr zutun hatte.

Aber das Beispiel bzgl. des Benchmarking hört sich toll an! Ist ja doch schon eine Summe, mit der ich ebenso rechnen werde. Was genau hat dich eigentlich zu ElasticSearch gebracht, bzw. wieso hast du dich gegen SOLR entschieden? Siehst du darin bestimmte Nachteile?

[Blar]

jedoch sind deren Metriken nicht das, was ich suche

Welche anderen Metriken werden von dir benötigt, die nicht über Google-Analytics abgebildet werden können?

Statistiken sind ein sehr umfangreiches Thema (Zuverlässigkeit, Datenmenge, Auswertung, Anzeige), das dich und deine Server schnell überfordern könnte.

[Gast]

elastic search ist ja vor allem eine volltextsuche.

piwik kommt mir mysql und/oder postgresql zurecht, bei den refferenzen lassen sich pI erahnen.

aber seis drum.

[Tyralcori]

Welche anderen Metriken werden von dir benötigt, die nicht über Google-Analytics abgebildet werden können?

Statistiken sind ein sehr umfangreiches Thema (Zuverlässigkeit, Datenmenge, Auswertung, Anzeige), das dich und deine Server schnell überfordern könnte.

Teils geht es einfach um Metriken für ein selbstentwickeltes Framework, welche nur Bilder in eine Art Blog Format darstellt. Derzeit läuft die Metrikenauswertung / Analyse nur auf Anstoß / bei Aufruf, und generiert dann ca. 2 Sekunden lang alle Metriken (ca. 30 Stück).

[Blar]

Mit den Events von Google-Analytics konnte ich z.B. dafür verwenden, welcher Benutzer wie viele Artikel erstellt hat, wie viele Kommentare erstellt worden sind oder wie oft ein Artikel gelesen worden ist. Mit der API konnte dann auch für bestimmte Zeiträume die Zahlen ausgelesen, gefiltert und über die Reporting API ausgelesen und weiterverwendet werden.

Nach mehreren mehr oder weniger erfolgreichen versuchen, für "Spezialfälle" ein eigenes Statistiksystem zu bauen, die meist nur sehr viel Arbeit bedeutet haben, würde ich so etwas wenn möglich vermeiden, ein solches System selbst zu bauen.

[HappyHippie]

Hallo HappyHippie,

die Auswertung selbst findet ja in der Replikation statt, also dem Slave. Daher wird die "richtige" Master Datenbank erstmal nicht belastet. Ich habe auch schon überlegt auf NOSQL umzusteigen, jedoch würde mich ElasticSearch mehr ansprechen, da ich damit viel weniger bis jetzt gearbeitet habe. Soll ja eine tolle Alternative zu SOLR sein, womit ich schon viel mehr zutun hatte.

Aber das Beispiel bzgl. des Benchmarking hört sich toll an! Ist ja doch schon eine Summe, mit der ich ebenso rechnen werde. Was genau hat dich eigentlich zu ElasticSearch gebracht, bzw. wieso hast du dich gegen SOLR entschieden? Siehst du darin bestimmte Nachteile?

Hatte schon öfters mit SLOR zu tun und ich fand es immer recht starr und "bockig", auch recht komplex. Jetzt setzte ich Elastica seit gut 2 Jahren ein und bisher hat es immer seine Zwecke auch im Bezug der Skalierbarkeit erfüllt. Für mich persönlich ist es weit aus mehr als eine Volltextsuche, wenn man sich mal damit beschäftigt hat. Hat sogar dann oftmal gepasst wenn alle Hadoop und HBase geschrien haben.

Auch ein Vorteil. ES wurde mit Java umgesetzt man kann es also ebenso wie SLOR erweitern. Ein dicker PLUS-Punkt war auch die REST API.