At Last, MongoDB Developers Get Full Autonomous Capabilities

February 15, 2022 | 4 minute read
Text Size 100%:

Guest post by Carl Olofson, Research Vice President, Data Management Software, IDC

For many enterprises, JavaScript Object Notation (JSON) documents are critical elements in their online applications. These documents fuel customer experience (CX), sales, and operational applications on the edge, where performance and reliability are critical. JSON enables users to build data structures defined directly by program code. Whenever new developments require data structure changes, developers can implement those changes immediately, without needing to apply to a DBA or wait for a schema upgrade process to complete.

MongoDB has become a leader in the area of JSON databases, and many organizations that use Oracle for enterprise relational applications have turned to MongoDB for their JSON database needs.

A year ago, Oracle announced Autonomous JSON Database (AJD), a new cloud service based upon the foundation of Oracle’s flagship Autonomous Database, as a simple, affordable package designed for JSON-centric developers. It included native JSON features along with a MongoDB-inspired NoSQL API called SODA (Simple Oracle Document Access) and full SQL support for accessing JSON content on Oracle Database. This capability is now enhanced so that the native JSON support is tied directly to the MongoDB API running on Oracle Autonomous Database (ADB), providing a plug-compatible alternative to MongoDB Atlas.

Prior to the introduction of the Oracle Database API for MongoDB, users and developers of MongoDB who wanted to perform analytical queries on document collections had to use an operationally separate database. Operations that ensure overall integrity of data, such as backups, could not be done on all the data together. They had to be done on each database separately, with no guarantee that databases containing logically related data could be recovered in a way that ensures full integrity. Users of separate, differently structured databases that must be coordinated were generally faced with performing that coordination using extract-transform-load (ETL) processes that expose the whole system to problems of data consistency and other faults resulting from operations problems and human error. In addition, the ETL process takes time, meaning that data to be analyzed would often be stale.

Maintaining JSON data in the multi-model AJD, the same database that manages the related table data, overcomes this problem, enabling users to perform SQL queries over JSON documents. Also, AJD offers the benefits of ADB. This means that those same machine learning-driven self-tuning and self-healing capabilities that underpin ADB are also available to MongoDB users who move their data to AJD.

Since Oracle Database users can fold their JSON documents under the Oracle Database umbrella, they can greatly simplify their database operations in the cloud. Using Oracle Database to manage the full range of operational data means that resources, including processors and storage, are allocated at the same rate, and there is just one bill to pay. Some JSON database users may argue that Oracle’s JSON support is less efficient than a specialized DBMS. That may have been true at one time, when JSON documents were stored as objects in tables. However, for the past year, Oracle Database has featured document handling and storage capabilities designed specifically for JSON documents including a new binary data type. In that mode, it is a native JSON database.

AJD is essentially a self-managing, self-healing, dynamically scaling JSON database with MongoDB API compatibility, running on OCI. It is affordably priced for those only using the JSON features, but can be expanded with just one click to the full transaction processing (ATP) configuration of ADB. Customers can also add Oracle Autonomous Data Warehouse (ADW) to the mix. For those who wish to try before they buy, there is an always-free tier.

It is clear that the concentration of all data on one database instance cannot completely solve an enterprise’s data management problems, and that having just one schema for all data is not practical. At the same time, there is a clear benefit with the ability to reduce the total number of database operational assets both from a management and billing perspective, and to blending database operations across models where it makes sense to do so. Using the same core technology for the range of database models required, as in Oracle’s converged database engine, means smoother integration and easier staff training and execution.

Why then use different database models? Some models are more effective in certain use cases than others. JSON documents have established a clear role in supporting applications that require both control over the data format and a high degree of flexibility; the absence of a schema enables developers to evolve applications quickly to address shifting requirements. So, a native JSON document database offers clear advantages for these requirements.

AJD enables users to run their JSON document databases on the self-driving ADB platform, entirely managed by Oracle on OCI, and to coordinate those operations with their other operational databases that are relational in nature, especially those running on Oracle Database. As for the future, Oracle has said that over 90% of its JSON customers are using another data model, suggesting that a greater convergence lies ahead for Oracle users. Those Oracle users who also use other JSON database systems, such as MongoDB or MongoDB-compatible databases, may want to give AJD and the Oracle Database API for MongoDB a good, hard look.

Learn more about Oracle Database API for MongoDB

Guest Author

Previous Post

Database Tools in Oracle Cloud Infrastructure (OCI)

Guest Author | 14 min read

Next Post

Oracle Zero Downtime Migration 21.3

Ricardo Gonzalez | 3 min read