Principles of Distributed Database Systems: Spotlight on Newsql

Principles of Distributed Database Systems: spotlight on NewSQL

Patrick Valduriez Outline

• Distributed database systems • NoSQL • Polystores • Spotlight on NewSQL • Taxonomy of NewSQL systems • Current trends Principles of Distributed Database Systems

Tamer Özsu & Patrick Valduriez The Story of the Book

Relational databases. 1991 “In the following 10 years, centralized DBMSs would be an antique curiosity and most organizations would move towards distributed DBMSs.” M. Stonebraker (1988)

Advanced transaction models, 1999 query optimization, object data management, parallel DBMSs.

2011 Data replication, database clusters, web data integration, P2P, cloud.

2020 Blockchain, big data, data streaming, graph data analytics, NoSQL, NewSQL, polystores.

SBBD 2020 © P. Valduriez 2020 4 Distributed Database - User View 1991

SBBD 2020 © P. Valduriez 2020 5 Distributed Database - User View 2020

SBBD 2020 © P. Valduriez 2020 6 Distributed DBMS – Reality

User Query

DBMS User Application Software DBMS Software

DBMS Communication Software Subsystem

User DBMS User Application Software Query DBMS Software

User Query

SBBD 2020 © P. Valduriez 2020 7 Definitions

• A distributed database (DDB) is a collection of multiple, logically interrelated databases distributed over a computer network • WAN, LAN, cluster interconnect

• A distributed database system (distributed DBMS) is the software that manages the DDB and provides an access mechanism that makes this distribution transparent to the users

SBBD 2020 © P. Valduriez 2020 8 Promises of Distributed DBMSs

• Transparent management of distributed, fragmented, and replicated data • Declarative query language (SQL) • Improved reliability/availability through replication and distributed transactions • Strong ACID consistency • Failover and online recovery • Improved performance • Proximity of data to its points of use • Data-based parallelism • Query optimization • Easier and more economical system expansion • Elasticity in the cloud

SBBD 2020 © P. Valduriez 2020 9 Implementation Alternatives

& Polystores

SBBD 2020 © P. Valduriez 2020 10 Speed Up

• Ideal: linear speed-up • Linear increase of ideal performance by growing Perf. the components • For a fixed database size and load Components size

SBBD 2020 © P. Valduriez 2020 11 Speed-up Limits

• Hardware/software • As we add more resources, arbitration conflicts increase • E.g. Access to the bus by processors, latching, … • Application • Only part of a program can be parallelized • Recall: Amdahl's law that gives the maximum speed-up • Seq = fraction of code that cannot be parallelized

1 Examples Seq + 1 - Seq • Seq=0, NbProc=4 => speed-up= 4 NbProc • Seq=30%, NbProc=4 => speed-up= 2,1 • Seq=30%, NbProc=8 => speed-up= 2,5

SBBD 2020 © P. Valduriez 2020 12 Scalability

• Ideal: linear scale-up • Sustained performance for a linear increase of ideal database size and load Perf. • By proportional increase of components Components size, DB size & load

SBBD 2020 © P. Valduriez 2020 13 Vertical vs Horizontal Scaleup

• Typically in a computer cluster

Pn Pn Pn Pn

Scale-up

P2 P2 P2 P2

P1 P1 P1 P1

Scale-out

SBBD 2020 © P. Valduriez 2020 14 Query Parallelism

• Inter-query … • Different queries on the same Q1 Qn data R Rn • For concurrent queries 1 • Intra-query inter-operator Join • Different operations of the Select Select same query on different data • For complex queries R S • Intra-query intra-operator • The same operation on Select … Select different data S S • For large queries 1 n

SBBD 2020 © P. Valduriez 2020 15 New Computing Hierarchy

Scalability

P P … P P M M M M

P P Cluster M M • Massively parallel (MPP) • Message-based comm. P P • Thousands of nodes M M

P NUMA (Non Uniform Memory Architecture) M • Memory-based communication • Tens of processors Parallelism

