La base de datos JSON autónoma de Oracle agrega compatibilidad con MongoDB

Cuando Oracle lanzó por primera vez el tipo de documento JSON de su base de datos autónoma hace 18 meses, hicimos la pregunta: ¿cuándo agregarán soporte para la API de MongoDB? Esta semana, Oracle ofreció su respuesta.

La próxima versión del servicio en la nube Oracle Autonomous JSON Database agrega soporte para una API compatible con MongoDB 4.2, lo que hace que su oferta resulte muy familiar para los desarrolladores de MongoDB.

La nueva versión, que tiene la marca Oracle Database API para MongoDB, es, en esencia, una base de datos Oracle con ropa de MongoDB. Los desarrolladores pueden usar controladores MongoDB, así como herramientas como Compass (que no están restringidas por la licencia SSPL de MongoDB), y pueden acceder a la mayoría de las funciones de la generación 4.2 de MongoDB. Si bien no es la última generación de la API de MongoDB, MongoDB todavía la admite.

Hay una pequeña excepción: en el momento del lanzamiento, Oracle aún no es compatible con la canalización de agregación, pero debería estar disponible en un futuro cercano. Sostenga ese pensamiento.

A través de todo esto, Oracle continúa admitiendo la API SODA (Acceso simple a documentos de Oracle) que se parece a la API de MongoDB. Pero cuando se dirige a una gran base de desarrolladores fuera de su base, es mejor reunirse con ellos donde viven.

A primera vista, el servicio compatible con MongoDB de Oracle se parece bastante a Amazon DocumentDB y Azure Cosmos DB, entre otros. Dada la licencia pública del lado del servidor (SSPL) de MongoDB, la mayoría de los terceros que ofrecen MongoDB o servicios similares a MongoDB generalmente implementan API compatibles para evitar las restricciones de licencia. Claro, hay excepciones: IBM ofrece un servicio de nube administrado a través de una asociación con MongoDB. Y Percona, que abre todo lo que hace, ofrece su propia implementación de MongoDB con la API oficial, pero no ofrece un servicio DBaaS administrado.

Entonces, sorpresa, sorpresa, Oracle, como Azure y AWS, está yendo por la ruta compatible con API.

Pero existen diferencias reales entre el servicio compatible con MongoDB de Oracle y otros servicios compatibles con MongoDB en la nube; todos están bajo el capó. En primer lugar, es una base de datos Oracle. A diferencia de muchos de sus rivales, la estrategia de Oracle es el soporte políglota de todos los modelos de datos dentro de la nave nodriza; Oracle lo denomina base de datos convergente. JSON es una implementación especializada del mismo motor de base de datos. Por lo tanto, el servicio de base de datos compatible con MongoDB de Oracle tiene la misma administración de usuarios y soporte de transacciones de Oracle Database, y admite un subconjunto de capacidades de la nave nodriza, como aprendizaje automático, espacial y, por supuesto, el venerable lenguaje de consulta SQL.

También significa que si los clientes quieren actualizarse al shebang completo, solo es cuestión de activar capacidades adicionales; no es necesaria la migración de la base de datos.,

En segundo lugar, la oferta compatible con MongoDB es otra edición de Autonomous Database. Este es el servicio de base de datos autónomo solo en la nube que se originó hace cinco años. Sobre la base de las tecnologías de automatización de bases de datos existentes de Oracle, aplica el aprendizaje automático (ML) como la guinda del pastel para que la base de datos tome sus propias decisiones operativas, dejando que el DBA se concentre en asuntos más estratégicos, como el esquema y el desarrollo de aplicaciones. Mientras que otros servicios de bases de datos recién comienzan a aplicar ML para optimizar algunas de sus operaciones, Oracle sigue siendo el único que es totalmente autónomo.

