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...