MariaDB 10.1 Prospective Feature Descriptions

18 downloads 140 Views 203KB Size Report
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  well­understood SQL statements, and the ability to JOIN the message queue with other database  tables to perform real­time 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 ad­hoc  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 non­relational database that runs on top of Hadoop and HDFS. Modeled after  Google’s BigTable database, it excels at real­time 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 post­analysis 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 document­oriented 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 BSON­based 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 low­latency, simply­structured data  in RocksDB/LevelDB with more complex structured data in MariaDB.   

  Page: 5