Oracle Database API for MongoDB - Best Practices

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):

1. As part of a fully managed Autonomous Database Serverless.

2. Using a standalone ORDS server connected to an Autonomous Database Dedicated/CC or an unmanaged Oracle Database, on-premises or in the Cloud.

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 API architecture

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.

I have an Autonomous Database Serverless. Is there any reason to use a standalone ORDS server??

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.

Can I use WebLogic Server or Apache Tomcat?

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.

Where should I run ORDS?

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:

◉ Deploy ORDS centrally as a separate component.

◉ Consider ORDS part of your application that requires MongoDB API compatibility.

 

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:

◉ The MongoDB API scales with the number of application server nodes.

◉ You only need to size the resources for each ORDS installation based on the requirements of a single application node.

◉ There’s no need to keep other ports open between your application node and the ORDS node. The only connection port required to communicate with the Oracle Database is the port for your SQL*Net connection.

◉ You don’t need to maintain separate hardware or containers for the ORDS nodes.

◉ Assuming you have a high-availability and/or load-balancing solution for your application nodes, that will also automatically work for ORDS.

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:

◉ A single ORDS instance can serve multiple applications and/or databases.

◉ ORDS can be scaled independently of the application.

◉ You can maintain a shared connection pool.

When deploying ORDS as a separate central component in a multi-tenant fashion, you need to ensure that:

◉ Your HA requirements must be met with multiple deployments and a mechanism to transparently work with any of your deployed ORDS instances, for example, through Load Balancers in a Cloud environment.

◉ You need to size the resources required for ORDS based on the aggregated requirements of all ORDS-supported services.

Are there other recommendations for installing and using Standalone ORDS?

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.

Anything I need to do to achieve high throughput?

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. 

Source: oracle.com