Hacker News Reader

Comment by qeternity | Hacker News Reader

I want to believe that GPUs can accelerate databases but I rarely see head to head comparisons. Is 100ms for this query really that good? With only 4mm rows how would vanilla Postgres hold up, not to mention something like Citus or Memsql (both of which are at the core my startup’s big data pipeline).

View on HN

100ms for this query is good compared to PostgreSQL (~4s when running the query as-is, ~275ms when using a window function) considering that MapD doesn't seem to utilize an index for it.

That being said a 146MB CSV with 5 million rows is not a challenge for vanilla PostgreSQL either. If you're willing to add an index and use window functions (which MapD doesn't seem to support), you can run this query in ~34ms: https://gist.github.com/felixge/fffef4bc41a5e87e26f62c2a5c8e...

I have no experience with MapD, but people often significantly underestimate the performance of relational databases and reach for the big/expensive toys too soon.

You are right, as a demonstration there is a trade-off between using a real dataset and making the data large enough to demonstrate the performance gains. You are proving the other part of my argument though, in that you don't need to add an index (though, the comparison between using a window function in Postgres is fair, since that would be the canonical way to write that query)

As far as the "big/expensive toys", I'm using the Community Edition, which is FOSS.

I guess you're just trying to show how to use MapD rather than showing when it makes sense to use it, which is cool. For the latter, I found the results over here fairly interesting: http://tech.marksblogg.com/benchmarks.html

As far as "big/expensive toys" go, I was referring to total cost of ownership of putting something like MapD in production vs PostgreSQL. The latter can run on any machine (no GPU needed), there are plenty of hosted services, and there is a large pool of people familiar with it. If this is just about running some analysis on a local machine, that argument doesn't apply so much :).

Note that MapD can run on CPU as well and is generally quite fast. I haven’t benchmarked but on a dataset of this size the numbers might be similar.

I’d also say that while this is a great example of getting up and running with MapD the system really shines when doing interactive queries over datasets from the 100M to 100B record range without requiring indexes.

For what it's worth, I've used MapD to query ~100gb of GPS data.

I was running queries where I was looking for ever point within a given distance of a source point (queries often had 10s to a hundred-something source point s), within a given time period.

MapD would scream through the hose queries ludicrously fast, I don't think I ever had a query run for longer than half a second, 0.7 seconds tops.

While I wasn't running the most complex queries, I also didn't have to do any complex setup (I literally just loaded the data in via command line, single table, nothing special), it was awesome.

Reply on news.ycombinator.com