Get best of the week

Por qué las bases de datos NoSQL son una mala solución para aplicaciones modernas

Hola Habr

Hoy traemos a su atención una traducción de un artículo del blog MemSQL, que originalmente es un anuncio (dedicado a las ventajas de MemSQL , actualizado a principios de enero de 2020). Sin embargo, decidimos traducirlo de forma abreviada, ya que explica en detalle por qué aún no hemos decidido publicar nada en MongoDB, Cassandra u otras bases de datos no relacionales. Quizás teníamos razón, limitándonos al exitoso libro " MySQL al máximo ".

Ha llegado el momento de reconocer la verdad bien conocida: las bases de datos NoSQL no son adecuadas para resolver muchos problemas prácticos que enfrentan las aplicaciones modernas, y el tiempo para estas bases de datos ha pasado.

Las bases de datos NoSQL aparecieron porque las bases de datos tradicionales que existían en el momento de su invención no podían hacer frente a la escala de tareas requerida. Esta nueva generación de servicios para trabajar con datos que aparecieron en circulación hace más de diez años, permitió resolver muchos problemas relevantes en toda la Web, así como operar con conjuntos de datos en rápido crecimiento. NoSQL también ofreció un nuevo método rentable de almacenamiento en frío / acceso por lotes episódico a volúmenes de datos de petabytes. Sin embargo, en los intentos apresurados de responder a los desafíos de los grandes datos y apoyar a un gran número de usuarios competidores, el paradigma NoSQL requirió abandonar algunas de las propiedades clave de las bases de datos tradicionales, lo que las hizo tan productivas y fáciles de usar.

Quizás encontrar todas estas compensaciones con éxito es la mayor contribución de NoSQL al mundo de las bases de datos. Provocaron la evolución al combinar las mejores características del manejo de big data con la estructura y flexibilidad de un modelo relacional probado y crear bases de datos relacionales escalables.

Las bases de datos relacionales han evolucionado, dando lugar a una generación completamente nueva de sistemas que pueden hacer frente a prácticamente cualquier carga y satisfacer los requisitos de escalabilidad, confiabilidad y disponibilidad que se aplican a las aplicaciones modernas. Estamos hablando de diferentes cargas de trabajo, desde aplicaciones tradicionales, por ejemplo, aplicaciones transaccionales y análisis de negocios, hasta otras más innovadoras, como compartir software entre diferentes suscriptores (multi-tenance) y análisis operativos. El surgimiento de nuevas bases de datos, en particular Google Spanner, Azure Data Warehouse y MemSQL, ha demostrado que en la mayoría de los casos las bases de datos relacionales son más fáciles de usar y, por regla general, muestran un mejor rendimiento que los sistemas NoSQL.

Sé que estos son temas controvertidos, y puede rechazar fácilmente mi punto de vista como parcial. Sin embargo, permítame clasificar el componente de historia, arquitectura y aplicación de estas bases de datos, y luego juzgar por usted mismo.

NoSQL Sunrise


NoSQL se hizo propio a fines de la década de 2000, aunque su historia comenzó mucho antes. Su desarrollo se llevó a cabo principalmente para resolver los problemas de escala inherentes a los sistemas de bases de datos existentes. Era obvio que la escala horizontal era un modelo más económico al crear sistemas grandes. Los sistemas más grandes, como los motores de búsqueda y los servicios de correo electrónico de Google, Facebook, Microsoft y Yahoo, solo podían escalar de esta manera.

Personalmente, aprecié por primera vez el valor total de la escala horizontal cuando leí el artículoJames Hamilton sobre el diseño y despliegue de servicios en Internet. Al principio, logré escalar el nivel de aplicaciones, ya que un sistema sin estado es más fácil de escalar. El nivel de almacenamiento de datos es otra historia. Las bases de datos, por definición, funcionan con la preservación del estado, y es realmente difícil dar garantías (es decir, ACID ) sobre este estado en la escala de un sistema distribuido completo. Por lo tanto, se crearon nuevos niveles sobre los sistemas de bases de datos existentes (MySQL, SQL Server, etc.) para crear un nivel de almacenamiento de datos distribuidos.

Tuve que lidiar con algunas situaciones de este tipo cuando trabajé como gerente de producto en el equipo de SQL Server en Microsoft. El primer caso estaba relacionado con un producto interno de Microsoft; luego, la compañía creó Webstore, una capa de fragmentación construida en SQL Server y utilizada por Hotmail y sus servicios relacionados. De hecho, fue la tienda web la que sirvió de incentivo para crear el producto que sirvió como prototipo de la base de datos Azure SQL actual. La tienda web era un tanto torpe, carecía de una parte importante de la funcionalidad clave, pero funcionó y proporcionó a Microsoft tanto escalamiento a la cantidad deseada de datos como alta disponibilidad. Pero para crear y seguir apoyando a la tienda web, se requería un equipo completo de ingenieros.

