¿Qué versión y cómo usar MySQL DBMS gratuito en proyectos comerciales? [cerrado

StackOverflow https://stackoverflow.com/questions/7818582

Pregunta

Actualmente, MySQL Community Edition Server 5.5.16 está bajo GPL. Esto significa que podría usarse en proyectos que también son proyectos de código abierto. Nuestro presupuesto de proyecto es muy ajustado y necesitamos encontrar una solución para usar MySQL Free Edition en Proyectos Comerciales. Tengo varias preguntas:

1) ¿Qué versión anterior de MySQL sería lo suficientemente sólida y libre de errores para usar en proyectos comerciales?

2) Acerca de el uso de MySQL Community Edition Server actual 5.5.16 con GPL: si una arquitectura de software de proyecto está diseñada con soporte para conectar muchos DBMS, ¿es legal tener un software de proyecto bajo la licencia que no sea GPL? Quiero decir, supongo que el software está diseñado con múltiples soporte de DBMS y el software se pone bajo licencia comercial. Si el cliente elige usar la versión MySQL GPL, ¿viola la licencia GPL?

3) Escuché algunas respuestas negativas sobre que PostgreSQL no era erróneo y no optimizado para modificar y almacenar grandes conjuntos de datos. La única razón por la que todavía se usa en algunos pequeños proyectos comerciales es porque es gratis. ¿Cuáles son tus opiniones sobre eso?

ACTUALIZACIÓN: Además, estamos planeando usar varios servidores, por lo que también se necesita replicación maestra-esclavo.

Actualización2: Escuché sobre un caso: se usó ~ 1GB PostgreSQL DB. La base de datos se utilizó fuertemente con actualizaciones modificando casi todos los datos. El problema era que la base de datos crecía constantemente unas diez veces cada 2.5 meses. Han utilizado PostgreSQL 8.3 + CentOS. Además, se utilizó autovacuum. Después de descargar la base de datos, destruir la antigua, recrear la base de datos e importar, pudieron reducir su tamaño ~ 10 veces. Publicaciones existentes (aquí y aquí) Muestre que este problema es relativo incluso en la última versión de PostgreSQL 9. No lo llamaría un comportamiento normal y tal crecimiento del tamaño no es aceptable en nuestro caso.

Actualización3: Gracias a todos por las respuestas. Todas las respuestas son relativas y útiles para la pregunta.

¿Fue útil?

Solución

Los otros carteles han mencionado que básicamente vincular a MySQL significa que ha licenciado el Proyecto GPL o alguna otra licencia de sistema operativo Oracle / MySQL hace una excepción, o es comercial y le debe dinero. De todos modos...

Ok, PostgreSQL almacena sus datos en un almacén de datos que admite MVCC, control de concurrencia de múltiples versiones. Esto significa en un nivel simple que cada transacción obtiene una instantánea de la base de datos que es coherente de cuando esa transacción comienza hasta que se compromete o retrocede. Esto significa que en cualquier momento, una sola tupla puede tener más de una versión en vivo en la base de datos. Debido a la forma en que se implementa MVCC en PGSQL, esas dos versiones existen al mismo tiempo en el almacén de datos. Eventualmente, todos menos los más nuevos serán más antiguos que la transacción de ejecución más antigua, y pueden ser recuperadas y reutilizadas por el DB. El proceso que reclama estas viejas tuplas muertas se llama aspiradora.

En 8.3, los viejos bloques muertos se hicieron un seguimiento con un segmento de memoria compartido llamado Mapa del espacio libre. Si las aspiradoras no son lo suficientemente agresivas o si se queda sin espacio en el mapa del espacio libre, la base de datos podría hacer tuplas muertas más rápido de lo que podría recuperarlas (vacío) o recordarlas (mapa de espacio libre).

Con 8.4, el mapa de espacio libre se vuelve gratuito para el usuario porque se almacena en el disco duro en archivos .fsm. Sin embargo, el problema con el vacío todavía existe. Autovacuum está sintonizado para no ser demasiado agresivo para no matar algo como una computadora portátil o un servidor pequeño cuando se instala. En máquinas más grandes con mucha capacidad de IO como un servidor con 16 SSD en una matriz RAID-10, puede aumentar la agresividad de Autovacuum y puede mantenerse al día con algunas tarifas de TPS bastante locas. Puede obtener de 1,000 a 3.000 transacciones por segundo durante largos períodos en un servidor con un autovacuum lo suficientemente agresivo y un controlador de redacción de hardware rápido con muchos discos. Los números de TPS que se acercan a 10,000 son posibles con servidores más caros y más grandes. Todo mientras atiende 100s de conexiones.

tl; dr: 8.3 es viejo y Def tuvo algunos problemas. 8.4 y arriba tienen una mejor recuperación de espacio libre, pero aún así necesitan autovac agresivo para mantenerse al día con una carga pesada.

Otros consejos

3) Escuché muchas respuestas negativas sobre PostgreSQL que no son erróneos y no optimizan para modificar y almacenar grandes conjuntos de datos. La única razón por la que todavía se usa en algunos pequeños proyectos comerciales es porque es gratis. ¿Cuáles son tus opiniones sobre eso?

Esto es FUD. PostgreSQL es un RDBMS de alto rendimiento totalmente destacado que se usa en varias implementaciones a gran escala.

2) Acerca de el uso de MySQL Community Edition Server actual 5.5.16 con GPL: si una arquitectura de software de proyecto está diseñada con soporte para conectar muchos DBMS, ¿es legal tener un software de proyecto bajo la licencia que no sea GPL? Quiero decir, supongo que el software está diseñado con múltiples soporte de DBMS y el software se pone bajo licencia comercial. Si el cliente elige usar la versión MySQL GPL, ¿viola la licencia GPL?

Tan pronto como vincule con una biblioteca con licencia de GPL, todo el cuerpo de código tiene licencia bajo el GPL. Oracle hace un excepción Solo para otras licencias gratuitas.

3) Escuché muchas respuestas negativas sobre PostgreSQL que no son erróneos y no optimizan para modificar y almacenar grandes conjuntos de datos. La única razón por la que todavía se usa en algunos pequeños proyectos comerciales es porque es gratis. ¿Cuáles son tus opiniones sobre eso?

Rofl

¡Usted debe estar bromeando! Puro FUD y nada más.

Tenemos un par de TB de datos en una base de datos PostgreSQL y todavía está creciendo alrededor de 200 GB por mes. Sin errores, sin problemas, solo un gran rendimiento. También a 500 usuarios concurrentes, no hay problemas en absoluto. Verifique la lista de correo para contar los errores y vea qué tan rápido se resuelven. No se sorprenda cuando hay una solución en cuestión de horas. MySQL puede aprender de eso.

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

Yo tuve el mismo problema. Anteriormente usé MySQL en proyectos comerciales. Pero después de que Oracle se hizo cargo y los cambios en la política de licencia, busqué otras opciones que incluyan SQL-Express, DB2-Express, SQL-Lite, PostgreSQL

No entraré en las comparaciones, porque hay mucha información. Pero PostgreSQL es, con mucho, el mejor con respecto a

a) manejo de grandes conjuntos de datos

b) estándares SQL

c) Documentación en línea

d) Estadísticas de uso de la base de datos

De hecho, podría comenzar un proyecto de la noche a la mañana, sin gastos generales con respecto a los cambios en los comandos o documentación SQL.

Sin embargo, dado que estoy usando Dotnet en Windows, NPGSQL es el único conector de confianza en el que nos asusta.

Pero hasta ahora desarrollar con PostgreSQL 9.0 ha sido absolutamente un pastel.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top