I’ve hit a problem devleoping document structure for Apache Solr (however, I guess this problem is simple and common to other NoSQL engines). I’ve a document that should contain zillion of user references (e.g. zillion of fields in it). In RDBMS I’d use 2 simple tables with one-to-many relations. However how is that achieved in NoSQL (especially Solr)? Won’t the document with zillion of fields (multivalued) become too heavy-weight? Solr does not support document update on field-level. It should be updated as a whole and this is too costly ;(
I’ve hit a problem devleoping document structure for Apache Solr (however, I guess this
Share
I don’t know about Solr, but MongoDB indeed doesn’t have joins. You can embed related data inside its parent entity (it is quite natural for
Userobject to embed user roles).If, however, because of this embedding document might outgrow its limit (currently 16M per document), then you have no choice but to store this related data in separate documents (either as individual documents or grouped into several document-batches).
If you store data separately from its main entity, then, naturally, you have to perform more than one query to fetch all the data. Not sure how Solr will like this.
MongoDB supports in-place partial updating of documents.