SBBD 2020 © P. Valduriez 2020 16 Shared-disk Architecture

UI BI App … UI BI App … DB client DB client

SQL API

DB server DB server DB server

Query Txn Query Txn Query Txn … … … engine engine engine engine engine engine

SAN Shared + Simple admin. & Txn disk - Scalability (cache coherency) Best for OLTP - Cost of SAN

SBBD 2020 © P. Valduriez 2020 17 Shared-nothing Architecture

UI BI App … UI BI App … DB client DB client

SQL API

DB server DB server DB server

Query Txn Query Txn Query Txn … … … engine engine engine engine engine engine

Data Store Data Store Data Store

+ Scalability, cost Perfect match for OLAP and - Distributed updates big data (read intensive)

SBBD 2020 © P. Valduriez 2020 18 NoSQL Why NoSQL?

SBBD 2020 © P. Valduriez 2020 20 Why NoSQL?

• Trends • Big data • Unstructured data • Data interconnection • Hyperlinks, tags, blogs, etc. • Very high scalability • Data size, data rates, concurrent users, etc. • Limits of SQL systems (in fact RDBMSs) • Need for skilled DBA, tuning and well-defined schemas • Full SQL complex • Hard to make updates scalable • Parallel RDBMS use a shared-disk for OLTP, which is hard to scale

SBBD 2020 © P. Valduriez 2020 21 NoSQL (Not Only SQL) Definition

• Specific DBMS, typically for web-based data • Specialized data model • Key-value, table, document, graph • Trade relational DBMS properties • Full SQL, ACID transactions, data independence • For • Simplicity (schema, basic API) • Horizontal scalability and performance • Flexibility for the programmer (integration with programming language)

SBBD 2020 © P. Valduriez 2020 22 NoSQL Approaches

• Characterized by the data model, in increasing order of complexity: 1. Key-value: DynamoDB, RockDB, Redis 2. Tabular: Hbase, Bigtable, Cassandra 3. Document (JSON): MongoDB, Coubase, CouchDB, Expresso 4. Graph: Neo4J, AllegroGraph, MarkLogic, RedisGraph 5. Multimodel: OrientDB, ArangoDB

• What about object DBMSs or XML DBMSs? • Were there much before NoSQL • Sometimes presented as NoSQL • But no horizontal scalability

SBBD 2020 © P. Valduriez 2020 23 Key-value Store Distributed Architecture

UI App … UI App … KV client KV client

KV API

KV store

KV engine … KV engine … KV engine …

DS client DS client DS client

Data store

DS server DS server DS server

SBBD 2020 © P. Valduriez 2020 24 Main NoSQL Systems

Vendor Product Category Comments Amazon DynamoDB KV Proprietary Apache Cassandra KV Open source, Orig. Facebook Accumulo Tabular Open source, Orig. NSA Couchbase Couchbase KV, document Origin: MemBase Google Bigtable Tabular Proprietary, patents FaceBook RocksDB KV Open source Hadoop Hbase Tabular Open source, Orig. Yahoo LinkedIn Voldemort KV Open source Expresso Document ACID transactions 10gen MongoDB Document Open source Oracle NoSQL KV Based on BerkeleyDB OrientDB OrientDB Graph, KV, document Open source, ACID transactions Neo4J.org Neo4J Graph Open source, ACID transactions Ubuntu CouchDB Document Open source

SBBD 2020 © P. Valduriez 2020 25 Polystores

Query Q

Query Engine

Q1 Q2 Q3

Wrapper1 Wrapper2 Wrapper3

Q1' Q2' Q3'

SQL NoSQL HDFS Polystores*

• Also called Multistores • Provide integrated access to multiple cloud data stores such as NoSQL, HDFS and RDBMS • Great for integrating structured (relational) data and big data • A major area of research & development

*Michael Stonebraker.The Case for Polystores. ACM blog, July 2015.

SBBD 2020 © P. Valduriez 2020 27 Differences with Federated Databases