Hay otras diferencias relacionadas con la estrategia de base de datos convergente de Oracle. Como se señaló anteriormente, así es como el servicio de base de datos autónoma de Oracle evita ser una plataforma separada que, de otro modo, habría tenido que reinventar desde cero. Además de relacional, puede administrar datos de documentos XML, espaciales, gráficos y JSON dentro del motor de la base de datos central.

Por supuesto, Oracle no es la única base de datos multimodelo que existe; La compatibilidad con documentos JSON se ha convertido en un elemento de la lista de verificación para muchas plataformas relacionales: IBM, Snowflake, Teradata y otras. Entonces, por ejemplo, hay una similitud con Snowflake, que ha hecho de los datos de documentos un ciudadano de primera clase para su almacén de datos en la nube desde el principio, pero hay un par de diferencias.

En primer lugar, como Snowflake no es una base de datos operativa, carece de soporte para transacciones en tiempo real. En segundo lugar, actualmente carece de soporte para algoritmos de aprendizaje automático en la base de datos. También hay una gran diferencia con Azure Cosmos DB, que es una base de datos de varios modelos, pero solo permite el acceso a través de la API seleccionada para la tabla, colección o conjunto de datos específicos.

Desde ese punto de vista, Oracle ofrece otra diferencia; los datos relacionales se pueden ver y acceder como documentos JSON y viceversa. Y eso plantea un punto interesante con las canalizaciones de agregación. Sí, en un futuro previsible, Oracle agregará soporte. Pero no debería sorprender, viniendo de una empresa de bases de datos relacionales, que Oracle crea que SQL es una forma más robusta de acceder y consultar datos, independientemente de si los datos están en tablas relacionales o colecciones de documentos.

Cuando se trata de datos complejos, las declaraciones SELECT pueden ser mucho más eficientes, siempre que no se trate de operaciones que requieran una cantidad ridícula de combinaciones de tablas. Las canalizaciones de agregación recopilan valores de varios documentos y los agrupan, mientras que las instrucciones SQL SELECT funcionan a través de uniones de tablas.

Por supuesto, el debate sobre cuál es el mejor método de consulta es discutible, ya que el objetivo de Oracle aquí es reunirse con los desarrolladores de MongoDB donde viven. Esa casilla de verificación finalmente se ha marcado con el soporte de una API compatible con MongoDB, en lugar de una API que se parece.

Cuando informamos sobre la introducción original de Oracle de la base de datos JSON autónoma, notamos que está fijando un precio muy agresivo para el servicio a tarifas que son más bajas que la edición completa de la base de datos autónoma. No es necesariamente un juego de suma cero para alejar a los clientes de MongoDB Atlas.

Aunque, dado el posicionamiento público de MongoDB de que el modelo de documento reemplazará al relacional, genera un debate filosófico interesante, uno que se reduce a matices dado que recientemente, Mongo agregó discretamente el $sql comando/etapa para admitir consultas SQL.

No obstante, al final del día, todo se trata de números. Un gran número de desarrolladores, eso es. La actualización de enero de 2022 del índice TIOBE clasifica a JavaScript como el séptimo lenguaje más popular, seguido de SQL en el número nueve. Comenzando con una gran base de desarrolladores de JavaScript, MongoDB construyó su popularidad con herramientas de desarrollo fáciles de usar como Compass. Desde entonces, Oracle también detectó ese error con su servicio en la nube APEX de código bajo (que también se puede usar en el servicio de base de datos JSON).

Más concretamente, la base de desarrolladores de MongoDB se ha convertido en un objetivo lo suficientemente grande como para admitir múltiples jugadores en este espacio. Para Oracle, los principales atractivos son la base de datos autónoma, que se apoya en las capacidades de gestión automatizada integradas en la nave nodriza. Para aquellos que buscan mantener sus opciones abiertas, hay una actualización con un solo clic para soporte multimodelo en caso de que los desarrolladores de JSON deseen la base de datos autónoma de Oracle completa en toda su forma convergente.

Divulgación: Oracle es un cliente de dbInsight.

Deja un comentario