首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

如何设计微博点赞功能数据库?

首先每条微博你所看到的点赞总数肯定本地和后端分开,也就是你点赞后,本地加1,先保证你自己马上看到变化。...然后通过点赞事件的方式传递给队列中,肯定不会直接写关系数据库,一条流量明星微博,千万粉丝点赞,评论里再点赞的请求事件挺吓人的。...这块可以参考lambda架构的办法。 这样点赞总数总是来自当日总数和非当天统计总数之和,当日总数是实时增量的,不去理会是否正确,做好批量统计比对就一定能保证隔天以后点赞总数的准确性。...再加一条,若应用场景不仅仅是高速写入,还可能涉及到大量的范围查找,那么就要从MongoDB这样的分布式数据库的选择基础之上进行优化,因其采用B-tree索引,范围查询的综合效果肯定是要好于基于lsm-tree...但Mongo的写入一定要根据实际数据结构优化,因为你的业务基本上是1毫秒级的写入,这对于Mongo是一个不小的挑战,所以MongoDB的批量顺序写,以及加大内存资源等设置就很重要。

1.1K30
您找到你想要的搜索结果了吗?
是的
没有找到

MONGODB Read Concern 与 Write concern 替代Read Concern

为了避免这样的极端的情况MONGODB 3.2版本后,提出了一个概念 read concern ,其中本意是你读到的数据是不能被回滚的,必须是MONGODB 中的大多数都被写入的数据....并且还有提示,如果你不使用这个功能则可以保证你的系统运行是平稳的,那么问题就来了,如果我不使用这个功能, 但我想保证极端的情况下,我的数据不会因为回滚而造成 dirty read....,将write concern 改变为 W:2, 这样我们就可以保证我们的集群的数据极端的情况下不会被回滚,并且读取数据降低是脏读的可能性...., 那对于这样的数据,我们可以将 w:3 来解决,保证写入的数据在三个节点都落地,那我们读取的时候必然不会碰到上面有可能读数据读不到的情况....(当然风险和性能方面的铤而走险就需要均衡利弊了) 所以,read concern 本身是可以不去设置,但我可以通过write concern 来弥补一些我们需要数据多节点一致性的问题.

60720

MongoDB 可调节的一致性,其他数据库都不行系列 (白皮书 翻译)--2

,以BSON格式发送数据,为实现水平扩展MongoDB 还提供了分片功能,允许用户将数据分布多个复制集中,但本文不会讨论分片的详细信息。...oplog,MongoDB中的所有操作都发生在wiredTiger 事务中,当操作的事务提交是,我们称为本地提交,一旦他被写入数据库和oplog中,他可以被复制到从节点,当oplog数据传播到足够多的节点的情况下...writeConcern可以被指定为数值,或majority,在任何写入语句中,w:1写操作的客户端将在该写入服务器的主节点后,立即受到确认,当你将语句中带入 w:N 完成的时候,写操作至少会写入N个服务器后才本地将事务提交...,当你写入 w:majority的时候,写操作客户端写入操作被大多数提交之前不会受到事务的确认信息。...假设你希望你写入的数据操作系统层面或硬件层面不存在丢失的可能性,则 w:大多数,可以向你的写入的客户端保证数据不丢失。

10410

RedisJson发布官方性能报告,性能碾压ES和Mongo

此外,RedisJSON 的读取、写入和负载搜索延迟更高的百分位数中远比 ElasticSearch 和 MongoDB 稳定。...当增加写入比率时,RedisJSON 还能处理越来越高的整体吞吐量,而当写入比率增加时,ElasticSearch 会降低它可以处理的整体吞吐量。...▐ 100% 读取基准 与写类似,我们可以观察到 Redis 在读取方面表现最佳,允许读取比 ElasticSearch 多 15.8 倍,比 MongoDB 多 2.8 倍,同时整个延迟范围内保持亚毫秒级延迟...每个测试变体中,我们添加了 10% 的写入,以按相同的比例混合和减少搜索和读取百分比。...正如您在图表中所看到的, RedisJSON* 上不断更新数据和增加写入比例不会影响读取或搜索性能并提高整体吞吐量。

1K30

RedisJson 横空出世,性能碾压ES和Mongo!

此外,RedisJSON 的读取、写入和负载搜索延迟更高的百分位数中远比 ElasticSearch 和 MongoDB 稳定。...当增加写入比率时,RedisJSON 还能处理越来越高的整体吞吐量,而当写入比率增加时,ElasticSearch 会降低它可以处理的整体吞吐量。...3.3 100% 读取基准 与写类似,我们可以观察到 Redis 在读取方面表现最佳,允许读取比 ElasticSearch 多 15.8 倍,比 MongoDB 多 2.8 倍,同时整个延迟范围内保持亚毫秒级延迟...正如您在图表中所看到的, RedisJSON* 上不断更新数据和增加写入比例不会影响读取或搜索性能并提高整体吞吐量。...写入时,MongoDB 和 RedisJSON* 即使 p99 时也能保持亚毫秒级的延迟。

