mongodb - comment system rdbms vs nosql -
what best way implement commenting system (huge data writing)?
1) use rdbms database such mysql, 2 tables 1 topics , 1 comments pros insertion of new comment fast, efficient , simple, efficient indexing. cons scaling out (horizontal scaling) hard.
2) use nosql database such couchdb or mongodb, pros scaling out (horizontal scaling) easy, supports huge data writes, schemaless cons i think insertion of new data not fast , efficient rdbms
for example update couchdb document need grab whole document, update locally submit again, , document size huge consume bandwidth.
also think couchdb in-place updates, mongodb updates slow , won't efficient in rdbms
also when want comments of each user in various topics think search faster in rdbms in nosql system.
that sample of couchdb database document [document sample each topic]
{"_id":"doc id", "_rev":"45521231465421" "topic_title":"the title of topic" "topic_body":"the body of topic" "comments":[ {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla1"}, {"user":"user1"} {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla2"}, {"user":"user2"} {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla3"}, {"user":"user3"} {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla4"}, {"user":"user4"} {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla5"}, {"user":"user5"} {"date":"mm/dd/yy hh:mm:ss"}, {"commment":"bla6"}, {"user":"user6"} ] }
i think insertion of new data not fast , efficient rdbms
you have hit there. insertion speed of nosql databases relies upon your scenario. cannot make clear enough, many people expect mongodb perform magically faster sql , sorely disappointed when not them, in fact before mongodb-user google group has been filled such people.
for example update couchdb
not couchdb uses versioning , json not efficient storing in sql , consume more space per record.
mongodb updates slow , won't efficient in rdbms
schema, queries, schema, queries...
that comes down to. ask 1 question.
will expecting lot of comments per post?
if in-memory (yes, in-memory) $push
, $pull
, other subdocument operators may slow on large subdocument (let's honest, will).
not consistently growing documents can problem , can cause heavy fragmentation , space usage, creating "swiss cheese" effect slowing system down massively (bringing grinding halt). presentation should understand more how storage works: http://www.10gen.com/presentations/storage-engine-internals
so know that, if used wrong, subdocuments can bad idea. being said partially remedy power of 2 sizes allocation: http://docs.mongodb.org/manual/reference/command/collmod/#usepowerof2sizes if getting way many comment insertions won't much.
i not embed relationship.
so go same set-up rdbms , start see problem. insertions same speed if wasn't mongodbs fsync queue, unlike sql writes straight disk. can set-up mongodb journalled writes same performance metrics sql @ end of day.
as querying, mongodb can still come out on top, providing your working set fits ram. cannot bold last bit enough!!
unlike sql, mongodb maps (your entire data) virtual memory, not ram , not confused ram. make faster larger lookups, smaller lookups speed same because both serving in-memory cache.
also when want comments of each user in various topics think search faster in rdbms in nosql system.
if topic id in comment document faster in mongodb, providing working set ready in ram.
what meant working set? here answer: what mean fit "working set" ram mongodb?
hope helps,
Comments
Post a Comment