Scale-out + Data Shard (Databases Architecture)

Scale-out + Data Shard (Databases Architecture)

Imaginemos la siguiente situación: somos una empresa y hemos crecido de forma orgánica, pero, se ha acumulado toda nuestra información en una “Monster Database”. ¿Qué tenemos delante nuestro? Claramente tenemos un gran problema, ya que seguramente ésta tendrá un coste (€) alto sumado a que tenemos una base de datos y un gran punto de fallo, sin entrar en detalles de escalabilidad, etc…

Monster database

Podríamos afrontar el problema haciendo un triple salto, aunque seguramente el resultado no sería, pada nada, el esperado (con suerte… quizás si). Es por ello que me agradaría plantear un triple salto, pero por partes, veamos:

Databases Architecture

En el anterior diagrama se plantea la posibilidad de iniciar un trabajo de investigación, primero, de nuestra tipología de información ya que, por ejemplo, de entrada podríamos afrontar una separación del acceso a la información, donde los datos que sean de lectura puedan ir a una base de datos (mirror) sólo para tal finalidad y, los de escritura, a nuestra base de datos Master. Por ejemplo podemos realizarlo de forma rápida con AWS Aurora Read Replica, ya en un anterior post hablamos de como migrar los datos y no morir en el intento.

Con éste “simple” cambio podremos dividir nuestro tráfico, estoy seguro que nuestra base de datos de lectura tendrá mucho más tráfico (tener una talla mayor), ya que por ejemplo los accesos de login, API, etc… pueden usar de forma exclusivo el endpoint correspondiente y dejar la de escritura para las finalizades que requieran de una inserción, update o delete, por ejemplo y éstas, seguro, son mucho más reducidas.

Un siguiente y segundo paso podría ser perfectamente el activar el shard de los datos, ya que con ello mejoraremos por ejemplo el acceso de lectura, es posible que algunas de nuestras query requieran de una alta computación, si no estudiamos con requerimiento nuestras necesidades, es posible que el coste de migración al Cloud sea Alto y tampoco es plan. Debemos, siempre, analizar con pasión nuestro comportamiento, la tiplogía de accesos y de información que tenemos y como la operamos. Es por ello que la activación del modo sharding de AWS Aurora es muy recomendable ya que podremos tener replicados nuestros datos en múltiples instancias y, también, poder computar una misma query en múltiples instancias; el tiempo de computación quedará reducido de forma muy interesante.

Un tercer paso, que podríamos dividir en dos, sería el separar la tipología de información. Es decir, por ejemplo:

  • Podríamos tener la información más clásica, operacional, pero también…
  • Podríamos tener la información más masiva, por ejemplo del tipo fichero.

Aquí podríamos afrontar el split de los datos, por ejemplo datos masivos del tipo “stream” podrían aglutinarse en ficheros (JSON) y guardarse como tal en una NoSQL o en formato File directamente en un Storage (AWS S3 por ejemplo). Éste tipo de información, por ejemplo en una SQL, ocupa mucho espacio y podría ralentizar nuestra computación en momentos de recuperación de información o de simple inserción de nuevos registros.

También, es totalmente posible, que tengamos tipologías de información que requieran de un proceso analítico posterior, por lo tanto también podríamos afrontar un nuevo cambio, apuntando dichos procesos a los nodos de read replica o directamente a los files. En un anterior post ya hablamos de como idear y afrontar un estrategia de Data Scaling y Data Caching, aquí también lo podríamos tener presente y crear una más que correcta estrategia para llevar nuestra empresa a un siguiente nivel.

Autor: Joakim Vivas

comments powered by Disqus