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 the Neo4j graph database cloud deployments.
When running Neo4j in production, especially for an enterprise, the obvious baseline is to use the Neo4j Enterprise edition 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 Neo4j 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 Neo4j Enterprise 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 it’s accessible ports and protocols. Neo4j is no different. While Neo4j provides basic auth, it is not recommended to expose your Neo4j 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 Neo4j 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 a Neo4j Enterprise 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 Neo4j 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 Neo4j Enterprise cloud offering. The GraphGrid 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 Neo4j enterprise cloud offering.