Syntaxe Sql

Syntaxe Sql jpp

Il est possible, avec un client Mysql/MariaDB standard, de se connecter à Clickhouse (port 9004) et d'utiliser des ordres SQL avec la syntaxe propre à Mysql/MariaDB. 
Il existe aussi une possibilité d'utiliser un client Postgresl en se connectant à Clickhouse (port 9005), je n'ai pas encore testé cette entrée.

On peut par exemple créer un utilisateur avec : 
create user lechef identified by 'le_beau_password'; 
grant all on *.* to lechef; 
Ce que je préfère nettement au "bidouillage" de fichiers XML.

Par exemple pour charger ma "grosse" table depuis une base MariaDB dans Clickhouse (dans une machine virtuelle) j'ai créé dans Clickhouse un "serveur" connecté à la base située sur la machine "physique" à l'aide d'un ordre "simple" (du même style que pour l'option "federatedx" disponible dans MariaDB :

CREATE DATABASE test_maria 
  ENGINE = MySQL('192.168.2.7:3306', 
  'local_ntopng', 
  'test', 'test') 
  SETTINGS read_write_timeout=10000, connect_timeout=10;

Dans la base "physique" la table est au standard Mysql et on peut donc y accéder à travers cette base "test_maria" par cette sorte de "dblink". L'ordre de chargement des données est très simple :

insert into local_ntopng.flowsv4 
    select * from test_maria.flowsv4;

select min(idx),max(idx),count(distinct idx) from local_ntopng.flowsv4;

Le temps d'exécution est assez important car il faut passer par :

  • Mariadb sur la machine physique
  • Le réseau entre les deux machines
  • Et enfin Clickhouse à travers le fameux dblink.

Comme déjà remarqué la consommation d'IO disques de Clickhouse est très irrégulière et a oscillé entre 0 et 240Mo/seconde. Le lien réseau est toujours resté au dessus de 100MO/sec avec des pointes à près de 200MO/sec (c'est en local sur la même machine physique). 
Les résultats : 
Query OK, 505751818 rows affected (36 min 54.958 sec) 
+----------+-----------+----------------+ 
| min(idx) | max(idx)  | uniqExact(idx) | 
+----------+-----------+----------------+ 
|        1 | 505785066 |      505751818 | 
+----------+-----------+----------------+ 
1 row in set (31.284 sec)

Ce qui n'est pas mauvais et simple pour ceux qui connaissent un peu le SQL.

Syntaxe SQL : suite

Syntaxe SQL : suite jpp

J'ai eu besoin de modifier la notion "Nullable" d'une colonne, or il semble que ce soit impossible. 
La table que j'ai utilisée pour les premiers tests comporte toutes les colonnes en Nullable ce qui peut gêner certains types d' opérations. 
J'ai donc initialisé une nouvelle table avec les colonnes adéquates en "not null" et j'y ai inséré les lignes de l'ancienne table. 
Au passage une remarque sur la syntaxe : 
- Une colonne "nullable" se déclare sous la forme "Nullable(String)" 
- La même en "not null" se déclare sous la forme plus classique "String not null".

La recopie est une opération simple 

insert into table1 select * from table2;

J'ai donc lancé cet ordre en direct sur cette table de 540 Millions de rangs et le résultat est :

Elapsed: 817.372 sec. Processed 524.04 million rows, 200.88 GB 
(641.13 thousand rows/s., 245.76 MB/s.)

Soit quand même plus de 13 minutes  ...

CPU > 90 .. 130%
IO  60 .. 370 Mo/seconde la moitié du temps en lecture, l'autre moitié en écriture.

Pour se débarrasser de l'ancienne table :

- sudo touch /var/lib/clickhouse/flags/force_drop_table
- sudo chmod 666 /var/lib/clickhouse/flags/force_drop_table

- Puis, enfin dans le shell Clickhouse. 

"drop ancienne_table"

 

Null ou pas Null

Null ou pas Null jpp

J'ai eu besoin de modifier la notion "Nullable" d'une colonne car il est impossible d'utiliser "GROUP BY" sur une colonne "Nullable", or il semble que ce soit impossible avec une commande "ALTER" standard. 
J'ai donc initialisé une nouvelle table avec les colonnes adéquates en "not null" et j'y ai inséré les lignes de l'ancienne table. 
Au passage une remarque sur la syntaxe (pas "standard" ?) :

  1. - Une colonne "nullable" se déclare sous la forme "Nullable(String)"
  2. - La même en "not null" se déclare sous la forme plus classique "String not null".

La notion de longueur de chaîne de caractères est ici inconnue.

La recopie est une opération simple : 

insert into table1 select * from table2;

J'ai donc lancé cet ordre en direct sur cette table de plus de 520 Millions de rangs et le résultat est :

Elapsed: 817.372 sec. Processed 524.04 million rows, 200.88 GB 
(641.13 thousand rows/s., 245.76 MB/s.)

Soit malgré tout plus de 13 minutes et demi ... mais pour autant de millions de lignes c'est une bonne performance.  
Rappel :  
la machine dispose de 28Go de RAM et de 4 VCPU ainsi que l'accès à un espace de stockage sur une paire de SSD en Raid 1. 
Avec des disques plus rapides, par exemple 4 NVME en Raid 10 on atteindrait des sommets. Avec un tel système disques j'ai vu des vitesses d'écriture à plus de 1,5Go/sec, hélas ce n'est pas à la portée de toutes les bourses et même impossible sur la majorité des cartes mères "amateurs". 
Au cours de cette copie j'ai pu constater :

CPU de 90 .. 130%
IO  60 .. 370 Mo/seconde la moitié du temps en lecture, l'autre moitié en écriture.

Pour se débarrasser de l'ancienne table :

  1.  sudo touch /var/lib/clickhouse/flags/force_drop_table
  2.  sudo chmod 666 /var/lib/clickhouse/flags/force_drop_table
  3.  Puis, enfin, le "drop ancienne_table" dans le shell Clickhouse.

Il n'est pas si facile que cela de se débarrasser d'une table encombrante...