About this resource...

308

0

Publicado el 11 . 8 . 2010 por Equipo GNOSS

Con un título tan rompedor como su contenido, este "paper" de 2007 adivina o inventa el futuro de los sistemas de almacenamiento de datos en la era de Internet. El documento puede ser objeto de críticas, algunas justificadas, pero no cabe duda de la inspiración o el acierto al describir muchas de las soluciones NoSQL actualmente en uso en muchas aplicaciones Web.

El documento comienza con una breve descripción de las consideraciones de diseño de los tradicionales sistemas de gestión de base de datos, antes de expresar los requisitos del nuevo sistema OLTP (On Line Transaction Process), HStore:

  1. La base de datos OLTP debería caber enteramente en memoria. No deberia haber escrituras en disco en absoluto.
  2. La base de datos OLTP debería tener un único hilo (thread) - sin concurrencia en absoluto. Esto debería ser posible cuando las transacciones OLTP duran menos del milisegundo, lo que en un sistema de "solo-memoria" debería ser incluso inferior. Esto elimina la necesidad de algoritmos y estructuras de datos complejas, y mejora aún más el rendimiento. No se permiten las consultas no predefinidas.
  3. Debería ser posible añadir capacidad a un sistema OLTP sin caída alguna de servicio. Esto implica una expansión incremental, escalando el sistema añadiendo nodos transparentemente.
  4. El sistema debería ser altamente disponible, con una configuración "peer-to-peer". La carga OLTP debería estar distribuida en varias máquinas, y la replicación entre máquinas usada para disponibilidad. En un sistema de este tipo "rehacer" y "deshacer" el log de la transacción es innecesario. (se cita otro "paper" según el cual rehacer un nodo que ha fallado en la red es tan eficiente como recuperarse de un "rehacer" un log). Obviamente, la eliminación de "rehacer" suprime uno de los peores cuellos de botella de los sistemas OLTP, cuando los datos se escriben en disco síncronamente.
  5. Sin Administradores de Bases de Datos (DBAs). Los sistemas deberían ser totalmente "autoconfigurables" y "autooptimizables".

Además, se describen otras propiedades de HStore:

  1. Sin el "rehacer" de los logs, y por tanto, sin los bloqueos, el siguiente cuello de botella son los interfaces (JDBC, ODBC, OleDB, etc). El código de la aplicación debería estar en procedimientos almacenados dentro del almacenamiento de datos. El único comando que se ejecutara externamente debería ser “execute transaction X”.
  2. Dado que la base de datos estaría distribuido y replicado, y que la latencia de la red toma milisegundos, se debería evitar las 2 fases de un protocolo de "commit".
  3. No hay consultas "ad-hoc". Toda la carga de trabajo se debería especificar con antelación.
  4. SQL es un lenguaje antiguo, con serios problemas ya expuestos por Chris Date hace 2 décadas. HStore debería ser programable en un lenguaje moderno y ligero como Ruby.

Los autores del documento son: 

  • Michael Stonebraker, Samuel Madden, Daniel J. Abadi, Stavros Harizopoulos del MIT CSAIL (Computer Science and Artificial Intelligence Laboratory).
  • Nabil Hachem, de AvantGarde Consulting, LLC.
  • Pat Helland, de Microsoft Corporation.

0 Comentarios

Do you want to comment? Sign up or Sign in