Объединение noSQL и ORM в инфраструктуре MVC для реального приложения

Question

В течение некоторого времени я пытался применить на практике некоторые «крутые» вещи, которые я читал о noSQL (couchDB, mongoDB, Redis ...) за последние годы.

IЯ довольно привык писать приложения с Django и начал использовать Play!когда Java является единственно приемлемым вариантом развертывания (и наслаждаюсь им тоже).Оба имеют модули для работы, например, с MongoDB , а у django также есть nonrel .Но я никогда не чувствовал потребности в noSQL.

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

Вариант использования

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

• Холодильник, который может иметь
  • одну или две двери,
  • класса A, B или C,
  • цвет поверхности
  • автономный или встроенный
• Духовка, которая может иметь:
  • газ или электричество или оба
  • Самостоятельная очистка или нет
  • автономная или встроенная

Решение SQL / ORM

Как видите, каждый объект может иметь несколькосвойства, которые могут быть ограничены по типу.

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

noSQL solutions

noSQL solutions IМожно подумать:

• с использованием RDF (с чем-то вроде Virtuoso или построением собственного упрощенного хранилища троек)
• с использованием ориентированной на документы базы данных, такой как MongoDB

Проблема

Но Мне не удается понять, как отличается (проще) разработка прагматично будет переход на решение NoSQL, все еще использующеефреймворк ORM с правильным адаптером (особенно с DODB).

Допустим, я использую Django с MongoDB через mongodb-engine.

Я все еще использую тот же ORM, поэтому япо-прежнему описывать эти объекты как модели, перечисляя все свойства.Таким образом, ORM выполняет точно такую ​​же работу!Затраты на создание миграции в случае изменения модели очень ограничены с помощью ORM (в частности, с чем-то вроде South), при этом нет ничего, что требовало бы изучения новой технологии само по себе.

Там могут быть / другие / преимуществаDODB и некоторые специфические для MongoDB (масштабируемость, обработка данных, возможно, производительность), но ... как насчет точного случая использования и проблемы, которую я описываю?

Скорее всего, я упускаю точку, поэтому здесьпришли реальные вопросы:

Для этого конкретного случая использования:

• Является ли этот пример хорошим или плохим для DODB (у вас есть хороший)?
• имеет ли смысл объединять ORM для базовых вещей (пользователи, заказы) и использование noSQL без ORM для сложных объектов, есть ли веская причина для полного перехода на noSQL или мне следуетоставайтесь со стандартным ORM / SQL?

Я понимаю, что ответы на эти вопросы могут быть частично субъективными, так что вы можете предполагать совершенное знание теории noSQL и SQL, а такжеОК ОРМ;наличие хороших мостов от стандартных ORM до БД noSQL.Давайте предположим, что мы говорим об этом сценарии использования с MongoDB в качестве альтернативы noSQL.

Но есть более общий вопрос - который является основным вопросом этого поста SO:

• Разве хороший ORM (такой как JPA, ActiveRecord или Django) не делает noSQL и, в частности, ориентированные на документы базы данных малопригодными?
• ... и стоит ли использовать noSQL с«классический» ORM?

(«мало пользы» с точки зрения программирования и обслуживания, производительность и аналогичные критерии - это другой вопрос, и для него требуется точное сравнение между продуктами)

[править]

Я также пытаюсь понять, не лучше ли отказаться от использования ORM при переходе на noSQL.Было бы неплохо иметь больше «динамических» моделей, например.У меня могла бы быть таблица, описывающая, что представляют собой модели Fridge и Oven (поля), и модели Fridge и Oven в коде могли бы конструировать свои представления динамически (формы для редактирования и списки для отображения).

Смежные вопросы:

[править] : это здесь, чтобы показать мое исследование, а также уточнить, что то, что я спрашиваю, не является общим для noSQL против SQL

• Является ли ORM избыточным с NoSQL API? : похоже!но я пытаюсь понять, почему большинство фреймворков (см. выше) предоставляют доступ к NoSQL через свои ORM.Это хорошая идея или нет?
• , почему использование ORM с NoSql (например, MongoDB) : более конкретно, чем предыдущий, но все же наоборот.Я утверждаю, что ORM делают noSQL бесполезным , а не наоборот!
• Когда заменить RDBMS / ORM на NoSQL
• Когда использовать MongoDB или другие ориентированные на документы системы баз данных?
• https://softwareengineering.stackexchange.com/questions/54373/when-would-someone-use-mongodb-or-similar-over-traditional-rdms

РЕДАКТИРОВАТЬ И ссылки:

• Siena : постоянный API для Java, созданный на основе хранилища данных Python для Google App Engine, пытающегося установить мост между мирами SQL и NoSQL.
• minimongo : легкий, без схемы, Pythonic Object-Oriented интерфейс для MongoDB

Answer 1

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

Я только что закончил проект, в котором мне пришлось отсоединить ORM от модели, чтобы я мог реализовать решение NoSQL, и оказалось, что это не так сложно, хотя иногда это было сложно, пытаясь выяснитьлучший подход.Поэтому, не вдаваясь в подробности своей реализации, я коснусь того, что мне нужно было сделать, чтобы она заработала, поскольку она может дать некоторое просветление, когда вы идете по тому же пути.

Мои настройки:

• Framework - Symfony 1.4
• ORM - Doctrine 1.4
• NoSQL - мое собственное решение

Цель:

• Сохранять пути к изображениям в файлах xml и базе данных
• Хранить пути описания html в файлах xml и базе данных

