The cloud today has become the primary deployment option for startups and is gaining adoption across the worlds largest enterprises. As with other critical infrastructure holding sensitive organization or customer data, there are several key questions enterprises must consider when evaluating Open Native Graph Database (ONgDB) cloud deployments.
When running ONgDB in production, especially for an enterprise, the fully open source graph database is enterprise-ready because it offers high availability clustering, cache sharding, hot backup, enhanced monitoring, and a several other critical production features. Taking a shortcut here will leave your enterprise vulnerable to outages, data loss and little ability to upgrade as new versions of ONgDB are released.
- Enterprise Lock Manager
The enterprise lock manager enables high levels of concurrency through fast lock resolution, which provides vertical scaling of concurrent applications beyond 5 CPU cores.
- Cache Sharding
For large graphs this is very useful when paired with sticky sessions because it provides a high cache hit ratio where reads that are relevant to each instance in the cluster will warm the cache without needing to load the whole graph into memory.
- Property Existence Constraints
This allows to specify a property that must exist on a node when that node has a certain label. This database enforced schema eases data integration within an enterprise environment as well as increases developer productivity.
You’ll definitely want to take advantage of ONgDB support from GraphGrid for commercial deployments where availability and scale are critical.
As with typical database deployments part of the security hardening process involves removing direct web access to the database through its accessible ports and protocols. ONgDB is no different. While ONgDB provides basic auth, it is not recommended to expose your ONgDB graph database production deployment with a publicly accessible URL.
Public hosting options aren’t an option here. A Virtual Private Cloud (VPC) will to be utilized to guarantee an isolated network where all ONgDB instances are launched without any pubic accessibility. In this configuration, the public-facing subnet is made for your HTTP servers requiring internet access on 80/443 while backend systems in private-facing subnet has no internet connectivity.
Achieving availability in the cloud requires a more complete deployment than single region, single availability zone. Deploying an ONgDB cluster into the cloud a single region and availability zone simply isn’t enough. An architecture and process is needed for managing Wide-Area Network WAN deployments across multiple geographical regions and availability zones worldwide to ensure low-latency access and durability of your cluster.
- Zero Downtime Upgrades
Staying current with the latest ONgDB versions to ensure access to new features, performance improvements and bug fixes is critical to a growing enterprise. Architecting and operational process to ensure these upgrades are seamless and occur without any interruption to service is not so trivial. With the right architecture and processes automated this can be done very effectively.
- Failover/Disaster Recovery
While it may not seem likely, it is still necessary to consider how your enterprise remains operational in the face of catastrophic failure. A “what if” scenario would be this: What happens if the AWS west regions in California disappears one day to the next due a massive earth quake? Does your database remain operational? What is your time to be back online? Automatic failover for near-immediate disaster recovery scenarios isn’t easy, but definitely possible and necessary.
We’ve thought through and designed for all these critical aspects of providing a robust ONgDB enterprise-ready cloud offering. The GraphGrid Connected Data Platform provides all additional security, multi-region availability, failover for disaster recovery and zero downtime upgrades along with other data platform features to provide a turn-key ONgDB enterprise-ready cloud offering.