[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linux-team] Database
On Mon, Nov 29, 1999 at 08:51:20PM +0100, Cedric Amand wrote:
> Hello Pascal,
Hello _CeD_ ;)
> PB> Oracle est très, très lent pour les delete (petite remarque en passant ;)),
> PB> c'est bien connu. Nous on supprime par paquets de 100 records, p.ex., pour
> PB> que ce soit plus rapide...
> Ca c'est très bon a savoir, merci du tuyau !
ah, tu savais pas ? c'est bien connu... Oracle est hyper-lent pour les deletes :\
Maintenant, c'est sur une 7.3.3 - je suppose que ça a été nettement amélioré sur
les 8.x. Une autre possibilité très intéressante (mais qu'on ne peut pas utiliser
ici, parce que notre code doit être 100% portable à tout niveau, y compris BD) avec
les 8.x, c'est de faire un DELETE parallélisé.
> PB> Oui, pour du data warhousing, où tu as en principe des requêtes fort complexes
> PB> (pas simplement un INSERT ou un DELETE ;)), les limitations de MySQL sont très
> PB> embêtantes. Peut-être migrer en Sybase (c'est gratos pour l'utilisation commerciale),
> PB> mais il faut s'y connaître (jamais travaillé avec Sybase ou Informix, moi)...
> PB> Enfin, j'imagine que le prix n'a pas beaucoup d'importance ;))
> PB> Mais 10MB, c'est quand même très petit...
> "10M record" = dix millions de records (environ 2 gigabytes.)
ah, ok ;)
De fait, c'est déjà un peu plus gros ;))
> A propos d'oracle, Oracle est venu nous presenter un truc chouette pour
> un data warehouse, qu'ils disent optimisé pour cet usage (cad en gros
> que ca pue pour tout, sauf pour çà ;) avec du pattern matching tout
> partout, stockage binaire des données pour accélerer les select (plus
> compressions par dessus)
Chais pas... on fait de l'OLTP et c'est bien plus difficile (à optimiser) ;)
> Donc en gros tout le monde semble d'accord ici pour dire que oracle
> d'impose dans le data warehouse ;) , et MySQL dans tout sauf çà, et
C'est clair. Rien que pour les fonctionnalités et l'advanced replication.
C'est super-bien fait et très solide.
De tout manière, c'est toujours le même problème: quand tu fais de l'OLTP,
tu dois tuner ta BD à l'exagéré quand c'est pas dans les temps de réponse.
On a entre-autres un système d'authorisation pour les banques (enfin, pas
exactement les banques ;) - genre Visa, Mastercard, Eurocard, etc..) et t'imagines
bien qu'il leur faut des temps de réponse extrêmement courts.
Là, va falloir casser notre portabilité (on utilise les DBTools.h++ de Rogue Wave)
et mettre du embedded SQL (ou même de l'OCI... beurk) et mettre des hints à donf ;)
> ca ne marche plus bien quand il y a beaucoup d'opérations simultanées.
Probablement. C'est plutôt pour un backend de site web (là, je pense que c'est idéal)
ou bien comme PAM d'authorisation (ça, c'est vraiment très "nifty" comme on dit ;)).
Mais j'imagine que PostgreSQL doit être nettement mieux fait à ce niveau-là. Sans
rigoler, ça a vraiment l'air bien foutu (bon, ça n'a pas les possibilités ni la
solidité d'Oracle ou autre "grosse" BD commerciale, mais quand même... ça vaut surement
un essai).
Allez, @+
BTW, pour ceux qui sont un peu moins familiers avec ce genre de choses:
"OLTP" c'est "OnLine Transaction Processing" et ça veut dire: beaucoup d'accès
(surtout insert/delete) concurrents et qui doivent généralement être très, très rapides.
Par contre, "data warehouse", c'est plutôt une BD qui contient énormément de données
qui sont très peu modifiées mais sur lesquelles on fait beaucoup de consultations souvent
très complexes.
PS: Tiens, qqn a déjà joué avec LDAP (p.ex. pour l'authentification d'utilisateurs via PAM) ?
J'arrive pas vraiment à m'y retrouver (comment créer une base LDAP, y accéder, etc...),
mais bon, j'ai pas cherché des masses non plus ;))
--
-o) Pascal Bleser |
/\\ C++/UNIX Development | God is real, unless
_\_v ATOS Payment Systems | declared integer.
Aachen, Germany |
<pbleser@atos-group.com>-------<guru@linuxbe.org>
---------
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/