¿Es mejor no procesar que procesar un poco?

Hagamos un pequeño experimento mental.

Sí, ya sé, pensar. ¿Quién quiere hacer eso?

¡Espera!

Antes de que me ignores y pases a la siguiente publicación sobre índices atractivos...

Dame al menos un par de minutos.

Digamos que tienes un sitio web.

Bueno, no cualquier sitio web...

Eso es un poco demasiado genérico.

De acuerdo, digamos que tienes un sitio web de viajes.

Un lugar donde la gente viene a hacer reservaciones de aerolínea.

Creo que todos hemos usado uno de esos en algún momento.

Por lo tanto, sus usuarios llegan a su sitio web y quieren ver qué vuelos están disponibles.

¿Qué es lo primero que hacen?

¿Escriben una pregunta a mano?

En estos días no.

Probablemente empiecen por seleccionar desde dónde quieren salir.

Su aeropuerto local.

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

Entonces, dos opciones, ambos aeropuertos.

Podrías hacer que adivinen qué aeropuertos hay alrededor.

O sea, por lo general solo ingreso la ciudad a la que necesito ir y dejo que el sitio web averigüe a qué aeropuerto tengo que volar.

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

Facilita nuestro pequeño experimento mental.

Por lo tanto, debes presentar al usuario una lista de aeropuertos para elegir.

Sí, será una lista larga.

Parece que hay muchos aeropuertos esparcidos por este gran mundo.

Simplemente cargar nuestro bucket travel-sample nos da casi 2 mil.

¡Vaya, son muchos aeropuertos!

Alguien hizo un montón de captura de datos...

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

O sea, sí, hay nuevos siendo construidos...

Y las viejas quedando en ruinas…

Pero todo eso ocurre con el tiempo.

Por lo general, si un aeropuerto es abandonado, a menudo se debe a que se construyó uno más nuevo y brillante.

Y toma mucho tiempo construir un nuevo aeropuerto.

Tampoco es que los estén vomitando todos los días.

Bien, volviendo a nuestra lista de aeropuertos...

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

Y si tu sitio web tiene mucho tráfico, podría haber muchos usuarios.

Y todos queremos que nuestros sitios web tengan mucho tráfico.

Así que supongamos simplemente que nuestro sitio web no solo está ocupado...

Está muy ocupado.

Millones de usuarios todos los días.

Miles de usuarios cada minuto.

¡Es la gran cantidad de veces que tienes que presentar esa lista de aeropuertos!

Por lo tanto, comencemos por asumir que los documentos de los aeropuertos en su bucket de Couchbase están estructurados como los de nuestro bucket travel-sample.

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

Facilita las cosas…

Por lo tanto, simplemente listar los aeropuertos usando una consulta N1QL sencilla:

SELECT `travel-sample`.*
FROM `travel-sample`
WHERE type = "airport"
;

Danos esto:

[
 {
  "airportname": "Calais Dunkerque",
  "city": "Calais",
  "country": "Francia",
  "faa": "CQF",
  "geo": {
    "alt": 12,
    "lat": 50.962097,
    "lon": 1.954764
  },
  "icao": "LFAC",
  "id": 1254,
  "type": "aeropuerto",
  "tz": "Europe/Paris"
 },
 {
  "airportname": "Peronne St Quentin",
  "city": "Peronne",
  "country": "Francia",
  "faa": null,
  "geo": {
    "alt": 295,
    "lat": 49.868547,
    "lon": 3.029578
  },
  "icao": "LFAG",
  "id": 1255,
  "type": "aeropuerto",
  "tz": "Europe/Paris"
 },
...
]

Mmm, 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 sea nulo...

[
 {
  "airportname": "Aeropuerto Lansdowne",
  "city": "Youngstown",
  "country": "Estados Unidos",
  "faa": "04G",
  "geo": {
    "alt": 1044,
    "lat": 41.1304722,
    "lon": -80.6195833
  },
  "icao": null,
  "id": 8534,
  "type": "airport",
  "tz": "America/New_York"
 },
 {
  "airportname": "Aeropuerto Municipal Moton Field",
  "city": "Tuskegee",
  "country": "Estados Unidos",
  "faa": "06A",
  "geo": {
    "alt": 264,
    "lat": 32.4605722,
    "lon": -85.6800278
  },
  "icao": null,
  "id": 8317,
  "type": "airport",
  "tz": "America/Chicago"
 },
...
]

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

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

[
 {
  "airportname": "Aeropuerto Lansdowne",
  "city": "Youngstown",
  "country": "Estados Unidos",
  "faa": "04G"
 },
 {
  "airportname": "Aeropuerto Municipal Moton Field",
  "city": "Tuskegee",
  "country": "Estados Unidos",
  "faa": "06A"
 },
...
]

Bien, ahora estamos llegando a lo que buscamos.

