MongoDB, Is it really worth it?

[Mun]

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

 

[kaniini]

I don't think that MongoDB is worth it.  There's a YouTube video which satirically goes through why it's a bad idea:

https://www.youtube.com/watch?v=b2F-DItXtZs

 

[Tux]

I don't think that MongoDB is worth it.  There's a YouTube video which satirically goes through why it's a bad idea:

https://www.youtube.com/watch?v=b2F-DItXtZs

I love myself some MySQL replication

If you know how to properly use it you can easily boost your performance.

 

[peterw]

If your DB is normalized and you have joins, foreign keys, indexs don't use MongoDB or any NoSQL database. If you need ACID do not use NoSQL.

But if you are prototyping, your data schema is changing all the time use MongoDB. The data stored in a collection is defining the schema no need to create tables or update tables.

 

[Adwait_Leap]

I would suggest MongoDB if you require flexiblity in the schema and  scalablity. For a small or medium size database you will not find it that useful rather an overhead.

 

[MannDude]

I feel like Francisco had some opinions on MongoDB though don't recall.

 

[wlanboy]

MongoDB is ideal for starting something.

I do like the freedom to get rid of schema migrations. Most of my rest apis are handling json data so MongoDB is ideal because it just takes any json-like data without any preparations.

Devide and conquer works great on MongoDB. You can write your own functions with javascript.

Honestly: I always start with MongoDB. You do not need any datamapper, no schema, just put in any json and that's it. Just working without any hassle.

 

[Mun]

The database will grow overtime, and will probably get very big. 

I guess the two biggest reasons I would want it is to have an instance on each node, instead of running off a remote SQL, and second to allow for a very large database that will eventually come in like ~10 years.

An example table would be:

Auto Increment | IP | RDNS | Created | Verifed 

There will be duplicated of the IP field and will be the main key for most of the data being processed. 

 

[Francisco]

How many rows are you talking?

There's some forks of MySQL that are designed for huge amounts of rows/TB's of data.

We were considering using it for our stats keeping but it's likely i'm going to use leveldb, as recommended by @acd.

Francisco

 

[jcaleb]

You can always partition your MySQL database (maybe on date created, dunno) so that performance is still okay.

If you are looking for sharding, not sure if MySQL supports that out of the box. But programming frameworks (e.g. Hibernate) supports sharding on application level.

 

[Mun]

I think the database will be rather small, but will grow larger as time continues. It will pretty much be like your stats keeping @francisco, but will have lots and lots of data from many years.

Mun