MongoDB разработала собственный тип Open Source лицензии

Оглавление (нажмите, чтобы открыть):

доступные технологии для вашего бизнеса

. because open source matters

Типы лицензий Open Source

Заблуждения, относительно того, что с программными продуктами open source можно делать все что угодно в личных и коммерческих целях, сильно распространено. У большинства людей такое ПО ассоциируется со словом «бесплатно», но на самом деле в разработанных open source-лицензиях ничего не говорится о цене программ, распространяемых таким образом.

Открытый код означает именно то, что написано, – исходный код таких программ доступен для ознакомления и модификации, а лицензии описывают, что можно делать с этим кодом, а чего делать нельзя. Данные ограничения затрагивают в основном коммерческих разработчиков программных продуктов и электронного оборудования.

Как лицензия MongoDb определяет «коммерческое» и «некоммерческое» использование?

У меня вопрос по поводу «коммерческого» и «некоммерческого» использования, в том числе с использованием MongoDb.

Давайте представим, что у нас есть сайт без бизнес-модели, популярность сайта растет, но все еще нет прибыльных денег. Мы говорим о некоммерческом на данный момент?

И как только сайт начинает зарабатывать деньги, разрешается ли в этот момент принимать решение о получении коммерческой лицензии?

Спасибо за помощь.

2 ответа

Лицензирование MongoDB выглядит довольно простым. Это лицензия AGPL 3.0 с лицензированными драйверами Apache, что означает, что вы можете бесплатно использовать ее в коммерческих целях, если вы вносите любые улучшения, которые вы делаете, в фактическую базу данных обратно в проект.

Более подробную информацию и мотивы см. на связанной странице.

Любое программное обеспечение, имеющее отдельные условия лицензии для коммерческого и некоммерческого использования, должно определять эти условия в лицензии. Если они не определяют термины, вам нужно спросить их, что они означают.

Для вашего конкретного вопроса о MongoDB коммерческий вариант лицензирования существует только в том случае, если вы не хотите или не можете соблюдать условия AGPL. Я понимаю, что если вы соблюдаете условия AGPL, вы можете использовать MongoDB для любых целей, коммерческих или нет, и если вы не хотите соблюдать AGPL, вы должны получить коммерческую лицензию, даже если ваше приложение некоммерческое .

Как и в случае с большинством вопросов о лицензировании: задайте владельцу авторского права такие вопросы. Они знают лучше, чем случайные люди в Интернете.

Введение в MongoDB

Что такое MongoDB

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

Со времен динозавров было обычным делом хранить все данные в реляционных базах данных (MS SQL, MySQL, Oracle, PostgresSQL). При этом было не столь важно, а подходят ли реляционные базы данных для хранения данного типа данных или нет.

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

Но, даже учитывая все недостатки традиционных баз данных и достоинства MongoDB, важно понимать, что задачи бывают разные и методы их решения бывают разные. В какой-то ситуации MongoDB действительно улучшит производительность вашего приложения, например, если надо хранить сложные по структуре данные. В другой же ситуации лучше будет использовать традиционные реляционные базы данных. Кроме того, можно использовать смешенный подход: хранить один тип данных в MongoDB, а другой тип данных — в традиционных БД.

Вся система MongoDB может представлять не только одну базу данных, находящуюся на одном физическом сервере. Функциональность MongoDB позволяет расположить несколько баз данных на нескольких физических серверах, и эти базы данных смогут легко обмениваться данными и сохранять целостность.

Формат данных в MongoDB

Одним из популярных стандартов обмена данными и их хранения является JSON (JavaScript Object Notation). JSON эффективно описывает сложные по структуре данные. Способ хранения данных в MongoDB в этом плане похож на JSON, хотя формально JSON не используется. Для хранения в MongoDB применяется формат, который называется BSON (БиСон) или сокращение от binary JSON.

BSON позволяет работать с данными быстрее: быстрее выполняется поиск и обработка. Хотя надо отметить, что BSON в отличие от хранения данных в формате JSON имеет небольшой недостаток: в целом данные в JSON-формате занимают меньше места, чем в формате BSON, с другой стороны, данный недостаток с лихвой окупается скоростью.

Кроссплатформенность

MongoDB написана на C++, поэтому ее легко портировать на самые разные платформы. MongoDB может быть развернута на платформах Windows, Linux, MacOS, Solaris. Можно также загрузить исходный код и самому скомпилировать MongoDB, но рекомендуется использовать библиотеки с офсайта.

Документы вместо строк

Если реляционные базы данных хранят строки, то MongoDB хранит документы. В отличие от строк документы могут хранить сложную по структуре информацию. Документ можно представить как хранилище ключей и значений.

Ключ представляет простую метку, с которым ассоциировано определенный кусок данных.

Однако при всех различиях есть одна особенность, которая сближает MongoDB и реляционные базы данных. В реляционных СУБД встречается такое понятие как первичный ключ . Это понятие описывает некий столбец, который имеет уникальные значения. В MongoDB для каждого документа имеется уникальный идентификатор, который называется _id . И если явным образом не указать его значение, то MongoDB автоматически сгенерирует для него значение.

Каждому ключу сопоставляется определенное значение. Но здесь также надо учитывать одну особенность: если в реляционных базах есть четко очерченная структура, где есть поля, и если какое-то поле не имеет значение, ему (в зависимости от настроек конкретной бд) можно присвоить значение NULL . В MongoDB все иначе. Если какому-то ключу не сопоставлено значение, то этот ключ просто опускается в документе и не употребляется.

Коллекции

Если в традиционном мире SQL есть таблицы, то в мире MongoDB есть коллекции. И если в реляционных БД таблицы хранят однотипные жестко структурированные объекты, то в коллекции могут содержать самые разные объекты, имеющие различную структуру и различный набор свойств.

Репликация

Система хранения данных в MongoDB представляет набор реплик. В этом наборе есть основной узел, а также может быть набор вторичных узлов. Все вторичные узлы сохраняют целостность и автоматически обновляются вместе с обновлением главного узла. И если основной узел по каким-то причинам выходит из строя, то один из вторичных узлов становится главным.

Простота в использовании

Отсутствие жесткой схемы базы данных и в связи с этим потребности при малейшем изменении концепции хранения данных пересоздавать эту схему значительно облегчают работу с базами данных MongoDB и дальнейшим их масштабированием. Кроме того, экономится время разработчиков. Им больше не надо думать о пересоздании базы данных и тратить время на построение сложных запросов.

GridFS

Одной из проблем при работе с любыми системами баз данных является сохранение данных большого размера. Можно сохранять данные в файлах, используя различные языки программирования. Некоторые СУБД предлагают специальные типы данных для хранения бинарных данных в БД (например, BLOB в MySQL).

В отличие от реляционных СУБД MongoDB позволяет сохранять различные документы с различным набором данных, однако при этом размер документа ограничивается 16 мб. Но MongoDB предлагает решение — специальную технологию GridFS, которая позволяет хранить данные по размеру больше, чем 16 мб.

Система GridFS состоит из двух коллекций. В первой коллекции, которая называется files , хранятся имена файлов, а также их метаданные, например, размер. А в другой коллекции, которая называется chunks , в виде небольших сегментов хранятся данные файлов, обычно сегментами по 256 кб.

Для тестирования GridFS можно использовать специальную утилиту mongofiles, которая идет в пакете mongodb.

Открытые встречи с Петром Зайцевым (CEO Percona) пройдут в Рязани и Нижнем Новгороде 5 и 9 ноября

Компания «Перкона» (Percona) организует два открытых мероприятия в России в начале ноября. 5 и 9 ноября в Рязани и Нижнем Новгороде пройдут встречи с Петром Зайцевым (Peter Zaitsev), генеральным директором Percona, соавтором книги «MySQL по максимуму», бывшим руководителем группы оптимизации производительности в компании MySQL AB.

Программа встреч в обоих городах одинакова. Доклады Петра:

— “Что разработчик должен знать о базах данных”,

— “Оптимизация и отладка открытых СУБД с помощью Percona Monitoring and Management 2.0”.

Время и место проведения:

5 ноября 2020, Рязань. АМАКС Конгресс-отель 4* (Первомайский проспект, 54).

Сбор участников: 19:00, начало докладов: 19:30.

9 ноября 2020, Нижний Новгород. Родионова, 192/2, Офис Росбанка (служебный вход).

Сбор участников: 17:30, начало докладов: 18:00

Для доступа на площадку (Росбанк) необходим документ, удостоверяющий личность.

Вход на оба мероприятия свободный при условии регистрации.

В Debian и Fedora не одобрили новую лицензию MongoDB

