Éste post me parece muy importante para poder entender como funcionan y hacer grandes sistemas pensados para escalar, sea por tráfico, por multi-sitio, multi-país, y más… todos estos sistemas distribuidos presentan la misma particularidad, y en el año 2000 un señor llamado Eric Brewer, pudo definir tres importantes propiedades y desarrollo un teorema. El se dio cuenta que mientras más aplicaciones basadas en la WEB existan, menos debemos preocuparnos por la consistencia de los datos, si queremos alta disponibilidad de nuestras aplicaciones entonces no podemos garantizar la consistencia de los datos.

El teorema CAP, también llamado formalmente Teorema de Brewer, dice que un sistema de datos distribuido pude asegurar dos de estas tres propiedades: Consistencia, Disponibilidad y Tolerancia al particionado. Bien, que significa cada una:

El bloqueo es la esencia de cualquier manejador de bases de datos relacional (RDBMS), para el caso de MySQL es importante destacar que el engine InnoDB lo gestiona de forma óptima, hasta la fecha no hay otro que lo haga mejor.

No podemos confundir bloqueos con niveles de aislamiento, ya que el bloqueo se hace a nivel de registros usando una instrucción específica, mientras el nivel de aislamiento es el comportamiento por defecto para cualquier otra instrucción normal que manipule los registros.

Los bloqueos existen para poder garantizar el ACID, su correcta implementación permite que halla concurrencia, de lo contrario se puede presentar la contención y es fatal.

Los bloqueos los podemos dividir en dos grandes …

Dedique varias semanas en investigar como implementar CloudFormation de Amazon para montar un entorno de pruebas de Percona XtraDB Cluster con cuatro nodos, dos HAProxy, un servidor con Nagios, y una VIP, adicionalmente usando Puppet, la idea que me atrajo de usar CloudFormation fue la practicidad de definir toda una infraestructura de maquinas virtuales usando un JSON como template, el tener un formulario para definir variables, y luego tener la ventaja de poder crear y destruir cualquier cantidad de veces el cluster de forma automatizada.

Al final me di cuenta que no es seguro usar CloudFormation por varios motivos:

• CloudFormation se asegura de mantener toda la infraestructura al 100% como está definida en el JSON. Si no hay algo que no encaja, crea una nueva maquina y destruye la anterior, al tener una Base de Datos con datos de producción los podemos perder muy fácilmente. Esto me paso al cambiar la versión de la AMI, …

Es curioso como se desencadena toda una revolución por un simple hashtag. Aquí les dejo una breve historia de su verdadero origen:

Johan Oskarsson organizó un evento en Junio de 2009 en San Francisco, la intención era discutir las nuevas tecnologías en el mundo IT sobre el almacenamiento y procesamiento de datos. La principal razón del evento fueron los nuevos productos como BigTable y Dynamo. Para el evento era necesario encontrar una palabra clave para ser usada en un hashtag de Twitter, término siendo “NoSQL“ y fue sugerido por Eric Evans de RackSpace. El término fue planeado para ser utilizado sólo para ésta reunión y no tenía un significado profundo. Pero resultó que se extendió por la red de forma viral y se convirtió en el nombre de facto de una tendencia de las bases de datos no relacionales y distribuidas.

El término …

La verdad no se como empezar este post, ya que el tema es muy delicado en el mundo de RubyOnRails y algo en Java, no quiero ofender a la comunidad, sino ayudarlos hacer un buen modelo de datos dentro de un Manejador de Bases de Datos Relacionales (RDBMS). Considero que primero debemos enterarnos que son las relaciones polimórficas, luego hablar de los problemas que conlleva y por último como podemos evitarlos.

¿Qué son las relaciones polimórficas?

Es una forma de relacionar muchas tablas con una sola mediante una única relación, esto se debe que programamos orientado a objetos y tratamos la base de datos de la misma forma, creando relaciones entre objetos, es una implementación de la librería (gema) ActiveRecord que compone el framework RubyOnRails. Depende del enfoque, esto nos puede traer un ahorro en el uso de tablas como …

El gran dilema, bases de datos relacionales (RDBMS) y no relacionales (NoSQL), todos preguntan, todos hablan de ello, estamos comparando cual es mejor, en fin, hay una gran incertidumbre en el tema, muchos apuntan a un extremo o al otro, cometen errores y nos olvidamos de ver con objetividad. Quiero explicar de que va todo esto de una forma simple para entendernos. Quiero recordar que grandes volúmenes de datos no son un simple millón de rows, son mucho más, billones por ejemplo, ahora imagina billones de rows que interactúan con otros billones de rows para generar información más significativa, cuando hay grandes volúmenes de información se aprecia todo de una forma diferente, esto impacta en tiempo y dinero.

Cada tipo de base de datos nació en una época …

El aislamiento es una parte importante de la propiedad ACID que garantiza que las transacciones sean fiables. Esto permite que las transacciones que se ejecutan simultáneamente no interfieran con otras, garantizando la integridad de los datos, al no existir aislamiento en una transacción podría modificar los datos que otra transacción está leyendo, por lo que se crea una inconsistencia cuando se crean datos.

Ahora que entendemos que es el aislamiento en términos generales, vamos a conocer cuales son los niveles de aislamiento, estos determinan como las transacciones se comportan con otras transacciones, es como ser más o menos restrictivo. Escoger cual es el mejor nivel depende de las necesidades de la aplicación, primero debe entender cuales son los beneficios y consecuencias de cada una de ellas.

InnoDB soporta los cuatro niveles de aislamiento estándar, a continuación se describen los estándares usados …

Puede que este papel hoy en día se este perdiendo, y se haya mezclado con los de Operaciones o con algún Desarrollador, está mal!, en proyectos grandes es muy importante dedicarle todo el tiempo posible, llega un momento que el volumen de datos y el tráfico se vuelve insostenible, a este punto, cuando algo falla es catastrófico y no suele arreglarse rápidamente, la prevención es bastante crucial y se vuelve una eterna lucha.

Ser Administrador de Bases de Datos es algo bastante exigente, porqué debes saber un poco de todo; de programación, de sistemas y mucho de Bases de Datos. El dominio de cada una de ellas es bastante crucial para entender como gestionar bien los recursos, prevenir incidencias e incluso resolverlas.

Debes trabajar codo a codo con los Desarrolladores, antes que ellos se …