ONgDB Deployment Options

Baseline for Deployment to be Production Ready

If you intend to perform an ONgDB production deployment successfully, you’ll likely think about the best application architecture to use and how you’ll operate your ONgDB deployment at a scale. Some ONgDB deployment basics you’ll need to think about should include how you intend to guarantee availability uptime, handle failures and efficiently facilitate zero downtime upgrades, which is really just the required baseline to be considered production ready. It may go without saying, but to go to production without using an ONgDB cluster is a huge risk to your applications availability.

In terms of deployment options, there are two ways in which you can incorporate the Open Native Graph Database (ONgDB) within your app. These can be:

• Using ONgDB embedded: This means you’ll be utilizing the ONgDB Java libraries and packaging it with the rest of your application code into a WAR or JAR file that is deployed to the Java server of your choice such as JBoss or Tomcat.
• Using ONgDB server: This means you’ll be utilizing the default Jetty server wrapper that is provided with ONgDB and communicating with the database over rest, which is the recommended approach for almost all applications because it keeps your database decoupled from your application and enables the two to be upgraded independently. In this architecture if you do need low-level access to the Java APIs you’ll be able to utilize unmanaged extensions that deploy directly to the ONgDB database.

What are the minimum requirements needed to ensure your ONgDB deployment is production ready?

• High Availability Clustering
  Thanks to advancements made in SaaS and mobile, enterprises have evolved to effectively engage with their customers over the years. This connected architecture offers numerous challenges since keeping services and systems running and connected is essential.

  High availability clustering is used to reduce downtime and offer consistent service when specific system components fail. High availability clusters have numerous nodes that interact and share data effectively to ensure high system scalability, availability, and reliability.

• Backup and Restoration
  A backup solution is the one responsible for creating separate data copies which can be utilized in restoring back the cluster in an event of failure. The backup strategy for how much you keep and how you perform the backup is largely dependent on the size of the database on disk, but whatever the case you’ll want that restoration to be nearly immediate.
• Disaster Recovery
  Disaster recovery deals with deploying to a geographically distinct location to enable your database to remain available in the event of a failure in your primary region. With multi-region failover, your ONgDB cluster will span multiple WAN (Wide Area Network) locations consisting of a primary region and a secondary failover region. In cases of failure or impairment in your primary region, your ONgDB enterprise-ready graph database will immediately have traffic routed to the newly elected master in the secondary region.

  *To utilize a multi-region failover with the least service interruption, you’ll need to make use of a CDN service. This is essential to curb service interruption. The CDN will continue serving cached content while your site is being switch over to the secondary region.

Figuring out all of these ONgDB deployment basics on your own will be time consuming and challenging, which is why after having done it hundreds times over the years we’ve made it a foundational component in GraphGrid Cloud for the ONgDB Enterprise cloud offering of production-ready ONgDB. We’ve done this because we know it’s just the expected baseline for any production application and not something you should leave to chance.