Can anyone tell me if it is possible to search multiple collections at once in Firebase?
What I need to do is search the data in both the 2009 and 2010 collections in bio_data (more collections will need to be added in the future) and extract the document from one of them.
Or it doesn't matter if there is a way to get a name list of the collections inside a document
Firestore does not have the concept of server-side joins or projections across collections. Each query or document read can only take data from a single collection, or from all collections that have the same name with collection group queries.
If you need to load data from two collections, you'll need at least two reads.
For a better understanding I highly recommend watching the Get to know Cloud Firestore playlist.
Michel's answer is correct.
In addition, I would suggest a change to your data model: Instead of having one sub-collection per year, you could have one unique sub-collection and add a year field to the docs in this unique collection.
This way it would be easy to query by year: For one year, for several years with the in operator (up to 10 equality (==) clauses) or for all the years.
And with a Collection Group query you could even query all the data for all the students.
Related
I am novice user to MongoDB. In our application the data size for each table quite bit large, So I decided to split the same into different collections even though it is same of kind. The only difference is the "id" between each document(documents in one collection is under one category) in the all the collections. So we decided to insert the data into number collections and each collections will be having certain number of documents. currently I have 10 collections of same of kind of document data.
My requirement is
1) to get the data from all the collections in a single query to display in application home page.
2) I do need to get the data by using sorting and filtering before fetching.
I have gone through some of the posts in the stackoverflow saying that use Mongo-3.2 $lookup aggregation for this requirement. but I am suspecting If I use $lookup for 10 collections, there might be performance Issue and too complex query.
since I have divided the my same kind of data into number of collections(Each collection will have the documents which comes under one category, Like that I have the 10 categories, so I need to use 10 collections).
Could any body please suggest me whether my approach is correct?
If you have a lot data, how could you display all of them in a webpage?
My understanding is that you will only display a portion of the dataset by querying the database. Since you didn't mention how many records you have, it's not easy to make a recommendation.
Based on the vague description, sharding is the solution, you should check out the official doc.
However, before you do sharding, and since you mentioned are a novice user, you probably want to check your databases' indexing, data models, and benchmark your performance first.
Hope this helps.
You should store all 10 types of data in 1 collection, not 10. Don't make things more difficult than they need to be.
I currently have this solution to the lack of join in MongoDB, where I am querying two collections to find out the sold information for 3 types of stock.
However I would prefer just to have one collection embedded into the other. Is this possible?
For instance a stock document would have an embedded sold document, which also had the same Stock_index before they were de-normalised (queried separately).
Both collections are fairly large (10,000+ documents each).
Thanks in advance.
I want to move customer surveys for different products and survey types into mongodb.
A product can have multiple survey types.
The existing data consists of about 2 million surveys and growing.
There will be a need of querying the data for stats and reports and the structure of the surveys and their questions can change over time. Which means that the documents wont always be the same.
What will suite the best:
One big collection with product_id and type overhead within one db
Multiple collections per product and type within one db
Or a mix of multiple dbs and collections for product and type
I read about advantages and disadvantages and also that every case has its own solution that suits the usage and purpose.
Unfortunately, I'm not sure what applies the best for my case.
It all depends on how you will access you data, it is by customer, survey or product?.
You can make a product collection and put the surveys as an array of subdocuments or you can make a customer collection and do the same thing.
It is not something we can help you with here without knowing the details of the business requirement.
Just keep in mind, MongoDB is schemaless and how you will design your documents and collections depends on how you will access your data.
We are planning to use MongoDB for a general purpose system and it seems well suited to the particular data and use cases we have.
However we have one use case where we will need to compare every document (of which there could be 10s of millions) with every other document. The 'distance measure' could be pre computed offline by another system but we are concerned about the online performance of MongoDB when we want to query - eg when we want to see the top 10 closest documents in the entire collection to a list of specific documents ...
Is this likely to be slow? Also can this be done across documents (eg query for the top10 closest documents in one collection to a document in another collection)...
Thanks in advance,
FK
I would like to know what is faster in terms of querying for mongodb.
Lets say I would like to search for income information based on areas
And a person can have many residencies in different states. And each polygon area would have an associated income for that individual.
I have outlined two options for querying this information, I would like to know which would be faster to search.
1) To have a single collection which has two types of documents.
Document1: has a geospatial index on it with polygons, and will have
2dsphere index on it. It will be searched with aggregation to return ids that will link to document 2. Essentially taking the place of a relation in mysql.
Document2: has other information (lets say income amount) and different indexes, but has an id
which the first document also has to reference it.
And also has an index on income amount.
The two documents are searched with an aggregation pipeline.
Stage 1 of pipeline: searching document1 geospatially for items and getting the id value .
Stage 2 of pipeline: using id found in document1 to search second document. As well searched by income type.
2) Seperating out the documents where each has its own collection and avoiding aggregation.
querying collection1 for geospatial and using the person id's found to query collection2 for income info.
3) A third option involving polyglot database, a combination of mongodb and postigs: Query postgis for the id and then use that to search mongodb collecton. I am including this option since I believe postgis to be faster for querying geospatially than mogo but I am curious if the speed of postgis will not matter due to latency of now querying two databases.
The end goal is to pull back data based on a geospatial radius. One geospatial polygon representing area where the person lives and does business for that income.
maps to 1 relational id and each relational id maps to many sets of data. Essentially I have a many to 1 to many relationship.
Many geospatials map to 1 person which maps to many data sets.
You should generally keep collections limited to a single type of document.
Solution 1 will not work. You cannot use the aggregation pipeline the way you are describing (if I'm understanding you correctly). Also, it sounds as though you are thinking in a relational way about a solution using a non-relational database.
Solution 2 will work but it will not have optimum performance. This solution sounds even more like a relational database solution where the collections are being treated like tables.
Solution 3 will probably work but as you said it will now require two databases.
All three of these solutions are progressively pulling these two types of documents further and further away from one another. I believe the best solution for a document database like MongoDB is to embed this data. It's impossible without a real example of your documents and without a clear understanding of your application to suggest an exact solution. But in general embedding data is preferred over creating relationships between documents in MongoDB. As long as no document will ever get to be over 16MB it's worth looking into whether embedding is the right solution.