MongoDB *

Мы — отдел большой компании, развивающий важную систему на Java SE / MS SQL / db4o. За несколько лет проект перешел от опытного образца к промышленной эксплуатации и db4o превратилась в тормоз расчета, захотелось перейти с db4o на современную noSQL-технологию. Пробы и ошибки завели далеко от первоначального замысла — от db4o отказаться удалось, но ценой компромисса. Под катом размышления и подробности реализации.

Все хорошие стартапы либо быстро умирают, либо дорастают до необходимости масштабироваться. Мы смоделируем такой стартап, который сначала про фичи, а потом про перфоманс. Перфоманс будем улучшать с MongoDB — это популярное NoSQL-решение для хранения данных. С MongoDB легко стартовать, и многие проблемы имеют решения «из коробки». Однако, когда нагрузка растет, вылезают грабли, о которых вас заранее никто не предупреждал… до сегодняшнего дня!



Моделирование проводит Сергей Загурский, который отвечает за инфраструктуру бэкенда вообще, и MongoDB в частности, в Joom. Также был замечен в серверной части разработки MMORPG Skyforge. Как сам себя описывает Сергей — «профессиональный набиватель шишек собственным лбом и граблями». Под микроскопом — проект, который использует стратегию накопления для управления техническими долгом. В этой текстовой версии доклада на HighLoad++ будем двигаться в хронологическом порядке от возникновения проблемы до решения с помощью MongoDB.

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

• писали js скрипты и запускали непосредственно в базе данных

• использовали Mongobee  -  инструмент для автоматических миграций

В прошлом году, нашей команде повезло принять участие в разработке программного обеспечения для социально значимого проекта – системы ввода архивных данных военных комиссариатов Хабаровского края времен Великой Отечественной войны. Кратко говоря, когда был призван, куда убыл и другую связанную с этим информацию – оцифровать и дать возможность искать эти данные кому угодно. Дальневосточный центр социальных технологий в 2018 году, при поддержке Фонда президентских грантов, реализовывал проект — «Вспомнить каждого». А мы, разработали приложение на нашем опенсорсном продукте IONDV. Framework. Итоговое приложение сейчас доступно под лицензией GPLv3.

Делимся нашим решением и опытом работы над проектом.

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

Я достаточно часто сталкивался с такой проблемой и решил ее созданием Eve — Telegram-бота, который помогает мне не забывать про релизы моих любимых фильмов. Что это, как оно работает и как разрабатывалось вы можете почитать под катом!

В 1999 году доходы музыкальной индустрии США достигли максимальной отметки $14,6 млрд (все цифры от RIAA). Но важно понимать, что именно продавалось:

• $12,8 млрд получено от продажи CD
  
• $1,1 млрд от продажи кассет
  
• $378 млн составили продажи музыкальных видео на физических носителях
  
• $222,4 млн — синглы на CD

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

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

The Guardian — одна из крупнейших британских газет, она основана в 1821 году. За без малого 200 лет существования архив накопился изрядный. По счастью, далеко не весь он хранится на сайте — всего за какие-то последние пару десятков лет. В базе данных, которую сами англичане назвали «источником истины» для всего онлайн-контента, около 2,3 млн элементов. И в один прекрасный момент они осознали необходимость миграции с Mongo на Postgres SQL — после того, как одним жарким июльским днём в 2015 году процедуры аварийного переключения были подвергнуты суровому испытанию. Миграция заняла без малого 3 года!..

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

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

Сегодня, Amazon AWS запустил продукт DocumentDB — новую базу данных, совместимую с API MongoDB. Компания описывает DocumentDB так — "быстрая, масштабируемая и отказоустойчивая документная база данных, разработанная так, чтобы быть совместимой с вашими существующими приложениями и инструментами на MongoDB". Фактически, это полная замена MongoDB, развёрнутая в AWS, которая не использует код MongoDB.

В AWS утверждают, что, хотя MongoDB отлично справляется со своими задачами, их клиентам всё же трудно создавать быстрые и высокодоступные приложения на платформе с открытым исходным кодом, которые смогут масштабироваться до нескольких терабайт и сотен тысяч операций чтения и записи в секунду. Поэтому компания создала свою собственную базу данных документов, но сделала ее совместимой с API MongoDB 3.6, распространяющимся под лицензией Apache 2.0.

