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