mysqlnosql_扩展到100M：MySQL是更好的NoSQL

mysql nosql

MySQL是更好的NoSQL。 在考虑NoSQL用例&＃xff08;例如键/值存储&＃xff09;时&＃xff0c;MySQL在性能&＃xff0c;易用性和稳定性方面更具意义。 MySQL是一个可靠的引擎&＃xff0c;具有许多在线资料&＃xff0c;从操作和故障案例到复制和不同的使用模式&＃xff0c;不一而足。 因此&＃xff0c;与未经测试的新型NoSQL引擎相比&＃xff0c;它具有优势。

近年来&＃xff0c;NoSQL引擎已成为主流。 许多开发人员将NoSQL引擎&＃xff08;例如MongoDB&＃xff0c;Cassandra&＃xff0c;Redis或Hadoop&＃xff09;视为构建应用程序的首选&＃xff0c;认为它们是弃用旧SQL引擎的单个产品系列。

选择使用NoSQL数据库通常是基于炒作&＃xff0c;或者是错误的假设&＃xff0c;即关系数据库不能像NoSQL数据库那样好执行。 在选择数据库时&＃xff0c;工程师通常会忽略运营成本以及其他稳定性和成熟度方面的问题。 有关不同NoSQL&＃xff08;和SQL&＃xff09;引擎的局限性和缺点的更多信息&＃xff0c;请参阅Aphyr的Jepsen系列文章。

这篇文章将解释为什么我们发现将MySQL用于键/值用例比大多数专用NoSQL引擎要好&＃xff0c;并提供了以这种方式使用MySQL时应遵循的指南。

Wix网站解析

当某人单击指向Wix站点的链接时&＃xff0c;他的浏览器会将HTTP请求发送到具有站点地址的Wix服务器。 无论地址是指向具有自定义域的Wix高级站点&＃xff08;例如domain.com &＃xff09;还是位于Wix域的子域上的免费站点&＃xff08;例如user.wix.com/site &＃xff09;&＃xff0c; 都会发生这种情况 。 该服务器必须通过执行站点的键/值查找URL来从站点地址解析请求的站点。 我们将URL表示为以下讨论的途径。

路由表用于将站点地址解析为站点对象。 因为站点可能会暴露在多条路线上&＃xff0c;所以这种关系是多对一的。 找到该站点后&＃xff0c;应用程序将加载该站点以供使用。 站点对象本身具有复杂的结构&＃xff0c;其中包括两个子对象列表-站点使用的不同服务。 这是我们的对象的示例模型&＃xff0c;假设使用标准SQL数据库和规范化架构&＃xff1a;

当使用传统的标准化模型更新站点时&＃xff0c;我们需要使用事务来更新多个表&＃xff0c;以确保我们保持数据的一致性。 &＃xff08;请注意&＃xff0c;事务正在使用DB级锁&＃xff0c;以防止从受影响的表中进行并发写入&＃xff0c;有时甚至是从受影响的表中读取。&＃xff09;继续使用此模型&＃xff0c;我们可能在每个表中都有一个串行键&＃xff0c;外键和一个索引。路由表中的URL字段。

但是&＃xff0c;标准化的模式化建模方式存在许多问题&＃xff1a;

• 锁限制了对表的访问&＃xff0c;因此在高吞吐量的用例中&＃xff0c;它可能会限制我们的性能。
• 读取对象涉及一些SQL查询&＃xff08;在这种情况下为4&＃xff09;或联接-再次涉及延迟。
• 串行密钥强加了锁定&＃xff0c;并再次限制了写入吞吐量。

这些问题构成了我们可以从MySQL&＃xff08;或任何其他SQL引擎&＃xff09;获得的吞吐量和并发性的限制。 由于这些缺点&＃xff0c;以及用例实际上是关键/价值这一事实&＃xff0c;因此许多开发人员选择寻找提供更好的吞吐量和并发性的NoSQL解决方案&＃xff0c;即使是以稳定性&＃xff0c;一致性或可用性为代价。

在Wix&＃xff0c;我们发现&＃xff0c;与具有标准化数据模型&＃xff08;如上述模型&＃xff09;MySQL和大多数NoSQL引擎相比&＃xff0c;将MySQL创造性地用作键/值存储时&＃xff0c;可以做得更好。 只需将MySQL用作NoSQL引擎即可。 我们现有的系统具有可伸缩性/吞吐量/并发性/延迟数字&＃xff0c;这对于任何NoSQL引擎而言都是令人印象深刻的。 这是我们的一些数据&＃xff1a;

• 跨三个数据中心的主动-主动-主动设置。
• 吞吐量约为200,000 RPM。
• 路由表的数量级为100,000,000个记录&＃xff0c;存储空间为10GB。
• 站点表的数量级为1亿条记录&＃xff0c;200 GB的存储空间。
• 读取延迟平均为1.0-1.5毫秒&＃xff08;实际上&＃xff0c;一个数据中心为0.2-0.3毫秒&＃xff09;。

