[Raizin]

[Antipika : Message scindé]

Sinon il parait que Access c'est pour les noobs, nous on utilise PostgreSQL (je suppose que c'est parce qu'il est gratos et multiOS).

[Kedare]

Déja si tu veux une vrais base de données, Oublis Mysql et passe a Postgresql, tu sera halluciné du nombre de chose qu'il est possible de faire par apport a MySQL

[jfbus]

Citation :

Publié par Kedare

Déja si tu veux une vrais base de données, Oublis Mysql et passe a Postgresql, tu sera halluciné du nombre de chose qu'il est possible de faire par apport a MySQL

Je crois que, pour un débutant, c'est déjà hallucinant ce qu'on peut faire avec MySQL. D'ailleurs, pour un pro aussi.

Les deux sont différents et répondent à des besoins légèrement différents, dans certains cas, MySQL est plus adapté, dans d'autres, PostgreSQL est plus adapté. Il y a des énormes sites qui tournent avec MySQL, d'autres énormes avec PostgreSQL. Par contre, il est sans doute plus facile de trouver un hébergeur gratuit/pas cher sur du MySQL.

Mais bon, on dérive du sujet initial...

[Tzioup]

Citation :

Access c'est pour les noobs

Citation :

si tu veux une vrais base de données, Oublis Mysql et passe a Postgresql

Vous pouvez arrêter avec votre prosélytisme mensonger et complètement débile? C'est pas la foire aux idées reçues de première année de fac ici :/

[Kedare]

Citation :

Publié par Tzioup

Vous pouvez arrêter avec votre prosélytisme mensonger et complètement débile? C'est pas la foire aux idées reçues de première année de fac ici :/

Bah excuse moi mais Mysql c'est carrément pas une base de données pro, quand tu vois par exemple qu'il n'y a AUCUN moyen avec Mysql de faire un backup consistant "a chaud" (sans verrous)(le seul moyen c'est de faire un master/slave et de faire le backup qui va lock le slave), ou que par exemple, impossible d'utiliser plusieurs tablespaces avec InnoDB (donc du coup le partitionnement est quasiment inutilisable avec InnoDB), bref le système de moteurs de MySQL c'est de la grosse daube)

[jfbus]

Citation :

Publié par Kedare

Bah excuse moi mais Mysql c'est carrément pas une base de données pro, quand tu vois par exemple qu'il n'y a AUCUN moyen avec Mysql de faire un backup consistant "a chaud" (sans verrous)(le seul moyen c'est de faire un master/slave et de faire le backup qui va lock le slave), ou que par exemple, impossible d'utiliser plusieurs tablespaces avec InnoDB (donc du coup le partitionnement est quasiment inutilisable avec InnoDB), bref le système de moteurs de MySQL c'est de la grosse daube)

Rien de tel qu'un fil de discussion anodin qui part en troll...

