[
https://issues.apache.org/jira/browse/HBASE-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769271#action_12769271
]
Jonathan Gray commented on HBASE-1931:
--------------------------------------
+1 across the board.
I would say that one advantage of documentation vs an automated tool is that it
provides a good opportunity for someone to learn what decisions are being made
according to different hardware/cluster specs (rather than a magic black box).
Many users start out on 1 or 5 nodes with plans to move to 10, 20, or more. As
we build up a good repository of information, we can add more as we/users learn.
Another major factor is what the expected load patterns are, especially related
to where you might host your ZK nodes, max number of map/reduce tasks, etc...
Good stuff.
> Add table of config. for 1, 4, 20 node clusters and table of config. for 1,
> 2, 8 processor CPU
> ----------------------------------------------------------------------------------------------
>
> Key: HBASE-1931
> URL: https://issues.apache.org/jira/browse/HBASE-1931
> Project: Hadoop HBase
> Issue Type: Task
> Reporter: stack
>
> Chatting w/ J-D, we should add to 'Getting Started' a simple table that says
> how to lay out daemons when you have a cluster of 1, 4, and 20 machines.
> Then we'd have another table that said what kind of config. to use when you
> have nodes of 1, 2, 4, 4+ processors. J-D wanted to go further and add a
> little jruby script to bin directory that could do a dumbed-down version of
> what apurtell suggested a while back, a thing to spit out config. It would
> ask the user a couple of questions and read the local config. and environment
> -- which wouldn't be hard if jruby --- then it would spit out recommendation.
> It would be easier to maintain than doc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
