[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linux-team] Database
On Mon, Nov 29, 1999 at 12:54:49PM +0100, Cedric Amand wrote:
> Hello Pascal,
> >> Avez-vous des experiences de terrain, des liens ou expriences a partager
> >> a ce propos ? Si oui, n'hesitez pas a m'envoyer
> PB> Je dirais seulement que s'il te faut un système très rapide, prends un bi-
> PB> processeurs et prends MySQL. MySQL est léger, multithreads et optimizé "à
> PB> mort" sous Linux et... très, très rapide. L'inconvénient, avec MySQL, c'est
> PB> qu'il n'a pas de vues (views), pas de transactions, pas de sub-selects (mais
> PB> y a pas de secret: c'est pour ça qu'il est si rapide ;)).
> MySQL ne convient pas IMHO a un usage intensif dans le temps, par exemple
Ben... "usage intensif dans le temps"... un peu vague ;)
Je pense qu'il faut d'abord bien analyser le type d'accès (bcp d'insert/delete
(OLTP) ou bien bcp de consultation (data warehouse)).
De toute manière, pour des systèmes OLTP qui ont besoin de très bonnes performances,
il n'y a pas de solution idéale. Il paraît que DB/2 (tiens, on l'avait oublié,
celui-là ;)) est très bon pour ça. On l'utilise ici pour des systèmes OLTP (ainsi
qu'Oracle) mais on en est assez mécontent - il faut dire qu'on utilise des techniques
assez complexes (Tuxedo --<XA>--> DB2/Oracle) et que les problèmes qu'on a avec DB/2
sont surtout liés à XA.
Sinon, Oracle n'est pas nécessairement le meilleur choix pour de l'OLTP (mais probablement
ce qui se fait de mieux pour du data warehouse, aussi grâce aux nombres outils de
reporting, etc... qui font partie de Developer/Report/etc...).
J'ai participé à un "oracle tuning workshop" au boulot et on avait invité un consultant
Oracle (qui fait du tuning, justement ;))... sa remarque "si vous faites de l'OLTP,
prenez Ingres" (Ingres utilise un fichier par table, ce qui permet de l'optimiser très
fort au niveau du systèmes (I/O), mais c'est déjà plus pour des grosses bécanes genre F50
ou H80 d'IBM - mais je pense qu'Ingres n'offre pas d'interface SQL... tiens, si j'ai
bien compris, PostgreSQL est basé sur Ingres, non ?), c'est assez révélateur ;)
Maintenant, Oracle est très, très solide (advanced replication, notamment) et est la
seule BD qui permet de faire du réel parallélisme (parallel server option).
> il te locke tes table quand tu fais un delete, ce qui est le comble pour une
ah oui ? de fait, c'est un peu embêtant ;)
> db qui doit a la fois se prendre 3 inserts seconde et faire des deletes de
> milliers de records à intervalles reguliers.
> (Typique de données d'accounting.)
Tu ne sais pas faire les delete en batch, la nuit p.ex. ?
Tu ajoutes un champ pour les marquer en tant que supprimes et tu ajoutes un
test sur ce champ dans le WHERE des SELECTs sur cette table... Et en batch,
tu fais un
DELETE FROM foo WHERE deleted=1;
Oracle est très, très lent pour les delete (petite remarque en passant ;)),
c'est bien connu. Nous on supprime par paquets de 100 records, p.ex., pour
que ce soit plus rapide...
> A part ca, c'est un excellent produit. La future version 3.23 stable
> annonce aussi un replication server qui m'a l'air bien utile. Vu que
hmm... chouette :)
> le but d'un replication est d'etre fiable, je n'ai evidemment pas
> testé le replication server en beta version (sic!) sur un systeme de
> production. Donc je n'ai pas d'avis.
De fait, vaut mieux attendre une version stable ;))
> Pour ma part j'utilise MySQL pour trois usages,
> 1) une DB pour site web (et j'en suis super content),
En effet, on fait difficilement mieux (sauf quand tu as besoin de transactions ;)).
> 2) une DB pour un serveur de Skynet (700K records, et je pense le
> remplacer par un sybase linux) car les selects un peu complexes
> rament sec au dessus de 500K records,
> 3) pour un data warehouse, ou j'en suis très mécontent. (10M records, et
> le serveur ne parvient jamais a rattraper un backlog de travail a
> cause du locking, pas possible de faire des "unions" dans les
> queries, etc )...
Oui, pour du data warhousing, où tu as en principe des requêtes fort complexes
(pas simplement un INSERT ou un DELETE ;)), les limitations de MySQL sont très
embêtantes. Peut-être migrer en Sybase (c'est gratos pour l'utilisation commerciale),
mais il faut s'y connaître (jamais travaillé avec Sybase ou Informix, moi)...
Enfin, j'imagine que le prix n'a pas beaucoup d'importance ;))
Mais 10MB, c'est quand même très petit...
--
-o) / Pascal Bleser ATOS Payment Systems|
/\\ \ C++/UNIX Development Aachen, Germany|
_\_v \<guru@linuxbe.org> <pbleser@atos-group.com>|
---------------------------------------------------|
The brain is a wonderful organ; it starts working :
the moment you get up in the morning, and does not :
stop until you get to school. :
---------------------------------------------------'
---------
Visit the Linux Supertore Online: http://www.redcorp.com !
If you want to be deleted from the list, send a mail to
majordomo@rtfm.be with "unsubscribe linux-team" in the body.
Archive of the list: http://tania.be.linux.org/