MongoDB *

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

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

Хакер — человек, который наступает на грабли, которые спрятаны в сарай и закрыты на замок

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

Наш стартап Olery был основан почти 5 лет назад. Мы начали с единственного продукта, Olery Reputation, который был создан агентством, занимавшимся разработкой на Ruby. Всё это выросло в набор различных продуктов. Сегодня у нас есть ещё Olery Feedback, API для Hotel Review Data, виджеты для вставки на сайты и многое другое.

Всего у нас работает 25 приложений (все на Ruby) – некоторые из них в вебе (Rails или Sinatra), но в основном это фоновые приложения для обработки данных.

Хотя нам есть, чем гордиться, есть у нас одна проблема, которая всё время висела где-то в фоне – база данных. Изначально мы использовали MySQL для важных данных (пользователи, контракты, и т.д.) и MongoDB для хранения обзоров и других данных, которые легко можно было бы восстановить в случае утери. Сначала всё работало неплохо, но по мере роста мы начали испытывать проблемы, в особенности с MongoDB. Некоторые из них возникали в сфере взаимодействия БД с приложениями, некоторые – непосредственно у самой БД.

К примеру, в какой-то момент нам надо было удалить миллион документов из MongoDB, а позже вставить. В результате работа базы застопорилась на несколько часов. Потом нам пришлось запускать repairDatabase. И сама починка тоже заняла несколько часов.

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

Основные нововведения и улучшения:

• Произвольные механизмы хранения, в том числе WiredTiger. Теперь api монго отделено от того как база хранит данные. Это позволяет создавать новые способы хранения данных, например InMemory.
• Высокая производительность и эффективность. Новый механизм хранения WiredTiger использует блокировку на уровне документа, что позволяет значительно улучшить производительность. Так же он использует алгоритмы сжатия данных и индексов, что значительно уменьшает размеры хранимых данных.
• Упрощенные операции через Ops Manager. Он позволяет проводить такие операции, как развертывание, масштабирование, модернизацию и резервное копирование в несколько кликов или вызов API. Улучшена система логирования.
• Улучшен аудит безопасности.
• Улучшен язык запросов и инструменты. mongoimport, mongoexport, mongodump, mongorestore и mongooplog теперь работают быстрее. Возможность смотреть план выполнения до запроса с помощью explain.

С более подробной информацией вы можете познакомиться здесь:
Официальный анонс 3.0
Анонс основных нововведений в Mongodb 3.0
Вебинар «Что нового в Mongodb 3.0»
pdf Что нового в Mongodb 3.0

Как-то незаметно прошел анонс новой версии MongoDB. Изменение номера версии с 2 на 3 указывает на значительные изменения внутри базы данных. Разработчики заявляют о значительном увеличении производительности и улучшении маштабируемости. Немного подробнее под катом.

На фото: Том Круз в фильме Лучший Стрелок

В этой статье мы рассмотрим взаимодействие Single Page HTML Application с облачной MongoDB через JavaScript. В качестве MongoDB-as-a-Service я возьму Mongolab. Стоимость развернутой MongoDB, с объёмом в 500мб, обойдется нам всего-лишь в 0 USD.

Для того, чтобы создать todo-лист, нам не потребуется бекенд. Взаимодействовать с Mongolab мы будем через REST API, а обертку для него в клиентской части мы напишем не прибегая к помощи сторонних JavaScript-фреймворков.

Прим. перев.: Американский писатель Майкл Льюис известен не только своими историями о трейдерах с Уолл Стрит, но и (в первую очередь) книгой Moneyball, по которой впоследствии был снят одноименный фильм («Человек, который изменил все»). Главный ее герой – Билли Бин, генеральный менеджер бейсбольной команды «Oakland Athleticks», создает конкурентоспособную команду исключительно на основе анализа статистических показателей игроков.

Памятуя об этом, мы решили опубликовать один любопытный материал о том, к каким интересным и нетривиальным выводам можно прийти, анализируя публично доступную статистику игр NBA за последние 30 лет с помощью фреймворка MongoDB Aggregation. Несмотря на то, что в данном примере автор анализирует показатели команд в целом, а не статистику по отдельным игрокам (она также находится в открытом доступе), он приходит к весьма занимательным выводам – руководствуясь его выкладками вполне реально провести самостоятельный анализ, подобно тому, как в свое время поступили герои Moneyball.



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

Доброго времени суток, дорогой %habrauser%!

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

Эта моя публикация чуть более чем полностью является ответом на перевод статьи «Почему вы никогда не должны использовать MongoDB». Статья, которая, по сути, рекомендует держаться подальше от MongoDB, является самой заплюсованной в хабе. И это звучит как приговор. Поэтому логично либо хаб закрыть и больше никогда не читать, либо написать ещё более рейтинговое опровержение. Конечно же, я выбрал второй вариант, рискуя своим рейтингом и кармой (ввиду крайней холиварности в комментах).

Картинка самоиронии

Эскимо — новый Node.js бойлерплэйт для быстрого прототайпинга (MVP).

