MOTService Enhanced Features

Memory Optimized Data Structures

MOTService uses a memory-optimized data structure that is more suitable for large-memory and multi-core servers. All data and indexes are stored in the memory, no intermediate page caches are used, and the lock with the shortest duration is used. The data structure and all algorithms are optimized for memory design. Memory-optimized tables are created side by side regular disk-based tables. MOTService's effective design enables almost full SQL coverage and support for a full database feature-set. MOTService is fully ACID compliant and includes strict durability and high availability support.

Lock-Free Transaction Management

While ensuring strict consistency and data integrity, MOT uses optimistic policies to achieve high concurrency and high throughput. During a transaction, the MOT does not lock any version of the data row being updated, greatly reducing contention in some large memory systems. Optimistic concurrency control (OCC) in transactions is implemented without locks. All data modification is performed in the part of memory dedicated to private transactions (also called private transactional memory). This means that during a transaction, related data is updated in the private transactional memory, thereby implementing lock-free read and write. In addition, a lock is locked for a short time only in the commit phase.

Lock-Free Index

The data and indexes of memory tables are stored in the memory. Therefore, it is important to have an efficient index data structure and algorithm. The MOTService index mechanism is based on the state-of-the-art Masstree, which is a fast and scalable Key Value (KV) storage index for multi-core systems and is implemented using the Trie of the B+ tree. In this way, excellent performance on multi-core servers can be achieved in the case of high-concurrency workloads. Masstree is a combination of tries and a B+ tree that is implemented to carefully exploit caching, prefetching, optimistic navigation, and fine-grained locking. However, the downside of a Masstree index is its higher memory consumption. MOTService's main innovation was to enhance the original Masstree data structure and algorithm, which did not support non-unique indexes. Another improvement is Arm architecture support.

Native Statements for Query

With the PREPARE client commands, users can execute query and transaction statements interactively. These commands have been pre-compiled into native execution formats, also known as Code-Gen or Just-in-Time (JIT) compilation. In this way, the performance can be improved by 30% on average. If possible, apply compilation and lightweight execution; otherwise, use the standard execution path to process the applicable query. The Cache Plan module has been optimized for OLTP. Different binding settings are used in the entire session and compilation results are reused in different sessions. Figure 1 shows the concepts of JIT queries and stored procedures.

Figure 1 JIT queries and stored procedures

NUMA-ware Memory Management

MOTService memory access is designed with Non-Uniform Memory Access (NUMA) awareness. NUMA-aware algorithms enhance the performance of a data layout in memory so that threads access the memory that is physically attached to the core on which the thread is running. This is handled by the memory controller without requiring an extra hop by using an interconnect, such as Intel QPI. MOTService's smart memory control module with pre-allocated memory pools for various memory objects improves performance, reduces locks and ensures stability. Allocation of a transaction's memory objects is always NUMA-local. Deallocated objects are returned to the pool. Minimal usage of OS malloc during transactions circumvents unnecessary locks. The MOTService engine performs synchronous Group Commit logging with NUMA optimization by automatically grouping transactions according to the NUMA socket of the core on which the transaction is running.

Figure 2 MOTService memory access

MOTService Active/Standby HA

MOTService uses the HA module of Manager for automatic active/standby switchover. The active HA process checks whether the active MOTService process on the same node is normal every 30 seconds.

If the process is abnormal, MOTService status is set to NonActive, the Nginx process on the same node is stopped, and the original standby instance is promoted to the active instance. Then, MOTService status on the same node is set to Active, and the Nginx process on the same node is started.

Both active and standby Nginx instances are configured to listen to the same floating IP address. Service applications can access MOTService through the Nginx route by connecting to the floating IP address. Therefore, the active/standby switchover of Nginx and MOTService is transparent to the interfaces used by service applications.

Figure 3 Active/standby HA deployment