Quelle version et comment utiliser un SGBD libre MySQL dans des projets commerciaux? [fermé]

Question

À l'heure actuelle, l'édition communautaire serveur MySQL 5.5.16 est sous licence GPL. Cela signifie qu'il peut être utilisé dans des projets qui sont des projets open source aussi. Notre budget du projet est très serré et nous devons trouver une solution pour utiliser la version gratuite de MySQL dans le projet commercial. J'ai plusieurs questions:

1) Quelle version antérieure de MySQL serait assez solide et sans bug à l'utilisation dans des projets commerciaux?

2) A propos de l'utilisation de MySQL Community Edition actuelle serveur 5.5.16 avec GPL: si une architecture logicielle de projet est conçu avec le soutien pour le branchement est alors beaucoup DBMSs il légal d'avoir un logiciel de projet sous licence GPL non? Je veux dire, supposons que le logiciel est conçu avec plusieurs SGBD prennent en charge et le logiciel est mis sous licence commerciale. Si le client choisit d'utiliser la version GPL de MySQL, il ne viole la licence GPL?

3) J'entendu des réponses négatives sur PostgreSQL étant buggy et non optimisé pour modifier et stocker de grandes séries de données. La seule raison pour laquelle il est encore utilisé dans certains petits projets commerciaux est parce qu'il est gratuit. Quelles sont vos opinions sur ce sujet?

MISE À JOUR: aussi, nous prévoyons d'utiliser plusieurs serveurs, donc la réplication maître-esclave est également nécessaire.

MAJ2: J'ai entendu parler d'un cas: on a utilisé ~ 1 Go PostgreSQL DB. La base de données a été fortement utilisé avec des mises à jour en modifiant presque toutes les données. Le problème était la base de données a été en constante augmentation sur les dix fois par mois 2.5. Ils ont utilisé PostgreSQL 8.3 + CentOS. En outre, autovacuum a été utilisé. Après la base de données dumping, détruisant l'ancien, ils ont pu recréer la base de données et l'importation pour réduire sa taille ~ 10 fois. postes existants ( et ici ) montrent que ce problème est relatif, même dans la version PostgreSQL 9 dernière. Je ne dirais pas un comportement normal et une telle croissance de la taille ne sont pas acceptables dans notre cas.

Update3: merci à vous tous pour les réponses. Toutes les réponses sont relatifs et utiles pour la question.

Answer 1

les autres affiches ont mentionné que lier essentiellement aux moyens mysql que vous avez une licence du projet GPL ou une autre licence d'exploitation Oracle / MySQL fait une exception pour, ou il est commercial et vous le devez leur argent. Quoi qu'il en soit ...

OK, PostgreSQL stocke ses données dans un magasin de données qui prend en charge MVCC, contrôle d'accès concurrentiel multi-version. Ce moyen sur un simple niveau que chaque transaction obtient un instantané de la base de données est cohérente à partir de laquelle cette transaction jusqu'à ce qu'il commence ou annule. Cela signifie que, à tout moment un seul tuple peut avoir plus d'une version live dans la base de données. En raison de la façon dont MVCC est mis en œuvre pgsql, ces deux versions existent en même temps dans le magasin de données. Finalement, tous, mais les plus récents seront les plus âgés que la plus ancienne transaction en cours d'exécution, et peuvent être récupérés et réutilisés par la db. Le processus qui reprend ces vieilles lignes mortes est appelée passer l'aspirateur.

