Преобразование проекта Django из MySQL в Mongo, какие основные подводные камни?

Question

Я хочу попробовать Mongodb W / MongoEngine.Я новичок в Django и базах данных, и у меня есть связи с Foreign Keys, Joins, Circular Imports (вы называете это).Я знаю, что в конечном итоге смогу решить эти проблемы, но Mongo кажется мне более простым решением для того, что я делаю.Мой вопрос заключается в том, что я использую множество подключаемых приложений (Imagekit, Haystack, Registration и т. Д.) И хотел знать, будут ли эти приложения продолжать работать, если я сделаю переход.Есть ли какие-либо известные головные боли, с которыми я столкнусь, если так, я мог бы просто продолжать биться головой с MySQL.

Answer 1

Нет причин, по которым вы не можете использовать одну из стандартных РСУБД для всех стандартных приложений Django, а затем Mongo для своего приложения. Вам просто нужно заменить все стандартные способы обработки вещей из Django ORM на монгольские.

Таким образом, вы можете сохранить urls.py и его точное сопоставление с шаблоном, представления будут получать параметры, а шаблоны могут принимать объекты

Вы потеряете наборы запросов, потому что я подозреваю, что они слишком тесно связаны с моделями СУБД, но на самом деле они просто лениво оцениваются списки. Просто игнорируйте документы Django при написании файла models.py и кодируйте бизнес-логику своей базы данных в парадигме Монго.

О, и у вас не будет интерфейса администратора Django для быстрого доступа к вашим данным.

Answer 2

Возможно, вы захотите проверить django-nonrel , которая является молодой, но многообещающей попыткой использовать NoSQL для Django. Документация на данный момент отсутствует, но она прекрасно работает, если вы просто решите ее.

Answer 3

Я использовал mongoengine с django, но вам нужно создать файл, например, mongo_models.py. В этом файле вы определяете ваши монго документы. Затем вы создаете формы, соответствующие каждому монго-документу. Каждая форма имеет метод сохранения, который вставляет или обновляет то, что хранится в Mongo. Формы Django предназначены для подключения к любому бэкэнду данных (с небольшим хитростью)

ВНИМАНИЕ: Если у вас есть очень четко определенные и структурированные данные, которые можно описать в документах или моделях, не используйте Mongo. Он не предназначен для этого, и что-то вроде PostGreSQL будет работать намного лучше.

• Я использую PostGreSQL для реляционных или хорошо структурированных данных, потому что это хорошо для этого. Небольшая память и хороший отклик.
• Я использую Redis для кэширования или работы в очередях / списках памяти, потому что это очень хорошо для этого. отличная производительность, если у вас есть память, чтобы справиться с ней.
• Я использую Mongo для хранения больших JSON-документов, а также для выполнения Map и сокращения их (при необходимости), потому что это очень хорошо для этого. Обязательно используйте индексацию для определенных столбцов, если вы можете ускорить поиск.

Не кружите, чтобы заполнить квадратное отверстие. Это не заполнит его.

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

Answer 4

Я недавно попробовал это (хотя без Mongoengine). Здесь огромное количество подводных камней, ИМХО:

• Нет интерфейса администратора.
• Нет Auth django.contrib.auth зависит от интерфейса БД.
• Многие вещи зависят от django.contrib.auth.User. Например, класс RequestContext. Это огромное препятствие.
• Нет регистрации (зависит от интерфейса БД и django.contrib.auth)

По сути, ищите в интерфейсе django ссылки на django.contrib.auth, и вы увидите, сколько вещей будет сломано.

Тем не менее, вполне возможно, что MongoEngine предоставляет некоторую поддержку для замены / дополнения django.contrib.auth чем-то лучшим, но от этого зависит так много вещей, что трудно сказать, как обезьяна исправит что-то так много .

Answer 5

Основная ловушка (для меня): нет СОЕДИНЕНИЙ!

Answer 6

В начале, он не будет работать для любого существующего приложения Django, которое поставляет свои модели. В настоящее время нет никакого бэкэнда для хранения данных модели Django в mongodb или других хранилищах NoSQL , и, если не считать бэкэндов базы данных, сами модели являются чем-то спорным, потому что, как только вы приступите к использованию приложения someones (* 1003) * приложения в комплекте), которые поставляют триады моделей-представлений-шаблонов, когда вам требуется немного другая модель для ваших целей, вы должны либо отредактировать код приложения (просто неправильно), либо динамически редактировать содержимое импортированных модулей Python во время выполнения (магическое), разветвить исходный код приложения (громоздко) или предоставить дополнительные настройки (хорошо, но это редкий случай, когда django.contrib.auth, вероятно, является единственным широко известным примером приложения, которое позволяет вам динамически указывать, какую модель он будет использовать, как и случай с моделями профиля пользователя через настройку AUTH_PROFILE_MODULE).

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

Есть много прекрасных джангонавтов с хранилищами NoSQL. Если вы следили за потоками из прошлых презентаций Djangocon, каждый год шли важные дискуссии о том, как Django должен использовать хранилища NoSQL. Я почти уверен, что в этом или следующем году кто-то проведет рефакторинг API приложений и моделей, чтобы проложить путь к чистому дизайну, который в конечном итоге может объединить все различные варианты хранилищ NoSQL как часть ядра Django.