3K50

MongoDB CTO 兼联合创始人Eliot Horowitz: 文档无处不在

文档模型,尤其是 MongoDB API,正在蓬勃迅猛发展。 正如 MongoDB CEO Dev Ittycheria 文档即未来的博文中所言,答案显而易见。文档是可以涵盖流行数据模型的超集。...Atlas允许跨越全球的复制集部署,为应用程序节点提供低延迟的读取功能 DocumentDB 没有分片功能,限制了其扩展能力 DocumentDB 缺少很多高级功能,如可以智能地将本地文档路由到世界各地的特定分片中的全球集群功能...由于兼容性问题,其实也无法本地MongoDB 开发 DocumenDB 的应用程序,因此,我们不清楚团队怎样才能开发 DocumentDB 应用。...我们无法确定这些崩溃的根本原因,但我们测量到故障转移时间需要两到四分钟。现实情况下,这可能会导致严重的、反复的宕机。...MongoDB Atlas是唯一一款为开发人员提供 MongoDB 全部功能、全球范围内、任何规模的真正分布式系统,并且每一个主要公有云都可以自由运行。

1.1K30

RedisJson 横空出世,惊爆了!

此外,RedisJSON 的读取、写入和负载搜索延迟更高的百分位数中远比 ElasticSearch 和 MongoDB 稳定。...当增加写入比率时,RedisJSON 还能处理越来越高的整体吞吐量,而当写入比率增加时,ElasticSearch 会降低它可以处理的整体吞吐量。...100% 读取基准 与写类似,我们可以观察到 Redis 在读取方面表现最佳,允许读取比 ElasticSearch 多 15.8 倍,比 MongoDB 多 2.8 倍,同时整个延迟范围内保持亚毫秒级延迟...正如您在图表中所看到的, RedisJSON* 上不断更新数据和增加写入比例不会影响读取或搜索性能并提高整体吞吐量。...写入时,MongoDB 和 RedisJSON* 即使 p99 时也能保持亚毫秒级的延迟。

51420

RedisJson 横空出世,比 ES 快7 倍,惊爆了!

此外,RedisJSON 的读取、写入和负载搜索延迟更高的百分位数中远比 ElasticSearch 和 MongoDB 稳定。...当增加写入比率时,RedisJSON 还能处理越来越高的整体吞吐量,而当写入比率增加时,ElasticSearch 会降低它可以处理的整体吞吐量。...100% 读取基准 与写类似,我们可以观察到 Redis 在读取方面表现最佳,允许读取比 ElasticSearch 多 15.8 倍,比 MongoDB 多 2.8 倍,同时整个延迟范围内保持亚毫秒级延迟...正如您在图表中所看到的, RedisJSON* 上不断更新数据和增加写入比例不会影响读取或搜索性能并提高整体吞吐量。...写入时,MongoDB 和 RedisJSON* 即使 p99 时也能保持亚毫秒级的延迟。

48920

mongoDB复制(译 v4.0)

不同数据中心维护数据副本可以增加分布式应用程序的数据位置和可用性。您还可以为专用目的维护其他副本,例如灾难恢复,报告或备份。 MongoDB中的复制 副本集是一组维护相同数据集的mongod实例。...[Replication in MongoDB] 选举成功完成之前,副本集无法处理写入操作。 如果查询被配置为主节点脱机时在从节点上运行,则副本集可以继续提供读取查询。...根据write concern,客户端可以写入持久之前查看写入结果: 无论是否write concern,使用“本地”或“可用”readConcern的其他客户端都可以向发布客户端确认写入操作之前查看写入操作的结果...使用“本地”或“可用”readConcern的客户端可以读取副本集故障转移期间可能随后回滚的数据。...变更流 从MongoDB 3.6开始,变更流可用于副本集和分片集群。 变更流允许应用程序访问实时数据变更,而不会产生拖尾oplog的复杂性和风险。

89220

碾压ES和MongoDB,RedisJson横空出世!

此外,RedisJSON 的读取、写入和负载搜索延迟更高的百分位数中远比 ElasticSearch 和 MongoDB 稳定。...当增加写入比率时,RedisJSON 还能处理越来越高的整体吞吐量,而当写入比率增加时,ElasticSearch 会降低它可以处理的整体吞吐量。...③100% 读取基准 与写类似,我们可以观察到 Redis 在读取方面表现最佳,允许读取比 ElasticSearch 多 15.8 倍,比 MongoDB 多 2.8 倍,同时整个延迟范围内保持亚毫秒级延迟...正如您在图表中所看到的, RedisJSON* 上不断更新数据和增加写入比例不会影响读取或搜索性能并提高整体吞吐量。...写入时,MongoDB 和 RedisJSON* 即使 p99 时也能保持亚毫秒级的延迟。

80020

MongoDB 高性能最佳实践: 事务,读取关心程度与写入关心程度

为了维持稳定可预测的数据库性能,开发者需要注意以下几点: 事务运行时限   默认地,MongoDB 会自动终止运行超过 60 秒的多文档事务。若服务器写入能力较弱,可以灵活调整事务的运行时间。...当低延迟比跨分片读取一致性更加重要时,应使用默认的local 读取关心等级,该等级将在本地单机的一份快照中执行事务(忽略其他分片节点)。...你可以MongoDB 多文档事务 参考文档里学习所有最佳实践。查阅文档中的生产环境注意事项一栏来了解性能相关的指引。...选择合适的写入保证等级   MongoDB 允许你向数据库提交写入请求时指定一个可靠性保证等级,称为“写入关心等级” (write concern) 注意:写关心等级可以对任何对服务器进行的操作生效,...同时确保数据不会因为新主节点的选举而被回滚。   MongoDB 支持一个“可线性化” (linearizable) 的读取关心等级。

88620

RedisJson 横空出世,比 ES 快7 倍,惊爆了!

此外,RedisJSON 的读取、写入和负载搜索延迟更高的百分位数中远比 ElasticSearch 和 MongoDB 稳定。...当增加写入比率时,RedisJSON 还能处理越来越高的整体吞吐量,而当写入比率增加时,ElasticSearch 会降低它可以处理的整体吞吐量。...3.3 100% 读取基准 与写类似,我们可以观察到 Redis 在读取方面表现最佳,允许读取比 ElasticSearch 多 15.8 倍,比 MongoDB 多 2.8 倍,同时整个延迟范围内保持亚毫秒级延迟...正如您在图表中所看到的, RedisJSON* 上不断更新数据和增加写入比例不会影响读取或搜索性能并提高整体吞吐量。...写入时,MongoDB 和 RedisJSON* 即使 p99 时也能保持亚毫秒级的延迟。

50530

MongoDB 4.0 系列之 —— 事务实现解析(二)

MongoDB startSession 时,可以指定一系列的选项,用于控制 Session 的访问行为,主要包括: causalConsistency:是否提供 causal consistency...,备节点拉取oplog,并在本地重放事务操作。...更新 oplog 可见时间戳,如果有其他节点从该备节点同步,此时就能读到这部分新写入的 oplog 更新本地 Snapshot(时间戳),新的写入将对用户可见。...有了 read "as of" a timestamp 特性后,重放 oplog 时,备节点上的读就不会再跟重放 oplog 有冲突了,不会因重放 oplog 而阻塞读请求,这是4.0版本一个巨大的提升...),会更新 stable timestamp,因为这些数据已经提交到大多数节点了,一定不会发生 ROLLBACK,这个时间戳之前的数据就都可以写到 Checkpoint 里了。

1.3K20

RedisJson 横空出世,性能碾压 ES 和 MongoDB

此外,RedisJSON 的读取、写入和负载搜索延迟更高的百分位数中远比 ElasticSearch 和 MongoDB 稳定。...当增加写入比率时,RedisJSON 还能处理越来越高的整体吞吐量,而当写入比率增加时,ElasticSearch 会降低它可以处理的整体吞吐量。...3.3 100% 读取基准 与写类似,我们可以观察到 Redis 在读取方面表现最佳,允许读取比 ElasticSearch 多 15.8 倍,比 MongoDB 多 2.8 倍,同时整个延迟范围内保持亚毫秒级延迟...正如您在图表中所看到的, RedisJSON* 上不断更新数据和增加写入比例不会影响读取或搜索性能并提高整体吞吐量。...写入时,MongoDB 和 RedisJSON* 即使 p99 时也能保持亚毫秒级的延迟。

65820

MongoDB 4.0 系列之 b—— 事务实现解析(b一)

结合上面两段代码,我们可以知道,mongodb4.0中,从节点的读是不会和并行回放oplog相互阻塞的,也不用担心会读到不一致的状态。...raft算法可以保证commit-timestamp 一定不会被回滚。...这里可以有一个反思: Q:既然raft可以保证 “commit-timestamp” 一定不会回滚,那么mongodb为何不仅仅应用commit-timestamp之前的oplog到状态机(wiredtiger-kvstore...该过程一般会出现这两种问题: 复制源写入过快(或者相对的,本地写入速度过慢),复制源的oplog覆盖了 本地用于同步源oplog而维持源的游标。...本节点在宕机之前是Primary,重启后本地oplog有和当前Primary不一致的Oplog。 这两种情况分别如下图所示: ? ?

96230
领券