• Multidatabase systems • A few databases (e.g. less than 10) • Corporate DBs • Powerful queries (with updates and transactions) • Web data integration systems • Many data sources (e.g. 1000’s) • DBs or files behind a web server • Simple queries (read-only) • In the cloud, more opportunities for an efficient architecture • Less restriction to where mediator and wrapper components need be installed

SBBD 2020 © P. Valduriez 2020 28 Classification of Polystores*

• We divide polystores based on the level of coupling with the underlying data stores • Loosely-coupled • Tightly-coupled • Hybrid

*C. Bondiombouy, P. Valduriez. Query Processing in Cloud Multistore Systems: an overview. Int. Journal of Cloud Computing, 5(4): 309-346, 2016.

SBBD 2020 © P. Valduriez 2020 29 Loosely-Coupled Polystores

• Reminiscent of multidatabase systems • Mediator-wrapper architecture • Deal with autonomous data stores • One common interface to all data stores • Common interface translated to local API

• Examples • BigIntegrator (Uppsala University) • Forward (UC San Diego) • QoX (HP Labs)

SBBD 2020 © P. Valduriez 2020 30 Tightly-Coupled Polystores

• Use the local interfaces of the data stores • Use a single query language for data integration in the query processor • Allow data movement across data stores • Optimize queries using materialized views or indexes • Examples • Polybase (Microsoft Research, Madison) • HadoopDB (Yale Univ. & Brown Univ.) • Estocada (Inria)

SBBD 2020 © P. Valduriez 2020 31 Hybrid Polystores

• Support data source autonomy as in loosely- coupled systems • Exploit the local data source interface as in tightly- coupled systems • Examples • SparkSQL (Databricks & UC Berkeley) • BigDaWG (MIT, U. Chicago & Intel) • CloudMdsQL (Inria & LeanXcale)

SBBD 2020 © P. Valduriez 2020 32 Polyglot Query Example

• A query in CloudMdsQL* that integrates data from • DB1 – relational (RDB) • DB2 – document (MongoDB) • Expressed as a Native subquery

p x, z

/* Integration */ SELECT T1.x, T2.z FROM T1 JOIN T2 @CloudMdsQL ON T1.x = T2.x

/* SQL sub-query */ p x, y T1(x int, y int)@DB1 = ( SELECT x, y FROM A ) T1@DB1 A (RDB) /* Native sub-query */ T2(x int, z string)@DB2 = {* N x, z db.B.find( {$lt: {x, 10}}, {x:1, z:1, _id:0} ) *} T2@DB2 (MongoDB)

*B. Kolev, C. Bondiombouy, P. Valduriez, R. Jiménez-Peris, R. Pau, J. Pereira. The CloudMdsQL Multistore System. SIGMOD 2016. SBBD 2020 © P. Valduriez 2020 33 Comparisons: functionality

Polystore Objective Data model Query language Data stores Loosely-coupled BigIntegrator Querying relational Relational SQL-like BigTable,RDBMS and cloud data Forward Unyfing relational JSON-based SQL++ RDBMS, NoSQL and NoSQL QoX Analytic data flows Graph XML based RDBMS, ETL

Tightly-coupled Polybase Querying Hadoop Relational SQL HDFS, RDBMS from RDBMS HadoopDB Querying RDBMS Relational SQL-live (HiveQL) HDFS, RDBMS from Hadoop Estocada Self-tuning No common model Native QL RDBMS, NoSQL

Hybrid SparkSQL SQL on top of Spark Nested SQL-like HDFS, RDBMS BigDAWG Unifying relational No common model Island query RDBMS, NoSQL, and NoSQL languages Array DBMS, DSMSs CloudMdsQL Querying relational JSON-based SQL-like with native RDBMS, NoSQL, and NoSQL subqueries HDFS

SBBD 2020 © P. Valduriez 2020 34 Comparisons: implementation techniques

Polystore Objective Data model Query language Data stores

Loosely-coupled

BigIntegrator Importer,absorber, LAV Access filters Heuristics finalizer Forward Query processor GAV Data store capabilities Cost-based

