InfiniDB is an advanced database specially tuned to deliver high performance, real time analytics ... BI queries and pre
w: www.mariadb.com e:
[email protected]
MariaDB 10.1 Prospective Feature Descriptions
Transactional DDL A number of other relational database systems include the ability to wrap schema changes (DDL) in transactions, and roll back most structural changes to the database, including table creation, adding/deleting columns and indexes, etc. Transactional DDL allows the database layer to help enable DevOps methodologies such as continuous integration, deployment, and automated test and configuration management by eliminating downtime for schema changes, and permitting automatic roll back should a deployment fail for some reason. Implementing this feature will involve using existing persistent, versioned table metadata to allow different versions of tables to coexist in the database and obey transactional semantics, and wiring this into the transactional mechanisms within MariaDB.
Kerberos authentication plug-in Kerberos is a standardised network authentication protocol providing strong, mutual authentication of potential users and network services in open, distributed networks. Kerberos uses a trusted third party, the Key Distribution Center (KDC), to facilitate the generation and secure distribution of encrypted authentication tickets and symmetric session keys. The goal of this feature is to add cross-platform (at least Linux and Windows) Kerberos authentication support to MariaDB database.
Integration of Galera multi-master clustering into MariaDB MariaDB and MariaDB Galera Cluster are currently separate products. MariaDB Galera Cluster is based on MariaDB with a set of Galera patches on top, including the wsrep provider and patches in the SQL layer. The idea here is to have the wsrep provider and the other Galera patches part of normal MariaDB. They would be disabled by default but easily turned on through some configuration option.
Geographic Information System (GIS) improvements: full OGC compliance and performance enhancements This feature will provide compliance to the SQL Options described in the Implementation Standard for Geographic information, available here: http://www.opengeospatial.org/standards/sfs. Page: 1
w: www.mariadb.com e:
[email protected]
Compliance with the OpenGIS standards will require new data structures, and improvements in the optimizer. More information is available here: ● MariaDB Plans on GIS; ● Spatial UDFs; ● Extra OGC Spatial Functions; ● Added new stored procedures and tables.
JSON, BSON and YAML support MariaDB currently stores data available in JSON or BSON format into a relational structure, based on standard data types such as NUMERIC, STRING, TEXT and BLOB columns. The retrieval of this data, using sequential access or indexing, is not ideal. This feature will allow users to store data structured in JSON and BSON format in specifically designed and optimized data types. JSON and BSON will be indexed in a format that makes data search and retrieval faster and more accurate. Functions added to MariaDB will also find, add, extract, replace and remove full or partial documents. Transformation and formatting functions will better integrate relational data with JSON and BSON data, and format the output of queries and SQL statements in JSON and YAML format.
Indexes on Expressions Many relational databases allow for index columns defined by functions and expressions. For example, a table could include an index that uses a lower() function to lower-case another column before indexing: CREATE INDEX my_table1_lowercase_column1_idx on my_table1 (lower(column1));
This feature will allow expressions within indexes to speed up operations such as JOINs between tables with similar but not exactly matching data using expressions to transform the data to match. There are many other potential use cases.
Page: 2
w: www.mariadb.com e:
[email protected]
Analytical functions starting with basic windowing functions Analytical functions allow you to add columns of aggregation functions based on partitioning rows into “windows” and then adding the aggregated value corresponding to the row’s window. For example: SELECT player, team, score, MAX(score) OVER (PARTITION BY team) AS max_team_score FROM allplayers; PLAYER TEAM SCORE MAX_TEAM_SCORE JoeB 1 4960 6763 MaryK 1 6763 6763 JackS 1 3431 6763 DonD 1 2324 6763 KarenJ 2 1311 10334 BobM 2 10334 10334 JohnS 2 4548 10334 SamC 2 7872 10334 JillJ 3 4454 5687 CaseyB 3 1299 5687 JimJ 3 5687 5687 This feature will add basic windowing analytical functions including ROW_NUMBER, COUNT, MAX, MIN, SUM to MariaDB.
Message queues Storing a message queue as a database table can add the features of database storage to the message queue for example, durability against server or power failures, administration through wellunderstood SQL statements, and the ability to JOIN the message queue with other database tables to perform realtime analysis as messages move through the system. One possible method for implementing this capability in MariaDB would be to build a message queuing storage engine such as the Q4M storage engine, or similar capability.
Page: 3
w: www.mariadb.com e:
[email protected]
InfiniDB Storage Engine InfiniDB is an advanced database specially tuned to deliver high performance, real time analytics against structured data. It combines columnar access technology with parallel processing to let applications written to the familiar MySQL interface to perform Big Data analytics including adhoc BI queries and predictive analytics on massive data sets. By storing data in adjacent columns rather than adjacent rows, InfiniDB reduces the I/O load for analytics workloads. InfiniDB goes beyond the standard storage engine API in implementing its capabilities, including special processing pipelines and optimizer modifications. This feature would encompass the joint work with InfiniDB’s development team to integrate InfiniDB with MariaDB 10.
Hadoop/HDFS Storage Engine (maps HDFS access, interoperates with MariaDB) The Hadoop Distributed File System (HDFS) is the base storage system underlying Apache Hadoop. It is designed to store very large datasets reliably by replicating the data on multiple commodity hardware servers. HDFS is “rack aware” and feeds that data locality information to Hadoop to allow for efficient processing of these large datasets. HDFS is optimized for batch processing workloads such as MapReduce jobs executing under Hadoop. An HDFS storage engine for MariaDB will allow DBAs to create tables that distribute their data automatically on multiple, inexpensive servers. MariaDB will rely on a storage engine that is fault tolerant, designed to work with a large stream of data spread on many servers in parallel. Both storage and retrieval operations can be handled by compute engines that interoperate with the HDFS distributed layer.
HBase Storage Engine (maps HBase access, interoperates with MariaDB) Apache HBase is a nonrelational database that runs on top of Hadoop and HDFS. Modeled after Google’s BigTable database, it excels at realtime analytical queries involving very large sparse tables up to billions of rows and millions of columns, and leverages HDFS for high availability and
Page: 4
w: www.mariadb.com e:
[email protected]
integration with Hadoop, so that these analytical queries can be efficiently run using Hadoop’s distributed processing architecture. This feature will allow MariaDB to interoperate with HBase, typically as a source of the data to be analyzed, and as an engine underlying postanalysis reporting applications. The precise way that this interoperability would work is still under discussion but could potentially operate similar to the Cassandra storage engine available in MariaDB 10 today. An HBase storage engine would map HBase’s tables to MariaDB and allow read and update access to these tables using standard MariaDB relational operations.
MongoDB Interoperability MongoDB is a documentoriented database system that organizes data in JSON format, in dynamic schemas. Replication and sharding make MongoDB a database system that can be used for online systems that require high scalability and availability. This feature will enable interoperability between MariaDB and MongoDB. MariaDB users can read and write MongoDB documents through the pluggable storage engine architecture, while MongoDB users can continue to use their applications through their BSONbased protocol.
RocksDB/LevelDB Storage Engine (maps key-value byte arrays to MariaDB tables) Similar to the HBase feature described above, this feature will allow applications written to use MariaDB’s SQL interface to directly read and write RocksDB/LevelDB byte arrays. Like the Cassandra and proposed HBase engines, this storage engine will be targeted at applications which must interoperate with RocksDB and LevelDB and combine the lowlatency, simplystructured data in RocksDB/LevelDB with more complex structured data in MariaDB.
Page: 5