Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

离散数据的同步问题

  这几天试着着手前后端同步的架构,但依然存在一些理论上问题。之前的文章似乎全都以线性数据为前提做讨论的,对于离散数据的同步确实比线性数据困难。因为客户端无法通过离散数据计算出查询可能产生的ID序列,这时就需要与服务器保持通信。
  一个包含复杂查询条件的查询,它可能查询的ID序列就是前端无法计算的。比如查找某个用户在某一时间段的发言,由于这些发言之间的ID并没必然联系,这个请求就需要遍历所有数据才能找到所属的部分(除非前后端有为此同步索引,但这个成本非常高,不考虑它)。然而客户端的数据存储是不完全的,所以这个工作需要由服务器端来完成。
  或者一个更典型的例子,全文搜索。除非客户端持有全部数据,否则不可能在客户端直接计算出任意关键词全文搜索的结果。所以对于这样的情况向服务器发起请求就是无法避免的。但不同于传统Web,客户端只是需要这个查询结果的ID序列,而数据可能在客户端已经被缓存过了。所以这个请求需要传输的数据实际上是很小的。
  数据如果存在删除操作,实际上也是离散数据。最初我的想法能不能将被删除的条目标记为已删除,而不去影响结构呢?但是即便如此,在需要查询特定数量的记录时就会使ID序列无法计算。比如有一个聊天室,一个用户在这个聊天室已经有50条聊天记录后才加入,现在已经聊到了100条。这时管理员发现,ID(从1开始计数)为16的记录是广告,并把它标记为了删除状态。如果此时这个用户需要查询第8页的数据(每页10条计),那么按照线性ID的计算会得到ID从71到80的记录。但由于ID为16的记录是删除的,它不该算入统计,所以真正的第8页ID应该是从72到81。也就是说,对数据的删除会破坏线性数据结构,使其变为离散数据。所以对于需要删除的数据,我们可能也需要请求服务器来获取查询对应的真正ID序列(其它做法不是没有,但还需要从适用性分析来进一步研究)。
  这篇暂时就讨论这些,关于数据同步的问题还有很多需要研究的地方。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^