Даже если интернет заполнен разными бойлерплэйтами и фрэймворками, на нынешний день отсутствует современный, модульный и минимальный бойлерплэйт для запуска прототипов (специально для строительства rapid minimal product-ов «RMVP's»). Проект создается с малого, одним человеком, но потом, под влиянием вкладчиков, он растет до непредсказуемых размеров. Поиск в Google и GitHub про Nodejs бойлерплэйт и Nodejs фрэймворк дает сотни результатов.

Но многие из этих запускателей проектов не имеют автоматизации для развертывания и тестирования продуктов. Некоторые игнорируют практику фронт-энда и не используют Bower, Bootstrap, Font Awesome, S3/CloudFront, clustering и LESS. И ни один бойлерплэйт или фрэймворк не внедрили инъекцию зависимостей с помощью электролита, за исключением Эскимо и проектов Джареда Хэнсона.

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

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

Недавно на хабре была публикация о том, как реализована аналитика на ivi.ru. После прочтения захотелось рассказать об аналитике, которую мы делали для одного крупного сайта. Заказчик, к сожалению, не разрешил публиковать в статье ссылку на сайт. Если верить Alexa Rank, то трафик на сайте, для которого мы делали аналитику, раз в 10 больше, чем на ivi.ru.

Одним из преимуществ .NET бэкенда мобильных сервисов в Azure является наличие встроенной поддержки не только SQL Database (SQL Azure), но и других хранилищ данных.

При использовании node.js вы можете отказаться от работы с SQL и использовать другие возможные хранилища (например, как это написано в статье Криса Райзнера об Azure Table Storage), но эта функциональность не является встроенной, поэтому придется написать некоторое количество кода самостоятельно.

При использовании .NET большая часть функций для работы с хранилищами, отличными от SQL, уже интегрирована, поэтому нет необходимости создавать «фиктивные» таблицы, как в node.js, только для возможности отправлять запросы к данным.

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

Объектно-ориентированная охота на мамонта (записки делопроизводителя).

При написании статьи ни один мамонт не пострадал.

«Охота на мамонта» — одна из первых абстракций, созданных предками на стене в пещере.
Любуясь на шедевр, дальновидный вождь наверняка думал о там, как повысить эффективность охоты. Сам думал, потому что бизнес-аналитиков не было. Если бы были и пытались оптимизировать охоту, мы бы сейчас кормили морковкой мамонтов в зоопарке, а фраза «Россия – родина слонов» ни у кого не вызывала сомнений.

Как бы описал бизнес-аналитик охоту на мамонта, если бы мудрые предки его вовремя не съели?

Эта статья появилась на свет после прочтения материала «Почему вы никогда не должны использовать MongoDB». Ниже — история о том, как мы постепенно отказались от MySQL и пришли к использованию MongoDB в качестве основного хранилища данных.



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

Первым делом были сформулированы:

Дисклеймер от автора (автор — девушка): Я не разрабатываю движки баз данных. Я создаю веб-приложения. Я участвую в 4-6 разных проектах каждый год, то есть создаю много веб-приложений. Я вижу много приложений с различными требованиями и различными потребностями хранения данных. Я разворачивала большинство хранилищ, о которых вы слышали, и несколько, о которых даже не подозреваете.

Несколько раз я делала неправильный выбор СУБД. Эта история об одном таком выборе — почему мы сделали такой выбор, как бы узнали что выбор был неверен и как мы с этим боролись.Это все произошло на проекте с открытым исходным кодом, называемым Diaspora.

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

Впервые слышите о tornado? Слышали, но боялись асинхронности? Смотрели на него более полугода назад? Тогда я посвящаю эту статью вам.

Чуть больше года назад меня попросили поучаствовать в развитии одной известной в узких кругах (но не всегда с хорошей стороны) социальной сети. В то время я уже был фанатом языка Haxe, поэтому с тем на чём писать вопросов не возникало. А вот с БД они появились. Опыт использования MS SQL Server и MySQL говорили о том, что когда дело касается больших объёмов информации, то порой случаются сложности (практически невозможным становится изменение структуры БД, а когда-то быстрые запросы работают уже критически медленно). Посовещавшись с коллегами (у которых уже был опыт с Mongo), мы решили использовать именно эту СУБД. А о тех особенностях, которые всплыли в течение этого года я и расскажу ниже.

В процессе разработки интернет-магазина была поставлена задача реализовать адресную книгу для авторизованного пользователя. Таким образом, чтобы сам пользователь хранился в базе mysql, а связанные с ним адреса — в mongoDB. Отдельного внимания данная задача заслуживает в части управления пользователями и их адресными книгами из админки, основанной на SonataAdminBundle.

Исходные данные:

Есть доктриновская сущность User и доктриновский документ Address. Между ними должна быть установлена связь один-ко-многим. Всё это должно управляться с формы добавления пользователя в админке на базе сонаты. Поскольку у 1 юзера может быть много адресов, на форме добавления пользователей должна быть реализована коллекция форм добавления адресов с кнопками «добавить», «удалить» и inline редактированием полей связанных адресов. Этим мы и займёмся далее.

Что нам надо:

1) Установить @Gedmo\References doctrine-extension

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