皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

ArangoDB 3.2.7 发布,多模式数据库

ArangoDB 3.2.7 发布,多模式数据库

ArangoDB 3.2.7 发布了,ArangoDB 是一个开源的分布式原生多模型数据库 (Apache 2 license)。

理念

利用一个引擎,一个 query 语法,一项数据库技术,以及多个数据模型,来最大力度满足项目的灵活性,简化技术堆栈,简化数据库运维,降低运营成本。

ArangoDB原生多模型数据库,指的是兼有图 (graph)、文档 (document)和键/值对 (key/value) 三种数据模型存储软件。其快捷灵活之处在于,它有适用于全部三种数据模型的统一内核和统一数据库查询语言——AQL (ArangoDB Query Language)。其可以涵盖全部三种数据模型,还允许在单个查询中混合使用三种数据模型。

因此,用户可以在单次查询过程中混合使用多种数据模型,而无需在不同数据模型间相互“切换”,也不需要执行数据传输过程。并且这三种数据模型均支持水平扩展。基于其本地集成多模型特性,ArangoDB 原生多模型数据库适用于搭建高性能应用程序。

该版本修复了很多 Bug,详细内容如下:

* Cluster customers, which have upgraded from 3.1 to 3.2 need to upgrade    
to 3.2.7. The cluster supervision is otherwise not operational.    
* Fixed issue #3597: AQL with path filters returns unexpected results    
In some cases breadth first search in combination with vertex filters    
yields wrong result, the filter was not applied correctly.    
* fixed some undefined behavior in some internal value caches for AQL GatherNodes    
and SortNodes, which could have led to sorted results being effectively not    
correctly sorted.    
* make the replication applier for the RocksDB engine start automatically after a    
restart of the server if the applier was configured with its `autoStart` property    
set to `true`. previously the replication appliers were only automatically restarted    
at server start for the MMFiles engine.    
* fixed arangodump batch size adaptivity in cluster mode and upped default batch size    
for arangodump    
these changes speed up arangodump in cluster context    
* smart graphs now return a proper inventory in response to replication inventory    
requests    
* fixed issue #3618: Inconsistent behavior of OR statement with object bind parameters    
* only users with read/write rights on the "_system" database can now execute    
"_admin/shutdown" as well as modify properties of the write-ahead log (WAL)    
* increase default maximum number of V8 contexts to at least 16 if not explicitly    
configured otherwise.    
the procedure for determining the actual maximum value of V8 contexts is unchanged    
apart from the value `16` and works as follows:    
- if explicitly set, the value of the configuration option `--javascript.v8-contexts`    
is used as the maximum number of V8 contexts    
- when the option is not set, the maximum number of V8 contexts is determined    
by the configuration option `--server.threads` if that option is set. if    
`--server.threads` is not set, then the maximum number of V8 contexts is the    
server's reported hardware concurrency (number of processors visible    
to the arangod process). if that would result in a maximum value of less than 16    
in any of these two cases, then the maximum value will be increased to 16.    
* fixed issue #3447: ArangoError 1202: AQL: NotFound: (while executing) when    
updating collection    
* potential fix for issue #3581: Unexpected "rocksdb unique constraint    
violated" with unique hash index    
* fixed geo index optimizer rule for geo indexes with a single (array of coordinates)    
attribute.    
* improved the speed of the shards overview in cluster (API endpoint /_api/cluster/shardDistribution API)    
It is now guaranteed to return after ~2 seconds even if the entire cluster is unresponsive.    
* fix agency precondition check for complex objects    
this fixes issues with several CAS operations in the agency    
* several fixes for agency restart and shutdown    
* the cluster-internal representation of planned collection objects is now more    
lightweight than before, using less memory and not allocating any cache for indexes    
etc.    
* fixed issue #3403: How to kill long running AQL queries with the browser console's    
AQL (display issue)    
* fixed issue #3549: server reading ENGINE config file fails on common standard    
newline character    
* UI: fixed error notifications for collection modifications    
* several improvements for the truncate operation on collections:    
* the timeout for the truncate operation was increased in cluster mode in    
order to prevent too frequent "could not truncate collection" errors    
* after a truncate operation, collections in MMFiles still used disk space.    
to reclaim disk space used by truncated collection, the truncate actions    
in the web interface and from the ArangoShell now issue an extra WAL flush    
command (in cluster mode, this command is also propagated to all servers).    
the WAL flush allows all servers to write out any pending operations into the    
datafiles of the truncated collection. afterwards, a final journal rotate    
command is sent, which enables the compaction to entirely remove all datafiles    
and journals for the truncated collection, so that all disk space can be    
reclaimed    
* for MMFiles a special method will be called after a truncate operation so that    
all indexes of the collection can free most of their memory. previously some    
indexes (hash and skiplist indexes) partially kept already allocated memory    
in order to avoid future memory allocations    
* after a truncate operation in the RocksDB engine, an additional compaction    
will be triggered for the truncated collection. this compaction removes all    
deletions from the key space so that follow-up scans over the collection's key    
range do not have to filter out lots of already-removed values    
These changes make truncate operations potentially more time-consuming than before,    
but allow for memory/disk space savings afterwards.    
* enable JEMalloc background threads for purging and returning unused memory    
back to the operating system (Linux only)    
JEMalloc will create its background threads on demand. The number of background    
threads is capped by the number of CPUs or active arenas. The background threads run    
periodically and purge unused memory pages, allowing memory to be returned to the    
operating system.    
This change will make the arangod process create several additional threads.    
It is accompanied by an increased `TasksMax` value in the systemd service configuration    
file for the arangodb3 service.    
* upgraded bundled V8 engine to bugfix version v5.7.492.77    
this upgrade fixes a memory leak in upstream V8 described in    
https://bugs.chromium.org/p/v8/issues/detail?id=5945 that will result in memory    
chunks only getting uncommitted but not unmapped

转自 http://www.oschina.net/news/90618/arangodb-3-2-7