Relational databases are pretty useful but:
- Joins are slow, even with lots of indexes and a great optimizer.
- ORMs hide but don’t eliminate joins.
- Natively handle objects, but,
- Abandon the idea of querying the data using a language.
The Akiban Database Server fundamentally solves the join problem and unifies the two worlds.
- Table groups assemble sets of tables into a new logical construct called table-groups. Table groups are a good match for your intuitive notions about what is related to what, i.e., mirror application objects.
- New physical organization: Store the joined rows of a table-group interleaved in a b-tree. E.g. a Customer is followed by its Orders. Each Order is followed by its items. Record keys are constructed so that insertion into the b-tree maintains this interleaving.
- The join is now precomputed, and joins that used to be expensive are essentially free. The rows of the join are consecutive b-tree records.
- ORMs can now request, for example, a Customer with all of its Orders and Items. A connection setting instructs the server to return the result as a JSON-structured object. Voila, a Customer its Orders and Items in one round trip, with the join computed for the cost of one b-tree probe on the server.
- Powerful indexing on a table group is now possible.
What this means
- Table-group interleaving reflects intuitive understanding of objects/documents.
- Documents can be accessed in a single request. ORMs can leverage this for efficient interaction between ORM and database.
- Joins within a group are close to free. Complex queries often run 10x-150x faster in memory (compared to MySQL). Denormalization is not necessary.
- The perfect synthesis of documents and SQL.
Sign in to add slides, notes or videos to this session