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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

ReadySet Core: next-generation SQL caching, freely available

106 点作者 marzoeva将近 3 年前

17 条评论

aeyes将近 3 年前
If you release something new, you should make sure that your documentation contains useful information.<p>Even the most fundamental information like available configuration options, command-line arguments, deployment information and so on is missing.<p>Looking at the code it appears that you need Consul, Zookeeper and Redis to make this fly and the docs don&#x27;t mention this anywhere. They (barely) explain how to run the SQL proxy on a local machine but thats it.<p>I wonder if the testimonials on your website are just pulled from thin air, I don&#x27;t think any sane person would even experiment with this anywhere near production environments.
评论 #31769645 未加载
评论 #31772675 未加载
评论 #31769622 未加载
zasdffaa将近 3 年前
There are too many questions here. What does it not do? What&#x27;s the overhead of monitoring the main DB and how&#x27;s it done - triggers? Does it need schema changes? What about race conditions - can you guarantee none? What&#x27;s the memory overhead you need for the cache? Can you control what gets cached?<p>&gt; It can serve millions of reads per second on a single node ...<p>I&#x27;m not a network guy but that seems just astonishing - what is a &#x27;node&#x27; here?<p>&gt; ReadySet incrementally maintains result sets of SQL queries based on writes to the primary database.<p>So basically you&#x27;ve solved the general materialised view incremental update problem? That&#x27;s an unsolved problem in general, surely?<p>Edit: not dissing but trying to see where the limits are.
评论 #31775800 未加载
评论 #31771037 未加载
jjice将近 3 年前
I love the concept. Not needing to have extra code and logic for a caching layer seems very nice. In my experience, I haven&#x27;t ever been in a situation where I needed super heavy caching, but this seems like it gives it to you &quot;for free&quot;. Interested to see if we see more of ReadySet in the future.
评论 #31768882 未加载
cpursley将近 3 年前
Woah, I had the same idea not so long ago. Right now I&#x27;m using GraphCDN but would much rather cache at the database level. Looks like this could be a drop in for lots of people already on Postgres &amp; MySQL (meaning no more dog-slow Rails apps).<p>There was a cool article about intercepting the Postgres connection with Elixir not long ago: <a href="https:&#x2F;&#x2F;docs.statetrace.com&#x2F;blog&#x2F;build-a-postgres-proxy&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.statetrace.com&#x2F;blog&#x2F;build-a-postgres-proxy&#x2F;</a>
评论 #31768767 未加载
评论 #31768660 未加载
steve-chavez将近 3 年前
How does ReadySet interact with Row level security[1]? For RLS to work you&#x27;d need validation at the origin server anyway right?<p>[1]: <a href="https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;ddl-rowsecurity.html" rel="nofollow">https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;ddl-rowsecurity.html</a>
评论 #31770726 未加载
freitasm将近 3 年前
Interesting. I would love to see this available for MS SQL Server.<p>I&#x27;ve played with Safepeak (1) which runs on Windows Server. It was sold later to an Israeli company (2), which have since gone out of business and assets ended up with another company and now sold as ScaleArc (3)<p>The original SafePeak is available free but no maintenance or anything, so not really production ready. It works, as tested in a test environment but eight years without support or updates...<p>(1) <a href="http:&#x2F;&#x2F;www.safepeak.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.safepeak.org&#x2F;</a> (2) <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;SafePeak" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;SafePeak</a> (3) <a href="https:&#x2F;&#x2F;www.devgraph.com&#x2F;scalearc&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.devgraph.com&#x2F;scalearc&#x2F;</a>
xtreak29将近 3 年前
GitHub repo : <a href="https:&#x2F;&#x2F;github.com&#x2F;readysettech&#x2F;readyset" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;readysettech&#x2F;readyset</a>
评论 #31769715 未加载
agacera将近 3 年前
This looks really nice. I was reading about this and realized it had similar ideas to this [1] Phd thesis from Jon Gjengset. I checked his twitter [2] and it was based on his work indeed.<p>Great that someone is productionalizing this!<p>Btw, is Jon involved in ReadySet?<p>[1] Partial State in Dataflow-Based Materialized Views - <a href="https:&#x2F;&#x2F;github.com&#x2F;mit-pdos&#x2F;noria" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mit-pdos&#x2F;noria</a><p>[2] <a href="https:&#x2F;&#x2F;twitter.com&#x2F;jonhoo&#x2F;status&#x2F;1537474261689872384" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;jonhoo&#x2F;status&#x2F;1537474261689872384</a>
评论 #31772874 未加载
_ben_将近 3 年前
PolyScale [1] is a serverless plug-and-play database edge cache. Our goal is for devs to be able to scale reads globally in a few minutes. It’s wire compatible with Postgres, MySQL, MS SQL Server (more coming including no-sql).<p>It has a global edge network, so no infrastructure to deploy and AI managed cache and auto invalidation, so no cache configuration needed.<p>[1] <a href="https:&#x2F;&#x2F;www.polyscale.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.polyscale.ai&#x2F;</a>
trollied将近 3 年前
&gt; ReadySet is a lightweight SQL caching engine that precomputes frequently-accessed query results and automatically keeps these results up-to-date over time as the underlying data in your database changes<p>I don&#x27;t see the point in using an extra app - you can do this natively in Postgres. Materialized views. <a href="https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;rules-materializedviews.html" rel="nofollow">https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;rules-materializedvi...</a>
评论 #31771315 未加载
评论 #31771050 未加载
评论 #31771220 未加载
tmikaeld将近 3 年前
&gt; Traditional databases would compute the results of this query from scratch every time it was issued.<p>Is this really the case that queries can&#x27;t be cached on traditional databases?
评论 #31769158 未加载
评论 #31769109 未加载
d_watt将近 3 年前
Interesting. What would you say the use case is for this, rather than setting up read replicas? Not having to maintain routing to the replicas on the application side?
评论 #31768425 未加载
anentropic将近 3 年前
Seems clever!<p>I&#x27;m curious what might be pathological cases, patterns of query watching and updates that give the cache a lot of work to do to keep up
wasd将近 3 年前
I signed up for the waitlist! I noticed it asked about AWS, Azure, and GCP but we use Heroku. Hopefully, that won&#x27;t put me too low on the list.<p>Do you have a sense for when people can try it? Most of our app is reads and we&#x27;re using Rails + Redis and it&#x27;s fine and sometimes a pain. Would love to try it.
评论 #31769112 未加载
pmarec将近 3 年前
Are you looking into spreading the dataflow even more down to the clients ? Think realtime subscription for complex queries over structured data.
评论 #31769099 未加载
pmarec将近 3 年前
I seems like i need an @readyset.io address to join your slack. Do you confirm ?
评论 #31839225 未加载
jensneuse将近 3 年前
BSL :(
评论 #31768861 未加载