›
Charte des bonnes pratiques sur PMB Community et PMB Community Forums

utf8mb4

pullrougepullrouge
dans Installations
Hello,
qu'en est-il du support des bases de données utf8mb4 par PMB 7 ?
Je sais que cette version "moderne" de UTF-8 permet de supporter entre autre les caractères émojis.
Wordpress et Nextcloud l'utilise.

Je dois mettre à jour un pmb de la version 5 à 7, avec une conversion UTF-8, alors je me demande si je saute déjà le pas de l'utf8mb4 ?

merci d'avance pour votre aide !

Réponses

  • PLeGPLeG
    juillet 2022 modifié
    Hello,

    Il est probablement un peu tard pour @pullrouge , mais je cherchais cette information également, en vain.
    Après expérimentation, la réponse est : cela dépend, surtout du type de table utilisé.

    Pour rappel, l'utf8 historique de MySQL encode les caractères sur 1 à 3 octets (utf8mb3) alors que l'UTF-8 standard les encode sur 1 à 4 octets (utf8mb4).

    Pour contexte, PMB utilise des index sur des champs VARCHAR d'une longueur maximale de 255 caractères.
    • En latin1 (ou tout autre encodage à un octet par caractère), la clef d'un tel index a une longueur de 255.
    • En utf8mb3, la clef d'un tel index a une longueur de 255 x 3 = 765.
    • En utf8mb4, la clef d'un tel index a une longueur de 255 x 4 = 1020.

    MyISAM/AriaDB permettent des clefs d'index de 1000 octets au plus.
    • utf8mb3 : 765 < 1000, cela passe,
    • utf8mb4 : 1020 > 1000 : cela ne passe plus pour plusieurs dizaines de tables.

    InnoDB dans ses versions récentes  permet des clefs d'index jusqu'à 3072 octets, à condition d'utiliser le format Barracuda (ROW FORMAT DYNAMIC [par défaut actuellement] ou COMPRESSED). Pour certaines versions, il fallait aussi activer la variable système innodb_large_prefix. Dans ce cas :
    • utf8mb4 : 1020 < 3072, tout passe (voir note 1 cependant)

    L'ancien format de table, Antelope, avec ROW FORMAT REDUNDANT ou COMPACT, présentait une limite de 767 octets, encore plus restrictive que MyISAM donc. Je n'ai pas expérimenté avec Antelope, mais les mathématiques indiquent qu'utf8mb3 passerait, puisque 765 < 767. Voir la documentation de votre version de MySQL/MariaDB.


    Note 1 : Quel que soit le type de table, la table words renvoie une erreur de doublon dans l'index unique. La solution simple consiste à faire un TRUNCATE sur la table, la convertir, puis re-générer les index globaux après conversion. La cause étant le changement des règles d'égalité de caractères entre les "collations" pour les latin1 et pour les utf8.

    Note 2 : Le cas en question est une petite bibliothèque personnelle, pas de prêts, peu ou pas de personnalisation de champs, sous MariaDB. Pas nécessairement représentatif de votre installation, donc.

    Note 3 : Le profil de performances d'InnoDB semble très différent de celui de MyISAM : la durée d'une réindexation des index globaux est multiplié par 3 à 5 (la base est stockée sur disques rotatifs, un support SSD améliorerait probablement cela). L'espace disque utilise par la base de données est également multiplié par 3. Bien sur, InnoDB garantit que la base de données reste saine, même en cas d’arrêt brutal du système, cela implique naturellement du travail supplémentaire pour la machine. A garder à l'esprit lors de la planification d'une migration.

    Note 4 : En matière de "collation", la valeur par défaut pour utf8[mbX] est utf8[mbX]_general_ci, dont j'ai lu ici ou là qu'elle prenait des raccourcis problématiques. J'ai donc forcé utf8[mbX]_unicode_ci.
  • PLeGPLeG
    Correction, un point de documentation que j'avais manqué :
    Aria accepte une longueur maximale de 2000 octets pour les clefs d'index à partir de MariaDB 10.5 [1], soit le double des 1000 octets de MyISAM.
    Cela rend Aria compatible avec utf8mb4 en présence de clefs d'index longues (1020 < 2000).

    Une utilisation typique de PMB génère proportionnellement peu d’écritures (catalogage, prêts, souscriptions) et surtout des lectures (recherches, OPAC...).
    Je ne sais pas à quel point PMB utilise les transactions quand elles sont disponibles (InnoDB).
    Il est possible qu'Aria avec TRANSACTIONAL=1 (attention, "transactional" est impropre ici, il s'agit seulement de rendre les tables robustes aux arrêts brutaux du système, pas de transactions proprement dites) soit un choix  plus judicieux qu'InnoDB.
    J’expérimenterai.

    Détails de l'installation:
    PMB 7.4.3
    PHP 7.4.28
    MariaDB 10.5.15
    Debian 11 sous libvirt/KVM

    Méthode de conversion : 
    ALTER TABLE ... ENGINE=...
    ALTER TABLE ... CONVERT TO CHARACTER SET ... COLLATE ...

    Pour que les nouvelles tables ne provoquent pas de régression :
    ALTER DATABASE ... DEFAULT CHARACTER SET...
    ALTER DATABASE ... DEFAULT COLLATE...
    InnoDB est le format par défaut depuis MariaDB 5.5 .


Connectez-vous ou Inscrivez-vous pour répondre.