¿Debo generar el id de los documentos en un CouchDB o debería depender de CouchDB para generarlo? ¿Cuáles son las ventajas o desventajas de estos enfoques? ¿Hay alguna implicancia de rendimiento en cualquiera de estas opciones?¿Qué es mejor: la identificación generada automáticamente o la asignación de identificación manual en documentos couchdb?
No hay diferencia en lo que se refiere a CouchDB. Frederick tiene razón en que los identificadores secuenciales son ligeramente más rápidos. Si consulta /_uuids?count=10, verá que los UUID son secuenciales (por defecto).
Sin embargo, incluso con identificadores aleatorios, una vez que ejecuta la compactación, todos estarán en el orden "correcto" internamente en el archivo .couch y en ese punto no hay diferencia. Entonces, a la larga, generalmente no me preocupo por eso.
Lo principal es que debe usar la mayoría de los identificadores secuenciales. Como this article y este bit de couchdb book explican, el uso de identificadores aleatorios da como resultado una estructura interna mucho menos eficiente, tanto en velocidad como en términos de espacio utilizado en el disco.
[Wiki oficial] (http://wiki.apache.org/couchdb/HttpGetUuids) significa algoritmo de "secuencia" si utiliza la generación de ID de CouchDB. En nuestro proyecto, decidimos generar identificaciones de forma independiente como esta: ** sha1 (uuid()) ** para disminuir las solicitudes GET a CouchDB –
Señor, ¿qué pasa con el problema que surgen por las identificaciones secuenciales? No podemos usar identificadores secuenciales en las URL de las aplicaciones debido a que otros ID son predecibles usando una ID, y usando ID largos ya que la autenticación no es posible, –
Los ID autogenerados son casi imposibles de tratar si tiene dos o más instancias separadas de su aplicación. Porque la sincronización entre las diferentes instancias no es instantánea. Una solución para esto puede ser tener un servidor dedicado a generar (o verificar la disponibilidad de) los identificadores, por ejemplo, utilizando una base de datos SQL, y actuando como una puerta para la creación de documentos.
Por otro lado, si solo tiene un servidor y nunca necesitará más, hay una ventaja que me parece interesante para los uidos autogenerados: dado que tienen que ser únicos, puede usarlos en urls. Por ejemplo, tome la babosa del título de una publicación de blog como _id.
En cuanto a rendimiento, los id. Generados por CouchDB son bastante largos, por lo que si sus identificaciones son más cortas, ahorrará mucho espacio en disco (suponiendo que tenga un montón de documentos).
¿Quiere decir usar BigCouch (varias instancias)? –
@DmitrySorin Me refiero a la replicación bidireccional. No sé mucho sobre BigCouch, pero por lo que acabo de leer, podría resolver el problema ... – Simon
Ambas respuestas arriba dicen sobre PROS de identificadores secuenciales. Aquí surge un problema importante con los ID secuenciales.
Previsibilidad de otros ID en documentos con un único ID.
Debido a esto, no podemos utilizar identificaciones consecutivas en las URL de la aplicación como identificadores debido a otras identificaciones ser predecible utilizando un ID, y el uso de la autenticación url tampoco es posible. (Como se ha hecho por los servicios de intercambio de archivos).
Por secuencial te refieres a 'aumentar en orden', ¿no? ¿No se incrementa en 1 o en cualquier otro número constante? –
Derecha. Los ID son cadenas, por lo que para aumentar el rendimiento, quiere que cada uno sea "mayor" que el otro, usando una comparación de cadenas. Sin embargo, como dije, cuando ejecuta la compactación, CouchDB crea un árbol equilibrado independientemente de sus ID, de modo que el aumento del rendimiento es solo temporal. – JasonSmith