TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

F1: A Distributed SQL Database That Scales

131 pointsby alecover 11 years ago

4 comments

jacques_chesterover 11 years ago
Impressive, as one might expect. Some reactions:<p>-- Secret sauce<p>A lot of the magic of F1 comes from Spanner, the distributed storage system. The name &quot;F1&quot; itself is an allusion to &quot;inheriting&quot; some of the properties of Spanner.<p>-- Hierarchical tables<p>What they call hierarchical tables, I would think best be viewed as one-to-many relationships. In guess they&#x27;ve privileged this model in their storage because that&#x27;s what a lot of their AdWords schema looks like.<p>-- Change History<p>I like the observation that keeping full histories is relatively straightforward with atomic, granular timestamping and indeed that it should be baked in. Every database schema I&#x27;ve ever worked with always goes through a similar evolutionary cycle:<p>1. We only need to capture the current state of the model.<p>2. Wait, we do need to capture historical states of the model.<p>3. Wait, the model is changed, we need to capture historical states and the models that were current.<p>(You can think of this as taking progressive differentials of incoming transactions).<p>The F1 designers have baked that right into the database, where it belongs. Weak temporal support has long been the sore point in SQL.<p>-- Remote data<p>I was struck by their observation that most database storage engines are built around the concept of seeks and reads, whereas theirs is necessarily built around batching and pipelining over a network. If I am reading them correctly, their engine takes advantage of having multiple copies of data by sending reads to multiple disk nodes and then working from the first copy that is returned.
评论 #6287921 未加载
评论 #6287933 未加载
评论 #6287984 未加载
fintlerover 11 years ago
I posted this question on StackOverflow regarding TrueTime (used by Spanner) a few days ago and haven&#x27;t received any responses:<p>&lt;<a href="http://stackoverflow.com/questions/18384883/why-is-googles-truetime-api-hard-to-duplicate&gt;" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;18384883&#x2F;why-is-googles-t...</a><p>However, I think this HN thread seems like it might be a good place to get comments on why my line of reasoning may be incorrect. Does anyone have any thoughts on why building something like Spanner on top of basic Paxos quorums and NTP would be a bad idea?
评论 #6287739 未加载
capkutayover 11 years ago
Can someone enlighten me as to why google doesn&#x27;t want to make an enterprise play? Many companies tout that they are offering data infrastructures similar to those used at google..why wouldn&#x27;t google commercialize that technology themselves? It should be pretty obvious as to how that could be of huge financial benefit to the company.
评论 #6290057 未加载
dvlimanover 11 years ago
This is not new by any mean...
评论 #6287073 未加载
评论 #6287554 未加载