Choisir une base de donnée

**Blustuff** · 04/07/2006, 13h28

Bonjour.

J'avoue que ma recherche s'arrête aux seuls sujets marqués "importants" de ce forum. En fait, je m'attendais à avoir un comparatif des bases de données. Je cherche à savoir d'une part quel peut être le temps minimal pour une très simple requête qui ne trouve qu'une entrée. (indexée) Quel ordre de temps ? Et par conséquent, quelle base de donnée est le plus efficace pour traiter des milliers de toutes petites requêtes ? Cela implique également ma troisième question : quels autres facteurs que la rapidité d'une simple requête sont importants dans le choix d'une base de donnée efficace dans cette situation ?

Blustuff.

[Edition]Ah, je cherchais au mauvais endroit, c'est en encadré au-dessus du forum...[/Edition]

**Blustuff** · 06/07/2006, 18h50

Ou bien dois-je préciser "Des milliers de toutes petites requêtes par seconde ?

**KiLVaiDeN** · 06/07/2006, 18h53

HSQLDB a l'avantage d'être codé en Java ( si ton programme initial est en Java, tout est accéléré ) et de pouvoir instancier des tables en mémoire directement : donc du coup, tu ne passes pas par un système de fichiers, qui est le goulot d'étranglement des mini-requêtes comme tu l'entends.

Pourquoi vouloir faire autant de mini requêtes, d'ailleurs, ne peux-tu pas tout charger en mémoire dès le début ?

**Blustuff** · 06/07/2006, 19h07

Au départ si. Au bout d'un moment, il commence à falloir un bon paquet de mémoire vive pour tout stocker, jusqu'à ce qu'il n'y en ait plus assez. Je cherche juste à utiliser la fonctionalité la plus simple d'une base de donnée : Stocker des données. Je me suis assuré qu'il n'y ait pas besoin d'opérations sur un grand nommbre de données, tri, recherche, etc. Tout ce que j'ai besoin c'est de dire "Je veux tel enregistrement". Des tables et quelques index, uniquement des requêtes dont la complexité ne dépasse pas ce que l'on peut apprendre à un premier cours de SQL.

Je ne travaille pas en java, mais en php. J'ai besoin de stocker des objets et de les reprendre. Je n'utilise donc pas (encore) de bdd, mais un système tellement simplissime qu'il ne demande aucun codage, et donc je peux à tout moment choisir de me tourner vers une bdd sans détruire un quelconque travail qui aurait déjà été effectué. Je pourrais toujours très simplement créer un cache en mémoire vive pour accèlérer tous les accès.

