sql占比计算_为nosql数据库设计一套通用的SQL

1 no-sql 数据库的标准化需求

众所周知&＃xff0c;业界主流的关系数据库长得普遍类似&＃xff0c;因为有 SQL 规范约束&＃xff0c;再另类的 DB 系统也不会太过于标新立异。所以&＃xff0c;关系数据库系统通常具备良好的可替换性&＃xff0c;从一种 DB 切换到另一种 DB&＃xff0c;一般不必付出太大代价。

但不同厂商的 no-sql 系统差别巨大。

• 因为 no-sql 起步比 sql 晚得多&＃xff0c;目前还处于战国纷争时代&＃xff0c;没有迹象表明主流 no-sql 可以归并了。

• 主流厂商&＃xff0c;尤其在 PaaS 层面提供服务的厂商&＃xff0c;通常将 no-sql 实施手段与编程语言特性紧密捆绑&＃xff0c;典型的如 Google 的 Cloud Datastore&＃xff0c;这大大拉低了 no-sql 标准化能力。

对于国内用户&＃xff0c;no-sql 可替换的需求远比国外强烈&＃xff0c;几个成气候的云计算平台不够中立&＃xff0c;像阿里云、腾讯云&＃xff0c;自身都是互联网大玩家&＃xff0c;其经营范围均覆盖一多半互联网业务。还有一家国外的&＃xff0c;AWS&＃xff0c;比较中立&＃xff0c;技术也先进&＃xff0c;可惜水土不服&＃xff0c;大家选择 AWS 心里是不安的&＃xff0c;哪天他们经营不下去了怎么办&＃xff0c;类似 GAE 退出中国重演的机率其实不低。

当年笔者花了数月时间用 GAE 开发了一个论坛&＃xff0c;即将上线&＃xff0c;Google 说走就走&＃xff0c;投入全都打水漂了。

不过&＃xff0c;事情也没那么悲观。我们做不到 no-sql 广泛可替换性&＃xff0c;降低要求&＃xff0c;实现小范围、有条件的可替换似乎也没那么难。在公有云领域&＃xff0c;亚马逊处于绝对领先位置&＃xff0c;据 Gartner 最近全球云市场份额报告显示&＃xff0c;AWS 所占份额两倍于第二名至第十名份额的总和&＃xff0c;这是一家独大的态势。在这一市场格局下&＃xff0c;如果 AWS 提供的某项服务是优质的、技术领先的&＃xff0c;那么&＃xff0c;业界的技术标准就该向他看齐&＃xff0c;而 AWS DynamoDB 正好满足此条件。

如果为 DynamoDB 设计一套通用的 SQL 规格&＃xff0c;新兴云计算厂商推出的 no-sql 又是仿 DynamoDB 设计的&＃xff0c;我们退而求其次的 “可替换性设计目标” 就达到了。况且&＃xff0c;针对国内市场&＃xff0c;新兴厂商向老大看齐&＃xff0c;保持兼容性&＃xff0c;能从老大那里分流部分用户&＃xff0c;算是不错的市场策略。

2 已有 no-sql 数据库的 DSL 设计

为 no-sql 数据库套一层类 SQL 的 DSL 描述层在业界较常见&＃xff0c;像 Google 为他的 Cloud Datastore 加了一层 GQL 描述&＃xff0c;针对 DynamoDB 业界也有数个增设 SQL 层的开源项目。这里&＃xff0c;我先简单介绍这些 SQL-like 的规格特色。

Google 的 GQL 只提供 SELECT 查询&＃xff0c;只读不写&＃xff0c;我估计它之所以不支持记录更新&＃xff0c;是因为 Datastore 的字段读写已融入编程特性&＃xff0c;以对象化方式描述表、记录、字段&＃xff0c;写操作是直接的赋值语句&＃xff0c;上下文还融合了事务处理语句。所以&＃xff0c;让 GQL 支持数据库写操作反而会变得不方便。

给 DynamoDB 追加 SQL 的开源项目在 github 能找到五个以上&＃xff0c;做得较好有&＃xff1a;

• DynamoDb.SQL

