TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Living Without Atomic Clocks

143 点作者 tschottdorf大约 9 年前

5 条评论

jasonwatkinspdx大约 9 年前
First, CockroachDB&#x27;s time api is based on the Hybrid Logical Clocks paper: <a href="http:&#x2F;&#x2F;www.cse.buffalo.edu&#x2F;tech-reports&#x2F;2014-04.pdf" rel="nofollow">http:&#x2F;&#x2F;www.cse.buffalo.edu&#x2F;tech-reports&#x2F;2014-04.pdf</a><p>This paper is one of the most interesting published in the last couple of years IMO. I remain surprised at how many people have overlooked it. I&#x27;m not sure why this blog post makes no mention of the work, in the past the Cockroach folks have been quite explicit about crediting the research documents they&#x27;re drawing from.<p>Second, cloudera has a patent on this work: <a href="http:&#x2F;&#x2F;www.freepatentsonline.com&#x2F;y2015&#x2F;0156262.html" rel="nofollow">http:&#x2F;&#x2F;www.freepatentsonline.com&#x2F;y2015&#x2F;0156262.html</a>
评论 #11126187 未加载
评论 #11123148 未加载
评论 #11123519 未加载
评论 #11124240 未加载
tlarkworthy大约 9 年前
I don&#x27;t understand why 7ms is considered a good bound for atomic clocks?<p>Hafele and Keating Experiment: &quot;During October, 1971, four cesium atomic beam clocks were flown on regularly scheduled commercial jet flights around the world twice, once eastward and once westward, to test Einstein&#x27;s theory of relativity with macroscopic clocks. From the actual flight paths of each trip, the theory predicted that the flying clocks, compared with reference clocks at the U.S. Naval Observatory, should have lost 40+&#x2F;-23 nanoseconds during the eastward trip and should have gained 275+&#x2F;-21 nanoseconds during the westward trip ... Relative to the atomic time scale of the U.S. Naval Observatory, the flying clocks lost 59+&#x2F;-10 nanoseconds during the eastward trip and gained 273+&#x2F;-7 nanosecond during the westward trip, where the errors are the corresponding standard deviations. These results provide an unambiguous empirical resolution of the famous clock &quot;paradox&quot; with macroscopic clocks.&quot;<p>So if we are loosing nano seconds per day, couldn&#x27;t we fly clocks around the datacenters and resync every month. 7ms seems beatable and not a terrible operational overhead for a fast globally consistent database.
评论 #11123566 未加载
评论 #11122216 未加载
评论 #11122071 未加载
评论 #11122070 未加载
评论 #11124731 未加载
nickpsecurity大约 9 年前
Nice writeup. I disagree that we need chip-scale, atomic clocks. My idea was a dedicated, battery-backed piece of hardware that reliably stored time plus could sync other machines. Plugs into an interconnect with ultra-low latency. One for each datacenter.<p>You can plug them into each machine in the cluster periodically to sync them. Or you can plug it into a master node that connects with low-latency management interface separate from main data line. Occasionally, time server gets exclusive access to that line, assesses latency, and then syncs its time. Time server might be custom built to avoid its own skew or keep one of the timekeeping devices attached. Those are periodically shipped to a central location to resync themselves against an atomic clock or each other.<p>What yall think?
评论 #11122902 未加载
评论 #11124177 未加载
Animats大约 9 年前
Chip-scale atomic clocks are now about $1500.[1] This just gets you a 10.0000000000 MHz oscillator; something else has to count time and provide output.<p>Passing around the max sequence number as a monotonic sequence indicator has a risk. A bogus sequence number near the max value can cause serious problems.<p>[1] <a href="http:&#x2F;&#x2F;www.microsemi.com&#x2F;salescontacts?ctype=3" rel="nofollow">http:&#x2F;&#x2F;www.microsemi.com&#x2F;salescontacts?ctype=3</a>
grogers大约 9 年前
When executing a transaction with a given timestamp on some node, doesn&#x27;t the node have to guarantee that it will no longer accept commits with a smaller timestamp? Without that commitment, you could read a piece of data that is later updated by a transaction that occurred logically before you, breaking serializablility and&#x2F;or snapshot isolation.<p>The spanner paper is unclear how they deal with this, but my guess is that since they have accurately synchronized clocks, you&#x27;ll never have to block long for that commitment to hold. Spanner also uses pessimistic locking, so for a R&#x2F;W transaction, you can rely on locking reads to prevent the anomaly.<p>With cockroachdb, wouldn&#x27;t this commitment imply that poorly synchronized clocks would lead to poor performance?
评论 #11130154 未加载