Una máquina no alcanza

Cuando una máquina ya no alcanza

Una base de datos relacional típica vive en un servidor. Cuando la carga crece, la primera respuesta es escalar verticalmente: más memoria, más procesadores, discos más rápidos. Pero eso tiene un techo, y cada salto cuesta más. La alternativa es escalar horizontalmente: repartir el trabajo entre muchas máquinas normales.

Repartir el trabajo es lo que hacen las bases de datos paralelas: dividen los datos (normalmente por tablas o por filas) para procesar una operación en varios discos y procesadores a la vez. Sirve para responder más rápido y para atender más carga sin que crezca el tiempo de respuesta. Hay cuatro arquitecturas:

• Memoria compartida: todos los procesadores usan una misma memoria. Se comunican muy rápido, pero el bus se vuelve cuello de botella: no pasa de 32 o 64 procesadores.
• Disco compartido: cada procesador tiene su memoria, pero todos acceden a los mismos discos. Si uno falla, otro toma su trabajo; el cuello de botella pasa a ser la conexión con los discos.
• Sin compartimiento: cada nodo tiene su procesador, su memoria y sus discos, y solo se comunican por la red. Es la que mejor escala, a cambio de que pedir datos a otro nodo cuesta más.
• Jerárquica: combina las anteriores; por ejemplo, nodos sin compartimiento que por dentro comparten memoria.

NoSQL: no solo SQL

NoSQL (not only SQL) agrupa los modelos y sistemas de bases de datos con arquitecturas distintas a la relacional. El nombre no dice “sin SQL”: algunas también lo aceptan, y conviven con las relacionales en arquitecturas políglotas, cada una para lo que mejor hace. Hay cuatro familias:

• Clave-valor: un diccionario gigante; cada clave aparece una sola vez. Ejemplos: Redis, DynamoDB, Riak.
• Documentos: cada registro es un documento (JSON, BSON, XML, YAML) con su propia estructura, y se puede buscar por su contenido. Ejemplos: MongoDB, Couchbase.
• Columnas anchas: filas con muchísimas columnas agrupadas en familias, pensadas para enormes volúmenes. Ejemplos: Cassandra, HBase, BigTable.
• Grafos: nodos y relaciones como ciudadanos de primera clase. Ejemplos: Neo4j, OrientDB.

Sus ventajas: diseño más simple, escalamiento horizontal sencillo en clústeres, esquemas flexibles y un control más fino de la disponibilidad. A cambio, muchas relajan las garantías ACID por BASE: disponibilidad básica, estado flexible y consistencia eventual.

Sharding y replicación

Para escalar horizontalmente, una base NoSQL como MongoDB usa dos técnicas a la vez:

• Sharding (particionamiento): divide los datos en trozos (shards) que viven en máquinas distintas, según una clave de shard. Un enrutador (mongos) recibe cada consulta y la envía al shard correcto; unos servidores de configuración guardan qué datos están en cada shard.
• Replicación: cada shard se copia en varios nodos (un replica set), para tolerar la caída de una máquina.

El teorema CAP

Un sistema distribuido quisiera tres cosas:

• C · Consistencia: todos los nodos ven el mismo dato al mismo tiempo.
• A · Disponibilidad: todo pedido recibe respuesta.
• P · Tolerancia a particiones: el sistema sigue funcionando aunque la red se corte entre nodos.

El teorema CAP dice que solo se pueden garantizar dos de las tres. Como en un clúster real la red sí se corta, la decisión práctica es qué sacrificar cuando eso pasa:

• CP (MongoDB, HBase, Redis, BigTable): ante un corte, el lado sin mayoría deja de responder antes que dar un dato viejo.
• AP (Cassandra, Dynamo, CouchDB, Voldemort): todos siguen respondiendo, aunque algunas copias queden desactualizadas por un rato; luego se reconcilian.
• CA (las relacionales en un solo servidor): consistentes y disponibles, porque no hay red que se corte entre nodos.

Antes de leer la respuesta