rdbnosql笔试题的简单介绍
Python学哪个数据库
主流的关系型数据库：
成都创新互联公司长期为上千多家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为江门企业提供专业的成都网站设计、做网站，江门网站改版等技术服务。拥有十多年丰富建站经验和众多成功案例,为您定制开发。
1. MySQL：目前使用最广泛的开源、多平台的关系型数据库，支持事务、符合ACID、支持多数SQL规范。
2. SQL Server：支持事务、符合ACID、支持多数SQL规范，属于商业软件，需要注意版权和licence授权费用。
3. Oracle：支持事务，符合关系型数据库原理，符合ACID，支持多数SQL规范，功能最强大、最复杂、市场占比最高的商业数据库。
4. Postgresql：开源、多平台、关系型数据库，功能最强大的开源数据库，需要Python环境，基于postgresql的time
scaleDB，是目前比较火的时序数据库之一。
非关系型数据库：
非关系型数据库也被称为nosql，作为关系型数据库的一个补充，能在特定场景和特点问题下发挥高效率和高性能。
常见的非关系型数据库类型有键值存储数据库和面向文档数据库。
键值存储数据库类似hash，通过key做添加、删除、查询、性能高，优势在于简单、易部署、高并发，主要产品有：
Redis：开源、Linux平台、key-value键值型nosql数据库，简单稳定，非常主流的、全数据in-momory，定位于快的键值型nosql数据库。
Memcaced：一个开源的、高性能的、具有分布式内存对象的缓存系统，通过它可以减轻数据库负载，加速动态的web应用。
面向文档数据库以文档的形式存储，每个文档是一系列数据项的集合，每个数据项有名称与对应的值，主要产品有：
MongoDB：开源、多平台、文档型nosql数据库，最像关系型数据库，定位于灵活的nosql数据库。适用于网站后台数据库、小文件系统、日志分析系统。
关于软考中数据库系统工程师
数据库系统工程师级考试大纲
一、考试说明
1.考试要求
（1）掌握计算机体系结构以及各主要部件的性能和基本工作原理；
（2）掌握操作系统、程序设计语言的基础知识，了解编译程序的基本知识；
（3）熟练掌握常用数据结构和常用算法；
（4）熟悉软件工程和软件开发项目管理的基础知识；
（5）熟悉计算机网络的原理和技术；
（6）掌握数据库原理及基本理论；
（7）掌握常用的大型数据库管理系统的应用技术；
（8）掌握数据库应用系统的设计方法和开发过程；
（9）熟悉数据库系统的管理和维护方法，了解相关的安全技术；
（10）了解数据库发展趋势与新技术；
（11）掌握常用信息技术标准、安全性，以及有关法律、法规的基本知识；
（12）了解信息化、计算机应用的基础知识；
（13）正确阅读和理解计算机领域的英文资料。
2. 通过本考试的合格人员能参与应用信息系统的规划、设计、构建、运行和管理，能按照用户需求，设计、建立、运行、维护高质量的数据库和数据仓库；作为数据管理员管理信息系统中的数据资源，作为数据库管理员建立和维护核心数据库；担任数据库系统有关的技术支持，同时具备一定的网络结构设计及组网能力；具有工程师的实际工作能力和业务水平，能指导计算机技术与软件专业助理工程师（或技术员）工作。
3. 本考试设置的科目包括
（1）信息系统知识，考试时间为150分钟，笔试；
（2）数据库系统设计与管理，考试时间为150分钟，笔试。
二、考试范围
考试科目1：信息系统知识
1. 计算机系统知识
1.1 硬件知识
1.1.1 计算机体系结构和主要部件的基本工作原理
•CPU和存储器的组成、性能、基本工作原理
•常用I/O设备、通信设备的性能，以及基本工作原理
•I/O接口的功能、类型和特点
•CISC/RISC，流水线操作，多处理机，并行处理
1.1.2 存储系统
•虚拟存储器基本工作原理，多级存储体系
•RAID类型和特性
1.1.3 安全性、可靠性与系统性能评测基础知识
•诊断与容错
•系统可靠性分析评价
• 计算机系统性能评测方法
1.2 数据结构与算法
1.2.1 常用数据结构
•数组（静态数组、动态数组）
•线性表、链表（单向链表、双向链表、循环链表）
•栈和队列
•树（二叉树、查找树、平衡树、遍历树、堆）、图、集合的定义、存储和操作
•Hash（存储位置计算、碰撞处理）
1.2.2 常用算法
•排序算法、查找算法、数值计算、字符串处理、数据压缩算法、递归算法、图的相关算法
•算法与数据结构的关系，算法效率，算法设计，算法描述（流程图、伪代码、决策表），算法的复杂性
1.3 软件知识
1.3.1 操作系统知识
•操作系统的类型、特征、地位、内核（中断控制）、进程、线程概念
•处理机管理（状态转换、同步与互斥、信号灯、分时轮转、抢占、死锁）
•存储管理（主存保护、动态连接分配、分段、分页、虚存）
•设备管理（I/O控制、假脱机、磁盘调度）
•文件管理（文件目录、文件的结构和组织、存取方法、存取控制、恢复处理、共享和安全）
•作业管理（作业调度、作业控制语言（JCL）、多道程序设计）
•汉字处理，多媒体处理，人机界面
•网络操作系统和嵌入式操作系统基础知识
•操作系统的配置
1.3.2 程序设计语言和语言处理程序的知识
• 汇编、编译、解释系统的基础知识和基本工作原理
• 程序设计语言的基本成分：数据、运算、控制和传输，程序调用的实现机制
• 各类程序设计语言的主要特点和适用情况
1.4 计算机网络知识
•网络体系结构（网络拓扑、OSI/RM、基本的网络协议）
•传输介质，传输技术，传输方法，传输控制
•常用网络设备和各类通信设备
•Client/Server结构、Browser/Server结构、Browser/Web/Datebase结构
•LAN拓扑，存取控制，LAN的组网，LAN间连接，LAN-WAN连接
•因特网基础知识及应用
•网络软件
•网络管理
•网络性能分析
•网络有关的法律、法规
2. 数据库技术
2.1 数据库技术基础
2.1.1 数据库模型
•数据库系统的三级模式（概念模式、外模式、内模式），两级映像（概念模式/外模式、外模式/内模式）
•数据库模型：数据模型的组成要素，概念数据模型ER图（实体、属性、关系），逻辑数据模型（关系模型、层次模型、网络模型）
2.1.2 数据库管理系统的功能和特征
•主要功能（数据库定义、数据库操作、数据库控制、事务管理、用户视图）
•特征（确保数据独立性、数据库存取、同时执行过程、排它控制、故障恢复、安全性、完整性）
•RDB（关系数据库），OODB（面向对象数据库），ORDB（对象关系数据库），NDB（网状数据库）
•几种常用Web数据库的特点
2.1.3 数据库系统体系结构
• 集中式数据库系统
• Client/Server数据库系统
• 并行数据库系统
• 分布式数据库系统
• 对象关系数据库系统
2.2 数据操作
2.2.1 关系运算
•关系代数运算（并、交、差、笛卡儿积、选择、投影、连接、除）
•元组演算
•完整性约束
2.2.2 关系数据库标准语言（SQL）
•SQL的功能与特点
•用SQL进行数据定义（表、视图、索引、约束）
•用SQL进行数据操作（数据检索、数据插入/删除/更新、触发控制）
•安全性和授权
•程序中的API，嵌入SQL
2.3 数据库的控制功能
•数据库事务管理（ACID属性）
•数据库备份与恢复技术（UNDO、REDO）
•并发控制
2.4 数据库设计基础理论
2.4.1 关系数据库设计
•函数依赖
•规范化（第一范式、第二范式、第三范式、BC范式、第四范式、第五范式）
•模式分解及分解应遵循的原则
2.4.2 对象关系数据库设计
•嵌套关系、 复杂类型，继承与引用类型
•与复杂类型有关的查询
•SQL中的函数与过程
•对象关系
2.5 数据挖掘和数据仓库基础知识
•数据挖掘应用和分类
•关联规则、聚类
•数据仓库的成分
•数据仓库的模式
2.6 多媒体基本知识
2.6.1 多媒体技术基本概念
•多媒体系统基础知识
•常用多媒体文件格式
2.6.2 多媒体压缩编码技术
•多媒体压缩编码技术
•统计编码
•预测编码
•编码的国际标准
2.6.3多媒体技术应用
•简单图形的绘制，图像文件的处理方法
•音频和视频信息的应用
•多媒体应用开发过程
2.7 系统性能知识
•性能计算（响应时间、吞吐量、周转时间）
•性能指标和性能设计
•性能测试和性能评估
2.8 计算机应用基础知识
•信息管理、数据处理、辅助设计、科学计算，人工智能等基础知识
•远程通信服务及相关通信协议基础知识
3. 系统开发和运行维护知识
3.1 软件工程、软件过程改进和软件开发项目管理知识
•软件工程知识
•软件开发生命周期阶段目标和任务
•软件开发项目基础知识（时间管理、成本管理、质量管理、人力资源管理、风险管理等）及其常用管理工具
•主要的软件开发方法（生命周期法、原型法、面向对象法、CASE）
•软件开发工具与环境知识
•软件质量管理基础知识
•软件过程改进基础知识
•软件开发过程评估、软件能力成熟度评估的基础知识
3.2 系统分析基础知识
•系统分析的目的和任务
•结构化分析方法（数据流图（DFD）和数据字典（DD），实体关系图（ERD），描述加工处理的结构化语言）
•统一建模语言（UML）
•系统规格说明书
3.3 系统设计知识
•系统设计的目的和任务
•结构化设计方法和工具（系统流程图、HIPO图、控制流程图）
•系统总体结构设计（总体布局，设计原则，模块结构设计，数据存取设计，系统配置方案）
•系统详细设计（代码设计、数据库设计、用户界面设计、处理过程设计）
•系统设计说明书
3.4 系统实施知识
•系统实施的主要任务
•结构化程序设计、面向对象程序设计、可视化程序设计
•程序设计语言的选择、程序设计风格
•系统测试的目的、类型，系统测试方法（黑盒测试、白盒测试、灰盒测试）
•测试设计和管理（错误曲线、错误排除、收敛、注入故障、测试试用例设计、系统测试报告）
•系统转换基础知识
3.5 系统运行和维护知识
•系统运行管理知识
•系统维护知识
•系统评价知识
4. 安全性知识
•安全性基本概念（网络安全、操作系统安全、数据库安全）
•计算机病毒的防治，计算机犯罪的防范，容灾
•访问控制、防闯入、安全管理措施
•加密与解密机制
•风险分析、风险类型、抗风险措施和内部控制
5.标准化知识
•标准化意识，标准化的发展，标准出台过程
•国际标准、国家标准、行业标准、企业标准基本知识
•代码标准、文件格式标准、安全标准软件开发规范和文档标准
•标准化机构
6.信息化基础知识
•信息化意识
•全球信息化趋势、国家信息化战略、企业信息化战略和策略
•有关的法律、法规
•远程教育、电子商务、电子政务等基础知识
•企业信息资源管理基础知识
7.计算机专业英语
•掌握计算机技术的基本词汇
•能正确阅读和理解计算机领域的英文资料
考试科目2：数据库系统设计与管理
1.数据库设计
1.1理解系统需求说明
•了解用户需求、确定系统范围
•确定应用系统数据库的各种关系
•现有环境与新系统环境的关系
•新系统中的数据项、数据字典、数据流
1.2 系统开发的准备
•选择开发方法，准备开发环境，制订开发计划
1.3 设计系统功能
•选择系统机构，设计各子系统的功能和接口，设计安全性策略、需求和实现方法，制定详细的工作流和数据流
1.4 数据库设计
1.4.1 设计数据模型
•概念结构设计（设计ER模型）
•逻辑结构设计（转换成DBMS所能接收的数据模型）
•评审设计
1.4.2 物理结构设计
•设计方法与内容
•存取方法的选择
•评审设计与性能预测
1.4.3 数据库实施与维护
•数据加载与应用程序调试
•数据库试运行
•数据库运行与维护
1.4.4 数据库的保护
•数据库的备份与恢复
•数据库的安全性
•数据库的完整性
•数据库的并发控制
1.5 编写外部设计文档
•编写系统说明书（系统配置图、各子系统关系图、系统流程图，系统功能说明、输入输出规格说明、数据规格说明、用户手册框架）
•设计系统测试要求
1.6 设计评审
2. 数据库应用系统设计
2.1 设计数据库应用系统结构
•信息系统的架构（如Client/Server）与DBMS
•多用户数据库环境（文件服务器体系结构、Client/Server体系结构）
•大规模数据库和并行计算机体系结构（SMP、MPP）
•中间件角色和相关工具
•按构件分解，确定构件功能规格以及构件之间的接口
2.2 设计输入输出
•屏幕界面设计，设计输入输出检查方法和检查信息
•数据库交互与连接（掌握C程序设计语言，以及Java、Visual Basic、Visual C＋＋、PowerBuilder、Delphi中任一种开发工具与数据库互连的方法（如何与数据库服务器沟通））
2.3 设计物理数据
•分析事务在数据库上运行的频率和性能要求，确定逻辑数据组织方式、存储介质，设计索引结构和处理方式
•将逻辑数据结构变换成物理数据结构，计算容量（空间代价），确定存取方法（时间效率）、系统配置（维护代价）并进行优化
2.4 设计安全体系
•明确安全等级
•数据库的登录方式
•数据库访问
•许可（对象许可、命令许可、授权许可的方法）
2.5 应用程序开发
2.5.1 应用程序开发
•选择应用程序开发平台
•系统实施顺序
•框架开发
•基础小组的程序开发
•源代码控制
•版本控制
2.5.2 模块划分（原则、方法、标准）
2.5.3 编写程序设计文档
•模块规格说明书（功能和接口说明、程序处理逻辑的描述、输入输出数据格式的描述）
•测试要求说明书（测试类型和目标，测试用例，测试方法）
2.5.4 程序设计评审
2.6 编写应用系统设计文档
•系统配置说明、构件划分图、构件间的接口、构件处理说明、屏幕设计文档、报表设计文档、程序设计文档、文件设计文档、数据库设计文档
2.7 设计评审
3. 数据库应用系统实施
3.1 整个系统的配置与管理
3.2 常用数据库管理系统的应用（SQL Server、Oracle、Sybase、DB2、Access或Visual Foxpro）
•创建数据库
•创建表、创建索引、创建视图、创建约束、创建UDDT（用户自定义类型）
•创建和管理触发器
•建立安全体系
3.3 数据库应用系统安装
•拟定系统安装计划（考虑费用、客户关系、雇员关系、后勤关系和风险等因素）
•拟定人力资源使用计划（组织机构安排的合理性）
•直接安装（安装新系统并使系统快速进入运行状态）
•并行安装（新旧系统并行运行一段时间）
•阶段安装（经过一系列的步骤和阶段使新系统各部分逐步投入运行）
3.4 数据库应用系统测试
•拟定测试目标、计划、方法与步骤
•数据加载，准备测试数据
•指导应用程序员进行模块测试进行验收
•准备系统集成测试环境测试工具
•写出数据库运行测试报告
3.5 培训与用户支持
4.数据库系统的运行和管理
4.1 数据库系统的运行计划
•运行策略的确定
•确定数据库系统报警对象和报警方式
•数据库系统的管理计划（执行，故障/恢复，安全性，完整性，用户培训和维护）
4.2 数据库系统的运行和维护
•新旧系统的转换
•收集和分析报警数据（执行报警、故障报警、安全报警）
•连续稳定的运行
•数据库维护（数据库重构、安全视图的评价和验证、文档维护）
•数据库系统的运行统计（收集、分析、提出改进措施）
•关于运行标准和标准改进一致性的建议
•数据库系统的审计
4.3 数据库管理
•数据字典和数据仓库的管理
•数据完整性维护和管理（实体完整性、参照完整性）
•数据库物理结构的管理（保证数据不推迟访问）
•数据库空间及碎片管理
•备份和恢复（顺序、日志（审计痕迹）、检查点）
•死锁管理（集中式、分布式）
•并发控制（可串行性、锁机制、时间戳、优化）
•数据安全性管理（加密、安全、访问控制、视图、有效性确认规则）
•数据库管理员（DBA）职责
4.4 性能调整
•SQL语句的编码检验
•表设计的评价
•索引的改进
•物理分配的改进
•设备增强
•数据库性能优化
4.5 用户支持
•用户培训
•售后服务
5. SQL
5.1 数据库语言
•数据库语言的要素
•数据库语言的使用方式（交互式和嵌入式）
5.2 SQL概述
•SQL语句的特征
•SQL语句的基本成分
5.3 数据库定义
•创建数据库（Create Datebase）、创建表（Create Table）
•定义数据完整性
•修改表（Alter Table）、删除表（Drop Table）
•定义索引（Create Index）、删除索引（Drop Index）
•定义视图（Create View）、删除视图（Drop View）、更新视图
5.4 数据操作
•Select语句的基本机构
•简单查询
•SQL中的选择、投影
•字符串比较，涉及空值的比较
•日期时间，布尔值，输出排序
•多表查询
•避免属性歧义
•SQL中的连接、并、交、差
•SQL中的元组变量
•子查询
5.5 完整性控制与安全机制
•主键（Primary Key）约束
•外键（Foreign Key）约束
•属性值上的约束（Null、Check、Create Domain）
•全局约束（Create Assertions）
•权限、授权（Grant）、销权（Revoke）
5.6 创建触发器（Create Trigger）
5.7 SQL使用方式
•交互式SQL
•嵌入式SQL
•SQL与宿主语言接口（Declare、共享变量、游标、卷游标）
•动态SQL
•API
5.8 SQL 标准化
6. 网络环境下的数据库
6.1 分布式数据库
6.1.1 分布式数据库的概念
•分布式数据库的特点与目标
6.1.2 分布式数据库的体系结构
•分布式数据库的模式结构
•数据分布的策略（数据分片、分布透明性）
•分布式数据库管理系统
6.1.3 分布式查询处理和优化
6.1.4 分布式事务管理
•分布式数据库的恢复（故障、恢复、2段提交、3段提交）
•分布式数据库的透明性（局部、分裂、复制、处理、并发、执行）
6.1.5 分布式数据库系统的应用
6.2 网络环境下数据库系统的设计与实施
•数据的分布设计
•负载均衡设计
•数据库互连技术
6.3 面向Web的DBMS技术
•三层体系结构
•动态Web网页
•ASP、JSP、XML的应用
7.数据库的安全性
7.1 安全性策略的理解
•数据库视图的安全性策略
•数据的安全级别（最重要的、重要的、注意、选择）
7.2 数据库安全测量
•用户访问控制（采用口令等）
•程序访问控制（包含在程序中的SQL命令限制）
•表的访问控制（视图机制）
•控制访问的函数和操作
•外部存储数据的加密与解密
8. 数据库发展趋势与新技术
8.1 面向对象数据库（OODBMS）
8.1.1 OODBMS的特征
8.1.2 面向对象数据模型
•对象结构、对象类、继承与多重继承、对象标识、对象包含、对象嵌套
8.1.3 面向对象数据库语言
8.1.4 对象关系数据库系统（ORDBMS）
•嵌套关系
•复杂类型
•继承、引用类型
•与复杂类型有关的查询
•函数与过程
•面向对象与对象关系
•ORDBMS应用领域
8.2 企业资源计划（ERP）和数据库
8.2.1 ERP概述
•基本MRP（制造资源计划）、闭环MRP、ERP
•基本原理、发展趋势
•ERP设计的总体思路（一个中心、两类业务、三条干线）
8.2.2 ERP与数据库
•运行数据库与ERP数据模型之间的关系
•运行数据库与ERP数据库之间的关系
8.2.3 案例分析
8.3 决策支持系统的建立
•决策支持系统的概念
•数据仓库设计
•数据转移技术
•联机分析处理（OLAP）技术
•企业决策支持解决方案
•联机事务处理（OLTP）
零基础学Python应该学习哪些入门知识
关于零基础怎么样能快速学好Python的问题，百度提问和解答的都很多，你可以百度下看看。我觉得从个人自学的角度出发，应从以下几个方面来理解：
1 为什么选择学python？
据统计零基础或非专业的人士学python的比较多，据HackerRank开发者调查报告2018年5月显示（见图），Python排名第一，成为最受欢迎编程语言。Python以优雅、简洁著称，入行门槛低，可以从事Linux运维、Python Web网站工程师、Python自动化测试、数据分析、人工智能等职位，薪资待遇呈上涨趋势。
2 入门python需要那些准备？
2.1 心态准备。编程是一门技术，也可说是一门手艺。如同书法、绘画、乐器、雕刻等，技艺纯熟的背后肯定付出了长时间的反复练习。不要相信几周速成，也不能急于求成。编程的世界浩瀚无边，所以请保持一颗敬畏的心态去学习，认真对待写下的每一行代码，甚至每一个字符。收拾好自己的心态，向着编程的世界出发。第一步至关重要，关系到初学者从入门到精通还是从入门到放弃。选一条合适的入门道路，并坚持走下去。
2.2 配置 Python 学习环境。选Python2 还是 Python3？入门时很多人都会纠结。二者只是程序不兼容，思想上并无大差别，语法变动也并不多。选择任何一个入手，都没有大影响。如果你仍然无法抉择，那请选择 Python3，毕竟这是未来的趋势。
编辑器该如何选？同样，推荐 pycharm 社区版，配置简单、功能强大、使用起来省时省心，对初学者友好，并且完全免费！其他编辑器如：notepad++、sublimeText 3、vim 和 Emacs等不推荐了。
操作环境？Python 支持现有所有主流操作平台，不管是 windows 还是 mac 还是 linux，都能很好的运行 Python。并且后两者都默认自带 Python 环境。
2.3 选择自学的书籍。我推荐的书的内容由浅入深，建议按照先后顺序阅读学习：
2.3.1《Python简明教程》。这是一本言简意赅的 Python 入门教程，简单直白，没有废话。就算没有基础，你也可以像读小说一样，花两天时间就可以读完。适合入门快速了解语法。
2.3.2 廖雪峰编写的《Python教程》。廖先生的教程涵盖了 Python 知识的方方面面，内容更加系统，有一定深度，有一定基础之后学习会有更多的收获。
2.4 学会安装包。Python中有很多扩展包，想要安装这些包可以采用两种方法：
2.4.1 使用pip或easy_install。
1)在网上找到的需要的包，下载下来。eg. rsa-3.1.4.tar.gz;
2)解压缩该文件;
3)命令行工具cd切换到所要安装的包的目录，找到setup.py文件，然后输入python setup.py install
2.4.2 不用pip或easy_install,直接打开cmd，敲pip install rsa。
3 提升阶段需要恒心和耐力。
完成入门阶段的基础学习之后，常会陷入一个瓶颈期，通过看教程很难进一步提高编程水平。这时候，需要的是反复练习，大量的练习。可以从书上的例题、作业题开始写，再写小程序片段，然后写完整的项目。我们收集了一些练习题和网站。可根据自己阶段，选择适合的练习去做。建议最好挑选一两个系列重点完成，而不是浅尝辄止。
3.1 多做练习。推荐网站练习：
crossin编程教室实例：相对于编程教室基础练习着重于单一知识点，
编程实例训练对基础知识的融会贯通；
hackerrank：Python 部分难度循序渐进，符合学习曲线
实验楼：提升编程水平从做项目开始；
codewar：社区型编程练习网站，内容由易到难；
leetcode：为编程面试准备，对初学者稍难；
牛客网：提供 BAT 等大厂笔试题目；
codecombat：提供一边游戏一边编程；
projecteuler：纯粹的编程练习网站；
菜鸟教程100例：基于 py2 的基础练习；
3.2 遇到问题多交流。
3.2.1 利用好搜索引擎。
3.2.2 求助于各大网站。推荐
stackoverflow：这是一个程序员的知识库；
v2ex：国内非常不错的编程社区，不仅仅是包含程序，也包含了程序员的生活；
segmentfault：一家以编程问答为主的网站;
CSDN、知乎、简书等
3.2.3 加入相关的QQ、微信群、百度知道。不懂的可以随时请教。
HTAP需求不能被HTAP数据库解决
HTAP（Hybrid Transaction and Analytical Process，混合事务和分析处理）自 2014 年明确提出以后成为了很多数据库厂商努力的方向。其实 HATP 并不新鲜，早年 RDB 刚兴起时本来就是用一个数据库同时做事务和分析，但随着数据规模不断变大再直接基于业务库做分析就会影响业务，这时数据仓库出现了，将业务数据导入数据仓库来专门应对分析需求，同时与业务库隔离，这样不仅可以更好地服务分析场景，又不会对业务系统产生影响，这是“合久必分”的阶段。但是由于数据仓库将 历史 数据与实时数据分开了，有时经常还会采用异构数据库（或大数据平台），如果要分析实时全量数据（T+0）就非常困难了，而 T+0 又是很多及时性业务必须的，这就造成了“数据仓库之殇”。为了解决这个问题，能不能把 AP 和 TP 在一个数据库内同时满足呢？于是 HTAP 再次登场了，这又到了“分久必合”的阶段。
但我们知道，AP 和 TP 两个场景有显著不同，前者涉及的数据量很大，并且计算逻辑复杂，但并发量往往不大，没有数据一致性要求，甚至经常为了使用方便可以不满足范式；后者恰恰相反，数据量不大且数据处理逻辑简单，但并发量很大，有数据强一致性要求。从功能上讲，TP 数据库本来就能执行 SQL，也本来就具有一定的 AP 功能。当初之所以要把 TP 和 AP 分开，就是因为巨大数据量时，继续采用偏向 TP 的技术就不能高效地处理 AP 的需求（比如 AP 要求高性能需要使用列存，但 TP 为了写入更新便利需要使用行存），TP 和 AP 的这些巨大差异就决定了这两个场景不能采用一个技术体系来同时满足，而这件事到现在并没有实质性地改变。
即使如此，还是有一些厂商尝试在同一引擎中同时满足 TP 和 AP 的需求，实现上有几种方式。一种是采用多副本的方式，其中某一个副本（可能使用列存）专门用来满足 AP 的需求；一种是采用行列混合存储，行存和列存各一份，二者之间自动转换；还有一种方式可以不区分行列存储，通过单一存储引擎支撑 TP 和 AP 场景，常见的是某些内存数据库。这类 HTAP 数据库在实现上会优先满足 TP 的需要，在此基础上再发展 AP 的功能，因此在满足 AP 需求时相对一般专用的 AP 产品往往会有很大差距。
另一种 HTAP 数据库的做法是在底层仍然将两个场景分离，以“模块化”的方式来设计存储，业务数据产生后就会被复制两份（不考虑副本的情况），一份仍然使用行存用于交易，一份复制使用列存用于分析。相应的存储和计算再借助原本在 TP 和 AP 领域已经成熟的技术进行封装和优化，同时设计统一的对外访问接口，底层的差异对应用层完全透明，这样就形成了可用的 HTAP 产品。
无论采用哪种方式设计 HTAP 数据库，在应用时都会碰到一个问题，如果原来的业务数据库不是（大概率）采用 HTAP 数据库就要涉及数据库迁移，这将面临巨大的风险和成本。不仅要考量数据类型差异导致的数据结构迁移过程中需要进行改造和处理，还会涉及视图、存储过程以及复杂 SQL 的改造等，还有在迁移工程中遇到的种种问题要解决，可谓坑多且深。由此带来的业务影响可能会带来极大价值损耗。
此外，现代业务系统不仅涉及 RDB，还有 MongoDB、InfluxDB 等 NoSQL，以及各种自己封装的业务数据源，种类很多五花八门。这些数据源要迁移到新数据库就没那么简单了，像 MongoDB 数据转存到 RDB 会发现实现很困难。MongoDB 中的很多数据类型和集合之间的关系在 RDB 中并不存在，比如嵌入式的数据结构、数组和哈希等集合类型、多对多关系的实现。这些问题并不是简单通过数据迁移就能解决的，需要在迁移之前先对部分数据结构进行重构，这需要事先投入相当多的人工和时间成本去梳理业务并设计目标数据组织方式。即使最后花费很大代价把业务数据源迁移到 HTAP 上，原来那些多样性数据源自身的优势却又丧失了，得失之间有时甚至很难权衡是否值得。
我们知道，数据计算性能和数据组织密不可分，在 AP 类场景中通常要使用列存来发挥计算优势，但只有列存是远远不够的，有些复杂计算需要针对计算特点专门设计数据存储形式（比如有序存储、数据类型转换、预计算等）。而这些对性能要求高的复杂计算在 AP 类场景中并不少见，但无论采用何种方式的 HTAP，简单“自动化”地行存转列存并不能实现相对“个性化”的效果，性能往往无法达标。这个道理也很简单，天下没有什么都好的事儿，你想融合就必须容忍在某一或某些方面的不足。
迁移风险大、成本高、有损失、性能还可能不达标，考虑到这些问题，我们不禁会问：HTAP 数据库这个技术路线对吗？
说到这里我们再回头看一下 HTAP 的目的，为什么要用 HTAP？
其实就是为了进行全量数据实时查询统计，也就是 T+0！
如果数据仓库等相关技术能搞定这个问题，那自然也就不需要 HTAP 了。不过很遗憾，数据仓库仍然延用了关系数据库的封闭体系，数据要先入库才能计算，而且入库又有较强约束。这些导致数据仓库无法很好实现跨数据源尤其是异构和非关系型数据源的混合计算，很难实现 T+0 的目标。
但集算器 SPL 可以。
集算器 SPL（Structured Process Language），一个专门面向结构化数据计算的 开源 计算引擎和程序语言。除了提供了丰富的计算类库使其拥有不依赖数据库的独立计算能力外，SPL 可以对接多种数据源并完成多源混合计算，从而轻松完成跨数据源的 T+0 查询。
SPL 通过与现有系统融合的方式实现 HTAP，这样原有系统的改动很小，TP 部分几乎不动，甚至原有的 AP 数据源也可以继续工作，逐步使用 SPL 接管 AP 业务。SPL 部分或全部接管 AP 业务后， 历史 冷数据使用 SPL 高性能文件存储，原来针对业务库到数据仓库的 ETL 过程可以直接移植到 SPL 上。冷数据量大且不再变化使用 SPL 高性能文件存储可以获得更高地计算性能；热数据量小仍然存放在原有 TP 数据源中，SPL 直接读取计算，由于热数据量并不大，直接基于 TP 数据源查询也不会对其造成太大影响，访问时间也不会太长。再利用 SPL 的冷热数据混合计算能力，就可以获得针对全量数据的 T+0 实时查询。我们只要定期将变冷的数据固化到 SPL 的高性能存储中，原数据源只需要保持少量近期新产生的热数据即可。这样不仅实现了 HTAP，而且还是高性能的 HTAP，且对应用架构冲击很小。
现代信息系统中建设数据仓库等专门服务分析场景已然十分常见，加之数据源种类繁多，将这些数据都迁移到一处代价太大了，对于这点前文我们已经分析过。如果能在现有架构的基础上增加跨数据源的实时混合计算能力，就相当于插上了 HTAP 的翅膀，在不改变现有架构的情况下快速实现 HTAP 的需求，而这正是 SPL 的强项。
SPL 支持多种数据源，RDB、NoSQL 以及 RESTful 等都可以直接使用，还可以解析 JSON/XML 等类型数据，可以对接 Elasticsearch、Kafka 等数据源，此外传统 / 新兴数据仓库、大数据平台等也可以直接取数计算。
在对接的同时可以针对任意多种数据源进行混合计算，这样实时数据从生产库中读与取自 历史 库 / 数据仓库 / 大数据平台的冷数据混合计算就可以实现 T+0 全量实时数据查询。这样原有应用架构几乎不用变动（尤其是生产库）就可以获得 HTAP（架构层面）期望的效果，成本极低。
使用 SPL 在现有架构上输出 HTAP 能力还有一个好处是可以充分保留原有数据源的优势。NoSQL 仍然可以继续使用而不必强行将结构拉成 RDB 的形式，自己封装的数据访问与交互接口也不必费心去迁就新数据库，原来的优势与个性化仍然保持，风险很低的同时价值几乎没有损耗。
在分析侧也一样，基于 SPL 也可以继续使用原本建设好的分析平台。但如前所述，分析场景面临的数据量大且计算逻辑复杂，尤其需要高性能。SPL 还提供了高性能计算机制，可以全面接管原来分析侧（AP）的业务实现高性能数据计算。
我们知道，高性能计算涉及两方面，一个是数据组织方式即数据存储，另一个是算法，这二者密不可分，很多高性能算法需要将数据组织成相应格式（如有序）才能发挥作用。SPL 提供了自有的高性能存储机制，直接采用文件系统。将数据存储特定格式的文件中，不仅可以获得更高的 IO 存取效率以及文件系统灵活的管理能力，还可以充分利用自有格式的列存、有序、压缩、并行分段等数据存储优势，从而高效地发挥高性能算法效力。
而在算法方面，SPL 提供了十分丰富的高性能算法库。遍历复用、有序归并、外键预关联、标签位维度、并行计算等，都已经封装好，可以直接使用，配合 SPL 的存储机制就能获得高性能。而且这其中有很多算法都是 SPL 独创的，在业内也是首次提出。
如果简单地将 TP 中的行存转换成 SPL 中的列存，工作量也非常低。但为了获得高性能，常常还需要精心设计存储方式，这时，将会有一定量的 ETL 动作，但这个工作与原来从业务系统 ETL 数据到数据仓库基本是一样的，并不会更复杂，而且这个工作对于高性能是少不了的。和一般 HTAP 数据库很难实施经过有效设计的存储相比，SPL 将冷热数据分离后可以从容不迫地像以前 TP/AP 分离时那样实施更高效的存储组织，这样更能将 TP 和 AP 双边的性能发挥到极致。相对大幅的性能提升，数据组织的工作往往是值得的。
在实战中，使用 SPL 存储和算法提升数倍数十倍性能的案例很多。比如在某保险公司车险保单跑批的案例（ 开源 SPL 优化保险公司跑批优从 2 小时到 17 分钟 ）中，使用 SPL 将计算时间从 2 小时缩短到 17 分钟。这里使用 SPL 接管存储后再利用 SPL 特有的遍历复用技术（在对大数据的一次遍历过程中实现多种运算）有效地减少外了存访问量，同时将涉及对一个大表进行三次关联和汇总的运算只需要遍历一次（SQL 要将大表遍历三次），并在关联运算上采用了不同的算法，因此获得了巨大的性能提升。
还有在 开源 SPL 将银行手机账户查询的预先关联变成实时关联 的案例中，使用 SPL 将原本只能预关联的手机账户查询变成实时关联，同时服务器数量从 6 台降为 1 台。这里充分利用了 SPL 的有序存储机制，一次性读取整个账户数据时可以有效减少硬盘时间（物理存储连续），再借助区分维表和事实表的外键实时关联技术使用单机就能完成实时关联查询，性能提升明显，硬件需求也降低了许多。
基于 SPL 的 HTAP，并不止于 T+0 和高性能。
数据计算（主要指 OLAP 场景）一向有两个难点，跑得慢（性能）和写得简单（开发效率）。前者我们说过了，后者使用 SPL 还可以获得很大改善。
现在我们处理数据还主要基于 SQL（其他高级语言太麻烦），但 SQL 仍然有很多不好描述的运算，这个原因主要是 SQL 的理论限制，这里我们不多说，感兴趣的小伙伴可以阅读这篇文章： 写着简单跑得又快的数据库语言 SPL
鉴于 SQL 在复杂计算方面的描述能力（开发效率）太差，SPL 并没有沿用 SQL 体系，而是基于新的理论重新设计了一套敏捷计算语法，基于这个语法再实施计算尤其复杂计算会更有优势，写法也更简单。
我们可以通过电商系统中常见的漏斗运算来感受一下 SPL 的简洁性。
SQL（oracle）实现：
SPL 实现：
oracle 的 SQL 写出来要三十多行，理解起来有相当的难度。而且这段代码和漏斗的步骤数量相关，每增加一步数就要再增加一段子查询。这种 SQL，写出来就已经不易，性能优化更是无从谈起。
相比之下，SPL 就简单得多，处理任意步骤数都是这段代码。
好了，说到这里各位看官应该了解了，SPL 并不是一个 HTAP 数据库，而是提供了一种新思路来满足 HTAP 的需要。HTAP 数据库很热，厂商的宣传口号很容易让我们陷入只能使用一种数据库来解决 HTAP 问题的藩篱而不自知。但只要我们再多想一点就会发现，HTAP 是一种合理的业务需求，满足它或许并不需要一种新数据库，而是能够解决问题的新技术和架构，而 SPL 提供了这种可能。
SPL下载地址：
SPL开源地址：
网站栏目：rdbnosql笔试题的简单介绍
URL分享：http://myzitong.com/article/dsegsij.html