a1a02d29ce
* Add WITH to graph traversal syntax * State clearer what where whitespace is ignored in conf files * Add cross-references between POSITION() and CONTAINS() * Mention GeoJSON in the description of the useLonLat option * Troubleshooting: unexpected long running queries Add remark that collection literals are inferior to FOR constructs and should not be used accidentally instead of variable names * Add storage engine comparison table, replace hint to note that users might want to pick RocksDB for an installation * CSS: No margin extra margin after last paragraph in callouts / hint boxes |
||
|---|---|---|
| .. | ||
| README.md | ||
| StorageEngines.md | ||
| WriteAheadLog.md | ||
README.md
Architecture
AppendOnly/MVCC
Instead of overwriting existing documents, ArangoDB will create a new version of modified documents. This is even the case when a document gets deleted. The two benefits are:
- Objects can be stored coherently and compactly in the main memory.
- Objects are preserved, isolated writing and reading transactions allow accessing these objects for parallel operations.
The system collects obsolete versions as garbage, recognizing them as forsaken. Garbage collection is asynchronous and runs parallel to other processes.
Mostly Memory/Durability
Database documents are stored in memory-mapped files. Per default, these memory-mapped files are synced regularly but not instantly. This is often a good tradeoff between storage performance and durability. If this level of durability is too low for an application, the server can also sync all modifications to disk instantly. This will give full durability but will come with a performance penalty as each data modification will trigger a sync I/O operation.