-
Join the MyBroadband community
South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
-
Question of the Day: What's the most interesting small town you've visited in South Africa?
mongoDB
- Thread starter debonair
- Start date
I went to a conference with Kore Nordmann on PHPillow. It is a PHP wrapper for couchDB. It was massively interesting. Here is the project page if you are interested. In what way are you looking to use it, we have been toying with the idea of using it for ad-serving, the potentials for it are massive.
Other Pineapple Smurf
Honorary Master
Interesting as I'm playing around with erlang for some backend stuff on my PHP code. PHPillow might actually help me as I'm limited with my time to migrate to erlang this year.
MongoDB is already significantly faster than CouchDB, and seems to enjoy a lot more support from the development community. PHP already has a mature extension for it (http://php.net/mongo) and support in other languages is experiencing some pretty rapid growth.
Keep in mind though that MongoDB (and document based DB's in general) was created for speed and scaling, at the expense of resources. Mongo's DB's for example grow at an alarmingly exponential rate compared to a relational DB, even for small amounts of data, and should ideally have access to a large amount of RAM. If your project is small, even though document based databases offer some handy features (embedding, storing a wide array of object types, spiffy query API) I'm not sure it would be worth extra resource requirements as your database grows.
I'm open to correction on any of the points, as I'm still reasonably new to MongoDB compared to my work with relational db's, but that's my experience with it thus far.
Keep in mind though that MongoDB (and document based DB's in general) was created for speed and scaling, at the expense of resources. Mongo's DB's for example grow at an alarmingly exponential rate compared to a relational DB, even for small amounts of data, and should ideally have access to a large amount of RAM. If your project is small, even though document based databases offer some handy features (embedding, storing a wide array of object types, spiffy query API) I'm not sure it would be worth extra resource requirements as your database grows.
I'm open to correction on any of the points, as I'm still reasonably new to MongoDB compared to my work with relational db's, but that's my experience with it thus far.
I should probably add that the growth of Mongo database disk consumption isn't due to bad practices or a shortcoming of the DB, but by design. From their website:
Each datafile is preallocated to a given size. (This is done to prevent file system fragmentation, among other reasons.) The first file for a database is .0, then .1, etc. .0 will be 64MB, .1 128MB, etc., up to 2GB. Once the files reach 2GB in size, each successive file is also 2GB.
Thus if the last datafile present is say, 1GB, that file might be 90% empty if it was recently reached.
Each datafile is preallocated to a given size. (This is done to prevent file system fragmentation, among other reasons.) The first file for a database is .0, then .1, etc. .0 will be 64MB, .1 128MB, etc., up to 2GB. Once the files reach 2GB in size, each successive file is also 2GB.
Thus if the last datafile present is say, 1GB, that file might be 90% empty if it was recently reached.
@Seeyou I was doing some stress tests on the my little project and generated a million sites each with 5 pages and not really much content, and observed was wondering the disk consumption was so behaving that way. Thanks for the clarification.
The speed is amazing and the whole idea of generating fields on the fly makes it really flexible. I think i am becoming a fanboi lol go ahead and give it a try, you won't regret it.
The speed is amazing and the whole idea of generating fields on the fly makes it really flexible. I think i am becoming a fanboi lol go ahead and give it a try, you won't regret it.
chopsuey
Well-Known Member
Have played around with CoutchDB some time back. (stumbled upon it while searching for real world non telecoms Erlang based software)
What I found pretty cool was that you could interface/query the DB without having a specialized driver. All that was needed was JSON HTTP PUT/GET requests that could even be done with curl command/app. All responses are JSON to.
From the whole "NoSQL" point of view it would probably take me so time to fully grasp the Map/Reduce function query concept.
The idea of a schema less DB really makes sense in some types of problems (I would have liked to use it as the persistence layer in in a PDF template system I developed, but was pretty sure management would not have approve of using this "new NoSQL stuff")
What I found pretty cool was that you could interface/query the DB without having a specialized driver. All that was needed was JSON HTTP PUT/GET requests that could even be done with curl command/app. All responses are JSON to.
From the whole "NoSQL" point of view it would probably take me so time to fully grasp the Map/Reduce function query concept.
The idea of a schema less DB really makes sense in some types of problems (I would have liked to use it as the persistence layer in in a PDF template system I developed, but was pretty sure management would not have approve of using this "new NoSQL stuff")
No doubt, the speed is awesome, especially when you bring in bulk inserts, and give the DB a ton of RAM and/or a really fast hdd for querying and cacheing. Schema-less development is also quite a novel experience - not having to generate migrations or fiddle with DB fields takes some getting used to.
Definitely a lot of potential here. I'm still wrapping my head around when to embed documents and when to use more traditional relationships, and I haven't even scratched the surface of its other features. So much to learn, so little time