Некоторое время назад, разработчики MongoDB сменили лицензию проекта с AGPLv3 на SSPLv1 (Server Side Public License). SSPLv1 — лицензия собственной разработки проекта MongoDB, основанная на AGPLv3, но включающая дополнительные ограничения, запрещающие предоставлять продукт под этой лицензией в виде сервиса без предоставления исходников всех систем, взаимодействующих с продуктом любым способом, даже через сеть.

Пока в OSI обсуждают, подходит ли SSPLv1 под определения Open Source, разработчики Debian и Fedora приняли решение не включать софт под этой лицензией в свои репозитории:

В результате, пакеты MongoDB скорее всего будут удалены из репозиториев этих дистрибутивов ввиду невозможности дальнейшего их обновления. Бэкпортирование изменений из более новых версий MongoDB также невозможно из-за несовместимости SSPLv1 с AGPLv3.

MongoDB сменила лицензию

MongoDB объявила, что все новые версии будут выходить под их собственной лицензией — SSPL.

Лицензия основана на GPL3. Главное отличие в том, что теперь надо выпускать свой код (либо приобрести коммерческую лицензию) всем, кто предоставляет MongoDB как сервис. То есть предоставляет третьим лицам возможность пользоваться своей установкой MongoDB.

Интересно, что в списке компаний, поведение которых толкнуло MongoDB пойти на этот шаг, указан Яндекс (Alibaba и Tencent другие компании в списке). Список упомянут в интервью The Register.

Open Source Initiative объявила, что MongoDB теперь не может считаться Open Source, по крайней мере до окончания процесса рассмотрения новой лицензии.

В MongoDB 4.0 появилась поддержка транзакций

Состоялся релиз новой версии NoSQL СУБД MongoDB. В новой версии разработчики добавили то, чего клиенты ждали долгие годы — транзакционность на уровне многих документов с уровнем изоляции Snapshot. Отныне разработчикам не нужно писать дополнительный код, который будет обеспечивать консистентность базы данных. Тем самым MongoDB убрала самый главный недостаток, который мешал многим разработчикам использовать эту СУБД в своих проектах.

Пока транзакции возможны только в режиме replica-set. Чтобы получить преимущества транзакций внутри шардированного кластера, нужно подождать версии 4.2.

Percona Memory Engine для MongoDB на базе WiredTiger

Percona объявила о выпуске Memory Engine для MongoDB, открытого in-memory хранилища. In-memory хранилище на базе WiredTiger предусмотрено в MongoDB 3.2 Enterprise Edition, но отсутствует в MongoDB Community Edition. С выпуском Percona Memory Engine появится возможность без дополнительных затрат использовать аналогичное хранилище и для Percona Server.

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

  • Application Cache заменяет memcached и самописные структуры данных уровня приложения.
  • Real-time Analytics использует вычисления в памяти для тех случаев, когда время отклика важнее, чем сохранение данных.
  • Sophisticated Data Manipulation обеспечивает более высокую производительность при сложных операциях c данными, например, при агрегировании и MapReduce.
  • Session Management — хранение в памяти активных сессий пользователей для уменьшения времени отклика.
  • Transient Runtime State — хранение динамического состояния приложения.

Обзор решений компании Percona и их техническое устройство

Петр Зайцев, эксперт по производительности MySQL, создатель компании Percona Inc., бывший тимлидер группы High Perfomance в MySQL Inc и ведущий блога Percona Performance Blog, проведет открытую презентацию в стенах Политехнического университета 7 июля 2020 года в 16:00 (мск), на которой он поделится практическими знаниями в области оптимизации производительности СУБД с разработчиками баз данных и программного обеспечения, раскроет вопросы технического устройства программных решений компании «Percona».

«Percona» на данный момент является единственной компанией, поставляющей решения корпоративного уровня для MySQLⓇ и MongoDBⓇ. «Percona» оказывает услуги поддержки, консалтинга и удалённого администрирования СУБД. Кроме того, «Percona» распространяет Open Source программное обеспечение, включая Percona Server для MySQL, Percona Server для MongoDB, Percona XtraBackup, Percona XtraDB Cluster, Percona TokuDB, а также инструменты и утилиты для MySQL — Percona Monitoring Plugins и Percona Toolkit. Регулярно обновляемый Percona Performance Blog (ранее – MySQL Performance Blog) является одним из авторитетных источников информации по теме оптимизации производительности СУБД.

С 2013 года «Percona» входит в список 5000 наиболее быстро растущих компаний Inc. 5000. С 2009 года «Percona» занимается проведением конференций, в настоящее время конференции Percona Live регулярно проходят в США и Европе. Клиентами «Percona» являются более 3000 компаний по всему миру, в том числе Cisco Systems, Time Warner Cable, Alcatel-Lucent, Groupon и BBC.

Мы приглашаем Вас принять участие в данном мероприятии в качестве слушателя. Вход в конференц-зал свободный.

Организаторы мероприятия: Percona Inc., Центр компетенции СПО Санкт- Петербургского политехнического университета имени Петра Великого (ЦК СПО СПБПУ), ООО «ГНУ/Линуксцентр», ООО «Линукс Формат».

MongoDB 2.6

Сегодня объявлено о выходе новой версии документо-ориентированной СУБД MongoDB. Версия 2.6 является крупнейшим релизом MongoDB из когда-либо выходивших.

Виды лицензий Open Source

Картинка распостраняется под CC-BY-SA 3.0.

Рассмотрим кратко основные виды лицензий Open Source:

1) Лицензия MIT
Лицензия MIT разработана Массачусетским технологическим институтом (МТИ) и считается академической лицензией, то есть она признана к использованию в сфере научных разработок. На сайте GNU она имеет название Expat license. Кроме того, система XFree86 распространяется тоже под лицензией MIT, только в этом случае на сайте GNU она получила название X11 License.

2)Лицензия BSD
Лицензия BSD появилась в начале 1980-х специально для распространения операционной системы BSD. Существует три варианта текста этой лицензии:
1. Original BSD license или четырехпунктная лицензия BSD.
2. Modified BSD license («New BSD license» на сайте OSI) или трехпунктная лицензия BSD.
3. Лицензия корпорации Intel «BSD+Patent License» — специально разработана для модифицирования и распространения программ, которые могут защищаться патентами на программное обеспечение корпорации Intel. Эта лицензия не одобрена ни Open Source Initiative, ни FSF.
Самая первая лицензия BSD состояла из 4-х пунктов:
1. При повторном распространении исходного кода должно оставаться указанное выше уведомление об авторском праве, этот список условий и нижеследующий отказ от гарантий.
2. При повторном распространении двоичного кода должно воспроизводиться указанное выше уведомление об авторском праве, этот список условий и нижеследующий отказ от гарантий в документации и/или в других материалах, поставляемых при распространении.
3. Все рекламные материалы, упоминающие возможности либо использование этой программы, должны содержать следующее уведомление: «Этот продукт включает программное обеспечение, разработанное Калифорнийским Университетом Беркли и его жертвователями».
4. Ни название Университета, ни имена его сотрудников не могут быть использованы в качестве поддержки или продвижения продуктов, основанных на этом ПО без предварительного письменного разрешения.
Но в 1999 году по многочисленным просьбам третий пункт был исключен как «раздражающее соглашение о рекламе BSD» т. к. сложным системам, использующим код многих программ, приходилось прокручивать порой до десятка страниц рекламы. В результате появилась модифицированная трехпунктная лицензия BSD, которая сейчас является основной.
Кроме того, на сайте GNU выделяется еще одна двухпунктная лицензия «FreeBSD license», которая состоит только из двух первых пунктов лицензии BSD. На том же сайте GNU не рекомендуется называть эту лицензию «лицензией BSD», чтобы не вызывать неразбериху.

