1
0
Fork 0
arangodb/Documentation/Books/Manual/Scalability
sleto-it 0ba532b16a
Doc - Replication Refactor - Part 1 (#4555)
Next steps after DC2DC and Cluster doc improvements:

- We refactor replication sections and make more intuitive separation between Master/Slave and the new Active Failover in 3.3
- We create corresponding sections for Master/Slave and Active Failover in the Administration and Deployment chapters, as well as in the Scalability chapter, where these "modes" are introduced
- We touch and improve the "Architecture" chapter as well, where some architecture info have to be placed
- We reorg the TOC having in more "logical" order:
-- Deployment
-- Administration
-- Security
-- Monitoring
-- Troubleshooting
- We adds parts in the TOC
- We add toc per pages, using page-toc plugin
- We also put close together "Scalability" and "Architecture" chapters, preliminary steps of further improvements / aggregation
- We improve swagger

Internal Ref:
- https://github.com/arangodb/planning/issues/1692
- https://github.com/arangodb/planning/issues/1655
- https://github.com/arangodb/planning/issues/1858
- https://github.com/arangodb/planning/issues/973 (partial fix)
- https://github.com/arangodb/planning/issues/1498 (partial fix)
2018-02-28 12:23:19 +01:00
..
ActiveFailover Doc - Replication Refactor - Part 1 (#4555) 2018-02-28 12:23:19 +01:00
Cluster Doc - Replication Refactor - Part 1 (#4555) 2018-02-28 12:23:19 +01:00
DC2DC Doc - ArangoSync doc integration (#4590) 2018-02-14 18:59:18 +01:00
MasterSlave Doc - Replication Refactor - Part 1 (#4555) 2018-02-28 12:23:19 +01:00
README.md Doc - Replication Refactor - Part 1 (#4555) 2018-02-28 12:23:19 +01:00

README.md

Scalability

ArangoDB is a distributed database supporting multiple data models, and can thus be scaled horizontally, that is, by using many servers, typically based on commodity hardware. This approach not only delivers performance as well as capacity improvements, but also achieves resilience by means of replication and automatic fail-over. Furthermore, one can build systems that scale their capacity dynamically up and down automatically according to demand.

One can also scale ArangoDB vertically, that is, by using ever larger servers. There is no built in limitation in ArangoDB, for example, the server will automatically use more threads if more CPUs are present.

However, scaling vertically has the disadvantage that the costs grow faster than linear with the size of the server, and none of the resilience and dynamical capabilities can be achieved in this way.

Options

Several options are available to scale ArangoDB, each of them has its own pros and cons: