¿Por qué las lecturas de CouchDB son tan lentas? (1.5MB/so más o menos)

Question

Tengo un servidor CouchDB (1.1.1) en ejecución que contiene una gran cantidad de documentos en el rango de tamaño 400-600KB.

Si llego a la hora de obtener un documento completo de la base de datos (no desde una vista, solo el documento sin procesar) se necesitan 200-400ms para completar, lo que equivale a alrededor de 1.5MB/s de rendimiento.

Si escribo los mismos datos en archivos sin procesar en el disco, se cargan en 10-20ms (alrededor de 25-50 MB/s).

Espero que CouchDB tenga algunos gastos generales, pero un orden de magnitud (y algo) parece una locura para lo que es esencialmente una lectura.

¿Alguien puede arrojar algo de luz sobre por qué este podría ser el caso?

actualización: Como se solicita a continuación, un tiempo de rizo:

# time curl http://localhost:5984/[dbname]/[documentname] 

real 0m0.684s 
user 0m0.004s 
sys  0m0.020s 

El documento fue exagerado 642842 bytes. Lo probé tanto en un disco duro estándar de 1TB como en una instancia EC2 (volumen EBS) con resultados similares.

Answer 1

creo que esto es una serie de factores

1. usted estuviera recibiendo a través de HTTP, que es fundamentalmente un protocolo de mayor latencia. En particular, está creando una conexión TCP desde cero utilizando curl. (Los navegadores web y la mayoría del software cliente mantienen un conjunto de conexiones persistentes HTTP/1.1 keepalive). Pero, fundamentalmente, CouchDB elige un protocolo "más lento" porque es tan universal y tan estándar.
2. Sus documentos están en el tamaño más grande para CouchDB. La mayoría de los documentos son KB de uno o dos dígitos, no triples. CouchDB codifica/decodifica ese JSON en un gran trago (es decir, no está transmitiendo desde el disco).
3. EC2 (incluso EBS) no es ideal para una base de datos (tiene una alta latencia) , pero también puede fluctuar a medida que sus vecinos generan explosiones de E/S desconocidas con las que compite.
4. CouchDB es un sistema de archivos en la parte superior de un sistema de archivos. El archivo .couch se parece mucho a un sistema de archivos en sí mismo. Entonces estás multiplicando ineficiencias. El archivo .couch y los metadatos requieren una E/S aleatoria contra el almacenamiento; y leyendo el documento requiere una E/S aleatoria dentro del archivo .couch. Puede ver multiplicados los efectos de la latencia del disco. En lugar de comparar la lectura de un documento con la lectura de un archivo del sistema de archivos, puede comparar la lectura de un documento y la lectura de una fila equivalente de MySQL.

Nota, no estoy diciendo que CouchDB sea realmente rápido y sus resultados sean incorrectos. Todo lo contrario: CouchDB es más lento de lo que mucha gente espera.Hasta cierto punto, tiene espacio para mejorar y optimizar; pero principalmente CouchDB ha decidido que esos costos valen la pena por el bien general que trae.

CouchDB no supera los puntos de referencia y le da problemas a la universidad. Sugiero que el próximo banco de pruebas comparta una carga completa en CouchDB, simulando su demanda esperada de múltiples accesos concurrentes, y se acerque lo más posible a sus demandas en el mundo real. Esa será una prueba más útil y, en términos generales, CouchDB funciona de forma impresionante allí.

Dicho esto, CouchDB es una base de datos específica del dominio y puede quedar claro que también está buscando una herramienta diferente.

Answer 2

¿Cómo está recuperando el documento? Si está utilizando algún código, incluya ese código y las bibliotecas que esté utilizando.

O simplemente use curl para recuperar el documento. Ej., Acabo de hacer time curl http://localhost:5984/bwah/foo y obtuve el documento en .017s. Una nota importante es que estoy en una máquina con SSD.

Además, hacer una lectura no es suficiente para sugerir el rendimiento que puede esperar de CouchDB, o de cualquier software de servidor para el caso. Debe hacer muchas solicitudes y luego ver cuáles son los tiempos promedio y mediano.