Escalando tu base de datos con ReadySet

Hola a todos. Soy Nick Marino. Hola, soy Griffin Smith. Y vamos a hablar sobre cómo escalar tu base de datos con ReadySet. Para resumir, vamos a comenzar dando un poco de información de fondo, explicar cuál es el problema que ReadySet intenta resolver y cómo lo hace. Luego, Griffin hará una demostración que muestra cómo usar ReadySet con una aplicación del mundo real y te dará una idea de algunos de los beneficios de rendimiento y características que puedes esperar ver allí. Y finalmente, después de eso, abriremos la sesión para preguntas que puedan tener.

Muy bien. Primero, ¿qué es ReadySet? Si miras el sitio web de ReadySet, dice que es un sistema de almacenamiento en caché para MySQL y PostgreSQL, lo cual es cierto. Cuando vi el sitio web por primera vez, pensé que tal vez era solo una envoltura alrededor de Redis o Memcached o una copia de algún tipo de sistema de almacenamiento en caché popular existente. Entonces, es algo así como un producto genial y útil, pero tal vez no algo revolucionario. Resulta que en realidad es mucho más que eso. Te permite crear rápidamente y fácilmente cachés para consultas SQL individuales sobre la marcha sin necesidad de realizar cambios en tu aplicación, aparte de tal vez un cambio de configuración o dos. Y, ya sabes, no quiero revelar demasiado de la demostración más adelante, pero en una de las consultas que hemos evaluado, vemos una mejora de velocidad de alrededor de 25,000 veces. Así que eso es bastante emocionante, creo. Pero antes de entrar en todo eso, hablemos del problema. Creo que esta cita resume bastante bien el problema que estamos tratando de resolver, así que la leeré en voz alta. La capa de acceso a datos de una idea millonaria comienza como una base de datos relacional de un solo servidor. No te preocupas mucho por los problemas de escalabilidad, tienes una aplicación que escribir. Sin embargo, si tu idea millonaria termina valiendo incluso 100,000, es probable que encuentres que tu base de datos lucha por mantenerse al día con la escala. Y esta es ciertamente una historia con la que personalmente estoy familiarizado. Sé que muchas personas ahí fuera también lo están. Cuando estás comenzando una startup o un sitio web y estás en una etapa muy temprana, no tienes realmente el tiempo y los recursos para construir algo utilizando la última moda de no-SQL, escalable del día, y no hay nada de malo en usar MySQL o Postgres. Son gratuitos, son muy populares, son fáciles de usar. Y cuando solo estás tratando de obtener una versión inicial simple de algo, un producto mínimo viable un prototipo, como quieras llamarlo, no quieres pasar demasiado tiempo lidiando con sistemas de escalabilidad realmente complejos y sofisticados. Solo quieres obtener algo que funcione. Pero, por supuesto, si y cuando alcanzas los límites de escalabilidad en tu database, puede ser un problema bastante complicado de resolver. Y es un buen problema para tener, pero a menudo ocurre en un punto bastante crítico en la vida de un sitio web o una organización. Entonces, si estamos analizando el problema al que nos enfrentamos aquí, solo quiero enmarcarlo de manera muy breve. Cuando estás escalando una aplicación web en producción, creo que lo primero en lo que realmente te importa a medida que alcanzas los límites de escalabilidad de un solo servidor de database es el rendimiento de lectura. Creo que para la mayoría de las aplicaciones web, ese es el punto crítico para la experiencia del usuario, hay un número que se cita y hay algunas investigaciones bastante extensas que muestran que cargar una página web se siente instantáneo en alrededor de 200 milisegundos. Y esos 200 milisegundos, la mayor parte del tiempo lo pasas leyendo datos de tu database. Entonces, si necesitas escalar esas lecturas de la database, si necesitas que esas lecturas de la database sean más rápidas, hay tres opciones principales de alto nivel que vas a tomar. Podrías pasar mucho tiempo optimizando tus consultas. Eso puede ser tan simple como agregar índices o algo más complicado. Podrías usar una réplica de lectura para escalar la capacidad de consulta. Entonces, si estás recibiendo muchas consultas, podrías usar réplicas de lectura para aumentar el número de consultas que puedes manejar.