Je veux savoir quelles autres solutions existent. Ouvrir, lire, écrire, fermer un fichier de moins de 4 Ko est une opération dont le temps ne dépend pas de la taille. (J'pense que vous en savez plus que moi sur le sujet, et sur le caractère variable du "4 Ko") Par conséquent, je peux lire / écrire plus de données que ce que j'ai normalement besoin sans trop de pénalités. Mais les base de données ont certainement des choses à apporter de ce coté là. Il me semble qu'il existe des bases de données capables de stocker des objets. Il me semble aussi que des systèmes de cache sont déjà programmés pour ça. Et puis lorsque la charge devient trop importante pour un seul serveur, je sais qu'il existe des solutions auxquelles les concepteurs de bdd ont réfléchi pour partager cette charge.

J'aimerais donc savoir à partir de quand il devient pour moi intéressant d'utiliser une base de donnée plutôt qu'un système de fichier + système de cache ? J'aimerais savoir également quels paramètres j'oublie éventuellement dans mon raisonnement ?

**Alexandre T** · 06/07/2006, 21h17

Dans le cadre de votre premier paragraphe je vous conseille MySQL avec les tables de type MyISAM ! Ce moteur privilégie la rapidité et "passe volontairement outre" toutes les notions des moteurs relationnels ; pas de transactions, etc... Si votre applications doit gérer quelques tables transactionnelles , le moteur MySQL gère aussi le moteur de table InnoDB

**Blustuff** · 06/07/2006, 21h48

Toutes les requêtes sur des tables MyISAM que j'ai pu tester étaient relativement lentes par rapport à des solutions moins conventionnelles. Après, j'imagine que leur rapidité dépend de beaucoup du serveur. D'où ma question.

**KiLVaiDeN** · 07/07/2006, 07h50

Pour de telles requêtes je te conseille de faire un fichier binaire, représentant un arbre binaire par exemple.

Ca ira beaucoup plus vite que d'agir sur une base de données, à mon avis..

Enfin PHP pour ce genre de chose c'est pas le top, mais ça peut aller..

**Blustuff** · 07/07/2006, 11h17

Enfin PHP pour ce genre de chose c'est pas le top, mais ça peut aller..

Pourquoi ?

**KiLVaiDeN** · 07/07/2006, 11h22

Ben n'étant pas fortement typé, les manipulations sur les fichiers binaire via fseek deviennent rapidement un casse tête, si tu ne t'organises pas bien depuis le début. Je suis partisant de Java, et en Java c'est quand même beaucoup plus puissant !

Enfin si tu fais un objet solide qui fera tes insertions/suppressions/modifications dans ton arbre binaire, tu seras tranquille au final et ça ira

**Blustuff** · 07/07/2006, 11h35

PHP propose des fonction serialize/uniserialize pour enregistrer un objet. Un fichier par objet, et la gestion reste simple.

Le plus simple pour améliorer est de coder un module php dans un autre langage, ou de rester en php et d'utiliser les fonctions de mémoire partagée déjà programmées pour php.

**KiLVaiDeN** · 07/07/2006, 11h52

Sérialiser / Déserialiser est très lourd comme opération.

**Blustuff** · 07/07/2006, 11h58

C'est pour cela que je veux la reprogrammer. (Curieusement, sur mes tests, elle est moins lourde que de reconstruire les objets à partir de requêtes mysql)

**Alexandre T** · 07/07/2006, 13h19

Envoyé par Blustuff

Toutes les requêtes sur des tables MyISAM que j'ai pu tester étaient relativement lentes par rapport à des solutions moins conventionnelles. Après, j'imagine que leur rapidité dépend de beaucoup du serveur. D'où ma question.

Lentes ?

Je ne trouve pas. J'ai des temps de l'ordre de 50ms sur des recherches d'enregistrements indexés sur table MyISAM. Je passe à 250ms sous InnoDB et des temps similaires sous SQLSERVER. (La table de test possèdait 200.000 lignes.)

**Blustuff** · 07/07/2006, 14h05

Ouch... quand je dis rapide, je parle de temps de l'ordre de la milliseconde, ce qui me paraît nécessaire lorsque l'on veut en caser plusieurs milliers par seconde.

**Alexandre T** · 07/07/2006, 14h49

Maintenant cela dépend de l'architecture technique... Tests effectués sur un petit ordinateur portable pendant mes déplacements professionnels... Mais si la charge est énorme, les solutions en load balancing ou en cluster existent !

**Blustuff** · 07/07/2006, 15h11

Mais si ne pas utiliser Mysql et lui préférer une solution plus "basique" permet de n'avoir besoin que d'un serveur au lieu de trois, j'imagine que ça reste relativement intéressant. Mais beaucoup de questions encore... Par exemple, que gagnerais-je à n'utiliser qu'un nombre réduit de fichier plutôt que plusieurs dizaines de milliers ?

**Blustuff** · 07/07/2006, 21h54

Un hébergeur web explique que les sémaphores ne sont pas activées sur leur serveur php mutualisé, pour des raisons évidentes. Il propose avec d'utiliser des tables Mysql de type Memory (ou Heap) qui effectivement ont l'air intéressantes :

http://dev.mysql.com/doc/refman/5.0/...ge-engine.html

La reconstruction d'objet reste toutefois pénible avec mysql...

**Blustuff** · 13/07/2006, 20h48

Autre découverte fabuleuse : Un forum qui possède une option activée par défaut qui utilise la base de donnée à la place des fichiers pour la gestion des sessions. Qu'en pensez-vous ?

**Alexandre T** · 14/07/2006, 15h21

Ca dépend.

Les traitements de session en php par fichiers textes sont + rapides que par des données. Par contre, les bases de données peuvent avoir des "moteurs de tables" très rapides, mais moins orientés "relationnel". Pour l'exemple, en MySQL, les tables de type HEAP sont stockées en mémoire vive.

Mais je n'ai pas trop testé la gestion des sessions par sgbd. Donc aucune idée des rapidités de traitement.sous forme de

Choisir une base de donnée

Décisions SGBD

Discussions similaires

Partager

Partager