The Oracle Database API for MongoDB (hereafter MongoDB API) allows you to access Oracle Databases from MongoDB-compatible programs and drivers simply by modifying the access URI of your program or application.
There are two ways to use the Oracle Database API for MongoDB (or MongoDB API):
As a fully managed service, the first option requires no configuration (beyond turning the feature on) nor any maintenance from a customer perspective. This document will therefore concentrate on the second option, where the customer manages the deployment and support of the MongoDB API.
MongoDB programs and drivers communicate with their database(s) over a socket connection, usually using port 27017. A URI contains all the information needed to define the server connection and typically takes the form
mongodb://[user:pass@]servername:27017/databasename?parameters
In the case of a MongoDB database, the database server itself listens on port 27017 and acts on incoming requests. Oracle MongoDB API provides the same transparent connection through Oracle REST Data Services (ORDS), so all you need to do is to change your connection string. No additional port openings or firewall changes are required; all you need is network connectivity to your ORDS installation, on-premises, or in the Cloud.
The MongoDB API is an integral part of ORDS. It rewrites MongoDB requests into appropriate Oracle SQL or SODA operations and passes them to the Oracle database server over SQL*Net. Storing your documents centrally in an Oracle Database enables you to provide MongoDB compatibility with your data stored and managed in the most mature, mission-critical Oracle Database and enhance your capabilities to work with the data beyond pure document-store APIs, such as full SQL/JSON access for analytics.
You need to deploy ORDS as a standalone application, meaning that the ORDS process spins up its own Jetty Web Server. Such a deployment has the advantage of requiring only Java and a minimal resource footprint.
The following defines some best practices for deploying the MongoDB API for your applications.
No.
In most cases, the built-in MongoDB API support is sufficient, and you don’t want to deploy and manage anything yourself. However, you may get more tunability and performance under certain challenging conditions by utilizing a standalone ORDS server on an OCI VM or a machine outside of OCI. If you decide to deploy your own ORDS, you can still use the MongoDB API interface provided by the Autonomous Database Service in parallel, for example, for testing or development purposes.
No.
Although ORDS itself can run standalone or as part of WebLogic Server (WLS) or Tomcat, the MongoDB API is currently only supported through standalone ORDS deployments.
The location of where to deploy ORDS is primarily a decision of your architectural preference and how you leverage ORDS in your enterprise. It also depends on whether ORDS is just a means for providing the MongoDB API or is also leveraged for other ORDS functionality, such as serving as a REST Server or as a backend for Oracle APEX. Depending on your use case, you can either:
When working with ORDS, where the sole purpose is to provide the MongoDB API, it is usually best to run the ORDS server in the application node next to your application. When you have multiple application servers on individual nodes, you can run an ORDS instance with each application server. That way:
However, there can be advantages to running ORDS on a separate cluster, mainly in the case of using ORDS for more than the MongoDB API. The benefits would be:
When deploying ORDS as a separate central component in a multi-tenant fashion, you need to ensure that:
Yes. Please see Oracle REST Data Services (ORDS) best practices, but when reading it, remember that any references to WLS or Tomcat should be ignored—any recommendation wrt. High Availability is applicable for standalone ORDS installations. Most of these recommendations will be more relevant for separate, centrally deployed ORDS environments.
Yes. ORDS is configured with a relatively basic set of performance settings out of the box. Those might be ok for testing or small applications with light-weight utilization, but if you want high throughput, you must configure some settings like the connection pool size. Please see Section 9.7, Achieving High Performance in the ORDS Installation and Configuration Guide.
If you want to spend 7 minutes to read about what simple parameter changes can do, then check out this blog post.. If you ask me, a quick-and-easy read and definitely worth the time.
Hermann is a Senior Director of Product Management in the Oracle Database organization. He and his team focus on Oracle's core functionality, such as Oracle Partitioning, the Oracle Optimizer, and analytical SQL. His team also looks after semi-structured data processing, such as the relational SQL/JSON capabilities, Oracle Text, and more recently Autonomous JSON Database and the Oracle Database API for Mongo DB.
Hermann has held several positions at Oracle in Sales Consulting and Consulting, dealing with the database for quite some time
Previous Post