Можно ли использовать mysql в коммерческих проектах

спользование MySQL в коммерческих целях / MySQL

Ссылка на сообщение

Ссылка (включая название темы)

Ссылка (URL)

x

Источник

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

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

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

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

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

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

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

ОБНОВЛЕНИЕ3: спасибо всем за ответы. Все ответы относительны и полезны для вопроса.

Centurion 19 окт ’11 в 08:35 2011-10-19 08:35

2011-10-19 08:35

5 ответов

Решение

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

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

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

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

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

2011-10-20 09:01

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

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

Fred Foo 19 окт ’11 в 08:44 2011-10-19 08:44

2011-10-19 08:44

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

Это ФУД. PostgreSQL — это полнофункциональная высокопроизводительная СУБД, используемая в нескольких крупномасштабных развертываниях.

2011-10-19 08:39

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

ROFL

Ты, должно быть, шутишь! Чистая ФУД и больше ничего.

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

https://s.postgresql.org/pgsql-bugs/

2011-10-19 09:14

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

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

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

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

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

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

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

Тем не менее, поскольку я использую dotnet в Windows, Npgsql является единственным надежным соединителем, который нас пугает.

Но пока что разработка с PostgreSql 9.0 была абсолютно легкой.

arvind 19 окт ’11 в 10:22 2011-10-19 10:22

2011-10-19 10:22

Источник

База данных в коммерческом проекте: как поступить?

Всех с окончанием праздников!… Некоторые скажут, что это поздравление — так себе. Но, наверняка, у многих скоро отпуск, так что поднажмите еще немного. Ну а мы не сдаем обороты и в этот теплый день делимся опытом наших партнеров. Речь пойдет об оптимизации работы с базой данных. Подробнее под катом!

Передаю слово автору.

Приветствуем вас, читатели Хабра! Мы команда WaveAccess, в этой статье поделимся с вами опытом применения службы баз данных (БД) Azure Cosmos DB в коммерческом проекте. Расскажем, для чего предназначена БД, и нюансы, с которыми нам пришлось столкнуться во время разработки.

Что такое Azure Cosmos DB

Azure Cosmos DB — это коммерческая глобально-распределенная служба база данных с мульти-модельной парадигмой, предоставляется как PaaS решение. Она является следующим поколением Azure DocumentDB.

База данных была разработана в 2017 г. в корпорации Microsoft при участии доктора компьютерных наук Лесли Лэмпорт (лауреата Премии Тьюринга 2013 г. за фундаментальный вклад в теорию распределенных систем, разработчик LaTex, создателя спецификации TLA+).

Главные характеристики Azure Cosmos DB это:

• Нереляционная база данных;
• Документы в ней хранятся в виде JSON;
• Горизонтальное масштабирование с возможностью выбора географических регионов;
• Мульти-модельная парадигма данных: ключ-значение, документное, графовое, семейство столбцов;
• Низкая задержка для 99% запросов: менее 10 мс для операций чтения и менее 15 мс для (индексированных) операций записи;
• Спроектирована для высокой пропускной способности;
• Гарантирует доступность, согласованность данных, задержку на уровне SLA 99,999%;
• Настраиваемая пропускная способность;
• Автоматическая репликация (master-slave);
• Автоматическое индексирование данных;
• Настраиваемые уровни согласованности данных. 5 различных уровней (Strong, Bounded Staleness, Session, Consistent Prefix, Eventual);

На графике можно видеть зависимость различных уровней согласованности от доступности, производительности и согласованности данных.

• Для удобного перехода на Cosmos DB со своей базы данных предусмотрено множество API для доступа к данным: SQL, JavaScript, Gremlin, MongoDB, Cassandra, Azure Blob;
• Настраиваемый брандмауэр;
• Настраиваемый размер БД.

Задача, которую мы решали

Тысячи датчиков, расположенные по всему миру, передают информацию (в дальнейшем нотификации) каждые несколько N-секунд. Эти нотификации должны сохраняться в БД, а в дальнейшем осуществляться поиск по ним и их отображение в UI оператора системы.

Требования от заказчика:

• Использование стек технологий Microsoft, в том числе облако Azure;
• Пропускная способность 100 запросов в секунду;
• Нотификации не имеют четкой структуры и могли в дальнейшем расширяться;
• Для критических нотификаций важна скорость обработки;
• Высокая отказоустойчивость системы.

Исходя из требований заказчика нам идеально подошла нереляционная, глобально-распределенная, надежная коммерческая БД.

Если рассмотреть похожие на Cosmos DB базы данных, то можно вспомнить об Amazon DynamoDB, Google Cloud Spanner. Но Amazon DynamoDB не является глобально-распределенной, а Google Cloud Spanner имеет меньше уровней согласованности и видов моделей данных (только табличное представление, реляционное).

По этим причинам мы остановились на Azure Cosmos DB. Для взаимодействия с БД использовали Azure Cosmos DB SDK для .NET, так как бэкенд был написан на .NET.

Нюансы, с которыми мы столкнулись

1. Управление базой данных

Для того, чтобы начать пользоваться базой данных, в первую очередь нужно выбрать инструмент для управления ей. Мы использовали Azure Cosmos DB Data Explorer в портале Azure и DocumentDbExplorer. Также существует утилита Azure Storage Explorer.

2. Настройка коллекций БД

В Cosmos DB каждая БД состоит из коллекций и документов.

Настраиваемые характеристики коллекции, на которые следует обратить внимание:

• Размер коллекции: фиксированная или неограниченная;
• Пропускная способность в единиц запросов в секунду RU/s (от 400 RU/s);
• Политика индексации (включение или исключение документов и путей к индексу и из него, настройка различных типов индекса, настройка режимов обновления индекса).

Пример типичного индекса

{ «id»: «datas», «indexingPolicy»: { «indexingMode»: «consistent», «automatic»: true, «includedPaths»: [ { «path»: «/*», «indexes»: [ { «kind»: «Range», «dataType»: «Number», «precision»: -1 }, { «kind»: «Hash», «dataType»: «String» }, { «kind»: «Spatial», «dataType»: «Point» } ] } ], «excludedPaths»: [] } }

Чтобы работал поиск по подстроке, для строковых полей нужно использовать Hash-индекс («kind»: «Hash»).

3. Транзакции БД

Транзакции реализованы в БД на уровне хранимых процедур (выполнение хранимой процедуры — это атомарная операция). Хранимые процедуры пишутся на JavaScript

var helloWorldStoredProc = { id: «helloWorld», body: () { var context = getContext(); var response = context.getResponse(); response.setBody(«Hello, World»); } }

4. Канал изменений БД

Change Feed (канал изменений) прослушивает изменения в коллекции. Когда происходят изменения документов коллекции, то БД «выкидывает» событие об изменениях всем подписчикам этого канала.

Мы использовали Change Feed для отслеживания изменений коллекции. При создании канала нужно предварительно создать вспомогательную коллекцию AUX, которая координирует обработку канала изменений для нескольких рабочих ролей.

5. Ограничения БД:

• Отсутствие bulk-операций (использовали хранимые процедуры для массового удаления, обновления документов);
• Отсутствие частичного обновления документа;
• Нет операции SKIP (сложность реализации пагинации). Чтобы реализовать пагинацию в запросах получения нотификаций мы использовали параметры RequestContinuation (ссылка на последний элемент в результате выдачи) и MaxItemCount (количество элементов возвращаемой из БД). По умолчанию результаты возвращаются в пакетах (не более 100 элементов и не более 1 МБ в каждом пакете). Количество возвращаемых элементов можно увеличить до 1000 с помощью параметра MaxItemCount.

6. Обработка 429-ой ошибки БД

Когда пропускная способность коллекции достигает максимума, то база данных начинает выдавать ошибку «429 Too Many Request». Для ее обработки можно воспользоваться настройкой RetryOptions в SDK, где MaxRetryAttemptsOnThrottledRequests — это количество попыток выполнения запроса, а MaxRetryWaitInSeconds — это суммарное время выполнения попыток подключения.

7. Прогноз стоимости использования БД

Чтобы спрогнозировать стоимость использования базы данных, мы использовали онлайн-калькулятор RU/s. В базовом плане одна единица запроса для элемента размером 1 КБ соответствует простой команде GET по ссылке на себя или идентификатору этого элемента.

Выводы

Azure Cosmos DB удобна в использовании, легко и гибко настраивается через портал Azure. Множество API для доступа к данным позволяют быстро осуществить переход на Сosmos DB. Не нужно привлекать администратора баз данных для обслуживания базы данных. Финансовые гарантии SLA, глобальное горизонтальное масштабирование делают эту базу данных очень привлекательной на рынке. Она подходит для использования в корпоративных и глобальных приложениях, которые предъявляют высокие требования к отказоустойчивости и пропускной способности. Мы в WaveAccess продолжаем использовать Cosmos DB в наших проектах.

Об авторе

Команда WaveAccess создаёт технически сложное высоконагруженное отказоустойчивое ПО для компаний всего мира. Александр Азаров, старший вице-президент по разработке ПО в WaveAccess, комментирует:

Сложные на первый взгляд задачи можно решить сравнительно простыми методами. Важно не только изучать новые инструменты, но и доводить до совершенства знание привычных технологий.

Блог компании

Источник