Après le mise à jour hebdomadaire apache refuse de démarrer ...
Un examen des logs (systemd ne donne, comme d'habitude aucun renseignement utile !), je vois que c'est "modsec2" qui se  plaint d'un problème de version de la bibliothèque "pcre" :

<span style="font-family:Arial,Helvetica,sans-serif;font-size:18px;">

J'ai voulu faire un dernier test qui représente un gros travail toujours à partir de la même table qui atteint maintenant 542 975 185 rangs ce qui représente un bon test.

J'ai voulu chercher les ports TCP les plus attaqués en sélectionnant les connections TCP qui ont fourni un retour de 0 octets, le SQL est donc :

Cet ordre SQL est très simple et le résultat est plus que spectaculaire, le passage "Clickhouse" a été réalisé avec l'inerface compatible Mysql.

L'ordre est très simple :
select count(*),max(LAST_SWITCHED),max(FIRST_SWITCHED) from flowsv4;

1) Résultats Clickhouse.

Ce test montre assez bien la vitesse de Clickhouse.

La table "origine" est stockée sur une machine distante, les accès se font donc à travers le réseau.
Pour MariaDB utilisation de Federatedx pour accès à la base distante, pour Clickhouse la structure équivalente de base Mysql distante avec une syntaxe de création assez semblable à celle utilisée par MariaDB.
Résultats :

Page en cours de réalisation.

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.

Je conserve les traces (voir NTOPNG) de toutes les connexions et je me suis demandé quelles étaient les caractéristiques de  ceux qui passant leur vie à scanner le web.
J'ai donc fait un extrait les données : nombre de hits; nombre de ports différents, date du premier hit et date du dernier hit pour les entrées n'ayant pas donné lieu à réponse (port fermé).
Le résultat est comporte quelques chiffres surprenants :

Un petit ennui : les fichiers "binlog" ne sont plus supprimés malgré la présence du paramètre adéquat : expire_logs_days        = 3
Ce phénomène m'a été montré par l'augmentation anormale de la taille de la partition qui supporte ces fichiers et son approche des 100% fatidiques.
Après quelques recherches sur Internet je ne trouve rien à ce sujet.