A mediados de la década de 2000, MySpace utilizó una gran cantidad de servidores SQL para administrar un sitio de rápido crecimiento. La audiencia de usuarios de la compañía creció tan rápido que se necesita instalar diariamente nuevas instancias de servidores SQL. La explotación de todos estos servidores SQL y la ejecución de consultas en todos ellos resultó ser una cuestión de enorme complejidad que un ejército completo de ingenieros también se involucró en ellos.
Se repitieron historias similares en Facebook y otras compañías, ya que todos los gigantes de la tecnología en rápido crecimiento se encontraron con el problema de la escala.

Se hizo evidente que a tales tasas de crecimiento y explotación, estos nuevos servicios digitales requieren una nueva solución para la absorción de datos, la gestión y su salida a la superficie. Idealmente, se requería una solución que pudiera proporcionar de forma nativa una interfaz única, pero escalar horizontalmente en muchas máquinas y al mismo tiempo tener herramientas integradas para garantizar una alta disponibilidad.

Como resultado, los servicios en la nube a gran escala (Google, Facebook, Yahoo, Microsoft y otros) construyeron sus propios sistemas especiales para satisfacer la necesidad de escalar. Estos sistemas eran diferentes, pero se establecieron ideas comunes en ellos. En la siguiente etapa, los sistemas de código abierto que usaban las mismas ideas comenzaron a multiplicarse, por lo que surgió el movimiento NoSQL.

Para resolver problemas a escala web, NoSQL se separó de las bases de datos tradicionales en varios indicadores clave. Entonces, veamos por qué estas decisiones específicas se tomaron aquí.

Rendimiento y fallas conformacionales en última instancia


Hay dos enfoques arquitectónicos, ACID y BASE .

ACID significa "Atómico, Consistente, Aislamiento, Duradero" (Atómico, Consistente, Aislamiento, Durabilidad). Este paradigma cubre todas las garantías que generalmente se brindan en bases de datos relacionales. ACID asegura que las operaciones de escritura tendrán que esperar hasta que los datos lleguen al disco, y solo después de eso, se informará al cliente que la operación se completó con éxito. Además, si realmente le preocupa la longevidad de los datos (es decir, intenta no perderlos), entonces configura la base de datos para que la operación de escritura pueda seguir a través de la red a otra máquina, y los datos también se escribirán en el disco y allí . Por lo tanto, obtiene garantías de que exactamente lo que anotó siempre entra en los datos, sin embargo, en parte, sacrifica la velocidad de escritura.

La arquitectura BASE típica de los sistemas NoSQL significa "Básicamente disponible, estado suave, eventualmente coherente" ("disponibilidad básica, estado inestable y, en última instancia, coherencia"). La consistencia en última instancia proporciona una velocidad de grabación más rápida porque la aplicación no tiene que esperar la confirmación de que la grabación se ha guardado. Tan pronto como el almacén de datos haya aceptado la grabación, pero incluso antes de que los datos se hayan almacenado permanentemente en su disco o en el disco de otra máquina, la base de datos puede informar a la aplicación que la operación de escritura fue exitosa, y la aplicación puede continuar con la siguiente operación. Por lo tanto, gana en rendimiento, sin embargo, corre el riesgo de no ver los datos que acaba de grabar, o los datos pueden perderse por completo debido a algún tipo de error.

La consistencia es, en última instancia, un compromiso razonable que se puede alcanzar mientras se lucha por la longevidad y la disponibilidad de datos. Si su negocio involucra la participación del consumidor, cualquier demora afecta directamente sus ganancias (y esto se aplica igualmente a cualquier contenido, comunidad y aplicación comercial). Naturalmente, logra la mayor capacidad de respuesta posible de la interfaz de usuario. Si su tarea es escalar para servir a millones de usuarios que compiten con el sistema, entonces cualquier obstáculo es inaceptable para usted. Cuando implementa la coherencia en la arquitectura de su base de datos, corre el riesgo de perder accidentalmente la publicación o comentario de alguien, y este tipo de riesgo es aceptable en este tipo de aplicación.

En el otro extremo del espectro de oportunidades "longevidad versus riesgo" se encuentran las aplicaciones financieras. Si realiza una transacción a través de un cajero automático, entonces, por supuesto, la consistencia finalmente no será adecuada para usted. Lo mismo se aplica al comercio en el intercambio. En tales casos, todavía habrá usuarios que aceptarán solo retrasos mínimos (o no estarán de acuerdo en absoluto), pero no están listos para soportar el hecho de que la transacción no se escribirá en el disco.