Honnêtement, on s'en fout de savoir qu'on ne peut pas faire de sauvegarde sérieusement, ni des tablespaces avec innodb. Ca (et les milliards d'autres défauts de MySQL) n'en font pas un outil "pas pro".

Faisons un petit test : quelle est la base de données qui fait tourner Youtube, Facebook et Twitter ? MySQL... Pour une base de données aussi cheap, ce sont de belles références...

Sinon, pour ce qui est de trouver du boulot (ce qui est finalement un point important pour le fil de discussion), il vaut mieux connaître mysql que postgresql. Une petite recherche "mysql" remonte 148 annonces sur monster.fr alors que "postgresql" n'en remonte que 19.
Dans l'absolu, "access" et "sql server" remontent plus de résultats, mais je doute que l'intérêt des postes soit aussi élevé

[Kedare]

Citation :

Publié par jfbus

Faisons un petit test : quelle est la base de données qui fait tourner Youtube, Facebook et Twitter ? MySQL... Pour une base de données aussi cheap, ce sont de belles références...

Ils utilisent un Mysql modifié adapté a leur sauce, et Facebook utilise une autre base de données a coté pour tout ce qui est massif niveau performance (j'ai plus le nom de l'autre base de données, mais il me semble que c'est un truc développé par eux)

[Tzioup]

Citation :

Publié par Kedare

Ils utilisent un Mysql modifié adapté a leur sauce, et Facebook utilise une autre base de données a coté pour tout ce qui est massif niveau performance (j'ai plus le nom de l'autre base de données, mais il me semble que c'est un truc développé par eux)

Ca n'enlève en rien à l'énormité de ce que tu racontais.

Facebook fonctionne sur une base MySQL, et Facebook Photos utilise Haystack, un modèle qui n'est pas relationnel. Enfin bon, on est loin du "MySQL c'est de la merde et n'est pas pro", n'est-ce pas?

NB : vis-à-vis de ton post précédent, bien sûr que MySQL gère les backups incrémentaux, et les tablespaces ne sont pas comparables entre les deux moteurs (MySQL a une granularité bien plus importante, et est au contraire plus flexible de ce côté que PostgreSQL).

[jfbus]

Citation :

Publié par Kedare

Ils utilisent un Mysql modifié adapté a leur sauce, et Facebook utilise une autre base de données a coté pour tout ce qui est massif niveau performance (j'ai plus le nom de l'autre base de données, mais il me semble que c'est un truc développé par eux)

C'est la beauté de l'open-source : s'il y a des choses qui te plaisent pas, tu peux les changer. Ceci étant dit, ils n'ont fait que des patches (Google aussi en a fait), pas réécrit le moteur...

Pour le reste, tu penses sans doute à Cassandra (http://perspectives.mvdirona.com/200...AndDesign.aspx), qui apparemment n'est utilisé que sur la messagerie. C'est encore pire que MySQL d'un point de vue pureté...

[Kedare]

Citation :

Publié par Tzioup

NB : vis-à-vis de ton post précédent, bien sûr que MySQL gère les backups incrémentaux, et les tablespaces ne sont pas comparables entre les deux moteurs (MySQL a une granularité bien plus importante, et est au contraire plus flexible de ce côté que PostgreSQL).

Mysql ne gère pas les backups a chaud sans vérrouillage (par table sur MyISAM, par lignes sur InnoDB), je vois pas trop ce que tu veux dire par "MySQL a une granularité bien plus importante, et est au contraire plus flexible de ce côté que PostgreSQL", explique

Le probleme des tablespace c'est qu'en gros il y a pas de vrais systeme de tablespace avec InnoDB, je peux pas choisir de mettre une partition de table ou une table sur un disque, et une autre sur un autre disque, c'est possible qu'avec MyISAM et c'est bien dommage....
Dans le même genre, les indexes et tables innodb sont dans le même fichier, donc pour le moindre ALTER TABLE on a le droit a une reconstruction complète de la table et de l'indexe, ce qui prend un temps fou, et verrouille le tout, la ou avec Postgresql c'est pratiquement instantané (ca dépend du ALTER), et ca ne verrouille rien

Bon après tout ca ce sont des détails insignifiant pour quelqu'un qui débute et veux juste apprendre a utiliser une base de données, mais quand on commence a utiliser des systèmes en production qui peuvent devenir massif... les limitations de mysql deviennent tout de suite plus gênantes.

[Mikushi]

Citation :

Publié par Kedare

Ils utilisent un Mysql modifié adapté a leur sauce, et Facebook utilise une autre base de données a coté pour tout ce qui est massif niveau performance (j'ai plus le nom de l'autre base de données, mais il me semble que c'est un truc développé par eux)

En ayant un bon design de DB, MySQL suffit largement pour du lourd trafic, et bon faut aussi savoir que dans le cas de Facebook (et dans beaucoup d'autres quand il s'agit de haut volumes de trafics), MySQL est doublé avec des systèmes comme Sphinx, ou encore Memcache, qui permettent d'alléger la charge sur MySQL, et offre des meilleurs temps de réponse dans leur domaine respectif (Sphinx pour la recherche text et Memcache pour le caching).

Quand au locking des tables, oui c'est super chiant, mais par exemple, nous on effectue aucun backup sur le master, on effectue plutôt une replication sur un slave passif, sur lequel on exécute le backup, a date aucun problème avec ce système.

Mais j'avoue que pour avoir bossé avec postgre, il a ses avantages qui ne laisse pas indiffèrent

[Kedare]

Citation :

Publié par Mikushi

Quand au locking des tables, oui c'est super chiant, mais par exemple, nous on effectue aucun backup sur le master, on effectue plutôt une replication sur un slave passif, sur lequel on exécute le backup, a date aucun problème avec ce système.

Ca fait cher le backup de se payer un slave pour ça
Mais bon c'est le seul moyen de faire du vrais backup a chaud sur Mysql si j'ai bien comprit...
La simplicité de réplication est le gros avantage de Mysql, faire ca sur Postgresql c'est d'un enfer... mais on a beaucoup plus de type de réplication avec tout les projets qui tentes de l'implanté, mais tous sont super complexe a maitriser par apport a la réplication ou même au clustering de Mysql que l'on peut mettre en place en quelques minutes (je parle pour la réplication, le clustering est quand même plus complexe a mettre en place que ça...).
Autre gros avantage a Mysql, il y a aussi l'excellent support d'entreprise que fournis Mysql AB... Ah non SUN.... Ah non mince, Oracle (Oui on sais plus trop qui possède Mysql ses derniers temps... et on sais pas trop ce qu'Oracle va en faire), il est aussi triste de voir que ses derniers temps certaines personnes ont eu l'idée de créer plusieurs fork de Mysql au lieu de contribuer au projet principal, même le fondateur de Mysql s'est cassé pour fonder MariaDB....

Bref pour le moment entre tout ces rachats, l'avenir de MySQL est très incertain...

J'ai il y a quelques temps écrit 2 posts sur mon blog: En gros des critiques plus ou moins trollesque sur Postgresql et Mysql :
http://kedare.alwaysdata.net/article...-de-mysql.html
http://kedare.alwaysdata.net/article...s-parfait.html

A propos de memcached, c'est indispensable pour tout site qui se veut performant
Sphinx faut voir, je l'ai jamais utilisé, pour la recherche fulltext (dans mon blog par exemple), j'utilise la recherche fulltext de PostgreSQL (en compilant l'article en tsvector) qui est très bien conçu, je sais pas trop ce qu'elle vaut quand la base commence a grossir...

[Current Mood]

En passant, un petit résumé de la situation Oracle/Sun ( Enfin on est grave HS la )

http://pro.01net.com/editorial/50750...jeter-leponge/

[Mikushi]

Citation :

Publié par Kedare

Ca fait cher le backup de se payer un slave pour ça
Mais bon c'est le seul moyen de faire du vrais backup a chaud sur Mysql si j'ai bien comprit...
La simplicité de réplication est le gros avantage de Mysql, faire ca sur Postgresql c'est d'un enfer... mais on a beaucoup plus de type de réplication avec tout les projets qui tentes de l'implanté, mais tous sont super complexe a maitriser par apport a la réplication ou même au clustering de Mysql que l'on peut mettre en place en quelques minutes (je parle pour la réplication, le clustering est quand même plus complexe a mettre en place que ça...).
Autre gros avantage a Mysql, il y a aussi l'excellent support d'entreprise que fournis Mysql AB... Ah non SUN.... Ah non mince, Oracle (Oui on sais plus trop qui possède Mysql ses derniers temps... et on sais pas trop ce qu'Oracle va en faire), il est aussi triste de voir que ses derniers temps certaines personnes ont eu l'idée de créer plusieurs fork de Mysql au lieu de contribuer au projet principal, même le fondateur de Mysql s'est cassé pour fonder MariaDB....

Bref pour le moment entre tout ces rachats, l'avenir de MySQL est très incertain...

J'ai il y a quelques temps écrit 2 posts sur mon blog: En gros des critiques plus ou moins trollesque sur Postgresql et Mysql :
http://kedare.alwaysdata.net/article...-de-mysql.html
http://kedare.alwaysdata.net/article...s-parfait.html

A propos de memcached, c'est indispensable pour tout site qui se veut performant
Sphinx faut voir, je l'ai jamais utilisé, pour la recherche fulltext (dans mon blog par exemple), j'utilise la recherche fulltext de PostgreSQL (en compilant l'article en tsvector) qui est très bien conçu, je sais pas trop ce qu'elle vaut quand la base commence a grossir...

Clair, on a un total de 25 serveurs MySQL -dont 3 master, 1 par DB- (pour ça qu'avoir un slave passif c'est pas trop problématique, 1 serveur de plus ou de moins ), et la réplication se fait vraiment simplement, pour la mise en cluster, je pourrais pas me prononcer, c'est loin d'être mon domaine normalement .

Sinon c'est vrai que ce problème de locking est chiant, pas plus tard que la semaine dernière, notre système était out pour 2j, un bug dans le code créait des situations de locking récursifs, résultat, les process s'accumulaient lentement (jusqu'a 30 000 ), jusqu'a ce que le serveur sature et plante


Sinon intéressante tes critiques. Un petit bémol sur ta critique des memory tables dans MySQL, avec une bonne infrastructure, c'est une excellente solution pour des exécutions ultra-rapides, après il s'agit de mettre des gardes fous (nous on copie les données dans un slave toutes les heures) et surtout ne pas mettre tout et n'importe quoi dans des memory tables, aucune donnée critique ne devrait se trouver dedans, ou alors des données dont vous pouvez vous permettre de perdre la dernière heure par exemple. Mais il faut avouer que c'est vraiment ultra rapide, et offre la possibilité de recherche par SQL que memcache n'offre pas (et ce n'est clairement pas son rôle).

Memcached, depuis que je le connais je suis en amour avec , une bonne implémentation de Memcache (si vous faites du php, je recommande l'utilisation de l'extension memcached (qui n'est pas par défaut), bien plus complete que la classe Memcache de base -notamment au niveau du hashing system-)) permet vraiment d'alleger ses serveurs de DB, et c'est pas rien .
Sphinx, on ne l'a mis en place qu'il y a 3mois, et on ne l'utilise pas vraiment sur ce qu'il est le meilleur (les gros textes), mais quand même, c'est une excellente solution, facile a mettre en place, et vraiment très performante sur les grosses BDD. Par exemple la recherche de JoL marche sous Sphinx (c'est récent).