Должны ли мы использовать OGM/ORM как Hibernate в Java для Mongodb?
Недавно я начал работать на монго. Поскольку вся концепция mongodb не содержит схем и документов, как я могу перенести отношения в сущности?
Я использовал hibernate ORM в Java для отображения объектов в таблицах. Есть ли необходимость сделать то же самое для mongodb?
Вещи, которые ограничивают меня от использования OGM:
Как только Java-сущность будет сопоставлена с коллекцией в монго, концепция монго, не имеющая схемы, останется в силе. В этом случае я должен отобразить переменные-члены на ключи этой коллекции. Кроме того, если коллекция монго должна содержать вложенные объекты или массив объектов, то что?
Hibernate недавно запустил свою OGM для баз данных NoSQL (январь 2015 г.).
Может кто-нибудь помочь мне с решением выбрать OGM для Монго?
2 ответа
Конечно, ORM просты в использовании, и многие из них позволяют нам использовать SQL или JPQL для запросов аналогично RDBMS, но ORM имеют свои собственные ограничения, и да, они также добавят немного накладных расходов (с точки зрения производительности)., Вот почему использование Java драйвера Native MongoDB является предпочтительным.
Для баз данных NOSQL выбор ORM зависит исключительно от варианта использования. ORM отобразит вашу таблицу (Collection в случае MongoDB) на объект Entity. Вы добавили, что вы можете сохранить карту в сущности, которая позволит вашему дизайну стать немного без схемы. В большинстве случаев наши данные почти структурированы, поэтому можно использовать ORM. Но если у вас есть полностью разносторонние и неструктурированные данные, перейдите на Java Driver. Проверьте документацию Монго.
Также есть и другие стабильные инструменты ORM, такие как Kundera, Spring Data. Вы должны изучить их.
PS:
- Этот ответ предназначен для ORM против собственного драйвера, а не для Hibernate ORM
- Я разработчик Кундеры
Я бы порекомендовал OGM-фреймворк, такой как Tinkerpop, или, если вам нужно что-то более высокого уровня и более похожее на Hibernate, рассмотрите Ferma. Ферма находится на вершине Tinkerpop и использует аннотации для определения классов Java, которые напоминают сущность в JPA и Hibernate. Разница в том, что Ferma и Tinkerpop созданы специально для графовых баз данных, а не пытаются встроить их в среду, разработанную для традиционных реляционных баз данных.
Хорошая особенность Ferma и Tinkerpop заключается в том, что, будучи созданными для графических баз данных, они все еще работают с реляционными базами данных. Существует несколько драйверов для Tinkerpop, которые позволяют ему работать практически на всех основных графических базах данных и реляционных базах данных на рынке. Он также может использовать драйверы в памяти, которые изначально существуют в Tinkerpop и поэтому вообще не нуждаются в поддержке какой-либо базы данных. Это чрезвычайно гибкая платформа, которая имеет много преимуществ, когда речь идет о модульном и гибком коде.
Для справки вот описание проекта Ferma.
Проект Ferma изначально был создан как альтернатива проекту TinkerPop2 Frames. Который в то время испытывал недостаток в функциях, необходимых сообществу, и его работа была крайне медленной. Сегодня Ferma - это надежная структура, которая играет роль, подобную библиотеке объектно-реляционной модели (ORM) для традиционных баз данных. Ferma часто называют библиотекой Object-graph Model (OGM) и отображает объекты Java на элементы графа, такие как Vertex или Edge. Короче говоря, это позволяет определять схему с использованием интерфейсов и классов Java, что обеспечивает уровень абстракции для взаимодействия с нижележащим графом.
А также описание проекта Tinkerpop.
Apache TinkerPop™ - это графическая вычислительная среда для графовых баз данных (OLTP) и графоаналитических систем (OLAP).
Примечание: я один из авторов Ферма.