¿Es mejor no procesar que procesar?

Hagamos un pequeño experimento mental.

Sí, lo sé, pensando. ¿Quién quiere hacer eso?

¡Espera!

Antes de que me dejes de lado y pases al siguiente post sobre índices sexys...

Al menos dame un par de minutos.

Supongamos que tiene un sitio web.

Bueno, no cualquier sitio web...

Eso es demasiado genérico.

Digamos que tienes un sitio web de viajes.

Un lugar donde la gente viene a hacer reservas de avión.

Creo que todos hemos usado uno de esos alguna vez.

Así, sus usuarios llegan a su sitio y quieren ver qué vuelos están disponibles.

¿Qué es lo primero que hacen?

¿Escriben una pregunta a mano?

Hoy en día, no.

Probablemente empiecen seleccionando desde dónde quieren salir.

Su aeropuerto local.

Y luego probablemente quieran seleccionar a dónde quieren ir.

Así que, dos opciones, ambos aeropuertos.

Podrías hacerles adivinar qué aeropuertos hay cerca.

Por lo general, introduzco la ciudad a la que tengo que ir y dejo que el sitio web averigüe a qué aeropuerto tengo que volar.

Pero supongamos que sus usuarios ya conocen los aeropuertos de ambos extremos de su viaje.

Facilita nuestro pequeño experimento mental.

Por tanto, debe presentar al usuario una lista de aeropuertos entre los que elegir.

Sí, será una larga lista.

Parece que hay muchos aeropuertos repartidos por el mundo.

Sólo cargando nuestro cubo de muestras de viaje tenemos casi 2.000.

Tío, ¡son muchos aeropuertos!

Alguien introdujo muchos datos...

Pero lo bueno de los aeropuertos es que no cambian tan a menudo.

Quiero decir, sí, se están construyendo nuevos...

Y a los viejos dejándolos en la ruina...

Pero todo eso ocurre con el tiempo.

Por lo general, el abandono de un aeropuerto se debe a la construcción de otro más nuevo y brillante.

Y se tarda mucho tiempo en construir un nuevo aeropuerto.

No es que los vomiten todos los días.

Así que, volviendo a nuestra lista de aeropuertos...

Larga o no, tendrá que proporcionar algún tipo de lista de aeropuertos para que el usuario elija.

Y si su sitio web tiene mucho tráfico, puede haber muchos usuarios.

Y todos queremos que nuestros sitios web estén ocupados.

Así que vamos a seguir adelante y asumir que nuestro sitio web no sólo ocupado ...

Está muy ocupado.

Millones de usuarios cada día.

Miles de usuarios cada minuto.

Son muchas veces las que tienes que servir esa lista de aeropuertos.

Así pues, vamos a empezar suponiendo que los documentos del aeropuerto de tu bucket de Couchbase están estructurados como los de nuestro bucket de muestra de viajes.

Oye, viene con nuestro producto Couchbase Server, ¡más vale usarlo!

Facilita las cosas...

Así pues, basta con enumerar los aeropuertos mediante una simple consulta N1QL:

Nos da esto:

Hmm, no va a ser fácil encontrar lo que nuestros usuarios necesitan en esto. Tal vez si lo ordenamos por el código de aeropuerto de la FAA, y luego eliminamos aquellos en los que el código es nulo...

Eso está mejor, pero son más datos de los que necesitamos proporcionar al sitio web.

Así pues, reduzcamos lo que estamos devolviendo al código de la FAA, el nombre del aeropuerto, la ciudad y el país:

Bien, ahora vamos a lo que buscamos.

Por lo tanto, si hacemos una consulta obtendremos, digamos, un tiempo de respuesta de unos 50-60 ms.

No está mal.

Pero con miles de peticiones de esta lista cada minuto...

Hmm, tal vez podamos acelerar las cosas un poco.

Hagamos una consulta cubierta añadiendo nuestro propio índice que incluya todo lo que necesitamos.

Y ahora volvemos a ejecutar la consulta y obtenemos un tiempo de respuesta en torno a 17,5 ms.

Mucho mejor.

Pero, ¿es posible hacerlo aún mejor?

Esta lista será solicitada miles de veces cada minuto.

