Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jbellis@gmail.com designates
 72.14.220.158 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=S/MoguvdzYOmSef6Nx4ynUIeoKOj8CojqJHQB6V2BbNkBSPS7M6214G+K4KHp0mpBi
         iry5aV376XjmpONpNM6Xj4y7+TIEe92eoQA0DzhYoexfQSuMi4gFfoThbo3t3qZ98YXz
         4JuWm+j1LoUBJYUh0307O1QSfdooCANT2LPok=
MIME-Version: 1.0
In-Reply-To: <878wbclxo7.fsf@lifelogs.com>
References: <2d864a8c1001290416g723270efxb79ac1831c159c9@mail.gmail.com>
	<e06563881001290630y71d372d6u6d0dbf9f75b017b@mail.gmail.com>
	<2d864a8c1001290709t6bf9afd1hb0c3f26eabccfacd@mail.gmail.com>
	<e06563881001291006y2c104a8aqd6634f77dd9db4ca@mail.gmail.com>
	<87aavwmxhm.fsf_-_@lifelogs.com> <87sk9lkn3k.fsf@lifelogs.com>
	<e06563881002010742w3b4f1190sd3e4e79add749e79@mail.gmail.com>
	<878wbclxo7.fsf@lifelogs.com>
From: Jonathan Ellis <jbellis@gmail.com>
Date: Mon, 1 Feb 2010 10:41:28 -0600
Message-ID: <e06563881002010841q465cd8dbqb79d8c7ce55786fa@mail.gmail.com>
Subject: Re: bitmap slices
To: cassandra-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I don't think this is very useful for column names.  I could see it
being useful for values but if we're going to add predicate queries
then I'd rather do something more general.

2010/2/1 Ted Zlatanov <tzz@lifelogs.com>:
> On Mon, 1 Feb 2010 09:42:16 -0600 Jonathan Ellis <jbellis@gmail.com> wrot=
e:
>
> JE> 2010/2/1 Ted Zlatanov <tzz@lifelogs.com>:
>>> On Fri, 29 Jan 2010 15:07:01 -0600 Ted Zlatanov <tzz@lifelogs.com> wrot=
e:
>>>
> TZ> On Fri, 29 Jan 2010 12:06:28 -0600 Jonathan Ellis <jbellis@gmail.com>=
 wrote:
> JE> On Fri, Jan 29, 2010 at 9:09 AM, Mehar Chaitanya
> JE> <meharchaitanya@gmail.com> wrote:
>>>>>> =A0 1. This would lead to enourmous amount of duplication of data, i=
n short
>>>>>> =A0 if I now want to view the data from IS_PUBLISHED dimenstion then=
 my database
>>>>>> =A0 size would scale up tremendously.
>>>
> JE> Yes. =A0But disk space is so cheap it's worth using a lot of it to ma=
ke
> JE> other things fast.
>>>
> TZ> IIUC, Mehar would be duplicating the article data for every article t=
ag.
>>>
> TZ> I searched the bug tracker and wiki and didn't find anything on the
> TZ> topic of tag storage and search, so I don't think Cassandra supports
> TZ> tags without data duplication.
>>>
> TZ> Would it be possible to implement an optional byte[] bitmap field in
> TZ> SliceRange? =A0If you can specify the bitmap as an optional field it =
would
> TZ> not break current clients. =A0Then the search can return only the sub=
set
> TZ> of the range that matches the bitmap. =A0This would make sense for
> TZ> BytesType and LongType, at least.
>>>
>>> I looked at the source code and it seems that
>>> StorageProxy::getSliceRange() is the focal point for reads and bitmap
>>> matching should be implemented there. =A0The bitmap could be applied as=
 a
>>> filter before the other SliceRange parameters, especially the max numbe=
r
>>> of return results. =A0It may be worth the effort to send the bitmap dow=
n
>>> to the ReadCommand/ColumnFamily level to reduce the number of potential
>>> matches.
>>>
>>> If this is not feasible for technical reasons I'd like to know.
>>> Otherwise I'll put it on my TODO list and produce a proposal (unless
>>> someone more knowledgeable is interested, of course).
>
> JE> how would this be different then the byte[] column name you can
> JE> already match on?
>
> Given byte columns
>
> A 0110
> B 0111
> C 0101
>
> the bitmask approach would let you specify a bitmask of "0011" and get
> only B. =A0It's just an AND that looks for a non-zero value. =A0So you ca=
n
> say "0111" and get A, B, and C. =A0Or "0010" to get A and B. =A0"1000" ge=
ts
> nothing.
>
> Cassandra could support OR-ed multiples for better queries, so you could
> ask for (0001,0010) to get A, B, and C.
>
> Ted
>
>