La segunda pieza con YugabyteDB es la capa de almacenamiento, ¿verdad? La capa de consulta, tomamos el enfoque de Aurora, la capa de almacenamiento, tomamos realmente el enfoque de Google Spanner porque queríamos tanto la escalabilidad como la alta disponibilidad. Si sabes algo sobre Amazon Aurora, sabes que aunque escala muy bien las lecturas, la escalabilidad no es tan buena. Así que usando Google Spanner y el consenso Raft, podemos agregar lentamente más nodos a tu clúster hasta que lo necesites, ¿verdad?
Y solo para profundizar en el conjunto de características de RDBMS, esto es lo que se admite hoy en YugabyteDB a partir de la versión 2.9, puedes ver una lista completa en nuestra documentación también. Cosas como procedimientos almacenados, disparadores, seguridad a nivel de roles, tipos definidos por el usuario, etc., verás que no muchas bases de datos NoSQL, si alguna, NewSQL, así como todos los sistemas SQL distribuidos, no tendrán eso porque es casi imposible hacerlo sin reutilizar el código SQL de Postgres. Entonces, si estás usando alguno de estos hoy, ten la seguridad de que también puedes usarlos con YugabyteDB si decides hacer esa transición.
Ahora, para profundizar en la parte de escalabilidad. Aquí a la izquierda, esto es lo que has visto durante años, tu típica, tenemos un servidor único de base de datos y los clientes llegan, todos nuestros datos están en un solo nodo. Si queremos escalar para poder manejar más tráfico de clientes, estamos un poco limitados. Dependiendo de dónde esté tu cuello de botella en el almacenamiento o si es la CPU o si es la RAM, realmente todo lo que puedes hacer es aumentar el tamaño de tu instancia, escalar verticalmente. Y eventualmente, llegas a este punto de cruce donde se vuelve demasiado caro, ¿verdad? O tal vez las limitaciones físicas están ahí. Estás confiando en los fabricantes de estos servidores que eligen las relaciones entre CPU y RAM, ¿verdad? Y a veces eso es lo que te hace pensar, bueno, ahora tengo que empezar a fragmentar, ¿verdad? Bueno, hasta este punto, habrías tenido que fragmentar manualmente si estás usando MySQL, Oracle, tienen la capacidad de fragmentar, pero no hacen fragmentación automática como lo hace YugabyteDB, tienes que fragmentar manualmente tus datos en un clúster y tienes que administrar todo eso. Cada vez que hay cambios, tendrás que hacer esos cambios en los fragmentos mismos y fragmentarlo manualmente a la aplicación, y esto lleva mucho tiempo. Si eres alguien que está haciendo esto hoy o lo ha hecho en el pasado, o incluso solo ha oído hablar de ello, lleva mucho tiempo y también requiere mucha experiencia. Por lo tanto, el objetivo de YugabyteDB era eliminar esto del usuario y asegurarse de que la base de datos misma pudiera hacerlo automáticamente.
Entonces, cada vez que creas una base de datos en YugabyteDB, mira aquí a la derecha, dividimos esos datos en fragmentos y luego distribuimos esos fragmentos en todos los nodos de tu clúster. La parte interesante de esto es que ahora cada uno de estos nodos actuará como el nodo maestro, aceptando el tráfico del cliente, teniendo su propia CPU y RAM que puede atender ese tráfico. Cada vez que necesites escalar, aún puedes escalar verticalmente si lo deseas, ¿verdad?, pasar de dos núcleos a cuatro núcleos, ocho, 16, 32, etc., o simplemente puedes agregar más nodos al clúster. Y estos nodos pueden estar en la misma región, pueden estar en diferentes regiones, somos muy flexibles cuando se trata del tipo de topología que tienes. La parte clave es que todos estos nodos son idénticos, ¿verdad?, cada nodo tiene su propia capa de consulta de Postgres, tiene su propia capa de almacenamiento de DocumentDB que se ejecuta en el nodo de YugabyteDB dentro de un solo clúster.
Entonces, si miramos a un usuario en su teléfono celular, si tienes una aplicación móvil o es una aplicación web que utiliza GraphQL conectado a algo como Hasura GraphQL Engine, y luego Hasura se comunica con el motor de YugabyteDB, se comunica con esa capa de consulta que es compatible con Postgres, como verás cuando hagamos la demostración de Hasura, estaremos utilizando el Conector de Postgres en sí. No hay un conector especial de YugabyteDB, estamos utilizando el mismo exacto. Y luego eso se comunica con los datos, ¿verdad? Conectando a cualquier nodo, YugabyteDB almacenará en caché las diferentes ubicaciones de los fragmentos y podrá dirigir el tráfico hacia donde sea necesario, y luego puedes agregar o eliminar nodos en cualquier momento sin tiempo de inactividad. Eso es diferente a cómo tendrías que hacerlo con sistemas tradicionales, ¿verdad? Digamos que tenías una aplicación monolítica y una base de datos de un solo servidor, tendrías una aplicación conectada a GraphQL, conectada al servidor GraphQL, que golpea esa instancia de Postgres de un solo nodo, en este ejemplo.
Ahora, si vemos cómo se verá con YugabyteDB y GraphQL, como ves hoy, te divides en microservicios, cada uno utiliza APIs de GraphQL, conectándose al mismo clúster. A medida que construyes más microservicios y más APIs, puedes golpear el mismo clúster y agregar nodos a ese clúster, ¿verdad? Entonces no estás limitado a un solo nodo. Si comienzas con un clúster de tres nodos, puedes hacer crecer eso a un clúster de seis nodos o un clúster de nueve nodos, etc. Incluso si estás ejecutando, muchas veces en nuestras conversaciones, los usuarios crearán microservicios para su código de aplicación y dividirán su código de aplicación masiva en diferentes secciones. Y a veces todavía lo están ejecutando en un solo nodo de base de datos, ya sea Postgres, MySQL, Oracle. No importa realmente, porque al mismo tiempo todos ellos son, es el mismo tipo de sistema, ¿verdad? No escala tan fácilmente. Entonces, una parte clave de cualquier tipo de esfuerzo de modernización para tus aplicaciones será la base de datos. Porque realmente lo que estamos haciendo es que si continúas ejecutándolo en una instancia de un solo nodo, eventualmente te encontrarás con otro cuello de botella. Porque ese es un beneficio que YugibyteDB proporciona.
Y hay diferentes topologías con cualquier clúster de YugibyteDB. Cada clúster de YugibyteDB tiene un mínimo de tres nodos. Entonces, si asumimos que cada una de estas pequeñas visualizaciones es un solo nodo, puedes ejecutarlo en diferentes zonas de disponibilidad. Bien, zona de disponibilidad uno, zona de disponibilidad dos, zona de disponibilidad tres. Tus datos se distribuyen en estos tres nodos que se ejecutan en tres zonas de disponibilidad diferentes, y se replican de forma síncrona y utilizando el consenso RAF para asegurar la integridad de los datos entre ellos. Entonces tienes consistencia entre zonas, pero obviamente no tienes la ventaja de los rellenos regionales. Ahí es donde entra en juego la topología regional. Si deseas redundancia a nivel de región, querrás tener tus nodos en tres regiones diferentes en lugar de tres zonas de disponibilidad diferentes. Técnicamente, también pueden ser tres zonas de disponibilidad diferentes. Pero estarán en tres regiones diferentes, ¿verdad? Entonces, ahí está la clave. Estamos ampliando la distancia que queremos proteger.
Y luego la última es la multi-nube. Si deseas ejecutar en AWS, GCP y Azure, y deseas tener X cantidad de nodos en cada uno, también puedes hacerlo. Y eso obviamente lo lleva a otro nivel, ¿verdad? Donde si algo tuviera un nuevo proveedor de nube en una región en particular, tienes otros proveedores de nube que se asegurarán de que tu clúster siga funcionando. Y estas nubes también pueden ser un centro de datos privado. Entonces, esto no necesariamente tiene que ser una nube pública como AWS. Si tienes tu propio centro de datos, puedes tener un nodo en tu propio centro de datos y luego otros nodos que estén tal vez en nubes públicas. Una de las áreas clave de conversación que tenemos con los usuarios es a medida que se expanden a nivel mundial, ¿cómo llegamos a nuestros usuarios con una latencia más baja en estas nuevas regiones en las que estamos lanzando nuestra aplicación? Y para eso, eso es algo en lo que YugibyteDB es realmente bueno, donde te permite escalar y agregar nodos a nuevas regiones según sea necesario. Y puedes lograr esto de dos formas diferentes. Una de ellas es mediante la replicación síncrona y la idea de la partición a nivel geográfico, donde asignas filas específicas a regiones específicas. Particionamos una columna en particular que te permite seleccionar diferentes variables que te permiten elegir, bueno, si llega una fila y la columna geográfica es EE. UU., se asignará automáticamente esa fila a Estados Unidos. Si es la UE, irá a la UE. Si es Asia, irá a Asia. ¿Verdad? Entonces, eso es algo que, cuando surge mucho, cuando hablas de cumplimiento de datos, especialmente con el cumplimiento de la UE y el GDPR, casi siempre necesitamos asegurarnos de que, bueno, los datos de la UE se queden en la UE. Pero al mismo tiempo, si quisieras, podrías consultar en las diferentes regiones, pero los datos se almacenan en esa región en particular. YugabyteDB también tiene el concepto de replicación asíncrona. Entonces, si deseas tener dos clústeres separados sincronizados con replicación asíncrona en lugar de replicación síncrona, eso también es algo que podemos hacer. Y cuando hemos visto a los usuarios lograr eso para una baja latencia en diferentes regiones también. Al combinar Yugabyte Cloud y otros servicios diferentes, digamos, por ejemplo, Hasura Cloud, realmente hemos visto a los desarrolladores comenzar a adoptar este tipo de arquitectura donde no tienen que lidiar con la infraestructura. No tienen que ir a la línea de comandos y ejecutar diferentes scripts y diferentes tipos de comandos para implementar estas diferentes tecnologías. Estas tecnologías son completamente administradas para ellos por las personas que las construyeron en primer lugar. Y al usarlas juntas, realmente obtienes una pila GraphQL totalmente administrada. Y eso es lo que vamos a mostrarte hoy en la parte de Hasura.
Comments