It makes sense.
Thanks, David!
On Mon, Apr 5, 2010 at 2:34 PM, David Timothy Strauss
<da...@fourkitchens.com> wrote:
> Cache the <product, tag> => <score> map as you write values (a
> "write-through" cache) so that reading the current score hits something like
> memcached instead of Cassandra. With a cache hit, you get an ideal,
> write-only path in Cassandra. Three blind writes in Cassandra is cheap -- no
> matter what your scale. The only risk is inability to efficiently remove old
> scores if you lose the contents of memcached, but that risk can be mitigated
> various ways.
>
> Of course, I'm assuming a single data center, here. Memcached isn't too
> useful for this if you need to update scores at two data centers.
>
> I'm not sure how much the 0.6 row cache might help in this case, too.
>
> ----- "Andriy Bohdan" <a.boh...@gmail.com> wrote:
>
>> Hello guys
>>
>> I have a pretty similar task. There's a need to store tags of
>> products
>> with score. Score may go up and down and tags have to be ordered by
>> their score for each product. Score is updated "very" often.
>>
>> I was thinking of using the following model (simplified here for
>> clarity):
>>
>> Product = {
>> product_key: {
>> name: ....
>> etc..
>> }
>> ...
>> }
>>
>> Product_Tags = {
>> product_key : {
>> tag_name: score
>> ...
>> }
>> ...
>> }
>>
>> Product_Tags_Ordered (compareWith:BytesType) = {
>> product_key: {
>> (score, time_uuid) : tag_name
>> ...
>> }
>> ...
>> }
>>
>> So to update a score of a tag:
>> 1) need to look old value of score to be able to remove it from
>> Product_Tags_Ordered
>> 2) remove Row from Product_Tags_Ordered with old score
>> 3) update score in Product_Tags
>> 4) insert new Row into Product_Tags_Ordered with new score
>>
>> 4 IO operations look like a bit too much to update one score as for
>> me.
>>
>> I'm curious if there's any better solution I missed.
>>
>>
>> On Mon, Apr 5, 2010 at 11:54 AM, JKnight JKnight <beukni...@gmail.com>
>> wrote:
>> > Thanks David,
>> > But what's does "monotonicity" mean?
>> >
>> > User's score belongs to their action. When they win the game or
>> sale
>> > something, user's score will increase. When user lose the game or
>> buy
>> > something, user's score will decrease.
>> >
>> > On Mon, Apr 5, 2010 at 4:09 AM, David Strauss
>> <da...@fourkitchens.com>
>> > wrote:
>> >>
>> >> I need the question about monotonicity answered, too.
>> >>
>> >> You should also know: Cassandra is not ideal for directly tracking
>> >> values you increment or decrement.
>> >>
>> >> On 2010-04-05 08:04, JKnight JKnight wrote:
>> >> > Thanks for for reply, David.
>> >> >
>> >> > I will tell more the detail about the system. My system is used
>> to store
>> >> > the score (point) user earn when they play game.
>> >> >
>> >> > "Mark" is the score.
>> >> > User's score changes when user win game, buy or sell anything.
>> >> >
>> >> > Sorry I make a mistake. My data model is:
>> >> >
>> >> > Mark{ //Column Family
>> >> > gameId:{ //row key
>> >> > mark_userId: ""// (column name : value),
>> >> > mark2_userId2: ""
>> >> > },
>> >> > gameId2:{//row key
>> >> > mark_userId: ""
>> >> > }
>> >> > }
>> >> >
>> >> >
>> >> > On Sun, Apr 4, 2010 at 11:44 PM, David Strauss
>> <da...@fourkitchens.com
>> >> > <mailto:da...@fourkitchens.com>> wrote:
>> >> >
>> >> > On 2010-04-05 02:48, JKnight JKnight wrote:
>> >> > > I want to design the data storage to store user's mark for
>> a large
>> >> > > amount of user. When system run, user's mark changes
>> frequently.
>> >> >
>> >> > What is a "mark"?
>> >> >
>> >> > > I want to list top 10 user have largest mark.
>> >> >
>> >> > Do the "marks" increase monotonically? What other properties
>> do they
>> >> > have?
>> >> >
>> >> > > Could we use Cassandra for store this data?
>> >> > >
>> >> > > Ex, here my Cassandra data model design:
>> >> > > Mark{
>> >> > > userId{
>> >> > > mark_userId
>> >> > > },
>> >> > > }
>> >> >
>> >> > I do not understand that notation. What parts are the CF,
>> key/row,
>> >> > and
>> >> > column?
>> >> >
>> >> > > When user's mark changes, we remove old mark_userId and add
>> new
>> >> > > mark_userId.
>> >> > > Because user's mark change frequently and with large amount
>> of
>> >> > user, I
>> >> > > think Cassandra can not satisfy.
>> >> >
>> >> > On the contrary, Cassandra excels at tracking rapidly
>> changing data
>> >> > and
>> >> > even shards rows to scale I/O horizontally.
>> >> >
>> >> > --
>> >> > David Strauss
>> >> > | da...@fourkitchens.com <mailto:da...@fourkitchens.com>
>> >> > Four Kitchens
>> >> > | http://fourkitchens.com
>> >> > | +1 512 454 6659 [office]
>> >> > | +1 512 870 8453 [direct]
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Best regards,
>> >> > JKnight
>> >>
>> >>
>> >> --
>> >> David Strauss
>> >> | da...@fourkitchens.com
>> >> | +1 512 577 5827 [mobile]
>> >> Four Kitchens
>> >> | http://fourkitchens.com
>> >> | +1 512 454 6659 [office]
>> >> | +1 512 870 8453 [direct]
>> >>
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > JKnight
>> >
>>
>>
>>
>> --
>> Andriy
>
> --
> David Strauss
> | da...@fourkitchens.com
> | +1 512 577 5827 [mobile]
> Four Kitchens
> | http://fourkitchens.com
> | +1 512 454 6659 [office]
> | +1 512 870 8453 [direct]
>
--
Andriy