QoX Dataflow engine No Data/function shipping Cost-based

Tightly-coupled

Polybase HDFS bridge GAV Query splitting Cost-based

HadoopDB SMS planer, db GAV Query splitting Heuristics conector Estocada Storage advisor Materialzed views Query rewriting Cost-based

Hybrid

SparkSQL Dataframes Nested In-memory caching Cost-based

BigDAWG Island query GAV within islands Function/datashipping Heuristics

CloudMdsQL Query planner No Bind join Cost-based

SBBD 2020 © P. Valduriez 2020 35 Spotlight on NewSQL Why NewSQL?

• Pros NoSQL • Scalability • Often by relaxing strong consistency • Performance • Practical APIs for programming • Pros Relational • Strong consistency • Transactions • Standard SQL • Makes it easy for tool vendors (BI, analytics, …) • NewSQL = NoSQL/relational hybrid

SBBD 2020 © P. Valduriez 2020 37 Transaction vs. Analytical Processing

Operational DB Data warehouse/lake Transactions Analytics

OLTP OLAP ETL/ELT

• Problems • ETL/ELT development cost up to 75% of analytics • Analytical queries on obsolete data • Leads to miss business opportunities, e.g., proximity marketing, real-time pricing, risk monitoring, etc.

SBBD 2020 © P. Valduriez 2020 38 HTAP*: blending OLTP & OLAP

Analytical queries on operational data

OLTP HTAP OLAP

OLT OLAP P

• Advantages • Cutting cost of business analytics by up to 75% • Simpler architecture: no more ETLs/ELTs • Real-time analytical queries on current data

*Gartner, 2015 SBBD 2020 © P. Valduriez 2020 39 Use Case: Google AdWords • Application to produce sponsored links as results of search engine • Revenue: $50 billion/year • Use of an auction system • Pure competition between suppliers to gain access to consumers, or consumer models (the probability of responding to the ad), and determine the right price offer (maximum cost-per-click (CPC) bid) • The AdWords database with Google Spanner • 30 billion search queries per month • 1 billion historical search events • Hundreds of Terabytes

SBBD 2020 © P. Valduriez 2020 40 Use Case: Network Monitoring

• NoSQL to store data at high rates • Data is put in a data store able to ingest data at very high rates • E.g. network performance monitoring information about packets sniffed in the network • Problems • Because NoSQL is used to store the data, BI tools cannot be used for real time data • Data needs to be aggregated and exported periodically to an SQL database to query the data with BI tools

SBBD 2020 © P. Valduriez 2020 41 Use Case: Oil & Gas

• Context: drilling oil in a given location • Objective: detect ASAP that the drilling prospection will fail • Save millions of $ by preventing useless drilling • Requirements • Efficient ingestion of real-time data from drillers • With transactions to guarantee data consistency • Real time analytics of all the data produced by the drillers • Problem • Transactions and real-time analytics on driller data

SBBD 2020 © P. Valduriez 2020 42 HTAP and Big Data

• Challenges • Scaling out transactions • Millions of transactions per second • Mixed OLTP/OLAP workloads on big data • Big data ingestion from remote data sources • Ingest data fast, query it with SQL • Polystore capabilities • To access HDFS, NoSQL and SQL data sources

SBBD 2020 © P. Valduriez 2020 43 Main Techniques

• From SQL • Parallel, in-memory query processing • Fault-tolerance, failover and synchronous replication • Streaming • From NoSQL • Key-value storage and access • JSON data support • Horizontal and vertical data partitioning (sharding) • New • Scalable transaction management • Polyglot language and polystore • Access to SQL, NoSQL and HDFS data stores

SBBD 2020 © P. Valduriez 2020 44 NewSQL Distributed Architecture

UI BI App … UI BI App … DB client DB client SQL & KV APIs Query engine

QE … QE … QE … QE …

KV client KV client KV client KV client

Txn engine Txn Txn Txn

KV store

KVE KVE KVE

