Hawkin
/
arangodb
mirror of https://gitee.com/bigwinds/arangodb
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Move some docs from administration to architecture

This commit is contained in:
Simran Brucherseifer 2016-05-02 03:33:55 +02:00
parent b9b89937d5
commit 7e6ac5f5fd
2 changed files with 29 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
Documentation/Books/Users/Administration/README.mdpp
View File

@ -1,31 +1,8 @@
!CHAPTER Administrating ArangoDB
!CHAPTER Administration
!SECTION AppendOnly/MVCC
!SECTION Durability Configuration
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.
!SECTION 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.
!SUBSECTION Durability Configuration
!SUBSUBSECTION Global Configuration
!SUBSECTION Global Configuration
There are global configuration values for durability, which can be adjusted by
specifying the following configuration options:
@ -39,7 +16,7 @@ specifying the following configuration options:
@startDocuBlock WalLogfileSyncInterval
!SUBSUBSECTION Per-collection configuration
!SUBSECTION Per-collection configuration
You can also configure the durability behavior on a per-collection basis.
Use the ArangoDB shell to change these properties.
@ -48,7 +25,7 @@ Use the ArangoDB shell to change these properties.
@startDocuBlock collectionProperties
!SUBSUBSECTION Per-operation configuration
!SUBSECTION Per-operation configuration
Many data-modification operations and also ArangoDB's transactions allow to specify
a *waitForSync* attribute, which when set ensures the operation data has been

24
Documentation/Books/Users/Architecture/README.mdpp Normal file
View File

@ -0,0 +1,24 @@
!CHAPTER Architecture
!SECTION 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.
!SECTION 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.