3)Лицензия GPL
GNU General Public License (Универсальная общедоступная лицензия GNU или Открытое лицензионное соглашение GNU) — самая популярная лицензия на свободное программное обеспечение, созданная в рамках проекта GNU. Первая версия лицензии GPL была выпущена в 1988 году, но затем она была откорректирована и в июне 1991 вышла версия 2 GPL, которая до сих пор является стандартом. GPL предоставляет получателям компьютерных программ следующие права, или «свободы»:
— свободу запуска программы, с любой целью;
— свободу изучения того, как программа работает, и ее модификации (предварительным условием для этого является доступ к исходному коду);
— свободу распространения копий;
— свободу улучшения программы, и выпуска улучшений в публичный доступ (предварительным условием для этого является доступ к исходному коду).
16 января 2006 г. на первой международной конференции по GPL 3, которая состоялась в MIT, был представлен первый черновой вариант лицензии. Разумеется, GPL 3 оказалась длиннее и сложнее GPL 2.
Практически сразу после этого Линус Торвальдс выразил свое разочарование в отношении лицензии GPLv3, заявив, что не видит в ней фундаментальных изменений, которые могли бы подтолкнуть к обновлению лицензии на ядро Linux. Против GPLv3 также выступили Эндрю Мортон, один из главных разработчиков операционной системы Linux, Дэвид Вудхаус, Дэйв Джонс и ряд других экспертов. По их мнению, представленный вариант GPLv3 нуждался в серьезной доработке.
Второй черновик появился 27 июля, до этого были проведены международные конференции в США, Бразилии и Испании, а в систему комментариев FSF поступило более тысячи предложений. В результате было внесено довольно много исправлений, но они, в основном, касаются нюансов и второстепенных вопросов.
Вот некоторые нововведения, которые несет GPLv3:
— Первый вариант черновика GPLv3 совсем запрещал использовать управление цифровыми правами (Digital Restriction Management, DRM), например, там было сказано следующее: «DRM фундаментально несовместимо с предназначением GPL, и сильно ограничивает свободу пользователей; поэтому GPL гарантирует что ПО, выпускаемое под этой лицензией, никогда не будет подвластно цифровым ограничениям, и никогда не сделает подобное с другим ПО или цифровым контентом». Однако во втором варианте лицензии формулировки стали более нейтральными, а сам термин DRM в тексте даже не упоминается.
— Появилась возможность расширять лицензию некоторыми дополнительными требованиями (например, требованием указывать авторские права исходного продукта во всех модифицированных). Подобные дополнения должны помочь в вопросах совместимости GPL с другими свободными лицензиями.
— Регламентируется использование патентов. Как сказано в черновиках GPLv3: «. каждой программе постоянно угрожают патенты на ПО. Мы хотим уменьшить опасность, которой подвергаются свободные программы, когда редистрибьюторы в индивидуальном порядке обходят эти самые патенты, тем самым, делая программы проприетарными. Чтобы пресечь данные действия, GPL уменьшает подобную опасность, подразумевая, что любой патент должен быть лицензирован для свободного использования каждым пользователем или вообще не должен быть лицензирован ни для кого».
— Добавлен пункт, разрешающий распространение программы GPL по сетям peer-to-peer, таким как BitTorrent, без принятия лицензии и, соответственно, без предоставления исходного кода ПО.

4)Лицензия LGPL
Сокращенная Универсальная Общественная Лицензия GNU (GNU Lesser General Public License, кратко GNU LGPL) специально создана для возможности компоновки библиотек с программами, распространяемыми по другим лицензиям. GNU Library General Public License появилась одновременно с лицензией GPL 2, поэтому тоже получила номер версии 2, для обозначения того, что эти две лицензии являются взаимодополняющими. Номера версий разошлись в 1999 году, когда была выпущена LGPL версии 2.1, которая была переименована в Lesser General Public License для уточнения ее местоположения в философии GNU.
Стоит отметить, что вместе со вторым черновиком GPL 3 появился и первый вариант LGPL 3, разработанный как частный случай GPL 3 посредством применения раздела о дополнительных условиях.

5)Лицензия Guile
Состоит из GNU GPL с добавлением особого пункта, дающего неограниченное право компоновки с несвободными программами. Как следствие, она не является строгим «авторским левом», но совместима с GNU GPL.

6)Лицензия Apache

Лицензия не являющаяся «авторским левом», под которой распространяется известный сервер Apache. Позволяет модифицировать и распространять программы как в открытых кодах, так и в двоичном виде. Помимо прав на сам программный продукт (на его использование, модификацию, распространение), лицензия требует передачи сопутствующих патентов. Предусмотрена контрмера на случай судебных претензий к разработчику ПО, распространяемого под лицензией Apache, — в этом случае лицо, предъявившее такие претензии, автоматически теряет переданные ему права в отношении программы или сопутствующих патентов.

7)Лицензия Common Public License (CPL)
эту лицензию сформулировала фирма IBM, чтобы распространять свои продукты.
Особенностью этой лицензии является то, что она позволяет разработчикам изменять исходный код и использовать его в своих коммерческих продуктах. Под этой лицензией выпустила свой продукт даже Microsoft — Windows Installer XML.

СУБД MongoDB переведена на новую лицензию, которая пока не проверена на открытость

