5.2 Desaf´ıos t´ ecnicos
5.2.3 Persistencia de datos
Previamente, se mencion´o la utilizaci´on de dos tipos diferentes de motores de bases de datos. El equipo tuvo que pasar por un proceso de investigaci´on para tomar una buena decisi´on en cuanto a d´onde (y c´omo) se iban a almacenar los datos. A continuaci´on se detalla t´ecnicamente las opciones elegidas y una idea en alto nivel de como fueron utilizadas.
DynamoDBes una base de datos no relacional, ideal para cuando se conocen de antemano los patrones de acceso a datos que va a tener la aplicaci´on y no se necesitan cruzar datos entre registros [46]. En otras palabras, no se necesita tener el concepto de“JOIN” (durante una solicitud) de una base de datos relacional tradicional.
Las claves primarias de DynamoDB se comportan como las claves primarias de otros motores, pero ´estas se componen de una “partition key”(requerida) y una
“sorting key”(opcional). Las partition key pueden verse como un puntero a la loca- lizaci´on del dato en un servidor, recordando que DynamoDB es una base de datos distribu´ıda en varios servidores[47].
Una sorting key, tambi´en conocida como “range key” obliga a DynamoDB a guardar los registros de una partici´on de manera ordenada. Adem´as, varios registros pueden ser almacenados con la mismapartition key siempre y cuando lasorting key difiera del resto. Esto genera un patr´on de acceso interesante donde, por ejemplo, se puede guardar el documento de identidad de un cliente comopartition key y como sorting key losids de ventas que realiz´o. Esto permitir´ıa la r´apida b´usqueda de una compra en particular (por sorting key) u obtener todas las compras realizadas por el mismo cliente (porpartition key).
Sin embargo - y por esto es importante conocer con cierta seguridad los patrones de acceso a datos al utilizar DynamoDB - es virtualmente imposible (muy ineficiente y costoso) obtener todas las compras de un d´ıa con modelo. Es importante notar que una vez la tabla es creada con una determinadapartition key esta no puede ser modificada.
A su vez, ofrece dos tipos diferentes de ´ındices[48]:
´Indices secundarios globales: en donde la clave primaria del ´ındice pueden ser dos atributos cualesquiera de la tabla.
Indices locales secundarios: en donde la clave de partici´on del ´ındice debe ser igual a la clave de partici´on de la tabla,pero la clave de ordenamiento puede ser cualquier otro atributo.
Con este tipo de ´ındices pueden subsanarse algunas consultas como la descrita anteriormente sin embargo existe un l´ımite fijo en la cantidad de ´ındices secundarios que se pueden crear en DynamoDB (durante el tiempo de desarrollo el l´ımite era 20).
Una forma de flexibilizar estos l´ımites es utilizar el patr´on de dise˜no propuesto por Alex DeBrie (escritor deThe DynamoDB Book[49]) [50][“single table design”] e impulsado por Amazon, en donde se modelan los datos en una ´unica tabla, que se sirve de distintos tipos de claves e ´ındices de los datos.
Para lograr entender en profundidad los beneficios que describe este modelo es necesario adentrarse con patrones avanzados de dise˜no de dynamodb. Adem´as de los recursos citados en el p´arrafo anterior, el lector puede informarse mas en [51, los laboratorios de AWS para DynamoDb]. La conclusi´on mas importante sobre el modelado en dicha base de datos es que es flexible aplicados algunos conceptos avanzados pero no tan intuitivo y definitivamente no tan familiar como una base de datos SQL.
Por otra parte,RDSes un servicio ofrecido por AWS de base de datos relacional donde, en su variante del servicio denominada “AuroraDB”, ofrececlusters de bases de datos “PostgreSQL” en formatoserverless. Esto significa que AWS es encargado de mantener la infraestructura de los servidores utilizados y provee unaData Api[52]
para consultar la base de datos mediante pedidos HTTP.
Contar con la Data Api no es menor, ya que de otra manera el equipo habr´ıa tenido que gestionar sus propias conexiones a la bases de datos, las cuales tienen
un costo de “construcci´on” y “destrucci´on”. Esto no es un problema en una infraes- tructura tradicional pero si en un ambiente “serverless” dondeen teor´ıa no existe memoria compartida entre ejecuciones de un mismoLambda (por lo cual no se puede mantener esa conexi´on abierta en memoria).
En la pr´actica elscope principal donde se define el manejador de laLambdano es destruido luego de cada ejecuci´on, por lo que es posible persistir cierta informaci´on en este punto. Sin embargo, esa informaci´on es vol´atil dado que depende del framework de AWS cu´ando y por qu´e destruye completamente el contexto. Eso puede suceder por ejemplo por desuso, si no hay invocaciones en un lapso de tiempo AWS libera ese entorno de ejecuci´on (contenedor), o tambi´en puede ser ocasionado por otras necesidades de infraestructura.
En general la mejor pr´actica es usar ese contexto para constantes, evitando per- sistir informaci´on din´amica entre llamadas a funciones en la memoria del entorno.
La alternativa entonces a usar la Api HTTP es utilizar un servicio que se en- cargara de la tarea de gestionar las conexiones como Amazon RDS Proxy lo cual implicar´ıa incurrir en gastos extra para mantener dichopool de conexiones abierto.
Como el equipo contaba con nula experiencia en dise˜no de este tablas con dise˜no
“one table”, opt´o por usar este modelo para estructuras de datos con consultas bien definidas. Si bien algunos de los requerimientos de consultas que el equipo tuvo pudo haber sido resuelto con un dise˜no correcto de DynamoDB, el equipo opt´o por la familiaridad en “PostgreSQL” para realizarlo (particularmente para implementaciones queries conjoins din´amicos).
La persistencia de datos no relacionados, como ser datos de usuarios y las configu- raciones est´aticas de su instancia de la “Consola” fueron realizadas en DynamoDB, mientras que por ejemplo, datos de las promociones o clientes los cuales pueden ser filtrados de distintas formas a elecci´on del usuario, fueron persistidos en PostgreSQL para hacer m´as f´acil su consulta.
El equipo igualmente no descarta que a medida que su conocimiento y dominio
del dise˜no de tablas en DynamoDB aumente y los estimativos de gastos comparan- do a los gastos incurridos por utilizar Aurora lo validen, se migren tablas a esta tecnolog´ıa.