2009-08-15 8 views
8

Quiero implementar un contador de vista orientado al usuario (similar al SO para las vistas de preguntas) que rastrea el número de vistas únicas en una página. Hay un par de preguntas similar aquí, pero ninguna parece responder a mi pregunta por completo.¿Implementar un único contador de vista de página?

¿Cuál sería la mejor configuración para esto (en términos de tablas de bases de datos, etc.)? ¿Sería bueno agregar una columna de "vistas" a la tabla de "preguntas" y simplemente incrementarla en cada vista de página? Y si quiero que las vistas sean únicas, creo que podría tener otra tabla con id de pregunta y direcciones IP y solo incrementar la columna 'ver' si todavía no hay una entrada con la IP actual. Sin embargo, esta tabla 'ip-view' se volvería enorme rápidamente ... Principalmente me preocupa la sobrecarga de tener que almacenar cada vista de página y cada IP en una tabla.

¿Cómo se podría optimizar esto para que no se convierta en un cuello de botella de rendimiento? ¿Hay un mejor enfoque de lo que describí? Tenga en cuenta que es muy importante para mí que solo se cuenten las vistas únicas.

Actualización: además de sugerir métodos de implementación, también me gustaría entender dónde entran en juego los problemas de rendimiento, asumiendo el ingenuo enfoque de simplemente verificar si existe la IP y actualizar la columna 'ver' en cada vista de pagina. El problema principal es la gran cantidad de inserciones (suponiendo mucho tráfico) o es más el tamaño de la tabla de asignación de objeto a IP (lo que podría ser enorme ya que se insertará una nueva fila por pregunta para cada nuevo visitante único). ¿Deben considerarse las condiciones de carrera (simplemente asumí que una instrucción update/increment sql era atómica)? Perdón por todas las preguntas, pero estoy perdido en cuanto a cómo debería abordar esto.

+0

Compruebe mi respuesta aquí, posiblemente: http://stackoverflow.com/questions/1269968/incremented-db-field/1269973#1269973 –

Respuesta

0

Parece haber un enfoque revolucionario (en la parte superior de mi cabeza), del cual yo mismo todavía no estoy seguro acerca de ser escalable o más bien factible.

Si realmente desea almacenar la dirección IP en DB y desea evitar que su DB se bloquee, debería pensar en almacenarlos en un orden jerárquico.

<ID, IP_PART, LEVEL, PARENT_PART, VIEWS> 

modo, cuando un usuario visita el sitio web de ur IP 212.121.139.54, las filas en la tabla ur sería:

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

Puntos a destacar:

  1. Solo las filas con LEVEL val = 4, tendrán el conteo de las vistas.
  2. Para evitar la redundancia de almacenar VIEWS val = 0, para LEVEL VAL = 1,2,3; puedes pensar en almacenarlos en una tabla diferente.
  3. La idea, tal como se concibió, no parece adecuada para un pequeño conjunto de direcciones IP.
  4. Aunque esto puede haber descuidado el hecho de que un IP proxy público se encuentre frente a una red privada accediendo a su sitio web desde más de un cuadro. Pero eso no parece ser tu pregunta. supongo.

Así que, chao, déjame saber qué implementaste?

6

Si necesita rastrear vistas únicas específicamente, probablemente existan dos formas de hacerlo ... a menos que esté operando con usuarios internos que pueda identificar. Ahora, para hacer esto, necesita hacer un seguimiento de cada usuario que ha visitado la página.

El seguimiento se puede realizar desde el lado del servidor o desde el lado del cliente.

La parte del servidor tendrá que ser una dirección IP, a menos que se trate de usuarios internos que pueda identificar. Y cada vez que maneja direcciones IP, se aplican todas las advertencias habituales sobre su uso para identificar personas (puede haber varios usuarios por IP o múltiples direcciones IP por usuario) y no puede hacer nada al respecto.

También debe considerar que la "enorme tabla de IP de la muerte" no es tan malo como una solución. El rendimiento solo será un problema si tienes cientos de miles de usuarios ... suponiendo que esté indexado correctamente, por supuesto.

El lado del cliente probablemente implique que deje un "He visitado!" Galleta. Si la cookie NO está presente, entonces incremente su número de usuarios. Si no se puede crear la cookie, tendrá que vivir con una vista de usuario inflada. Y todas las advertencias sobre el trato con las cookies se aplican ... lo que quiere decir que al final se irán mal y desaparecerán.

Cuestiones relacionadas