MongoDB *

В интернете не так много статей о производительности GridFS, вот одна из них Serving files out of GridFS которая показывает, что отдача файлов из GridFS медленнее чем с диска в 6 раз.
Но в той статье есть недочет — в тестировании обращение идет к одному файлу, а при этом файл кешируется на уровне nginx либо файловой системы что дает отрыв по сравнению с GridFS. Да и неплохо проверить свежий GridFS, 3 года прошло как никак.
Поэтому я решил провести собственное тестирование, с обращением по разным именам файлов.

Есть 52 тыс файлов — постеры к фильмам, общий объем 2Гб, средняя картинка весит 40кб. Копия файлов на ext4, копия в GridFS.
Виртуалка 512Мб с 1 ядром. Ubuntu server 12.04 LTS 64bit, настройки Nginx/1.4.1 стандартные.
Тест рассчитан на low-cost сервер, для мощных серверов результаты будут другие.

Способы отдачи файлов:
1) Nginx — статика
2) Gevent через nginx
3) 2 x Gevent через nginx (балансировка)
4) Gevent напрямую
5) Gevent через nginx (unix socket)
для пунктов 2-5 использовался http сервер на Python + Gevent который отдавал файлы из GridFS

Способы нагрузки:
1) ol, t2 — Обращение к одному url, 2 потока
2) ol, t10 — Обращение к одному url, 10 потоков
3) t2 — Обращение к разным url, 2 потока
4) t10 — Обращение к разным url, 10 потоков

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

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

В последнее время набирает популярность семейство подходов и методологий обработки данных, объединенных общими названиями Big Data и NoSQL. Одной из моделей вычислений, применяемых к большим объемам данных, является технология Map-Reduce, разработанная в недрах компании Google. В этом посте я постараюсь рассказать о том, как эта модель реализована в нереляционной СУБД MongoDB.

Что касается будущего нереляционных баз вообще и технологии Map-Reduce в частности, то на эту тему можно спорить до бесконечности, и пост совершенно не об этом. В любом случае, знакомство с альтернативными традиционным СУБД способами обработки данных является полезным для общего развития любого программиста, так же как, к примеру, знакомство с функциональными языками программирования может оказаться полезным и для программистов, работающих исключительно с императивными языками.

Нереляционная СУБД MongoDB представляет данные в виде коллекций из документов в формате JSON и предоставляет разные способы обработки этих данных. В том числе, присутствует собственная реализация модели Map-Reduce. О том, насколько целесообразно применять именно эту реализацию в практических целях, будет сказано ниже, а пока ограничимся тем, что для ознакомления с самой парадигмой Map-Reduce эта реализация подходит как нельзя лучше.

Итак, что же такого особенного в Map-Reduce?

Суть проблемы

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

{
    _id: 123,
    firstName: "John",
    lastName: "Smith",
    age: 25,
    height: 6.0,
    dob: Date,
    eyes: "blue",
    sign: "Capricorn",
    ...
}

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

Если вы молоды и энергичны интересуетесь mongoDb, хотите подискутировать на тему перевода слова tailable на русский, и вас интересует откуда взята пикрелейтед — добро пожаловать под кат.

В данной статье будет рассмотрена одна из новых возможностей MongoDB версии 2.4 — полнотекстовый поиск. Большая часть этой статьи будет вольным переводом документации, которая, к слову, очень подробная, но разрозненная. Здесь все будет собрано вместе. Так как этого для полноценной статьи мне показалось мало, я решил сравнить МонгоДБ с другой популярной программой для текстового поиска — Sphinx. Мое сравнение будет очень поверхностным, так как со Сфинксом я раньше не работал. Создам таблицу с 16 000 000 записей и посмотрю, кто быстрее.

Сегодня состоялся релиз финальной версии MongoDB 2.4. Одна из новых возможностей — поддержка полнотекстового поиска с морфологией и стоп-словами. Правда, пока только в экспериментальном режиме. Среди 15 поддерживаемых языков есть и русский, что очень радует.

Ещё одно заметное изменение — смена движка javascript. Вместо SpiderMonkey теперь используется V8. Довольно логичный шаг, теперь было бы неплохо посмотреть сравнительные тесты map-reduce.

Также можно отметить улучшения в индексировании и выборке гео-данных.

И ещё одно крупное изменение: добавление ролей пользователей и привилегий(read, readWrite, dbAdmin, clusterAdmin и т.д.). Посмотрим, что из этого выйдет.

Полный список изменений

Меня порадовало, что вместе с основным релизом вышла новая версия драйвера для C# с поддержкой новых возможностей.

Драйвер C#

Перевод этой статьи уже есть на хабре, но он ужасен и содержит ложную информацию.

Приветствую, искатели приключений! Путешествуя по территории индексации MongoDB хотя бы некоторое время, вы, возможно, познакомились с таким правилом: если ваш запрос содержит сортировку/порядок (orderby) – добавьте сортируемое поле в конец индекса который используется для запроса.

Во многих случаях когда запрос содержит равенство (то есть поиск конкретного значения, например, {“name”: “Charlie”}) данная мантра бывает весьма полезной.

Запрос

db.drivers.find({"country": {"$in": ["A", "G"]}}).sort({"carsOwned": 1})

Индекс

{"country": 1, "carsOwned": 1}

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

system.indexes

• Предисловие
• Настройка Amazon EC2
• Установка MongoDB
• Настройка репликации
• Что почитать

local.abstract

В этой статье я расскажу о том, как максимально безболезненно организовать репликацию MongoDB на базе Amazon EC2. Несомненно, существует отличная документация как по работе с Amazon EC2, так и по настройке MongoDB в целом и репликации в частности. Но, как известно, дьявол живёт в мелочах. И в этой статье я выделю те “мелочи”, которые более всего донимали меня.

23 января 2013 года будет создана первая в Украине MongoDB User Group. Мы хотим, чтобы больше людей изучили и полюбили более гибкую, масштабируемую, документо-ориентированную СУБД «MongoDB».

Зачем это необходимо? Мы создадим теплую и ламповую обстановку для задушевных технических бесед, каждый раз будут новые лица как среди докладчиков, так и среди участников, будем готовить действительно интересные презентации по MongoDB. Одним словом, регулярные мероприятия, на которые тратить время можно и нужно.

Первая встреча организована при поддержке внутреннего движение по свободному обмену знаниями Ciklum Practice Leaders, но это только начало.

UPD: для всех желающих организована прямая трансляция докладов на сайте сообщества http://mongoua.tk/
Вопросы докладчикам можно задавать с хеш-тегом #MongoUA

Заканчиваются курсы по MongoDB для разработчиков и архитекторов баз данных от 10gen, компании разработчика MongoDB.
Финальный экзамен отправлен на проверку и хотелось бы поделиться впечатлениями от курса и полученной информации, рассказать о плюсах и «минусах» MongoDB.

— документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Написана на языке C++ и распространяется в рамках лицензии Creative Commons.

В последнее время становится довольно популярной и восстребованой. И вот возникла идея использовать ее в связке с фреймворком Django. Собственно о чем далее и пойдет речь.

Вечер добрый, хабр. На прошлой неделе стартовал курс «MongoDb for developers» от 10gen, о котором уже писали на хабре. Если вы смотрели уроки, то можете смело проходить мимо. Остальным — добро пожаловать.

В этой статье будет изложен основной материал первой недели обучения. Если аудитория проявит интерес — то подобные посты будут выходить в конце каждой недели.

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

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

Для тех, кто пропустил топик 20-дневной давности от creage: сегодня начались два бесплатных курса по MongoDB, на которые ещё можно записаться:

M101: MongoDB for Developers

M102: MongoDB for DBAs

Все, кого интересуют детали, могут заглянуть в топик-анонс: MongoDB для разработчиков