DS server DS server DS server

SBBD 2020 © P. Valduriez 2020 45 LeanXcale Architecture

OLAP App App Application JDBC Drv JDBC Drv

Elastic Drv Elastic Drv

Query Engine QE QE QE QE KVClient KVClient KVClient KVClient

Txn Engine Txn Txn Txn

KV Store KV Master (KiVi) Server KV Data KV Data KV Data independent scale out scale independent Server Server Server out scale independent

SBBD 2020 © P. Valduriez 2020 46 LeanXcale Scalable Transaction Processing*

Processes & Traditional approach commits transactions Single-node bottleneck in parallel

Provides a consistent vs view Time Time

* R. Jimenez-Peris, M. Patiño-Martinez. System and method for highly scalable decentralized and low contention transactional processing. Priority date: 11th Nov. 2011. European Patent #EP2780832, US Patent #US9,760,597. SBBD 2020 © P. Valduriez 2020 47 Traditional Approach

Centralized Transaction Manager

Atomicity Isolation

Central TM

Consistency Durability

Single-node bottleneck

SBBD 2020 © P. Valduriez 2020 48 Traditional Approach

Centralized Transaction Manager

Atomicity Isolation Writes Central TM

Isolation Durability Reads

Single-node bottleneck

SBBD 2020 © P. Valduriez 2020 49 LeanXcale: Scaling ACID Properties

Atomicity Isolation Atomicity Atomicity Writes

Isolation Durability Reads

SBBD 2020 © P. Valduriez 2020 50 LeanXcale Scaling ACID Properties

Local TMs Conflict managers Atomicity Isolation Writes Isolation Reads Durability

Snapshot Commit server sequencer Loggers

SBBD 2020 © P. Valduriez 2020 51 LeanXcale Transaction Mgt Principles

• Separation of commit from the visibility of committed data • Proactive pre-assignment of commit timestamps to committing transactions • Detection and resolution of conflicts before commit • Transactions can commit in parallel because: • They do not conflict • They have their commit timestamp already assigned that will determine their serialization order • Visibility is regulated separately to guarantee the reading of fully consistent states

SBBD 2020 © P. Valduriez 2020 52 Transactional Life Cycle: start

Snapshot snapshot Server Current consistent

Get start TS The local txn mng gets the “start TS” from the snapshot server.

Local Txn Manager

The transaction will read the state as of “start TS”. Write-write conflicts are detected Conflict by conflict managers on the fly. Manager

Run on start TS snapshot

Get start TS

Local Txn Manager

The local transaction manager orchestrates the commit.

Commit

Run on start TS snapshot

Get start TS

Local Txn Manager

Get Public Report Log Commit TS Updates Snaps Serv

Commit TS Writeset Writeset Commit TS

Snapshot Commit Logger Data Store Sequencer Server

Sequence of commit timestamps received by the Snapshot Server

11 15 TIMESTAMP 12 TIMESTAMP 14 TIMESTAMP 13 TIMESTAMP TIMESTAMP

11 15 12 14 13

Time

Evolution of the current snapshot at the Snapshot Server (starting at 10)

11 11 TIMESTAMP 12 TIMESTAMP 12 TIMESTAMP 15 TIMESTAMP TIMESTAMP

10 11 11 12 12 15

2.35 Million TPS

• Without data manager/logging to see how much TP throughput can be attained • Based on a micro-benchmark to stress the TM

OLAP Application App App JDBC Drv JDBC Drv

Query Engine

QE QE QE QE DataLake API Wrapper Wrapper Wrapper Wrapper

DSClient DSClient DSClient DSClient External Data Store DS DS DS independent scale out scale independent

Shard Shard Shard out scale independent

• Workers access directly data shards through wrappers • DataLake API: get list of shards; assign shard to worker

• Objectives • Intra-operator parallelism • Apply parallel algorithms • Exploit data sharding in data stores • Access data shards (partitions) in parallel • Polyglot capabilities • Optimization • Select pushdown, bindjoin, etc. • Solution • The LeanXcale Distributed Query Engine (DQE) • … with CloudMdsQL polyglot extensions

