Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The approach suggested by orangeoctopus is storing one row per day, per store, per item, with a column for every transaction. That's a good one; the other approach is to store each transaction in its own row, with the same key fields plus the unique ID as part of the key. Then there's a single column in a single column family, for the amount.</p> <pre><code>20110103-PIZZAHUT-MEATLOVERS-857283394 20110103-PIZZAHUT-MEATLOVERS-857283395 20110103-PIZZAHUT-MEATLOVERS-857283396 20110103-PIZZAHUT-VEGETABLE-859238494 20110103-PIZZAHUT-VEGETABLE-859238494 </code></pre> <p>etc.</p> <p>The same logic applies in this design; your queries both scan over a specific date range and get the data they need that way (and, if you want to restrict to a single store, or a store product combo, you can do that). The only difference is that now you're scanning over a bunch of rows, instead of many columns in one row per date/store/item combination.</p> <p>These are the two key design techniques in HBase: entities as rows, or entities as columns nested within a parent entity row. The advantage to the latter is that all columns within a row can be updated transactionally; the downside is that the code to retrieve it is a little more complicated (and, you pay a slight price for that transactionality if you have high concurrency).</p> <p>FYI, what you <em>can't</em> do efficiently with this row key is a query that doesn't lead with the parts of your row key, in order. So for example, if you wanted sales for pizza hut for all time, you'd have to scan every row in the table on the server side (which is presumably not desirable b/c presumably you have a LOT of data in this table, otherwise you wouldn't be using HBase ... :)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload