Sharding

ArangoDB is organizing its collection data in shards. Shardingallows to use multiple machines to run a cluster of ArangoDBinstances that together constitute a single database. This enablesyou to store much more data, since ArangoDB distributes the data automatically to the different servers. In many situations one can also reap a benefit in data throughput, again because the load canbe distributed to multiple machines.

Shards are configured per collection so multiple shards of data formthe collection as a whole. To determine in which shard the data is tobe stored ArangoDB performs a hash across the values. By default thishash is being created from _key.

To configure the number of shards:

127.0.0.1:8529@_system> db._create("sharded_collection", {"numberOfShards": 4});

To configure the hashing for another attribute:

127.0.0.1:8529@_system> db._create("sharded_collection", {"numberOfShards": 4, "shardKeys": ["country"]});

This would be useful to keep data of every country in one shard whichwould result in better performance for queries working on a per countrybase. You can also specify multiple shardKeys. Note however that ifyou change the shard keys from their default ["_key"], then findinga document in the collection by its primary key involves a request toevery single shard. Furthermore, in this case one can no longer prescribethe primary key value of a new document but must use the automaticallygenerated one. This latter restriction comes from the fact that ensuringuniqueness of the primary key would be very inefficient if the usercould specify the primary key.

On which node in a cluster a particular shard is kept is undefined.There is no option to configure an affinity based on certain shard keys.

Unique indexes (hash, skiplist, persistent) on sharded collections areonly allowed if the fields used to determine the shard key are alsoincluded in the list of attribute paths for the index: