【Hacker News搬运】分布式SQLite：范式转变还是炒作？

hackernews

Title: Distributed SQLite: Paradigm shift or hype?

分布式SQLite：范式转变还是炒作？

Text:

Url: https://kerkour.com/distributed-sqlite

很抱歉，我尝试抓取指定网页的内容时遇到了问题，该网页返回了403状态码，这意味着访问被禁止。因此，我无法直接分析或总结网页内容。如果您有其他网页或内容需要分析，请提供，我会尽力帮助您。

Post by: mooreds

Comments:

tptacek: This is kind of missing the point. I can only speak for the company that sponsors LiteFS (I don't think any edge computing companies put 'otoolep up to doing rqlite, for instance). We love Postgres. Most of our users use Postgres. And Postgres works fine in edge/backhaul configurations; companies were doing geographically distributed Postgres read replicas long, long before we came around. That's where we got the idea.The idea of LiteFS is:* Most apps are read-heavy, and some of them are overwhelmingly read-heavy.* If you're read-heavy and can thus get away with it, there's a pretty significant performance win in replacing the networked n-tier architecture with SQLite, because Postgres round trips add up over the lifecycle of any given request.* In fact, that's so much the case that --- as Richard Hipp has been pointing out for over a decade --- you can blow off the N+1 problem and just write natural queries.I think Ben Johnson would be the first to tell you that LiteFS isn't a perfect fit for every application. We have systems that use both Postgres and LiteFS.Meanwhile, you have to dig to find it on our web page! It's an open source project that works everywhere Linux does. Dial back the cynicism a bit! :)A plug here for:<a href="https://kerkour.com/sqlite-for-servers" rel="nofollow">https://kerkour.com/sqlite-for-servers</a>Same author, and one of the best SQLite articles ever.

tptacek: 这有点跑题了。我只能代表赞助LiteFS的公司发言（例如，我不认为有任何边缘计算公司会让Otolep做rqlite）。我们喜欢Postgres。我们的大多数用户使用Postgres。并且Postgres在edge&#x2F中工作得很好；回程配置；早在我们出现之前，公司就已经在做地理分布的Postgres读取副本了。那个；这就是我们的想法 LiteFS的理念是：*大多数应用程序的阅读量都很高，其中一些应用程序的读取量绝大多数都很高 *如果您；重读很重，因此可以逃脱惩罚；用SQLite取代网络n层架构是一个相当显著的性能优势，因为Postgres的往返行程在任何给定请求的生命周期中都会增加 *事实上；正如Richard Hipp十多年来一直指出的那样，你可以解决N+1问题，只需编写自然查询 我想Ben Johnson会第一个告诉你LiteFS不是；并非完全适合各种应用。我们的系统同时使用Postgres和LiteFS 同时，你必须挖掘才能在我们的网页上找到它！它；这是一个开源项目，在Linux的任何地方都可以使用。把冷嘲热讽调回一点！：） 这里的插件用于：<A href=“https://；&#x2F；kerkour.com&#x2F！sqlite for servers”rel=“nofollow”>https://&#x2F；kerkour.com&#x2F；sqlite for servers</a>同一作者，也是有史以来最好的sqlite文章之一。

zackify: I think this skips one mega benefit for apps.I’ve been using liteFS in production for a couple months.Your web app is able to resolve db queries instantly.You don’t need loading states if you’re using complex charts and other frontend JS that waits for data.All the data is resolved so fast and you can just return all your data like more traditional apps, and the load times are insane.If you’re multi region you can deploy one app instance there. Instead of 2-3. Postgres read replica, maybe something like redis.It really replaces both of those, assuming you have a read heavy app it works great.

zackify: 我认为这忽略了应用程序的一大好处 我已经在生产中使用liteFS几个月了 您的web应用程序能够立即解决数据库查询 如果您使用复杂的图表和其他等待数据的前端JS，则不需要加载状态 所有数据都能很快解决，你可以像更传统的应用程序一样返回所有数据，加载时间太长了 如果你是多地区的，你可以在那里部署一个应用程序实例。而不是2-3。Postgres阅读复制品，也许是类似redis的东西 它真的取代了这两者，假设你有一个阅读量很大的应用程序，它会很好地工作。

galaxyLogic: What portion of writes typically have to go to the primary server? If users are local then their data maybe is often local as well. In other words not all writes need to first go the central server from where they are distributed back to all edge-databases.I can see that the organization running the application needs a global view of all data. But regional users perhaps don't. Often they just need to know their own data.Write first to edge then copy to central database rather than write first to central database then trickle down to the site from where the write originated in. Just wondering what portion of applications could use this alternative design.

galaxyLogic: 写入的哪些部分通常必须转到主服务器？如果用户是本地的，那么他们的数据可能也经常是本地的。换言之，并不是所有的写入都需要首先到达中心服务器，从那里它们被分布回所有边缘数据库 我可以看到，运行应用程序的组织需要所有数据的全局视图。但是区域用户可能不喜欢；t.通常他们只需要知道自己的数据 先写入边缘，然后复制到中央数据库，而不是先写入中央数据库，然后从写入源站点滴入。只是想知道应用程序的哪一部分可以使用这种替代设计。

xray2: Most apps never need to scale. Also, worried about scaling? Just use an ORM that allows you to switch from SQLite to Postgres. It’s as simple as that.

xray2: 大多数应用程序从不需要扩展。还有，担心缩放？只需使用一个ORM，就可以从SQLite切换到Postgres。就这么简单。

icpmacdo: Among the various free backend hosting options currently available, does Cloudflare stand out as the best choice with its offerings such as Workers and D1? I would love to hear users experiences with these services or if there any informative resources that discuss the costs associated with scaling applications on the infra?

icpmacdo: 在目前可用的各种免费后端托管选项中，Cloudflare是否凭借Workers和D1等产品脱颖而出，成为最佳选择？我很想听听用户对这些服务的体验，或者是否有任何信息资源可以讨论在基础设施上扩展应用程序的相关成本？