wouldn't that be ignoring the fact that is just a "prefix" and there is
still the unique key after that prefix ;), so yes it may be just as clumpy
as using OPP but only within a node which I don't really see as a big deal
at that point, or am I missing something? Though maybe the default impl
woul
On Fri, Sep 9, 2011 at 10:34 AM, Dean Hiller wrote:
> I saw this quote in the pdf.
>
> "For large indexes with common terms this too much data! Queries with >
> 100k hits"
>
> 1. What would be considered large? In most of my experience, we have the
> typical size of a RDBMS index but just ha
I saw this quote in the pdf.
"For large indexes with common terms this too much data! Queries with > 100k
hits"
1. What would be considered large? In most of my experience, we have the
typical size of a RDBMS index but just have many many many more indexes as
the size of the index is just de
Actually, we only need a 8 bit key(one whole byte) because an 8 bit key
would be useful up to 2^8 nodes which I am pretty sure we would never get
too. Of course, I guess we could use one more whole byte just in case ;)
We are planning on doing this ourselvesit would just be nice if it was
hid
On Thu, Sep 8, 2011 at 5:12 PM, Dean Hiller wrote:
> I was wondering something. Since I can take OPP and I can create a layer
> that for certain column families, I hash the key so that some column
> families are just like RP but on top of OPP and some of my other column
> families are then on OP
I was wondering something. Since I can take OPP and I can create a layer
that for certain column families, I hash the key so that some column
families are just like RP but on top of OPP and some of my other column
families are then on OPP directly so I could use lucandra, why not make RP
deprecate