Otra opción es construir una solución de almacenamiento en caché personalizada donde almacenas datos que se acceden con frecuencia y que no cambian mucho en algún tipo de almacén de clave-valor al que puedes acceder de forma muy rápida.

Todas estas opciones tienen sus compensaciones. Entonces, nuestra primera opción, la optimización de consultas, es algo que requiere mucha experiencia. Debes entender cómo funcionan las bases de datos SQL. Tienes esta idea de que tu base de datos debería poder realizar la consulta de la manera más rápida posible. Pero todos los servidores de bases de datos en el mercado, al menos los que conozco, necesitan un poco de ayuda para hacer esto. Como mencioné anteriormente, esto puede ser tan simple como agregar índices o tan complejo como cambiar por completo la forma en que se escribe la consulta. Y en este último caso, a menudo estás luchando contra tu ORM. Todos los que han utilizado un ORM han tenido este problema en el que el ORM quiere emitir consultas de una manera particular. Pero sabes que hay una forma diferente de escribir la consulta que podría devolver los mismos resultados y ejecutarse más rápido en la base de datos. Y tienes que luchar contra tu ORM o biblioteca de clientes. Incluso los índices tienen un costo, ¿verdad? Aumentan el tiempo necesario para realizar una escritura. Aumentan el uso de disco. Aumentan el uso de memoria. Nada de esto es gratuito. Lo otro importante es que tu aplicación está cambiando, ¿verdad? Si estás dedicando mucho tiempo a optimizar tus consultas, algún día agregarás una nueva función y una nueva consulta se volverá importante. Esto es algo que ocurre, todas las aplicaciones están cambiando todo el tiempo. Y si estás agregando este tiempo adicional para crear índices u optimizar consultas para cada función que tienes que escribir, significa que estás implementando menos funciones, ¿verdad? La segunda opción es escalar con réplicas de lectura.

Sabes, esta es una forma bastante estándar de escalar el número de consultas que puedes manejar. Tanto Postgres como MySQL, estoy bastante seguro de que bifurcan procesos por conexión, por lo que tienen un límite superior en el número de conexiones que pueden manejar. Y así, puedes escalar el rendimiento ejecutando réplicas de lectura, pero esto tampoco es gratuito. Tus réplicas de lectura deben conectarse a tu database principal para transmitir el registro de replicación , lo que agrega carga a tu database principal. Y estás agregando una carga operativa significativa al ejecutar tu database en producción.

Entonces, esto sigue siendo mucho trabajo. Es un costo considerable. Y al final del día, solo estás mejorando el rendimiento, no la latencia, porque es el mismo motor de database, ejecutando la misma consulta, solo en otro servidor. Y luego, eso nos lleva a la tercera opción, que es construir esta solución de almacenamiento en caché personalizada. La idea aquí es ejecutar una consulta una vez, almacenar los resultados en algo como Redis o Memcached, y luego, si los data no han cambiado, puedes leer los data de Redis o Memcached. Pero esto, ya sabes, esto es mucho trabajo. Esto es código que tienes que escribir. Antes, tu aplicación solo hacía consultas SQL contra MySQL o Postgres. Ahora, tienes que, ya sabes, tienes un patrón de acceso totalmente diferente para acceder a estas cachés. Tienes que lidiar con la invalidación de las cachés en las escrituras. Y con frecuencia, esto es algo totalmente manual. Entonces, puedes introducir errores donde olvidas invalidar una caché en una escritura en particular. Y estos errores, ya sabes, he pasado meses de mi vida rastreando errores que al final, ya sabes, resultó que simplemente olvidamos invalidar la caché en una escritura. Y aún estás agregando carga operativa, porque tienes que ejecutar este servicio adicional. Y hay muchos otros problemas, ya sabes, pequeños problemas marginales que vienen con ejecutar estas cachés. Ya sabes, la recuperación y conmutación por error, ejecutar estas cachés en un escenario distribuido puede ser realmente complicado. Y tienes este problema donde, debido a la invalidación en las escrituras, si tienes muchas escrituras, entonces debes ejecutar la consulta nuevamente contra tu database principal. Y tienes este problema de manada rugiente, donde, ya sabes, si un montón de personas solicitan los mismos data contra una entrada de caché invalidada, ya sabes, puedes poner mucha carga en tu database principal y, ya sabes, causar muchos problemas en producción.

