materialized view vs MongoDB

[Jubeh]

Hello,

I have a database which is about 250 GB of data, some queries
calculations takes a lot of time. A simple solution for that is to
create a materialized view. Is there a big difference in performance
if I used mongodb instead of materialized view to store my queries. Is
there a comparison of MongoDB and querying one single table in
relational database ?

Thanks in advance

[Sam Millman]

Not really tbh since the two methods of querying are so different and it normally depends on your scenario exactly how fast one method or the other is.

I mean I suppose you can garruantee that querying on a Mongo collection will always be faster than a table due to the extra data and schema stored about a table.

What exactly do you mean by "storing queries"? Do you mean result sets or storing the data for them or....what part of storing queries do you mean?

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[Scott Hernandez]

There are no expressions or calculations done with a query in mongo.
The closest you get would be projections (limiting fields or subsets
of arrays).

Can you explain a bit more about what you want from a "materialized
view" and how you plan to implement that?

[Turan Öztürk]

is the answer CouchDb may be ??

2011/10/24 Scott Hernandez <scotthe...@gmail.com>

[Karl Seguin]

Is there any chance that you can build the results incrementally on a background job?

any new or updated documents you could add a field like processed:false

Then you could run a job every 5 seconds (or whenever) that pulls down all unprocessed documents, processes them, stores the result in a denormalized collection, and removes the processed flag (or sets it to true). You could potentially achieve this via a MapReduce, or you could just pull the data down to code.

Alternatively, maybe rather than having slow running read queries, you can move some of the workload on insert/update?

http://mongly.com/Speedig-Up-Queries-Re-Imagining-Your-Data/

Karl

[Salah Jubeh]

Hello Guys,


Thanks for the responses,  according to your replies if I understood correctly, mongoDB suppose to be faster than relational database even if we store the data in one table in the RDBMS.  I am wondering why is that true, one response indicates that it is because of checks, triggers, and constraints but the checks and constraints are applied on update and delete but not on Select. What I mean Mongo DB might be faster on updating and deleting data, but what about selection?

Thanks in advance 
 

--

You received this message because you are subscribed to the Google Groups "mongodb-user" group.

To view this discussion on the web visit https://groups.google.com/d/msg/mongodb-user/-/qRoW9mNM5_oJ.

[Sam Millman]

SQL requires very heavy query analyzers, these are the burden of speed freaks.

Also Mongo uses no schema so there is little metadata attached to each table unlike SQL which attaches lots of data.

Also Mongo is memory mapped (much like memcached) with an fysnc queue (per connection).

Also due to its flat table structure it requires much less stuff on querying than SQL making it in general a lot faster (not having to run join integrity every select helps).

Sorry if this seems a bit vague have had to reply quite quickly.

Hopefully should give you enough to lookup and read about though :)