Aprende sobre pruebas de rendimiento para escrituras duraderas con SDK 3.0+ y cómo configurar la infraestructura usando cbc-pillowfight de Couchbase.
Las pruebas de rendimiento de la durabilidad con cualquier base de datos pueden ser subjetivas y complicadas porque hay otros factores que influyen en el rendimiento. La durabilidad es la capacidad de escribir en copias activas, réplicas y persistentes de los datos. Couchbase tiene diferentes niveles de durabilidad basados en el caso de uso y SLA. Pero en última instancia, la velocidad de la red, la velocidad de escritura del disco y los recursos de CPU disponibles son tan sensibles al rendimiento como la propia base de datos.
¿Qué define el rendimiento (o alto rendimiento) de las escrituras duraderas? ¿Es la latencia de la operación? ¿Es el rendimiento (operaciones por segundo)? Depende del caso de uso. La respuesta popular suele ser... ¡AMBAS!
Actualizaciones de durabilidad en el SDK de Couchbase
Las versiones anteriores del SDK de Couchbase (Pre-3.0) tienen escrituras duraderas con los parámetros replicateTo y persistTo. ReplicateTo espera a que se complete la escritura de 1 a 3 réplicas. PersistTo espera a que también se escriba en la copia activa en disco. Los desarrolladores querían un control más preciso y un mayor rendimiento con escrituras duraderas en las réplicas y el disco.
Couchbase SDK 3.0 fue lanzado hace aproximadamente un año. Una actualización fundamental de la nueva versión del SDK es la durabilidad, teniendo en cuenta tanto la latencia como el rendimiento.
Véanse las definiciones en la documentación:
Hay tres niveles de durabilidad:
- Mayoría - El servidor se asegurará de que el cambio esté disponible en memoria en la mayoría de las réplicas configuradas.
- MayoríaYPersistenciaActiva - Nivel mayoritario, más persistencia en disco en el nodo activo.
- PersistToMajority - Nivel mayoritario, más persistencia en disco en la mayoría de las réplicas configuradas.
Cada nivel de durabilidad tiene un impacto en el rendimiento, ya que el SDK esperará a que se complete la escritura utilizando mayoría, persistToo ambos.
En mi experiencia de trabajo con clientes con experiencia en bases de datos relacionales, la decisión instintiva es optar por el nivel de durabilidad más alto. Pero su experiencia es muy diferente, ya que los RDBMS tienen la durabilidad integrada en la arquitectura para no permitir las lecturas antes de que se realicen las escrituras.
Mientras que Couchbase tiene un control más detallado sobre los ajustes de durabilidad de lo que los usuarios de RDBMS tradicionales podrían haber esperado. Por ejemplo, Couchbase también tiene un durabilidad del nivel del cubo ajuste.
Además, la elección de la durabilidad es específica del caso de uso, la aplicación y los SLA. Si la durabilidad a nivel de bucket no es suficiente control, Couchbase soporta durabilidad escritura a escritura - cada escritura individual puede configurarse para una durabilidad específica o puede establecerse a nivel de cubo, es decir, todas las escrituras seguirán el mismo nivel de durabilidad.
Consideraciones sobre la configuración del servidor para las pruebas
Aún más importante que el mecanismo de durabilidad dentro de la arquitectura de la base de datos son las especificaciones de la máquina de alojamiento para probar el rendimiento de las escrituras duraderas. Couchbase nunca colocará una copia activa y una réplica en el mismo disco; autoguardamos los datos y garantizamos que las réplicas no residirán con una activa estando así en un nodo diferente.
Esto significa que la escritura en las réplicas se ve afectada por la velocidad y la latencia de la red. Cuanto más rápida sea la red, más rápida será la escritura duradera a la réplica, es decir, a la mayoría. El factor más influyente de la máquina de alojamiento para las escrituras duraderas es la latencia y el rendimiento del disco. Couchbase recomienda SSDs locales para la persistencia, no sólo por la velocidad sino por la recuperación rápida y eficiente de un nodo en caso de fallo.
Consideraciones sobre la nube pública
En la actualidad, cada vez más clientes realizan pruebas y POC en entornos de nube pública por motivos de rapidez, sencillez e inversión temporal de recursos.
Selección de almacenamiento/disco
En la nube pública, todos los proveedores disponen de distintos niveles de almacenamiento en disco para las instancias de máquina: desde el almacenamiento de tipo EBS, que suele ser el más lento, hasta las unidades SSD NVRAM de alto rendimiento.
Cualquier tipo de almacenamiento funcionará, pero la evaluación debe tener en cuenta que el rendimiento de los tipos de volumen es, posiblemente, el factor más importante para las escrituras duraderas, independientemente de la base de datos que se esté evaluando. Por ejemplo, este enlace de documentación de AWS muestra lo complicados que pueden ser los tipos de almacenamiento en la nube pública.
Selección del tipo de instancia
Los clientes que han probado con éxito la durabilidad de Couchbase intentan hacer coincidir el entorno de pruebas con su entorno alojado de producción. Sin embargo, los clientes también despliegan t3.grande o t3.pequeño para probarlo y luego preguntar por qué no funciona.
Escenarios de red
Asegúrese de que el cliente está en la misma red que el entorno del servidor para obtener el mejor rendimiento. A menudo, las pruebas de baja calidad se ejecutan en un ordenador portátil a través de la red inalámbrica a un nombre de host expuesto públicamente en una nube pública. Hay tantos saltos de red desde la conexión inalámbrica al router, la red pública, la red alojada, etc. que las latencias son enormes.
En resumen, con el manejo de eventos para escrituras duraderas, Couchbase tiene escrituras muy rápidas. Las escrituras duraderas se realizan tan rápido como el entorno de alojamiento lo permita y/o esté configurado para ello.
Pruebas de durabilidad de Couchbase
La durabilidad puede ser probada usando cualquier aplicación que ya hayas creado con el SDK de Couchbase, sin embargo, para simplificar y estandarizar las pruebas, una de nuestras herramientas puede ayudar.
Couchbase Server incluye una herramienta de línea de comandos de medición del rendimiento llamada cbc-pillowfight. Pillowfight ha sido parte de Couchbase durante años, por lo que es una roca sólida para las pruebas de rendimiento. Pillowfight está basado en el C SDK de Couchbase por lo que es altamente eficiente. Es muy rápido, ¡hasta el punto de ser demasiado rápido! ¿Qué quiero decir con "demasiado rápido"? Voy a llegar a eso en un momento.
La información de instalación y configuración se presenta en este blog anterior con respecto a las pruebas de Couchbase con pillowfight y algunos escenarios de ejemplo se presentan a continuación.
Opciones para las pruebas de rendimiento con pillowfight
Los ajustes por defecto de pillowfight pueden no ser óptimos para el tipo de aplicación que vas a utilizar con Couchbase. Hay muchas formas de ajustar pillowfight para que se adapte mejor a tus casos de uso. Para ver la lista completa de opciones, escribe cbc-pillowfight -help en la línea de comandos.
He aquí algunas opciones notables que quizá quiera probar:
- -I o -num-items con un número, para especificar sobre cuántos documentos desea operar.
- -json para utilizar cargas JSON en los documentos. Por defecto, los documentos se crean con cargas útiles no JSONpero es posible que desee disponer de documentos JSON reales para probar otros aspectos del rendimiento mientras se ejecuta la lucha de almohadas.
- -e para que los documentos caduquen después de un cierto periodo de tiempo. Si estás usando Couchbase como caché o almacenamiento a corto plazo, querrás usar esta configuración para monitorizar el efecto de los documentos que caducan.
- -subdoc para utilizar la API de subdocumentos. No todas las operaciones tendrán que realizarse en un documento entero.
- -M o -tamaño máximo para fijar un límite al tamaño de los documentos. Es posible que desee ajustar esto para adaptar un tamaño de documento más realista para su sistema. También existen los correspondientes -m y -min-size
He aquí otro ejemplo utilizando las opciones anteriores:
cbc-pillowfight.exe -U couchbase://localhost/pillow -u Administrador -P contraseña -I 10000 -json -e 10 -subdoc -M 1024
Esto iniciará una pelea de almohadas usando 10000 documentos JSON, que expiran después de 10 segundos, usan la API de sub-documento, y tiene un tamaño máximo de documento de 1024 bytes.
Nota: Existe un -t -num-threads opción. Actualmente, si utiliza Windows (como yo), está limitado a un único subproceso (véase este código).
Pillowfight puede ajustarse para operaciones específicas, especialmente duraderas escribe pruebas de rendimiento.
Repasemos este comando de pelea de almohadas:
cbc-pillowfight -U / -u -P -I 2000 -set-pct=100 -min-size=100 -max-size=250 -t 10 -durability majority_and_persist_to_active -no-population
¿Qué hace este comando?
-I 2000 es el número de artículos, 2000.
-set-pct=100 is 100% de las operaciones son escrituras. Si se establece en 50, entonces 50/50 de escrituras a lecturas.
-tamaño-mín=100 es un documento de tamaño mínimo de 100 bytes.
-tamaño-máx=250 es un documento de tamaño máximo de 250 bytes. Pillowfight aleatorizará los documentos de 100 a 250 bytes.
-t 10 es de 10 hilos
-durabilidad mayoría_y_persistencia_a_actividad es el ajuste de durabilidad. El SDK escribirá en la mayoría de las réplicas si hay más de una y esperará a que persista la copia activa en disco.
-sin población consigna la escritura y luego la borra.
Gestión de hilos/buffers
Este comando seguirá creando documentos y escribiendo en Couchbase tan rápido como sea posible. Pillowfight creará una lista de claves como un array y escribirá recursivamente. Una vez que llegue al final, volverá al principio del array y comenzará a escribir las mismas claves de nuevo.
¿Recuerdas mi comentario anterior de "demasiado rápido"? Al probar la durabilidad, especialmente en entornos de alojamiento lentos con redes lentas y almacenamiento masivo (EBS S3), pillowfight será mucho más rápido que la infraestructura. Esto significa que un hilo pillowfight todavía estará esperando para terminar mientras que otro hilo está esperando para hacer la siguiente escritura.
¿Cómo podemos crear una prueba que realmente compruebe la durabilidad? Haz que el buffer de teclas sea grande y no vuelvas al principio.
cbc-pillowfight -U / -u -P -I 2000000 -set-pct=100 -min-size=100 -max-size=250 -t 10 -durability majority_and_persist_to_active -batch-size 1 -no-population
¿Cuál es la diferencia entre estos comandos? El comando anterior crea una lista de 2 millones de claves y sólo la recorre una vez. Esto garantizará que un hilo no estará esperando la escritura de un hilo anterior para completar el mismo documento. Esto está realmente probando la capacidad de Couchbase y del entorno de hospedaje de escrituras duraderas. Es posible eliminar tamaño del lotelo más probable es que no haya hilos esperando para escribir.
Incluso si la prueba no utiliza pillowfight, la aplicación y los criterios de prueba deben ser conscientes de que si se va a utilizar recursivamente un búfer de documentos, existe la probabilidad con hilos de que una escritura pueda estar esperando a que se complete otra escritura.
Conclusiones
Couchbase es bastante capaz de realizar escrituras de alto rendimiento, pero cada caso de uso y las condiciones son únicas para la prueba. Configurar el entorno de pruebas adecuado es fundamental para cualquier prueba de escritura duradera.
Pillowfight es una gran herramienta para probar Couchbase con muchas de las características ya incorporadas como el establecimiento de la proporción de lecturas a escrituras, hilos, tamaño del documento, y los niveles de durabilidad.
Si se está creando la aplicación de prueba, es importante realizar pruebas que pongan a prueba realmente la base de datos y la infraestructura. Los resultados son subjetivos no sólo para la base de datos, sino también para el entorno en el que se ha probado.
Si tiene alguna pregunta, póngase en contacto conmigo en james.powenski@couchbase.com Estaré encantado de ayudarle.