#adku

After all the drama around Groupon's IPO, it seems like the company has remained relatively quiet and there hasn't been too much excitement around the stock. Since its IPO, GRPN has gone as high as $31.14 per share and as low as $14.85, and now the share price has settled at $20.26. And as I've mentioned here previously, I don't really consider Groupon to be a tech company and didn't think their IPO should (would is a different story) affect the IPO market for tech companies after them. Additionally, Groupon's main competitor, LivingSocial, hasn't been too active either. Both companies just seem to be humming along and relatively content to be settled in to the market that they essentially created. That was up until the last week and a half or so. In that time span, Groupon has announced three acquisitions: Adku, Hyperpublic, and Kima Labs. While all three startups will contribute to Groupon in different ways, they all will bolster the daily deal site's technology, an area that has been severely lacking.

On February 6, Groupon announced the acquisition of Adku, an e-commerce data company. Adku's technology optimizes a person's shopping experience by providing product suggestions on sites like Amazon, eBay, and Zappos. Groupon has long been criticized for not providing targeted daily deals (bikini waxes and pole dancing classes in Boston aren't exactly what I'm looking for), and this acquisition should go a long way towards helping Groupon and its merchants send the right deals to the right people. Meanwhile, just yesterday Groupon announced the acquisitions of Hyperpublic and Kima Labs. Hyperpublic is a particularly interesting acquisition as it is really a pure technology / data play. The NYC-based startup creates databases of local info and makes them available to developers for free and will certainly help Groupon figure out how to target customers by location, an essential feature for services like Groupon Now. Lastly, the acquisition of Kima Labs should better enable Groupon's mobile payments capabilities.

The 8 6 reasons[1] Adku prefers Cassandra to HBase:

Reliability

Performance

Consistency

Single point of failure

Hot spot problem

MapReduce

Simpler, Hackable

Community support

Before jumping to any conclusions make sure you read the disclaimer:

While these decisions apply to Adku, they might not apply to your situation. Always do your own investigation and experimentation before choosing any large part of your system.

Update: JD Cryans2 commented on the points listed above (thanks JD):

This comparison reminds me of the pain we went through in the late 2009 when lots of similar comparisons came out from all sides — the “NoSQL war”. Unfortunately as we all found out, no one wins.

But let’s look at the points mentioned in this post.

Reliability: As far as I can tell that’s not a reliability test. The first thing that raises questions is the large number of crashes of the region servers. Considering the data set used (1 million rows of the full “Alice in Wonderland” text) is small compared to the ones other HBase users (StumbleUpon, Mozilla) are handling, that would point out to a configuration problem that wasn’t taken care of.

One could say it’s because HBase is hard to configure or that the default configurations aren’t good, and to some extent I agree, but you don’t quantify reliability based on these.

Hot Spot Problem: This point is an interesting one, and more likely falls into the disclaimer.

Distribution based on timestamp row keys will be better with Cassandra. But usually when using timestamps you also want range scans which is impossible with hashing. For example OpenTSDB provides a very efficient way to store time series by using a clever row key design. A design that you’ll probably also use if you need scans in Cassandra.

Not to mention that using MapReduce will require sorted row keys anyways.

Community Support: Comparing communities only based on the number of IRC users is too much of a simplification. Someone looking to use an open source project should spend some time getting to know and interact with the users before stating that “one community is more helpful” than the other — a message that could also be perceived as disrespectful.

There are also a couple of points that are mentioned in the post even if HBase is the “winner” (MapReduce) or the feature is not a hard requirement (consistency).

I left performance last as the post mentions similar write performance results. But there is too little information about the benchmark to be able to comment on it. At first glance those results look weird considering they weren’t using a Hadoop version that supports append, which as shown by the original YCSB paper would make quite a difference.

After the Adku blog came out, Edward Capriolo wrote this response (rant?) to all who try to do the same as them and I think it’s worth the read: http://www.edwardcapriolo.com/roller/edwardcapriolo/entry/myths_rumors_fud_hate_nosql

From the original list I have crossed MapReduce as the author considers HBase as the “winner”. Also commenters to the original post have clarified the confusion about HBase single point of failure.  ↩

Jean-Daniel Cryans: Apache HBase committer and DB Engineer at StumbleUpon, @jdcryans↩