La irracional eficacia de SQL

Hace dos veintenas y cinco años, dos jóvenes investigadores de IBM dieron a luz en las bases de datos un nuevo lenguaje, concebido en relacional, dedicado a la proposición de que los datos pueden manipularse de forma declarativa y sencilla. En los años transcurridos desde que Don Chamberlin y Ramond Boyce publicaron SEQUEL: Un lenguaje de consulta estructurado en inglés El modelo relacional y SQL se han ampliado y adaptado a un importante número de tecnologías: OLTP, OLAP, bases de datos de objetos, bases de datos relacionales de objetos e incluso NoSQL. SQL ha inspirado el diseño de lenguajes de consulta para bases de datos no relacionales: SQL para bases de datos de objetos, SQL para relacionales de objetos, SQL para XML, SQL para espaciales, SQL para búsquedas, SQL para JSON, SQL para series temporales, SQL para flujos, etc. Todas las herramientas de BI interactúan con los datos utilizando una variedad de SQL. De hecho, SQL es la éxito del lenguaje de 4ª generación.

"SQL es un dispositivo cuyo misterio sólo es superado por su poder".  Lukas Eder

Como Don dijo recientemente, SQL se basó en los cimientos de álgebra relacional con el objetivo de hacerlo más fácil proporcionando un lenguaje de consulta similar al inglés con los siguientes objetivos:

• Un lenguaje y un procesamiento declarativos (en lugar de procedimentales)
• Hacer el lenguaje componible para facilitar la escritura de consultas complejas
• Trabajar con el modelo relacional desarrollado por Edger F Codd.

Mientras el big data intentaba complementar y sustituir a los sistemas relacionales para el almacenamiento de datos, intentaban hablar el mismo idioma: SQL. Hive, Impala, drill, BigSQL hablan todos un lenguaje inspirado en SQL, optimizan y ejecutan de forma similar a la ejecución MPP de SQL. También están añadiendo nuevas características de SQL con regularidad. Todo esto en cualquier tipo de almacén de datos y modelo que se te ocurra. La separación de los formatos de almacenamiento de datos, el modelo de datos y el procesamiento de consultas en SQL ha reportado importantes beneficios. En los cuarenta y cinco años transcurridos desde que se introdujo SQL, muchas bases de datos han ido y venido; muchos procesamientos de datos han ido y venido. Algunos miembros del movimiento NoSQL insinuaron, aunque fuera sin querer, la muerte de SQL y de las bases de datos SQL. El campo SQL se lo ha tomado con calma y Don Chamberlin dijo recientemente: "Cuando una lengua es tan reconocida que otras lenguas empiezan a definirse como no esa, debe de irle bastante bien".

Las bases de datos, por su parte, simplemente pasaron a No-SQL. Aunque la definición actual es "No sólo SQL", los planteamientos originales consistían en prescindir de SQL y probar lenguajes y marcos alternativos como map-reduce. Una década después, todas las bases de datos NoSQL populares tienen una variación de SQL: N1QL en Couchbase, CQL en Cassandra, ElasticSearch SQL en Elastic. Tú dices: "MongoDB no tiene SQL". Yo digo: "Entrecierra los ojos. Verás una implementación de SQL muy simplista". Al utilizar un diseño simplista, algo procedimental y ad-hoc en MongoDB, las consultas pierden composibilidad, optimizaciones y muchas de las innovaciones realizadas con SQL.

Aunque el modelo relacional ha tenido mucho éxito, las bases de datos admiten diversos modelos de datos: JSON, Graph, XML, Timeseries, espaciales, de columnas anchas, de columnas, de documentos, etc. La mayoría de estas bases de datos, si no todas, tienen su versión de SQL. N1QL es SQL para JSON; SQL/XML, SQL de InfluxDB, SQL/Spatial, CQL en Cassandra, etc. Incluso las bases de datos NoSQL han implementado SQL y lenguajes de consulta inspirados en SQL. Incluso en el nuevo mundo cool de la "ciencia de datos", Conocimientos de SQL muy recomendables. Lukas Eder expone este punto en sus charlas imprescindibles. Consulte los enlaces a sus charlas en la sección de referencias.

Ahora, hay más proyectos SQL en bases de datos NOSQL que en bases de datos SQL.

¿POR QUÉ SQL TIENE TANTO ÉXITO?