Pero la idea aquí, la idea detrás de ReadySet es que estas tres opciones no son muy buenas. Y sería genial si no tuviéramos que hacer ninguna de ellas. Ya sabes, queremos centrarnos, en lugar de centrarnos en, ya sabes, escalar nuestra database, queremos centrarnos en desarrollar funciones que nuestros usuarios deseen, ya sabes, hacer felices a nuestros clientes. Y todo este problema de escalar la database es algo que distrae. Entonces, esto nos lleva a lo que creo que es tan emocionante de ReadySet, es que te permite escalar sin lidiar con ninguno de esos problemas de los que hablamos anteriormente y que Griffin mencionó en las últimas diapositivas. Entonces, esto muestra algunas de las características más emocionantes de ReadySet. Número uno, es plug and play.

En primer lugar, es plug and play. Por lo tanto, utiliza el mismo protocolo que Postgres y MySQL. Esto significa que, a diferencia de una solución de almacenamiento en caché personalizada donde tendrías que integrar, por ejemplo, una biblioteca de cliente de Redis en tu aplicación, e incluso necesitarías hablar múltiples protocolos, para poder comunicarte directamente con la database principal si necesitas retroceder en caso de que haya un problema con la caché, simplemente utilizas el mismo código y las mismas bibliotecas de cliente que ya estás utilizando. Hemos implementado todo el protocolo de comunicación para estas bases de datos existentes. Por lo tanto, no tienes que cambiar ningún código en tu aplicación. Solo tienes que cambiar una línea de configuración, por lo general, para apuntar tu aplicación a Rediset en lugar de la database.

En segundo lugar, es muy flexible. Podemos activar y desactivar la caché para consultas individuales a voluntad. Esto facilita mucho la iteración rápida sobre el impacto del performance de la caché. Puedes realizar experimentos. Puedes ver qué sucede si almaceno en caché esta consulta, qué sucede si almaceno en caché esta otra consulta? ¿Cómo afecta al performance? ¿Cómo afecta al uso de memoria? Facilita mucho la realización rápida de este tipo de experimentos, obtener resultados, ver qué funciona.

Además, Rediset es muy, muy escalable. Ya lo mencioné un poco antes, pero cuando realizas una lectura de una consulta que ha sido almacenada en caché y la caché está disponible, es simplemente una búsqueda en un HashMap. Por lo tanto, es muy rápido y eficiente. Por lo general, incluso podemos ver latencias de menos de un milisegundo allí. Además, si los beneficios de performance que obtienes de un solo nodo de Rediset no son suficientes, o no tienes suficiente memoria en una sola máquina, también admitimos la escalabilidad a múltiples nodos. Por lo tanto, no solo obtienes más margen y espacio en términos de performance, sino que además, una de las cosas interesantes de este enfoque es que aún actuamos desde la perspectiva de la database principal como una única réplica de lectura. Por lo tanto, en la diapositiva de la réplica de lectura que Griffin mostró anteriormente, si tienes más réplicas, todas reciben actualizaciones de la database principal, por lo que se agrega más carga debido a que las réplicas adicionales necesitan recuperar actualizaciones y replicar los datos. Pero con Rediset, actúa como una única réplica. Toda la escalabilidad en una configuración de múltiples nodos ocurre internamente en Rediset. Por lo tanto, no necesariamente incurres en carga adicional en tu database solo al agregar más nodos de Rediset.

Por último, este último punto, latencia negativa, puede sonar como una palabra de moda, pero permíteme explicar lo que quiero decir aquí. La latencia es el lapso de tiempo entre cuando solicitas un resultado y cuando llega el resultado en. Y parte de la gran idea de Rediset es que estamos actualizando continuamente los resultados de tu caché a medida que llegan nuevos datos antes de que los solicites. Entonces, a diferencia de una solución de almacenamiento en caché personalizada donde tal vez, ya sabes, tienes que invalidar las cosas periódicamente. Y luego, cuando solicitas los nuevos data, es temporalmente más lento porque tiene que volver a ejecutar la consulta. Constantemente intentamos mantener actualizados los resultados de tu caché en tiempo real a medida que llegan nuevos datos a la database y se replican en Rediset. Para mostrar cómo funciona esto un poco, tenemos este pequeño diagrama aquí. Lo que puedes ver aquí es que cuando tu aplicación realiza escrituras en la database, es decir, inserciones, actualizaciones, eliminaciones. Va directamente a la database, pero luego Rediset actúa como una réplica de lectura, y solo recibe actualizaciones de la database utilizando el mismo protocolo que usaría una réplica de lectura.

