This article is the first in a series about Squid Solutions’ technology. French version available here.

Introduction

Way back in 2005, we chose to develop new technology to simplify analytics in massive datawarehouses. Our approach, described in the series of upcoming articles, is now called « in-database, » although this term did not exist at the time. Basically, we use high performance Massively Parallel Processing (MPP) databases to execute in-database analytics. Let’s start by describing what we see in MPP databases.

Shared-Nothing Architecture or MPP (Massively Parallel Processing)

Shared-nothing corresponds to a distributed architecture, both in terms of storage and processing. The idea is to split data automatically between a collection of segments, each cluster of segments being managed independently by a processing node and all nodes communicating via a dedicated network.

An SQL processor directs the execution of queries between the different nodes. Each node processes the query locally. The results are then concatenated, either by the processor, or directly by the network layer.

The distribution of data among different segments/nodes is critical for the performance of the system. Unlike a conventional database, which also uses data partitioning techniques to maintain good performance levels, the secret of the performance of an MPP system is to use a distribution  key that is independent from data logic.

For instance, a transactional processing system would partition the transactions month per month in order to filter the relevant segments called in a query and thus reduce data loading time. On the other hand, the MPP approach favors the use of opaque hash key that allows a distribution data between a variable number of segments.

The first advantage is scalability of the system when data volumes increase: if there are n segments, each segment stores only 1 / n percent of the data.

The second advantage is to greatly simplify system administration since it is generally not necessary to explicitly partition data (even though most current MPP systems also support partitioning on top of the native distribution mechanism). The addition of segments is usually transparent to the user. The system is able to redistribute all data automatically.

This mechanism of data redistribution can also be called during a join if the distribution keys of the concerned tables are not compatible with each other. As such, the choice of a distribution key is a major driver in the optimization of an MPP system.

(To be continued …)

Cet article est le premier d’une série visant à décrire la technologie de Squid Solutions. Click here for English.

Introduction

Nous avons fait le choix en 2005 de développer une nouvelle technologie pour rendre plus agiles les analyses dans les entrepôts massifs de données. Notre approche, décrite dans la série d’articles à venir, s’appelle « in-database », même si ce terme n’existait pas à l’époque. La démarche part : (1) de l’exploitation des bases haute performance dites Massivement Parallèles (MPP), sur lesquelles nous réalisons (2) des analyses « in-database », grâce à la technologie décrite en (3).

Architecture Shared Nothing ou MPP (Massively Parallel Processing)

Il s’agit d’une architecture de base de donnée distribuée, tant au niveau du stockage que du processing. Le principe est de partager automatiquement les données entre une collection de segments, une grappe de segments étant gérée de façon autonome par un noeud de calcul et tous les noeuds communiquent via un réseau dédié.

Un processeur SQL ordonne l’exécution des requêtes entre les différents noeuds qui traitent localement chaque requête, puis les résultats de chaque noeud sont concaténés, soit au niveau du processeur, soit directement par la couche réseau.

La distribution des données entre les différents segments/noeuds est critique pour les bonnes performances du système. A la différence d’un système de base de données classique qui utilise également des techniques de partitionnement des données pour maintenir de bonnes performances, le secret de la performance d’un système MPP réside dans l’utilisation d’une clé de distribution indépendante de la logique de donnée. Là où un système transactionnel utilisera par exemple un partitionnement par mois de la transaction pour pouvoir intelligemment filtrer les segments utiles dans une requêtes et ainsi diviser les besoins de chargement, l’approche MPP privilégie l’utilisation de clé de hachage opaque qui permet une distribution des données entre un nombre variable de segments.

L’avantage premier est une grande évolutivité du système lorsque les volumes de données augmentent:  s’il y a n segments, chaque segment ne stocke que 1/n pourcent des données.

Le second avantage est de grandement simplifier l’administration du système puisqu’il n’est généralement pas necessaire de recourir à un partitionnement explicite (la plupart des systèmes MPP actuels supportent également des fonctions de partitionnement classiques au dessus du mécanisme natif de distribution, les partitions étant elles-mêmes distribuées).

L’ajout de segments est généralement transparent pour l’utilisateur et le système est capable de redistribuer l’ensemble des données automatiquement. Ce mécanisme de redistribution des données peut également intervenir lors d’une jointure si les clés de distribution des tables concernées ne sont pas compatibles entre elles – de fait le choix de la clé de distribution est un des levier majeur dans l’optimisation d’un système MPP.

(to be continued…)