Я не хотел хранить изображения в виде больших двоичных объектов в постоянном хранилище (база данных), и я не хотел хранить пути к изображениям в базе данных, так как не хотел оплачивать дополнительные расходы при создании соединения с базой данных и запросе пути.Поэтому я решил сохранить информацию о пути в постоянном хранилище (файловой системе) NoSQL.

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

Все мои файлы NoSQL относятся к объекту (например, холодильник).Эти файлы содержат пути к связанным с ними активам (html-описание и изображения) в том, что я называю указателями, которые указывают на ресурсы в файловой системе.Я решил использовать формат XML для хранения данных, чтобы он выглядел примерно так:

// Path to pointer file
/home/files/app/needle/myApp/refrigerator/1/1.xml

// Example pointer
<pointer>/home/files/app/file/myApp/refrigerator/1.png</pointer>

Теперь в рамках структуры мне пришлось переопределить методы save (), чтобы я мог сохранить вышеупомянутые активы с помощью NoSQLAPI.Это было довольно просто, я просто проверял родительские вызовы и поддерживал значения, поступающие в методы, чтобы они не нарушали цепную логику (методы, вызывающие другие методы с теми же аргументами), о которых я не знал.Я также заставил свои пользовательские вызовы API NoSQL генерировать исключения, поскольку основной вызов save () был заключен в блок try / catch.Единственное, с чем вам следует быть здесь осторожным, это определить, стоят ли ваши активы NoSQL остановки всей транзакции.В моем примере мне пришлось выяснить, не будет ли загрузка изображения прервана, сохранив остальные поля формы в базе данных (я решил разорвать транзакцию).

Мне также пришлось изменить методы load ()чтобы получить активы, используя API-интерфейс NoSQL против стандартной логики модели.Как и в случае с методами сохранения, это было не так уж сложно сделать.Мне просто нужно было увидеть, что делали родительские классы, а не гадить с какими-либо значениями аргументов.

Когда все было сказано и сделано, я смог сохранить изображения и описания html в файловой системе с созданным xml-файлом.указатели, указывающие на их местоположение.Так что теперь я не выполняю вызов базы данных каждый раз, когда мне нужен актив.

Некоторые соображения (они могут быть включены в другие решения NoSQL, я должен был написать свой собственный):

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

Я думаю, что я преодолел все основные препятствия, с которыми я столкнулся при реализации решения NoSQL с помощью ORM, если выЕсли у вас есть другие вопросы, не стесняйтесь задавать мне вопросы.

- Правка -

Ответы на комментарии:

1. Как я уже упоминал, я не хотел создавать соединение с базой данных и делать запросы, чтобы просто получить путь к активу.Я чувствую, что для такого типа информации лучше использовать решение NoSQL, поскольку на самом деле нет причин запускать запросы к информации такого типа (изображения или описания html).

2. Разработка собственного NoSQLрешение было больше проблемой эго.На работе был проект по реализации пользовательского решения NoSQL (имел плохой опыт работы с MogileFS), и, честно говоря, был плохо спроектирован и плохо реализован.Но вместо того, чтобы просто указать на плохое, я поставил перед собой задачу предложить лучшее решение, но для стороннего проекта.И из-за проблемного аспекта я не исследовал уже доступные решения NoSQL, но, оглядываясь назад, я, вероятно, должен был это сделать.

Я все еще думаю, что вы можете реализовать MongoDB или любое решение NoSQL, переопределив функции crud на уровне модели вашего ORM, относительно просто.Фактически, я не только реализовал свое решение NoSQL, я также добавил возможность индексировать данные в SOLR (для полнотекстового поиска) также во время функций crud, так что все возможно.

Answer 2

Что я тоже пытаюсь понять, так это если бы не было лучше отказаться от использования ORM при переходе на noSQL

Не совсем выгодно полностью отказаться от ORM. Но, возможно, вам придется переписать его совсем немного. Существует множество мелочей, таких как транзакции, последовательные записи в четном формате, обработка ошибок и проверки целостности данных, которые ORM может обработать для вас в режиме noSQL.

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

Answer 3

Это довольно открытый вопрос, нет «правильного» ответа.Решение между NoSQL и SQL (ORM) зависит от слишком многих факторов.Несколько вопросов, которые я хотел бы задать:

• Насколько вы знакомы с обеими технологиями?
• Какое влияние компромиссов в вашем сценарии?Реляционная модель предоставляет некоторые гарантии, которых нет в NoSQL, и наоборот
• Как часто ваша модель может меняться?Эволюция приложения обычно требует смены модели, но сколько вы ожидаете от нее?

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

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

РЕДАКТИРОВАТЬ в комментарии (ответ не помещается в области комментариев):

@ Stefano Боюсь, я не вижуВаша точка зрения, поскольку использование NoSQL в каркасах (или использование ORM) зависит от ваших потребностей.

Это не проблема "хорошо использовать этот инструмент в этой среде", так как поддержка есть (часто)отлично.Вопрос должен звучать так: «Нужно ли мне использовать этот инструмент, почему и какие преимущества он мне дает?».

Если ответ «да, мне это нужно, потому что A, B и / или C», топросто продолжайте и используйте его.

Если ответ «нет, потому что А или В» или «это не имеет значения», то либо не используйте его, либо выберите наиболее подходящий вам вариантзнакомы с доступными вам.

То есть тот факт, что один фреймворк поддерживает что-то, не означает, что оно хуже или лучше, или его следует или не следует использовать.Вот почему я ставлю свои вопросы.В конце концов, это вопрос о NoSQL против SQL, поскольку инструменты, которые вы используете для его интеграции (ORM, SQL и т. Д.), Являются просто каналом для доступа к данным, и это менее важно, чем система хранения, которую вы выбираете для своей проблемы.(так как инструмент будет ограничен системой хранения по определению)