MongoDB *

ИДЕЯ

Идея проекта — попробовать реализовать базовые функции MongoDB API для поиска, сохранения, обновления и удаления документов так, чтобы можно было бы не меняя клиентский код вместо MongoDB использовать InterSystems Caché.

МОТИВАЦИЯ

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

Ну, а почему бы и нет?! ¯\_(ツ)_/¯

Стал я замечать, что из 15 гигабайт бесплатного месте, предоставленного Google, у меня почта занимает уже почти 12 гигабайт. И такая тенденция меня не радует.
С другой стороны я в качестве почтового клиента использую Thunderbird с полной синхронизацией. Т.е. все письма должны быть закачены. Так вот папка Thunderbird со всеми письмами и индексами занимает всего 3 гигабайта. Хотя по логике вещей размер должен не просто более менее совпадать с занятым местом на GMail, а быть побольше, т.к. Thunderbird не архивирует письма, а хранит как есть и еще индексы строит для ускорения поиска.
Проблема на лицо! Начинаем докапываться до сути.

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

• Частичный ( partial ) индекс
• Валидация
• Нововведения агрегационного фреймворка
• Новые опции в утилитах импорта экспорта
• Нововведения в CRUD
• WiredTiger и fsyncLock
• Новое GUI compass

Недавно мне удалось пройти сертификация C100DEV: MongoDB Certified Developer Associate Exam и C100DBA: MongoDB Certified DBA Associate Exam. В данной статье я хочу поделиться своим опытом и сказать на что следует обратить внимание при подготовке, и как проходил экзамен. Также приведу несколько примеров вопросов.

В целом, системы управления реляционными базами данных были задуманы как «один-размер-подходит-всем решение для хранения и получения данных» на протяжении десятилетий. Но растущая необходимость в масштабируемости и новые требования приложений создали новые проблемы для традиционных систем управления РСУБД, включая некоторую неудовлетворенность подходом «один-размер-подходит-всем» в ряде масштабируемых приложений.

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

В этой статье я расскажу об использовании нереляционной базы MongoDB для мониторинга журнальных файлов. Для мониторинга log-файлов существует множество инструментов, от мониторинга shell-скриптами, завязанными на cron, до кластера apache hadoop.



Подход с мониторингом скриптами текстовых файлов удобен только в простейших случаях, когда, например, проблемы выявляются наличием в журнальном файле строк «ERROR», «FAILURE», «SEVERE» и т.п. Для мониторинга больших файлов удобно использовать систему Zabbix, где Zabbix Agent (active) будет считывать только новые данные и с определённой периодичностью отправлять их на сервер.

Это достаточно вольный перевод статьи об основных новшествах асинхронного драйвера для mongodb используемого в tornado. Основной мотив, который послужил для написания этого перевода — новшества, появившиеся в этой версии, такие как поддержка asyncio, async, await и Python 3.5. Сама статья не сколько перечисление новшеств, сколько лаконичные примеры асинхронной работы с MongoDB.


Введение
asyncio
aggregate
Python 3.5
async and await

Новый тренд на HighLoad++ — множество докладов об использовании оперативной памяти. Слово Константину Осипову, разработчику платформы Tarantool, автору доклада «Что особенного в СУБД для данных в оперативной памяти».

Ты отвечал в MySQL за производительность, как так получилось, что ты решил разрабатывать свою СУБД?

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

MySQL по многим параметрам был работой мечты, но, к сожалению после того, как мы стали частью Oracle, многое изменилось.

Несколько моих коллег ушли в MariaDB, кто-то основал свою компанию (SeveralNines, FromDual). Я никогда не чувствовал себя «недогруженным», а с уходом многих ключевых разработчиков работа вообще превратилась в марафон по передаче знаний. Сопротивление поглощению, желание начать всё с чистого листа, бунт против медленного принятия решений большой компанией, нежелание по разным причинам уезжать в США, в конце концов, хорошее предложение от Mail.Ru, которому к этому моменту уже было около года — и я ушёл.

Если бы знал, куда ухожу, ещё десять раз подумал бы. Иногда вообще не было веры, что удастся сделать что-то полезное, чем будут пользоваться за пределами Mail.Ru, да и сейчас Tarantool очень далёк пока от «идеальной СУБД».

Привет, Хабр! Мы продолжаем делиться технологической кухней Retail Rocket. В сегодняшней статье мы разберем вопрос выбора БД для хранения больших и часто обновляемых данных.

На самом начальном этапе разработки платформы перед нами возникли следующие задачи:

• Хранить у себя товарные базы магазинов (т.е. сведения о каждом товаре всех подключенных в нашу платформу магазинов с полным обновлением 25 млн. товарных позиций каждые 3 часа).
• Хранить рекомендации для каждого товара (около 100 млн. товаров содержит от 20 и более рекомендуемых товаров для каждого ключа).
• Обеспечение стабильно быстрой выдачи таких данных по запросу.

Года полтора назад встал вопрос совместимости написанного кода с Python3. Поскольку уже стало более менее очевидно, что развивается только Python3 и, рано или поздно, все библиотеки будут портированы под него. И во всех дистрибутивах по умолчанию будет тройка. Но постепенно, по мере изучения, что нового появилось в последних версиях Python мне все больше стал нравится Asyncio и, скорее, даже не Acyncio а написанный для работы с ним aiohttp. И, спустя какое то время, появилась небольшая обертка вокруг aiohttp в стиле like django. Кому интересно что из этого получилось прошу под кат.

Вторая часть

Введение
Краткий обзор других фреймворков на базе aiohttp
1. Структура
2. aiohttp и jinja2
3. aiohttp и роуты
4. Статика и GET, POST параметры, редиректы
5. Websocket
6. asyncio и mongodb, aiohttp, session, middleware
7. aiohttp, supervisor, nginx, gunicorn
8. После установки, о примерах.
9.RoadMap

В последние несколько лет MongoDB приобрела огромную популярность среди разработчиков. То и дело в интернете появляются всякие статьи, как очередной молодой популярный проект выкинул на свалку истории привычные РСУБД, взял в качестве основной базы данных MongoDB, выстроил инфраструктуру вокруг неё, и как все после этого стало прекрасно. Даже появляются новые фреймворки и библиотеки, которые строят свою архитектуру целиком на Mongo (Meteor.js например).

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

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

Здравствуйте, любители нашего хаброблога и прочие читатели!

Мы планируем вновь отметиться на поле неувядающего Node.js и рассматриваем возможность издания этой книги:



Поскольку вполне понятен читательский интерес «а как он впихнул все это в двести страниц, и зачем мне это нужно»? под катом предлагаем перевод доскональной статьи Томислава Капана о том, зачем на самом деле нужен Node.js.

Как-то давно мы задумали написать один проект для Node.js которому очень нужно было работать с NoSQL базой данных, но при этом не иметь никаких зависимостей от внешних приложений. Как это обычно бывает, все закончилось разработкой новой библиотеки.

Начав разработку два года назад, желание использовать встроенную базу данных для web приложения казалось весьма странным. В самом деле, зачем? Сейчас, когда появился проект node-webkit, объяснить это гораздо легче. Используя встроенную базу данных возможно разработать web приложение двойного назначения. Такое приложение сможет работать как в классической схеме клиент-сервер, так и с использованием node-webkit как обычное загружаемое приложение. Важной особенностью и в том и другом случае является то, что код базы данных является частью вашего приложения, что избавляет от многих проблем совместимости и установки.

Здравствуйте, уважаемые пользователи и посетители Хабра. В первой статье Веб-приложения на Clojure были рассмотрены базовые инструменты и библиотеки для построения веб-проектов на Clojure. А именно Leiningen, Ring, Compojure, Monger, Buddy и Selmer. Здесь же речь пойдет об их практическом применении.

Однажды столкнулся с задачей: mongoDb использовался как кэш/буфер между backend на Java и frontend на node.js. Все было хорошо, пока не появилось бизнес требование перебрасывать большие объемы за короткое время через mongoDb (до 200 тыс. записей не более чем за пару минут). Для чего не так важно, важна что задача такая появилась. И вот тут уж пришлось разбираться во внутренностях монги…

[ Первая часть ]

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

Случаи использования разделены там на восемь статей, которые условно можно разделить на три группы. Мне показались самыми интересными для перевода три материала, связанные с e-commerce.

1. Операторы в aggregation framework
2. Каталог продуктов
3. Корзина и управления остатками на складе
4. Иерархия категорий

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

Деплойд — самый простой способ создать свой АПИ

Это просто как раз, два… ну вообщем вы счас все поймете:

1. Никаких бойлерплейтов
Всего лиш одной командой, вы можете запустить свой API. Это абсолютно пустой контейнер, который только и дожидается вас, чтобы вы заполнили его ресурсами. Работает из коробки — дополнительный код необязателен.

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

3. Панель управления
Добавляйте и управляйте вашими API ресурсами через интуитивный веб интерфейс панели управления.

4. Развертка в 1 шаг

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

Звучит красиво, но что собственно под капотом? А давай те глянем:

В BSON-ruby был найден баг, который в лучшем случае приводил к небольшому DoS, но большинство версий было уязвимо к инъекции в BSON (аналог SQL инъекции, BSON это бинарный аналог JSON, используемый для работы с базой).

На хабре уже как-то упоминалась особенность регулярок в руби — у нас ^$ значат не просто начало и конец строки, но и новую строку \n.

Но тогда в примерах были лишь XSS «javascript:a()\nhttp://», и я давно искал пример, когда регулярки приводят к чему-то серьезному. И вот пару дней назад, во время аудита внешних библиотек нашего клиента, наткнулся на следующий код в BSON-ruby.

def legal?(str)
  !!str.match(/^[0-9a-f]{24}$/i)
end

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

Не хотелось бы, чтобы пост воспринимался в ключе холиваров на тему SQL vs. NOSQL И так понятно что везде есть свои плюсы и минусы, в данном случае это просто где-то немного справки, где-то немного примеров из того, с чем приходилось сталкиваться. Примеры на mongo shell и на python.

1. Миграция в на новые версии в mongodb
   
   • До версии 2.6
   • С 2.6 до 3.0 версии
   • Новое в PyMongo
2. Запросы сравнения и логические
3. Полнотекстовый поиск в Mongodb, regexp, индексы и пр.
4. Атомарные операторы (модифицирующие данные )
5. Немного о транзакциях в Mongodb
   
   • Уникальный индекс
   • Двухфазный коммит
6. Агрегационный фреймворк и JOIN-ы в Mongodb
7. Примеры
   
   • Деревья, комментарии в Mongodb
   • Теги, блоги
   • Е-commerce, и сложные фильтры в Mongodb
8. Небольшая песочница на Python

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

Также доступны подготовленные к инсталляции бинарники и есть подробные инструкции по их установке, но мы для лучшего понимания процессов произведём собственную сборку. Все действия описанные ниже, выполняются в операционной системе openSUSE Linux версии 13.2 На текущий момент последней доступной версией MongoDB является версия с номером 3.0.3.