Hace unos días, en uno de los proyectos en los que participo, tuvimos que enfrentarnos a un problema que poseen las bases de datos SimpleDB de Amazon. Aunque para la mayoría de los proyectos podría funcionar correctamente, existen dos limitaciones a la hora de abordar proyectos grandes con esta tecnología.
La primera limitación tiene que ver con el límite de 10 GB de capacidad. Se que muchos de vosotros seguramente os sobrará con esa capacidad, pero en proyectos grandes es una limitación muy a tener en cuenta.
La segunda limitación no está muy clara, porque no encuentras cual es el número de peticiones por segundo que soporta un dominio. Por lo que pone en una FaQ comparando SimpleDB y DynamoDB, el límite estaría en 25 peticiones por segundo. Como hemos comentado anteriormente, seguramente para la mayoría de proyectos 25 peticiones por segundo (90000 peticiones hora) puede satisfacer las previsión de peticiones que se esperan recibir. Sin embargo, en algunos proyectos, como en el que me encuentro, podría suponer un obstáculo casi insalvable a la hora de elegir SimpleDB frente a otras tecnologías, como DynamoDB que en principio no tiene tantas restricciones pero tiene la contrapartida de resultar más cara y ser menos flexible que SimpleDB.
Así, decidimos realizar un pequeño algoritmo siguiendo las consejos de Amazon y poniendo algo de nuestra parte, para poder solventar estos problemas y utilizar la tecnología.
El reparto de dominios en SimpleDB
Debemos tener guardado en algún sitio, el número de dominios activos y los dominios que están activos en ese momento. Además, las claves deben contener el dominio en el que se encuentran. Vamos a ilustrar con un ejemplo:
Queremos guardar en nuestros dominios una lista de usuarios, y actualmente tenemos tres dominios activos (porque necesitamos dar soporte a 270.000 peticiones hora), por lo que nos encontramos con los siguientes dominios creados:
usuarios_Ausuarios_Busuarios_C
Así tendremos la siguiente lista de dominios activos (A,B,C) y nuestro número de dominios será de 3.
Cuando tengamos que guardar un usuario, utilizaremos nos crearemos un id único (no entra en este blog la creación de estos ids) y haremos una operación de módulo para saber el dominio que le corresponde. Así, si tenemos que guardar los siguientes usuarios:
Usuario Antonio, ID: 1Si hacemos la operación 1 mod 3 = 1. El dominio que le corresponde es el B (según la posición, el A le corresponde el 0, el B el 1 y el C el 2). Ahora nos llegan otra ristra de usuarios:
Usuario Bea, Id:2.
2 mod 3 = 2. El Identificador del usuario será 2CUsuario Manolo, Id: 33 mod 3 = 0. El identificador que le corresponde es 3A.
Usuario Pepe, Id: 44 mod 3 = 1. El identificador que le corresponde es 4B.
y Así con todos los usuarios. Si nos damos cuenta que el dominio B se llena (Amazon nos devolverá una excepción indicando el hecho), debemos crear un nuevo dominio (el dominio D) y actualizar nuestra lista de dominios.
Lista de dominios: A,C,D. Así, cuando hagamos la operación de módulo, ahora a la A le corresponderá el 0, el 1 será para el C y el 2 para el D.
Si tenemos los siguientes usuarios:
Usuario Juana, ID: 5hacemos la operación 5 mod 3 = 2. El identificador del usuario será 5C.
Si nos damos cuenta, así somos capaces de repartir la carga y además seguir funcionando a pesar de haber sobrepasado los 10 GB de un dominio.
Si vemos que con 3 dominios activos no somos capaces de satisfacer el número de peticiones, podemos aumentar el número de dominios activos. Es decir, podemos pasar de 3 a 4, simplemente creando un nuevo dominio y añadiendo el dominio a nuestra lista de dominios activos.
Si continuamos con el ejemplo, ahora vamos aumentar el número de dominios a 4, así se queda:

Lista de dominios activos: A,C,D,E (que se corresponde con A=0, C=1,D=2,E=3)   Número de dominios activos: 4Así, si tenemos que almacenar los siguientes usuarios, haremos lo siguiente:
Usuario María, ID 66 mod 4 = 2. El identificador será 6D.
Usuario Bea, ID 77 mod 4 = 3. El identificar será 7E.
Así ya tenemos el algoritmo completo. Si tenemos que consultar un usuario, en concreto, sólo tenemos que coger el último dígito y preguntar en el dominio correspondiente. Así, si tenemos que actualizar un usuario con 6D, buscaremos ese ID en el dominio que se llama USUARIOS_D.
Así ya tenemos completados todos los casos. Este algoritmo funciona muy bien para dominios que no van a estar haciéndose consultas masivas de información. En ese caso, según el número de dominios, tendremos que evaluar la opción de utilizar una DynamoDB.