MongoDB — замечательная база данных, которая становится все популярнее в последнее время. Все больше людей с SQL опытом начинают её использовать, и один и первых вопросов, который у них возникает: MongoDB transactions?.

Если поверить ответам со stackoverflow, то все плохо.

MongoDB doesn't support complex multi-document transactions. If that is something you absolutely need it probably isn't a great fit for you.

If transactions are required, perhaps NoSQL is not for you. Time to go back to ACID relational databases.

MongoDB does a lot of things well, but transactions is not one of those things.

Но мы не поверим и реализуем транзакции (ACID*) основанные на MVCC. Ниже будет рассказ о том, как эти транзакции работают, а тем, кому не терпится посмотреть код — добро пожаловать на GitHub (осторожно, java).

Пост не о MongoDB, а о том, как использовать compare-and-set для создания транзакций, а durability обеспчивается ровно в той степени, в которой её обеспечивает хранилище.

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

В последнее время я все чаще слышу о NoSQL и о графовых базах данных в частности. Но воспользовавшись хабропоиском с удивлением обнаружил, что статей на эту тему не так и много, а по запросу «Neo4j», так вообще 4 результата, где косвенно упоминается это название в тексте статей.

Что такое Neo4j?

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

Как я докатился до этого?

Уже более года я не использовал в своих проектах SQL, с того времени, как попробовал документо-ориентированную СУБД "MongoDB". После MySQL моей радости не было предела, как все просто и удобно можно делать в MongoDB. За год, в нашей студии создания сайтов, переписали тройку CMS, использующих основные фишки Mongo c её документами, и с десяток сайтов работающих на их основе. Всё было хорошо, и я уже начал забывать, что такое писать запросы в полсотни строк на каждое действие с БД и все бы ничего пока на мою голову не свалился проект с кучей отношений, которые ну никак не укладывались в документы. Возвращаться к SQL очень не хотелось, и пару дней я потратил чисто на поиск NoSQL решения, позволяющего делать гибкие связи — на графовые СУБД. И по ряду причин мой выбор остановился на Neo4j, одна из главных причин — это то, что мой движок был написан на PHP, а для неё был написан хороший драйвер "Neo4jPHP", который охватывает почти 100% REST-интерфейса, предоставляющегося сервером Noe4j.

Вчера состоялся долгожданный релиз NoSQL базы данных MongoDB 2.2.0.
Среди самых важных нововведений стоит отметить:

Aggregation Framework
Инструмент, оптимизирующего обработку больших массивов данных без map-reduce (больше информации на хабре)

TTL-коллекций
TTL-коллекции позволяют удалять из коллекции данные, у которых вышло время жизни, установленое с помощью специального индекса(удобно, например, для хранения логов, сессий и подобной информации). При использовании таких коллекций создается дополнительный фоновый процесс для реализации соответсвующей проверки
docs.mongodb.org/manual/release-notes/2.2

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

В целом скажу так: работать с MongoDB удобнее чем с MS SQL. Регулярно встречаются сценарии, которые требуют больше усилий по сравнению с SQL, однако, в результате ты больше знаешь о том, как устроена твоя база данных и лучше контролируешь что будет тормозить, а что — нет.

На хабре полно приложений в стиле «Hello World», так что инициализацию среды опустим и перейдем сразу к более продвинутым вопросам, а именно:

• Почему удобнее хранить весь объект целиком, а не по таблицам?
• Как бороться с реляциями?

Введение

В начале июля вышла очередная версия(1.5) официального драйвера MongoDB для C#. Среди нововведений стоит отметить поддержку типизированных запросов. Теперь появилась возможность использовать лямбда-функции в связке с Expression.
В этой статье я покажу примеры нового синтаксиса, который мне очень нравится(а мне вообще Expression в C# очень нравится), а также продемонстрирую примеры запросов, где, увы, Expression нам ничем не поможет и придется вернуться к привычным строкам. Также я порассуждаю, почему оно так, и будет ли когда-нибудь всё прекрасно в С# при работе с MongoDB.