Uso de una base de datos relacional para datos Schemaless: mejores prácticas

Question

Después de leer un impactante artículo escrito por Bret Taylor (cocreador de FriendFeed, actual CTO de Facebook), How FriendFeed uses MySQL to store schema-less data, comencé a preguntarme si existen 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 utilizando 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?

Answer 1

eso es el artículo clásico en este tema: http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html (Uso de MySQL como NoSQL - Una historia por exceder 750.000 QPS en un servidor de productos básicos)

Answer 2

Almacenamiento sin esquema de datos en SQL básicamente significa la implementación de un almacén de claves-valor que sucede usar 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á.

Answer 3

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.

Answer 4

He investigado este problema 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 problema.)

Si indexa la tabla de propiedades, termina 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).

Answer 5

Los ingenieros de Quora usan MySQL as the data store instead of NoSQLs such as Cassandra, MongoDB, CouchDB etc. Son partition data at the application level, lo que significa que los datos de partición solo si es necesario, mantener los datos en una máquina si es posible y utilizar un hash de la clave principal 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 dichos criterios (o tal vez un conjunto diferente de criterios) pueden enviarse a una base de datos diferente