tag:blogger.com,1999:blog-7229726356350157529.post4353717573001171495..comments2019-08-28T15:13:27.130-04:00Comments on Que es Bhaskar: Comments in response to Don Anderson's 3n+1 benchmarkBhaskarhttp://www.blogger.com/profile/14323369551611484731noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-7229726356350157529.post-35656121476480600302011-02-02T13:54:24.609-05:002011-02-02T13:54:24.609-05:00I responded to Dan Weinreb's comments with ano...I responded to Dan Weinreb's comments with another post (http://ksbhaskar.blogspot.com/2011/02/responses-to-dan-weinrebs-comments-of.html) because it was too long for a reply.<br /><br />-- BhaskarBhaskarhttps://www.blogger.com/profile/14323369551611484731noreply@blogger.comtag:blogger.com,1999:blog-7229726356350157529.post-37265294254885952782011-02-01T11:49:53.326-05:002011-02-01T11:49:53.326-05:00I have a few comments.
First: I do not know what ...I have a few comments.<br /><br />First: I do not know what you mean by "recoverable". If the transactions are not durable, then you cannot recover them. Recoverable in the database literature means that you can recover the state as it was after all transactions that committeed, in the face of any "stop" including total system crash. The log file must be persisted when a (write) transaction commits. Omitting this can speed things up a lot; real durability isn't cheap if you have to actually write the log to rotating magnetic storage. (Less so if you can use FLASH, or you disk has a battery-backed-up RAM buffer, or you're copying the data to main memory in two servers with independent failure modes, or something like that.)<br /><br />Is this really a database benchmark? You use the word "NoSQL" in the name. But since this is just a computation that ends promptly, getting the job done does not need durability anyway. It just runs to completion. That is, unless you want the application to complete even if a server crashes; but then measuring the execution time would not make sense. I don't even see why there's any need for a log at all.<br /><br />Second: This benchmark appears to be operating on key/value pairs that are very small, containing small character strings (naming integers) rather than, say, images. Don Anderson says that the record sizes are typically 20-40 bytes. Some of the "NoSQL" systems are clearly designed for much larger K/V pairs. I am pretty sure that Riak (with BitCask) is like this, as well as Google's BigTable and the clones thereof (HBase in Hadoop, and Cassandra).<br /><br />Third: Many of the NoSQL systems are specifically designed to use replication, to the point where using them without replication is simply not done, and therefore not optimized for. This might make a difference.<br /><br />Fourth: About tuning, this is a problem that always arises in benchmark comparisons. I have been involved in many such comparisons in my career, especially the "OO7" benchmake for object-oriented database systems. "Apples to apples" gets to be very hard to define fairly. This isn't your fault; it's an inherent problem in comparative benchmarks.<br /><br />It's a good idea to have well-specified benchmarks, and this is a good start!<br /><br />-- Dan WeinrebDan Weinrebhttps://www.blogger.com/profile/07868811586654591249noreply@blogger.comtag:blogger.com,1999:blog-7229726356350157529.post-51169879334578557602011-02-01T07:04:51.331-05:002011-02-01T07:04:51.331-05:00GT.M can also be accessed via Javascript (using No...GT.M can also be accessed via Javascript (using Node.js) - see https://github.com/robtweed/node-mwire<br /><br />RobRob Tweedhttps://www.blogger.com/profile/17455762392019541755noreply@blogger.com