• *B. Kolev, O. Levchenko, E. Pacitti, P. Valduriez, R. Vilaça, R. Gonçalves, R. Jiménez-Peris, P. Kranas. Parallel Polyglot Query Processing on Heterogeneous Cloud Data Stores with LeanXcale. IEEE Big Data, 2018.

LineItem( L_ORDERKEY int, … )@mongo = {* return db.lineitem.findSharded( {l_quantity: {$lt: 5}} ); *} App SELECT count(*) FROM LineItem L, Orders O WHERE L_ORDERKEY = O_ORDERKEY Q1

W1 W2 Wn

WR1 WR2 WRn listShards()

Mongo db.lineitem.find(…) Router Mongo Mongo Mongo KVDS KVDS KVDS Shard Shard Shard

SQL NoSQL NewSQL Data model Relational Specialized: KV, Relational document, graph Query SQL Key-value API SQL language New query language Key-value API Scalability Only for high-end By design (SN cluster) By design (SN cluster) (Teradata, Exadata) Consistency Strong Limited Strong

Big data External tables Integration within Integration within Hadoop ecosystem (HDFS) Hadoop Workload OLAP or OLTP OLTP OLAP, OLTP, HTAP

Polystore SQL or HDFS data SQL or HDFS data SQL, NoSQL, HDFS data sources sources sources

• Why a taxonomy? • Different flavors of NewSQL systems, for different workloads • Main dimensions • Transaction model • Scalability • Storage engine • Query parallelism • Polystore

• Ad hoc • ACID properties partially provided • Isolation and atomicity not guaranteed • A priori-knowledge • Requires to know which rows will be read and written before executing the transaction • ACID • ACID properties fully provided • Isolation levels well such as serializability or snapshot isolation

• Bounded scalability • Centralized transaction manager: can scale out as far as it does not get overloaded • Logarithmic scalability • ROWA replication: can scale out the read workload • Cache consistency: requires synchronization of the updated blocks • 2PC: to deal with multi-node transactions • Linear scalability • Linear scale-out in shared-nothing cluster

• Relational • Support of algebraic operators, such as predicate filtering, aggregation, grouping and sorting • Read/write, key-value • Capability of reading and writing individual data items • May support range queries

• Inter-query parallelism • Multiple queries can be processed in parallel • Intra-query parallelism • Inter-operator parallelism: different operators in the query plan can be processed on different nodes, but a single operator runs on a single node. • Intra-operator parallelism: the same operator can run across multiple nodes

• SQL+key-value • Use a key-value data store to scale data management, e.g. Splicemachine, EsgynDB and LeanXcale. • HTAP • Systems that combine OLTP and OLAP, e.g. SAP Hana, EsgynDB and LeanXcale. • In memory • Optimized for processing the workload fully in main memory, e.g. SAP Hana and MemSQL • New transaction managers • New, scalable approach to transaction management, e.g. Spanner and LeanXcale

Vendor Product Objective Comment

Google Spanner OLTP Google cloud distributed database service. Used by F1 for the AdWords app.

LeanXcale LeanXcale HTAP HTAP DBMS with fast insertion, fast aggregation over real-time data and polystore capability SAP Hana HTAP The HTAP pioneer, based on in-memory, column store MemSQL Inc. MemSQL HTAP In-memory, column and row store, MySQL compatible Esgyn EsgynDB HTAP Apache Trafodion for OLTP, Hadoop for OLAP NuoDB NuoDB OLTP Distributed SQL DBMS with P2P architecture

Splice Machine Splice Machine HTAP HBase as storage engine, Derby as OLTP query engine and SparkQL as OLAP query engine

• Globally distributed database service in Google Cloud Synchronous replication between data centers with Paxos • Load balancing between Spanner servers • Favor the geographical zone of the client • Different levels of consistency • ACID transactions • Snapshot (read only) transactions • Based on data versioning • Optimistic transactions (read without locking, then write) • Validation phase to detect conflicts and abort conflicting transactions • Two interfaces • SQL • NoSQL key-value interface • Hierarchical relational storage • Precomputed joins

