I am recently working on a django project documentation which uses MongoDB.
So I need to know how to make some clear diagrams of the MongoDB collections.
I understand that there's no fixed form to do it due to the MongoDB's flexible nature,
but my records in each collection follows certain order and rule defined by the collection while some of the collection records contain inner documents.
So, is something like this the most proper way, or there's more standard way to show my MongoDB collections to other developers or package users?
I would sugguest the tree mode.
collection
`-- _id
`-- field1
`-- field2
`-- f1
`-- f2
`-- field3
Related
I developing an app with tree(folder-file) structure, on which I should perform full-text searches with MongoDB. I did a research on the best tree structure practices and found this great article, but I still can not decide which DB structure will fit my needs.
I have the following requirements in my mind:
I should be able to perform full-text search on individual folders, as well as everything from specific users
The folders/files should be shareable, so I need to be able to perform full-text search on all items accessible by specific user
I've been thinking about the following structures.
Structure 1
Fields of Users collection
1. _id - objectid
2. name - string
Fields of Folders collection
1. _id - objectid
2. name - string
3. owner - objectid
4. sharedWith - array of objectIds
5. location - objectid of parent folder, null if in root
6. createDate - datetime
Fields of File collection
1. _id - objectid
2. name - string
3. owner - objectid
4. sharedWith - array of objectIds
5. data - string
6. location - objectId of folder
7. createDate - datetime
So here comes my questions:
Should I use model tree structures with Parent References or Child References?
Should I use 1 collection for both files and folders(with type field) or I should separate them.
Does it worth to have only folder collection and nest documents in it.
This were my most important questions, thought I will greatly appreciate any advice on how I can improve the structure. I'm sorry if this isn't the right place to ask such questions.
It depends a bit on how far you want/need the setup to scale. For small numbers of files, folders, and files per folder it doesn't matter too much. That said,
I'd use references from children to parents. Parents (folders) may have hundreds or thousands of children (files and folders). This might be ok to store as references in one folder document, but most likely in that case you would want to index the array to support fast queries like "is file x in folder y?", and the array would be frequently changing. A large, frequently changing, indexed array is a recipe for bad performance in MongoDB. If you have only a couple hundred or so children per folder, you might be able to get away with storing references to all children in the parent, as long as you don't rely on that array being indexed for your queries. This essentially means you'd put a reference from the children to the parents to support the same queries.
I'd use one collection since you want to return both in response to many queries. Add a field to identify folders, like `folder : true or something.
No, it won't work to have folder documents with many nested layers. MongoDB in general doesn't support recursive or arbitrary-depth operations, making it difficult to work with such structures.
I have multilingual data in MongoDB with format like
"name":{
"en" : "dog",
"fr" : "chien"
},"description" :{
}
I am concerned about text search, i.e user should be able to locate the same object with text search like "dog" or "chien" (or their substrings).
I am looking at several full text search engine like elasticsearch ,solr and sphinxsearch, and at first glance elasticsearch looks promising. Is the above a bad structure and is there obvious advantage of the other engines that would matters? And how would one implement such a search in elasticsearch?
Solr and ElasticSearch both are built on top of Apache Lucene, and both will provide the functionality you want.
I have not used Elastic Search, hence giving an overview based on my experience with Solr, but I am sure the same can be seamlessly transitioned to Elastic Search as well.
You will need to import and index your mongodb data into Solr . This is easily doable by running Solr, and using its rest api .
You can also use 10gen mongo-connector : https://github.com/10gen-labs/mongo-connector which imports your mongodb records into Solr.
There are many other ways to import your mongodb data into Solr, including writing your own scripts in language of your choice.
You need to define schema defition for the data that you import. For your search case, you will be mostly using "text" with Solr factories(filters/tokenizers etc) applied to the text data.
3.How you define the schema depends on the user flow , you will chose. Is your site going to be language neutral and a search for "fem" will show all results from all languages which start with "fem".
Or you are going to let user select the language first. e.g. "French", and then search the term only in the 'fr' field, which would be a cleaner solution in my opinion.
I want to create only the collections structure.
i.e.
Say Products collection contains a list of Categories.
I want to specify this container structure by creating this dependencies, but I do not want to create any collection entry (say there is a loader program somewhere that bulk uploads the data).
The closet analogy in RDBMS is; DBA creates the schema design with constraints and dependencies; application or ETL tool loads the actual data.
Most of the examples that I see simply create a sample collection and then invoke the
db.insert(document)
OR
db.save(document)
Is it even possible in MongoDB?
if the question is not clear, please let me know.
Thanks
The short answer is NO.
You cannot create a schema in MongoDB. A collection is just a set of documents. Furthermore, dependencies are likely to be represented with embedded documents (as opposed to referenced documents).
We can be more specific if you post the data you want to represent.
I have nodes which are attached to mongo documents.
I want to be able to do the following:
Search the node's title + description + mongo keywords (mongo has a nid field). Any node that matches any of that information is returned in the view. Is this possible with some special view hook? (I can already search the view by description)
You need to store the node title and body in the mongodb document you want to query as mongodb can't query. If you are not bound to a current structure store the keywods as a multivalue text field and use efq_views. If you can't do that, I once wrote a MongoDB Views backend, you can look at it in http://drupal.org/sandbox/chx/1261486 but it's years old. Really the only challenge is telling MongoDB about the structure of your document but if you are bound to a structure then you don't need to solve that in a generic way.
Edit: As for credible, I am (ok, was) the MongoDB Drupal module maintainer, took part of the design and the initial implementation sprint of field API, was the Drupal architect of a Top 100 website running on Drupal 7 + MongoDB.
I am working on my first mongodb project and am trying to wrap my head around schema design in Mongodb vs relational dbs.
I want to create a databases of vegetables from several rss feeds. Each of these feeds has a tag for vegetable name for me to use.
1) I get 2 feeds for vegetable nutritional information
2) 3 feeds for vegetable growing/farming information
3) 4 feeds for blog articles
There are only 500 different vegetables i get information for.
Would the best schema in this scenario be:
A) to have one collection for each vegetable and have sub collection for nutrition, growing and blog articles?
B) Or to have one collection for nutritional information, one for farming information and one for blog articles?
I envision the users primarily querying on vegetable name, but it will be possible to query on other fields as well.
MongoDB is schemaless - so you don't have to think about this in the same way as you would a relational database. I know it's confusing at first. Also, MongoDB does not support "Sub-collections" - you have documents (individual entities) within a collection.
I would actually opt for this:
C) Two collections. The veggies collection is essentially a complex array structure containing not only the information about the veggies, but also the growing / nutrition info. Just make sure you create an index for each piece you will need to search on. A separate collection for blog posts if you can't use a blogging engine that already exists.
That's the beauty of NoSQL - as long as you index - you can make each entity (called a document in Mongo's case) pretty complex. Hope this helps.