tutorial relacionales relacional que gestor ejemplos diseño datos bases aws nosql relational-database schemaless

nosql - relacionales - Uso de una base de datos relacional para datos sin esquema: mejores prácticas



nosql tutorial (5)

Después de leer un impactante artículo escrito por Bret Taylor (co-creador de FriendFeed, actual CTO de Facebook), How FriendFeed usa MySQL para almacenar datos sin esquema , comencé a preguntarme si hay mejores prácticas para usar un RDBMS como Oracle, MySQL o PostgreSQL para almacenar y consultar datos sin esquema.

A pocas personas les gusta admitir que están usando una base de datos relacional cuando NoSQL es el nuevo hotness, lo que hace que sea difícil encontrar buenos artículos sobre el tema. ¿Cómo implemento una base de datos sin esquema (o "documentada") como una capa sobre una base de datos relacional?


El almacenamiento de datos sin esquema en SQL básicamente significa implementar un almacén de clave-valor que usa SQL como back-end. Como no está utilizando ninguna función relacional y el esquema es bastante trivial, no encontrará mucha información sobre el diseño de bases de datos SQL de esta manera. Sin embargo, debería poder encontrar mucha información más general sobre el diseño de aplicaciones para el almacenamiento de clave-valor que se aplicará.



No encontrará mucho sobre este tema porque la mayoría de la gente crea soluciones de un solo propósito. Sus soluciones están diseñadas para satisfacer una necesidad muy bien. Las bases de datos NoSQL le cuestan mucho construir estos almacenes de datos de un solo propósito pero usted paga por no tener la flexibilidad y algunos de los controles incorporados y las características de seguridad de un RDBMS.


He investigado este tema extensamente. Es bastante trivial modelar datos sin esquema en un RDBMS usando una tabla de "propiedades" (esencialmente usando pares clave / valor). La parte difícil es indexar y consultar contra tus cosas. (Esencialmente toda la complejidad que lidió Friendfeed se centró en este tema).

Si indexas la tabla de propiedades, terminas con un índice contra todas las propiedades. Esto es indeseable ya que agrega demasiada sobrecarga, ya que solo querrá consultar contra ciertas propiedades. Además, seguramente querrás acceder a tus cosas a través de índices compuestos. Es increíblemente complejo modelar índices compuestos. Las únicas soluciones que he encontrado requieren que construyas tus propios índices usando el esquema solo para ese propósito, muy engorroso. Cuanto más lo miraba, menos práctico parecía.

Una buena solución a este problema se basa en el uso de índices parciales (también conocidos como índices filtrados).


Los ingenieros de Quora utilizan MySQL como el almacén de datos en lugar de NoSQL, como Cassandra, MongoDB, CouchDB, etc. Particionan los datos en el nivel de aplicación , lo que significa que los datos de partición solo si es necesario, mantienen los datos en una máquina si es posible y utilizan un hash de la clave primaria para particionar conjuntos de datos más grandes en múltiples bases de datos. El reparto de datos a nivel de aplicación funciona de tal manera que los datos que cumplen un conjunto de criterios se transfieren a una base de datos, mientras que los datos que no cumplen esos criterios (o tal vez un conjunto diferente de criterios) pueden enviarse a una base de datos diferente