mirror of https://gitee.com/bigwinds/arangodb
updated new features document
This commit is contained in:
parent
8c52ccf6cf
commit
4aafe2173c
|
@ -1,7 +1,7 @@
|
|||
devel
|
||||
-----
|
||||
|
||||
* --server.maximal-queue-size is now an absolute maximum. If the queue is
|
||||
* `--server.maximal-queue-size` is now an absolute maximum. If the queue is
|
||||
full, then 503 is returned. Setting it to 0 means "no limit".
|
||||
|
||||
|
||||
|
|
|
@ -5,60 +5,200 @@ The following list shows in detail which features have been added or improved in
|
|||
ArangoDB 3.2. ArangoDB 3.2 also contains several bugfixes that are not listed
|
||||
here.
|
||||
|
||||
SmartGraphs
|
||||
-----------
|
||||
|
||||
Memory management
|
||||
-----------------
|
||||
|
||||
Data format
|
||||
-----------
|
||||
* added startup options `--vm.resident-limit` and `--vm.path` for file-backed
|
||||
memory mapping after reaching a configurable maximum RAM size
|
||||
|
||||
This prevents ArangoDB from using all available RAM when using large datasets.
|
||||
This will also lower the chances of the arangod process being killed by the
|
||||
operation system's OOM killer.
|
||||
|
||||
Note: these options are only available in all builds and environments.
|
||||
|
||||
* make arangod start with less V8 JavaScript contexts
|
||||
|
||||
This speeds up the server start and makes arangod use less memory at start.
|
||||
Whenever a V8 context is needed by a Foxx action or some other JavaScript operation
|
||||
and there is no usable V8 context, a new context will be created dynamically now.
|
||||
|
||||
Up to `--javascript.v8-contexts` V8 contexts will be created, so this option
|
||||
will change its meaning. Previously as many V8 contexts as specified by this
|
||||
option were created at server start, and the number of V8 contexts did not
|
||||
change at runtime. Now up to this number of V8 contexts will be in use at the
|
||||
same time, but the actual number of V8 contexts is dynamic.
|
||||
|
||||
The garbage collector thread will automatically delete unused V8 contexts after
|
||||
a while. The number of spare contexts will go down to as few as configured in
|
||||
the new option `--javascript.v8-contexts-minimum`. Actually that many V8 contexts
|
||||
are also created at server start.
|
||||
|
||||
The first few requests in new V8 contexts may take longer than in contexts
|
||||
that have been there already. Performance may therefore suffer a bit for the
|
||||
initial requests sent to ArangoDB or when there are only few but performance-
|
||||
critical situations in which new V8 contexts need to be created. If this is a
|
||||
concern, it can easily be fixed by setting `--javascipt.v8-contexts-minimum`
|
||||
and `--javascript.v8-contexts` to a relatively high value, which will guarantee
|
||||
that many number of V8 contexts to be created at startup and kept around even
|
||||
when unused.
|
||||
|
||||
Waiting for an unused V8 context will now also abort and write a log message
|
||||
in case no V8 context can be acquired/created after 60 seconds.
|
||||
|
||||
* the number of pending operations in arangod can now be limited to a configurable
|
||||
number. If this number is exceeded, the server will now respond with HTTP 503
|
||||
(service unavailable). The maximum size of pending operations is controlled via
|
||||
the startup option `--server.maximal-queue-size`. Setting it to 0 means "no limit".
|
||||
|
||||
* the in-memory document revisions cache was removed entirely because it did not
|
||||
provide the expected benefits. The 3.1 implementation shadowed document data in
|
||||
RAM, which increased the server's RAM usage but did not speed up document lookups
|
||||
too much.
|
||||
|
||||
This also obsoletes the startup options `--database.revision-cache-chunk-size` and
|
||||
`--database.revision-cache-target-size`.
|
||||
|
||||
The MMFiles engine now does not use a document revisions cache but has in-memory
|
||||
indexes and maps documents to RAM automatically via mmap when documents are
|
||||
accessed. The RocksDB engine has its own mechanism for caching accessed documents.
|
||||
|
||||
|
||||
Communication Layer
|
||||
-------------------
|
||||
|
||||
* HTTP responses returned by arangod will now include the extra HTTP header
|
||||
`x-content-type-options: nosniff` to work around a cross-site scripting bug
|
||||
in MSIE
|
||||
|
||||
Cluster
|
||||
-------
|
||||
* the default value for `--ssl.protocol` was changed from TLSv1 to TLSv1.2.
|
||||
When not explicitly set, arangod and all client tools will now use TLSv1.2.
|
||||
|
||||
* the JSON data in all incoming HTTP requests in now validated for duplicate
|
||||
attribute names.
|
||||
|
||||
Incoming JSON data with duplicate attribute names will now be rejected as
|
||||
invalid. Previous versions of ArangoDB only validated the uniqueness of
|
||||
attribute names inside incoming JSON for some API endpoints, but not
|
||||
consistently for all APIs.
|
||||
|
||||
* Internal JavaScript REST actions will now hide their stack traces to the client
|
||||
unless in HTTP responses. Instead they will always log to the logfile.
|
||||
|
||||
|
||||
Document revisions cache
|
||||
------------------------
|
||||
JavaScript
|
||||
----------
|
||||
|
||||
* updated V8 version to 5.7.0.0
|
||||
|
||||
* change undocumented behaviour in case of invalid revision ids in
|
||||
`If-Match` and `If-None-Match` headers from 400 (BAD) to 412 (PRECONDITION
|
||||
FAILED).
|
||||
|
||||
* change default string truncation length from 80 characters to 256 characters for
|
||||
`print`/`printShell` functions in ArangoShell and arangod. This will emit longer
|
||||
prefixes of string values before truncating them with `...`, which is helpful
|
||||
for debugging. This change is mostly useful when using the ArangoShell (arangosh).
|
||||
|
||||
|
||||
AQL
|
||||
---
|
||||
|
||||
### Functions added
|
||||
|
||||
|
||||
### Optimizer improvements
|
||||
|
||||
* Geo indexes are now implicitly and automatically used when using appropriate SORT/FILTER
|
||||
statements in AQL, without the need to use the somewhat limited special-purpose geo AQL
|
||||
functions `NEAR` or `WITHIN`.
|
||||
|
||||
Compared to using thespecial purpose AQL functions this approach has the
|
||||
advantage that it is more composable, and will also honor any `LIMIT` values
|
||||
used in the AQL query.
|
||||
|
||||
The special purpose `NEAR` AQL function can now be substituted with the
|
||||
following AQL (provided there is a geo index present on the `doc.latitude`
|
||||
and `doc.longitude` attributes):
|
||||
|
||||
FOR doc in geoSort
|
||||
SORT DISTANCE(doc.latitude, doc.longitude, 0, 0)
|
||||
LIMIT 5
|
||||
RETURN doc
|
||||
|
||||
`WITHIN` can be substituted with the following AQL:
|
||||
|
||||
FOR doc in geoFilter
|
||||
FILTER DISTANCE(doc.latitude, doc.longitude, 0, 0) < 2000
|
||||
RETURN doc
|
||||
|
||||
Note that this will work in the MMFiles engine only.
|
||||
|
||||
|
||||
### Miscellaneous improvements
|
||||
|
||||
* the slow query list now contains the values of bind variables used in the
|
||||
slow queries. Bind variables are also provided for the currently running
|
||||
queries. This helps debugging slow or blocking queries that use dynamic
|
||||
collection names via bind parameters.
|
||||
|
||||
Audit Log
|
||||
---------
|
||||
* AQL breaking change in cluster:
|
||||
The SHORTEST_PATH statement using edge collection names instead
|
||||
of a graph names now requires to explicitly name the vertex collection names
|
||||
within the AQL query in the cluster. It can be done by adding `WITH <name>`
|
||||
at the beginning of the query.
|
||||
|
||||
Example:
|
||||
```
|
||||
FOR v,e IN OUTBOUND SHORTEST_PATH @start TO @target edges [...]
|
||||
```
|
||||
|
||||
Now has to be:
|
||||
|
||||
```
|
||||
WITH vertices
|
||||
FOR v,e IN OUTBOUND SHORTEST_PATH @start TO @target edges [...]
|
||||
```
|
||||
|
||||
This change is due to avoid deadlock sitations in clustered case.
|
||||
An error stating the above is included.
|
||||
|
||||
|
||||
Client tools
|
||||
------------
|
||||
|
||||
Added the tool _arangoexport_ to export collections to json and jsonl. It can also export graphs or collections to xgmml.
|
||||
* added data export tool, arangoexport.
|
||||
|
||||
Web Admin Interface
|
||||
-------------------
|
||||
arangoexport can be used to export collections to json, jsonl or xml
|
||||
and export a graph or collections to xgmml.
|
||||
|
||||
* added "jsonl" as input file type for arangoimp
|
||||
|
||||
* added `--translate` option for arangoimp to translate attribute names from
|
||||
the input files to attriubte names expected by ArangoDB
|
||||
|
||||
The `--translate` option can be specified multiple times (once per translation
|
||||
to be executed). The following example renames the "id" column from the input
|
||||
file to "_key", and the "from" column to "_from", and the "to" column to "_to":
|
||||
|
||||
arangoimp --type csv --file data.csv --translate "id=_key" --translate "from=_from" --translate "to=_to"
|
||||
|
||||
`--translate` works for CSV and TSV inputs only.
|
||||
|
||||
* changed default value for client tools option `--server.max-packet-size` from 128 MB
|
||||
to 256 MB. this allows transferring bigger result sets from the server without the
|
||||
client tools rejecting them as invalid.
|
||||
|
||||
|
||||
Authentication
|
||||
--------------
|
||||
|
||||
* added LDAP authentication (Enterprise only)
|
||||
|
||||
|
||||
Foxx
|
||||
----
|
||||
|
||||
The [cookie session transport](../Foxx/Sessions/Transports/Cookie.md) now supports all options supported by the [cookie method of the response object](../Foxx/Router/Response.md#cookie).
|
||||
* the [cookie session transport](../Foxx/Sessions/Transports/Cookie.md) now supports all options supported by the [cookie method of the response object](../Foxx/Router/Response.md#cookie).
|
||||
|
||||
It's now possible to provide your own version of the `graphql-sync` module when using the [GraphQL extensions for Foxx](../Foxx/GraphQL.md) by passing a copy of the module using the new _graphql_ option.
|
||||
* it's now possible to provide your own version of the `graphql-sync` module when using the [GraphQL extensions for Foxx](../Foxx/GraphQL.md) by passing a copy of the module using the new _graphql_ option.
|
||||
|
||||
Endpoints can now be tagged using the [tag method](../Foxx/Router/Endpoints.md#tag) to generate a cleaner Swagger documentation.
|
||||
* custom API endpoints can now be tagged using the [tag method](../Foxx/Router/Endpoints.md#tag) to generate a cleaner Swagger documentation.
|
||||
|
|
Loading…
Reference in New Issue