2011-09-12 14 views
5

Quiero almacenar contadores en un documento CouchDB, incrementado en cada vista de página. CouchDB creará una revisión completa de este documento para solo 1 actualización de contador.Cómo evitar que CouchDB cree revisiones de documentos al actualizar contadores simples

¿No consumiría demasiado espacio? Considerando que tengo 1M de visitas en un día, podría estar mirando revisiones de 1M al documento en un día.

Cualquier pensamiento sobre esto ...

¡Gracias!

Respuesta

7

CouchDB es muy explícito acerca de las compensaciones que realiza. En este caso particular, estamos hablando de tener una base de datos de prueba de fallas que, por desgracia, puede y usará una gran cantidad de disco hasta la compactación.

Obtiene esta confiabilidad y mucha concurrencia para las lecturas. También obtendrá la capacidad de replicarse a la perfección con cualquier otro nodo. Este es el tocino de eso. Tener que compactar debido a los contadores golpeados es una mierda. Olvídate de perder el tiempo con _rev_limit. Te enloquecerás haciéndolo porque las revisiones son tan fundamentales para Couch.

Una posibilidad que tiene es registrar alguna información, la fecha y la hora, IP y otras cosas. Luego crearía una vista que emitiría los datos que necesita y usar _count como función de reducción. Obtendrá la información que necesita y algunas otras cosas posiblemente valiosas para el análisis. Esta es la solución "solo crear una vista".

La segunda posibilidad sería usar redis (http://redis.io/commands/incr). Redis es bastante agradable y encajaría bien con este caso de uso (http://ai.mee.nu/is_couchdb_the_anti-redis). Esta sería la solución "la herramienta adecuada para el trabajo correcto".

La tercera posibilidad sería simplemente ignorarlo. Puede que no sea un problema en absoluto (si compactas a menudo). Esta sería la solución "simplemente relajarse".

Tienes que tomar lo bueno con lo malo y asegurarte de que las ventajas superen las desventajas. Mida todo dos veces antes de cortar/optimizar.

3

No creo que sea posible.

Una solución alternativa sería colocar el contador en un documento pequeño y ejecutar compaction periódicamente. Esto no es óptimo, pero minimiza el espacio ocupado.

+0

Estoy de acuerdo, pero creo que debería haber una mejor manera de solucionar este problema. Estoy explorando la limitación de las revisiones de un documento determinado. Actualizaré esta pregunta con mis hallazgos ... –

+0

Algunas investigaciones revelan este hilo - http://www.mail-archive.com/[email protected]/msg01974.html –

+0

Si una base de datos está configurada con _revs_limit = 1, ¿el feed de resolución de conflictos y cambios seguirá funcionando? Hipotéticamente, para mantener un contador de incremento, podemos tener dicho par clave/valor en el documento cuya base de datos está configurada con _revs_limit = 1 ¿Pensamientos? Gracias! –

1

También puede considerar usar algo como memcached (o Membase) para que sirva como su "contador de almacenamiento". Eso le permitirá actualizar estos contadores sin crear revisiones adicionales en CouchDB. Supongo que no es necesario que guardes todos los estados intermedios del contador (ya que dices que no quieres que las revisiones se mantengan) por lo que ponerles algo más adecuado para este caso de uso parece tener sentido.

0

Estábamos haciendo un pequeño experimento ...

el documento había predeterminado 1000 revoluciones límite, tenía alrededor de 100 KB de archivos adjuntos, 1 contador de números enteros, que nos mantuvo de incremento

Terminamos con alrededor de 4 GB disco utilizado para aproximadamente 200,000 incrementos. La compactación usada & se redujo a aproximadamente 6KB.

¡Eso es un fastidio!

Mis serias preocupaciones ahora son: realizar una compactación frecuente (tal vez cada hora/dos veces al día/etc.) en una sesión de escritura de sofá pesado.

Cuestiones relacionadas