为什么 Imgur 放弃 MySQL 转而支持 HBase

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸:仿小红书(微服务架构)》 正在持续爆肝中,基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...点击查看项目介绍 ;
  • 《从零手撸:前后端分离博客项目(全栈开发)》 2 期已完结,演示链接: http://116.62.199.48/ ;

截止目前, 星球 内专栏累计输出 63w+ 字,讲解图 2808+ 张,还在持续爆肝中.. 后续还会上新更多项目,目标是将 Java 领域典型的项目都整一波,如秒杀系统, 在线商城, IM 即时通讯,权限管理,Spring Cloud Alibaba 微服务等等,已有 2200+ 小伙伴加入学习 ,欢迎点击围观

在一篇 Medium 帖子 中,Imgur 工程师 Carlos Espinoza 描述了 Imgur 如何从 MySQL 切换到 HBase,以便更好地处理 Imgur 正在实施的大量通知。多年来,Imgur 一直使用 MySQL 作为他们的主要存储,而 HBase 处理他们堆栈中的其他部分。由于他们试图创建的通知的复杂性,Espinoza 说他们决定在宽列值存储之上构建他们的系统。

HBase 是一个以 Hadoop 为核心的开源 Apache 项目。在 DB-Engines Ranking 上,它排在 Elasticsearch 之后和 Hive 之上的第十五位。

MySQL 是一种开源 RDBMS,其客户包括 Pinterest、Apple、Dell 和 Motorola。它于 1995 年首次创建,自 2013 年以来一直是使用率第二高的数据库系统,仅次于 Oracle RDBMS。

Imgur 选择 HBase 而不是 MySQL 的一些原因包括:

  • 限制较少的模式——因为 Imgur 上的通知由少数事件组成,它会导致 MySQL 表中的“NULL”值。 HBase 没有这个问题,尽管 Espinoza 说该表可能看起来很稀疏。

  • 原子增量——Imgur 的通知传递逻辑更“轻量级”,因为这些增量仅在超过特定里程碑时才发送通知。

  • “快速”表扫描

  • 线性可扩展性

  • 复制

RDBMS 的限制性模式是离开 SQL 存储转而使用 NoSQL 替代方案的一个常见原因。 Telerik 指出,随着围绕数据的需求不断增长和变化,对可扩展性的需求也可能随之而来;与其在 RDBMS 之上投入更多的精力,不如使用 NoSQL 数据库进行水平扩展更有意义。

以前,Imgur 只有两种类型的通知,因此管理他们的数据要容易得多。由于他们添加了几个具有条件逻辑的通知,例如,当用户的帖子获得 100 个赞时,用户将收到通知,但之前不会。随着更多通知类型的添加,列的数量增加,并且更容易放弃 MySQL 以支持更灵活的 NoSQL 组织。

在此处 查看 Espinoza 的完整帖子。

相关文章