Изучение PyMongo и когда использовать ODM вместо реального

Об отображении объекта-документа

Один из  вопросов PyMongo, который мне чаще всего задают, заключается в том, должны ли люди использовать PyMongo напрямую или использовать один из ODM (Object-Document Mappers: думайте ORM для нереляционных баз данных), которые были написаны поверх него. Я всегда рекомендовал «просто использовать PyMongo» — я постараюсь объяснить почему в этом посте. Хотя это делает этот пост немного специфичным для Python, я думаю, что большая часть размышлений здесь одинаково хорошо применима к Ruby, PHP и т. Д.

Избегание нового программного обеспечения

MongoDB это новое программное обеспечение. Он используется во многих высокоразвитых производственных приложениях, и я думаю, что это отличный выбор практически для всех разработок веб-приложений, но это все еще относительно молодой проект. С практической точки зрения, молодежь означает, что вы, скорее всего, столкнетесь с ошибками, или просто с ситуациями, которые еще недостаточно документированы или где лучшие практики еще не разработаны. Имея это в виду, я думаю, что имеет смысл ограничить ваше знакомство с новым программным обеспечением. Опять же, я думаю, что преимущества MongoDB делают его достойным выбором. Однако добавление ODM в микшер зависит от еще более нового программного обеспечения, поэтому вам, возможно, придется быть готовым к появлению некоторых новшеств (отчетов об ошибках, исправлений и т. Д.).

Придерживаться Lingua Franca

Одна из лучших частей
 Лучшая часть о MongoDB — это сообщество. Список рассылки всегда активен и невероятно полезен, несмотря на то, что пока не является списком Fiesta :). Одна из проблем, с которыми мы столкнулись при масштабировании инфраструктуры сообщества / поддержки, заключается в том, что в использовании MongoDB существует большое разнообразие. Существуют десятки различных языковых драйверов, каждый из которых имеет как минимум пару особенностей. Когда вопрос попадает в список рассылки, первым шагом в ответе всегда является выяснение того, на что нацелен вопрос: это вопрос MongoDB или PyMongo / Ruby-driver / и т.д. вопрос? Для вопросов последней категории достаточно ли общего, чтобы на него мог ответить любой, кто имеет опыт работы с MongoDB, или это территория, на которую может ответить только эксперт по PHP?

На общие вопросы гораздо чаще можно получить быстрый и обстоятельный ответ: гораздо больше людей имеют право на них ответить. Придерживаясь «лингва франка» MongoDB (в Python это PyMongo), вам будет легче получать помощь, когда она вам нужна.

Понимание того, что под капотом

Наконец, я предлагаю использовать PyMongo напрямую, потому что, даже если вы используете ODM, по всей вероятности, в какой-то момент вам нужно будет знать, как использовать PyMongo напрямую. Как и в случае с ORM, ODM имеют тенденцию очень хорошо обрабатывать основные случаи. К сожалению, большинству приложений в конечном итоге требуется выполнить хотя бы одну или две операции, которые не полностью охвачены OxM: разработчикам в конечном итоге необходимо отказаться от абстракции и написать сырой SQL (или «сырые» операции PyMongo).

Так как вы должны планировать, что вам все равно придется заглядывать «под капот», я думаю, что имеет смысл начать с изучения работы PyMongo. Таким образом, если вы решите использовать ODM позже, у вас будет хорошее представление о том, что он делает. Когда дела ведут себя странно или когда вам нужно сделать что-то «продвинутое», у вас уже есть опыт, необходимый для того, чтобы вернуться под капот.

Важно отметить, что использование PyMongo напрямую сильно отличается от встраивания запросов SQL в код вашего приложения. Одна из замечательных особенностей MongoDB — то, как водителям удается чувствовать себя «родным» на многих языках. В Python вы просто работаете со словарями. Это может быть не такая хорошая абстракция, как классы моделей, но это, безусловно, шаг вперед по сравнению с необработанным SQL.

Быстрый отказ от ответственности

Мне посчастливилось работать с разработчиками  MongoEngine ,  MongoKit  и Ming  (три из самых популярных Python ODM) во время моей работы над проектом PyMongo. Эти люди умны, и я думаю, что их программное обеспечение хорошо. Поэтому даже после прочтения этого поста я рекомендую вам проверить проекты и решить для себя, хотите ли вы использовать один из них; они не для меня, но они могут быть для вас.

Наша установка

Я объяснил, почему мы используем PyMongo напрямую, а не ODM, но я не объяснил, как мы его используем. Вот краткий обзор настроек, которые мы используем для Fiesta :

У нас есть единственный модуль,  db.py , где мы размещаем вспомогательные методы для любых взаимодействий с PyMongo. Эти методы в основном состоят из одной или двух строк, вот пример:

def new_group(group):
    db.groups.insert(group, safe=True)
    return group

Причина размещения всего в одном модуле в основном организационная — мы можем легко увидеть все различные типы запросов и команд, которые мы используем.

Есть некоторые места, где мы вызываем эти методы напрямую из других частей приложения, но по большей части мы склонны заключать вызовы в домодельные классы Model (например, модель Group или модель User). Таким образом, мы можем поместить валидацию и другие тонкости непосредственно в код модели. Наша модельная инфраструктура является доморощенной, но я думаю, что что-то вроде DictShield может быть правильным сочетанием простоты и простоты использования здесь.

При использовании наших собственных моделей или чего-то подобного DictShield конечный результат не сильно отличается от использования ODM (хотя мы делаем немного больше работы, чтобы соединить все вместе). Однако я думаю, что преимущество заключается в том, что мы храним валидацию и моделирование совершенно отдельно от взаимодействия с базой данных. Это должно облегчить большинство проблем, которые я указал выше.

Я хотел бы услышать от других людей на эту тему. У вас был успех с ODM, или вы используете подход, аналогичный нашему? Что работает, а что нет?