Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B33E77D1A for ; Tue, 15 Nov 2011 20:12:25 +0000 (UTC) Received: (qmail 97313 invoked by uid 500); 15 Nov 2011 20:12:23 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 97285 invoked by uid 500); 15 Nov 2011 20:12:23 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 97277 invoked by uid 99); 15 Nov 2011 20:12:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Nov 2011 20:12:23 +0000 X-ASF-Spam-Status: No, hits=1.6 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rajkumar.w93@gmail.com designates 209.85.214.44 as permitted sender) Received: from [209.85.214.44] (HELO mail-bw0-f44.google.com) (209.85.214.44) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Nov 2011 20:12:17 +0000 Received: by bkbzv15 with SMTP id zv15so1707207bkb.31 for ; Tue, 15 Nov 2011 12:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=lLtwyvsQM/0M0TCeNlnxJ4dNca4LfcgGSFRNzuioNNo=; b=fE99sJvsXoFMpBigUk8qSj17WDbP64GsoSdEQq56h/KMn38EquTv+38xsNPl5PM1km 9v/GAtJo+3mZ0+zST+IBIqDkpGLLT0DUQbFdxBeuwK/ILROV2o5OCAg3JfY4mo6YtUQ/ OJq+DWosBmV93fFk4Sv3uHHUiXctFDSwIo6Jo= MIME-Version: 1.0 Received: by 10.205.118.13 with SMTP id fo13mr17898430bkc.123.1321387915126; Tue, 15 Nov 2011 12:11:55 -0800 (PST) Sender: rajkumar.w93@gmail.com Received: by 10.223.2.148 with HTTP; Tue, 15 Nov 2011 12:11:54 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 01:41:54 +0530 X-Google-Sender-Auth: zhCvROb3XAJ6-rZjtpY8ODY-zvg Message-ID: Subject: Re: Seeking advice on Schema and Caching From: Aditya Narayan To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=000e0cdfcbc64aa6a104b1cb9952 --000e0cdfcbc64aa6a104b1cb9952 Content-Type: text/plain; charset=ISO-8859-1 Any insights on this ? On Tue, Nov 15, 2011 at 9:40 PM, Quintero wrote: > > > Aditya Narayan wrote: > > >Hi > > > >I need to add 'search users' functionality to my application. (The trigger > >for fetching searched items(like google instant search) is made when 3 > >letters have been typed in). > > > >For this, I make a CF with String type keys. Each such key is made of > first > >3 letters of a user's name. > > > >Thus all names starting with 'Mar-' are stored in single row (with > >key="Mar"). > >The column names are framed as remaining letters of the names. Thus, a > name > >'Marcos' will be stored within rowkey "Mar" & col name "cos". The id will > >be stored as column value. Since there could be many users with same name. > >Thus I would have multple userIds(of users named "Marcos") to be stored > >inside columnname "cos" under key "Mar". Thus, > > > >1. Supercolumn seems to be a better fit for my use case(so that ids of > >users with same name may fit as sub-columns inside a super-column) but > >since supercolumns are not encouraged thus I want to use an alternative > >schema for this usecase if possible. Could you suggest some ideas on this > ? > > > >2. Another thing, I would like to row cache this CF so that when the user > >types in the next character & the query is made consequently, then this > row > >be retrieved from the cache without touching DB. It is expected while > >searching for a single username, the query(as a part of making > >instantaneous suggestions) will be made at least 2-3 times. One may also > >suggest to fetch all the columns starting with queried string to be > >retrieved & then filter out at application level but what about just > >fecthing the exact no of columns(ids/names of users) I need to show to the > >user. Thus instead of keeping all the hundreds of cols in the application > >layer what about keeping it within the DB cache.!? > >The space alloted for the cache will be very small so that row remains in > >cache for a very short time(enough to serve only for the time duration > >while user is making a single search!?) ? > --000e0cdfcbc64aa6a104b1cb9952 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Any insights on this ?

On Tue, Nov 15, 20= 11 at 9:40 PM, Quintero <quinteros8888@gmail.com> wrote:


Aditya Narayan <adynnn@gmail.com= > wrote:

>Hi
>
>I need to add 'search users' functionality to my application. (= The trigger
>for fetching searched items(like google instant search) is made when 3<= br> >letters have been typed in).
>
>For this, I make a CF with String type keys. Each such key is made of f= irst
>3 letters of a user's name.
>
>Thus all names starting with 'Mar-' are stored in single row (w= ith
>key=3D"Mar").
>The column names are framed as remaining letters of the names. Thus, a = name
>'Marcos' will be stored within rowkey "Mar" & col= name "cos". The id will
>be stored as column value. Since there could be many users with same na= me.
>Thus I would have multple userIds(of users named "Marcos") to= be stored
>inside columnname "cos" under key "Mar". Thus,
>
>1. Supercolumn seems to be a better fit for my use case(so that ids of<= br> >users with same name may fit as sub-columns inside a super-column) but<= br> >since supercolumns are not encouraged thus I want to use an alternative=
>schema for this usecase if possible. Could you suggest some ideas on th= is ?
>
>2. Another thing, I would like to row cache this CF so that when the us= er
>types in the next character & the query is made consequently, then = this row
>be retrieved from the cache without touching DB. It is expected while >searching for a single username, the query(as a part of making
>instantaneous suggestions) will be made at least 2-3 times. One may als= o
>suggest to fetch all the columns starting with queried string to be
>retrieved & then filter out at application level but what about jus= t
>fecthing the exact no of columns(ids/names of users) I need to show to = the
>user. Thus instead of keeping all the hundreds of cols in the applicati= on
>layer what about keeping it within the DB cache.!?
>The space alloted for the cache will be very small so that row remains = in
>cache for a very short time(enough to serve only for the time duration<= br> >while user is making a single search!?) ?

--000e0cdfcbc64aa6a104b1cb9952--