All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Mongodb, is it really worth it?
I am going to be doing some work on an app that I already run, and I will be storing some of the queries it creates and over time I expect it to get VERY large. However, I still think there will be plenty of room in a normal MySQL server.
So the real question I have is, should I try and make it do mongodb?
Some info on the data:
Not important and can be lost in small amounts
Lots and lots of entries with multiple fields being the same.
Small size of entries, in total each line may contain 500 characters max.
Lots and lots of adds and reads, though very little updates.
Would like the data to be scalable (multiple machines asking and adding data, not so much redundant)
Thanks for everyones input that will or wont come
Mun
Comments
It depends on how you will model your app and data. If your mindset is tied to relational thinking, then mongo will not help. You have to design it differently to benefit a lot from mongo
Have you used it jcaleb?
Yes, I did experiment projects. Not in real projects though.
It is very fun because you don't change context of your mind very much. When you do UI in javascript and JSON, then in backend you also think in JSON. That is also efficient both for your mind and for computing power because you don't need to translate from objects to JSON back and forth.
When I use facebook, I appreciate the whole concept of their pages. You can really feel it is not very relational and document oriented. this is what i mean different mindset. it is really obvious FB is very different.
Used it. It's great. Wrote a Java OO binding for it too. Just be aware that it can't do everything MySQL can do (yet).
@concerto49 what type of functionality. Mine will be very basic, lots of records in a table with multiple records using the same fields repeated.
e.g. full text search. Not fully / properly implemented in MongoDB yet.
Hmm that might be bad. so if I wanted to search the db for munroenet.com it would have issues?
Depends if it's a full text search. If you're talking about a distinct field that contains that, it'd work.
Full text search is like using Google - you type in a search, get results / ranking etc.
okay thanks
It might be easier to go over to PostgreSQL. Which is much more mature nowadays compared to MySQL. And you get a lot of extra functionality, while still being relational.
still boils down what you want to do
That's the problem. It's relational. It's "fun" when you use relational in an OO language.
If you want to have fun with your databases try out Filemaker Pro.
SEOMoz/Moz uses Mongo. They wrote an article about it on the dev forum a few weeks back I think it was. It seems quite good and can be tweaked quiet a bit from what I've read.
Sounds more like a use case for Redis to me. Realistically, how much data are we talking about? Unless your data can fit in RAM you're going to take a performance hit with either MongoDB or Redis, probably less so with Redis…
It would be quite small for a bit, but as time progresses it will expand to quite some size. Really it is an archive of processed data that I will accumulate over time. There is two reasons I was thinking of using mongodb. One I can easily shard it so I can expand the project when processing gets too heavy, and two it will allow a ton of expansion.
Mun
If scalability is what you're looking for, mongodb should be better than MySQL.
Its more over so that I can have a local instance of the data, and thus hopefully lowering transaction times.
A production setup of mongodb would require the use of replica sets, which would be good for your usage scenarios. But MySQL has master/master and master/slave setups as well.
Indeed, but they are very picky to setup on VPS infrastructure.
Mongodb doesn't like openvz either: I tried to install it from 10gen repo, and it warns mongodb's known not to work well in ovz containers. Xen/KVM should work fine, I guess.
dont forget to use 64bit OS
FYI facebook uses MySQL.
I think they use a nosql database for just one portion of their site. Something to do with searching inboxes.
nosql type db's like mongo are best for when you want to have clusters spread out in different data centers. Like when you want to provide some type of cloud service.
I haven't done anything with mongo but I have worked with BigCouch which I found to be very easy to install, learn and work with. Surprisingly easy to cluster. Unlike MySQL which I know pretty well but don't like very much.
@sman: I'm exploring bigcouch as well, as I heard it has lower memory requirements than mongodb. How many nodes do you use for bigcouch? Could you share your experiences? Thanks
Bigcouch is very simple. There isn't much to explain really. Learning curve is less than a few days. You use something like HAproxy on the front end to connect your app to the clusters and have it load balance.
On the back end there is another port where you make all the individual DB servers aware of each other with a simple one line command. In the config file you can set up zones and allocate individual servers to zones. Once that is done the DB takes care of the replication automatically.
@sman: Thanks, that's the route I'm gonna to take if I'm to use bigcouch. Did you set up HA for HAproxy?
Yes I had multiple HAProxies as it was just a middleman to something else on the front end which is kind of hard to explain and off topic anyways.
The bottom line was that using BigCouch made a clustered multi-datacenter distributed DB the simplest part of the project. Normally with MySQL it's the most complicated part.
here is a good comparison
http://stackoverflow.com/questions/3375494/nosql-mongodb-vs-couchdb