请注意&＃xff0c;对于大多数关键/价值引擎&＃xff08;包括开源和基于云的引擎&＃xff09;而言&＃xff0c;大约1.0毫秒的延迟被认为是令人印象深刻的&＃xff01; 我们使用MySQL&＃xff08;被认为是基本SQL引擎&＃xff09;实现了这一点。

这是我们正在使用的实际架构&＃xff1a;

CREATE TABLE &＃96;routes&＃96; (&＃96;route&＃96; varchar(255) NOT NULL,&＃96;site_id&＃96; varchar(50) NOT NULL,&＃96;last_update_date&＃96; bigint NOT NULL,PRIMARY KEY (&＃96;key&＃96;),KEY (&＃96;site_id&＃96;)
)CREATE TABLE &＃96;sites&＃96; (&＃96;site_id&＃96; varchar(50) NOT NULL,&＃96;owner_id&＃96; varchar(50) NOT NULL,&＃96;schema_version&＃96; varchar(10) NOT NULL DEFAULT &＃39;1.0&＃39;,&＃96;site_data&＃96; text NOT NULL,&＃96;last_update_date&＃96; bigint NOT NULL,PRIMARY KEY (&＃96;site_id&＃96;)
) /*ENGINE&＃61;InnoDB DEFAULT CHARSET&＃61;utf8 ROW_FORMAT&＃61;COMPRESSED KEY_BLOCK_SIZE&＃61;16*/;

任何未在查询中用作条件的字段都被折叠到单个Blob字段&＃xff08;site_data文本字段&＃xff09;中。 这包括子obj表以及对象表本身上的任何字段。 还要注意&＃xff0c;我们没有使用串行密钥。 取而代之的是&＃xff0c;我们使用varchar&＃xff08;50&＃xff09;&＃xff0c;它存储客户端生成的GUID值-在下一节中将详细介绍。

下面是我们正在使用的查询&＃xff0c;它具有高吞吐量和低延迟&＃xff1a;

select * from sites where site_id &＃61; (select site_id from routes where route &＃61; ?
)

它的工作方式是首先通过唯一索引对路由表执行查询&＃xff0c;该索引仅返回一个结果。 然后&＃xff0c;我们通过主键查找站点&＃xff0c;再次查找一条记录。 嵌套查询语法确保我们仅对数据库执行一次往返操作以运行两个SQL查询。

上面显示的结果是&＃xff0c;在高流量和高更新率的情况下&＃xff0c;平均性能约为1毫秒。 即使不使用事务&＃xff0c;更新也是半事务的。 这是因为我们在一个插入语句中输入了完整的站点&＃xff0c;并且在我们输入路由之前&＃xff0c;它不会在查询中找到。 因此&＃xff0c;如果我们先进入站点&＃xff0c;然后进入路线&＃xff0c;即使在站点表中可能有孤立数据的极端情况下&＃xff0c;也要确保我们具有一致的状态。

将MySQL用作NoSQL引擎的准则

利用从上面的示例&＃xff08;以及Wix的其他此类案例&＃xff09;获得的经验&＃xff0c;我们制定了一些简短的准则来将MySQL用作NoSQL引擎。

将MySQL用作NoSQL引擎时&＃xff0c;要记住的主要事情是避免使用数据库锁或复杂的查询。

• 不要使用会引入锁的事务。 而是使用应用交易。
• 不要使用串行键。 串行密钥引入了锁定并使主动-主动配置复杂化。
• 使用客户端生成的唯一密钥。 我们使用GUID。

在设计要针对读取进行优化的架构时&＃xff0c;请遵循以下其他准则&＃xff1a;

• 不规范。
• 仅存在要建立索引的字段。 如果索引不需要字段&＃xff0c;则将其存储在一个Blob /文本字段中&＃xff08;例如JSON或XML&＃xff09;。
• 不要使用外键。
• 设计架构以启用读取查询中的一行。
• 不要执行表alter命令。 表alter命令引入了锁定和停机时间。 相反&＃xff0c;请使用实时迁移。

查询数据时&＃xff1a;

• 通过主键或索引查询记录。
• 不要使用联接。
• 不要使用聚合。
• 在副本而不是主数据库上运行内务查询&＃xff08;BI&＃xff0c;数据浏览等&＃xff09;。

我们打算撰写另一篇博客文章&＃xff0c;其中包含有关实时迁移和应用交易的更多信息。

摘要

这篇文章最重要的一点是&＃xff0c;允许您以不同的方式思考。 将MySQL用作NoSQL引擎真是太好了&＃xff0c;这不是它设计的工作方式。 如本文所演示的&＃xff0c;此示例使用MySQL而不是为键/值访问而构建的专用NoSQL引擎。 在Wix上&＃xff0c;MySQL是键/值案例&＃xff08;以及其他案例&＃xff09;的首选引擎&＃xff0c;因为它易于使用和操作&＃xff0c;并且是一个很棒的生态系统。 而且&＃xff0c;它提供的延迟&＃xff0c;吞吐量和并发度指标可以与大多数NoSQL引擎相匹配&＃xff08;甚至超过&＃xff09;。

翻译自: https://www.javacodegeeks.com/2015/12/scaling-100m-mysql-better-nosql.html

mysql nosql