Nested Loop Join Hash Join Broadcast Join
Currently, AsterixDB supports multiple join types (hash, nested loop, and broadcast), but it does not yet have effective statistics or selectivity estimates. Therefore, the default join algorithm is a hash-join. For non-equality predicates such as inequalities or “like” predicates for strings where, the default is a nested-loop join, since hashing can only be used for exact matches.
Initially, AsterixDB used one custom query language, the Asterix Query Language (AQL). This is laid out like JSON but has more flexibility, making it a superset of JSON. However, the most recent documentation lists AQL as deprecated. The currently supported query interface for AsterixDB is SQL++, which is a superset of both SQL and JSON, making it more flexible than AQL.
N-ary Storage Model (Row/Record)
AsterixDB stores data in an NSM layout, hash-partitioning records to different nodes based on their primary keys.
AsterixDB uses logical logging at an index granularity, meaning each insert, delete, or update to an index generates a single log record. Logs have sequence numbers (LSNs) for the sake of the recovery phase. Unlike the ARIES protocol, where pages have page LSNs that indicate the most recent update applied to it, AsterixDB’s indexes have an index LSN, which indicates the most recent update applied to that particular index.
B+Tree R-Tree Inverted Index (Full Text) Log-Structured Merge Tree
For primary indexes, AsterixDB uses Log-Structured Merge trees (LSM trees), and for secondary indexes, it allows B+trees, R trees, and inverted keyword indexes. However, these secondary indexes are “LSM-ified” to make their properties more like those of an LSM tree.
Asterix uses its own data representation, the Asterix Data Model (ADM). It is laid out similar to a JSON object but has more flexibility, making it a superset of JSON. It currently supports common primitive types (booleans, strings, ints of different sizes, floats/dobules, binary) as well as geometric data types (point, line, rectangle, circle, polygon), and time-based data types (date, time, timestamp, interval, duration). It supports null/missing values, as well as derived types (objects, arrays, and multisets).
Two-Phase Locking (Deadlock Prevention) Two-Phase Locking (Deadlock Detection)
Locks are only required on primary indexes; for secondary indexes, accesses do not require locks, but primary index lookups verify the integrity of secondary index lookups. Furthermore, locking is only done for lookups, inserts, and deletes -- other operations such as flushing to disk do not acquire locks. Notably, AsterixDB only supports single-statement transactions, and some more complicated SQL++ statements are even represented as multiple single-object statements and as such are represented as multiple transactions.
https://github.com/apache/asterixdb
University of California-Irvine
2009