Como sabes, no necesitas ningún tipo de complemento o cambios sofisticados en la base de datos. Aún utiliza el mismo protocolo y replicación, así como las consultas. Y luego, Rediset utiliza esas actualizaciones replicadas para mantener tus cachés actualizadas, de modo que cuando la aplicación solicite un resultado de consulta, con suerte lo obtenga directamente de Rediset sin ninguna demora adicional de lectura en frío o algo así. Genial.

A continuación, te mostraré el proceso de puesta en marcha de Rediset. Hemos trabajado mucho para que el proceso de configuración de Rediset sea lo más sencillo posible. Realmente hay dos pasos en este proceso. Primero, ejecuta Rediset apuntando a tu base de datos, y luego cambia la configuración en tu aplicación para que apunte a Rediset. Como dijo Nick, hablamos el lenguaje de las bibliotecas de cliente de Postgres y MySQL, como el protocolo de conexión para Postgres y MySQL. Por lo tanto, si tu aplicación ya está conectada a una de esas bases de datos, simplemente puede conectarse a Rediset. Y luego, simplemente funciona. Puedes almacenar en caché consultas y experimentar con cuáles se almacenan en caché y cuáles no, y idealmente ver una mejora significativa de velocidad.

A continuación, realizaré una demostración en vivo utilizando cal.com. Cal.com es una aplicación de código abierto. Es una aplicación de producción del mundo real. No la escribimos. No participamos en la escritura de esta aplicación. La elegimos por varias razones. Primero, es una aplicación del mundo real. Por lo tanto, la idea aquí es que este escenario sea lo más realista posible para ejecutar Rediset. Está construida con Next.js y Prisma. Por lo tanto, es una pila que esperamos que sea relevante para parte de la audiencia aquí. Como dije, es madura. Tiene muchas consultas, algunas simples, otras que han pasado por mucha optimización y otras que son muy lentas. Algunas de esas consultas no se pueden almacenar en caché en Rediset. Como dijo Nick, no podemos almacenar en caché todo, porque aún estamos trabajando para admitir todo el SQL. Pero la idea es que no tenemos que almacenar en caché todo, solo almacenamos en caché las consultas que son más importantes y críticas para el rendimiento de la aplicación. También elegimos Cal.com porque es bastante fácil de configurar.

Es una aplicación de Node.js. Simplemente ejecutas un comando de Yarn y las cosas funcionan. Voy a cambiar para hacer esa demostración.

Esto es Cal.com. Lo tengo ejecutando en un navegador web aquí. Se está ejecutando a través de un servidor de desarrollo en mi máquina local aquí. La aplicación es básicamente, si están familiarizados con Calendly, es básicamente como una versión de código abierto de Calendly. La idea aquí es que puedes crear tipos de eventos que permitan a las personas reservar tiempo en tu calendario sujeto a tu disponibilidad y luego las personas pueden reservar diferentes tipos de eventos en tu calendario. Algunos de esos eventos pueden ser recurrentes. Pueden tener enlaces de reunión asociados. Puedes crear eventos grupales con personas. Es en realidad una aplicación bastante agradable.

Esto es Cal.com ejecutándose tal cual, apuntando a Postgres. Puedes ver que acabo de hacer clic en la pestaña de reservas aquí. Solo para demostrar, con ReadySet, he generado alrededor de 10 millones de filas en esta tabla de reservas. Toma un poco de tiempo cargar esta página cuando estamos ejecutándola solo con Postgres. Así que es un gran ejemplo de lo que sucede cuando de repente tu aplicación experimenta una cantidad inesperadamente alta de carga. Y podemos ver que las cosas realmente se ralentizan. Sí.

