Aujourd’hui, j’ai décidé d’optimiser une recherche MySQL de recherche par proximité de points spatiaux. En effet, j’avais une requête qui prenait 250 ms en moyenne.
Je recherche donc quelques infos et là, bonne surprise je tombe sur un document issu de l’entreprise MySQL sur le sujet. En utilisant l’optimisation qu’ils recommandent (par approximation préalable en un carré de recherche), j’arrive à réduire les requêtes à des temps allant de 5 à 35 ms.
Et puis, je finis de lire le document et je m’aperçois que MySQL possède une extension spatiale. Je regarde donc, ça se base sur les R-Tree, là je sens que j’ai trouvé la solution parfaite. Mais NON, les R-Tree ne sont disponible qu’en MyISAM. La création d’index spatiaux est interdite en InnoDB. De même, les index FULLTEXT non disponibles en InnoDB.
On a le choix entre avoir une base de données peu solide et une base de données avec moins de fonctionnalités. Il existe bien sur des solutions, comme de dédoubler ses tables en InnoDB et MyISAM pour obtenir des index FULLTEXT. Mais ça devient vite contraignant.
Enfin, je tiens à relativiser cette petite critique. La plupart des personnes, surtout en entreprise “non-web”, ne connaissent MySQL en version 3 et le trouvent de fait pourri. Peu savent que pour la gestion des données critiques, MySQL avec le moteur InnoDB est très robuste. Je ne suis jamais parvenu à obtenir une quelconque corruption des données même après de bonnes maltraitances (coupure de courant en pleine écriture massive). Ses capacités relationnelles et transactionnelles en font un très bon moteur de stockage de base de données.
Pour l’instant j’ai des tables qui contiennent un peu plus de 10 000 000 lignes et InnoDB tient sans problème, je vous en reparle quand ça atteindra les 20 000 000 lignes.
Ajout du 15/05/2010 :
L’expérience de ce projet s’est arrêtée à 35M lignes et InnoDB a tenu sans aucun soucis.