On 16/04/13 03:09, Elias Levy wrote:
On Sun, Apr 14, 2013 at 8:09 PM, <[email protected]
<mailto:[email protected]>> wrote:
From: Chris Corbyn <[email protected] <mailto:[email protected]>>
The thing is, the *only* querying criteria for this app is to
aggregate the data for the purpose of reporting. Our finance guys
want to be able to check a few boxes to specify how they want the
data grouped, then generate the report. We actually do this data
warehousing style in MySQL at the moment, where the data is
renormalized about as far as we can, but still allowing for some run
time use of GROUP BY and ordering.
Riak is not an analytics DB, don't use it as such.
If you are analyzing data that is years old, then you are not utilizing
Riak for availability properties. If you are writing sales reports,
then you are more likely worried about consistency than availability.
You have to do some herculean work to turn Riak into a OLAP cube (see
Boundary.com's Kobayashi).
You are better off using Hadoop or AWS's Elastic MapReduce if you want
do use MR. Or if you just need to roll up reports using SQL but
allowing ad hoc queries, consider datases like Vertica
<http://www.vertica.com/> or Infobright <http://www.infobright.com/>,
which are either distributed or excel at handling data aggregation.
Thanks, it has been interesting to read all the feedback about this.
I'm in a similar boat, wondering about using Riak for large analysis
tasks. It's sounding like it just isn't the right tool for the job.
Riak looks like it can replace several different systems I use, which
will simplify administration greatly, while providing better
reliability. I was hoping that on top of that it could also do big
MapReduce jobs and warehousing, but maybe that was too much to ask. I'm
going to keep an eye out for improvements or people with successful
experiences anyway.
-Toby
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
