<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>question Re: Hbase tall-narrow or flat wide design in Support Questions</title>
    <link>https://community.cloudera.com/t5/Support-Questions/Hbase-tall-narrow-or-flat-wide-design/m-p/158097#M120496</link>
    <description>&lt;P&gt;Hello arunkumar&lt;/P&gt;&lt;P&gt;As a general rule it will come back to what you are trying to achieve and how you want to service data. Remember that Hbase's performance is directly derived from the rowkey and hence how you access data. Hbase will split up data in regions served by region servers and on a lower level data will be split by Column Family. A single entry however will be served by the same region. At high level the difference between tall-narrow and flat-wide comes back to scans vs gets. Since Hbase has an ordered on the rowkey storage policy and full scans are costly. A Tall-narrow approach would be to have a more complex rowkey giving adjacency of similar elements and allowing to do focused scans for  logical group of entries. A Flat-wide approach would ahve much more information in the entry itself, you "get" the entry through the rowkey and the entry would have sufficient information to do your compute or answer your query.&lt;/P&gt;&lt;P&gt;hope this helps&lt;/P&gt;</description>
    <pubDate>Wed, 06 Apr 2016 14:05:27 GMT</pubDate>
    <dc:creator>nmaillard1</dc:creator>
    <dc:date>2016-04-06T14:05:27Z</dc:date>
    <item>
      <title>Hbase tall-narrow or flat wide design</title>
      <link>https://community.cloudera.com/t5/Support-Questions/Hbase-tall-narrow-or-flat-wide-design/m-p/158096#M120495</link>
      <description>&lt;P&gt;Can anyone throw some light on the hbase table design. which one should one use "tall-narrow or flat wide design" and for which use case.&lt;/P&gt;</description>
      <pubDate>Wed, 06 Apr 2016 13:07:18 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/Hbase-tall-narrow-or-flat-wide-design/m-p/158096#M120495</guid>
      <dc:creator>arunpoy</dc:creator>
      <dc:date>2016-04-06T13:07:18Z</dc:date>
    </item>
    <item>
      <title>Re: Hbase tall-narrow or flat wide design</title>
      <link>https://community.cloudera.com/t5/Support-Questions/Hbase-tall-narrow-or-flat-wide-design/m-p/158097#M120496</link>
      <description>&lt;P&gt;Hello arunkumar&lt;/P&gt;&lt;P&gt;As a general rule it will come back to what you are trying to achieve and how you want to service data. Remember that Hbase's performance is directly derived from the rowkey and hence how you access data. Hbase will split up data in regions served by region servers and on a lower level data will be split by Column Family. A single entry however will be served by the same region. At high level the difference between tall-narrow and flat-wide comes back to scans vs gets. Since Hbase has an ordered on the rowkey storage policy and full scans are costly. A Tall-narrow approach would be to have a more complex rowkey giving adjacency of similar elements and allowing to do focused scans for  logical group of entries. A Flat-wide approach would ahve much more information in the entry itself, you "get" the entry through the rowkey and the entry would have sufficient information to do your compute or answer your query.&lt;/P&gt;&lt;P&gt;hope this helps&lt;/P&gt;</description>
      <pubDate>Wed, 06 Apr 2016 14:05:27 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Support-Questions/Hbase-tall-narrow-or-flat-wide-design/m-p/158097#M120496</guid>
      <dc:creator>nmaillard1</dc:creator>
      <dc:date>2016-04-06T14:05:27Z</dc:date>
    </item>
  </channel>
</rss>

