Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # user - HBase Stack

Copy link to this message
Re: HBase Stack
Joey Echeverria 2011-11-15, 19:55
You can certainly run HBase on a single server, but I don't think
you'd want to. Very few projects ever reach a scale where a single
MySQL server can't handle it. In my opinion, you should start with the
easy solution (MySQL) and only bring HBase into the mix when your
scale really demands it. If you're worried about being locked into a
specific technology, then spend your design efforts building
interfaces that are easy to swap out when the time comes.


On Tue, Nov 15, 2011 at 2:17 PM, Em <[EMAIL PROTECTED]> wrote:
> Thank you both for your answers.
> There is no real project.
> But the scenario we talked about was something like having a community,
> browsergame or something like that while having a low-budget (low in
> terms of he is a student and thinks about how to realize some of his
> ideas from a technical perspective).
> When it starts the amount of data is relativley small and a large
> percentage will fit into RAM. However if the project is becoming more
> successfull, one wants to focus on making the project more awesome
> (adding/improving features) instead of refactoring the whole
> data-management and -architecture.
> The question he asked was what I think about using HBase right from the
> beginning and where I expect problems. Since I have no experiences with
> HBase I had no answer.
> I even don't know whether a good advice would be to take a refactoring
> of the data-management into consideration, if HBase is no choice for a
> single-server-project (not even in the beginning).
> Regards,
> Em
> Am 15.11.2011 19:08, schrieb Travis Camechis:
>> agreed, What is your current size of your data?
>> On Tue, Nov 15, 2011 at 12:54 PM, Ayon Sinha <[EMAIL PROTECTED]> wrote:
>>> I believe one of the biggest problem you will face with HBase in a small
>>> setup is that MySQL is happy with single machine setup (less maintenance
>>> headache for small scale projects) compared to HBase running in
>>> pseudo-ditrib mode. In the pseudo-distib mode single HBase machine will
>>> have too much overhead. It will really shine when you grow really big and
>>> need to scale out. THats when HBase will pull-out from MySQL really fast.
>>> This particular scenario is very well described in the HBase: The Def
>>> Guide book. When you have to grow, LAMP stack need things like memcached +
>>> sharding (lots of headache).. compared to HBase (headache growing smaller
>>> with more community support and stability).
>>> -Ayon
>>> See My Photos on Flickr
>>> Also check out my Blog for answers to commonly asked questions.
>>> ________________________________
>>> From: Em <[EMAIL PROTECTED]>
>>> Sent: Tuesday, November 15, 2011 9:38 AM
>>> Subject: Re: HBase Stack
>>> Hi Travis,
>>> I think I wasn't very clear about my question:
>>> If the project grows, you will be able to have machines optimized for
>>> special things (hbase-servers and tomcat-servers, maybe devided into
>>> sub-groups with special hardware-requirements for more efficiency).
>>> And this is what you should do, if your project grows and you gain the
>>> revenue neccessary to pay for it.
>>> My question was more targeted at the starting point of a (small) project:
>>> How does a machine with Linux, Java (Tomcat) and MySQL competes with the
>>> same setup with HBase beeing the database server?
>>> Given this example one can assume that you access your data in MySQL by PK.
>>> Regards,
>>> Em
>>> Am 15.11.2011 17:41, schrieb Travis Camechis:
>>>> I don't think you would want to run all of this on the same machine,
>>>> especially if your application/ data requirements are fairly large.
>>>> On Tue, Nov 15, 2011 at 11:27 AM, Em <[EMAIL PROTECTED]>
>>> wrote:
>>>>> Hello folks,
>>>>> seems like you deal here with HBase-questions.
>>>>> Below you will find my question.
>>>>> Thanks!
>>>>> Em
>>>>> -------- original message --------

Joseph Echeverria
Cloudera, Inc.