16. Limites connues
Cette page recense, honnêtement et à jour, ce qui n'est pas disponible dans cette version de MIRAJ. Chaque point a été vérifié directement dans le code du moteur plutôt que recopié d'une documentation antérieure : plusieurs fonctionnalités longtemps annoncées comme absentes sont en réalité déjà livrées (voir la remarque de fin de page à ce sujet), et cette page en tient compte.
Pour les limites chiffrées (tailles maximales, plages de types, nombre de fils, etc.), voir le chapitre consacré aux limites de dimensionnement ; cette page porte sur les fonctionnalités absentes, avec une alternative quand il y en a une.
1. Transactions et concurrence#
| Fonctionnalité absente | Situation actuelle | Alternative / contournement |
|---|---|---|
SAVEPOINT opérant réellement | SAVEPOINT nom seul est accepté sans effet ; ROLLBACK TO SAVEPOINT et RELEASE SAVEPOINT renvoient une erreur (fonctionnalité non prise en charge) | Découper la transaction en unités plus petites, ou gérer la reprise partielle côté application |
XA (transactions distribuées deux phases) | Non reconnu | Pas d'alternative dans cette version ; prévu dans une version ultérieure pour les scénarios multi-ressources |
| Niveaux d'isolation inférieurs à SERIALIZABLE | SET TRANSACTION ISOLATION LEVEL est mémorisé sans effet : toute lecture d'une transaction qui écrit est validée à son COMMIT. Avec la mise à jour différée (chapitre 9, §9.2), une transaction qui lit une ligne puis la met à jour reçoit donc 1213 au COMMIT si une autre transaction a modifié cette ligne entre-temps | Porter la condition dans l'UPDATE lui-même (… WHERE id = 7 AND qte >= 1) plutôt que de lire la ligne d'abord ; sinon, rejouer la transaction |
MIRAJ utilise un contrôle multiversion optimiste avec isolation sérialisable : les lecteurs ne sont jamais bloqués ni annulés, et une transaction n'attend jamais un verrou de ligne (elle échoue immédiatement et doit être réessayée). C'est une différence de fond avec un moteur à verrous pessimistes classique, décrite en détail dans docs/concurrency.md — ce n'est pas une limite mais un choix d'architecture à connaître pour écrire du code qui retente correctement ses transactions. La mise à jour différée (active par défaut) évite ce 1213 aux UPDATE d'une ligne désignée par sa clé, recalculés au COMMIT ; en contrepartie, une erreur de calcul (1264, 1048, 4025…) ou un conflit peut n'apparaître qu'au COMMIT, qui annule alors toute la transaction.
2. SQL : ce qui manque réellement#
Contrairement à ce qu'une documentation plus ancienne du produit a pu laisser entendre, la plupart des constructions SQL avancées listées ci-dessous sont déjà prises en charge par cette version. Seules les suivantes manquent encore :
| Fonctionnalité absente | Situation actuelle | Alternative / contournement |
|---|---|---|
WITH RECURSIVE (CTE récursive) | Une expression de table (WITH nom AS (...)) non récursive est prise en charge ; la forme récursive ne l'est pas | Dérouler la récursion côté application, ou utiliser une procédure stockée avec une boucle |
NATURAL JOIN | Reconnu par l'analyseur syntaxique mais rejeté à l'exécution (fonctionnalité non prise en charge) | Écrire la condition de jointure explicitement avec ON ou USING |
FULL [OUTER] JOIN | Non reconnu | Combiner un LEFT JOIN et un RIGHT JOIN avec UNION |
Sous-requête corrélée dans la condition ON d'une jointure, ou dans l'ORDER BY d'un UNION | Erreur signalée | Réécrire la condition sans corrélation à cet endroit précis (la même sous-requête corrélée reste possible ailleurs dans la requête) |
INTERSECT / EXCEPT | Non reconnus | Réécrire avec NOT EXISTS / EXISTS ou une jointure |
Séquences (CREATE SEQUENCE) | Non prises en charge | Utiliser une colonne AUTO_INCREMENT |
Index secondaires par plage ou préfixe de colonne (col(n) dans un INDEX) | Les index secondaires eux-mêmes sont pris en charge (voir plus bas), mais seulement pour une égalité exacte sur la totalité de leurs colonnes ; jamais pour un intervalle, un IN, ni un préfixe | Créer une colonne générée qui isole la partie utile de la valeur, et l'indexer |
| Index inversés | Non pris en charge | — |
Index vectoriel (VECTOR INDEX, HNSW) | Un seul par table, sur une colonne VECTOR(n) NOT NULL ; résultat approché ; jamais utilisé pour DESC, sans LIMIT, une jointure, une agrégation ni UPDATE / DELETE … ORDER BY … LIMIT ; pas d'index IVFFlat (USING ivfflat) ni de classes halfvec / bit / vector_l1_ops ; ef_construction sans effet (voir le chapitre 19) | Augmenter mhnsw_ef_search pour un meilleur rappel ; sans index, ORDER BY distance LIMIT k reste exact |
Ne sont plus des limites (contrairement à une documentation produit plus ancienne, qui n'est pas destinée au public) : les sous-requêtes (non corrélées et corrélées, sauf les deux emplacements cités ci-dessus), UNION/UNION ALL, RIGHT JOIN, INSERT ... SELECT, REPLACE, INSERT ... ON DUPLICATE KEY UPDATE, les index secondaires non uniques, EXPLAIN, les fonctions de fenêtrage (OVER (PARTITION BY ... ORDER BY ...)) et les expressions de table non récursives (CTE) sont implémentés dans cette version. Voir la remarque en fin de page.
3. Connexions et sécurité#
| Fonctionnalité absente | Situation actuelle | Alternative / contournement |
|---|---|---|
| Chiffrement des données au repos | Non implémenté : les fichiers de table (.mrj, .bmrj) ne sont pas chiffrés sur disque | Chiffrer au niveau du système de fichiers ou du disque (BitLocker, LUKS...) si nécessaire |
Privilèges par colonne (GRANT SELECT (col1, col2) ON ...) | Non pris en charge ; le contrôle s'arrête au niveau de la table | Restreindre l'accès via une vue qui ne projette que les colonnes autorisées |
Privilèges par routine (GRANT EXECUTE ON PROCEDURE ...) | Non pris en charge : seul le privilège global EXECUTE existe | — |
PROXY (utilisateurs proxy) | Non reconnu | — |
RENAME USER | Non reconnu | Recréer le compte sous le nouveau nom et reporter ses privilèges avec GRANT |
Limites de ressources par compte (GRANT ... WITH MAX_QUERIES_PER_HOUR ...) | Non prises en charge | Gérer la limitation côté application ou proxy réseau |
Ne sont plus des limites : le TLS pour les connexions clientes est disponible (--tls-cert, --tls-key, --require-tls, TLS 1.2 et 1.3) — c'est une fonctionnalité distincte du TLS mutuel utilisé entre nœuds d'un cluster de réplication (voir §5), les deux ne devant pas être confondus : l'un chiffre la liaison client ↔ serveur, l'autre chiffre la liaison entre nœuds du cluster et authentifie chaque nœud par certificat signé par l'autorité du cluster. KILL et KILL QUERY sont également disponibles, tout comme les rôles et les privilèges par base et par table.
4. Types de données#
| Fonctionnalité absente | Situation actuelle | Alternative / contournement |
|---|---|---|
BIGINT UNSIGNED au-delà de 2^63 − 1 | La colonne est stockée sur un entier signé 64 bits en interne : les valeurs entre 2^63 et 2^64 − 1 (pourtant valides pour ce type) sont refusées à l'écriture | Utiliser DECIMAL pour des valeurs positives dépassant 2^63 − 1 |
5. Réplication et cluster (édition Cluster)#
La réplication multi-nœud est implémentée dans cette version : un nœud primaire accepte les écritures, des nœuds secondaires en nombre illimité répliquent le journal en continu et restent consultables en lecture seule (édition Cluster), la liaison entre nœuds étant chiffrée en TLS mutuel avec authentification par certificat propre à chaque nœud. Ce point corrige une documentation plus ancienne qui présentait la réplication comme absente ou insuffisamment décrite.
Limites actuelles de cette fonctionnalité :
| Fonctionnalité absente | Situation actuelle | Alternative / contournement |
|---|---|---|
| Bascule automatique (élection d'un nouveau primaire) | En mode manuel (défaut), la promotion est manuelle et contrôlée (refus 9003). En mode raft (mode = "raft", chapitre 12, §12.9), le primaire est élu par une majorité des membres ; limites de ce premier incrément : membres fixes, lectures non linéarisables, écritures OFF d'un leader isolé perdues (quarantaine), élection bloquée possible (base absente chez les survivants), base supprimée réapparue si un nœud absent est élu | Mode raft avec MAJORITY pour les écritures qui ne doivent pas être perdues ; 'force_primary' en dernier recours quand la majorité est perdue |
| Requêtes distribuées inter-nœuds | Chaque nœud répond avec ses propres données ; il n'y a pas de fédération de requêtes entre nœuds | Adresser les requêtes au nœud approprié depuis l'application |
| Réplication pleinement synchrone (écriture invisible tant qu'elle n'est pas accusée), quorum | La réplication est asynchrone par défaut ; la réplication semi-synchrone (@@cluster_sync_commit = RECEIVED | APPLIED, chapitre 12, §12.8) fait attendre à une écriture les accusés de cluster_sync_replicas secondaires, mais l'écriture est validée et visible sur le primaire avant ces accusés, et un délai dépassé la confirme avec un avertissement 9004 (ou une erreur 9004, l'écriture restant validée) ; le niveau MAJORITY (écrite sur une majorité des membres) et l'élection existent en mode raft (§12.9) | Pour les écritures qui ne doivent pas être perdues à la bascule : SET SESSION cluster_sync_commit = 'received' avec cluster_sync_timeout_action = 'error' (ou 'wait'), et traiter l'erreur 9004 comme un résultat inconnu à vérifier |
6. Où consulter le détail technique#
Pour un inventaire complet et chiffré (tailles, plages, comportements précis colonne par colonne, y compris ceux non listés ici parce qu'ils ne sont pas des limites mais des caractéristiques du moteur), consulter le code source du moteur reste la référence la plus à jour ; cette page se limite aux fonctionnalités concrètement absentes pour un usage courant.
7. Perspective : évolutions futures#
Certaines des limites ci-dessus sont amenées à disparaître dans des versions ultérieures de MIRAJ, au fil d'une feuille de route en plusieurs étapes qui couvre notamment :
- un moteur de stockage encore plus performant pour l'analytique (compression avancée, calcul vectorisé SIMD, optimiseur à coûts) ;
- des fonctionnalités serveur complémentaires (sauvegardes incrémentales ou compressées — la sauvegarde à chaud complète existe, voir chapitre 18 —, chiffrement des données au repos, supervision étendue) ;
- une évolution de la haute disponibilité (bascule automatique, requêtes distribuées).
Ces évolutions sont données à titre indicatif de trajectoire produit et ne constituent pas un engagement de calendrier.
Remarque sur cette page : plusieurs points listés comme absents dans une documentation antérieure du produit se sont révélés, à la vérification directe du code, déjà implémentés — en particulier les sous-requêtes, UNION, RIGHT JOIN, INSERT ... SELECT, REPLACE, ON DUPLICATE KEY UPDATE, le TLS pour les connexions clientes, KILL QUERY, les index secondaires non uniques, EXPLAIN, les fonctions de fenêtrage, les expressions de table (CTE non récursives), ainsi que la réplication cluster avec TLS mutuel entre nœuds et les procédures/fonctions stockées. Cette page a été corrigée en conséquence.