Why Distributed Analytical Databases Are the Future: Inside ArgoDB’s Architecture

Background Introduction

Distributed analytical databases are emerging as an alternative to MPP parallel computing. They offer better scalability, broader hardware support, and address several architectural limitations of MPP systems.

Academic research on distributed analytical databases is limited this year; most advances come from industry. The storage layer typically uses distributed or cloud storage, while the compute layer relies on an independent distributed compute engine, unlike MPP where storage and compute are tightly coupled.

When Hadoop rose, its distributed architecture demonstrated scalability, elasticity, fault‑tolerance, and cost benefits, but sacrificed traditional SQL features such as transactions and relational models. Since 2013, many SQL‑on‑Hadoop engines have matured, proving the importance of SQL over API‑centric approaches.

Building a data warehouse with a distributed analytical database requires solving distributed transactions and high‑concurrency batch processing, often requiring a new transaction engine and a compute engine that may use a DAG model.

Overall Architecture

Distributed databases can absorb the strengths of MPP and Hadoop while avoiding their drawbacks. Their logical architecture typically includes a service layer, SQL engine, distributed transaction engine, distributed compute engine, and storage engine. The key difference from MPP is the separation of compute and storage, enabling elastic scaling of compute resources.

Distributed Storage Engine

Most industry solutions use Paxos or Raft for high‑availability distributed storage. Columnar formats such as ORC and Parquet are common, providing high read throughput, strong compression (5‑10×), and parallel column reads. Columnar storage also supports diverse structured and unstructured data.

Read‑optimised APIs expose filtering, indexing, and push‑down capabilities. Writes are typically buffered in memory before being persisted, as columnar stores are less write‑friendly.

Distributed transactions rely on MVCC and compaction. Updates create new versions; reads merge visible versions based on transaction IDs. Compaction merges many small versions to maintain read performance.

Operational concerns include disk/node addition‑removal, data migration, and overall management.

Distributed Compute Engine

The compute engine provides a framework (often DAG or MPP), a rich set of operators (hash join, sort‑merge join, index join, skew join, etc.), an optimizer, and resource management. Advanced systems aim for autonomous databases using rule‑based and machine‑learning optimisations.

Resource management integrates with YARN, Kubernetes, or cloud platforms to support multi‑tenant workloads.

Distributed Transaction Engine

Key techniques include two‑phase commit (2PC), MVCC, snapshot isolation, and various isolation levels (serializable, repeatable read, read committed). Analytical workloads often involve low‑concurrency batch updates, allowing simpler algorithms such as two‑phase locking (2PL).

SQL Engine

The SQL engine offers full SQL support, compatibility with Oracle, Teradata, DB2, and advanced optimisation. Providing comprehensive SQL capabilities remains a major challenge for new databases.

StarRing Analytical Database ArgoDB

ArgoDB targets high‑performance distributed analytical workloads on private‑cloud environments. It combines a flash‑optimized storage layer, a vectorised DAG compute engine (Crux), a SQL compiler, and a distributed transaction manager.

The storage manager TDDMS abstracts the underlying storage engine (Holodesk) via Raft‑based consensus, enabling high availability, backup, and plug‑in support for new storage back‑ends.

Holodesk uses a hybrid row‑column layout on flash SSDs, supporting auxiliary indexes and block‑level aggregation, while also allowing memory‑plus‑flash‑plus‑disk tiering.

Crux executes vectorised plans, reads columnar files efficiently, and minimizes data conversion overhead.

ArgoDB implements a two‑level resource scheduler: a static pool of CPU/memory resources and a dynamic “Furion” tree‑structured scheduler that allows resource borrowing between nodes, ACLs, and affinity settings, supporting multi‑tenant fairness and priority‑based pre‑emptive scheduling.

ArgoDB has been deployed in numerous financial‑grade production cases and achieved top‑rank results in the TPC‑DS benchmark, demonstrating its advanced architecture.

Conclusion

The article presented the architectural principles of distributed analytical databases and highlighted ArgoDB’s core capabilities, emphasizing compute‑storage separation, elasticity, and resource management. Future topics will explore data federation for cross‑database analytics.