trafodion-codereview mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DaveBirdsall <>
Subject [GitHub] incubator-trafodion pull request: First phase of website update.
Date Wed, 18 Nov 2015 17:55:54 GMT
Github user DaveBirdsall commented on a diff in the pull request:
    --- Diff: docs/src/site/markdown/ ---
    @@ -0,0 +1,154 @@
    +## Overview ##
    +Trafodion provides an operational SQL engine on top of Hadoop -- a solution targeted
toward operational workloads in the Hadoop Big Data environment. Included are:
    +* Fully functional ANSI SQL language support
    +* Full ACID support for read/write queries including distributed transaction protection
for multiple rows, tables and statements
    +* Heterogeneous storage engine access including native access to data stores
    +* Enhanced High Availability support for client applications
    +* Support for large data sets using optimized intra-query parallelism
    +* Performance improvements for OLTP workloads via compile and runtime optimizations
    +Transaction management features include:
    +* Transaction serializability using the HBase-Trx implementation of Multi-Version Concurrency
    +* Transaction recovery to achieve database consistency
    +* Thread-aware transaction management support to work with multi-threaded SQL clients
    +* Non-transactional/direct access to HBase tables
    +## Process Architecture ##
    +The following figure depicts the Trafodion process architecture:
    +![Trafodion Process Architecture](images/process-architecture.png "Trafodion Process
    +The figure above should be interpreted as follows:
    +* Client Applications talk to Trafodion via a JDBC or ODBC interface. The Trafodion drivers
implement these interfaces, using an optimized Trafodion-specific wire protocol to talk to
the Master Executor process in the SQL layer. The diagram shows a JDBC Type-4 driver configuration.
    +* The Master Executor is the root process for executing SQL statements submitted via
JDBC or ODBC. It contains a copy of the SQL compiler code. Most SQL statements are compiled
within this process. The root of any compiled query plan is also executed in the Master Executor.
    +* A few SQL statements (for example, DDL and some utilities) require a second instance
of the compiler code; this is the CMP process in the diagram.
    +* Trafodion supports several forms of execution-time parallelism. When a query plan requires
parallelism, a set of ESP (Executor Server Processes) is dynamically spawned (if not already
available). Each ESP executes a fragment of the query plan.
    +* The DTM (Distributed Transaction Management) process manages distributed transactions.
This includes log management and transaction coordination.
    +* The Storage Engine layer consists of HBase and Hadoop processes. Trafodion allows SQL
access to native HBase tables. Trafodion reads HBase metadata in order to process these tables.
Trafodion also offers its own implementation of SQL table, stored as an HBase table, for applications
that need a more efficient OLTP representation. Trafodion generates its own metadata for such
tables, and stores that in HBase.
    +## Connectivity ##
    +The Database Connectivity Services (DCS) framework enables applications developed for
ODBC/JDBC APIs to access a Trafodion SQL database server. DCS is a distributed service. It
uses the underlying HBase ZooKeeper instance for its definition of a cluster. [Apache ZooKeeper]
( "Zookeeper website") is a centralized service for maintaining
configuration information, naming, providing distributed synchronization, and providing group
services. All participating nodes and clients need to be able to access the running ZooKeeper.
    +DCS is a collection of components:
    +* **ODBC/JDBC Drivers**: Provide a standard programming language middle-ware API for
accessing database management systems (DBMS).
    +* **DCS Master Process**: The DCS Master server is responsible for monitoring all server
instances in the cluster. It assigns an ODBC/JDBC client connection request to a Master Executor
(MXOSRVR) process. It also has a backup process that takes over the Master Executor role during
    +* **DCS Server Process**: This process is responsible for starting and keeping a Master
Executor (MXOSRVR) server process executing. There is one DCS Server process per node in the
    +* **Master Executor Process**: This is the database server that provides database access
to ODBC/JDBC clients. There is a one-to-one relationship between an ODBC/JDBC client connection
and a database server process. The Master Executor performs all SQL queries on behalf of its
client's requests. It will perform all required SQL calls to execute a SQL query through the
Executor to access HBase tables. The Master Executor is often referred to as MXOSRVR.
    +## Transaction Subsystem ##
    +Trafodion supports distributed ACID transaction semantics using the Multi-Version Concurrency
Control (MVCC) model. The transaction management is built on top of a fork of the *HBase-trx*
project implementing the following changes:
    +* Upgraded it to work on HBase version 0.98.1 (for CDH 5.1) or 0.98.0 (for HDP 2.1).
    +* Added support for parallel worker processes doing work on behalf of the same transaction.
    +* Added support for global transactions, that is, transactions that can encompass resources
(regions/HTables) across an HBase cluster.
    +* Added transaction recovery after server failure.
    +There is on Distributed Transaction Manager (DTM) process per node in a cluster running
Trafodion. The DTM process owns and keeps track of all transactions that were started on that
node. (In HBase-trx, transactions were tracked in the library code of each client, which meant
that after a server failure, there was no way to restart the transaction manager for in-doubt
    +When a Trafodion client begins a SQL statement, it checks in with the Transaction Manager
(TM) to begin the transaction. The TM returns a cluster-unique transaction ID. This transaction
ID in turn is propagated by the Trafodion Executor to any processes that work on some fragment
of that SQL statement. This transaction ID propagation occurs courtesy of a Trafodion messaging
layer, which keeps track, for example, of whether a process death has occurred.
    +When a Trafodion Executor process issues an HBase call, the modified client-side HBase-trx
library can deduce which TM owns the transaction from the transaction ID, and registers itself
with that TM if it has not already done so. Thus, at any given moment in time, a TM is aware
of what processes are participating in a transaction.
    +The original HBase-trx library worked by extending certain Java classes in the region
server. Our implementation has for the most part changed to execute this library in co-processors.
This allows better extensibility at the HBase level. With a class extension approach, only
one feature could extend the HBase code. With co-processors, it is possible to host several
extensions. Endpoint and observer co-processors perform the resource manager role in transaction
    +For additional details, please refer to the [Trafodion Distributed Transaction Management]
(presentations/dtm-architecture.pdf) presentation.
    +## Compiler Architecture ##
    +The Trafodion Compiler translates SQL statements into query plans that can then be executed
by the Trafodion execution engine, commonly called the Executor.
    +The Compiler is a multi-pass compiler. Each pass transforms a representation of the SQL
statement into a new or augmented representation which is input to the next pass. The sections
below give more detail on each pass. The logic that calls each pass is in the CmpMain class,
method CmpMain::compile. You can find that logic in file $MY_SQROOT/sql/sqlcomp/CmpMain.cpp.
    +A copy of the compiler code runs in the Master process, which avoids inter-process message
passing between the Compiler and Executor. At the moment the compiler code is not re-entrant,
but it is a serially reusable resource within the Master. Some processing is recursive. For
example, the execution logic for DDL statements is packaged with the compiler code. When we
execute a DDL statement, the Executor spawns a separate Compiler process to execute that logic.
For another example, the UPDATE STATISTICS utility dynamically generates SQL SELECT statements
to obtain statistical data. Since we are not re-entrant, we spawn a separate Compiler process
for this recursive processing.
    +The compiler is written in C++.
    +### Parser ###
    +The parser pass performs lexical and syntactic analysis, transforming the SQL statement
into a parse tree. Trafodion uses a hand-coded scanner for lexical analysis of UCS2 strings.
(UTF-8 encoding for SQL statement text is support but is translated to UCS2 internally). 
    --- End diff --
    Typo: UTF-8 encoding for SQL statement text is support [sic, should be "supported"]...

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message