• DQL

• dynamodb-sql

DynamoDb.SQL 基于 .Net 平台&＃xff0c;只供查询&＃xff0c;没支持 update、delete 等写操作&＃xff0c;DQL 基于 Python&＃xff0c;有查询&＃xff0c;也提供 insert、update、delete 等写操作&＃xff0c;甚至还提供 create table 操作。dynamodb-sql 基于 Javascript&＃xff0c;设计功能较全&＃xff0c;遗憾的是&＃xff0c;功能还没做完作者停止开发了。

这些项目总有一些缺陷&＃xff0c;尤其未注重 “通用性”设计&＃xff0c;在跨 DB 可移植方面考虑得较少。具体而言&＃xff0c;像 create table、descript table 这类跨越 DB 很难寻求一致设计的指令就不该去做&＃xff1b;还有一些专属特性&＃xff0c;应理解为“配置参数”&＃xff0c;而非表现为 SQL 语言规格&＃xff0c;做成语言规格就不容易跨 DB 获得普遍支持。

因为缺少现成的&＃xff0c;我们就自己动手新做了一个&＃xff0c;即 dynamo-sql&＃xff0c;用 Javascript 开发&＃xff0c;已在 github 上开源。

3 SQL 与 NO-SQL 的差异

SQL 作为一种领域专用语言(Domain Specific Language&＃xff0c;DSL)&＃xff0c;之所以在传统数据库上产生&＃xff0c;无非为了达到 “一致规格”与“简化应用”两个目的&＃xff0c;我们为 DynamoDB 设计 SQL 也同样基于这两个目的。但针对 no-sql 的 DSL 设计似乎更麻烦些&＃xff0c;因为你面对的是 “非结构化” 的数据表&＃xff0c;得针对传统数据库与 no-sql 数据库的关键差异&＃xff0c;有重点的去解决问题。

先来对比 SQL 与 no-sql 的差异&＃xff0c;我截一张图放给大家看看&＃xff1a;

SQL vs. NO-SQL

图中对比的是 Google 的两类数据库服务&＃xff0c;Datastore 是 no-sql&＃xff0c;Cloud SQL 是在云端开放的类似 MySQL 的传统 DB 系统。传统 SQL 在查询、事务处理、一致性方面占优&＃xff0c;而在横向伸展、易管理、Schema 变更方面不如 no-sql。

尽管 MySQL 为应对伸展扩容问题&＃xff0c;也发展出 “分片” 等技术&＃xff0c;但本质没变&＃xff0c;拿它去解决该用 no-sql 实现的系统&＃xff0c;就像破漏的船只&＃xff0c;无论怎么修补&＃xff0c;都无法从根上解决问题。

事实上&＃xff0c;在微服务框架体系里&＃xff0c;什么时候该用 SQL&＃xff0c;什么时候该用 no-sql&＃xff0c;划分标准还是很清晰的&＃xff0c;数据库如何选型也实际指导了微服务如何划分。一个产品如果没采用微服务架构&＃xff0c;SQL 与 no-sql 如何选型是个大问题&＃xff0c;而微服务框架下&＃xff0c;在两大 DB 之间如何选择就不该成问题。

要命的是&＃xff0c;某新兴公有云服务商还缺一个像样的 no-sql 系统&＃xff0c;手头只一把锤子&＃xff0c;于是尝试用传统那套东西解决所有问题&＃xff0c;既然都进军公有云了&＃xff0c;还陷在私有云思路里&＃xff0c;迟早会出问题的。

回到 no-sql 的本质&＃xff0c;我想&＃xff0c;抓住 “分级索引”特性是问题的关键。以 DynamoDB 为例&＃xff0c;有 “主键”&＃xff0c;没 “外键”&＃xff0c;主键又有 “分区键” 与 “排序键”&＃xff0c;分区键提供全局检索&＃xff0c;相当于有两层表格体系&＃xff1a;

• 解决某条记录的全局检索&＃xff0c;决定把它的内容保存到哪个分区中

