Well you don't want to do joins in HBase.
There are a couple of ways to do this, however, I think based on what you have said... the larger issue for either solution (HBase or MySQL would be your schema design.)
Basically you said you have Table A w 50 Million rows and Table B of 7 Million rows.
You don't really talk about any indexes or Foreign Key constraints between the two tables.
Or what that data is...
Can you provide more information?
Right now you haven't provided enough information to solve your problem.
On Oct 10, 2012, at 3:16 AM, David Parks <[EMAIL PROTECTED]> wrote:
> In looking at the AWS MapReduce version of HBase, it doesn't even give an
> option to run it on lower end hardware.
> I am considering HBase as an alternative to one large table we have in MySQL
> which is causing problems. It's 50M rows, a pretty straight forward set of
> product items.
> The challenge is that I need to do 10+ range scans a day over about 7M
> items each where we check for updates. This is ideal for HBase, but hell for
> MySQL (a join of a 7M row table with a 50M row table is giving us
> But beyond the daily range scans the actual workload on the boxes should be
> reasonable, just random access reads. So it doesn't seem like I should need
> significant memory/CPU requirements...
> But here's where I don't find a lot of information - as someone reasonably
> new to HBase (I read a book, did the examples), am I missing anything in my