Компания MongoDB, развивающая одноимённую документо-ориентированную СУБД, объявила об изменении условий распространения исходных текстов проекта и переводе кода с AGPLv3 на новую лицензию SSPL (Server S > Все значительные и корректирующие выпуски MongoDB, начиная с 16 октября будут формироваться под новой лицензией.

Вики Брассёр (Vicky Brasseur), вице-президент организации OSI (Open Source Initiative), предупредила пользователей, что лицензия SSPL совсем недавно была передана в OSI для проверки соответствия критериям Open Source и пока не добавлена в список открытых лицензий. Проблема в том, что процесс проверки был запущен не до, а после перелицензирования кода и непонятно сколько времени он может занять и будет ли вообще лицензия SSPL признана открытой.

Обычно лицензии передают на проверку заранее, а код перелицензируют после официального одобрения. До окончания проверки лицензия SSPL не является открытой и перелицензированный код MongoDB формально не попадает в категорию Open Source. Пользователям СУБД MongoDB рекомендуется дождаться утверждения SSPL и пока оставаться на версиях, выпущенных до 16 октября.

Мэтью Гаррет (Matthew Garrett), известный разработчик ядра Linux и один из директоров Фонда Свободного ПО, изучил новую лицензию и пришёл к выводу, что добавленные изменения формально соответствуют определению открытых лицензий. Текст SSPL основан на AGPLv3, а различия сводятся к замене 13 раздела AGPLv3 на требование поставки не только кода самого приложения, но и исходных текстов всех компонентов, вовлечённых в предоставление облачного сервиса, используя для них указанные в SSPL условия лицензирования.

Тем не менее, в SSPL имеются и спорные моменты, требующие дополнительного изучения. Больше всего вопросов создаёт требование публикации под условиями SSPL всего кода, используемого для обеспечения работы сервиса. Мэтью полагает, что, возможно, подобное требование не позволит использовать MongoDB в сервисах, запущенных на базе Linux, так как GPL и другие копилефт лицензии запрещают перелицензирование чужого кода. Если юристы подтвердят данное опасение, то создателям облачных сервисов с MongoDB придётся использовать BSD-системы или купить платную версию MongoDB.

Не исключено, что организация OSI не одобрит SSPL, но такой шаг потребует внесения изменений в определение открытых лицензий. В текущем виде SSPL соответствует определениям открытых лицензий, но лишь формально, так как SSPL не предоставляет какие-либо свободы, а лишь вынуждает покупать коммерческую версию продукта. Создатели MongoDB оправдывают предпринятый шаг тем, что провайдеры облачных сервисов по сути паразитируют на открытом ПО, продавая готовую функциональность, но не участвуя в разработке и ничего не возвращая взамен.

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

MongoDB

MongoDB

Разработчики: MongoDB Inc.
Выпущена: February 2009, 11 ( 11-02-2009 ) [1]
Постоянный выпуск: 3.4.9 [2] / 11 September 2020 года ; 2 years ago ( 2020-09-11 )
Предыдущий выпуск: 3.5.12 [3] / 22 August 2020 года ; 2 years ago ( 2020-08-22 )
Состояние разработки: Активное
Написана на: C++, C и JavaScript
Операционная система: Windows Vista и позднее, Linux, macOS 10.7 и позднее, Solaris, [4] FreeBSD [5]
Локализация: Английский язык
Тип ПО: Document-oriented database
Лицензия: Various; see § Licensing
Веб-сайт mongodb .org

MongoDB (от humongous) — кроссплатформенная документо-ориентированная система управления базами данных. Классифицированная как база данных NoSQL, MongoDB отходит от традиционных основ реляционной структуры базы данных в пользу JSON-подобных документов с динамическими схемами (MongoDB называет этот формат BSON), что делает интеграцию данных в определенных видах приложений проще и быстрее. Выпущено под комбинацией GNU Affero General Public License и лицензией Apache, MongoDB является бесплатным программным обеспечением с открытым исходным кодом.

Впервые разработанный софтверной компанией MongoDB Inc. в октябре 2007 года в качестве компонента запланированной площадке в качестве продукта обслуживания, компания смещается к модели развития с открытым исходным кодом в 2009 году, с MongoDB предлагает коммерческую поддержку и другие услуги [6] . С тех пор, MongoDB был принят в качестве серверной программного обеспечения в ряде крупных веб-сайтов и услуг, в том числе Craigslist, eBay, и Foursquare и другие. По состоянию на июль 2015 года, MongoDB является четвертым наиболее популярный тип системы управления базами данных, и самый популярный для магазинов документа [7] .

Содержание

Основные особенности

Документо-ориентированность
Вместо того, чтобы брать бизнес-объект и разбить его на несколько реляционных структур, MongoDB может хранить бизнес объект в минимальном количестве документов. Например, вместо того, чтобы хранить название и сведения об авторе в двух различных реляционных структур, название, автор, и другой информации в заголовке, связанных могут быть сохранены в одном документе под названием Книга.

Специальные запросы
MongoDB поддерживает поиск по области, запросов по диапазону, поиск регулярного выражения. Запросы могут возвращать определенные поля документов, а также включают в себя пользовательские функции JavaScript.

Индексация
Любое поле в документе MongoDB могут быть проиндексированы (индексы в MongoDB концептуально схожи с RDBMSes). Вторичные индексы также доступны.

Репликации
MongoDB обеспечивает высокую доступность с наборов реплик. Реплика набор состоит из двух или более копий данных. Каждый набор реплик член может выступить в роли первичного или вторичного реплики в любое время. Основная реплика выполняет все пишет и читает по умолчанию. Вторичные реплики поддерживать копию данных первичного помощью встроенного в репликации. Когда первичная реплика не удается, реплика устанавливается автоматически проводит избирательный процесс, чтобы определить, какие дополнительные должна стать основным. Вторичные также может выполнять операции чтения, но данные в конечном счете соответствует по умолчанию.

Балансировка нагрузки
MongoDB весы горизонтально, используя шардинга. Пользователь выбирает ключ осколка, который определяет, как данные в коллекции будет распространяться. Данные разделены на диапазоны (на основе ключа шарда) и распределены по нескольким осколков. (Осколок мастер с одним или несколькими рабами.) MongoDB может работать на нескольких серверах, балансировка нагрузки и / или дублирования данных, чтобы сохранить систему и работает в случае выхода из строя оборудования. Автоматическая конфигурация легко развернуть и новые машины могут быть добавлены к работающей базе данных.

Файл хранения
MongoDB может быть использован в качестве файловой системы, пользуясь балансировки нагрузки и репликации данных содержит более нескольких машин для хранения файлов.

Эта функция, называемая сетевая файловая система, входит с драйверами MongoDB и доступна для языков программирования (см «Языковая поддержка» для списка поддерживаемых языков). MongoDB предоставляет функции для работы с файлами и содержания для разработчиков. GridFS используется, например, в плагинах для NGINX и Lighttpd. Вместо того чтобы хранить файл в одном документе, GridFS делит файл на части, или куски, и в магазинах каждый из этих кусков в качестве отдельного документа.

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

Агрегирование
MapReduce может быть использован для пакетной обработки данных и операциями агрегирования. Рамки агрегации позволяет пользователям получить вид результатов, для которых SQL GROUP BY статьи используется.

Серверный выполнение JavaScript
JavaScript может быть использован в запросах, агрегация функции (такие как MapReduce), и направлено напрямую в базу данных, которая будет выполнена.

Блокирование коллекций
MongoDB поддерживает коллекции фиксированного размера называется блокированы коллекции. Этот тип сбора поддерживает порядок ввода и, по истечении заданного размера была достигнута, ведет себя как круговой очереди.

Архитектура

Модель данных

Данных в качестве документов
MongoDB хранит данные как документы в двоичном представлении под названием BSON (Binary JSON). Кодирование BSON расширяет популярным JSON (JavaScript Object Notation) представление, чтобы включить дополнительные типы, такие как Int, длинные, и с плавающей точкой. BSON документы содержат одно или несколько полей, а каждое поле содержит значение определенного типа данных, в том числе массивов, бинарных данных и судокументов.

Документы, которые стремятся поделиться аналогичную структуру организованы коллекций. Это может быть полезно думать о коллекциях как аналог таблицы в реляционной базе данных: документы схожи с рядами, и поля похожи на колонках.

Рассмотрим, например, модель данных для приложения блогов. В реляционной базе данных данные модели будет включать несколько таблиц. Для упрощения примера предположим, есть столы для категории, теги, пользователей, Комментарии и статьи.

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

Как показывает этот пример, документы MongoDB, как правило, есть все данные для данной записи в единый документ, в то время как в реляционной базе данных информации для данной записи, как правило, распространяется во многих таблицах. С модели документа MongoDB, данные более локализованы, что значительно снижает необходимость объединения отдельных таблиц. В результате резко более высокую производительность и масштабируемость через стандартное оборудование в виде одного чтения к базе данных может получить весь документ, содержащий все данные, связанные с.

Кроме того, документы MongoDB BSON более тесно связаны со структурой объектов в языке программирования. Это делает его проще и быстрее для разработчиков смоделировать, как данные в приложении будут отображаться в данных, хранимых в базе данных.

Динамический схемы
документы MongoDB может варьироваться в структуре. Например, все документы, которые описывают пользователей может содержать идентификатор пользователя и дату последнего они вошли в систему, но только некоторые из этих документов могут содержать идентификатор пользователя для одного или нескольких сторонних приложений. Поля могут варьироваться от документа к документу; нет необходимости декларировать структуру документов в системе — документы самостоятельно, описывающий. Если новое поле должно быть добавлено к документу, то поле может быть создано без влияния все другие документы в системе, не обновляя каталог центральную систему, и без перевода системы в автономном режиме.

Разработчики могут начать писать код и сохраняются объекты, как они создаются. И когда разработчики добавляют больше возможностей, MongoDB продолжает хранить обновленные объекты без необходимости для выполнения дорогостоящих операций ALTER_TABLE, или еще хуже — приходится заново проектировать схемы с нуля.

Схема Дизайна
Хотя MongoDB обеспечивает гибкость схемы, дизайн схемы по-прежнему важно. Разработчики и администраторы баз данных должны рассмотреть ряд вопросов, включая типы запросов, приложение необходимо будет выполнить, как объекты управляются в коде приложения, и как документы будут меняться с течением времени. Проектирование схемы обширная тема, которая выходит за рамки данного документа. Для получения более подробной информации, пожалуйста, см моделирования данных соображений.

Модель запросов

Идиоматические Драйверы
MongoDB обеспечивает родные драйверы для всех популярных языков программирования и структуры, чтобы сделать развитие естественно. Поддерживаемые драйверы включают в себя Java, .NET, Ruby, PHP, JavaScript, Python Node.js,, Perl, PHP, Scala и др. Драйверы MongoDB предназначены для идиоматических для данного языка.

Одно из фундаментальных различий по сравнению с реляционных баз данных является то, что модель запроса MongoDB реализован как методов или функций в API конкретного языка программирования, в отличие от совершенно отдельный языке, как SQL. Это, в сочетании с близостью между JSON модели документа MongoDB и структур данных, используемых в объектно-ориентированного программирования, делает интеграцию с приложениями простых. Для получения полного списка драйверов посетите страницу MongoDB Драйверы.

Монго оболочки
оболочки Монго является богатым, интерактивная оболочка JavaScript, что входит в состав всех дистрибутивов MongoDB. Почти все команды, поддерживаемые MongoDB может быть выдан через оболочку, в том числе административных операций. Оболочка Монго является популярным способом взаимодействовать с MongoDB для специальных операций. Все примеры в Руководстве по MongoDB на основе скорлупы. Для более на корпусе Монго, увидеть соответствующую страницу в руководстве MongoDB.

Типы Запроса
В отличие от баз данных NoSQL, MongoDB не ограничивается простыми операциями ключ-значение. Разработчики могут создавать приложения, используя богатые сложные запросы и вторичные индексы, которые разблокировать значение в структурированных, полу-структурированных и неструктурированных данных.

Ключевым элементом этой гибкости является поддержка MongoDB для многих типов запросов. Запрос может вернуть документ, подмножество конкретных областях в документе или сложных агрегатов против многих документов:

  • Запросы ключ-значение Результаты возврат основанные на любом поле InThe документа, часто первичный ключ.
  • Множество запросов Результаты, основанные на определенных значений в виде неравенств (например, больше, меньше или равно, между ними).
  • Геопространственные запросы Показывать результаты, основанные на критериях приближения, пересечения и включения в указанный точке, линии, окружности или многоугольника.
  • Поиск текста запросы возвращают результаты в порядке релевантности, основанные на текстовых аргументов, используя логические операторы (например, И, ИЛИ, НЕ).
  • Запросы агрегации вернуться скопления значений, возвращаемых запросом (например, рассчитывать, мин, макс, средний, похожий на SQL GROUP BY заявление).
  • ‘Уменьшение количества запросов’ Выполнить сложную обработку данных, выражается в JavaScript и выполнен по данным в базе данных.

Индексирование
Индексы решающим механизмом для оптимизации производительности и масштабируемости системы, обеспечивая гибкий доступ к данным. Как и большинство систем управления базами данных, в то время как индексы улучшит производительность некоторых операций на несколько порядков, они берут на себя нагрузку, связанные в операциях записи, использование дискового пространства, и потребление памяти. По умолчанию, механизм хранения WiredTiger сжимает индексы в памяти, освобождая больше рабочего набора документов.

MongoDB включает в себя поддержку многих видов вторичных индексов, которые могут быть объявлены на любом поле в документе, в том числе полей в массивы:

  • Уникальная Индексы., Указав индекс уникальным, MongoDB будет отвергать вставки новых документов или обновления документа с существующей значение для области, для которых уникальный индекс был создан. По умолчанию все индексы не установлены как уникальный. Если составной индекс определен как уникальный, комбинация значений должно быть уникальным.
  • Составные индексы. Это может быть полезно для создания составных индексов для запросов, которые определяют несколько предикатов Например, рассмотрим приложение, которое хранит данные о клиентах. Приложение может понадобиться, чтобы найти клиентов на основе фамилии, имени и города проживания. С индексом соединения на фамилию, имя и город проживания, запросы могут эффективно найти людей со всеми тремя из этих заданных значений. Дополнительным преимуществом индекса соединения является то, что любой лидер поле в индексе может быть использован, sofewer индексы на отдельных полях могут быть необходимы: этот показатель соединение также оптимизировать запросы ищут клиентов по фамилии.
  • Массива индексов. Для полей, содержащих массив, каждое значение массива хранится в отдельной записи индекса. Например, документы, которые описывают продукты могут включать в себя поле для компонентов. Если есть индекс на поле компонента, каждый компонент индексируется и запросы на поле компонента могут быть оптимизированы по этому показателю. Там нет специального синтаксиса, необходимая для создания индексы массива — если поле содержит массив, она будет индексироваться как индекс массива.
  • TTL индексов. В некоторых случаях данные должны истекают из системы автоматически. Время жизни (TTL) показатели позволяют пользователю задать период времени, после которого данные будут автоматически удалены из базы данных. Обычное использование TTL индексов приложения, которые поддерживают качению окно истории (например, большинство последних 100 дней) для действий пользователя, таких как маршрут передвижения.
  • Геопространственные Индексы. MongoDB обеспечивает геопространственных индексы для оптимизации запросов, связанных с места в двумерном пространстве, например, проекционных систем для земли. Эти показатели позволяют MongoDB для оптимизации запросов к документам, которые содержат точек или полигон, которые находятся ближе к заданной точке или линии; что находятся в круг, прямоугольник, или многоугольника или, что пересекаются с окружностью, прямоугольником или полигоном.
  • Редкие Индексы. Редкие индексы содержат только записи для документов, содержащих указанное поле. Поскольку модель данных документ MongoDB обеспечивает гибкость в модели данных из документа в документ, он является общим для некоторых полей, чтобы присутствовать только в подгруппе всех документов. Редкие показатели позволяют для небольших, более эффективных показателей, когда поля не присутствует во всех документах.
  • Text Search индексов. MongoDB предоставляет специализированный индекс для поиска текста, который использует передовые, конкретного языка лингвистические правила морфологии, токенизации и остановить слова. Запросы, использующие индекс текстового поиска будет возвращать документы в порядке релевантности. Одно или несколько полей могут быть включены в индекс текста.

Оптимизация запросов
MongoDB автоматически оптимизирует запросы, чтобы сделать оценку как можно более эффективным. Оценка обычно включает в себя выбор данных на основе предикатов и сортировки данных на основе критериев сортировки, предоставляемых. Оптимизатор запросов выбирает лучший показатель для использования, периодически работает альтернативные планы запросов и выбрав индекс с лучшим временем отклика для каждого типа запроса. Результаты этого теста эмпирической хранятся в кэшированной плана запроса и периодически обновляться. Разработчики могут предварительно отзыв и оптимизировать планы, используя мощный объяснить метод и фильтры индекса.

Индекс пересечения обеспечивает дополнительную гибкость, позволяя MongoDB использовать более одного индекса для оптимизации специальную запрос во время выполнения.

Покрытые Запросы
Запросы, которые возвращают результаты, содержащие только индексированные поля называются покрытые запросы. Эти результаты могут быть возвращены, не читая из исходных документов. С соответствующими индексами, нагрузки могут быть оптимизированы для использования преимущественно покрытые запросов.

Управление данными

Авто-шардинг
MongoDB обеспечивает горизонтальное масштабирование аут для баз данных по низкой стоимости, товар аппаратного или облачной инфраструктуры, используя технику под названием Sharding, который является прозрачным для приложений. Шардинг распределяет данные между несколькими физическими разделов, называемых осколками. Шардинг позволяет развертывание MongoDB для решения аппаратных ограничений одном сервере, например, узкие места в ОЗУ или дискового ввода / вывода, без добавления сложности в применении. MongoDB автоматически балансирует данные в sharded кластера, так как данные растет или размер кластера увеличивается или уменьшается.

В отличие от реляционных баз данных, Sharding является автоматическим и встроенным в базу данных. Разработчики не сталкиваются сложность построения логики Sharding в их коде приложения, которые затем должен быть обновлен осколки будут перенесены. Операции команды не нужно развернуть дополнительное программное обеспечение кластеризации для управления процессов и данных распределения.

В отличие от других распределенных баз данных, несколько политик Sharding доступны, которые позволяют разработчикам и администраторам распределять данные в кластере по образцам запросов или местности данных. В результате, MongoDB обеспечивает высокую масштабируемость гораздо через разнообразный набор рабочих нагрузок:

  • Диапазон основе Шардинг. Документы распределена по осколками в соответствии с значением ключа шарда. Документы с шарда ключевых ценностей «близких» друг с другом, вероятно, будут совмещены на одном осколке. Этот подход хорошо подходит для приложений, которые нуждаются в оптимизации rangebased запросов.
  • На основе хэш-Шардинг. Документы равномерно распределена по MD5 хеш значением ключа шарда. Документы с шарда ключевых ценностей «Закрыть» друг с другом, вряд ли будут совмещены на одном осколке. Этот подход гарантирует равномерное распределение по всей записи осколками, но менее оптимальным для запросов по диапазону основе.
  • На расположение Шардинг. Документы разделена в соответствии с указанной пользователем конфигурации, которая связывает осколок диапазоны ключей с конкретными осколками и аппаратного обеспечения. Пользователи могут непрерывно совершенствовать физическое местоположение документов для требований приложения, такие как данные обнаружения в конкретных центрах обработки данных или на хранении с разными температурными (т.е. накопителей для самых последних данных, и жесткие диски для старых данных).

Маршрутизатор запрсов
Маршрутизатор запросов является прозрачным для приложений; есть ли один или сто осколки, код приложения для запроса MongoDB то же самое. Приложения выполнять запросы к маршрутизатору запроса, отправляет запрос в соответствующие осколками.

Для ключ-значение запросов, основанных на ключе шарда, маршрутизатор запрос будет отправлять запрос на осколок, который управляет документ с запрашиваемой ключа. При использовании диапазона на основе шардинга запросы, которые определяют диапазоны по ключу шарда отправляются только черепки, которые содержат документы со значениями в пределах диапазона. Для запросов, которые не используют ключ осколка, маршрутизатор запрос будет транслировать запрос всем осколков и агрегировать и сортировать результаты в подходящее. Несколько маршрутизаторов запросов можно использовать с системой MongoDB, и соответствующее количество определяется на основе требований производительности и доступности приложения.

Базовые операции в MongoDB

Проверка установленной версии MongoDB

Подключиться к базе данных из оболочки

По умолчанию, Монго выглядит для сервера базы данных на порту 27017 на сервере LOCALHOST. Мы можем изменить эти настройки с помощью -host и -port варианты.

или с использованием команды kill:

Выключить базу данных
Завершить процесс:

Мы должны быть осторожны при использовании убийство -9

, эта команда вызовет резкое падение базы данных, и это может привести к несогласованности и потере данных.

Обращение к списку созданных баз данных

Мы проверили, что мы подключены к базе данных Мы обратились с просьбой, однако, не была создана! MongoDB создает резервную копию базы данных и сбор, когда мы вставки наш первый документ.

Мы уже знаем, что MongoDB не схему, то есть, мы не должны объявить структуру и характеристики наших коллекций перед их использованием. Таким образом, коллекция будет создана, когда мы вставляем первый документ в нем, как мы видели раньше.

MongoDB создает набор файлов в базе данных. Эти файлы хранятся в каталоге мы указали, когда мы начали службу mongod или, по умолчанию, в каталоге /var/lib/mongodb/.

Удалить базу данных

С помощью команды dropDatabase () мы удалим базу данных всю текущую, включая метаданные, а также физические файлы. К «db» объект будет по-прежнему указывает на ту же базу данных.

MongoDB Drupal 8

Для установки использовалась ОС Ubuntu 14.04

MongoDB C# ORM

Для MongoDB существует драйвер MongoDB C#, который позволяет написать свою ORM-ку. Рассмотрим работу с mongo с помощью ORM в среде .net.

Создание базы данных.

По умолчанию база данных находится в папке c:/data/db Запустим mongo.exe и создадим новую базу данных:

Особенностью MongoDb является то, что это документо-ориентированная база данных, и не содержит информацию о структуре, так что тут мы закончили. Сразу переходим к описанию моделей данных.

У нас будет одна сущность (коллекция) unicorns.

Далее рассмотрим работу с MongoDB: 1) подключение к Mongo 2) добавление записи 3) изменение записи 4) индексация 5) удаление записи 6) вывод записей (фильтрация/пейджинг/сортировка) 7) поиск 8) бекап базы