• 指定分区中表格&＃xff0c;分区确定了&＃xff0c;在分区内建立的索引称为 “本地二级索引”&＃xff0c;即 LSI。如果单以主键还满足不了全局查询的需求&＃xff0c;那就再建 “全局二级索引”&＃xff0c;即 GSI。

由于索引方式差别巨大&＃xff0c;SQL 与 no-sql 在 DSL 表述时&＃xff0c;也表现出巨大差异。比如&＃xff0c;后者的 DSL 不再支持多索引联合查询&＃xff0c;也不支持 join 等复杂操作。不过&＃xff0c;no-sql 在查询的过滤条件&＃xff0c;update 前的判断条件等&＃xff0c;有更丰富支持。

4 不过度封装

AWS-SDK 的 DynamoDB 通过类似如下代码操作数据库&＃xff1a;

• 对于 GET 操作&＃xff0c;调用 dynamodb.getItem

• 对于 PUT 操作&＃xff0c;调用 dynamodb.putItem

其它操作&＃xff0c;如 SELECT、SCAN、UPDATE、DELETE 等都通过不同 API 调用实现&＃xff0c;各 API 规格一样&＃xff0c;都用 params 参数指明如何操作。所以&＃xff0c;我们封装的 SQL 语句&＃xff0c;经翻译&＃xff0c;都准确生成所需的 params 参数&＃xff0c;再由 AWS-SDK 最后实现数据库作业。

如何封装 SQL&＃xff1f;我们面临两种选择&＃xff1a;

• 简单处理&＃xff0c;近似于直译&＃xff0c;让 SQL 的能力与 AWS-SDK 提供的接口一一对应

• 提供 PaaS 级别的封装&＃xff0c;把易用性再提高一些

AWS 的 DynamoDB 按官方的提法&＃xff0c;是 IaaS 层面的服务&＃xff0c;与之可对照的是 Google 的 Datastore&＃xff0c;是 PaaS 服务。这两种 DB 除了规格特性不同之外&＃xff0c;所谓 IaaS 与 PaaS 的差别&＃xff0c;无非后者稍多一点封装而已&＃xff0c;实质差别并不大。

最终我们还是选择了简单直译的方式&＃xff0c;如果想多封装些&＃xff0c;也就下面几点可改进&＃xff1a;

• 追加事务处理

• 索引与排序做点优化

5 兼容 S3 Select 查询

AWS 新近推出 S3 Select 服务&＃xff0c;它用一种类似 SQL 的查询语句&＃xff0c;直接用一个命令提取 S3 文件&＃xff0c;一般是 CSV 数据表文件&＃xff0c;然后由 S3 实施查询&＃xff0c;只返回合乎条件的数据集&＃xff0c;而不是 CSV 整个文件的内容。这项服务可节约不少流量成本&＃xff0c;结合 S3 的静态网站功能显得比较有意义。

既然&＃xff0c;我们为 DynamoDB 封装了 SQL&＃xff0c;为什么不把这 SQL 规格延伸到 S3 呢&＃xff1f;让 DynamoDB 提供强服务 DB&＃xff0c;让 S3 提供弱服务 DB&＃xff0c;形成双级服务机制。

如下是查询 S3 文件 DB 的例子&＃xff1a;

与查询 DynamoDB 差别在于&＃xff0c;表名要有 "/" 分隔。此特性目前还没实现(语法分析已支持)&＃xff0c;留以后去做。

不多说了&＃xff0c;dynamo-sql 项目的代码量不大&＃xff0c;感兴趣的童鞋请读源码。

End.

作者&＃xff1a;程序强

来源&＃xff1a;简书

零基础入职数据分析就业班

课程的形式主要是“直播&＃43;录播”

报名专享&＃xff1a;课程项目作业&＃43;1v1班主任监督学习&＃43;爱数据学院学员专属网站&＃43;班级答疑群

课程结束后能熟练掌握SQL、Python、Excel、PPT等工具

适合人群&＃xff1a;

1.转行(岗位相关&＃xff0c;专业相关、对数据分析感兴趣)

2.从事数据分析工作&＃xff0c;但是需要提升技能以及增加实战经验

3.应届毕业生入职数据分析