Rendimiento de ID largos

Question

Me he estado preguntando sobre esto durante un tiempo. En CouchDB tenemos algunos identificadores de registro bastante ... por ejemplo:

"000ab56cb24aef9b817ac98d55695c6a"

Ahora bien, si estamos en busca de este artículo y pasando por la estructura de árbol creado por la vista. Parece un número entero simple ya que una identificación sería mucho más rápida. Si utilizamos enteros de 64 bits, sería un CMP simple seguido de un JMP (suponiendo que el código de Erlang estuviera usando JIT, pero entiende mi punto).

Para cadenas, supongo que generamos un hash de la ID o algo así, pero en algún momento tenemos que hacer una comparación de caracteres en los 33 caracteres ... ¿no afectará eso al rendimiento?

Answer 1

La respuesta corta es, sí, por supuesto que afectará el rendimiento, ya que la longitud de la clave afectará directamente el tiempo que lleva recorrer el árbol.

También afecta al almacenamiento, ya que las claves más largas ocupan más espacio, el espacio lleva tiempo.

Sin embargo, el matiz que se está perdiendo es que aunque Couch CAN (y lo hace) asignó nuevos ID para usted, no es necesario. Será más que feliz de aceptar sus propias identificaciones en lugar de generarlas. Por lo tanto, si la duración de la clave te molesta, puedes utilizar claves más cortas.

Sin embargo, dada la naturaleza "json" del sofá, es una base de datos basada en "texto". No hay una gran cantidad de datos binarios almacenados en una instancia de Couch normal (sin embargo, los archivos adjuntos no son compatibles, pero incluso aquellos que creo que están almacenados en BASE64, puedo estar equivocado).

Entonces, si bien un 64-bit sería el más eficiente, el simple hecho es que Couch está diseñado para funcionar con cualquier tecla, y "cualquier tecla" se expresa más fácilmente en el texto.

Finalmente, a decir verdad, el costo de la comparación de claves es empequeñecido por los tiempos de captación de E/S de disco, y la recopilación de datos JSON (especialmente en escrituras). Cualquier ganancia real lograda mediante la conversión a un sistema de este tipo probablemente no tenga un impacto del "mundo real" en el rendimiento general.

Si realmente desea acelerar el sistema de llaves Couch, codifique la rutina de teclas para bloquear la clave en longitudes de 64 bits, y compárelas (como usted dijo). 8 bytes de texto son lo mismo que 64 bits "long int". Eso te daría, en teoría, un aumento de rendimiento de 8 veces en comparación de claves. Si erlang puede crear dicho código, no puedo decirlo.

Answer 2

Desde el CouchDB: La guía definitiva:

Necesito hacer un dibujo de esto en algún momento, pero la razón es que si piensa en la árbolB idealizada, cuando uso UUID puede estar golpeando cualquier número de nodos raíz en ese árbol, por lo que con la naturaleza solo anexar tiene para escribir cada uno de esos nodos y todo lo anterior en el árbol. pero si usa monótonamente identificadores entonces está invalidando la misma ruta en el lado derecho del árbol minimizando así la cantidad de nodos que deben reescribirse. sería ser el mismo para monótonamente disminuyendo también. y debería funcionar técnicamente si se puede garantizar que las actualizaciones lleguen a uno o dos nodos en el interior del árbol, aunque es mucho más difícil de probar.

Los identificadores secuenciales ofrecen un beneficio de rendimiento, sin embargo, debe recordar que esto no se puede mantener cuando tiene más de una base de datos, ya que los ID colisionarán.