Como dije, estoy ejecutando Cal.com localmente. Vamos a pasar por el proceso de apuntar esto a ReadySet. También estoy ejecutando ReadySet localmente en mi máquina. Se está ejecutando en el puerto 5435. Entonces, todo lo que tengo que hacer para cambiar a ReadySet es ir a mi configuración, que es solo un archivo punto end. Y cambiar el puerto. Luego puedo ejecutar el servidor de desarrollo nuevamente, y tomará un segundo compilar, porque es un servidor de desarrollo, por lo que está recompilando todo. Y solo para ser más claro, normalmente probablemente tendrías que cambiar más que solo el puerto. Pero Griffin está ejecutando todo en una sola máquina, por lo que sucede que el cambio de URL para apuntar a ReadySet es bastante mínimo en este caso. Sí, eso es correcto. Pero podemos ver una vez que Next.js compila todo que todavía puedo hacer clic y la aplicación sigue funcionando perfectamente bien.

Sigo obteniendo los mismos resultados en todas partes. Pero en realidad no he almacenado en caché ninguna consulta, por lo que no veo ninguna mejora en esta página de reservas. Lo que podemos hacer, hay algunas formas de explorar cómo se ve almacenar en caché consultas individuales. Una opción es ver que solo estoy registrando las consultas aquí. Prisma registra por defecto las consultas que se ejecutan. Así que puedes ver que hay muchas consultas en los registros aquí.

ReadySet también realiza un seguimiento de todas las consultas que no estamos almacenando en caché. Cuando no almacenamos en caché una consulta, la redirigimos a la base de datos de origen. Puedo obtener una lista de esas consultas simplemente conectándome a ReadySet a través de una shell de PSQL como he hecho aquí, y luego ejecutando show proxy queries. Y eso me da una lista de todas las consultas que ReadySet está redirigiendo a la base de datos de origen, junto con si esta consulta se puede almacenar en caché. Y, como puedes ver, esta aplicación está ejecutando bastantes consultas.

Y para ser claro, cuando decimos la palabra consulta aquí, es útil ser preciso acerca de lo que estamos hablando aquí. Realmente, creo que la forma más fácil de entender esto es mediante declaraciones preparadas. Entonces puedes ver, cuando Prisma ejecuta una consulta, tenemos estos marcadores de posición con el signo de dólar aquí. ReadySet también piensa en las consultas en términos de que una consulta es la misma consulta modulo un valor particular para un marcador de posición en una declaración preparada. Y cuando almacenamos en caché una consulta, en realidad estamos diciendo que queremos poder almacenar en caché conjuntos de resultados individuales para valores de esos marcadores de posición. Así que puedes imaginar una consulta para cargar data para un usuario en particular filtrando por un ID de usuario. Almacenamos en caché una consulta y decimos almacenar en caché esta consulta para todos los valores del ID de usuario, excepto que no almacenamos en caché conjuntos de resultados en memoria para cada usuario individual. Solo almacenamos los conjuntos de resultados de la consulta para los usuarios que realmente están solicitando esos data. Entonces, para los usuarios que realmente inician sesión. Y la idea aquí es, ya sabes, si tienes una aplicación, es posible que tengas miles o incluso millones de usuarios en tu base de datos, pero solo unos pocos inician sesión en un semana en particular. Ya sabes, hay esta especie de distribución normal de registro de qué usuarios están iniciando sesión. Tienes tus usuarios realmente activos y luego tus usuarios que nunca abren la aplicación. Y para un usuario que nunca inicia sesión, no queremos gastar memoria ni recursos para mantener los data en la caché para esos usuarios. Entonces, lo que hará ReadySet es que solo almacenaremos data en memoria para las consultas que realmente los conjuntos de resultados que realmente se están solicitando. Y luego, a medida que tengamos presión de memoria, los eliminaremos según el uso menos reciente. Y si todo esto suena un poco abstracto, creo que la idea principal aquí es que si le dices que almacene en caché, ya sabes, selecciona todo de usuarios donde el ID de usuario es igual a 14, no solo va a almacenar en caché el resultado donde el ID de usuario es igual a 14. En realidad, es lo suficientemente inteligente como para generalizar a partir de eso y almacenar en caché la misma consulta para otros ID de usuario también. Sí. Así que hice algunas pruebas con esta aplicación de antemano y encontré una consulta que, ya sabes, funciona particularmente mal y que ReadySet puede ayudar bastante.

