下载文档原格式
数据库服务器选型原则及实例解说数据库服务器选型原则及实例解说数据库服务器作为业务系统的核心，具有业务量大、存储数据量大等特点。
它承担着业务数据的存储和处理任务，因此关键数据库服务器的选择就显得尤为重要。
服务器的可靠性和可用性是首要的需求，其次是数据处理能力和安全性，然后是可扩展性和可管理性。
根据应用类型和规模的不同，数据库对于服务器的性能要求也不一样。
如对于大型数据库(ERP, OLTP, data mart)来说，服务器往往仅用来运行数据库，或仅运行单一的应用。
数据库的容量在1TB以上，需要有较高的CPU处理能力，大容量内存为数据缓存服务，并需要很好的IO性能，使用这类应用时，通常需要有较高的CPU主频。
那么，具体到某个行业甚至某个项目，数据库服务器该如何选择呢?数据库服务器选型五个原则首先，数据库服务器选型应该遵循以下几个原则：1)高性能原则保证所选购的服务器，不仅能够满足运营系统的运行和业务处理的需要，而且能够满足一定时期的业务量增长的需要。
一般可以根据经验公式计算出所需的服务器TpmC值，然后比较各服务器厂商和TPC组织公布的TpmC值，选择相应的机型。
同时，用服务器的市场价/报价除去计算出来的TpmC值得出单位TpmC 值的价格，进而选择高性能价格比的服务器。
2)可靠性原则可靠性原则是所有选择设备和系统中首要考虑的，尤其是在大型的、有大量处理要求的、需要长期运行的系统。
考虑服务器系统的可靠性，不仅要考虑服务器单个节点的可靠性或稳定性，而且要考虑服务器与相关辅助系统之间连接的整体可靠性，如：网络系统、安全系统、远程打印系统等。
在必要时，还应考虑对关键服务器采用集群技术，如：双机热备份或集群并行访问技术，甚至采用可能的完全容错机。
比如，要保证系统(硬件和操作系统)在99.98%的时间内都能够正常运作(包括维修时间)，则故障停机时间六个月不得超过0.5个小时。
服务器需7×24小时连续运行，因而要求其具有很高的安全可靠性。
数据库的选型⽬录影响数据库选择的因素数据量：是否海量数据，单表数据量太⼤会考验数据库的性能数据结构：结构化 (每条记录的结构都⼀样) 还是⾮结构化的 (不同记录的结构可以不⼀样)是否宽表：⼀条记录是 10 个域，还是成百上千个域数据属性：是基本数据 (⽐如⽤户信息)、业务数据 (⽐如⽤户⾏为)、辅助数据 (⽐如⽇志)、缓存数据是否要求事务性：⼀个事务由多个操作组成，必须全部成功或全部回滚，不允许部分成功实时性：对写延迟，或读延迟有没有要求，⽐如有的业务允许写延迟⾼但要求读延迟低查询量：⽐如有的业务要求查询⼤量记录的少数列，有的要求查询少数记录的所有列排序要求：⽐如有的业务是针对时间序列操作的可靠性要求：对数据丢失的容忍度⼀致性要求：是否要求读到的⼀定是最新写⼊的数据对增删查改的要求：有的业务要能快速的对单条数据做增删查改 (⽐如⽤户信息)，有的要求批量导⼊，有的不需要修改删除单条记录(⽐如⽇志、⽤户⾏为)，有的要求检索少量数据 (⽐如⽇志)，有的要求快速读取⼤量数据 (⽐如展⽰报表)，有的要求⼤量读取并计算数据 (⽐如分析⽤户⾏为)是否需要⽀持多表操作不同的业务对数据库有不同的要求SQL 数据库 & NoSQL 数据库SQL 数据库就是传统的关系型数据库⾏列式表存储结构化数据需要预定义数据类型数据量和查询量都不⼤，如果数据量⼤要做分表对数据⼀致性、完整性约束、事务性、可靠性要求⽐较⾼⽀持多表 Join 操作⽀持多表间的完整性，要删除 A 表的某条数据，可能需要先删除 B 表的某些数据SQL 的增删改查功能强较为通⽤，技术⽐较成熟⼤数据量性能不⾜⾼并发性能不⾜⽆法应⽤于⾮结构化数据扩展困难常⽤的 SQL 数据库⽐如 Oracle、MySQL、PostgreSQL、SQLiteNoSQL 泛指⾮关系型数据库表结构较灵活，⽐如列存储，键值对存储，⽂档存储，图形存储⽀持⾮结构化数据有的不需要预定义数据类型，有的甚⾄不需要预定义表⽀持⼤数据量多数都⽀持分布式扩展性好基本查询能⼒，⾼并发能⼒⽐较强 (因为采⽤⾮结构化、分布式，并牺牲⼀致性、完整性、事务性等功能)对数据⼀致性要求⽐较低通常不⽀持事务性，或是有限⽀持通常不⽀持完整性，复杂业务场景⽀持较差通常不⽀持多表 Join，或是有限⽀持⾮ SQL 查询语⾔，或类 SQL 查询语⾔，但功能都⽐较弱，有的甚⾄不⽀持修改删除数据不是很通⽤，技术多样，市场变化⽐较⼤常⽤的 NoSQL 数据库⽐如列式：HBase、Cassandra、ClickHouse键值：Redis、Memcached⽂档：MongoDB时序：InfluxDB、Prometheus搜索：ElasticsearchSQL 和 NoSQL 是⼀个互补的关系，应⽤在不同的场景中OLTP & OLAPOLTP (On-Line Transaction Processing)主要做实时事务处理⽐如处理⽤户基本信息、处理订单合同、处理银⾏转账业务、企业的 ERP 系统和 OA 系统，等等频繁地，对少量数据，甚⾄是单条数据，做实时的增删改查数据库经常更新通常对规范化、实时性、稳定性、事务性、⼀致性、完整性等有要求操作较为固定，⽐如订单业务，可能永远就那⼏个固定的操作数据库主要模型是 3NF 或 BCNF 模型OLAP (On-Line Analytical Processing)数据仓库，主要做历史数据分析，为商业决策提供⽀持⽐如对⼤量的⽤户⾏为做分析，对设备的状态、使⽤率、性能做分析频率较低地，对⼤量数据，做读取、聚合、计算、分析，实时性要求不⾼，对吞吐能⼒要求较⾼通常列的数量⽐较多，但每次分析的时候只取少部分列的数据通常是批量导⼊数据通常数据导⼊后不会修改，主要是读取操作，写少读多通常对规范化、事务性、⼀致性、完整性等要求较低，甚⾄⼀个查询操作失败了也不会有什么影响操作较为灵活，⽐如⼀个海量⽤户⾏为数据表，可以想出许多不同的⽅法，从不同的⾓度对⽤户做分析数据库主要是星型、雪花模型不使⽤⾼性能的 OLAP 之前，更传统的做法是通过离线业务构建 T+1 的离线数据，⽐较滞后OLTP 通常⽤传统的关系数据库，如果数据量⼤要分表，对事务性、⼀致性、完整性等要求不⾼的话也可以⽤ NoSQLOLAP 通常⽤ NoSQL，数据量不⼤的话也可以⽤传统的关系数据库关系型数据库 Oracle、SQL Server、MySQL、PostgreSQL、SQLiteOracle：甲⾻⽂开发的商业数据库，不开源，⽀持所有主流平台，性能好，功能强，稳定性好，安全性好，⽀持⼤数据量，⽐较复杂，收费昂贵SQL Server：微软开发的商业数据库，只能在 Windows 运⾏MySQL：甲⾻⽂拥有的开源数据库，⽀持多种操作系统，体积⼩，功能弱些，简单的操作性能好，复杂的操作性能差些PostgreSQL：使⽤ BSD 协议的完全开源免费的项⽬，⽀持多种操作系统，功能更强⼤，可以和多种开源⼯具配合SQLite：开源、轻型、⽆服务器、零配置，⼀个数据库就只是⼀个⽂件，在应⽤程序内执⾏操作，占⽤资源⼩，可⽤于嵌⼊式或⼩型应⽤Oracle 多⽤于银⾏等⾼要求的领域，要求不⾼的⽐如互联⽹⾏业多⽤ MySQL 和 PostgreSQL，⽽ SQLite ⽤于嵌⼊式或作为应⽤程序内的数据库使⽤，SQL Server ⽤于 Window 服务器HBase (宽表、列式存储、键值对存储、NoSQL、OLTP)基于 Hadoop 的 HDFS 分布式⽂件系统分布式数据库，需要 ZooKeeper 作为节点间的协调器⽀持宽表，⽀持⾮结构化数据，不需要预定义列和数据类型列式存储，每个 HFile ⽂件只存储⼀个列族的数据，⼀个列族可以有多个 HFile，⽽ HFile 内部按 Key-Value 格式存储，其中 Key 是rowkey, column family, column, timestamp 的组合并且按 rowkey 在 HFile 中按序存储，⽽ value 就是 Column Cell 的值⽀持海量数据 (千亿级数据表)数据先写⼊内存，达到阀值再写⼊磁盘，性能好，占⽤内存⼤不⽀持 SQL，不⽀持 Join，有⾃⼰专⽤的语句，⽀持增删改查⾃动分区、负载均衡、可线性扩展⾃动故障迁移强⼀致性 (每个分区 Region 只由⼀个 Region Server 负责，容易实现强⼀致性)CP 模型 (不保证可⽤性，每个 Region 只由⼀个 Region Server 负责，Server 挂了得做迁移导致暂时不可⽤)不⽀持事务、⼆级索引组件⽐较多，⽐较重，适⽤于已有的 Hadoop 平台，适⽤于海量宽表数据、需要增删改查、OLTP 的场景Phoenix (基于 HBase 的数据库引擎、关系型、OLTP)嵌⼊到 HBase 的 Region Server 的数据库引擎⽀持 SQL⽀持 Join⽀持事务 (需要在定义表的时候配置)⽀持⼆级索引⽀持撒盐⽀持 JDBC⽤于强化 HBase，主要作为 OLTP，查询性能要求不⾼的话也可作为 OLAP，多⽤于 HDP (HDP 有集成 Phoenix)Cassandra (宽表、键值对存储、NoSQL、OLTP)⽆单点故障：Cassandra 节点按环形排列，没有中⼼节点，每个节点独⽴互联地扮演相同⾓⾊，每个节点都可以接受读写请求，数据可以有多个副本存储在多个节点，节点之间通过 Gossip (P2P) 协议交换状态信息，集群中有若⼲节点配为种⼦节点，⽤于新加⼊的节点获取集群拓扑结构并启动 Gossip 协议提供类 SQL 语⾔ CQL适合结构化、⾮结构化数据Table 需要定义 Partition Key、Clustering Key、以及普通列，其中 Partition Key ⽤于分区和排序，即按照 Partition Key 的 Hash Token 决定了数据被分配到哪个节点，并且在节点内也是按该 Hash Token 按序存储的，有相同 Partition Key 的数据会存在⼀起，并且按照 Clustering Key 排序存储，有点类似于 HBase 的 RowKey、ColumnFamily、Column，不过 HBase 是相同 CF 存⼀起，内部再按 RowKey 排序存储，再取 Column 值 (Column 值不排序)，⽽ Cassandra 是先按 Partition Key 的 Token 排序存储，内部再按Clustering 排序存储，再取普通 Column 的值 (Column 值不排序)⾼度可扩展，允许添加硬件、节点以提⾼数据容量，同时保持快速的响应时间通过 Consistency 命令可以配置⼀致性级别，主要是通知客户端操作前，必须确保的 replica 的成功数量Cassandra 采⽤的是最终⼀致性，是 CAP 理论⾥的 APCassandra 不⽀持 Join 和⼦查询主要⽤于 OLTP，要求不⾼的话也可以作为 OLAP 使⽤，和 HBase ⽐需要的组件⽐较少，维护⽐较容易Redis (基于内存的 Key-Value 的 NoSQL 数据库，OLTP)由 C 语⾔编写⽀持多种数据类型如 strings，hashes，lists，sets，sorted sets，bitmaps，hyperloglogs，geospatial 等操作原⼦性，保证了两个客户端同时访问服务器将获得更新后的值数据存储在内存中可以配置持久化，周期性的把更新数据写⼊磁盘，或周期性地把修改操作写⼊追加记录⽂件，也可以关闭持久化功能，将 Redis 作为⼀个⾼效的⽹络缓存数据功能使⽤⽀持主从同步，数据可以从主服务器向任意数量的从服务器同步，从服务器可以是关联其他从服务器的主服务器，这使得 Redis 可执⾏单层树复制，存盘可以有意⽆意的对数据进⾏写操作，由于完全实现了发布/订阅机制，使得从数据库在任何地⽅同步树时，可订阅⼀个频道并接收主服务器完整的消息发布记录，同步对读取操作的可扩展性和数据冗余很有帮助⽀持消息的发布/订阅（Pub/Sub）模式单线程模式，即⽹络 IO、数据读写，都由⼀个线程完成，正因为如此保证了原⼦性、稳定性、代码容易维护，之所以单线程不影响性能，是因为数据都在内存，操作本来就⾼效，当然这⾥的单线程指⽹络 IO、数据读写这个主功能，实际上还有其他线程，⽐如周期性写⼊硬盘的线程⾼版本在⽹络 IO 这块使⽤了多线程 (因为在⾼并发操作时，⽹络 IO 成为了瓶颈)，但读写操作还是单线程 (操作内存数据性能还是⾮常⾼的，能应付⾼并发场景)通常作为⾼性能内存数据库、缓存、消息中间件等使⽤memcached (基于内存的 Key-Value 的 NoSQL 数据库，OLTP)开源、⾼性能、分布式的基于内存的 Key-Value 数据存储，作⽤类似于 Redis存储 String/RawData，不定义数据结构 (Redis 有 hash、list、set 等多种结构)数据通常由 key，flags，expire time，bytes，value 组成服务端基本上只能简单的读写数据，服务端能⽀持的操作⽐较少包含 Server 组件和 Client 组件，可以有多个 server 但 server 之间是独⽴的，没有同步⼴播等机制，需要选择哪个 server 由 client 的API 决定的数据只在内存，不会落到硬盘没有安全机制协议简单性能⾼效memcached ⽐较简单，作为纯粹的 Key-Value 缓存性能会⽐ Redis 好些，但功能没有 Redis 强⼤MongoDB (⽂档数据库，NoSQL，OLTP)之所以说是⽂档数据库，是因为它的数据是以 JSON ⽂档的形式存储MongoDB 的概念和很多数据库不⼀样，它的 collection 相当于表，document 相当于⾏，field 相当于列⽐如er.insert({"name": "Lin","age": 30"address": {"street": "Zhongshan Road","city": "Guangzhou","zip": 510000},"hobbies": ["surfing", "coding"]})这是⼀条插⼊语句，这⾥的 db 是指当前数据库，user 就是 collection 相当于表，insert 语句⾥⾯的 JSON 就是 document 相当于其他数据库的⾏，name，age，street 这些就是 field 相当于列相同的⽂档可以插⼊多次⽽不会被覆盖，实际上 mongodb 会⾃动创建 _id 字段作为 primary key，并分配不同的数值，所以不会重复，也可以 insert 的时候指定 _id，但如果 _id 已经存在则会报错可以看到，mongodb 是⾮结构化数据，不需要预定义 collection，也不需要预定义数据结构提供丰富的查询表达式⽀持⼆级索引，⾃动负载平衡，读效率⽐写⾼⽀持分布式、⽀持故障恢复、数据冗余、分⽚、⽔平扩展可以配置存储引擎，WiredTiger Storage Engine (默认) 会做内存到⽂件的映射以提⾼性能，但内存消耗⼤，In-Memory Storage Engine (企业版⽀持) 只存在内存，不会落盘⾼版本⽀持 Join，⽀持事务⽀持安全认证功能提供扩展，⽐如实现可视化的⼯具，实现 BI 集成的⼯具mongodb 更适⽤于⾼度⾮结构化，或者源数据就是 JSON，每条数据⽐较⼤，以 OLTP 为主的场景，不适合于事务要求⽐较⾼，或⽐较复杂的⼤数据量的查询的场景，另外由于 mongodb 的语法和其他数据库差异⽐较⼤，需要⼀定的学习成本Hive (基于 HDFS 的数据库引擎、关系型、OLAP)Hive 是基于 Hadoop 的⼀个数据仓库⼯具数据存储在 HDFS，创建表的时候要通过 STORED AS 命令指定存储格式⽐如 TEXTFILE、ORCFILE、PARQUET，也可以通过STORED BY 命令指定为 HBase，可以创建新表也可以创建已有 HBase 表的映射查询通过 MapReduce、Spark 等作业完成提供了类 SQL 查询语⾔ HQL (HiveQL)，⽀持⽤户定义函数 (UDF)⾼版本⽀持事务 (需要创建表时指定)⽀持海量数据结构化数据⽀持增删改查不适合于 OLTP，主要作为 OLAP ⽤于⼤数据批量查询使⽤，需要有 Hadoop 平台Impala (基于 HDFS、HBase、Kudu 存储，并⾏计算，关系型，OLAP)Cloudera 开发的基于内存的分布式并⾏计算的数据库查询引擎主要由 C++ 实现，和 Hadoop 的交互使⽤ JNIImpala 使⽤和 Hive ⼀样的 metadata、SQL、ODBC driver、UI，这样在提⾼了 HDFS 的 SQL 查询性能的同时，⼜提供了相似的⽤户使⽤体验和 Hive ⼀样可以通过 STORED AS 指定 HDFS 的存储格式⽐如 TEXTFILE、ORCFILE、PARQUET通过 Hive 操作的表，需要⼿动同步到 ImpalaImpala 不仅 SQL 和 Hive ⼀样，实际上元数据也存在 Hive 中表数据除了 HDFS，也可以存储到 HBase，但需要在 HBase 建表，然后在 Hive 通过 STORED BY 建⽴映射表，由于 Impala 和 Hive 使⽤⼀样的 metadata，在 Hive 建好表后，只要在 Impala 执⾏刷新命令 INVALIDATE METADATA，就可以看到对应的 HBase 表⽀持 Join、Aggregate 等功能⽀持 JDBC、ODBC和 Hive 不同，Impala 不依赖于 MapReduce，⽽是在每个 HDFS DataNode 上运⾏⾃⼰的引擎实现并⾏处理Impala 的并⾏处理引擎主要由 state store、catalog service、多个 impala daemon 组成每个 impala daemon 都可以接收 client 的请求，impala daemon 由 query planner、query coordinator、query executor 组成，planner 接收 client 的 SQL 查询，然后分解为多个⼦查询，由 coordinator 将⼦查询分发到各个 daemon 的 executor 执⾏，daemon 获取HDFS、HBase 数据、计算、然后返回给 coordinator，然后由 coordinator 聚合后将最终结果返回给 clientImpala 是⽆中⼼结构，每个 daemon 都可以接受连接查询，可以通过 HA Proxy 实现多个 daemon 的负载均衡state store ⽤于收集监控各个 daemon 的状态catalog service 将 SQL 做出的元数据变化通知给集群中所有的 impala daemonImpala 的计算都在内存进⾏，对内存要求⽐较⾼Impala 在 2.8 以后才⽀持 update 操作，但是只限于 Kudu 存储，需要安装 Kudu，并通过 STORED AS 指定 Kudu 作为数据库的存储，Kudu 是 Cloudera 开发的列式存储管理器，⽬的是做 OLAP，并且平衡 HDFS 和 HBase 的性能，Kude 的随机读写性能⽐HDFS（⽐如 Parquet）好，但是⽐ HBase 差，⽽⼤数据量查询性能⽐ HDFS（⽐如 Parquet）差，但⽐ HBase 好，Kude 和 Impala ⾼度集成，也可以和 MapReduce/Spark 集成，⽤ Kudu 替换 HDFS/HBase 这样 Impala 就可以做 update，兼顾 OLAP 和改数据的需求，适合于以 OLAP 为主⼜有⼀定的 Update 需求的场景，Kudu 可以配置⼀致性，采⽤结构化表数据模型，需要定义主键，不使⽤HDFS ⽽是有⾃⼰的组件存储和管理数据, 采⽤ c++ 没有 full gc 风险Impala 不适合于 OLTP，主要作为 OLAP ⽤于⼤数据批量查询使⽤需要有 Hadoop 平台和 Hive性能⽐ Hive 好很多作为 OLAP 的性能⽐ Phoenix 之类的好主要是 CDH 在推，CDH 有集成 ImpalaPresto (基于多种数据源，并⾏计算，关系型，OLAP)Facebook 推出的基于内存的分布式并⾏计算的数据库查询引擎由 coordinator server、discovery server (通常集成在 coordinator ⾥，也可以独⽴)、多个 worker server 组成coordinator 负责与 client 交互，负责管理 worker，负责解析 statement、规划 query、创建⼀系列的 stage、再转换成⼀系列的 task 分发到不同 worker 并发执⾏worker 负责执⾏ task 和处理数据，会通过 connector 获取数据，和其他 worker 交互中间数据，最终结果会由 coordinator 返回给clientconnector 是适配器，使得 Presto 可以访问不同的数据库内建的 connector 主要是 Hive，此外有很多三⽅开发的 connector ⽐如 cassandra、es、kafka、kudu、redis、mysql、postgresql 等等需要在配置⽂件配置 catalog，这⾥ catalog 维护 schema 并通过 connector 指向⼀个数据源，定位 presto 表都是从 catalog 开始的，⽐如 hive.test_data.test 指的是 hive catalog 下的 test_data schema 下⾯的 test 表，⽽ schema 的概念则依赖于具体的 connector，⽐如对于 mysql ⽽⾔，presto 的 schema 就是 mysql 的 schema，⽽对于 cassandra ⽽⾔，presto 的 schema 就是 cassandra 的keyspace，可以建⽴多个 catalog 关联同⼀个 connector ⽐如环境⾥有多个 kafka 集群那可以有 kafka1 和 kafka2 两个 catalog statement 可以认为就是 presto 收到的 sql 语句，然后会解析成 query plan，然后 query ⼜被分为多个 stages，这些 stages 组成⼀个树的结构，每个 stage 会聚合计算它下⾯的其他 stages 的结果，每个 stage ⼜分为⼀个或多个 tasks，这些 task 会分发到不同的worker 并⾏执⾏，每个 task 处理不同的数据分⽚，每个 task ⼜有⼀个或多个 driver 并发处理数据Presto ⽀持 JDBC 接⼝，JDBC 的 URL 格式为 jdbc:presto://host:port/catalog/schema 或 jdbc:presto://host:port/catalog 或jdbc:presto://host:port⽀持 Join 查询，并且⽀持多数据源的 join 查询 (多张⼤表的 join 可能会影响性能)，跨数据源查询的时候需要指定完整的表名即[catalog].[schema].[table]，并且使⽤ presto://host:port 连接 JDBC，不指定 catalog 和 schema有限⽀持⼦查询不⽀持 update 操作⽀持安全机制⽀持标准的 ANSI SQL扩展性好可以和 Tableau 集成⽀持 Spark适合有多种数据源的⼤数据量的 OLAP 查询性能和 Impala 可能差不多，但⽀持多种数据源，不依赖 HadoopGreenplum (基于多个 PostgreSQL，并⾏计算，关系型，OLAP)基于多个 PostgreSQL 的分布式并⾏计算的数据库查询引擎内部的 PostgreSQL 有做改动以适应并⾏分布式计算主要由⼀个 master、多个 segments、⼀个 interconnect 组成master 维护元数据，接收并认证 client 的链接，接收 SQL 请求，解析 SQL，⽣成 query plan，并将任务分发到 segments，协调聚合segments 的返回结果，并将最终结果返回给 client，可以设置 master 为主从配置每个 segment 有个独⽴的 PostgreSQL 数据库，每个 segment 负责存储部分数据，并执⾏相应的查询计算，segment 也可以配置备份机制Interconnect 是 Greenplum 的⽹络层，负责 master 和 segment 的链接，以及各个 segment 之间的链接链接和 SQL 语法都和 PostgreSQL 兼容，⽀持 JDBC、ODBC创建表时可以指定是⽤列存储、⾏存储、外部表 (数据在其他系统⽐如 HDFS ⽽ GP 只存储元数据)操作外部数据，需要安装 PXF (Platform Extension Framework)，有了 PXF 可以⽀持 Hive、HBase、Parquet、S3、MySQL、ORACLE 等等⽀持安全、权限配置⽀持分布式事务，⽀持 ACID，保证数据的强⼀致性，不是使⽤锁，⽽是使⽤ MVCC (Multi-Version Concurrency Control) 来保证数据⼀致性shared-nothing 架构和 Impala、Presto 类似都是并⾏内存计算，但 Greenplum 性能可能稍差⼀点点，并且 Greenplum 还分开源版和商业版，有的功能只有商业版才⽀持Kylin (基于 Hive、HBase，并⾏计算，关系型，多维度、预计算 OLAP)传统 OLAP 根据数据存储⽅式的不同分为 ROLAP（Relational OLAP）以及 MOLAP（Multi-Dimension OLAP），ROLAP 以关系模型的⽅式存储数据，优点在于体积⼩，查询⽅式灵活，缺点是每次查询都需要对数据进⾏聚合计算，⽽ Kylin 属于 MOLAPKylin 将数据按维度的不同组合，提前计算好结果，形成 Cube (⽴⽅体) 结构，这样查询速度快，缺点是数据量不容易控制，N 个维度可以有 2**N 种组合，可能会出现维度爆炸的问题，⽽且数据有改动的话需要重新计算⽐如有 Phone 和 Country 两张维度表，以及 Sale 事实表 (明细表)，取⼿机品牌、国家、⽇期作为三个维度，有 (null)、(品牌)、(国家)、(⽇期)、(品牌、国家)、(品牌、⽇期)、(国家、⽇期)、(品牌、国家、⽇期) 共 8 种组合，可以提前计算好这 8 种 group by 组合的 sale 的各种汇总信息 (sum、count 等)，⼀个维度组合的⼀个汇总信息称为⼀个 cuboid，所有的 cuboid 合起来就被称为⼀个 CubeKylin 的数据源可以是 Hive 或 Kafka (Json 格式消息，key 就是列名)Kylin 的预计算结果存到 HBase，RowKey 就是各种维度的组合，相应的明细汇总存在 Column 中，这样 SQL 就变成对 RowKey 的扫描，并进⼀步的对 Column 计算 (如果需要的话)，这样查询性能⾃然就提升了，可以⽀持亚秒级查询Kylin ⽀持 ODBC，JDBC，RESTful API 等接⼝Kylin 可以和 Tableau、PowerBI 等 BI ⼯具集成使⽤步骤如下创建 Project同步 Hive 表或 Kafka 表创建 Data Model创建并命名 Model选择 Fact Table (事实表) 和 Lookup Table (查找表，主要是维度信息)，以及 Join 字段从 Fact Table 和 Lookup Table 中挑选维度列 (可以被 Cube 做 group by)从 Fact Table 选择指标列 (可以被 Cube 做 aggregation)从 Fact Table 选择⽤于⽇期分区的列，不需要就留空添加 Filter (可以被 Cube ⽤来做 Where 操作)创建 Cube创建并命名 Cube，并选择要关联的 Data Model添加维度列 (必须从 Data Model 配置的维度列中选择)添加指标列 (必须从 Data Model 配置的指标列中选择)共有 8 种 aggregation 操作可以配置给指标列：SUM, MAX, MIN, COUNT, COUNT_DISTINCT, TOP_N,EXTENDED_COLUMN and PERCENTILE (如果要查 avg 实际上就是⽤ sum 除以 count 得出，所以这⾥不需要配置 avg 等可以通过预计算结果进⼀步计算出的操作)build Cube，实际是通过 MapReduce/Spark 计算，任务完成后结果会写⼊ HBasebuild 成功后即可直接⽤ SQL 查询了，实际是根据维度查 RowKey，然后把 Column 存的聚合结果取出，如果必要的话再做进⼀步计算如果数据源有改动，需要重新 build Cube可以看到 Kylin 是⼀个纯粹的 OLAP ⼯具，通过预计算提升查询性能，但⽆法及时反应出数据源的改变，预计算可能很耗时并且可能会占⽤⼤量空间，且需要和 Hadoop 集成基于预计算的 OLAP 数据查询引擎还有 DruidClickHouse (列存储，向量化计算，并⾏计算，OLAP)俄罗斯企业 Yandex 开发的 OLAP 数据库列存储对于 OLAP 的好处由于 OLAP 经常是在⼤量数据列中检索少量列，如果采⽤⾏存储，意味着要逐⾏扫描，并且每⾏都很⼤，⽽采⽤列存储只需要扫描要检索的列，能减少 IO假设有的记录并没有存储要检索的列，⾏存储依然要扫描该记录才知道，⽽对于列存储则不存在这样的问题，因为没存储，⾃热⽽然就不会扫描到因为同⼀列的数据类型、⼤⼩⽐较⼀致，列存储更容易压缩，效率更⾼，进⼀步减少 IOIO 的减少还意味着有更多数据可以被缓存到内存向量化计算SIMD (Single Instruction，Multiple Data，单指令流多数据流)，现在的 CPU ⽀持这样的功能，通过⼀条指令即可利⽤多核对⼀组数据 (也就是向量) 进⾏ CPU 层⾯的并发计算，适⽤于纯基础计算的场景，如果有判断、跳转、分⽀的场景则不合适ClickHouse 有⼀个向量计算引擎，尽可能地使⽤ SMID 指令，批量并⾏地处理数据，⼤⼤提升了处理能⼒主要由 C++ 实现⽆中⼼化结构，由⼀个集群的 server 组成，并且每个 server 都可以接受客户端的链接查询，server 收到请求后会和其他 server 协调做并⾏计算，每个 server 都是多线程的，server 之间通过 ZooKeeper 协调同步⽀持分⽚（shard），数据可以跨节点存储在不同分⽚中，⼀个分⽚就是⼀个节点，或者多个节点组成⼀个有副本备份的分⽚，由配置⽂件配置⽀持分区，通过 Partition By 命令创建表分⽚和分区有时候不好区分，分⽚更多指的是表的数据分布在不同节点，⽽且⼀个节点可以存储多个数据库、多个表的数据，⽽分区更多指的是按某列数据将⼀个⼤表分成多个⼩表，⽐如按⽇期列分区，每天⼀个分区表，既可以查分区表，也可以查⼤表⽀持副本备份、⽀持数据完整性表引擎（Table Engine）创建表的时候要通过 Engine 命令指定要⽤的表引擎，决定如何存储数据最常⽤的是 MergeTree 系列引擎，⽐如ENGINE = MergeTree()ENGINE = AggregatingMergeTree()⽐较轻量级的 Log 系列引擎ENGINE = Log;ENGINE = TinyLog;允许从其他数据源查询，⽐如ENGINE = ODBC(connection_settings, external_database, external_table)ENGINE = JDBC(dbms_uri, external_database, external_table)ENGINE = MySQL('host:port', 'database', 'table', 'user', 'password')ENGINE = PostgreSQL('host:port', 'database', 'table', 'user', 'password')ENGINE = MongoDB(host:port, database, collection, user, password)ENGINE = HDFS(URI, format)ENGINE = Kafka() SETTINGS kafka_broker_list = 'host:port', kafka_topic_list = 'topic1'特殊类型，⽐如ENGINE = Memory 数据存在内存分布式在某个 server 创建的表只是该 server 的本地表，不是分布式的，如果要创建分布式表，需要在每个 server 创建相同名字的表，再在其中⼀台 server 上创建分布式表（会⾃动在所有 server 上都创建），这个分布式表是个逻辑表，不真正存储数据，⽽是映射到各个 server 的本地表，会⾃动做并⾏计算ENGINE = Distributed(cluster_name, database, table, [sharding_key])cluster_name 是在配置⽂件⾥配置的通常使⽤ MergeTree 存储，数据可以快速地按序 append 到⼀颗 MergeTree 的后⾯，后台会做合并和压缩操作，这样提升了数据插⼊的性能主索引，数据按 Primary Key 排序也可以在创建表时通过 Order By 指定排序的字段⽀持⼆级索引，也叫跳数索引 data skipping index，⽐如 minmax 索引，会统计每⼀段数据内某列数据（或是某个表达式）的最⼤值和最⼩值，检索的时候可以依据 minmax 决定是否跳过这段数据（感觉⽐较怪，性能应该⽐重建⼀张索引表的做法要差吧）⽀持 TTL，包括列级别、⾏级别、分区级别的 TTL⽀持 HTTP、TCP 接⼝⽀持 JDBC、ODBC有三⽅⼯具⽀持将其他数据库如 PG 的数据导⼊ ClickHouse有三⽅⼯具⽀持和⼀些可视化⼯具如 Grafana、DBeaver、Tabix 集成有三⽅⼯具⽀持 Kafka、Flink、Spark 等⽀持 SQL，⽀持 group by、order by、join、部分⼦查询等功能⽀持 array、json、tuple、set 等复杂数据类型⽀持近似计算，⽐如计算平均值，可以取部分数据计算，这样提升了性能，但降低了准度⾃适应 Join 算法，⽐如优先使⽤ Hash-Join，如果有多张⼤表则⾃动改⽤ Merge-Join安全机制、基于 Role 的权限控制⽀持错误恢复、扩展性好不⾜的地⽅对⾼并发的⽀持不⾜没有成熟的事务功能修改、删除数据的性能⽐较差，并且仅提供有限⽀持Primary Key 是采⽤稀疏索引，即索引只能指向⼀段数据，具体的数据还得⼀条条查，所以如果是查少量数据，或者查询单条数据，性能会⽐较差不依赖 Hadoop、列存储、向量化、并⾏、多线程、多存储引擎单表查询性能极好，⽐ Impala、Presto 之类的要好很多多表查询性能差些，⽐ Impala、Presto 之类的要差Elasticsearch (倒索引、分词、搜索引擎)Elastic Stack 是⼀组组件包括 Elasticsearch、Logstash、Filebeat、Kibana 等Elasticsearch 是基于 Apache Lucene 开发的搜索引擎，主要由 Java 开发Elasticsearch 集群主要由 master、data、ingest、coordinating 节点组成每个节点可以同时配置多种⾓⾊，⽐如即是 master ⼜是 data，但在⼤型集群中，通常每个节点只负担⼀种功能coordinating 是每个节点都会有的功能，不需要配置，即⽆论 master 还是 data 都会有 coordinating 功能，⽤于接收 client 的读写请求，然后将请求转发给相应节点处理，然后将处理结果合并后返回给 client，在⼤型集群中为了不对 master/data 等节点造成太⼤压⼒，可以配置多个专门的 coordinating，通过将 role 配置为空或是将 master、data、ingest 设置为 false (取决于不同版本) 即可，这样这些 coordinating 节点就只负责接收响应 client 请求不做其他⼯作，就像是⼀个反向代理的负载均衡⼀样，能提⾼并发性能master 负责管理整个集群，负责对 index 的创建删除等管理操作，决定数据要分⽚到哪个节点，管理其他节点的状态等等，可以配置多个 master 做 HA，需要单数个，⾄少要 3 个，系统实际上⾃动选举其中⼀个做 master，如果该 master 挂了，会从其他配置为master 的节点中重新选举⼀个，master 的配置可以低⼀些data 负责存储、计算、处理数据，对资源要求⽐较⾼，data 还可以进⼀步配置，指定节点⽤于存储 hot data、warm data、cold data 等等。
《数据库设计》ppt课件目录•数据库设计概述•需求分析•概念结构设计•逻辑结构设计•物理结构设计•数据库实施与维护•案例分析与实战演练01数据库设计概述数据库设计定义与重要性定义数据库设计是指根据用户需求，运用数据库技术，设计数据库结构、建立数据库及其应用系统的过程。
重要性数据库设计是信息系统开发过程中的重要环节，直接影响系统的性能、可扩展性、可维护性等。
01目标02满足用户需求03保证数据的完整性、一致性和安全性提高数据的共享性和利用率降低数据冗余度，提高数据独立性用户参与原则让用户参与数据库设计全过程，确保设计满足用户需求。
综合性原则综合考虑数据结构、数据操作、数据完整性、安全性等多方面因素。
标准化原则遵循国际、国家和行业标准，提高设计的通用性和可移植性。
优化原则在满足用户需求的前提下，优化数据库性能，提高系统效率。
流程1.需求分析2.概念结构设计1 2 33. 逻辑结构设计4. 物理结构设计5. 数据库实施•数据库运行和维护步骤1.收集和分析用户需求，确定系统功能和性能要求。
2.选择合适的数据模型，设计概念结构，形成概念模式。
02030401 3. 将概念模式转换为逻辑模式，进行逻辑优化。
4. 选择物理存储结构，设计物理模式，进行物理优化。
5. 用DDL 定义数据库结构，组织数据入库，编制与调试应用程序。
6. 试运行数据库系统，进行性能和安全测试，对系统进行评估和调整。
02需求分析需求收集与整理与用户沟通了解用户的业务需求、数据需求和处理需求。
收集资料从现有系统、文档、报表等资料中收集相关信息。
整理需求将收集到的需求进行分类、归纳和整理，形成规范化的需求描述。
数据流图与数据字典数据流图用图形化方式描述系统中数据的流动和处理过程，包括外部实体、数据流、数据存储和处理过程等元素。
数据字典对数据流图中出现的所有元素进行定义和描述，包括数据项、数据结构、数据流、数据存储、处理逻辑和外部实体等。
需求分析评审与确认需求分析评审组织专家和用户代表对需求分析结果进行评审，检查需求描述的完整性、准确性和一致性。
