Implementieren Sie einen eindeutigen Zähler für die Seitenansicht?

Question

Ich möchte einen benutzerorientierten View Counter implementieren (ähnlich dem, was SO für Frageansichten hat), der die Anzahl der eindeutigen Ansichten auf einer Seite verfolgt. Es gibt ein paar similar Fragen hier, aber keine scheint meine Frage vollständig zu beantworten.

Was wäre das beste Setup dafür (in Bezug auf Datenbanktabellen etc.)? Wäre es gut, der Tabelle "Fragen" eine Spalte "Ansichten" hinzuzufügen und diese bei jeder Seitenansicht einfach zu erhöhen? Und wenn ich möchte, dass die Ansichten eindeutig sind, könnte ich eine andere Tabelle mit Frage-IDs und IP-Adressen haben und die "Ansicht" -Spalte nur erhöhen, wenn es nicht schon einen Eintrag mit der aktuellen IP-Adresse gibt. Allerdings würde diese 'ip-view'-Tabelle sehr schnell enorm werden ... Hauptsächlich geht es mir um den Aufwand, jede Seite und jede IP in einer Tabelle speichern zu müssen.

Wie könnte dies optimiert werden, damit es nicht zu einem Leistungsengpass wird? Gibt es einen besseren Ansatz als das, was ich beschrieben habe? Bitte beachten Sie, dass es für mich sehr wichtig ist, dass nur einmalige Ansichten gezählt werden.

Update: Zusätzlich zu den Implementierungsmethoden möchte ich auch weiter verstehen, wo die Leistungsprobleme ins Spiel kommen, indem man den naiven Ansatz einfach prüft, ob die IP existiert und die Spalte 'view' auf jedem aktualisiert Seitenansicht. Das Hauptproblem ist eine große Anzahl von Einfügungen (unter der Annahme starken Datenverkehrs) oder eher die Größe der Objekt-zu-IP-Zuordnungstabelle (die sehr groß sein kann, da für jeden neuen eindeutigen Besucher eine neue Zeile pro Frage eingefügt wird). Sollten Race-Bedingungen in Betracht gezogen werden (ich nahm einfach an, dass eine update/increment SQL-Anweisung atomar war)? Sorry für alle Fragen, aber ich bin nur verloren, wie ich das angehen sollte.

Answer 1

Es scheint einen revolutionären Ansatz (über den Kopf) zu geben, von dem ich selbst noch nicht sicher bin, ob er skalierbar oder eher machbar ist.

Wenn Sie wirklich die IP in DB speichern möchten und vermeiden möchten, dass Ihre DB verstopft wird, sollten Sie sie in einer hierarchischen Reihenfolge speichern.

<ID, IP_PART, LEVEL, PARENT_PART, VIEWS> 

so, wenn ein Benutzer ur Website von IP 212.121.139.54 besucht, würden die Reihen in ur-Tabelle sein:

< 1, 212, 1, 0, 0> < 2, 121, 2, 1, 0> < 3, 139, 3, 2, 0> < 4, 54, 4, 3, 1>

Punkte zu beachten:

1. Nur Zeilen mit LEVEL val = 4, haben die Anzahl der Aufrufe.
2. Um Redundanz zu vermeiden, VIEWS zu speichern val = 0, für LEVEL val = 1,2,3; Sie können daran denken, sie in einer anderen Tabelle zu speichern.
3. Die Idee, wie sie konzipiert wurde, scheint nicht geeignet für eine kleine Reihe von IPs.
4. Obwohl dies möglicherweise die Tatsache vernachlässigt haben, dass eine öffentliche Proxy-IP vor einem privaten Netzwerk Zugriff auf Ihre Website von mehr als einer Box. Aber das scheint nicht so zu sein. Ich vermute.

also, chao, lass mich wissen, was hast du implementiert?

Answer 2

Wenn Sie eindeutige Ansichten speziell verfolgen müssen, gibt es wahrscheinlich zwei Möglichkeiten, dies zu tun ... es sei denn, Sie arbeiten mit internen Benutzern, die Sie identifizieren können. Um dies zu tun, müssen Sie jeden Benutzer, der die Seite besucht hat, im Auge behalten.

Tracking kann entweder serverseitig oder clientseitig erfolgen.

Server-Seite müssen IP-Adressen sein, es sei denn, Sie haben mit internen Benutzern zu tun, die Sie identifizieren können. Und immer, wenn Sie mit IP-Adressen arbeiten, treffen Sie alle üblichen Vorbehalte, wenn Sie sie zum Identifizieren von Personen verwenden (es könnte mehrere Benutzer pro IP oder mehrere IPs pro Benutzer geben), und Sie können nichts dagegen tun.

Sie sollten auch bedenken, dass die "riesige IP-Tabelle des Todes" ist nicht so schlecht von einer Lösung. Die Leistung wird nur dann ein Problem, wenn Sie Hunderttausende von Benutzern haben ... vorausgesetzt, sie ist richtig indiziert.

Client-Seite beinhaltet wahrscheinlich Sie verlassen ein "Ich habe besucht!" Plätzchen. Wenn der Cookie NICHT vorhanden ist, erhöhen Sie Ihre Benutzeranzahl. Wenn der Cookie nicht erstellt werden kann, müssen Sie mit einer überhöhten Benutzeransicht leben. Und all die Vorbehalte gegen den Umgang mit Cookies gelten ... das heißt, sie werden irgendwann schlecht werden und verschwinden.