Entonces, hay esta consulta, tiene un par de agregados, tiene, ya sabes, estoy en una cuenta y está filtrando por, como dije, filtrando por ID de usuario. Y esto es, ya sabes, no estoy completamente familiarizado con cal.com, pero solo leyendo la consulta, parece que esto está obteniendo el evento recurrente más temprano. Entonces puedes tener eventos recurrentes y es posible que desees obtener la próxima reserva para un evento recurrente en particular. Y podemos ver si ejecuto esta consulta, sé que mi ID de usuario es 14, así que estoy filtrando por 14, por el ID de usuario 14. Si ejecutamos esta consulta en Postgres, sin caché de Ready Set, podemos ver que lleva bastante tiempo. Mencioné anteriormente que la mayoría de las cargas de página tienen un presupuesto de aproximadamente 200 milisegundos para que la carga de la página se sienta instantánea, subjetivamente, para el usuario, y una carga de página en particular podría hacer decenas de consultas. Por lo tanto, realmente necesitas que cada consulta individual sea bastante rápida para ajustarse a ese presupuesto de 200 milisegundos, y esta consulta por sí sola ya está superando ese presupuesto por un factor de tres. Así que veamos el proceso de acelerar esta consulta con Ready Set. Entonces, si quiero almacenar en caché esta consulta, todo lo que tengo que hacer es tomar la consulta y agregar, crear, caché, from, nuevamente, todo esto solo en una shell de PSQL. Y ahora Ready Set va a almacenar en caché los conjuntos de resultados de esa consulta y, como dijo Nick, podrá decir, okay, sabemos que este ID de usuario es 14 aquí, pero en realidad vamos a almacenar conjuntos de resultados para cualquier ID de usuario y luego, como dije, solo almacenar los conjuntos de resultados para los ID de usuario que realmente se leen. Entonces, ahora, después de crear la caché, si ejecuto la consulta nuevamente, tomará un segundo para precalcular los conjuntos de resultados la primera vez. Está calentando la caché. Pero luego, si ejecuto la consulta nuevamente, podemos ver que se ejecuta bastante rápido. Hemos pasado de, ya sabes, aproximadamente 700 milisegundos a una fracción de milisegundo. Y, ya sabes, esto, creo que cambia el juego.

Sabes, otra cosa de la que quería hablar aquí es un problema con el que te encuentras en muchas aplicaciones web, y es que tiendes a realizar consultas de más datos de los necesarios. Existe este problema de realizar consultas excesivas. Puede que tengas una función que dice: dame toda la información que tienes sobre este usuario en particular. Y luego, cada carga de página llama a esa función porque algunas páginas necesitan ciertos datos y otras páginas necesitan otros datos. Pero, ya sabes, esa función podría estar realizando una consulta que nunca se utiliza en una página en particular. Por lo tanto, uno de los pasos que podrías tomar si estás tratando de optimizar esta aplicación sería revisar y agregar indicadores a tu función, agregar una configuración para asegurarte de que solo estás consultando los datos que necesitas. Esto es por qué la gente usa GraphQL. Pero GraphQL es complejo y tiene sus propias compensaciones. En mi opinión, una solución mucho más convincente a este problema es hacer que la consulta de datos que no necesitas sea tan económica que ya no te importe. Y creo que este tipo de latencia, si estamos hablando de una fracción de milisegundo, podríamos estar realizando decenas de estas consultas en una carga de página, y no nos acercaremos a nuestro presupuesto de tiempo de carga de página de 200 milisegundos.

Y luego, lo otro de lo que quería hablar aquí es que, ya sabes, ReadySet, ya sabes, la mayoría de las soluciones de caché, si hicieras una inserción en esta tabla, tendrías que descartar el resultado y luego volver a calcular el conjunto de resultados. Con ReadySet, si hago una inserción en esta tabla, se actualizará el conjunto de resultados de la caché y luego vuelvo a ejecutar la consulta, podemos ver, ya sabes, este número solía ser 100,008, ahora es 100,009. Este número cambió, pero la latencia no ha aumentado. Eso se debe a que no estamos volviendo a calcular el conjunto de resultados de la consulta. En realidad, estamos manteniendo el conjunto de resultados actualizado en su lugar basado en los data que fluyen en la database aguas arriba.

