mirror of https://gitee.com/bigwinds/arangodb
wrote NewFeatures doc
This commit is contained in:
Jan Steemann
parent
194b83b491
commit
e3db9dfc33
|
|
@ -193,7 +193,7 @@ v2.8.0-alpha1 (2015-12-03)
|
|||
|
||||
the index will now contain the individual values `"AQL"`, `"ArangoDB"` and `"Index"`.
|
||||
|
||||
Now the index will be for finding all documents having `"ArangoDB"` somewhere in their
|
||||
Now the index can be used for finding all documents having `"ArangoDB"` somewhere in their
|
||||
tags array using the following AQL query:
|
||||
|
||||
FOR doc IN colName
|
||||
|
|
|
|||
|
|
@ -0,0 +1,258 @@
|
|||
!CHAPTER Features and Improvements
|
||||
|
||||
The following list shows in detail which features have been added or improved in
|
||||
ArangoDB 2.8. ArangoDB 2.8 also contains several bugfixes that are not listed
|
||||
here. For a list of bugfixes, please consult the
|
||||
[CHANGELOG](https://github.com/arangodb/arangodb/blob/devel/CHANGELOG).
|
||||
|
||||
!SECTION AQL improvements
|
||||
|
||||
!SUBSECTION Array Indexes
|
||||
|
||||
Hash indexes and skiplist indexes can now optionally be defined for array values
|
||||
so that they index individual array members instead of the entire array value.
|
||||
|
||||
To define an index for array values, the attribute name is extended with the
|
||||
expansion operator `[*]` in the index definition.
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
db._create("posts");
|
||||
db.posts.ensureHashIndex("tags[*]");
|
||||
```
|
||||
|
||||
When given the following document
|
||||
|
||||
```json
|
||||
{
|
||||
"tags": [
|
||||
"AQL",
|
||||
"ArangoDB",
|
||||
"Index"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
this index will now contain the individual values `"AQL"`, `"ArangoDB"` and `"Index"`.
|
||||
|
||||
Now the index can be used for finding all documents having `"ArangoDB"` somewhere in
|
||||
their `tags` array using the following AQL query:
|
||||
|
||||
```
|
||||
FOR doc IN posts
|
||||
FILTER "ArangoDB" IN doc.tags[*]
|
||||
RETURN doc
|
||||
```
|
||||
|
||||
It is also possible to create an index on sub-attributes of array values. This makes
|
||||
sense when the index attribute is an array of objects, e.g.
|
||||
|
||||
```js
|
||||
db._drop("posts");
|
||||
db._create("posts");
|
||||
db.posts.ensureIndex({ type: "hash", fields: [ "tags[*].name" ] });
|
||||
db.posts.insert({ tags: [ { name: "AQL" }, { name: "ArangoDB" }, { name: "Index" } ] });
|
||||
db.posts.insert({ tags: [ { name: "AQL" }, { name: "2.8" } ] });
|
||||
```
|
||||
|
||||
The following query will then use the array index:
|
||||
|
||||
```
|
||||
FOR doc IN posts
|
||||
FILTER 'AQL' IN doc.tags[*].name
|
||||
RETURN doc
|
||||
```
|
||||
|
||||
Array values will automatically be de-duplicated before being inserted into an array index.
|
||||
|
||||
Please note that filtering using array indexes only works from within AQL queries and
|
||||
only if the query filters on the indexed attribute using the `IN` operator. The other
|
||||
comparison operators (`==`, `!=`, `>`, `>=`, `<`, `<=`) currently do not use array
|
||||
indexes.
|
||||
|
||||
|
||||
!SUBSECTION Optimizer improvements
|
||||
|
||||
The AQL query optimizer can now use indexes if multiple filter conditions on attributes of
|
||||
the same collection are combined with logical ORs, and if the usage of indexes would completely
|
||||
cover these conditions.
|
||||
|
||||
For example, the following queries can now use two independent indexes on `value1` and `value2`
|
||||
(the latter query requires that the indexes are skiplist indexes due to usage of the `<` and `>`
|
||||
comparison operators):
|
||||
|
||||
```
|
||||
FOR doc IN collection FILTER doc.value1 == 42 || doc.value2 == 23 RETURN doc
|
||||
FOR doc IN collection FILTER doc.value1 < 42 || doc.value2 > 23 RETURN doc
|
||||
```
|
||||
|
||||
|
||||
!SUBSECTION AQL functions added
|
||||
|
||||
The following AQL functions have been added in 2.8:
|
||||
|
||||
* `POW(base, exponent)`: returns the *base* to the exponent *exp*
|
||||
|
||||
* `UNSET_RECURSIVE(document, attributename, ...)`: recursively removes the attributes
|
||||
*attributename* (can be one or many) from *document* and its sub-documents. All other
|
||||
attributes will be preserved.
|
||||
Multiple attribute names can be specified by either passing multiple individual string argument
|
||||
names, or by passing an array of attribute names:
|
||||
|
||||
UNSET_RECURSIVE(doc, '_id', '_key', 'foo', 'bar')
|
||||
UNSET_RECURSIVE(doc, [ '_id', '_key', 'foo', 'bar' ])
|
||||
|
||||
* `IS_DATESTRING(value)`: returns true if *value* is a string that can be used in a date function.
|
||||
This includes partial dates such as *2015* or *2015-10* and strings containing
|
||||
invalid dates such as *2015-02-31*. The function will return false for all
|
||||
non-string values, even if some of them may be usable in date functions.
|
||||
|
||||
|
||||
!SUBSECTION Miscellaneous improvements
|
||||
|
||||
* the ArangoShell now provides the convenience function `db._explain(query)` for retrieving
|
||||
a human-readable explanation of AQL queries. This function is a shorthand for
|
||||
`require("org/arangodb/aql/explainer").explain(query)`.
|
||||
|
||||
* improved performance of skipping over many documents in an AQL query when no
|
||||
indexes and no filters are used, e.g.
|
||||
|
||||
FOR doc IN collection
|
||||
LIMIT 1000000, 10
|
||||
RETURN doc
|
||||
|
||||
* added cluster execution site info in execution plan explain output for AQL queries
|
||||
|
||||
* for 30+ AQL functions there is now an additional implementation in C++ that removes
|
||||
the need for internal data conversion when the function is called
|
||||
|
||||
* the AQL editor in the web interface now supports using bind parameters
|
||||
|
||||
|
||||
!SECTION Deadlock detection
|
||||
|
||||
ArangoDB 2.8 now has an automatic deadlock detection for transactions.
|
||||
|
||||
A deadlock is a situation in which two or more concurrent operations (user transactions
|
||||
or AQL queries) try to access the same resources (collections, documents) and need to
|
||||
wait for the others to finish, but none of them can make any progress.
|
||||
|
||||
In case of such deadlock, there would be no progress for any of the involved
|
||||
transactions, and none of the involved transactions could ever complete. This is
|
||||
completely undesirable, so the new automatic deadlock detection mechanism in ArangoDB
|
||||
will automatically kick in and abort one of the transactions involved in such deadlock.
|
||||
Aborting means that all changes done by the transaction will be rolled back and error
|
||||
29 (`deadlock detected`) will be thrown.
|
||||
|
||||
Client code (AQL queries, user transactions) that accesses more than one collection
|
||||
should be aware of the potential of deadlocks and should handle the error 29
|
||||
(`deadlock detected`) properly, either by passing the exception to the caller or
|
||||
retrying the operation.
|
||||
|
||||
|
||||
!SECTION Replication
|
||||
|
||||
The following improvements for replication have been made in 2.8 (note: most of them
|
||||
have been backported to ArangoDB 2.7 as well):
|
||||
|
||||
* added `autoResync` configuration parameter for continuous replication.
|
||||
|
||||
When set to `true`, a replication slave will automatically trigger a full data
|
||||
re-synchronization with the master when the master cannot provide the log data
|
||||
the slave had asked for. Note that `autoResync` will only work when the option
|
||||
`requireFromPresent` is also set to `true` for the continuous replication, or
|
||||
when the continuous syncer is started and detects that no start tick is present.
|
||||
|
||||
Automatic re-synchronization may transfer a lot of data from the master to the
|
||||
slave and may be expensive. It is therefore turned off by default.
|
||||
When turned off, the slave will never perform an automatic re-synchronization
|
||||
with the master.
|
||||
|
||||
* added `idleMinWaitTime` and `idleMaxWaitTime` configuration parameters for
|
||||
continuous replication.
|
||||
|
||||
These parameters can be used to control the minimum and maximum wait time the
|
||||
slave will (intentionally) idle and not poll for master log changes in case the
|
||||
master had sent the full logs already.
|
||||
The `idleMaxWaitTime` value will only be used when `adapativePolling` is set
|
||||
to `true`. When `adaptivePolling` is disable, only `idleMinWaitTime` will be
|
||||
used as a constant time span in which the slave will not poll the master for
|
||||
further changes. The default values are 0.5 seconds for `idleMinWaitTime` and
|
||||
2.5 seconds for `idleMaxWaitTime`, which correspond to the hard-coded values
|
||||
used in previous versions of ArangoDB.
|
||||
|
||||
* added `initialSyncMaxWaitTime` configuration parameter for initial and continuous
|
||||
replication
|
||||
|
||||
This option controls the maximum wait time (in seconds) that the initial
|
||||
synchronization will wait for a response from the master when fetching initial
|
||||
collection data. If no response is received within this time period, the initial
|
||||
synchronization will give up and fail. This option is also relevant for
|
||||
continuous replication in case *autoResync* is set to *true*, as then the
|
||||
continuous replication may trigger a full data re-synchronization in case
|
||||
the master cannot the log data the slave had asked for.
|
||||
|
||||
* HTTP requests sent from the slave to the master during initial synchronization
|
||||
will now be retried if they fail with connection problems.
|
||||
|
||||
* the initial synchronization now logs its progress so it can be queried using
|
||||
the regular replication status check APIs.
|
||||
|
||||
* added `async` attribute for `sync` and `syncCollection` operations called from
|
||||
the ArangoShell. Setthing this attribute to `true` will make the synchronization
|
||||
job on the server go into the background, so that the shell does not block. The
|
||||
status of the started asynchronous synchronization job can be queried from the
|
||||
ArangoShell like this:
|
||||
|
||||
/* starts initial synchronization */
|
||||
var replication = require("org/arangodb/replication");
|
||||
var id = replication.sync({
|
||||
endpoint: "tcp://master.domain.org:8529",
|
||||
username: "myuser",
|
||||
password: "mypasswd",
|
||||
async: true
|
||||
});
|
||||
|
||||
/* now query the id of the returned async job and print the status */
|
||||
print(replication.getSyncResult(id));
|
||||
|
||||
The result of `getSyncResult()` will be `false` while the server-side job
|
||||
has not completed, and different to `false` if it has completed. When it has
|
||||
completed, all job result details will be returned by the call to `getSyncResult()`.
|
||||
|
||||
* the web admin interface dashboard now shows a server's replication status
|
||||
at the bottom of the page
|
||||
|
||||
|
||||
!SECTION Web Admin Interface
|
||||
|
||||
The following improvements have been made for the web admin interface:
|
||||
|
||||
* the AQL editor now has support for bind parameters. The bind parameter values can
|
||||
be edited in the web interface and saved with a query for future use.
|
||||
|
||||
* the AQL editor now allows canceling running queries. This can be used to cancel
|
||||
long-running queries without switching to the *query management* section.
|
||||
|
||||
* the dashboard now provides information about the server's replication status at
|
||||
the bottom of the page. This can be used to track either the status of a one-time
|
||||
synchronization or the continuous replication.
|
||||
|
||||
|
||||
!SECTION Foxx improvements
|
||||
|
||||
* the module resolution used by `require` now behaves more like in node.js
|
||||
|
||||
* the `org/arangodb/request` module now returns response bodies for error responses
|
||||
by default. The old behavior of not returning bodies for error responses can be
|
||||
re-enabled by explicitly setting the option `returnBodyOnError` to `false`
|
||||
|
||||
|
||||
!SECTION Miscellaneous changes
|
||||
|
||||
The startup option `--server.hide-product-header` can be used to make the server
|
||||
not send the HTTP response header `"Server: ArangoDB"` in its HTTP responses. This
|
||||
can be used to conceal the server make from HTTP clients.
|
||||
By default, the option is turned off so the header is still sent as usual.
|
||||
|
||||
|
|
@ -19,7 +19,8 @@
|
|||
* [Upgrading to 2.3](Upgrading/Upgrading23.md)
|
||||
* [Upgrading to 2.2](Upgrading/Upgrading22.md)
|
||||
* [Cluster setup](Installing/Cluster.md)
|
||||
* [Whats New](NewFeatures/NewFeatures27.md)
|
||||
* [Whats New](NewFeatures/NewFeatures28.md)
|
||||
* [Whats New in 2.7](NewFeatures/NewFeatures27.md)
|
||||
* [Whats New in 2.6](NewFeatures/NewFeatures26.md)
|
||||
* [Whats New in 2.5](NewFeatures/NewFeatures25.md)
|
||||
* [Whats New in 2.4](NewFeatures/NewFeatures24.md)
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ will automatically abort one of the transactions involved in such deadlock. Abor
|
|||
means that all changes done by the transaction will be rolled back and error 29
|
||||
(`deadlock detected`) will be thrown.
|
||||
|
||||
Client code (AQL queries, user transactions) that access more than one collection
|
||||
Client code (AQL queries, user transactions) that accesses more than one collection
|
||||
should be aware of the potential of deadlocks and should handle the error 29
|
||||
(`deadlock detected`) properly, either by passing the exception to the caller or
|
||||
retrying the operation.
|
||||
|
|
|
|||
Loading…
Reference in New Issue