UPD: туториал обновлен в связи с выходом релизной версии.

Хорошие новости! Официальный драйвер go для mongoDB вышел в релиз.
Немного поразмыслив я решил перевести статью с официального сайта mongoDB вместо того, чтобы писать материал самостоятельно(данный перевод отличается от статьи).
Вот что будет в данном туториале:

• Установка mongo-go-driver
• Соединение с mongoDB с помощью mongo-go-driver
• Использование BSON объектов
• Использование CRUD методов

В MongoDB несколько обижены тем, что некоторые облачные провайдеры, особенно в Азии, используют их открытый код и предлагают коммерческую версию их базы данных в облаке своим пользователям, не играя по правилам открытого ПО. Чтобы бороться с этим, MongoDB сегодня объявила о выпуске новой лицензии на программное обеспечение — Server Side Public License (SSPL), которая будет использоваться во всех новых релизах их MongoDB Community Server, а также во всех патчах к предыдущим версиям.

Вы когда-нибудь анализировали вакансии?

Задавались вопросом, в каких технологиях наиболее сильна потребность рынка труда на текущий момент? Месяц назад? Год назад?

Как часто открываются новые вакансии Java-разработчиков в определенном районе Вашего города и как активно они закрываются?

В этой статье я расскажу Вам, как можно достичь желаемого результата и построить отчетную систему по интересующей нас теме. Поехали!


(Источник картинки)

Летом 2018 года (т.е. прямо сейчас, на момент написания данной статьи) случилось невероятное — в MongoDB завезли честные ACID транзакции. С выходом четвёртой версии этой документ-ориентированной СУБД, её можно использовать для чуть более серьёзных приложений.

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

К сожалению, разработчику воспользоваться этой супер-фичей не так-то просто. Ниже я расскажу почему, и что с этим всем делать.

В этом сообщении будут рассмотрены способы соединения коллекций в NoSQL базах данных mongodb, arangodb, orientdb и rethinkdb (помимо того, что это NoSQL базы данных, их объединяет еще и наличие бесплатной версии с достаточно лояльной лицензией). В реляционных базах данных аналогичная функциональность реализуется при помощи SQL JOIN. Несмотря на то, что CRUD — операции в NoSQL базах данных очень похожи и различаются только в деталях, например, в одной базе данных для создания объекта используется функция create({… }), в другой — insert({… }), а в третьей — save({… }), — реализация выборки из двух и более коллекций в каждой из баз данных реализована совершенно по-разному. Поэтому будет интересно выполнить на всех базах данных одинаковую выборку. Для всех баз будет рассмотрено получение выборки (связь типа многие-ко многим) для двух таблиц.

При работе с базами данных существует проблема которую принято называть «SELECT N + 1» — это когда приложение вместо одного запроса к базе данных, который выбирает все необходимые данные из нескольких связанных таблиц, коллекций, — делает дополнительный подзапрос для каждой строки результата первого запроса, чтобы получить связанные данные. Например, сначала мы получаем список студентов университета, в котором его специальность обозначена идентификатором, а потом для каждого из студентов делаем дополнительный подзапрос в таблицу или коллекцию специальностей, чтобы по идентификатору специальности получить наименование специальности. Поскольку каждый из подзапросов может потребовать еще один подзапрос, и еще один подзапрос — колчество запросов к базе данных начинает расти в геометрической прогрессии.

При работе с graphql очень просто породить проблему «SELECT N + 1», если в resolver-функции сделать подзапрос к связанной таблице. Первое что приходит в голову — сделать запрос сразу с учетом всех связанных данных, но это, согласитесь, нерационально, если связанные данные не запрашиваются клиентом.

Один из вариантов решения проблемы «SELECT N + 1» для graphql будет рассмотрен в этом сообщении.

После прочтения заголовка у многих наверняка возникает вопрос — зачем ещё один велосипед при наличии уже обкатанных Mongoose, Mongorito, TypeORM и т. д.? Для ответа нужно разобраться в чём отличие ORM от ODM. Смотрим википедию:

ORM (англ. Object-Relational Mapping, рус. объектно-реляционное отображение, или преобразование) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных».