Подключение к базе.

По умолчанию база занимает порт 27017 на сервере (у нас как обычно localhost). Подключаемся к базе:

Добавление/изменение записи

MongoDb самостоятельно добавляет поле _id — уникальный параметр. Если при выполнении команды Save у объекта будет Id существующий уже в коллекции, то выполнится апдейт этого объекта.

Индексация

Для быстрого поиска мы можем добавить индекс по какому-либо полю. Для индексации используется команда

Это ускорит сортировку по этому полю.

Удаление

Для удаления по id создается запрос (Query). В данном случае это

и выполняется команда:

Вывод записей

Для вывода значений применив фильтр и отсортированных, да еще и с пейджингом используется курсор. Например чтобы выбрать из коллекции неудаленные (IsDeleted = false) отсортированные по дате убывания (AddedDate desc) 10ю страницу (пропускаем 90 элементов и выводим 10 следующих) составляется такой курсор:

Поиск.

Для того чтобы найти элемент содержащий заданную подстроку необходимо задать следующий запрос:

Есть 2 проблемы так как поиск учитывает регистр, т.е. Петя != петя, и к тому же у нас есть много полей.

Бекап базы.

Именно бекап а не репликация. Для того чтобы иметь доступ к файлу базы данных нужно выполнить lock (база продолжит работать, только в этот момент все команды записи будут кешироваться, чтобы потом выполнится). После чего базу данных можно скопировать, заархивировать и выложить на ftp. После этой процедуры базу надо разлочить (Unlock). Команды:

Если что-то пойдет не так, то сервер БД надо будет перезапустить с командой:

Полное видео установки

Установка Mongo DB в Ubuntu Server 16.04

Шаг 1 — Добавление репозитория MongoDB

MongoDB доступен из стандартных репозиториев Ubuntu, однако, для установки самых последних версий рекомендуется использовать официальный репозиторий MongoDB. На этом шаге мы добавим этот репозиторий на наш сервер.

Ubuntu проверяет подлинность пакетов путём проверки подписей GPG ключей, поэтому сначала нам необходимо импортировать ключ официального репозитория MongoDB.

После успешного импорта ключа вы увидите следующий вывод:

Далее нам необходимо добавить настройки репозитория в apt, чтобы иметь возможность загрузить MongoDB с помощью apt.

Для этого выполните следующую команду:

После добавления репозитория нам необходимо обновить список пакетов.

Шаг 2 — Установка MongoDB

Теперь мы можем установить пакеты MongoDB.

Эта команда установит несколько пакетов, содержащих последнюю стабильную версию MongoDB, а также некоторые средства настройки сервера MongoDB.

Для того, чтобы запускать MongoDB в виде сервиса Ubuntu 16.04, нам необходимо создать юнит-файл описывающий этот сервис. Юнит-файлы сообщают systemd, как управлять соответствующими ресурсами. Наиболее часто встречающимся типом юнит-файла является сервис, который указывает, как запускать и останавливать тот или иной сервис. Также этот файл указывает, надо ли запускать соответствующий сервис при старте системы, а также, имеет ли сервис зависимости от другого программного обеспечения.

Мы создадим юнит-файл для управления сервисом MongoDB. Создайте файл конфигурации mongodb.service в директории /etc/systemd/system с помощью nano или любого другого текстового редактора.

Вставьте следующий текст в этот файл, сохраните и закройте его.

Этот файл имеет простую структуру:

Секция Unit описание сервиса MongoDB, а также его зависимостей, которые должны быть удовлетворены до запуска сервиса. В нашем случае MongoDB требует наличия сетевого подключения для запуска, поэтому мы указали директиву network.target.

Секция Service описывает параметры запуска сервиса. Директива User указывает, что сервис будет запущен от имени пользователя mongodb, а директива ExecStart задаёт команду запуска сервера MongoDB.

Последняя секция Install сообщает systemd, когда необходимо автоматически запускать сервис. Параметр multi-user.target задаёт стандартную последовательность запуска, что означает, что сервер будет автоматически запущен в процессе загрузки.

Далее запустим только что созданный нами сервис с помощью systemctl.

Эта команда не выводит ничего в консоль после завершения. Мы можем использовать systemctl для проверки успешного запуска сервиса.

Последнее, что нам осталось сделать, это включить автоматический запуск MongoDB при старте системы.

Репликации MongoDB

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

В MongoDB репликация асинхронная. Это значит, что данные синхронизируются между репликами не в момент непосредственного изменения данных, а через какое-то время. В этом есть плюс: не тратится время на репликацию в момент изменения данных. Минус: в определенные моменты времени данные между репликами могут быть не согласованными. На данный момент MongoDB поддерживает две основные репликации: master-slave и replica sets.

Master-Slave

Master-Slave применяется во многих СУБД. Есть несколько серверов: один мастер, и два слейва. Удалить и писать в базу можно только в мастер-сервере, а читать как из мастера так и из слейвов. Слейвов может быть несколько. Такая схема полезна, когда у нашей системы много запросов на получение данных. Так как приложение может обращаться к слейвам для чтения, то мы можем равномерно распределить нагрузку между ними.

Реализация master-slave в MongoDB. Допустим у нас три машины: 127.0.0.1 будет мастером, а 127.0.0.2 и 127.0.0.3 соответственно слейвами. Для начала запустим mongod в режиме мастера:

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

Когда запускается мастер-сервер, он создает в своей базе коллекцию local.oplog.$main (лог операций). В этой коллекции хранятся все последние операции (изменения данных), которые применялись на мастере. Именно из этой коллекции по слейвам расходятся команды обновления их локальных копий. Размер лога операций ограничен ( можно задать самим). В случае, если лог будет заполнен полностью, более старые операции будут удаляться из него, а новые соответственно добавляться.

Replica Sets

В наборе реплик также присутствует мастер, и при том только один в каждый момент времени. Отличие же в автоматической смене мастера в случае если это необходимо (например, если прежний мастер упадет). Создается несколько процессов mongod с ключом —replSet и указанием имени набора.

Затем серверы реплик необходимо инициализировать. В это время реплики решат между собой, кто будет выполнять функции мастера.

После запуска серверов и их инициализации можно приступать к изменению данных на мастере и чтению с него. Чтение как и запись возможны только с мастера.

Деньги в технологиях с открытым исходным кодом

Ни для кого не секрет, что опенсорс технологии (технологии с открытым исходным кодом) постигла та же участь что радикалов, хиппи и любителей мюслей — они превратились в мейнстрим.

Эта наш перевод статьи https://techcrunch.com/2020/02/09/the-money-in-open-source-software/ , которая была написана почти год назад, но для нас стала актуальной только сейчас. Благодарим Макса (кстати, бывшего СЕО MongoDB) и Дхармеша за полезный ликбез. Желаем им успехов в бизнесе!

Согласно оценкам отрасли, в период с 2011 по 2014 г. общий доход 180 молодых компаний, выпускающих свое программное обеспечение, составил 3.2 млрд. $. Даже крупные IT компании, поставщики программного обеспечения, в настоящее время делают ставку на открытый код для реализации критически важных бизнес функций. Это действительно большая перемена, ведь еще совсем недавно Стив Баллмер (бывший генеральный директор компании Microsoft) назвал операционную систему Linux с открытым исходным кодом “раковой опухолью” (видимо имея в виду, что она представляет угрозу для Windows).

Несмотря на растущую популярность ПО с открытым исходным кодом, многие опенсорс компании сложно назвать финансово успешными. Так же, как в конце 90-х большая аудитория доткомов не обеспечивала сервисы реальными онлайн-покупками, в наше время миллионы скачиваний свободного кода не всегда приводят к устойчивым финансовым потокам.

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

