History[07]

McObject started in 2001 with the launch of the eXtremeDB In-Memory Database System.

Checkpoints

• A hybrid database system-eXtremeDB combines the strengths of the on-disk and all-in-memory approaches to data management in a DBMS. eXtremeDB was originally designed and optimized as an in-memory database system, enabling more efficient data management. • The unique eXtremeDB Active Replication Fabric™ is the foundation for eXtremeDB High Availability, eXtremeDB Cluster and IoT data replication. IoT data replication, in particular, must handle: o intermittent connectivity o low bandwidth (e.g. LoRaWAN) o secure transfer • Multiple application programming interfaces (APIs). • B-Tree, R-Tree, Patricia Trie, KD-Tree, Trigram and Hash indexes • A wide range of supported data types – in addition to the usual scalar data types, eXtremeDB supports strings, structures, arrays, vectors and BLOBs for maximum efficiency. • Statistical analysis – eXtremeDB HPC comes with a library of more than 100 functions for performing statistical analysis on time series data, such as grand, group, grid and window averages to name a few. • Pipelining – eXtremeDB’s extensive library of math functions are building blocks that can be assembled into a pipeline to minimize data transfers and maximally exploit the CPU and L1/L2/L3 cache. • Columnar and conventional row-oriented storage – The best of OLTP and time series data management. • Horizontal partitioning (sharding) – Elastically scale databases on-premises or in the cloud. Utilize every CPU and every core. • Tools that support the encryption of data in transit as well as at rest.

Compression[08]

eXtremeDB offers Zip-like compression for tables (horizontal storage), and Run-length Encoding for time series (vertical storage).

Concurrency Control[09][10]

eXtremeDB offers a multi-version concurrency control (MVCC) optimistic transaction manager and an alternative "pessimistic" MURSIW (MUltiple Reader, Single Writer) transaction manager.

Data Model

Foreign Keys

Indexes[11]

eXtremeDB database offers multiple indexes, including the following:

B-Trees for common sorting and searches, insertions, and deletions R-Trees for geospatial indexing (common in GPS/navigation systems) Hash tables for quickly locating a single unique index entry Patricia trie index, which speeds searches in networking and telephony applications Trigram indexes are ideal for text searches when the exact spelling of the target object is not precisely known. It finds objects which match the maximum number of three-character strings in the entered search terms, i.e., near matches. “Custom indexes” or b-trees that allow the application to define the collating sequence of entries; this is useful in implementing soundex algorithm searches, for example KD-Trees or k-dimensional trees, for spatial and pattern-matching tasks and in applications where query predicates contain various combinations of object fields (for example, to construct Query-By-Example, or QBE features)

Isolation Levels

Query Compilation

As well as Prepared Statements

Query Interface

Storage Architecture[12]

eXtremeDB enables the developer to combine both database paradigms – in-memory and on-disk – in a single database instance. Specifying one set of data as transient (managed in memory), while choosing persistent storage for other record types, requires a simple database schema declaration.

Storage Model[13]

eXtremeDB implements row-based layout for all data types other than sequences. Row and columnar layout can be combined in hybrid data designs to optimize performance managing mixed data.

Stored Procedures[14]

Lua, Python or C++ based stored procedures run in the context of the SQL server and therefore minimizes client-server inter-process communication and attendant network overhead, and fully utilizes the multi-core nature of modern hardware.

System Architecture