>> Edanuff + Beautiful People
I think "row cache" could be the best fit but it can take resource
depending on row size. It will only touch disk once (first time) in case of
SST, rest of the req for that row will be served from memory. Try
increasing row cache size and decreasing save period to appropriate value
*Row cache size / save period in seconds: *200/30
>> one catch this is only good for small size row, as your one row contain
all entry with first 3 similar char, this can happen that one row could
become very large while other remain very thin.
eg:
many ppl can have aditya name
adi{
{tya,1}
.
.
}
but only few ppl will have name with x or y.
On Thu, Nov 17, 2011 at 3:29 AM, Aditya <ady...@gmail.com> wrote:
> Thanks to samal who pointed to look at the composite columns. I am now
> using composite columns names containing username+userId & valueless
> column. Thus column names are now unique even for users with same name as
> userId is also attached to the same composite col name. Thus the
> supercolumn issue is resolved.
> But I am still seeking advice some on the caching strategy for these rows.
> Since while a user is doing the search, the DB will be queried multiple
> times because I 'm not keeping the retrieved columns in the application
> layer. Thus I am thinking of caching this row so that the further queries
> be served through the cache. However the important point here is that I am
> using very fewer resources for this cache so that the rows remain in cache
> for a very short time so as to serve the needs only for a single search
> time interval like max 30 seconds. Is this approach correct.? That way I
> wont be putting unneccessary data in cache for a long time thus saving
> resources for other needs.
>
>
> On Wed, Nov 16, 2011 at 11:20 AM, samal <samalgo...@gmail.com> wrote:
>
>> I think you can but I am not sure, I haven't tried that yet, Nothing harm
>> in keeping value also it will be read in single query only.
>>
>> In 2nd case, yes 2 or more query required to get specific user details.
>> As username is map to user_id's key(unique like UUID) and user_id key store
>> actual details.
>>
>>
>> On Wed, Nov 16, 2011 at 11:10 AM, Aditya Narayan <ady...@gmail.com>wrote:
>>
>>> Regarding the first option that you suggested through composite columns,
>>> can I store the username & id both in the column name and keep the column
>>> valueless?
>>> Will I be able to retrieve both the username and id from the composite
>>> col name ?
>>>
>>> Thanks a lot
>>>
>>> On Wed, Nov 16, 2011 at 10:56 AM, Aditya Narayan <ady...@gmail.com>wrote:
>>>
>>>> Got the first option that you suggested.
>>>>
>>>> However, In the second one, are you suggested to use, for e.g,
>>>> key='Marcos' & store cols, for all users of that name, containing userId
>>>> inside that row. That way it would have to read multiple rows while user is
>>>> doing a single search.
>>>>
>>>>
>>>> On Wed, Nov 16, 2011 at 10:47 AM, samal <samalgo...@gmail.com> wrote:
>>>>
>>>>>
>>>>> > 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 ?
>>>>>>> >
>>>>>>>
>>>>>>
>>>>> Aditya,
>>>>>
>>>>> Have you any given thought on Composite columns [1]. I think it can
>>>>> help you solve your problem of multiple user with same name.
>>>>>
>>>>> mar:{
>>>>> {cos,unique_user_id}:unique_user_id,
>>>>> {cos,1}:1,
>>>>> {cos,2}:2,
>>>>> {cos,3}:3,
>>>>>
>>>>> // {utf8,timeUUID}:timeUUID,
>>>>> }
>>>>> OR
>>>>> you can try wide rows indexing user name to ID's
>>>>>
>>>>> marcos{
>>>>> user1:' ',
>>>>> user2:' ',
>>>>> user3:' '
>>>>> }
>>>>>
>>>>> [1]http://www.slideshare.net/edanuff/indexing-in-cassandra
>>>>>
>>>>>
>>>>
>>>
>>
>