Entonces, la idea aquí es que no importa cuántas escrituras estés realizando, tus lecturas siguen siendo rápidas y siguen siendo tan rápidas como las ves aquí. Y todas estas consultas que he estado ejecutando son solo como una consulta aislada que estoy ejecutando en la shell de pSQL, lo cual no es muy realista. En una aplicación web del mundo real, no solo vas a ejecutar una consulta a la vez. Vas a ejecutar, ya sabes, miles o cientos de miles de consultas por segundo Y potencialmente, si tu aplicación está recibiendo mucha carga. Y para ver cómo se ve eso, simplemente voy a ejecutar PgBench, que es una herramienta de referencia que se distribuye con Postgres. Y solo para establecer una referencia, voy a ejecutar esto contra Postgres en sí mismo. Este archivo benchmark.sql contiene la misma consulta que hemos estado ejecutando. Y lo que estamos haciendo aquí es ejecutar 32 clientes concurrentes y hacer 32 consultas a la vez. Y podemos ver que cuando ejecutamos esto contra Postgres, nuestra latencia aumenta bastante un poco. Antes estábamos viendo alrededor de 700 milisegundos. Ahora estamos viendo de 3.5 a 4 segundos de latencia, porque Postgres, un solo servidor de database no escala muy bien. Y nuestras consultas por segundo son alrededor de nueve. Eso no es suficiente para una aplicación de producción del mundo real que está recibiendo mucha carga. Entonces, este es el escenario en el que es posible que no tengas otra opción que escalar con réplicas de lectura.

Con ReadySet, puedo ejecutar la misma prueba de referencia contra ReadySet, simplemente cambiando el puerto. Estas son las configuraciones de conexión predeterminadas. Estoy ejecutando todo esto localmente. Así que voy a ejecutar la misma prueba de referencia contra ReadySet. Y solo para enmarcar esto, cuando estamos ejecutando la shell pSQL, estamos usando el modo de consulta ad hoc. Estas pruebas de referencia utilizan declaraciones preparadas porque ReadySet, al igual que todas las bases de datos, funciona mejor con declaraciones preparadas porque solo tenemos que analizar la consulta una vez. Y podemos ver que la latencia incluso mejora más que lo que estábamos viendo en la shell pSQL por esa razón. Y las consultas por segundo pueden escalar hasta alrededor de 200,000. Y creo que 200,000 suele ser suficiente para la mayoría de las aplicaciones. Creo que tienes que estar haciendo bastante bien para que 200,000 consultas por segundo no sean suficientes. Pero en el caso de que estés haciendo tan bien para ti mismo, como dijo Nick antes, Ready Set puede escalar horizontalmente.

Entonces podemos ejecutar el doble de servidores ReadySet, el doble de servidores de caché ReadySet, sin agregar carga adicional a la base de datos aguas arriba porque solo estamos replicando datos de la base de datos aguas arriba una vez, y servir el doble de esto. Por lo tanto, podemos atender 400,000 consultas por segundo con el doble de servidores. Y de hecho, hemos visto números aún mejores que esto en nodos individuales, pero esto es solo la máquina de desarrollo de Griffin, que se ejecuta en la misma máquina. Así que se está ejecutando en mi escritorio.

Muy bien. Entonces, podrías ver todo eso y decir, bueno, no hay tal cosa como un almuerzo gratis. ¿Qué tengo que sacrificar? ¿Es esto demasiado bueno para ser verdad? Entonces, hay algunas pequeñas compensaciones que debes hacer con ReadySet. Creo que en general, a menudo no son un gran problema, pero voy a hablar de ellas un poco para que estés consciente de ellas. En primer lugar, lo más notable es que debes tener en cuenta que estás obteniendo consistencia eventual. No obtienes las mismas garantías de consistencia fuerte que obtendrías al consultar tu base de datos aguas arriba. Lo que eso significa en la práctica es simplemente que los resultados que obtienes en una caché pueden estar ligeramente desactualizados. Hay un pequeño retraso para que los datos se repliquen y actualicen en tu caché. Eso puede ser menos malo de lo que piensas. Para muchas consultas, está bien. Para algunas no lo está. Pero como vimos, puedes habilitar y deshabilitar fácilmente la caché para consultas individuales según sea necesario. Si hay consultas específicas en las que sabes que realmente necesitas esas garantías de que todo esté actualizado, por ejemplo, como con el saldo de una cuenta bancaria, no querrás tener consistencia eventual allí porque no quieres que el usuario pueda gastar el mismo dinero dos veces porque tal vez intentaron gastarlo una segunda vez antes de que el saldo se haya actualizado en los resultados de la caché o algo similar. En ese caso, obviamente no querrías cachear esa consulta. Pero al mismo tiempo, si el mismo banco hipotético tiene un panel de control que el usuario puede ver para ver sus transacciones recientes, podría ser completamente aceptable cachear eso porque si realizan una compra y no aparece en su aplicación telefónica durante un segundo, nadie realmente lo notará o le importará. No es un gran problema en absoluto.

