网站建设规划书感受,全球速卖通官网入口,百度识图入口,手机app开发为什么80%的码农都做不了架构师#xff1f; 在上一篇文章中#xff0c;回顾和总结了Cassandra中使用的查询驱动数据模型#xff08;或者说非常规数据模型#xff09;方法论的缺陷。事实证明#xff0c;如果不对查询有深入的了解#xff0c;通过该方法论将… 为什么80%的码农都做不了架构师 在上一篇文章中回顾和总结了Cassandra中使用的查询驱动数据模型或者说非常规数据模型方法论的缺陷。事实证明如果不对查询有深入的了解通过该方法论将无法开发高效的应用。实际上这种场景的应用架构上会变得更加的复杂难于维护并且会造成很大的数据冗余。 此外这个问题通常会被这样的观点掩盖“如果想要扩展性、速度以及高可用性那么就得准备存储多份数据并且牺牲SQL和强一致性。”这个论调十年前可能是正确的但是现在完全错误 没那么夸张我们选择了另一个ASF成员Apache Ignite。在本文中会讲解基于Ignite的应用架构然后衡量它的维护成本。 我们选择的应用仍然是跟踪所有厂商生产的车辆然后了解每个单一厂商的产能如果看过第一篇文章那么应该知道关系模型如下 下一步可以使用Ignite的CREATE TABLE命令创建这三个表然后运行由SQL驱动的应用了么不一定如果不需要对存储于不同表中的数据进行关联操作那么是可以的。但是根据前文前提是应用需要支持两种关联的查询 Q1获取一个厂商在特定的时间段内生产的车型。Q2获取一个厂商特定车型的产量。在Cassandra的案例中我们为每个查询创建了一张表规避了关联的问题那么用Ignite是不是还要经历同样的过程完全不用。事实上Ignite的非并置的关联已经完全可用如果三个表已经建好了那么不需要什么额外的工作。但是这没有比并置的高效和快速。因此首先要多学习一下关系并置然后了解这个概念在Ignite中是如何使用的。 基于并置关联的数据模型 关系并置在Ignite还有其他的分布式数据库比如Google Spanner以及MemSQL中是一个强大的概念它可以在以一个集群节点上存储相关的数据。那么哪些数据是相关的呢尤其是在关系数据库的背景下这非常简单只需要在业务对象之间标示一个父子关系在CREATE TABLE语句中指定一个关系键就可以了剩下的就交给Ignite了 还是拿车辆和厂商的应用举例使用厂商作为父实体车辆作为子实体是合理的。比如按照这样配置好之后某个厂商生产的所有车辆数据都会存储于同一个节点上如下图所示 如图所示丰田生产的车辆都存储于节点1而福特生产的车辆都存储于节点2这就是关系并置车辆都会存储于对应的厂商所在的节点上。 要做到这样的数据分布Vendor表的SQL定义如下 CREATE TABLE Vendor (id INT PRIMARY KEY,name VARCHAR,address VARCHAR
);厂商数据会在整个集群中随机地分布Ignite会使用主键列计算厂商数据所在的节点。 下一个是Car表 CREATE TABLE Car (id INT,vendor_id INT,model VARCHAR,year INT,price float,PRIMARY KEY(id, vendor_id)
) WITH affinityKeyvendor_id;车辆表有一个affinityKey参数配置为vendor_id列它告诉Ignite车辆存储于vendor_id对应的集群节点。 在Production表上重复同样的过程它的数据也是存储于vendor_id对应的集群节点上,如下 CREATE TABLE Production (id INT,car_id INT,vendor_id INT,country VARCHAR,total INT,year INT,PRIMARY KEY(id, car_id, vendor_id)
) WITH affinityKeyvendor_id;这样数据模型就建完了,下一步就进入应用的代码然后开发必要的查询。 带关联的SQL查询 Ignite集群可以使用我们熟悉的SQL进行查询它支持分布式的SQL关联以及二级索引。 Ignite支持两种类型的关联并置和非并置。假定要关联的表已经并置并且本地数据全部可用那么并置的关联会避免数据(关联所需的的移动,这是在分布式数据库中效率最高、性能最好的。如果部分表无法实现关系并置但是还需要进行关联那么非并置的关联就是一个备份计划。这种类型的关联速度较慢因为在关联时它需要在集群节点间进行数据的移动。 之前已经配置好了Vendor、Car和Production表下一步就是利用并置关联的优势为Q1写一个SQL SELECT c.model, p.country, p.total, p.year FROM Vendor as v
JOIN Production as p ON v.id p.vendor_id
JOIN Car as c ON c.id p.car_id
WHERE v.name Ford Motor and p.year 2017
ORDER BY p.year;还能更快么当然能。下面为Vendor.name和Production.year列定义二级索引 CREATE INDEX vendor_name_id ON Vendor (name);
CREATE INDEX prod_year_id ON Production (year);针对Q2的查询也不需要额外的工作: SELECT p.country, p.total, p.year FROM Vendor as v
JOIN Production as p ON v.id p.vendor_id
JOIN Car as c ON c.id p.car_id
WHERE v.name Ford Motor and c.model Explorer;现在如果老板要求增加一个新特性时很快就能构造出一套新的SQL满足他。 完成作为比较如果要支持Q2可以看看基于Cassandra的架构是怎么搞的。 架构简化任务完成 Ignite的基于关系并置的数据模型针对Cassandra的基于查询驱动的模型有如下的优点 应用的数据层基于熟悉的关系模型进行建模易于维护数据使用标准的SQL语法进行访问关系并置提供了现代分布式数据库的更多好处 高效和高性能的分布式关联并置计算;使用Ignite替代Cassandra简化的软件架构并不是唯一的好处过段时间还会有关于强一致性和内存极性能方面的想法。 本文译自Denis Magda的博客。 转载于:https://my.oschina.net/liyuj/blog/1615008
