Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=subject
	:references:from:content-type:in-reply-to:message-id:date:to
	:content-transfer-encoding:mime-version; q=dns; s=
	thelastpickle.com; b=QKs5SNapAaETDa+0FyT7OAP05eDtbLLRTCH85bi/FdE
	T9OAxWYlnEJN/f9cWFI00/7feViQ8cpNUQSLAQcI/E/u3dr8bdPcx035yZ/Nbzbg
	JrGVrOxh/PmD6ou7ZHjiDytaO63b9q9pWHsBnzHB9vnrlyKUCHjZrvmkMdVAmZBw
	=
Subject: Re: Using a synchronized counter that keeps track of no of users on
 the application & using it to allot UserIds/ keys to the new users after sign
 up
References: <AANLkTi=279fB=mDVtXfKP-sU_3o9qSuObXFSh9Z=2O6_@mail.gmail.com>
 <239C144D-D816-4011-BB93-5A734513C121@spadac.com>
 <AANLkTikrYXRDGoPoMgEBGcBb+_ggKMWnY+MuR8tVsfbx@mail.gmail.com>
 <AANLkTi=DDdzciL4EPJ7YWCJz3Yqd0gYCatJdecezRgGm@mail.gmail.com>
 <AANLkTinRMhxf+C+yp0393HhzCkHM2zxNf+8UYY=F96ma@mail.gmail.com>
 <AANLkTikpuhxwpb-st92k8gEqHkMJ1voZ0CzMf=9R2t5P@mail.gmail.com>
From: Aaron Morton <aaron@thelastpickle.com>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <AANLkTikpuhxwpb-st92k8gEqHkMJ1voZ0CzMf=9R2t5P@mail.gmail.com>
Message-Id: <34C71130-58C6-4D8F-AB2D-A9BD7E319FE3@thelastpickle.com>
Date: Mon, 7 Feb 2011 10:02:10 +1300
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (iPad Mail 8C148)

If you mix mysql and Cassandra you risk creating a single point of failure a=
round the mysql system.

If you have use data that changes infrequently, a row cache in cassandra wil=
l give you fast reads.

Aaron

On 5/02/2011, at 8:13 AM, Aklin_81 <asdkl93@gmail.com> wrote:

> Thanks so much Ryan for the links; I'll definitely take them into
> consideration.
>=20
> Just another thought which came to my mind:-
> perhaps it may be beneficial to store(or duplicate) some of the data
> like the Login credentials & particularly userId to User's Name
> mapping, etc (which is very heavily read), in a fast MyISAM table.
> This could solve the problem of keys though auto-generated unique &
> sequential primary keys. I could use the same keys for Cassandra rows
> for that user. And also since Cassandra reads are relatively slow, it
> makes sense to store data like userId to Name mapping in MyISAM as
> this data would be required after almost all queries to the database.
>=20
> Regards
> -Asil
>=20
>=20
>=20
> On Fri, Feb 4, 2011 at 10:14 PM, Ryan King <ryan@twitter.com> wrote:
>> On Thu, Feb 3, 2011 at 9:12 PM, Aklin_81 <asdkl93@gmail.com> wrote:
>>> Thanks Matthew & Ryan,
>>>=20
>>> The main inspiration behind me trying to generate Ids in sequential
>>> manner is to reduce the size of the userId, since I am using it for
>>> heavy denormalization. UUIDs are 16 bytes long, but I can also have a
>>> unique Id in just 4 bytes, and since this is just a one time process
>>> when the user signs-up, it makes sense to try cutting down the space
>>> requirements, if it is feasible "without any downsides"(!?).
>>>=20
>>> I am also using userIds to attach to Id of the other data of the user
>>> on my application. If I could reduce the userId size that I can also
>>> reduce the size of other Ids, I could drastically cut down the space
>>> requirements.
>>>=20
>>>=20
>>> [Sorry for this question is not directly related to cassandra but I
>>> think Cassandra factors here because of its  tuneable consistency]
>>=20
>> Don't generate these ids in cassandra. Use something like snowflake,
>> flickr's ticket servers [2] or zookeeper sequential nodes.
>>=20
>> -ryan
>>=20
>>=20
>> 1. http://github.com/twitter/snowflake
>> 2. http://code.flickr.com/blog/2010/02/08/ticket-servers-distributed-uniq=
ue-primary-keys-on-the-cheap/
>>=20