Какая версия и как использовать бесплатные СУБД MySQL в коммерческих проектах? [закрыто

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

Вопрос

В настоящее время MySQL Community Edition Server 5.5.16 находится под GPL. Это означает, что он может быть использован в проектах, которые также являются проектами с открытым исходным кодом. Наш бюджет проекта очень жесткий, и нам нужно найти решение для использования MySQL Free Edition в коммерческом проекте. У меня есть несколько вопросов:

1) Какая ранее версия MySQL будет достаточно прочной и достаточно без ошибок, чтобы использовать в коммерческих проектах?

2) Об использовании текущего MySQL Community Edition Server 5.5.16 с GPL: если архитектура программного обеспечения проекта разработана с поддержкой подключения многих DBMS, то законно ли иметь проектное программное обеспечение по лицензии без GPL? Я имею в виду, предположим, что программное обеспечение разработано с поддержкой нескольких СУБД, а программное обеспечение помещается по коммерческой лицензии. Если клиент решит использовать версию MySQL GPL, он нарушает лицензию GPL?

3) Я слышал, как некоторые негативные ответы о том, что PostgreSQL стал глюми и не оптимизирован для изменения и хранения больших наборов данных. Единственная причина, по которой он все еще используется в некоторых небольших коммерческих проектах, заключается в том, что это бесплатно. Что вы думаете об этом?

ОБНОВЛЕНИЕ: Кроме того, мы планируем использовать несколько серверов, поэтому также необходима репликация мастер-рабов.

ОБНОВЛЕНИЕ2: Я слышал об одном случае: использовался ~ 1 ГБ PostgreSQL DB. База данных широко использовалась с обновлениями путем изменения почти всех данных. Проблема заключалась в том, что база данных постоянно растет примерно в десять раз каждые 2,5 месяца. Они использовали PostgreSQL 8.3 + centos. Также использовался Autovacuum. После сброса базы данных, уничтожения старой, воссоздания базы данных и импорта, они смогли уменьшить его размер ~ 10 раз. Существующие посты (здесь а также здесь) Покажите, что эта проблема относительна даже в последней версии PostgreSQL 9. Я бы не назвал это нормальным поведением, и такой размер рост не приемлем в нашем случае.

Обновление3: Спасибо всем за ответы. Все ответы относительны и полезны для вопроса.

Это было полезно?

Решение

Другие плакаты упомянули, что в основном ссылка на MySQL означает, что вы лицензировали GPL Project или какую -либо другую лицензию ОС Oracle / MySQL, за это исключение, или это коммерческое, и вы должны им деньги. Тем не мение...

ОК, PostgreSQL хранит свои данные в хранилище данных, которая поддерживает MVCC, управление параллелизмом с несколькими версиями. Это означает, что на простом уровне каждая транзакция получает снимок базы данных, которая является когерентной, когда эта транзакция начинается, пока она не совершит или не откажется назад. Это означает, что в любой момент времени у одного кортежа может быть более одной живой версии в базе данных. Из -за того, как MVCC реализован в PGSQL, эти две версии существуют одновременно в хранилище данных. В конце концов все, кроме самых новых, будут старше, чем самая старая работающая транзакция, и может быть восстановлен и повторно использован БД. Процесс, который восстанавливает эти старые мертвые кортежи, называется пылесосом.

В 8.3 старые мертвые блоки отслеживали с общим сегментом памяти, называемой картой свободного пространства. Если либо вакуумы недостаточно агрессивны, либо если у вас не хватает места на карте свободного пространства, то база данных может сделать мертвые платки быстрее, чем они могли бы восстановить их (вакуум) или запомнить их (карта свободного пространства).

С 8.4 карта свободного пространства становится бесплатным для пользователя, потому что она хранится на жестком диске в файлах .fsm. Однако проблема с вакуумом все еще существует. Autovacuum настроен, чтобы быть не слишком агрессивным, чтобы не убивать что -то вроде ноутбука или небольшого сервера при установке. На более крупных машинах с большим количеством возможностей ввода-вывода, таких как сервер с 16 SSD в массиве RAID-10, вы можете запустить агрессивность AutoVacuum, и это может не отставать от довольно сумасшедших ставок TPS. Вы можете получить от 1000 до 3000 транзакций в секунду в течение длительных периодов на сервере с достаточно агрессивным Autovacuum и быстрым аппаратным контроллером RAID с большим количеством дисков. Числа TPS, приближающиеся к 10 000, возможны с более дорогими и более крупными серверами. Все во время обслуживания сотюдных соединений.

TL; DR: 8.3 старый, и у DEF были некоторые проблемы. 8.4 и выше имеют лучшее восстановление свободного пространства, но все же нуждается в агрессивном Autovac, чтобы не отставать от тяжелой нагрузки.

Другие советы

3) Я слышал, как много негативных ответов о том, что PostgreSQL стал багги и не оптимизирован для изменения и хранения больших наборов данных. Единственная причина, по которой он все еще используется в некоторых небольших коммерческих проектах, заключается в том, что это бесплатно. Что вы думаете об этом?

Это FUD. PostgreSQL - это полностью показанная высокопроизводительная RDBMS, используемые в нескольких крупномасштабных развертываниях.

2) Об использовании текущего MySQL Community Edition Server 5.5.16 с GPL: если архитектура программного обеспечения проекта разработана с поддержкой подключения многих DBMS, то законно ли иметь проектное программное обеспечение по лицензии без GPL? Я имею в виду, предположим, что программное обеспечение разработано с поддержкой нескольких СУБД, а программное обеспечение помещается по коммерческой лицензии. Если клиент решит использовать версию MySQL GPL, он нарушает лицензию GPL?

Как только вы ссылаетесь на GPL-лицензированную библиотеку, весь объем кода лицензирован под GPL. Oracle делает исключение Только для других бесплатных лицензий.

3) Я слышал, как много негативных ответов о том, что PostgreSQL стал багги и не оптимизирован для изменения и хранения больших наборов данных. Единственная причина, по которой он все еще используется в некоторых небольших коммерческих проектах, заключается в том, что это бесплатно. Что вы думаете об этом?

Rofl

Ты, должно быть, шутишь! Чистый FUD и ничего больше.

У нас есть пара туберкулеза данных в базе данных PostgreSQL, и она все еще растет около 200 ГБ в месяц. Нет ошибок, нет проблем, просто отличная производительность. Также в 500 одновременных пользователях нет проблем вообще. Проверьте список рассылки, чтобы подсчитать ошибки и посмотреть, как быстро они решаются. Не удивляйтесь, когда есть исправление в течение нескольких часов. MySQL может извлечь уроки из этого.

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

У меня такая же проблема. Ранее я использовал MySQL в коммерческих проектах. Но после того, как Oracle вступил во владение и изменения политики лицензии, я искал другие варианты, включая SQL-Express, DB2-EXPRESS, SQL-Lite, PostgreSQL

Я не буду идти в сравнение, потому что вокруг много информации. Но PostgreSQL, безусловно, самый лучший в отношении

а) Обработка больших наборов данных

б) стандарты SQL

в) встроенная документация

г) Статистика использования базы данных

На самом деле, я мог бы запустить проект в одночасье, без каких -либо накладных расходов относительно изменений в командах SQL или документации.

Однако, поскольку я использую Dotnet в Windows, NPGSQL является единственным надежным разъемом, вокруг которого нас пугает.

Но до сих пор развивается с PostgreSQL 9.0, был абсолютно торт.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top