Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Mongodb, is it really worth it?
New on LowEndTalk? Please Register and read our Community Rules.

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?

MunMun Member

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

«1

Comments

  • jcalebjcaleb Member

    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

  • MunMun Member

    Have you used it jcaleb?

  • jcalebjcaleb Member

    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.

  • jcalebjcaleb Member

    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).

  • MunMun Member

    @concerto49 what type of functionality. Mine will be very basic, lots of records in a table with multiple records using the same fields repeated.

  • @Mun said:
    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.

  • MunMun Member

    @concerto49 said:
    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?

  • @Mun said:
    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.

  • MunMun Member

    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.

  • jcalebjcaleb Member

    still boils down what you want to do

  • @Centaur said:
    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.

    That's the problem. It's relational. It's "fun" when you use relational in an OO language.

  • bcrlsnbcrlsn Member

    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.

  • FFFlipFFFlip Member
    edited July 2013

    @Mun said:
    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)

    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…

  • MunMun Member

    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

  • hyaohyao Member

    If scalability is what you're looking for, mongodb should be better than MySQL.

  • MunMun Member

    @hyao said:
    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.

  • hyaohyao Member

    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.

  • MunMun Member

    @hyao said:
    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.

  • hyaohyao Member

    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.

  • jcalebjcaleb Member

    dont forget to use 64bit OS

  • @jcaleb said:
    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.

    FYI facebook uses MySQL.

    I think they use a nosql database for just one portion of their site. Something to do with searching inboxes.

  • smansman Member
    edited July 2013

    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.

  • hyaohyao Member

    @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

  • smansman Member
    edited July 2013

    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.

  • hyaohyao Member

    @sman: Thanks, that's the route I'm gonna to take if I'm to use bigcouch. Did you set up HA for HAproxy?

  • smansman Member
    edited July 2013

    @hyao said:
    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.

Sign In or Register to comment.