Entonces, tenemos dónde aplicar la consistencia a largo plazo, pero, por supuesto, no es la única solución. Los arquitectos y los desarrolladores de sistemas de datos deben poder elegir qué nivel de consistencia necesitan. Esta elección debería depender de los detalles de uso y no de las capacidades de la plataforma.

Tratando de sobrevivir sin un esquema


No está del todo claro por qué en el movimiento NoSQL se decidió abandonar los esquemas. Sí, en los albores de NoSQL, era difícil construir un administrador para administrar metadatos distribuidos, lo que proporcionaría soporte para esquemas en todo el sistema distribuido y operaciones de soporte como agregar una columna. Por lo tanto, no es sorprendente que los esquemas desaparecieran en los primeros proyectos de tales bases de datos. Pero, en lugar de encontrar una manera de volver a agregar los esquemas posteriormente, se decidió abandonarlos por completo. El punto de vista de esos tipos que indican que si hay un esquema, la base de datos se vuelve menos flexible. Es difícil diseñar un buen esquema, para esto es necesario pensar cuidadosamente y de antemano todo. Cuando la situación está cambiando rápidamente (como era entonces y ahora es así), quién quiere encerrarse en el esquema.

Pero esto es una falacia.

De hecho, la falta de circuitos beneficia al ingeniero, cuya tarea es escribir datos en el sistema. Sin embargo, en este caso, los problemas se envían a la parte de quienes leen los datos, y generalmente son un orden de magnitud mayor que los ingenieros, y a menudo no tienen información sobre el contexto en el que se encontraban los datos al momento de la grabación. Son los usuarios quienes usualmente obtienen valor de los datos, y necesitan dejar la menor cantidad posible de obstáculos para trabajar con la información.

Daré una analogía. Imagine que los bibliotecarios afirman que están cansados ​​de trabajar con los catálogos decimales de Dewey, y ahora simplemente dejarán caer los libros en un gran agujero en el piso, porque el trabajo del bibliotecario se simplifica enormemente. A veces sucede que es apropiado usar datos parcialmente estructurados, porque a veces no imaginas la forma de algunos datos, o los datos en sí mismos son demasiado escasos. Pero si realmente no comprende de dónde vendrán estos o esos datos, o cómo debería verse, ¿de qué sirve?

La verdad es que siempre hay un circuito. Los datos siempre tienen algún significado para alguien. Pero alguien debería pasar tiempo e integrar su conocimiento de este significado en la plataforma para que otras personas puedan usar los datos después de ello. Si estamos tratando con datos, algunos de los cuales son comprensibles para nosotros, y la otra parte está cambiando rápidamente, entonces la segunda parte cae en una columna con información parcialmente estructurada, y luego decidimos qué columnas formaremos posteriormente a partir de esta información parcialmente estructurada. SQL Server y Oracle lograron hacer esto en XML hace 15 años. En MemSQL y algunas otras bases de datos modernas de hoy, lo mismo se hace con datos JSON. El almacenamiento de datos de documentos (y el trabajo con pares clave-valor) deberían ser características de las bases de datos modernas, pero no la única posibilidad de este o aquel producto.

La sintaxis de consulta no es como en SQL


Esta decisión en el diseño de bases de datos NoSQL siguió al abandono del esquema. Si no hay un esquema, entonces parece apropiado abandonar la sintaxis SQL. Además, el procesador de consultas es difícil de escribir para una sola computadora, pero para un sistema distribuido es mucho más complicado. Lo más notable es que si usted es un desarrollador que necesita lanzar rápidamente una nueva aplicación, ese nuevo sistema parece más fácil.

MongoDB ha perfeccionado el arte de una fácil instalación y uso sin experiencia. Sin embargo, resulta que el modelo relacional es muy poderoso. Es bueno llevarse bien con las funciones get y put si nunca ha tenido que resolver problemas más difíciles que "seleccionar un objeto con id 2". Pero la mayoría de las aplicaciones existentes necesitan hacer mucho más. Si desea leer un excelente artículo del autor que llegó a esta conclusión (y al mismo tiempo no funciona en un producto para almacenar datos), resuelva dos proyectos separados usando MongoDB: lea este . Un gran ejemplo que muestra cuándo las capacidades de la base de datos de documentos son limitadas.

En cualquier sistema, excepto el más trivial, tarde o temprano deberá solicitar datos con un principio diferente al que los guardó. Irónicamente, el modelo relacional se inventó en la década de 1960 para resolver exactamente el mismo problema con los almacenes de datos que existían en ese momento (IMS y Codasyl). El modelo relacional que proporcionaba la capacidad de unirse parecía la única forma sensata de extraer datos. Sí, al principio es bastante difícil, pero mucho más fácil que extraer todos los datos en su aplicación y luego crear las asociaciones usted mismo. Vi a los clientes tratar de hacer esto una y otra vez usando bases de datos NoSQL, y esto siempre los llevó a algún tipo de tontería.