Dans 8.3 les anciens blocs morts ont été gardé la trace de un segment de mémoire partagée appelée la carte de l'espace libre. Si soit les aspirateurs ne sont pas assez agressifs ou si vous manquez d'espace sur la carte de l'espace libre, alors la base de données pourrait faire tuples morts plus vite qu'il pourrait les récupérer (vide) ou les retenir (carte d'espace libre).

Avec la carte 8.4 de l'espace libre est sans entretien à l'utilisateur car il est stocké sur le disque dur dans des fichiers .fsm. mais le problème avec le vide existe toujours. autovacuum est accordé ne pas être trop agressif pour ne pas tuer quelque chose comme un ordinateur portable ou un petit serveur lorsqu'il est installé. Sur des machines plus grandes avec beaucoup de capacité IO comme un serveur avec 16 disques SSD dans une matrice RAID-10, vous pouvez mettre en marche l'agressivité de autovacuum et il peut suivre des taux de tps assez fou. Vous pouvez obtenir soutenue 1000 à 3000 transactions par seconde sur de longues périodes sur un serveur avec un assez agressif autovacuum et un contrôleur RAID matériel rapide avec beaucoup de disques. numéros TPS approchant 10 000 sont possibles avec des serveurs plus chers et plus. Tout en service 100s de connexions.

tl; dr: 8.3 est vieux et def eu quelques problèmes. 8.4 et jusqu'à ont une meilleure récupération de l'espace libre, mais encore besoin autovac agressif pour suivre une lourde charge.

Answer 2

3) J'entendu de nombreuses réponses négatives sur PostgreSQL étant buggy et non optimisé pour modifier et stocker de grandes séries de données. La seule raison pour laquelle il est encore utilisé dans certains petits projets commerciaux est parce qu'il est gratuit. Quelles sont vos opinions sur ce sujet?

Ceci est FUD. PostgreSQL est entièrement comporté, SGBDR haute performance utilisé dans plusieurs déploiements à grande échelle.

Answer 3

2) A propos de l'utilisation de MySQL Community Edition actuelle serveur 5.5.16 avec GPL: si une architecture logicielle de projet est conçu avec le soutien pour le branchement est alors beaucoup DBMSs il légal d'avoir un logiciel de projet sous licence GPL non? Je veux dire, supposons que le logiciel est conçu avec plusieurs SGBD prennent en charge et le logiciel est mis sous licence commerciale. Si le client choisit d'utiliser la version GPL de MySQL, il ne viole la licence GPL?

Dès que vous établissez un lien avec une bibliothèque sous licence GPL, est autorisé le corps de code sous la licence GPL. Oracle fait une exception pour d'autres que des licences libres.

Answer 4

3) J'ai entendu beaucoup de réponses négatives sur PostgreSQL et étant buggé non optimisée pour la modification et le stockage de grands ensembles de données. Le seul raison pour laquelle il est encore utilisé dans certains petits projets commerciaux parce que c'est gratuit. Quelles sont vos opinions sur ce sujet?

ROFL

Vous plaisantez! FUD pure et rien d'autre.

Nous avons deux To de données dans une base de données PostgreSQL et il est encore en croissance par mois au sujet de 200GB. Pas d'insectes, pas de problème, juste des performances exceptionnelles. Également à 500 utilisateurs simultanés, aucun problème. Consultez la liste de diffusion pour compter les bugs et voir à quelle vitesse ils sont résolus. Ne soyez pas surpris quand il y a une solution en quelques heures. MySQL peut apprendre de cela.

http://archives.postgresql.org/pgsql-bugs/

Answer 5

J'ai eu le même problème. Plus tôt j'ai utilisé MySQL dans des projets commerciaux. Mais après oracle a repris et les changements de politique de licence, je cherchais d'autres options, y compris SQL Express, DB2-Express, SQL-lite, PostgreSql

Je ne vais pas entrer dans les comparaisons, car il y a beaucoup d'informations autour. Mais PostgreSql est de loin le meilleur par rapport à

a) le traitement grands ensembles de données

b) les normes SQL

c) Documentation intégrée

d) les statistiques d'utilisation de base de données

enfait, je pourrais commencer un projet du jour au lendemain, sans frais généraux sur les modifications des commandes SQL ou la documentation.

Cependant, depuis que je suis en utilisant dotnet sur les fenêtres, Npgsql est le seul connecteur de confiance autour qui nous fait peur.

Mais pour le développement loin avec PostgreSql 9.0 a été tout à fait un gâteau.