From 9cdc2630dcd053d1f0b75cb9e8c0ea0e9d455581 Mon Sep 17 00:00:00 2001 From: Simran Date: Thu, 29 Nov 2018 06:18:41 -0800 Subject: [PATCH] Documentation/rdb exclusive options (#7548) --- Documentation/Books/AQL/Operations/Insert.md | 5 ++--- Documentation/Books/AQL/Operations/Remove.md | 4 ++-- Documentation/Books/AQL/Operations/Replace.md | 4 ++-- Documentation/Books/AQL/Operations/Update.md | 5 ++--- Documentation/Books/AQL/Operations/Upsert.md | 11 +++++------ .../Books/Manual/DataModeling/OperationalFactors.md | 8 ++++---- 6 files changed, 17 insertions(+), 20 deletions(-) diff --git a/Documentation/Books/AQL/Operations/Insert.md b/Documentation/Books/AQL/Operations/Insert.md index a1b8409353..7719945ab5 100644 --- a/Documentation/Books/AQL/Operations/Insert.md +++ b/Documentation/Books/AQL/Operations/Insert.md @@ -100,13 +100,12 @@ FOR i IN 1..1000 } INTO users OPTIONS { overwrite: true } ``` - In contrast to the MMFiles engine, the RocksDB engine does not require collection-level locks. Different write operations on the same collection do not block each other, as long as there are no _write-write conficts_ on the same documents. From an application development perspective it can be desired to have exclusive write access on collections, -to simplify the development. Note that writes do not block reads in rocksdb. -Exclusive access can also speed up modification queries, because we avoid conflict checks.
+to simplify the development. Note that writes do not block reads in RocksDB. +Exclusive access can also speed up modification queries, because we avoid conflict checks. Use the *exclusive* option to achieve this effect on a per query basis: diff --git a/Documentation/Books/AQL/Operations/Remove.md b/Documentation/Books/AQL/Operations/Remove.md index ad4ee2ec7f..c67e89f5e6 100644 --- a/Documentation/Books/AQL/Operations/Remove.md +++ b/Documentation/Books/AQL/Operations/Remove.md @@ -122,8 +122,8 @@ In contrast to the MMFiles engine, the RocksDB engine does not require collectio locks. Different write operations on the same collection do not block each other, as long as there are no _write-write conficts_ on the same documents. From an application development perspective it can be desired to have exclusive write access on collections, -to simplify the development. Note that writes do not block reads in rocksdb. -Exclusive access can also speed up modification queries, because we avoid conflict checks.
+to simplify the development. Note that writes do not block reads in RocksDB. +Exclusive access can also speed up modification queries, because we avoid conflict checks. Use the *exclusive* option to achieve this effect on a per query basis: diff --git a/Documentation/Books/AQL/Operations/Replace.md b/Documentation/Books/AQL/Operations/Replace.md index b973d7a5e3..e782ab48aa 100644 --- a/Documentation/Books/AQL/Operations/Replace.md +++ b/Documentation/Books/AQL/Operations/Replace.md @@ -115,8 +115,8 @@ In contrast to the MMFiles engine, the RocksDB engine does not require collectio locks. Different write operations on the same collection do not block each other, as long as there are no _write-write conficts_ on the same documents. From an application development perspective it can be desired to have exclusive write access on collections, -to simplify the development. Note that writes do not block reads in rocksdb. -Exclusive access can also speed up modification queries, because we avoid conflict checks.
+to simplify the development. Note that writes do not block reads in RocksDB. +Exclusive access can also speed up modification queries, because we avoid conflict checks. Use the *exclusive* option to achieve this effect on a per query basis: diff --git a/Documentation/Books/AQL/Operations/Update.md b/Documentation/Books/AQL/Operations/Update.md index e7238bc216..41cd753e33 100644 --- a/Documentation/Books/AQL/Operations/Update.md +++ b/Documentation/Books/AQL/Operations/Update.md @@ -230,13 +230,12 @@ FOR i IN 1..1000 OPTIONS { ignoreRevs: false } ``` - In contrast to the MMFiles engine, the RocksDB engine does not require collection-level locks. Different write operations on the same collection do not block each other, as long as there are no _write-write conficts_ on the same documents. From an application development perspective it can be desired to have exclusive write access on collections, -to simplify the development. Note that writes do not block reads in rocksdb. -Exclusive access can also speed up modification queries, because we avoid conflict checks.
+to simplify the development. Note that writes do not block reads in RocksDB. +Exclusive access can also speed up modification queries, because we avoid conflict checks. Use the *exclusive* option to achieve this effect on a per query basis: diff --git a/Documentation/Books/AQL/Operations/Upsert.md b/Documentation/Books/AQL/Operations/Upsert.md index a18d45dba1..b64262eace 100644 --- a/Documentation/Books/AQL/Operations/Upsert.md +++ b/Documentation/Books/AQL/Operations/Upsert.md @@ -99,21 +99,20 @@ the searchExpression. Even worse, if you use an outdated `_rev` in the searchExp UPSERT will trigger the INSERT path instead of the UPDATE path, because it has not found a document exactly matching the searchExpression. - In contrast to the MMFiles engine, the RocksDB engine does not require collection-level locks. Different write operations on the same collection do not block each other, as long as there are no _write-write conficts_ on the same documents. From an application development perspective it can be desired to have exclusive write access on collections, -to simplify the development. Note that writes do not block reads in rocksdb. -Exclusive access can also speed up modification queries, because we avoid conflict checks.
+to simplify the development. Note that writes do not block reads in RocksDB. +Exclusive access can also speed up modification queries, because we avoid conflict checks. Use the *exclusive* option to achieve this effect on a per query basis: ```js FOR i IN 1..1000 - UPSERT { _key: CONCAT('test', i)} - INSERT {foobar: false} - UPDATE {foobar: true } + UPSERT { _key: CONCAT('test', i) } + INSERT { foobar: false } + UPDATE { foobar: true } IN users OPTIONS { exclusive: true } ``` diff --git a/Documentation/Books/Manual/DataModeling/OperationalFactors.md b/Documentation/Books/Manual/DataModeling/OperationalFactors.md index 999af6804a..4fbbaaac7b 100644 --- a/Documentation/Books/Manual/DataModeling/OperationalFactors.md +++ b/Documentation/Books/Manual/DataModeling/OperationalFactors.md @@ -262,18 +262,18 @@ the `intermediateCommitCount` option in the API to subdivide the AQL transaction ### Read / Write Load Balance Depending on whether your data model has a higher read- or higher write-rate you may want -to adjust some of the rocksdb specific options. Some of the most critical options to +to adjust some of the RocksDB specific options. Some of the most critical options to adjust the performance and memory usage are listed below: `--rocksdb.block-cache-size` -This is the size of the block cache in bytes. This cache is used for read operations, -increasing the size of this may improve the performance of read heavy workloads. +This is the size of the block cache in bytes. This cache is used for read operations. +Increasing the size of this may improve the performance of read heavy workloads. You may wish to adjust this parameter to control memory usage. `--rocksdb.write-buffer-size` -Amount of data to build up in memory before converting to a file on disk. +Amount of data to build up in memory before converting to a file on disk. Larger values increase performance, especially during bulk loads. `--rocksdb.max-write-buffer-number`