Nota de marzo de 2017: se puede encontrar información detallada sobre el bus de eventos y la recopilación de métricas en el documentación oficial. Parte de la información de este artículo puede estar obsoleta.
Mientras Europa se derretía con el calor del verano, Simon (desde París), Sergey (de Minsk) y I (de Viena) reutilizó el calor y preparó una nueva versión para ti. Se trata de la segunda versión preliminar para desarrolladores de la próxima versión 2.2.0. Aparte de las correcciones de errores (que también se incluyeron en la versión 2.1.4), trae las siguientes mejoras y nuevas características
- Mayor compatibilidad con N1QL y el escalado multidimensional (MDS)
- Mejoras en las API Sync y Async
- Mejoras de la compatibilidad con métricas
- Varias actualizaciones de dependencias y cambios en el DCP
Aquí te explicamos cómo conseguirlo ahora mismo:
https://gist.github.com/daschl/5b32706a0a4fe50cfaa4.js
Compatibilidad ampliada con N1QL y MDS
La funcionalidad N1QL DSL ha sido extendida para soportar una variedad de funciones N1QL, incluyendo (pero no limitadas a) agregación, array, comparación, fecha, meta, concordancia de patrones y funciones de cadena. Todas estas funciones se encuentran bajo el namespace "com.couchbase.client.java.query.dsl.functions" y deben ser importadas como métodos estáticos de ayuda por conveniencia.
Dado que Multi-Dimensional Scaling también afecta a los buckets Memcached (no todos los nodos tienen que ser nodos de datos), el SDK ahora se asegura automáticamente de que sólo esos nodos de datos se utilizan en el algoritmo de hashing ketama. Esto es completamente transparente para el usuario, pero es importante elegir 2.2.0 o posterior si quieres usar Couchbase Server 4.0 con MDS y cubos memcached. El SDK 1.4.x no se ve afectado y seguirá funcionando sin problemas.
Finalmente, para asegurarnos de que todas las APIs son consistentes, hemos optado por renombrar las consultas "parametrizadas" a "parametrizadas", que se considera la forma correcta en toda la documentación de Couchbase y las APIs del SDK.
Mejoras en las API Sync y Async
Uno de los problemas comunes de la API asíncrona es que los observables devueltos eran "calientes" en lugar de "fríos". Esto tiene sutiles implicaciones en la semántica del reintento y la reutilización. Especialmente si se desea utilizar el operador de reintento, es necesario "diferir" el observable devuelto para que en cada resuscripción se genere un nuevo observable. En la versión 2.2.0 hemos decidido hacer que todas las llamadas a la API sean frías, envolviéndolas desde el principio. El código existente seguirá funcionando, e incluso los aplazamientos dobles no causarán ningún daño.
Compare este código de reintento con el de 2.1.4:
https://gist.github.com/daschl/0666841cb2bd69e53d17.js
con la ligeramente más sencilla contra 2.2.0:
https://gist.github.com/daschl/2b63c5193bac4dd11713.js
Dado que las llamadas getFromReplica sirven para primar la disponibilidad sobre la consistencia, a menudo tiene sentido limitarse a tomar los N primeros documentos devueltos. Aunque esto es bastante fácil de hacer en la API asíncrona con el operador "take()", la API síncrona sólo ofrecía una versión List. Para que sea más flexible para los usuarios que trabajan con la API de bloqueo, se han añadido nuevas sobrecargas que ahora devuelven un Iterator en su lugar. Si sólo te interesa el primer documento devuelto, puedes hacerlo de la siguiente manera:
https://gist.github.com/daschl/0c7c92642d8c0af7dae3.js
Anteriormente no era posible fallar en una operación de contador si el documento no existía - siempre se inicializaba con 0. Dado que esta característica estaba disponible en la serie 1.x, hemos decidido traerla de vuelta en la sobrecarga del método donde no se especifica ningún valor por defecto.
Así que en 2.2.0, esta sobrecarga del método "Observable counter(String id, long delta)" fallará con una "DocumentDoesNotExistException" si el documento no existe. Si quieres el comportamiento anterior, simplemente usa la sobrecarga con el valor inicial y ponlo a 0.
Por último, el SDK soporta ahora más opciones de configuración del entorno (incluyendo la posibilidad de configurar TCP_NODELAY) y los documentos de diseño pueden configurarse ahora con opciones en el momento de su creación. A continuación se explica cómo crear un documento de diseño y cambiar el intervalo mínimo de actualización por defecto:
https://gist.github.com/daschl/ddec1089eed01285d0c4.js
Mejoras de la compatibilidad con métricas
Una pregunta común que se hacen los desarrolladores y los operadores es: ¿qué está pasando dentro de mi aplicación? Y también muy a menudo relacionada: ¿por qué obtengo una TimeoutException? Hemos estado depurando despliegues de producción durante algunos años y hemos aprendido un par de cosas mientras lo hacíamos. Una de las cosas más importantes es la información. Cuanta más información puedas obtener de tu aplicación, mejor podrás entenderla.
Precisamente por este motivo, hemos añadido al SDK métricas de latencia y tiempo de ejecución siempre activas que se publican a través del bus de eventos y pueden consumirse como mensajes. Hay una gran diferencia entre limitarse a registrar datos y exponerlos a través de un bus de eventos (aunque también se registren posteriormente). Te permite consumirlos y, lo que es más importante, reaccionar ante ellos al instante. Puede tomar los datos y enviarlos a su sistema de monitorización favorito como nagios, graphite o logstash. No hay necesidad de analizar archivos de registro en las secuelas de una interrupción del sistema que tiene personal para analizar.
Por defecto, el SDK recopilará de forma transparente las latencias de las operaciones que se ejecuten a través de él y las escribirá en el bus de eventos cada hora. El intervalo de emisión, así como muchos otros ajustes, son totalmente personalizables a través del entorno. Aquí hay un ejemplo simple que escucha en el bus de eventos y sólo imprime eventos métricos a stderr (estamos distribuyendo muchos más eventos que los del bus para proporcionar la máxima flexibilidad):
https://gist.github.com/daschl/51e5193a57d909fd072b.js
Aquí puedes ver dos eventos. El primero imprime información en tiempo de ejecución como estadísticas de GC, memoria y uso de hilos. El otro es ligeramente más grande y contiene estadísticas de latencia (y rendimiento) recogidas en histogramas internos. La información impresa contiene latencias mínimas y máximas, el número de operaciones, así como percentiles. Bajo las cubiertas estamos utilizando el excelente HdrHistograma y el paquete relacionado LatencyUtils.
Observe que no sólo lo imprime por operación, sino que también puede identificar el nodo de destino y el código de estado que devuelve. Esto le permite construir una forma de árbol del estado del sistema y obtener información sobre cómo están funcionando los nodos o servicios individuales (el nodo A es más lento que los demás, reemplazar es más rápido que insertar, muchos errores contra el nodo B,...).
Basándonos en los comentarios de los usuarios, estamos considerando añadir consumidores para registrar esas métricas y enviarlas a graphite o logstash. Además, vamos a añadir formatos de salida más sofisticados, incluyendo JSON con un formato agradable que es a la vez humano y máquina parasable. Por favor, háganos saber qué formato de destino le gustaría ver incorporado en el controlador.
Actualizaciones de dependencias y cambios de DCP
Dado que estamos mejorando la versión menor, también estamos actualizando las dependencias a sus últimas versiones de corrección de errores. Aquí está la lista completa de dependencias, pero tenga en cuenta que en realidad sólo exponemos RxJava como una dependencia explícita, todos los demás son reempaquetados para no causar problemas en su entorno si potencialmente tiene versiones en conflicto.
Estos son los cambios de 2.2.0-dp2 sobre 2.1.4:
- RxJava de 1.0.4 a 1.0.13
- Netty de 4.0.25.Final a 4.0.29.Final
- Disruptor LMAX 3.3.0 a 3.3.2
- Jackson de 2.4.2 a 2.5.4
- LatencyUtils nuevo en la versión 2.0.2
Además, Sergey está ocupado trabajando en la ampliación del conector Kafka, que también ha dado lugar a mejoras de DCP en la biblioteca core-io. Todavía es muy experimental, pero nos estamos acercando a un punto en el que puede ser consumido por un público más amplio.
El camino hacia la AG
Otra característica de N1QL que todavía se está incubando son las sentencias preparadas (con nombre). El código se ha actualizado en esta segunda vista previa para desarrolladores, pero aún está sujeto a cambios, por lo que hemos comentado esa API por ahora. Por favor, sea paciente hasta que nos acerquemos a GA para un soporte completo y una extensa documentación.
Aparte de eso, no hay grandes características en la lista de tareas pendientes para 2.2.0, por lo que estamos cambiando de marcha hacia pequeñas correcciones, mejoras de estabilidad y lo más importante la documentación. Para que esta versión sea la mejor que hemos lanzado hasta ahora, ¡necesitamos tu opinión! Por favor, pruébala y danos tu opinión, especialmente sobre las nuevas funciones y la compatibilidad con N1QL. ¡Háganos saber lo que falta o roto ya sea a través de un comentario aquí, en los foros oa través del rastreador de errores!
