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

Недавно меня спросили, как фронтенд-разработчику проще всего сохранить пользовательские данные? Под катом — моя краткая инструкция для тех, кто с базами данных «на вы».

Компания MongoDB Inc. анонсировала следующую версию одноименной NoSQL базы данных с открытым исходным кодом — MongoDB 3.6. В ней представлены новые инструменты для разработчиков и апдейт безопасности. Последний связан с серией кибератак на компании, использующие эту СУБД.

О том, что изменили разработчики, и какие функции внедрили, расскажем далее.

Перед вами четвёртая часть серии материалов, которые посвящены разработке веб-приложения Budget Manager с использованием Node.js, Vue.js и MongoDB. В первой, второй и третьей частях речь шла о создании основных серверных и клиентских компонентов приложения. Сегодня мы продолжим развитие проекта, а именно — займёмся списками документов и клиентов. Кроме того, нельзя не заметить, что к настоящему моменту сделано уже немало, поэтому вполне можно критически взглянуть на то, что получилось, и поработать над повторным использованием кода.

Напомним на всякий случай, если кто-то забыл, что GitHub – это одна из крупнейших платформ для разработки программного обеспечения и дом для многих популярных проектов с открытым исходным кодом. На страничке «Explore» GitHub вы можете найти информацию о проектах, которые набирают популярность, проектах, понравившихся людям, на которых вы подписаны, а также популярные проекты, объединенные по направлениям или языкам программирования.

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

В этой статье мы делимся нашим опытом построения системы рекомендаций для GitHub от идеи до реализации.

Исследователи информационной безопасности сообщили о новой волне атак хакеров-вымогателей на серверы с установленной MongoDB. Начиная с прошлой надели было взломано более 26 000 серверов, причем 22 000 из них были атакованы одной кибергруппой.

Приветствую бойцов невидимого бэкенда!

Вы уже почитали обзоры MongoDB. Вероятно, прошли отличные онлайн-курсы на university.mongodb.com. Конечно, у вас уже есть многообещающий проект-прототип с использованием MongoDB.

Что мы можем ждать от MongoDB на этом этапе?

• Удешевление хранилища — чтение с ведомых реплик экономит iops мастера, не требуется RAID, отказ одного диска не фатален.
• Повышаем скорость разработки — можно допустить бОльшую небрежность в проектировании структур данных, т.к. мы вполне можем все исправлять на работающем приложении.
• Повышаем отзывчивость приложения — независимо от разработки, легко увеличить число ведущих реплик или количество шардов, чтобы компенсировать возросшую нагрузку на приложение.
• Повышаем надежность приложения — независимо от разработки, убираем единую точку отказа.

И вот, вы готовы ввязаться в бой — выпустить проект на публику.

Как вы уже знаете, MongoDB — это одно из наиболее развитых, open-source NoSQL решений, которое представляет собой документо-ориентированную базу данных, является кросс-платформенным, а также обеспечивает высокую производительность, доступность и простоту масштабирования.

В современных open-source веб-приложениях использование NoSQL решений получило свою популярность в связи с их нереляционным поведением. В данной статье шаг за шагом мы реализуем простое ASP.NET Core Web API приложение «записной книжки», которое будет поддерживать операции CRUD применимо к коллекции в MongoDB.

Обычно при веб-разработке на всех уровнях стека используются разные языки программирования. База данных MongoDB, фреймворки Express и AngularJS и технология Node.js вместе образуют стек MEAN — мощную платформу, на всех уровнях которой применяется всего один язык: JavaScript. Стек MEAN привлекателен для разработчиков и бизнеса благодаря простоте и экономичности, а конечные пользователи любят MEAN-приложения за их скорость и отзывчивость.

JavaScript достиг зрелости. Благодаря ему теперь можно создать веб-приложение от начала до конца с помощью всего одного языка программирования. Стек MEAN включает в себя лучшие в своем классе технологии в данной области. В качестве БД вы получаете MongoDB, в качестве серверного фреймворка веб-приложений — Express, в качестве клиентского фреймворка — AngularJS, а в качестве серверной платформы — Node.

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

Discord продолжает расти быстрее, чем мы ожидали, как и пользовательский контент. Чем больше пользователей — тем больше сообщений в чате. В июле мы объявили о 40 млн сообщений в день, в декабре объявили о 100 млн, а в середине января преодолели 120 млн. Мы сразу решили хранить историю чатов вечно, так что пользователи могут вернуться в любой момент и получить доступ к своим данным с любого устройства. Это много данных, поток и объём которых нарастает, и все они должны быть доступными. Как мы это делаем? Cassandra!

Петр Зайцев показывает разницу между MySQL и MongoDB. Это — расшифровка доклада с Highload++ 2016.

Если посмотреть такой известный DB-Engines Ranking, то можно увидеть, что в течении многих лет популярность open source баз данных растет, а коммерческих — постепенно снижается.

Так как колоночная СУБД ClickHouse (внутренняя разработка Яндекс) стала доступна каждому, решил использовать эту СУБД заместо MongoDB для хранения аналитических данных. Перед использованием сделал небольшой тест производительности и хочу поделиться результатами с IT сообществом.

Сергей Туленцев (TextMaster)

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

Кому будет полезен этот доклад? Это обзорный доклад с претензией на структурированность. Если вы что-то где-то когда-то слышали про NoSQL, то через 40 минут вы будете знать гораздо больше, вы будете легче ориентироваться в терминах и более уверенно выбирать базы данных для своего проекта.

Поговорим также про типичные примеры применения и как не надо применять NoSQL базы данных.

В предыдущей статье я писал о загрузке файлов в GridFS. Там мы создали MongoDB документ со свойством $file, аннотированным как @MongoDB\File. Так как ORM сущности я использую чаще, чем ODM документы, я искал простой способ получить доступ к документу из сущности.

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

Введение

Здраствуйте, дорогие хабровчане! Сегодня у нас в основном будут маленькие изменения, но изменений много. В этой части мы будем:

• Создавать свой логгер
• Записывать в лог запросы и время их обработки
• Исправлять ошибки, которые мы допустили в первой части.
• Разбираться с авторизациеей
• Разбираться с некоторыми классами
• Конфиги!

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