А насколько сложно построить большой, прибыльный бизнес в опенсорс технологиях?

Возьмем такой пример: Red Hat может похвастаться тем, что ее оценочная стоимость составляет 14 млрд. $ (такого результата компания добилась за 20 лет работы), к тому же, компания продолжает расти и ее стоимость будет увеличиваться и дальше.

Или пример MySQL, которую за 1 млрд $. в 2008 году купила компания Sun. Есть и несколько других показательных событий в истории опен сорс компаний. Так что успех в этом направлении возможен и для инвесторов и для предпринимателей.

Основываясь на нашем опыте работы с некоторыми опенсорс компаниями, такими как Mirantis, Cloudera, MongoDB и др. ( проспонсированными Мистером Таккером, когда он был в Intel Capital) мы выделили несколько ключевых уроков, которые нужно выучить предпринимателям, если они хотят создавать не просто опенсорс сообщество, но и устойчивый бизнес. Эти два направления не должны быть взаимоисключающими.

Думай о бизнес-модели с первого дня.

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

Чаще всего опенсорс компании зарабатывают деньги за счет продажи корпоративного софта с дополнительными функциями безопасности и управления. Как правило, такой софт рассчитан на крупные предприятия с большим потреблением интернет технологий.

Другой вариант заработка заключается в предоставлении премиум услуг SaaS, когда бизнес-модель основана на принципе оплаты pay-as-you-go. В то время, как предоставление надежных услуг может вызывать определенные трудности, а именно сложность упаковать множество опенсорс компонентов в одно полноценное облачное предложение — SaaS может стать выгодным способом получения прибыли.

Red Hat является хорошим примером компании, которая думала о монетизации с самого начала своей деятельности. Уже на раннем этапе, когда компания только только переключалась с отправки компакт-дисков Linux вклеенных в учебники на продажи своего софта крупным предприятиям, руководство компании сделало четкое разграничение между проектом Fedora, диструбутивом со свободным программным обеспечением, которое поддерживается только сообществом пользователей, и более сложным продуктом Red Hat Enterprise Linux (RHEL). Red Hat осознали, что их целевые покупатели — ИТ-директора и директора по операционной деятельности — главной ценностью продукта считают его стабильность, а не наличие множества функций. Поэтому корпорации хотели платные продукты корпоративного класса, которые должны поддерживать работу основных приложений Linux.

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

Таким образом, Red Hat одновременно поддерживала сообщество, которое активно развивало проект Fedora, обновляя его и снабжая новыми функциями каждые шесть месяцев, и продвигала на рынок свои платные корпоративные продукты, усиливая безопасность этих продуктов и внедряя оптимизацию для стандартных аппаратных средств Intel. Такая тактика позволила Red Hat одновременно получить регулярный поток денежных средств от корпоративных клиентов (в размере более чем 1 млрд. $) и превратить операционную систему Linux в более массовый продукт.

Возьмем пример другой дальновидной компании, занимающейся разработкой программного обеспечения — Cloudera.

Cloudera — это компания, которая ведет свою деятельность в области Big Data. Сейчас в этой области несколько компаний работают над тем, чтобы монетизировать опенсорс продукт Apache Hadoop. Так же как и Red Hat, Cloudera сохранила за собой некоторые важные функции своего продукта, такие как безопасность, производительность и бизнес-аналитику. Эти функции компания использует для своего премиум продукта Enterprise Data Hub.

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

Фонд Apache Software Foundation, чье серверное ПО с открытым исходным кодом ворвалось на технический рынок в 1990-е годы, подтолкнул многих поставщиков ПО использовать стратегию продажи поддержки клиентов как бизнес модель. Тогда это было связано с недоверием к технологиям с открытым исходным кодом, они считались рискованными, и многие компании хотели иметь страховку. Со временем, однако, большая часть клиентов начала чувствовать себя комфортно при использовании опенсорс технологий и уже не нуждалась в поддержке. В итоге такой способ монетизации не оправдал себя как долгосрочная перспектива.

Выберите модель лицензирования в соответствие с вашей стратегией монетизации

Лицензирование — это очень важный этап. Потому что именно лицензия на программное обеспечение с открытым исходным кодом определяет кто в итоге владеет всеми модифицированными версиями продукта. Неправильно выбранная лицензия (или ее отсутствие) может иметь серьезные последствия для вашего бизнеса.

Некоторые лицензии позволяют любому делать продукты с закрытым кодом на основе оригинального опенсорс продукта, тогда как другие лицензии оставляют право выпускать ПО с закрытым кодом только владельцам оригинального опенсорс продукта. Это важно учитывать, когда вы планируете добавлять новые функции к вашей системе, которую будете продавать. Потому что даже программное обеспечение с открытым исходным кодом всегда имеет своего владельца, как правило коммерческую компанию или некоммерческий фонд.

Лицензии варьируются от полностью допускающих использование программного обеспечения в коммерческих целях (Apache) до частично ограниченных (General Public License или GPL), самая ограничительная лицензия это Affero GPL. Всего существует 71 вид лицензий, все они перечислены на сайте opensource.org.

Более либеральные лицензии сильно облегчают строительство больших экосистем. То есть, если какой-то опенсорс проект сможет включить в себя часть вашего проекта (часть вашего опенсорс кода), вы можете оказаться связанным с другими успешными проектами, что будет способствовать вашему движению вперед.

Помните, что даже у технологий с открытым исходным кодом есть свой владелец

Более гибкие лицензии также могут решить вопрос с материальными вложениями в проект, что дает пользователям проекта возможность чувствовать себя более комфортно. Пользователи будут спокойны, что дальнейшая работа над проектом не зависит от небольшого стартапа. В то же время, позволяя любому пользователю добавлять новые функции к вашему продукту, вы оказываетесь в положении, когда становится труднее создавать устойчивую дифференциацию, увеличивать прибыль и избегать фрагментацию.

Речь в данном случае идет о популярном проекте OpenStack — облачной технологии от компании OpenStack Foundation. Факт того, что на ранней стадии в проект вложили деньги такие гиганты как Intel, Red Hat, HP, Dell, Juniper и тд. дало возможность проекту заполучить доверие крупных IT потребителей таких как PayPal, Walmart и Symantec. Крупные компании становились клиентами проекта, уверенные в том, что ядро инфраструктурной базы OpenStack поддержано широким сообществом и большими компаниями-производителями IT.

Тем не менее, недавно OpenStack все же была подвергнута критике. Связано это с тем, что компания развивается в нескольких направлениях, стараясь одновременно удовлетворить потребности нескольких компаний, занимающихся разработкой аппаратного обеспечения, не учитывая, что эти компании являются конкурентами между собой и имеют конкурирующие стратегии развития, и теперь, как следствие, продукты могут давать сбои при взаимодействии друг с другом.

В итоге это привело к появлению двух поставщиков — Red Hat и Mirantis, которые обещают быть “Швейцарией” экосистемы и работать со всеми, при этом сохраняя нейтралитет. По-видимому, это правильный бизнес-кейс на данный момент, учитывая какие проблемы были созданы ранее расширенными лицензиями.

MongoDB, напротив, целенаправленно следовала более строгой лицензионной модели AGPL. Однако, несмотря на использование строгой лицензии, ПО от MongoDB стало очень популярным. Это произошло в основном потому, что компания предложила убедительный продукт: простую и гибкую базу данных, которую многие разработчики оценили как гораздо более простую в использовании, чем старые реляционные базы данных. Это продукт превзошел ограничительную лицензию.

В течение двух лет MongoDB накопили миллионы скачиваний своего ПО, сейчас эта цифра составляет уже 10 миллионов.

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

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

ПО с открытым исходным кодом изменило расстановку сил в корпоративной инфраструктуре, пододвинув некоторые технологии: только подумайте MongoDB и Cassandra создали свои продукты на наследии баз данных Oracle, OpenStack и Docker, угрожающих гиганту виртуализации VMware, и наследии Linux, вытесняющей ПО Solaris и Windows Server. Это помогло им из аутсайдеров выйти в число успешных компаний. Именно это, а не дорогие консультационные услуги, за счет которых пытались расширяться некоторые предприниматели.

Разумеется, в первое время после старта опенсорс проекта будут нужны консультации профессионалов и поддержка клиентов, особенно если клиенты имеют дело с интеграцией продукта с его предыдущими версиями.

Например, некоторые из ранних внедрений Hadoop, OpenStack и Cloud Foundry нуждались в консультационных услугах, чтобы ключевые клиенты сервисов могли быстрее разобраться с продуктом и внедрить его.

