Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
uvdn7
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
31.
▲
by
uvdn7
4y ago
It's not meant to be a perfect analogy. The replication analogy is mostly talking about the tradeoff between performance and cost. So it's less about "replicating" the ip addresses (which is not happening). On that front
32.
▲
by
uvdn7
4y ago
This is a wonderful article. Thanks for sharing. As always, Cloudflare blog posts do not disappoint. It’s very interesting that they are essentially treating IP addresses as “data”. Once looking at the problem from a distributed system lens
33.
▲
by
uvdn7
4y ago
I am genuinely curious about what’s the appeal of SF?
34.
▲
by
uvdn7
4y ago
Managing machine life cycles, data intensive and stateful systems is very hard. I was hoping to see more concrete examples/data points instead of just saying we can also run the same software on our own machines.
35.
▲
Bet Using a Token Bucket
(blog.the-pans.com)
1 points
by
uvdn7
4y ago
|
0 comments
36.
▲
Fault Tolerant Generic Distributed Critical Section Is Impossible
(blog.the-pans.com)
3 points
by
uvdn7
4y ago
|
1 comments
37.
▲
Notes on Amazon's DynamoDB Usenix ATC'22 Paper
(blog.the-pans.com)
2 points
by
uvdn7
4y ago
|
1 comments
38.
▲
Leave something to be somebody else's problem
(blog.the-pans.com)
1 points
by
uvdn7
4y ago
|
0 comments
39.
▲
Why TIMEOUTs are hard to get rid of
(blog.the-pans.com)
1 points
by
uvdn7
4y ago
|
0 comments
40.
▲
Fast SQL from Schemaless Ingestion
(blog.the-pans.com)
3 points
by
uvdn7
4y ago
|
0 comments
41.
▲
Notes on Photon – Databricks' query engine over data lakes
(blog.the-pans.com)
2 points
by
uvdn7
4y ago
|
0 comments
42.
▲
by
uvdn7
4y ago
In this sense, TV and smart phone waste people much of their lives. And it’s only going to get worse for the coming generations.
43.
▲
by
uvdn7
4y ago
It’s very cool. On the surface, it appears to be similar to Alibaba's HTAP system (alibabacloud.com/blog/what-is-t…). I would love to learn more about how they manage the fundamental tradeoffs between read latency/cost a
44.
▲
Unistore, Snowflake’s New Workload for Transactional and Analytical Data
(snowflake.com)
2 points
by
uvdn7
4y ago
|
1 comments
45.
▲
by
uvdn7
4y ago
I will not say cache invalidation is easy; and I am not trying to minimize anyone’s struggles. But cache invalidation is _not_ like FLP impossibility or CAP. Too many systems reason caching (inherently a distributed system) in an ad-hoc way
46.
▲
by
uvdn7
4y ago
https://blog.the-pans.com/when-and-how-to-invalidate-cache/ Does this include the "actual cache consistency/invalidation strategy" you were referring to?
47.
▲
by
uvdn7
4y ago
I basically wrote a separate blog just for replying to this https://blog.the-pans.com/when-and-how-to-invalidate-cache/ .
48.
▲
by
uvdn7
4y ago
Good catch! I shouldn't have omitted the details here. Roughly there are two ways to solve the race you mentioned here. You can use a versioning scheme supported by the database to do compare-and-swap – i.e. sending invalidate along w
49.
▲
by
uvdn7
4y ago
More details can be found at https://blog.the-pans.com/when-and-how-to-invalidate-cache/
50.
▲
by
uvdn7
4y ago
I wrote a separate blog post focusing on when and how to invalidate cache and how it can be done – https://blog.the-pans.com/when-and-how-to-invalidate-cache/ .
51.
▲
by
uvdn7
4y ago
https://blog.the-pans.com/when-and-how-to-invalidate-cache/ Does this address the "knowing what needs invalidation" part?
52.
▲
by
uvdn7
4y ago
https://blog.the-pans.com/when-and-how-to-invalidate-cache/ Does this address the "knowing what needs invalidation" part?
53.
▲
When and How to Invalidate Cache
(blog.the-pans.com)
16 points
by
uvdn7
4y ago
|
1 comments
54.
▲
by
uvdn7
4y ago
> Given this statement, the original title of this submission is even more baffling. If you recognize that data can be cached in clients, and that invalidating those caches is so hard that most systems -- including yours -- just complete
55.
▲
by
uvdn7
4y ago
You think figuring out when to invalidate is the harder part of cache invalidation; in that sense Polaris is not checking the “when” logic but rather repeating it. And you are right. This is not the problem we solved in the post. I should h
56.
▲
by
uvdn7
4y ago
> You very clearly seem to think that the "hard" part of cache invalidation is how to implement invalidating it when you know exactly what needs invalidation. The "hard" part is actually in knowing what needs invalida
57.
▲
by
uvdn7
4y ago
Marc put it extremely well. I agree with every single word of his thread. I should have applied a narrower and more specific definition of cache invalidation in the blog post. I apologize for any confusions it caused.
58.
▲
by
uvdn7
4y ago
> Some cache entries depend on the state of rows in Table C, but for some combinations of Table A and Table B, no data from Table C ends up in the cache entry. This is a good example. Let's talk about it. Say we have a table for &qu
59.
▲
What is hard about Cache Invalidation
(blog.the-pans.com)
1 points
by
uvdn7
4y ago
|
1 comments
60.
▲
by
uvdn7
4y ago
This is a very good question. The number of nines actually go up with increasing timescale windows because Polaris checks anomalies at write-time/invalidation-time. I guess the behavior of what you are describing is cache inconsistenci
More ›