MongoDB *

В данной статье я бы хотел рассказать о разрабатываемой мной системе управления контентом Zoia, написанной на Javascript. Это мой side-project, не связанный с основной работой, который я разрабатываю и развиваю в свободное время. Есть мнение, что каждый веб-разработчик должен рано или поздно написать свою собственную CMS, а кто-то даже и не одну :-)

TL;DR: demo.zoiajs.org, панель администратора (логин: admin, пароль: password), Github, лицензия MIT

Друзья, очередной запуск курса «Базы данных» состоится уже завтра, поэтому мы провели традиционный открытый урок, запись которого вы можете посмотреть здесь. В этот раз поговорили о популярной БД MongoDB: изучили некоторые тонкости, рассмотрели основы работы, возможности и архитектуру. А также коснулись некоторых User Cases.



Вебинар провёл Иван Ремень, руководитель направления серверной разработки в «Ситимобил».

---

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

Предлагаю вам разобрать то, как можно создать гостевую книгу на ASP.NET Core (с reCAPTCHA) и захостить ее бесплатно на довольно известном облачном хостинге (да, с ограничениями, но для персонального вебсайта с не особо большим трафиком годится вполне)

Привет, Хабр!

Поделюсь опытом о том, как собрали собственную систему персонализации на базе «знаний» о потенциальном покупателе.



Единственное чем отличалось наше решение от классических — это использование комбинированной связки ряда решений и удовлетворял списку требований:

• сервис должен был работать сразу на N сайтах
• динамическая сегментация аудитории
• Коллаборативная фильтрация для целей прогнозирования в разных состояниях сегментов аудитории
• предварительно сгенеренная статика в виде рекомендованного контента + динамический подмес товаров на основе анализа кликстрима
• изменение контента, практически в реал-тайме, из оперативной памяти, с учетом динамических коэффициентов

Об этом подробнее :) И о тех граблях, которые помогали нам меняться стек в лучшую сторону.

Эта статья продолжает наш недавний материал про миграцию RabbitMQ и посвящена MongoDB. Поскольку мы обслуживаем множество кластеров Kubernetes и MongoDB, пришли к естественной необходимости мигрировать данные из одной инсталляции в другую и делать это без простоя. Основные сценарии прежние: перенос MongoDB из виртуального/железного сервера в Kubernetes или же перенос MongoDB в рамках одного кластера Kubernetes (из одного пространства имён в другое).

Мы — отдел большой компании, развивающий важную систему на 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 же наоборот, не умеет работать с такими ссылками, зато знает про встроенные документы.