1. Declarativo: Usted declara la salida y los motores de consulta calculan la forma óptima de ejecutar la consulta. El optimizador, especialmente el optimizador basado en costes inventado Pat Selinger, et al en 1979, ha contribuido a mejorar continuamente el rendimiento. Con ello se puso el listón muy alto para todos los nuevos participantes. A documento reciente sobre Apache Hive es un ejemplo de la complejidad y sofisticación que entraña.
2. SQL se utilizaba no sólo para "consultar", sino también para actualizar los datos y realizar transacciones. Los procedimientos almacenados y las UDF han ampliado su alcance combinando el lenguaje procedimental con el SQL declarativo.
3. SQL ha sido maleable. Se ha estandarizado muchas veces, cada vez añadiendo un libro lleno de características, un almacén lleno de sintaxis y un diccionario lleno de palabras clave. Por supuesto, no todo el SQL es igual. Incluso las implementaciones tradicionales de SQL en RDBMS no son exactamente compatibles, a menos que tengas cuidado de escribir tu SQL para que sea compatible. A pesar de todo, el espíritu original de SQL se ha mantenido. Un ejemplo de SQL que se presta a la evolución es SQL. Don Chamberlin y Prof. Mike Carey debatir la necesidad de apoyar modelos de datos complejos, haciendo que los datos en JSON sean fácilmente accesibles para usuarios y desarrolladores. El libro de Don SQL++ Para Usuarios de SQL: Un tutorial te enseña los últimos avances en SQL++, lenguaje diseñado para el procesamiento de datos sobre el flexible modelo de datos JSON, pero de forma compatible con SQL.
4. SQL, al igual que la lengua inglesa de la que tomó prestado el lenguaje, ha estado abierto a nuevas ideas y extensiones para nuevos tipos de datos, métodos de acceso y casos de uso.
5. La independencia de SQL respecto a la representación de los datos ha permitido su uso en datos no relacionales: CSV, JSON y todos los formatos de big data. Algunas personas confunden la rigidez de la representación del modelo relacional con la rigidez de SQL. De hecho, en un esquema dado, SQL permite seleccionar-unir-agrupar-agrupar-proyectar cualquiera de los formatos de datos.

Evaluación del soporte SQL:

Ahora que SQL está en todas partes, hay que comprobar el nivel de asistencia.

1. Descubra la características de la carga de trabajo y objetivo de cada carga de trabajo. Por ejemplo, aplicaciones interactivas o análisis interactivos o análisis por lotes o carga de trabajo de BI, etc.
2. Las declaraciones respaldadas reflejan las capacidades operativas.
3. Capacidades del lenguaje en términos de expresiones (escalares, agregadas, booleanas), uniones (internas, izquierda/derecha/externa completa), subconsultas, tablas derivadas, ordenación y paginación (LIMIT/OFFSET).
4. Indexación: SQL sin los índices adecuados no es más que un prototipo de máquina de Turing.
5. Optimizador: La reescritura de consultas, la elección de la ruta de acceso correcta y la creación de la ruta de ejecución de consultas óptima es lo que convierte a SQL en un 4GL de éxito. Algunos tienen un optimizador basado en reglas, otros tienen un optimizador basado en costes, otros tienen ambos. Evaluar la calidad del optimizador es fundamental. Las típicas pruebas comparativas (TPC-C, TPC-DS, YCSB, YCSB-JSON) no le ayudarán en este caso.
6. Como dice el refrán: "Hay tres cosas importantes en las bases de datos: rendimiento, rendimiento y rendimiento". Es importante medir el rendimiento de tu carga de trabajo.  YCSB y la ampliada YCSB-JSON facilitará esta evaluación.
7. SDK: Los completos SDK y la compatibilidad de idiomas aceleran el desarrollo.
8.  Soporte de herramientas de BI: Para el análisis de grandes volúmenes de datos, es importante la compatibilidad de las herramientas de BI, normalmente a través de controladores estándar de conectividad a bases de datos.

Gerald Sangudi, creador de N1QL, comentó en una ocasión que SQL tiene éxito porque representa las operaciones fundamentales del procesamiento de datos. SQL soporta un rico conjunto de operaciones select-join-nest-unnest-group-aggregate-having-window-order-paginate-set-ops. ¿Es así como pensamos nosotros (o las máquinas) cuando especificamos operaciones de datos? Aunque eso está por ver, otros lenguajes como python y java están añadiendo operadores para estas operaciones con datos. Quizá otros sigan su ejemplo. SQL ha llegado donde el modelo relacional no llegó. No es exagerado decirlo:

SQL ha muerto. Larga vida a SQL.

Referencias:

1. SQL++ Para Usuarios de SQL: Un tutorial
   • https://www.amazon.com/SQL-Users-Tutorial-Don-Chamberlin/dp/0692184503/
2. Lukas Eder - ¿2000 líneas de Java? ¿O 50 líneas de SQL? ¡Tú eliges!
   • https://www.youtube.com/watch?v=S3JbAEd5u_c
3. Diez trucos SQL que no creías posibles
   • https://www.youtube.com/watch?v=mgipNdAgQ3o
4. Cómo las bases de datos SQL modernas idean algoritmos que nunca habrías soñado por Lukas Eder
   • https://www.youtube.com/watch?v=wTPGW1PNy_Y
5. Historia de SQL
   • https://youtu.be/LAlDe1w7wxc
6. Eugene Wigner: La irrazonable eficacia de las matemáticas en las ciencias naturales 
   • https://www.maths.ed.ac.uk/~v1ranick/papers/wigner.pdf
7. Alon Halevy, Peter Norvig y Fernando Pereira: La irrazonable eficacia de los datos
   • https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/35179.pdf
8. Diferencia entre 3GL y 4GL
   • https://www.reference.com/technology/difference-between-3gls-4gls-8826a78c1e34c2e