• SQL DBMS • Access from a JDBC driver • Polyglot language with JSON support (pending) • SQL processing based on Apache Calcite • Key-value store (KiVi) • Fast, parallel data ingestion • Online aggregation • Multistore access: HDFS, MongoDB, Hbase, … • OLAP parallel processing (Query Engine) • Intra-query intra-operator parallelism • Ultra-scalable transaction processing (patented) • SQL isolation level: snapshot • Timestamp-based ordering and conflict detection just before commit • Massive parallel commits of transactions

System Trans. Scalability Storage Query Polystore model parallelism Spanner ACID Linear Key-value Inter-query LeanXcale ACID Linear Relational Intra-query SQL, NoSQL, key-value Intra-operator HDFS Hana ACID 2PC Relational Intra-query HDFS Columnar Intra-operator MemSQL Ad hoc Log Relational Inter-query HDFS (Spark connector) EsgynDB ACID 2PC Key-value Intra-query HDFS Intra-operator NuoDB ACID Log Read/write Inter-query HDFS

Splice ACID Centralized Key-value Intra-query HBase, HDFS Machine TM Intra-operator

• NewSQL is the hottest trend in database management • Scales out but without renouncing to SQL and ACID transactions • NewSQL has different roots leading to different flavours • The taxonomy enables comparing NewSQL systems as well as SQL systems

• NewSQL is the database kind growing faster in the market • 33% CAGR, according to 451 Research market analyst in their Total Data Report • It will become soon an important player in the database landscape • Early adopters of NewSQL will become leaders in database management • Faster database development with lower costs in engineering and lower needs in talent

SBBD 2020 © P. Valduriez 2020 76 Many Research Opportunities • Polyglot SQL • SQL++ compatibility • JSON indexing within columns • Polystore • Cost model, including histograms • Materialized views • Streaming and CEP • Query language combining streaming and access to the database, e.g., through SQL or KiVi API • Scientific applications • NewSQL/HTAP + scientific workflows • Analytics and ML • Spark ML using updatable RDDs, instead of redoing RDDs periodically, • Incremental ML algorithms based on online aggregation, scalable updates and OLAP queries • Benchmarking • Defining NewSQL/HTAP benchmarks and compare systems • Profiling to find new optimizations

1. T. Özsu, P. Valduriez. Principles of Distributed Database Systems. Fourth Edition. Springer, 2020. 2. P. Valduriez, R. Jimenez-Peris. NewSQL : principles, systems and current trends. IEEE BigData, Los Angeles, December 2019. 3. R. Jimenez-Peris, M. Patiño-Martinez. System and method for highly scalable decentralized and low contention transactional processing. Filed at USPTO: 2011. European Patent #EP2780832, US Patent #US9,760,597. 4. C. Bondiombouy, P. Valduriez. Query Processing in Cloud Multistore Systems: an overview. Int. Journal of Cloud Computing, 5(4): 309-346, 2016 5. B. Kolev, O. Levchenko, E. Pacitti, P. Valduriez, R. Vilaça, R. Gonçalves, R. Jiménez- Peris, P. Kranas. Parallel Polyglot Query Processing on Heterogeneous Cloud Data Stores with LeanXcale. IEEE BigData, 2018. 6. B. Kolev, P. Valduriez, C. Bondiombouy, R. Jiménez-Peris, R. Pau, J. Pereira. CloudMdsQL: Querying Heterogeneous Cloud Data Stores with a Common Language. Distributed and Parallel Databases, 34(4): 463-503, 2016. 7. B. Kolev, C. Bondiombouy, P.Valduriez, R. Jiménez-Peris, R. Pau, J. Pereira. The CloudMdsQL Multistore System. ACM SIGMOD, 2016. 8. M. Stonebraker.The Case for Polystores. ACM blog, July 2015.