Entonces, si consultamos esto, obtenemos, ah, digamos un tiempo de respuesta de unos 50-60 ms.

Nada mal.

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

Mmm, tal vez podamos acelerar las cosas un poco.

Convirtámosla en una consulta cubierta agregando nuestro propio índice que incluya todo lo que necesitamos.

CREATE INDEX myFaaIndex on `travel-sample`(faa asc,airportname,city,country)
WHERE type = "airport" AND faa IS NOT NULL;

Y ahora volvemos a ejecutar la consulta y obtenemos un tiempo de respuesta de alrededor de 17.5 ms.

Mucho mejor.

Pero, ¿es posible hacerlo aún mejor que esto?

O sea, esta lista se va a solicitar miles de veces cada minuto.

Esos milisegundos se acumularán.

Entonces, ¿qué tal si tomamos los resultados de esta consulta y los guardamos como un solo documento?

Llamémoslo “airport_list”.

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

SELECT `travel-sample`.*
FROM `travel-sample`
USE KEYS "airport_list";

Esto nos está dando un tiempo de respuesta de alrededor de 14.5 ms.

¡Mmm, ahorré otros 3 milisegundos completos!

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

Para un documento que necesita ser servido miles de veces por minuto.

Millones de veces al día.

Esos milisegundos se acumularán.

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

Sí, pero no cambian muy seguido.

Sí, este documento en específico deberá reemplazarse de vez en cuando.

Pero esa es una operación que no le da servicio a un sitio web de alta actividad.

Así que a quién le importa lo lento (en comparación) que pueda ser ese proceso.

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

¡Puedo ahorrar un poco de espacio en mi servidor de índices!

¡Yupiii! ¡Bono!

Sí, ya sé. Me emociono por cosas extrañas...

De acuerdo, ese fue un ejercicio para rasurar milisegundos a nuestro tiempo de respuesta. ¿Qué tal una consulta que tarde un poco más y haga más?

Digamos que diriges un centro de llamadas y es importante realizar un seguimiento de la rapidez con la que tu equipo responde a las llamadas entrantes...

De acuerdo, vamos a ser un poco más específicos.

Digamos que quieres tener un panel que muestre cuántas llamadas se han respondido en cinco segundos, en diez segundos y el número total de llamadas que han entrado hoy.

Algo así como...

SELECT SUM(five) como fiveCount, SUM(ten) como tenCount, SUM(incoming) como callCount
FROM
 (SELECT
    CASE 
      WHEN connectTime = 0 AND (endTime - startTime)  0 AND (acceptTime - startTime)  0 AND (acceptTime - startTime)  $today
    AND callType BETWEEN 10 AND 2000) como calls
;

Por lo tanto, comienzas con un índice en las propiedades startTime y callType, limitándolo a documentos de tipo “cdr”, solo para descubrir que esta consulta tarda aproximadamente un segundo en ejecutarse.

Y esta no es la única consulta que quieres usar para poblar tu tablero...

¡Uf, esto va a ir más lento que una procesión de caracoles!

Muy bien, entonces construyamos un nuevo índice con todas las propiedades en él, convirtiendo esto en una consulta cubierta, solo para descubrir que, aunque ha mejorado, todavía toma alrededor de 100 milisegundos.

¡Oye, esa es una mejora de 10 veces! Eso es genial, ¿no?

Solo tu panel todavía se actualiza como si funcionara en melaza.

Melaza rala y aguada, pero aun así...

Mmm, ¿qué podemos hacer para mejorar esto?

¿Y si, en lugar de usar esta consulta para alimentar el tablero, tomamos el resultado y lo usamos para crear un documento nuevo solo con los resultados?

Algo con un nombre conocido, como call_stats_…

Y podemos ejecutar esta consulta periódicamente, usando una tarea cron, o activarla mediante el servicio Eventing de Couchbase.

Solo si lo activamos desde el servicio Eventing, probablemente queramos ejecutarlo con una consistencia de análisis de al menos at_plus para incluir la actualización del documento que estás usando para activar la consulta.

Pero ahora, cuando recuperamos el documento de resultados, estamos logrando tiempos de respuesta de pocos milisegundos, ¡casi una mejora de 1000 veces en el rendimiento!

¡Y ahora tenemos un panel adaptable!

¡IUUUP!

¡Ahora sí estamos hablando a velocidad de turbo-propulsor!

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

Bueno, al tomar cualquier procesamiento que necesitábamos hacer en los datos y convertirlo en tareas en segundo plano, de modo que nuestras solicitudes de datos interactivas no impliquen ningún procesamiento, hemos hecho que las cosas sean muy rápidas...

¡Estamos hablando de más rápido que una bala rápida!

Dis discúlpanos Superman, venimos pasando...

Entonces, ¿ese experimento mental fue realmente tan doloroso?

Ahora pasemos a esos índices atractivos...

Couchbase, empoderando a los fanáticos de los datos en todas partes…

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