ArangoDB Enterprise: OneShard
Single server performance & semantics with cluster fault-tolerance
Not all use cases require horizontal scalability. In such cases, a OneShard deployment offers a practicable solution that enables significant performance improvements by massively reducing cluster-internal communication.
A database created with OneShard enabled is limited to a single DB-Server node but still replicated synchronously to ensure resilience. This configuration allows running transactions with ACID guarantees on shard leaders.
This setup is highly recommended for most Graph use cases and join-heavy queries.
Unlike a sharded cluster, where the Coordinator distributes access to shards across different DB-Server nodes, collects and processes partial results, the Coordinator in a OneShard setup moves the query execution directly to the respective DB-Server for local query execution. The Coordinator receives only the final result. This can drastically reduce resource consumption and communication effort for the Coordinator.
Scaling Graphs
For graphs larger than what fits on a single DB-Server node, you can use the SmartGraphs feature to efficiently limit the network hops between Coordinator and DB-Servers.
Database Creation
To take advantage of local execution on the DB-Server node, you can create a database that by default limits collections to a single shard by setting the sharding option to a value of “single”. A replication factor of 3 ensures that there are two replicas for resilience.
1
arangosh> db._createDatabase("oneShardDB", { sharding: "single", replicationFactor: 3 } )
After that, you don’t need to worry about additional settings when creating collections in that database. They will automatically be part of the same OneShard configuration.
Multi-Tenant Applications
To separate data from different clients in multi-tenant SaaS applications, you can use dedicated databases and still take advantage of availability and scaling benefits through cluster setup.
While each customer’s data fits on a single node, a growing number of tenants increase the need to scale the cluster. OneShard makes it possible to add more nodes to a cluster while still allowing queries to execute efficiently on a single DB-Server.
ACID Transactions on leader shards
In ArangoDB you can benefit from tunable transactional guarantees that you can increase when you need them. To ensure durability, activate waitForSync on query level to wait until data modifications have been written to disk. The collection option writeConcern:2 makes sure that a transaction is only successful if at least one replica is in sync. The RocksDB engine supports intermediate commits for larger document operations. To prevent this for individual queries you can increase RocksDB intermediateCommitSize (default 512 MB) and intermediateCommitCount accordingly. Using Stream Transactions in a OneShard setup and these mentioned options you get multi-document, multi-collection ACID transactions on leader shards.