То есть ORM — это именно про реляционное представление данных. Напомню, в реляционных БД нет возможности просто взять и встроить документ в поле другого документа (в этой статье записи таблиц тоже называются документами, хоть это и некорректно), можно конечно хранить в поле JSON в виде строки, но индекс по данным в нём сделать не выйдет. Вместо этого используются "ссылки" — в поле, где должен быть вложенный документ, вместо него записывается его идентификатор, а сам документ с этим идентификатором сохраняется в соседней таблице. ORM умеет работать с такими ссылками — записи по ним автоматически сразу или лениво забираются из БД, а при сохранении не нужно сперва сохранять дочерний документ, брать назначенный ему идентификатор, записывать его в поле родительского документа и только после этого сохранять родительский документ. Нужно просто попросить ORM сохранить родительский документ и всё что с ним связано, а он (object-relational mapper) уже сам разберётся как это правильно сделать. ODM же наоборот, не умеет работать с такими ссылками, зато знает про встроенные документы.

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

Решения с использованием elasticsearch имеют один существенный недостаток — очень большая вероятность рассогласования основной базы данных, например PostgreSQL, MySQL, mongodb и elasticsearch, в которой хранятся индексы для поиска.

Есть предложение. В связи с блокировками, давайте все массово просто попросим. Я понимаю, смешно. Но что то делать нужно. На https://rkn.gov.ru/ в самом низу есть «Сообщить об ошибке (Ctrl + Enter)». Давайте писать. Просто писать.

Я писал о docs.mongodb.com.

Присоединяйтесь. Вдруг что-то изменится?

Бывает, приходится делать сайты на flask, у которых есть пользователи и админы. Чисто для себя решил как-то это стандартизировать и, главное, не терять время, когда такая задача появляется. Цель — в несколько команд получить рабочий сайт у которого есть:

• Регистрация
• Email подтверждение
• Авторизация
• Выход (logout)
• Администраторы и роли администраторов
• Административная, пользовательская и публичная часть сайта
• Возможность юзера менять пароль
• Восстановление пароля
• Локализация для иностранных языков

Эта статья для вас, если вы:

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

Моя статья не для вас, если вы:

• хорошо умеете готовить свою любимую БД, оптимизировать индексы, настраивать и всякое такое;
• имеете в штате хорошего специалист, который сможет аргументировано выбрать нужный вашему проекту вариант. специалист должен быть действительно хорошим, а не «экспертом на диване»;
• обслуживаете проект с так называемым «big data», то есть у вас огромные базы, десятки или сотни серверов в кластере и всякое такое — ну у вас как бы должен быть в штате один или несколько специалистов.

О чем пойдет речь в статье?

Я разберу в своей статьи некоторые типичные и не очень варианты выбора баз данных, а если быть более точным — подходы к выбору. Когда следует остановится на том, что используют большинство, а когда можно и задуматься над новым и неизведанным. Я опишу СУБД MySQL, PostgreSQL, MongoDB, Redis, CouchDB/PouchDB и упомяну о Aerospike с Tarantool, парочку других — но в некоторых моментах конкретный выбор не настолько принципиален. Надо понимать, что лучше изначально правильно спроектировать структуру данных, чем выбрать СУБД, а потом уже пытаться придумывать, что в ней собственно хранить.
Итак, начнем.

Возникла необходимость выгрузки большого количества данных на клиент из базы MongoDB. Данные представляют собой json, с информацией о машине, полученный от GPS трекера. Эти данные поступают с интервалом в 0.5 секунды. За сутки для одной машины получается примерно 172 000 записей.

Серверный код написан на ASP.NET CORE 2.0 с использованием стандартного драйвера MongoDB.Driver 2.4.4. В процессе тестирования сервиса выяснилось значительное потребление памяти процессом Web Api приложения — порядка 700 Мб, при выполнении одного запроса. При выполнении нескольких запросов параллельно объем памяти процесса может быть больше 1 Гб. Поскольку предполагается использование сервиса в контейнере на самом дешевом дроплете с оперативной памятью в 0.7 Гб, то большое потребление оперативной памяти привело к необходимости оптимизировать процесс выгрузки данных.