Quel SGBDR plus rapide que MySQL et gratuit ?

Discussion dans 'Développement d'un site Web ou d'une appli mobile' créé par ortolojf, 22 Septembre 2015.

  1. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 234
    J'aime reçus:
    21
    Bonjour

    J'ai un VPS Classic 4 OVH. ( 8 Go RAM + 100 Go HD ).

    Mon site utilise UN SGBDR ( Système de Gestion de Base de Données Relationnelles ) : MySQL sous Debian 8 Wheezy.

    Mon moteur est InnoDB, qui permet plus les accès concurrents que MyISAM.

    Mon serveur Apache 2.4.10 ( avec le module mpm et php-fpm ), a des temps de réponse qui varient entre 0,40 sec, et 2,4 sec ( très rarement , le plus souvent < 1,0 sec ).

    La RAM utilisée reste en dessous de 15%, et la charge CPU < 5%. ( Console de Gestion OVH ).

    Mais.. La commande 'top' me donne jusqu'à 60 ou 70% pour la RAM par MySQL ( mesures très ponctuelles ), et un CPU correct faible. Le PHP-FPM me donne ( par le top ), dans les 25% ( ponctuel aussi ).

    Le problème, est la gestion des index par MySQL.

    Lors d'une requête MySQL avec index(es), MySQL attribue un poids aux différents index de la requête, ces poids sont une mesure de la quantité estimée de données qu'il faut charger pour satisfaire la requête.

    Comme MySQL n'utilise qu'un seul index par requête, il choisit celui ayant le plus faible poids ( = moins de quantité de données à lire ).

    Moi, j'étais j'étais habitué au SGBDR ORACLE V7 ( étudié lors de mon ( vieux ) stage de 1977 ), et au concept MERISE II suivant lequel une donnée indexée est accessible directement.

    MySQL ayant une gestion ( à l'exécution ) des index, qui me semble un peu vieillotte, n'y aurait-il pas d'autres SGBDR disponibles ( gratuits de préférence ), sous Debian Wheezy, qui gèrent correctement les index, et qui ne se mette pas - comme MySQL - à parcourir toute une table MySQL, sous le prétexte que la requête comporte plusieurs index ?

    Je ne peux pas optimiser plus mes requêtes, je suis obligé parfois, de faire des requêtes sur plusieurs tables MySQL, ou bien souvent, sur plus d'un seul index.

    Super merci pour vos réponses.

    Respectueusement.
     
  2. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 234
    J'aime reçus:
    21
    Rebonjour

    Je me répond.

    Il me semble, qu'au moins un type de requête dans mon cas, est mal indexée.

    Celui avec : FROM COURSES WHERE NUMCRS... AND REUNION... AND COURSE...

    NUMCRS dépendant de DATECRS ( autre champ dans ma table COURSE ), je vais faire un champ ID VARCHAR(10), contenant la date et le numéros des réunions et des courses.

    Cet ID ( en index multiple ), sera nécessairement de poids faible, et de toute façon, réduira la requête à un seul WHERE.

    Moi qui était obnubilé par le fait de faire des index numériques...

    Quant au reste, l'essentiel est d'avoir des requêtes indexées, dont le poids soit faible.

    Pas besoin de changer de SGBD semble-t-il.

    Respectueusement.
     
Chargement...
Similar Threads - SGBDR rapide MySQL Forum Date
Quel SGBDR autre que MySQL/MariaDB ? Administration d'un site Web 12 Janvier 2021
Besoin de booster mon référencement très rapidement :) Débuter en référencement 19 Avril 2020
Augmentation rapide du taux de rebond dans Google Analytics Google Analytics 7 Novembre 2019
Enlever rapidement des milliers url spam (erreur 404) de l'index google Crawl et indexation Google, sitemaps 25 Septembre 2019
Navigateur Brave : plus rapide que chrome et réelle alternative à Adsense Monétisation d'un site web 13 Juillet 2019
La pub sur pages AMP : + rapide donc + rentable ? Monétisation d'un site web 9 Juin 2016
Page d'aperçu rapide de produit indexé dans google Crawl et indexation Google, sitemaps 29 Mars 2016
Forcer rapidement la mise à jour de la cache de nos pages sur google ? Crawl et indexation Google, sitemaps 19 Mars 2016
Conseil désindexation rapide de tout un site sauf la home Problèmes de référencement spécifiques à vos sites 29 Janvier 2016
Déménagement de site pour un accès plus rapide ? Débuter en référencement 16 Juillet 2015