MariaDB Server 10.2 introduces Common Table Expressions (CTEs) that allows recursive SQL, that replaces the CONNECT BY syntax of older database systems. Here, we take a look at CTEs, how they relate to CONNECT BY and what these can be used for.
Join MariaDB ColumnStore Use Cases Webinar on March 23, 2017 10 a.m. PT
MariaDB ColumnStore provides a complete solution for automated high availability of a cluster. On the data processing side:
Multiple front-end or User Module (UM) servers can be deployed to provide failover on SQL processing.
Multiple back-end or Performance Module (PM) servers can be deployed to provide failover on distributed data processing.
Due to the shared-nothing data processing architecture, ColumnStore requires the storage tier to deliver high availability for a complete solution. In this blog, I intend to provide some clarity and direction on the architecture and choices available.
Authored by Shree Nair, Product Manager, Webyog
We are very excited to sponsor MariaDB’s inaugural user conference, M|17! It’s a great opportunity to introduce Webyog to the MariaDB community, and demonstrate the close collaboration between Webyog and MariaDB – we work together to provide powerful administrative tools for the fastest growing open source database.
MariaDB 10.2.4 has fantastic new features that perfectly match Replication Manager's ultimate goals: transparent automated failover on MariaDB master slave architecture (with as little as possible lost in transaction:)). We are going to explore those new features and how Replication Manager uses them for your benefit!
MariaDB 10.2 includes a number of JSON functions, but why would you use JSON as aren't JSON and SQL data contradictory? This blog shows you why this isn't so and how these JSON functions can be a very useful addition to MariaDB and how MariaDB 10.2 has some other tricks that make JSON with MariaDB even more useful.
MariaDB ColumnStore is a massively parallel scale out columnar database. Data loading and modification behaves somewhat differently from how a row based engine works. This article outlines the options available and how these affect performance.
The beta version of the upcoming MaxScale 2.1 has been released. This new release takes MaxScale to the next level by introducing functionality that makes it possible to configure parts of MaxScale’s configuration at runtime.
The 2.1 version of MaxScale introduced a new concept of module commands. This blog post takes a look at what they are, why they were implemented and where you see them when you use MaxScale.
Performance has been a central goal of MariaDB MaxScale’s architecture from the start. Core elements in the drive for performance is the use of asynchronous I/O and Linux’ epoll. With a fixed set of worker threads, whose amount is selected to correspond to the number of available cores, each thread should either be working or be idle, but never be waiting for I/O. This should provide good performance that scales well with the number of available CPUs. However, benchmarking revealed that was not entirely the case. The performance of MaxScale did not continuously increase as more worker threads were added, but after a certain point the performance would actually start to decrease.
When we started working on MariaDB MaxScale 2.1 we decided to investigate what the actual cause for that behaviour was and to make modifications in order to improve the situation.
We are happy to announce that MariaDB MaxScale 2.1.0 beta is released today. MariaDB MaxScale is the next generation database proxy for MariaDB. Beta is an important time in our release and we encourage you to download this release today!