6 ms·

Moving from MongoDB to MySQL. I never understood why people felt they need MongoDB/NoSQL for their projects. Does anyone have an example where it was really nec

by intoit 14y ago

Moving from MongoDB to MySQL. I never understood why people felt they need MongoDB/NoSQL for their projects. Does anyone have an example where it was really necessary/advantageous?

dkhenry 14y ago
According to the README they say preformance improvements with Mongo. The downside was having to port all the new features over to it. Personally I have used it to speed up development. It allows very fast iterations early on and integrates much more nicely with most languages then a SQL based solution. Also its a lot faster the MySQL.
- intoit 14y ago
  Yeah, I think this was a case of the developers just wanting to try the latest thing without really understanding the impact or tradeoffs.
- jmikola 14y ago
  10gen sponsors development of a Drupal module, EntityFieldQuery[1], which aims to improve support for non-SQL databases. Although I'm unfamiliar with Drupal project layouts, I didn't find a reference to the module in the GitHub project, so I don't believe they were using it. That said, there are still challenges to making MongoDB play nicely with Drupal 7, but 10gen is aiming for better integration in version 8 (through the same sponsorship). 1. http://drupal.org/project/efq_views http://drupal.org/project/efq_views
rburhum 14y ago
I'll give you an example for CouchDB that, for the first time in my life, I saw an advantage: I created a webapp where a user can author a form (with several different kinds of fields), then it syncs with a mobile app that downloads the forms and allows for data collecting.CouchDB supports synchronizing with a server very easily and already has mobile support to. If/when the user changes the number of fields in the webapp, starting to collect that data makes it very trivial... no need to schema 'alter' statements in the server and synced back to the sqlite db in the phone. It all runs couch and it "just works". Mind you, I am very skeptical about NoSQL in general, but for this particular example, for the first time in my life, I saw a clear advantage.
- intoit 14y ago
  Nice example! This clears it up for me a lot.
blindhippo 14y ago
I'd like a clear example too. I can see the benefits of using something like NoSQL for temporary datastores (in memory only), but MySQL can function just fine as a key->value store as well to the best of my understanding.
jat850 14y ago
Sure, a couple I can think of: - when JSON is the native language of your application, certain NoSQL implementations are beneficial. The value/need for this is changing with more RDBMS introductions of JSON datatypes. - speed/ease of development/familiarity - sqlite is easy to set up and maintain for small installations/projects, so is mongo or couch or redis - fairly straightforward tradeoff - leveraging other platforms. Quick example might be wanting to take advantage of Amazon Dynamo or SimpleDB. Sure, RDS is right there too and scales in a similar elastic fashion, but Dynamo especially feels much, MUCH more hands off in terms of redundancy and application design. We use Dynamo since day 1 of its release (we transitioned from mongoDB to Dynamo with 1 day of work) and have not looked back. In our particular project I cannot conceive of how or why we would want to use an RDBMS, it does not fit the task. I'm not advocating for NoSQL over RDBMS in any given, or especially all, situations. But there are plenty of reasons to select nosql-based implementations.
- intoit 14y ago
  Dynamo looks very interesting. Thanks for pointing it out.
diminoten 14y ago
When I don't know what my schema would look like I like using mongodb. Also, when I don't feel like dealing with the OR impedance mismatch. http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis...
- intoit 14y ago
  Hadn't heard about OR impedance mismatch... good to know about.
pnathan 14y ago
I like it because it provides a flexible material for development without committing to a schema.
- intoit 14y ago
  I think I finally "get" it. Thanks for putting it succinctly.
pessimizer 14y ago
When speaking about Drupal specifically, it means improving the rate of requests served 5x in some cases. http://cyrve.com/mongodb http://cyrve.com/mongodb edit: Data stored in Drupal is way normalized, and read from a hell of a lot more than it's written to. I think in this case, when they weren't using it for general field storage, but just petitions and signatures which consist of endless names and links to user pages, the data was naturally denormalized enough. Nothing in that usecase would take more than three, maybe four joins. All it's doing in that case is just making upgrades difficult.
fiorix 14y ago
this is bad reputation for mongodb anyway
ceol 14y ago
Session data. NoSQL isn't meant to be a catch-all solution, and it's certainly not meant to be the only database you use in a complex project. It's meant for data that you really wouldn't mind losing that you have to access a lot. Normally, that's temporary data in an app that might require it on every page view— recently viewed items, sessions, shopping carts that aren't saved for later, etc.

