La captura de señales de interés implícita en Django

Question

Para configurar el fondo: Estoy interesado en:

• La captura de señales implícitas de interés en los libros como a los usuarios navegar por un sitio. El sitio está escrito en django (pitón) utilizando MySQL, memcached, ngnix, y Apache

Digamos, por ejemplo, mi sitio vende libros. A medida que un usuario navega alrededor de mi sitio me gustaría hacer un seguimiento de lo que los libros que han vistos, y cuántas veces los han vistos.

No es que yo almacenar los datos de esta manera, pero lo ideal sería que pudiera tener sobre la marcha el acceso a una estructura como:

{user_id : {book_id: number_of_views, book_id_2: number_of_views}}

Sé que existen algunos enfoques aquí:

• Algunos de registro de archivo plano
• Escribir un objeto a una base de datos cada vez
• Al escribir a un objeto en memcached

No sé realmente las implicaciones de rendimiento, pero preferiría no estaría escribiendo a una base de datos en cada visita de página única, y el retraso de la escritura en un registro y el cálculo de la estructura posterior no parece lo suficientemente rápido como para dar buenas recomendaciones sobre la marcha y cuando se utiliza el sitio, y la appraoch memcached parece muy bien, pero hay un costo en mantener este obj en la memoria:. es posible que pierda, y que nunca se escribe en alguna parte 'permanente'

¿Qué enfoque sugiere usted? (No tiene que ser uno de los anteriores) Gracias!

Answer 1

Si estos datos no es una estadística poco importantes que podrían o no estar disponibles Yo sugeriría tomar el enfoque simple y el uso de un modelo. Seguramente va a golpear la base de datos cada vez.

A menos que esté absolutamente seguro de que estas consultas positivamente son en realidad degradar la experiencia en general no hay necesidad de preocuparse por ello. Incluso si optimiza éste, hay una buena probabilidad de otro inesperada consultas están perdiendo más tiempo de CPU. Asumo que usted no estaría haciendo esta pregunta si estuviera probando todas las otras consultas. Entonces, ¿por riesgo optimización prematura en este caso?

Una ventaja del enfoque de modelo sería tener una API en su sitio . Cuando se han probado y decidió optimizar puede mantener esta API y cambiar el modelo subyacente con otra cosa (que muy probablemente será más complejo que un modelo).

sin duda me quedo con un modelo primero y ver cómo se realiza. (Y también cómo otras partes del proyecto realizan)

Answer 2

¿Qué enfoque sugeriría usted? (No tiene que ser uno de los anteriores) Gracias!

Hmmmm ... esto como estar en una habitación de cuatro paredes con una sola puerta y diciendo que quiero salir de la habitación, pero no a través de la única puerta ...

Hubo un artículo que estaba leyendo en algún momento posterior (no se puede obtener el enlace ahora) que dice Memcache puede manejar enormes (facebook lo utiliza) conjuntos de datos en la memoria con muy poca degradación en el rendimiento ... mi consejo es que será necesario explorar más en memcache, creo que va a hacer el truco.

Answer 3

Ya sea un almacén de datos de documentos (mongo / couchdb), o un almacén persistente valor de la clave (tokyodb, memcachedb etc) pueden ser explorados.

No hay recomendaciones definitivas de mí como la solución final depende de múltiples factores - la carga, su voluntad de aprender / desplegar una nueva tecnología, el tamaño de los datos ...

Answer 4

Me parece que uno de los enfoques podría ser el uso de memcached para mantener el contador, pero tienen un cron ejecuta regularmente para almacenar el valor de memcached con el PP o el disco. De esa manera se obtendría todo el rendimiento de memcached, pero en el caso de un accidente que no perdería más de un par de minutos a los datos.