【Hacker News搬运】每个持久对象中的零延迟SQLite存储

[hackernews]

Title: Zero-latency SQLite storage in every Durable Object

每个持久对象中的零延迟SQLite存储

Text:

hn link

Url: https://simonwillison.net/2024/Oct/13/zero-latency-sqlite-storage-in-every-durable-object/

很抱歉，我无法直接访问外部链接来获取内容。但是，我可以根据您提供的链接描述和一般知识来分析内容并尝试进行总结。

链接指向的是Simon Willison的博客文章，标题为“在每一个持久对象中实现零延迟的SQLite存储”。以下是对该文章可能的总结：

Simon Willison在这篇文章中讨论了如何在Web应用中实现一个零延迟的SQLite存储系统，这对于持久化持久对象（Durable Objects）特别有用。以下是一些可能的关键点：

1. **持久对象**：持久对象是一种可以跨多个会话保持状态的对象，这在Web应用中非常有用，尤其是在处理需要长期存储的状态时。

2. **SQLite存储**：SQLite是一个轻量级的数据库，常用于嵌入式应用。文章可能探讨了如何将SQLite集成到Web应用中，以便持久对象可以存储和检索数据。

3. **零延迟存储**：Simon可能介绍了如何减少或消除将数据存储到数据库中的延迟。这可能涉及到优化数据库访问、使用缓存策略或者设计更高效的数据模型。

4. **Durable Objects**：Durable Objects是Web标准的一部分，允许开发者创建可以在任何客户端之间持久化和共享的对象。文章可能讨论了如何利用这些对象来实现高效的存储解决方案。

5. **示例和代码**：文章可能包含了实际的示例代码和配置，展示了如何在Web应用中实现这种存储机制。

6. **性能和可扩展性**：Simon可能会讨论这种方法的性能影响以及如何确保系统在扩展时的可伸缩性。

请注意，这只是一个基于标题和一般知识的假设性总结。要获得准确的内容，请访问原始链接并阅读Simon Willison的文章。

Post by: ajhit406

Comments:

****:

****:

emadda: Some other interesting points:<p>- The write api is sync, but it has a hidden async await: when you do your next output with a response, if the write fails the runtime will replace the response with a http failure. This allows the runtime to auto-batch writes and optimistically assume they will succeed, without the user explicitly handling the errors or awaits.<p>- There are no read transactions, which would be useful to get a pointer to a snapshot at a point in time.<p>- Each runtime instance is limited to 128mb RAM.<p>- Websockets can hibernate and you do not have to pay for the time they are sleeping. This allows your clients to remain connected even when the DO is sleeping.<p>- They have a kind of auto RPC ability where you can talk to other DOs or workers as if they are normal JS calls, but they can actually be calling another data center. The runtime handles the serialisation and parsing.

emadda: 其他一些有趣的点：<p>-写api是同步的，但它有一个隐藏的异步等待：当你用响应进行下一次输出时，如果写失败，运行时将用http失败替换响应。这允许运行时自动批处理写入，并乐观地假设它们会成功，而无需用户明确处理错误或等待<p> -没有读取事务，这对于在某个时间点获取指向快照的指针非常有用<p> -每个运行时实例的RAM限制为128mb。<p>-Websockets可以休眠，您不必为它们休眠的时间付费。这使您的客户端即使在DO睡眠时也能保持连接<p> -它们具有一种自动RPC功能，您可以与其他DO或工作人员交谈，就像他们是正常的JS调用一样，但他们实际上可以调用另一个数据中心。运行时处理序列化和解析。

stavros: This is a really interesting design, but these kinds of smart systems always inhabit an uncanny valley for me. You need them in exactly two cases:<p>1. You have a really high-load system that you need to figure out some clever ways to scale.<p>2. You're working on a toy project for fun.<p>If #2, fine, use whatever you want, it's great.<p>If this is production, or for Work(TM), you need something proven. If you don't know you <i>need</i> this, you don't need it, go with a boring Postgres database and a VM or something.<p>If you do know you <i>need</i> this, then you're kind of in a bind: It's not really very mature yet, as it's pretty new, and you're probably going to hit a bunch of weird edge cases, which you probably don't really want to have to debug or live with.<p>So, who are these systems for, in the end? They're so niche that they can't easily mature and be used by lots of serious players, and they're too complex with too many tradeoffs to be used by 99.9% of companies.<p>The only people I know for sure are the target market for this sort of thing is the developers who see something shiny, build a company (or, worse, build someone else's company) on it, and then regret it pretty soon and move to something else (hopefully much more boring).<p>Does anyone have more insight on this? I'd love to know.

stavros: 这是一个非常有趣的设计，但对我来说，这类智能系统总是处于一个神秘的山谷中。在两种情况下，你需要它们：<p>1。你有一个非常高的负载系统，你需要想出一些聪明的方法来扩展<p> 2。您；为了好玩，我们正在做一个玩具项目<p> 如果#2，好吧，使用你想要的任何东西，它；太好了<p> 如果这是生产或工作（TM），你需要一些经过验证的东西。如果你不这样做；我不知道你需要这个，你不需要；不需要它，用一个无聊的Postgres数据库和一个虚拟机什么的<p> 如果你知道你<i>需要</i>这个，那么你；re有点陷入困境：它；它还不是很成熟，因为它；这是相当新的，而你；我们可能会遇到一堆奇怪的边缘情况，而你可能不会；我真的不想调试或忍受<p> 那么，这些系统到底是为谁准备的呢？他们；他们非常小众，可以；它不容易成熟，也不容易被很多严肃的玩家使用，而且它们；太复杂了，有太多的权衡，99.9%的公司无法使用<p> 我唯一确定的是这类事情的目标市场是那些看到闪亮的东西，在上面建立公司（或者更糟糕的是，建立别人的公司），然后很快后悔并转向其他东西（希望更无聊）的开发人员<p> 有人对此有更深入的了解吗？我；我很想知道。

simonw: One thing I don't understand about Durable Objects yet is where they are physically located.<p>Are they located in the region that hosted the API call that caused them to be created in the first place?<p>If so, is there a mechanism by which a DO can be automatically migrated to another location if it turns out that e.g. they were created in North America but actually all of the subsequent read/write traffic to them comes from Australia?

simonw: 有一件事我不知道；我还不了解持久对象的物理位置<p> 它们是否位于承载API调用的区域，该调用导致它们首先被创建<p> 如果是这样，是否有一种机制，如果事实证明DO是在北美创建的，但实际上所有后续读取都是在北美，则DO可以自动迁移到另一个位置；给他们写来自澳大利亚的流量？

braden-lk: Durable objects seem so cool but the pricing always scares me. (Specifically, having to worry about getting hibernation right.) They’d be a great fit for our yjs document based strategy, but while everything in prod still works on plain ol redis and Postgres, it’s hard to justify an exploration.

braden-lk: 耐用对象看起来很酷，但价格总是让我害怕。（具体来说，必须担心休眠是否正确。）它们非常适合我们基于yjs文档的策略，但虽然prod中的所有内容仍然适用于普通的ol-resi和Postgres，但很难证明探索的合理性。