Muchos de estos sistemas NoSQL han logrado su objetivo principal. Proporcionaron una interfaz única para el almacén de datos, a través de la cual fue posible escalar a muchos sistemas, confiando en la alta disponibilidad incorporada. Sin embargo, aunque NoSQL siempre ha progresado, su implementación se ha detenido constantemente.

Hay varias razones diferentes. La razón clave es el rendimiento, en particular cuando se trata de realizar consultas analíticas de conformidad con un acuerdo de calidad de servicio. Otra razón es la capacidad de administración, porque se sabe lo difícil que es administrar sistemas distribuidos. Sin embargo, nada ha impedido la adopción generalizada de NoSQL que la necesidad de volver a capacitar a las personas. Muchos especialistas estudiaron y formaron profesionalmente en el mundo de las bases de datos relacionales. NoSQL ha estado tratando de cambiar el mundo durante más de una década, pero no ha logrado casi nada. Todas las empresas que trabajan con NoSQL, combinadas, ocupan solo un pequeño porcentaje del mercado de bases de datos, cuyo volumen es de $ 50 mil millones.

Si bien a los programadores de NoSQL les gustó claramente, los especialistas en datos (DBA, arquitectos de datos, analistas) se mudaron de mala gana al mundo de NoSQL, porque parecía que solo este paradigma podría resolver problemas reales con el escalado. Sin embargo, esto significaba que tendrían que volver a aprender a nuevas API, herramientas, desarrollar un nuevo ecosistema, descartando muchos años dedicados a estudiar enfoques, patrones y recursos exitosos. Querían hacer su trabajo de acuerdo con el modelo familiar, pero al mismo tiempo lograr la escalabilidad necesaria, sin abandonar la durabilidad, disponibilidad y confiabilidad del sistema.

Adios NoSQL


Las bases de datos NoSQL surgieron para que los ingenieros pudieran hacer frente a los requisitos de escalabilidad que son relevantes en los tiempos modernos de las aplicaciones web y los servicios diseñados para diferentes suscriptores. Teniendo en cuenta lo difícil que fue resolver tales problemas, está claro que los primeros intentos de hacer frente a la escala en el nivel de almacenamiento de datos obligaron a los clientes a hacer compromisos difíciles.

Sin embargo, las bases de datos relacionales han evolucionado. Hoy pueden hacer frente a casi cualquier carga de trabajo, cumpliendo todos los requisitos de escalabilidad, confiabilidad y disponibilidad que se presentan a las aplicaciones modernas.

Esto implica, por ejemplo, cargas de trabajo tales como análisis operativos. Como todas las empresas reconocen el valor de un enfoque basado en datos, se esfuerzan por proporcionar a sus empleados datos relevantes. Esto requiere una nueva generación de sistemas analíticos que puedan escalar a cientos de consultas competitivas, emitir consultas rápidas sin agregación previa y absorber datos al mismo ritmo que se generan. Además de todo esto, debe proporcionar datos a clientes y socios, y para ello debe seguir ciertos acuerdos sobre el nivel de calidad de servicio (SLA), garantías de seguridad, rendimiento y capacidades de escalabilidad, que son difíciles para la mayoría de los almacenes de datos modernos. Aquí hay un tipo de carga de trabajo que ninguna base de datos heredada heredada puede manejar.No hay sistemas NoSQL.

El modelo relacional ha resistido la prueba del tiempo y continúa creciendo en innovación, como SingleStore de MemSQL. Además, el viejo paradigma ha absorbido muchos tipos de datos nuevos (búsqueda, espacial, semiestructurada, etc.) y modelos coincidentes que permiten que todos estos tipos de datos coexistan en el mismo sistema. No hay obstáculos insuperables para el modelo relacional y la sintaxis de las consultas SQL. Solo necesita una implementación diferente del almacén de datos que le permita aprovechar al máximo la arquitectura escalable verticalmente.

Las nuevas bases de datos, como MemSQL, demuestran que en la mayoría de los casos prácticos, las bases de datos relacionales son más fáciles de usar y, en general, demuestran un mejor rendimiento que los sistemas NoSQL.

Gracias NoSQL Ha presionado la presión necesaria sobre la comunidad de desarrollo de bases de datos, lo que nos ha hecho dar una respuesta digna a los desafíos del mundo de la nube. Funcionó. Las bases de datos relacionales comenzaron a evolucionar y comenzaron a cumplir con los requisitos modernos. Gracias a ti.

More articles:


All Articles