by intoit 14y ago

Moving from MongoDB to MySQL. I never understood why people felt they need MongoDB/NoSQL for their projects. Does anyone have an example where it was really necessary/advantageous?

dkhenry 14y ago

According to the README they say preformance improvements with Mongo. The downside was having to port all the new features over to it. Personally I have used it to speed up development. It allows very fast iterations early on and integrates much more nicely with most languages then a SQL based solution. Also its a lot faster the MySQL.

intoit 14y ago
Yeah, I think this was a case of the developers just wanting to try the latest thing without really understanding the impact or tradeoffs.
jmikola 14y ago
10gen sponsors development of a Drupal module, EntityFieldQuery[1], which aims to improve support for non-SQL databases. Although I'm unfamiliar with Drupal project layouts, I didn't find a reference to the module in the GitHub project, so I don't believe they were using it. That said, there are still challenges to making MongoDB play nicely with Drupal 7, but 10gen is aiming for better integration in version 8 (through the same sponsorship). 1. http://drupal.org/project/efq_views http://drupal.org/project/efq_views

rburhum 14y ago

I'll give you an example for CouchDB that, for the first time in my life, I saw an advantage: I created a webapp where a user can author a form (with several different kinds of fields), then it syncs with a mobile app that downloads the forms and allows for data collecting.CouchDB supports synchronizing with a server very easily and already has mobile support to. If/when the user changes the number of fields in the webapp, starting to collect that data makes it very trivial... no need to schema 'alter' statements in the server and synced back to the sqlite db in the phone. It all runs couch and it "just works". Mind you, I am very skeptical about NoSQL in general, but for this particular example, for the first time in my life, I saw a clear advantage.

intoit 14y ago
Nice example! This clears it up for me a lot.

blindhippo 14y ago

I'd like a clear example too. I can see the benefits of using something like NoSQL for temporary datastores (in memory only), but MySQL can function just fine as a key->value store as well to the best of my understanding.

jat850 14y ago

Sure, a couple I can think of: - when JSON is the native language of your application, certain NoSQL implementations are beneficial. The value/need for this is changing with more RDBMS introductions of JSON datatypes. - speed/ease of development/familiarity - sqlite is easy to set up and maintain for small installations/projects, so is mongo or couch or redis - fairly straightforward tradeoff - leveraging other platforms. Quick example might be wanting to take advantage of Amazon Dynamo or SimpleDB. Sure, RDS is right there too and scales in a similar elastic fashion, but Dynamo especially feels much, MUCH more hands off in terms of redundancy and application design. We use Dynamo since day 1 of its release (we transitioned from mongoDB to Dynamo with 1 day of work) and have not looked back. In our particular project I cannot conceive of how or why we would want to use an RDBMS, it does not fit the task. I'm not advocating for NoSQL over RDBMS in any given, or especially all, situations. But there are plenty of reasons to select nosql-based implementations.

intoit 14y ago
Dynamo looks very interesting. Thanks for pointing it out.

diminoten 14y ago

When I don't know what my schema would look like I like using mongodb. Also, when I don't feel like dealing with the OR impedance mismatch. http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis...

intoit 14y ago
Hadn't heard about OR impedance mismatch... good to know about.

pnathan 14y ago

I like it because it provides a flexible material for development without committing to a schema.

intoit 14y ago
I think I finally "get" it. Thanks for putting it succinctly.

pessimizer 14y ago

When speaking about Drupal specifically, it means improving the rate of requests served 5x in some cases. http://cyrve.com/mongodb http://cyrve.com/mongodb edit: Data stored in Drupal is way normalized, and read from a hell of a lot more than it's written to. I think in this case, when they weren't using it for general field storage, but just petitions and signatures which consist of endless names and links to user pages, the data was naturally denormalized enough. Nothing in that usecase would take more than three, maybe four joins. All it's doing in that case is just making upgrades difficult.

fiorix 14y ago

this is bad reputation for mongodb anyway

ceol 14y ago

Session data. NoSQL isn't meant to be a catch-all solution, and it's certainly not meant to be the only database you use in a complex project. It's meant for data that you really wouldn't mind losing that you have to access a lot. Normally, that's temporary data in an app that might require it on every page view— recently viewed items, sessions, shopping carts that aren't saved for later, etc.