I am trying to understand better EclipseLink NoSQL, but I am having trouble understand it's limitations, what it currently supports and I simply can't find anything about the future plans the team has.
So, in short, I have quite a big list of questions that i would like to know, if you people don't mind:
Does EclipseLink support:
Object Oriented queries
CRUD of entities
Polymorphic entities
Embeddable objects (components)
Basic types
Unidirectional and Bidirectional relationships (if yes, which ones?)
Collections (Set, List, Map, etc)
Full JPA support (I assume it does, but just in case I am wrong)
Denormalization
Complex joins and aggregations
Apart from these questions, are there any other limitations or jewels of the crown that I should know of?
Also, what is the team currently working in? What are the future plans?
I would be super happy if someone here could provide me with links or documentation for the questions I provided above, since I couldn't find anything :S
Thanks in advance, Pedro.
This depends on the NoSQL platform, for MongoDB a subset of JPQL and Criteria are supported (joins to external relationships are not supported)
Yes.
Yes, inheritance is supported.
Yes, Embeddables are supported, and ElementCollections (these are stored inline in the JSON document)
Yes
All unidirectional relationships are supported, bi-directional (mappedBy) is not supported, in NoSQL you just need to use two unidirectional relationships.
Yes.
Most of JPA. Some features such as joins, atomic transactions are not supported if the NoSQL platform does not support them (JPA transactions work, just rollback will not result in a rollback of any flushed changes if the database does not support transactions).
Yes.
Joins are not supported. Queries to embedded relationships is.
In an effort to complete the content of this discussion, I am now posting what I have found.
Currently (use discussion date as reference) EclipseLink Supports:
Complex hierarchical (including XML)
Indexed hierarchical data
Mapped hierarchical data (such as JSON)
CRUD operations
Embedded objects and collections
Inheritance
Relationships
Subset of JP-QL and Criteria API, dependant on NoSQL database's query support
Still needing answer:
Eclipselink limitations
Future plans
Sources:
http://www.eclipse.org/eclipselink/documentation/2.5/concepts/nosql001.htm#BJEIHEJG
http://wiki.eclipse.org/EclipseLink/FAQ/NoSQL
http://www.eclipse.org/eclipselink/documentation/2.5/concepts/app_tl_ext003.htm#CJAECHBD
http://www.eclipse.org/eclipselink/documentation/
Related
My startup project require complex data structure, which must be ready for geolocation and fulltext search. The information in the database are added by two different types of users, who together build a complex relationship network.
For a better understanding of my questions, here is a simple diagram that shows this relationship:
My first choice was MongoDB and Elasticsearch, but I noticed the problem of multiplication of the same data. Further planning, we concluded that for certain parts of the application need ACID transactions possibilities.
What NoSQL database is good for complex many to many relationships?
What would be a good choice for us?
A graph database like Neo4j is perfect for that.
If you need features of a document database like MongoDB, but with Neo4j under the hood, try Structr: http://de.slideshare.net/AxelMorgner/neo4j-as-document-database http://structr.org
(Disclaimer: I'm the project inititator of Structr)
I'm interested in using Ming to model my 100+ GB data set which is largely non-relational data (signals measured in a lab) with some "relational" meta-data (e.g. experiment name) in MongoDB. This is not a question about whether or not I should be using a NoSql database.
If modeling relationships using an ODM (e.g. Ming's version here) is a valid design pattern than why aren't any of the other popular ODMs providing that functionality? I didn't see it in any of the following:
-Mongoose (MongoDB)
-cqlengine (Cassandra)
-Hector (Cassandra)
-doctrine (CouchDB)
It's definitely valid to model relationships in a NoSQL data store, although if you have highly relational data you might want to reconsider whether the data store and schema design you have chosen is working with or against your use case goals.
In MongoDB a common decision (based on your use case) is whether it might be more appropriate to model relationships by embedding related data in the same collection or using a reference linking to document(s) in another collection (see: Data Model Design in the MongoDB manual).
Foreign key relationships are typically not populated or enforced with server-side support from distributed NoSQL databases, so declarative references in an ODM often translate into multiple queries on the server. Multiple queries aren't necessarily bad (although there can be poorly written extremes) and an application-level data join using references can be very convenient.
For MongoDB in particular, there is a BSON field type for Database References (DBRefs). There is currently (as at MongoDB 2.6) no support for server-side expansion of DBRefs, however many of the drivers and ODMs provide convenience methods for following and populating references in this standard notation.
You can see this used in a few of the ODMs you've mentioned:
Mongoose supports population of documents from other collections
Doctrine ODM supports references mapping relationships to other classes/collections
Typically ODMs offer a choice of either automatic population of references or lazy population (i.e. as needed or accessed in code).
I'm not familiar with the Cassandra libraries, but didn't see any obvious mention of references or relationships in the documentation. I would assume that presence (or absence) of a relationship feature is more a choice of the author(s) of the ODM rather than a specific pattern/antipattern.
I think its fair to say I'm pretty new to MongoDB having just installed the database this afternoon.
I'm managing to get to grips with storing and retrieving objects but am struggling to find the best way of storing objects that have a many-to-many relationship.
I've already come accross the DBRef object and have got that working but this seems to only support a lazy loaded approach.
Is there a way to encourage MongoDB to eagerly load DBRefs?
Is there a better/different way to store the many-to-many relationship?
Many thanks
Rob
So first, I think you need to look at this question over here, which talks about many-to-many relationships.
The other thing to understand is the nature of "DBRefs". The MongoDB database does not provide any join functionality.
The DBRef is just a standard that several library / driver implementers agreed upon a couple of years ago. The DBRef is just a JSON object in a specific notation that provides a pointer to some other document in some collection. So the implementation of "lazy vs. eager" loading is completely specific to the driver / wrapper library that you are using.
That stated, the concept of "eager loading" is rather pointless with MongoDB. In SQL you can potentially save on total queries by using some form of eager loading and doing a join "in advance". Again, the DB does not support joins, so "eager loading" takes the same number of queries as "lazy loading".
What would be the equivalent of ERD for a NoSQL database such as MongoDB?
It looks like you asked a similar question on Quora.
As mentioned there, the ERD is simply a mapping of the data you intend to store and the relations amongst that data.
You can still make an ERD with MongoDB as you still want to track the data and the relations. The big difference is that MongoDB has no joins, so when you translate the ERD into an actual schema you'll have to make some specific decisions about implement the relationships.
In particular, you'll need to make the "embed vs. reference" decision when deciding how this data will actually be stored. Relations are still allowed, just not enforced. Many of the wrappers for MongoDB actually provide lookups across collections to abstract some of this complexity.
Even though MongoDB does not enforce a schema, it's not recommended to proceed completely at random. Modeling the data you expect to have in the system is still a really good idea and that's what the ERD provides you.
So I guess the equivalent to the ERD is the ERD?
You could just use a UML class diagram instead too.
Moon Modeler supports schema design for MongoDB. It allows users to define diagrams with nested structures.
I know of no standard means of diagramming document-oriented "schema".
I'm sure you could use an ERD to map out your schemata but since document databases do not truly support--or more importantly enforce--relationships between data, it would only be as useful as your code was disciplined to internally enforce such relationships.
I have been thinking about the same issue for quite some time.
And I came to the following conclusion:
If NoSQL databases are generally schemaless, you don't actually have a 'schema' to illustrate in a diagram.
Thus, I think you should take a "by example" approach.
You could draw some mindmaps exemplifying how your data would look like when stored in a NoSQL DB such as MongoDB.
And since these databases are very dynamic you could also create some derived mindmaps to show how the data from today could evolve in time.
Take a look at this topic too.
Confusion about NoSQL Design
MongoDB does support 'joins', just not in the SQL sense of INNER JOIN (the default SQL join). While the concept of 'join' is typically associated with SQL, MongoDB does have the aggregation framework with its data processing pipeline stages. The $lookup pipeline stage is used to create the equivalent of a LEFT JOIN in SQL. That is, all documents on the left of a relationship will be pass through the pipeline, as well as any relating documents on the right side of the relationship. The documents are modified to include the relationship as part of the new documents.
Consequently, I postulate that Entity Relationship Diagrams do have a role in MongoDB. Documents are certainly related to each other in the db, and we should have a visualization of these relationships, including the cardinality relationship, e.g. full participation, partial participation, weak/strong entities, etc.
Of course, MongoDB also introduces the concept of embedded documents and referenced documents, and so I argue it adds additional flavor to the model of the ERD. And I certainly would want to see embedded and referenced relationships mapped out in a visual diagram.
The remaining question is so what is out there? What is out there for Mongoose for NodeJS? Mongoid for Ruby? etc. If you check the respective repositories for their corresponding ORMs (Object Relational Mappers), then you will see there are ERDs for them. But in terms of their completeness, perhaps there is a lot to be desired and the open source community is welcome to make contributions.
https://www.npmjs.com/package/mongoose-erd
https://rubygems.org/gems/railroady
I have an MSSQL database which I am considering porting to CouchDB or MongoDB. I have a many-to-many relationship within the SQL db which has hundreds of thousands rows in the xref table, corresponding to tens of thousands of rows in the tables on each side of the relationship. Will CouchDB and/or MongoDB be able to handle this data, and what would be the best way of formatting the relevant documents for performant querying? Thanks very much.
For CouchDB, I would highly recommend reading this article about Entity Relationships.
One thing I would note in CouchDB is to be careful of attempting to "normalize" a non-relational data model. The document-based storage offers you a great deal of flexibility, and it's seldom the best idea to abstract everything into as many "document types" as you can think of. Many times, it's best to leave much of your data within the same document unless you have clear cases where separate entities exist.
One common use-case of many-to-many relationships is implementing tagging. There are articles about different methods you can use to accomplish this in CouchDB. It may apply to your requirements, it may not, but it's probably worth a read.
Since the 'collection' model of MongoDB is similar to tables you can of course maintain
the m:n relationship inside a dedicated mapping collection (using the _id of the related documents of the referenced documents from other collections).
If you can: consider redesign your application using embedded documents.
http://www.mongodb.org/display/DOCS/Schema+Design
In general: try to turn off your memories to a RDBMS when working with MongoDB.
Blindly copying the database design from RDBMS to MongoDB is neither helpful nor adviceable nor will it work in general.