My point is about the difficulty in having perfect clocks in a distributed system. If nanosecond precision isn't happening at Google scale, it's unlikely to be happening anywhere. The fact that dapper was written in the context of tracing is irrelevant. On Thu, Oct 29, 2015 at 7:27 PM Brice Dutheil <brice.duth...@gmail.com> wrote:
> Additionally if the time uuid is generated client side, make sure the > boxes that will perform the write hava correct ntp/ptp configuration. > > @John Haddad > > Keep in mind that in a distributed environment you probably have so much > variance that nanosecond precision is pointless. Even google notes that in > the paper, Dapper, a Large-Scale Distributed Systems Tracing Infrastructure > [http://research.google.com/pubs/pub36356.html] > > I agree with your statement about variance. Though I just like to mention > Dapper is about *tracing* query/code, more generally it’s about about the > execution overhead of tracing, which is a bit different that just > *timestamping*. > > > -- Brice > > On Thu, Oct 29, 2015 at 2:45 PM, Clint Martin < > clintlmar...@coolfiretechnologies.com> wrote: > >> Generating the time uuid on the server side via the now() function also >> makes the operation non idempotent. This may not be a huge problem for your >> application but it is something to keep in mind. >> >> Clint >> On Oct 29, 2015 9:01 AM, "Kai Wang" <dep...@gmail.com> wrote: >> >>> If you want the timestamp to be generated on the C* side, you need to >>> sync clocks among nodes to the nanosecond precision first. That alone might >>> be hard or impossible already. I think the safe bet is to generate the >>> timestamp on the client side. But depending on your data volume, if data >>> comes from multiple clients you still need to sync clocks among them. >>> >>> >>> On Thu, Oct 29, 2015 at 7:57 AM, <chandrasekar....@wipro.com> wrote: >>> >>>> Hi Doan, >>>> >>>> >>>> >>>> Is the timeBased() method available in Java driver similar to now() >>>> function >>>> in cqlsh. Does both provide identical results. >>>> >>>> >>>> >>>> Also, the preference is to generate values during record insertion from >>>> database side, rather than client side. Something similar to SYSTIMESTAMP >>>> in Oracle. >>>> >>>> >>>> >>>> Regards, Chandra Sekar KR >>>> >>>> *From:* DuyHai Doan [mailto:doanduy...@gmail.com] >>>> *Sent:* 29/10/2015 5:13 PM >>>> *To:* user@cassandra.apache.org >>>> *Subject:* Re: Oracle TIMESTAMP(9) equivalent in Cassandra >>>> >>>> >>>> >>>> You can use TimeUUID data type and provide the value yourself from >>>> client side. >>>> >>>> >>>> >>>> The Java driver offers an utility class >>>> com.datastax.driver.core.utils.UUIDs and the method timeBased() to generate >>>> the TimeUUID. >>>> >>>> >>>> >>>> The precision is only guaranteed up to 100 nano seconds. So you can >>>> have possibly 10k distincts values for 1 millsec. For your requirement of >>>> 20k per sec, it should be enough. >>>> >>>> >>>> >>>> On Thu, Oct 29, 2015 at 12:10 PM, <chandrasekar....@wipro.com> wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> Oracle Timestamp data type supports fractional seconds (upto 9 digits, >>>> 6 is default). What is the Cassandra equivalent data type for Oracle >>>> TimeStamp nanosecond precision. >>>> >>>> >>>> >>>> This is required for determining the order of insertion of record where >>>> the number of records inserted per sec is close to 20K. Is TIMEUUID an >>>> alternate functionality which can determine the order of record insertion >>>> in Cassandra ? >>>> >>>> >>>> >>>> Regards, Chandra Sekar KR >>>> >>>> The information contained in this electronic message and any >>>> attachments to this message are intended for the exclusive use of the >>>> addressee(s) and may contain proprietary, confidential or privileged >>>> information. If you are not the intended recipient, you should not >>>> disseminate, distribute or copy this e-mail. Please notify the sender >>>> immediately and destroy all copies of this message and any attachments. >>>> WARNING: Computer viruses can be transmitted via email. The recipient >>>> should check this email and any attachments for the presence of viruses. >>>> The company accepts no liability for any damage caused by any virus >>>> transmitted by this email. www.wipro.com >>>> >>>> >>>> The information contained in this electronic message and any >>>> attachments to this message are intended for the exclusive use of the >>>> addressee(s) and may contain proprietary, confidential or privileged >>>> information. If you are not the intended recipient, you should not >>>> disseminate, distribute or copy this e-mail. Please notify the sender >>>> immediately and destroy all copies of this message and any attachments. >>>> WARNING: Computer viruses can be transmitted via email. The recipient >>>> should check this email and any attachments for the presence of viruses. >>>> The company accepts no liability for any damage caused by any virus >>>> transmitted by this email. www.wipro.com >>>> >>> >>> >
