Version Management

UES offers different product versions, and new versions are regularly released according to the official website updates. Users can choose the version they want to use according to their actual needs and usage habits. It is recommended to use the latest version.

The versions that are currently released are:

V5.5.1 V6.2.1 V6.5.4 V7.1.1

Version Features

Highlights of V6.0

Faster reboot and restore with serial numbers

The biggest new feature in version 6.0 is the sequence ID, which allows operation-based shard recovery. Previously, if a node disconnected from the cluster due to network problems or node restarts, each partition on the node had to be resynchronized by comparing the segment files with the master shard and copying any different segments. This could be a long and expensive process, even making the rolling restart of the node very slow. With sequence IDs, each shard will only be able to replay the missing operations in that shard, making the recovery process more efficient.

Faster queries with sorted indexes

With sorted indexing, the search can terminate as soon as enough hits are collected. It is much more efficient to sort on low-cardinality fields (like age, gender, is_published) that are often used as filters, because all potential matching documents are grouped together.

Sparse Area Improvements

Previously, each field in each column reserved a storage space. If only a few documents appear in many fields, it can lead to a huge waste of disk space. Now, you pay for what you use. Dense fields will use the same amount of space as before, but sparse fields will significantly reduce. This not only reduces the amount of disk space used, but also reduces merge time and improves query throughput, because it can better utilize the file system cache.

Type Removal

In version 6.0, an index no longer supports multiple types, parent-child relationships based on type will be implemented through a separate join field, and type will be completely removed in version 7.0.

Index Version Inheritance

To avoid conflicts caused by the merge of all matched index templates in version 6.0, only one will be matched, and it will be validated when the index is created.

Load-Based Request Routing

Previously, search requests were full-node polling, and slow nodes often caused overall latency. In version 6.0, the implementation will be based on queued time to automatically adjust the length of the queue, and both search and index will be based on this mechanism.