Esos milisegundos se acumulan.

¿Y si tomamos los resultados de esta consulta y los guardamos en un único documento?

Llamémosla "lista_de_aeropuertos".

Así que ahora, si ejecutamos una consulta seleccionando todo el documento con la cláusula "USE KEYS":

Esto nos da un tiempo de respuesta de unos 14,5 ms.

Hmm, ¡ahorré otros 3 milisegundos enteros!

Y podríamos ahorrar otro medio milisegundo o dos si utilizamos el acceso clave-valor y obtenemos el documento por su ID directamente del servicio de datos.

Para un documento que debe servirse miles de veces por minuto.

Millones de veces al día.

Esos milisegundos se acumulan.

Sí, ya lo sé. Los aeropuertos cambian de vez en cuando.

Sí, pero no cambian muy a menudo.

Sí, este documento tendrá que ser sustituido cada cierto tiempo.

Pero esa es una operación que no está sirviendo a un sitio web de alta actividad.

Así que a quién le importa lo lento (comparativamente) que pueda ser el proceso.

Además, ¡ya no necesito mi índice de cobertura!

Puedo ahorrar un poco de espacio en mi servidor de índices.

¡Woo-hoo! ¡Bonus!

Sí, lo sé. Me emociono con cosas raras...

Bien, esto ha sido un ejercicio para reducir el tiempo de respuesta en milisegundos. ¿Qué tal una consulta que tarda un poco más y hace más?

Supongamos que dirige un centro de llamadas y es importante controlar la rapidez con la que su equipo atiende las llamadas entrantes...

Bien, seamos un poco más específicos.

Supongamos que desea disponer de un cuadro de mandos que muestre cuántas llamadas se han contestado en cinco segundos, en diez segundos y el número total de llamadas que han entrado hoy.

Algo así como...

Así, se empieza con un índice sobre las propiedades startTime y callType, limitándolo a documentos de tipo "cdr", sólo para descubrir que se tarda alrededor de un segundo en ejecutar esta consulta.

Y ésta no es la única consulta que querrás utilizar para rellenar tu cuadro de mandos...

¡Uf, esto va a ser tan lento como la melaza!

De acuerdo, vamos a crear un nuevo índice con todas las propiedades, haciendo una consulta cubierta, sólo para descubrir que, aunque ha mejorado, sigue tardando unos 100 milisegundos.

¡Eso es una mejora de 10 veces! Es genial, ¿verdad?

Sólo que tu tablero de mandos sigue actualizándose como si funcionara en melaza.

Melaza fina y acuosa, pero aún así...

¿Qué podemos hacer para mejorar esto?

¿Y si, en lugar de utilizar esta consulta para alimentar el cuadro de mandos, tomamos el resultado y lo utilizamos para crear un nuevo documento con sólo los resultados?

Algo con un nombre conocido, como call_stats_...

Y podemos ejecutar esta consulta en un temporizador, utilizando un cron job, o lanzarla utilizando el servicio Couchbase Eventing.

Sólo si lo activamos desde el servicio Eventing, probablemente querremos ejecutarlo con una consistencia de escaneo de al menos at_plus para incluir la actualización del documento que está utilizando para activar la consulta.

Pero ahora, cuando recuperamos el documento resultante, obtenemos tiempos de respuesta de un solo dígito de milisegundo, ¡lo que supone una mejora del rendimiento de casi 1.000 veces!

Y ahora tenemos un salpicadero con capacidad de respuesta.

¡¡¡WOO-HOO!!!

Ahora estamos hablando de velocidad turbo.

Entonces, ¿cuál es la lección de estos dos escenarios?

Pues bien, al tomar cualquier proceso que necesitáramos realizar en los datos y convertirlo en tareas en segundo plano, de modo que nuestras solicitudes interactivas de datos no impliquen ningún proceso, hemos agilizado mucho las cosas...

Más rápido que una bala.

Discúlpenos Superman, estamos pasando...

¿Era tan doloroso ese experimento mental?

Ahora vamos con esos índices sexys...

Couchbase, el poder de los empollones de datos de todo el mundo...

(¡Eh, Peter, creo que ya tengo nuestro nuevo eslogan!)