En segundo lugar, el uso de memoria, obviamente, es un problema con cualquier solución de caché. Cuando estás cachando datos, tienen que ir a algún lugar. Por lo tanto, cuanto más datos caches, más memoria utilizas. Pero nuevamente, poder habilitar y deshabilitar la caché para consultas individuales hace que eso generalmente sea bastante fácil de gestionar. Puedes decidir qué consultas valen la pena cachear y gastar memoria en ellas. Y además, como también mencionamos, puedes escalar a múltiples nodos si es necesario. Si realmente quieres cachear más datos de los que caben en un solo nodo. Esa también es una opción.

Finalmente, esto puede ser obvio, pero funciona mejor para cargas de lectura pesadas. Creo que cuando vimos ese diagrama anterior donde mostramos cómo ocurre la replicación y cómo ReadySet mantiene los resultados actualizados, es posible que hayas notado que había una flecha para las escrituras que va directamente desde el cliente a la base de datos aguas arriba.

Las escrituras van directamente a la database. No pasan por ReadySet. Si estás construyendo algún tipo de aplicación con alta carga de escritura donde tienes millones de sensores IoT que envían data cada segundo, entonces ReadySet simplemente no te ayudará con eso. Tal vez aún te ayude con las lecturas si tienes un problema de rendimiento de lectura para esa misma aplicación. Pero todo esto se trata de hacer consultas y no de ingresar datos.

Y finalmente, todavía estamos en una etapa temprana. Todavía estamos encontrando y corrigiendo errores, aunque hemos estado progresando muy bien con eso últimamente. No todas las consultas son compatibles, porque para saber cómo mantener los datos actualizados en nuestras cachés, tenemos que ejecutar las consultas y conocer cómo funcionan las diferentes funciones y operadores SQL. Por lo tanto, aún no hemos implementado el soporte para todos ellos, pero estamos agregando más todo el tiempo.

Y, ya sabes, somos completamente de código abierto, por lo que siempre agradecemos los comentarios de la community. Si hay alguna función que no está presente y te gustaría ver, o cualquier tipo de problema que estés teniendo, por favor, ve a GitHub. Deja un comentario, presenta un problema y estaremos muy contentos de recibirlo y hablar contigo y ver lo que estás encontrando y viendo. Oh, tenemos una pregunta.

Oh, sí. ¿Es necesario instalar ReadySet localmente? Oh, esa es una excelente pregunta. Definitivamente no es necesario instalarlo localmente. Se puede instalar en cualquier tipo de máquina compatible que desees. Además, ofrecemos una versión cloud de ReadySet que configuramos, administramos, ejecutamos y brindamos soporte. Entonces, si solo quieres probarlo, descarga la versión de código abierto. Pero si quieres ejecutarlo en producción para tu empresa y no quieres lidiar con la instalación y el mantenimiento, estaremos encantados de hablar sobre los clientes de cloud. En cuanto a las opciones de implementación, tenemos un Helm Chart para ejecutarlo en Kubernetes. También puedes implementarlo en metal desnudo o en una instancia de EC2. Pero sí, si hay una forma particular en la que deseas implementar ReadySet y necesitas ayuda para hacerlo, te sugiero que crees un problema en GitHub y estaremos encantados de ayudarte. Sí. Sí, absolutamente. Muchas gracias a todos. Genial. Muy bien. Bueno, que tengan un buen día, todos.