por Andrew C. Oliver
¿Y si el principal problema con las bases de datos relacionales fuera el back-end y no el front-end?
Al principio, había archivos. Posteriormente existieron bases de datos de navegación basadas en archivos estructurados. Luego estaban IMS y CODASYL , y hace unos 40 años teníamos algunas de las primeras bases de datos relacionales. Durante gran parte de las décadas de 1980 y 1990, “base de datos” significaba estrictamente “base de datos relacional”. SQL gobernado.
Luego, con la creciente popularidad de los lenguajes de programación orientados a objetos, algunos pensaron que la solución al “desajuste de impedancia” de los lenguajes orientados a objetos y las bases de datos relacionales era mapear objetos en la base de datos. Por lo tanto, terminamos con “bases de datos orientadas a objetos”. Lo curioso de las bases de datos de objetos es que en muchos casos eran básicamente una base de datos normal con un mapeador de objetos incorporado. Estos disminuyeron en popularidad y el siguiente intento real de mercado masivo fue “ NoSQL ” en la década de 2010.
El ataque a SQL
NoSQL atacó tanto las bases de datos relacionales como SQL de la misma manera. El principal problema esta vez fue que Internet había destruido la premisa subyacente de la arquitectura del sistema de administración de bases de datos relacionales (RDBMS) de 40 años. Estas bases de datos fueron diseñadas para conservar un valioso espacio en disco y escalar verticalmente. Ahora había demasiados usuarios y demasiados para que los manejara un servidor gordo. Las bases de datos NoSQL dicen que si tiene una base de datos sin uniones, sin un lenguaje de consulta estándar (porque implementar SQL lleva tiempo) y sin integridad de datos, entonces puede escalar horizontalmente y manejar ese volumen. Esto resolvió el problema de la escala vertical pero introdujo nuevos problemas.
Desarrollado en paralelo con estos sistemas de procesamiento de transacciones en línea (OLTP), existía otro tipo de base de datos principalmente relacional llamada sistema de procesamiento analítico en línea (OLAP). Estas bases de datos apoyaron la estructura relacional pero ejecutaron consultas con el entendimiento de que devolverían cantidades masivas de datos. Las empresas de los años 80 y 90 todavía estaban impulsadas en gran medida por el procesamiento por lotes. Además, los sistemas OLAP desarrollaron la capacidad para que los desarrolladores y analistas imaginen y almacenen datos como cubos de n dimensiones. Si imagina una matriz bidimensional y búsquedas basadas en dos índices para que sea básicamente tan eficiente como el tiempo constante, pero luego tome eso y agregue otra dimensión u otra para que pueda hacer lo que son esencialmente búsquedas de tres o más factores (digamos oferta, demanda, y el número de competidores): podría analizar y pronosticar cosas de manera más eficiente. Sin embargo, construirlos es laborioso y un esfuerzo muy orientado por lotes.
Casi al mismo tiempo que NoSQL escalable, surgieron las bases de datos de gráficos. Muchas cosas no son “relacionales” per se, o no se basan en la teoría de conjuntos y el álgebra relacional, sino en las relaciones entre padres e hijos o amigos de un amigo. Un ejemplo clásico es la línea de productos a la marca de producto, al modelo a los componentes del modelo. Si desea saber “qué placa base hay en mi computadora portátil”, descubrirá que los fabricantes tienen un abastecimiento complicado y que la marca o el número de modelo pueden no ser suficientes. Si desea saber qué placas base se utilizan en una línea de productos, en SQL clásico (no CTE o Common Table Expression), debe recorrer las tablas y emitir consultas en varios pasos. Inicialmente, la mayoría de las bases de datos de gráficos no se fragmentaron en absoluto. En realidad, se pueden realizar muchos tipos de análisis de gráficos sin almacenar los datos como un gráfico.
Promesas NoSQL cumplidas y promesas incumplidas
Las bases de datos NoSQL escalaron mucho, mucho mejor que Oracle Database, DB2 o SQL Server, que se basan en un diseño de 40 años. Sin embargo, cada tipo de base de datos NoSQL tenía nuevas restricciones:
- Almacenes de clave-valor: no hay búsqueda más simple que db.get (clave). Sin embargo, gran parte de los casos de uso y datos del mundo no se pueden estructurar de esta manera. Además, realmente estamos hablando de una estrategia de almacenamiento en caché. Las búsquedas de claves primarias son rápidas en cualquier base de datos; lo que importa es simplemente lo que está en la memoria. En el mejor de los casos, se escalan como un mapa hash. Sin embargo, si tiene que hacer 30 viajes a la base de datos para volver a juntar sus datos o hacer cualquier tipo de consulta complicada, esto no va a funcionar. Estos ahora se implementan con mayor frecuencia como cachés frente a otras bases de datos. (Ejemplo: Redis .)
- Bases de datos de documentos: estas alcanzaron su popularidad porque usan JSON y los objetos son fáciles de serializar en JSON. Las primeras versiones de estas bases de datos no tenían combinaciones, y tener toda su “entidad” en un documento gigante tenía sus propios inconvenientes. Sin garantías transaccionales, también tuvo problemas de integridad de datos. Hoy en día, algunas bases de datos de documentos admiten una forma de transacción menos sólida, pero no es el mismo nivel de garantía al que la mayoría de la gente está acostumbrada. Además, incluso para consultas simples, estas suelen ser lentas en términos de latencia, incluso si escalan mejor en términos de todo. (Ejemplos: MongoDB , Amazon DocumentDB).
- Almacenes de columnas: son tan rápidos como los almacenes de valores-clave para búsquedas y pueden almacenar estructuras de datos más complicadas. Sin embargo, hacer algo que parezca una combinación en tres tablas (en la jerga RDBMS) o tres colecciones (en la jerga MongoDB) es, en el mejor de los casos, doloroso. Estos son realmente geniales para los datos de series de tiempo (dígame todo lo que sucedió entre la 1:00 p.m. y las 2:00 p.m.).
Y hay otras bases de datos NoSQL más esotéricas. Sin embargo, lo que todas estas bases de datos han tenido en común es la falta de soporte para modismos comunes de bases de datos y una tendencia a centrarse en un “propósito especial”. Algunas bases de datos NoSQL populares (por ejemplo, MongoDB) escribieron excelentes interfaces de base de datos y herramientas de ecosistema que hicieron que fuera realmente fácil de adoptar para los desarrolladores, pero diseñaron serias limitaciones en su motor de almacenamiento, por no mencionar las limitaciones de resiliencia y escalabilidad.
Fuente: https://www.infoworld.com/article/3564543/beyond-nosql-the-case-for-distributed-sql.html
