像实时编辑器一样的Google存储机制

Question

我已经组装了一个文本编辑器(WYSIWYG)，并且能够在这样的结构中来回发送三角洲：

{
    "action": "insert",
    "position": 25,
    "content": "some text"
}

我已经实现了一种将这些信息发送到所有参与的客户端并在目的地应用增量的方法。

问题

存储

我现在试图弄清楚如何处理服务器端的存储机制。我使用MongoDB作为主数据库，而且由于这些三角洲经常出现，所以我认为，当它们出现时将它们全部写入数据库可能很快就会使数据库变得紧张。

可能解决办法

我正在考虑将文档组装到内存中，并将文档刷新回数据库，每10秒进行一次(但如果在将更改写入数据库之前丢失了更改怎么办？此外，记忆是非常宝贵的)

服务

假设我已经成功地将这些更改的100 000存储在一起形成一个文档，那么当有人加载文档(操作DOM似乎是资源密集型的)时，将它们全部提取并呈现到编辑器上是明智的，还是在文档到达服务器并在文档被请求时返回已经组装好的文档时将它们应用到文档中更好呢？

有了上面提出的解决方案，我只需要得到一个文档，而不是要处理的一系列三角洲。但我不想向客户端发送HTML内容。

像Google这样的服务如何处理这个问题？欢迎就执行工作提出任何建议。

谢谢

资源到目前为止：

• 同时应用更改的过程

Answer 1

我不知道Google是如何做到这一点的，但这类东西正是像Redis和Memcached这样的DBs所设计的。它们主要是内存中的，但有一个定期刷新到磁盘，以持久.没有完美的原子性，但是通常在相同的解决方案中不可能同时具有完美的事务完整性和完美的可伸缩性；这通常是某种权衡。