Но не пытайтесь построить свой бизнес на предоставлении услуг. Такой способ получения прибыли даст вам наиболее низкий результат, чем другие способы, примерно 20–30% от возможной прибыли, когда как другие способы получения прибыли могут дать вам до 90% от потенциальной суммы. При этом консультации это не возобновляемая продажа. То есть такой способ привлечения денег не долгосрочен.

Сосредоточьтесь на развитие пассивного дохода от подписок

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

Кроме того, если вы будете гнаться за дохода от предоставления услуг слишком яро, вы начнете конкурировать такими мощными компаниями как Accenture или IBM, которые могли бы стать вам партнерами в предоставлении услуг и тем самым привлечь к вам огромное количество пользователей.

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

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

Более того мы бы вам посоветовали безжалостно дробить свои бизнес-услуги, чтобы сделать ваш продукт еще проще, чтобы пользователи были способны в дальнейшем управлять им самостоятельно, без поддержки с вашей стороны.

Постоянное удовлетворение клиента — является главным козырем для компаний где бизнес модель основывается на принципе предоплаты.

Циклы продаж в свободном программном обеспечении сильно отличаются от цикла продаж в традиционном, корпоративном ПО. В случае с регулярным корпоративным ПО часто бывает трудно убедить клиента начать использовать предлагаемое обеспечение и к тому же платить за его использование. Продажи в опенсорс технологиях осуществляются в два этапа. Убедить людей использовать ваше программное обеспечение чаще всего намного проще, потому что продукт изначально можно использовать бесплатно, но потом вы все равно столкнетесь с задачей, когда вам нужно убедить пользователя платить.

Это разделение на этапы может дезориентировать тех, кто привык к стандартному циклу продаж ПО и стандартному маркетингу. Представители могут потратить много времени на то, чтобы убедить пользователей использовать ваше программное обеспечение — и преуспеть в этом — но потом не выручить никакого дохода с продаж.

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

Но даже после того, как вы начнете расти и увеличивать объем продаж, вы не должны забывать сосредотачиваться на постоянном удовлетворении своих клиентов, потому что довольные клиенты всегда покупают чаще и покупают продукты с большей ценой. А наличие хорошего дохода позволяет вам тратить больше денег на исследования и опыты.

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

В MongoDB у нас был очень успешный сейлз, который до этого вообще занимался продажами спортивной формы, а еще ранее продавал услуги по очистке водостоков. Он не имел большого опыта работы с программным обеспечением, когда мы принимали его на работу, но он был фанатически сосредоточен на удовлетворенности клиентов.

Очевидно, что заработать деньги на опенсорс технологиях можно и существуют различные способы, чтобы добиться в этом успеха.

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

У нас есть множество исследований, которые мы проводили последние 20 лет, которые демонстрируют, что построить прибыльную и успешную компанию в области программного обеспечения с открытым исходным кодом, можно. При этом компания будет популярна среди пользователей.

Другими словами, вы можете не только иметь свои мюсли, но и есть их.

MongoDB Opensource vs MongoDB Enterprise

Не могли бы вы дать совет относительно выбора между Opensource и Enterprise MongoDB. основными моментами являются:

  • ограничение памяти
  • ограничение хранения
  • отказоустойчивого
  • Масштабируемость

Есть ли разница между Open Source и Enterprise MongoDB в этих точках?

Не могли бы вы прояснить еще один важный момент о разнице между License Commercial и GNU AGPL v3.0. для Монго?

Версия с открытым исходным кодом не имеет никаких искусственных ограничений в любом из аспектов, о которых вы говорили. Преимущества версии предприятия:

  • Служба управления MongoDB (решение для резервного копирования и мониторинга)
  • Мониторинг SNMP
  • Kerberos или LDAP в качестве альтернативы аутентификации на основе пароля или сертификата.
  • Лицензия на коммерческое развитие (изменения, внесенные в MongoDB, не подлежат условиям AGPL). Обратите внимание: в обычной настройке ваши клиенты свяжутся с вашим сервером приложений, а ваш сервер приложений взаимодействует с MongoDB. В этой конфигурации AGPL не требует публикации любого исходного кода, поскольку конечные пользователи не взаимодействуют с MongoDB непосредственно по сети. Это имеет значение только при непосредственном раскрытии MongoDB вашим клиентам. И даже тогда соблюдение AGPL является проблематичным только при внесении изменений в MongoDB.
  • MongoDB BI-Connector, который добавляет ограниченный (очень ограниченный) уровень совместимости SQL в MongoDB для интеграции с решениями Business Intelligence на базе SQL.
  • MongoDB compass — инструмент GUI для визуализации структур данных (но там являются бесплатными альтернативами для этого).
  • Механизм хранения в памяти (начиная с версии 3.2 все еще в бета-стадии и еще не рекомендуется для использования!)
  • Контракт на поддержку и обучение
  • Сертификация для некоторых операционных систем (учитывая, что бесплатная версия идентична, за исключением дополнительных функций, перечисленных выше, оплата просто для этого совершенно бессмысленна. Но, возможно, вы работаете в месте с большим количеством МВА, которые заботятся о таких формальностях)

Когда вы можете обойтись без всех этих вещей, вам не нужно платить за корпоративную версию.

Я думаю, вы спрашиваете, существуют ли какие-либо ограничения или ограничения с точки зрения базовой функциональности между MongoDB Enterprise и версией сообщества /OSS. Ответ отрицательный: нет никакой разницы или ограничения в отношении объема памяти, памяти или количества экземпляров/наборов/кластеров, которые вы можете запускать с использованием версии OSS, и нет никакой разницы в механизме переключения при сбое между ними.

Различия (как указано на странице MongoDB Enterprise) связаны с безопасностью, аутентификацией/авторизацией, аудитом, мониторингом интеграции, поддержка, лицензирование и т.д.

Другими словами, различия в областях, наиболее вероятно привлекательных для предприятий/предприятий, стремящихся запустить базу данных MongoDB как критическую интегрированную систему ответственным, поддерживаемым способом.

СУБД MongoDB переведена на новую лицензию, которая пока не проверена на открытость

Компания MongoDB, развивающая одноимённую документо-ориентированную СУБД, объявила об изменении условий распространения исходных текстов проекта и переводе кода с AGPLv3 на новую лицензию SSPL (Server S > Все значительные и корректирующие выпуски MongoDB, начиная с 16 октября будут формироваться под новой лицензией.

Вики Брассёр (Vicky Brasseur), вице-президент организации OSI (Open Source Initiative), предупредила пользователей, что лицензия SSPL совсем недавно была передана в OSI для проверки соответствия критериям Open Source и пока не добавлена в список открытых лицензий. Проблема в том, что процесс проверки был запущен не до, а после перелицензирования кода и непонятно сколько времени он может занять и будет ли вообще лицензия SSPL признана открытой.

Обычно лицензии передают на проверку заранее, а код перелицензируют после официального одобрения. До окончания проверки лицензия SSPL не является открытой и перелицензированный код MongoDB формально не попадает в категорию Open Source. Пользователям СУБД MongoDB рекомендуется дождаться утверждения SSPL и пока оставаться на версиях, выпущенных до 16 октября.

Мэтью Гаррет (Matthew Garrett), известный разработчик ядра Linux и один из директоров Фонда Свободного ПО, изучил новую лицензию и пришёл к выводу, что добавленные изменения формально соответствуют определению открытых лицензий. Текст SSPL основан на AGPLv3, а различия сводятся к замене 13 раздела AGPLv3 на требование поставки не только кода самого приложения, но и исходных текстов всех компонентов, вовлечённых в предоставление облачного сервиса, используя для них указанные в SSPL условия лицензирования.

Тем не менее, в SSPL имеются и спорные моменты, требующие дополнительного изучения. Больше всего вопросов создаёт требование публикации под условиями SSPL всего кода, используемого для обеспечения работы сервиса. Мэтью полагает, что, возможно, подобное требование не позволит использовать MongoDB в сервисах, запущенных на базе Linux, так как GPL и другие копилефт лицензии запрещают перелицензирование чужого кода. Если юристы подтвердят данное опасение, то создателям облачных сервисов с MongoDB придётся использовать BSD-системы или купить платную версию MongoDB.

Не исключено, что организация OSI не одобрит SSPL, но такой шаг потребует внесения изменений в определение открытых лицензий. В текущем виде SSPL соответствует определениям открытых лицензий, но лишь формально, так как SSPL не предоставляет какие-либо свободы, а лишь вынуждает покупать коммерческую версию продукта. Создатели MongoDB оправдывают предпринятый шаг тем, что провайдеры облачных сервисов по сути паразитируют на открытом ПО, продавая готовую функциональность, но не участвуя в разработке и ничего не возвращая взамен.

Мастер Йода рекомендует:  TОП-10 свежих open source проектов по машинному обучению
Добавить комментарий