精华内容
下载资源
问答
  • 交易型数据库系统的设计应符合第三范式,如若不然将...分析型数据库的设计使用反范式会带来哪些好处? 交易型数据库主体遵循三范式,特殊场景使用反范式 当前内容版权归码字科技所有并授权显示,盗版必究。阅读原文
  • 其他非度量的属性,有2种典型的:事物标识码事物时间。 · 事物标识码举例:哪些产品在相同的交易事务中被出售 · 这种事物标识码的分析一般称为“购物篮数据分析”,也叫做“关联规则挖掘”/“关联性分组” ...

    每个星型模式中都包含一个与日期信息相关的维度。

     

    在一个典型的设计良好的星形模式中,任何维度表中的记录数都小于事实表中的纪录数。

     

    创建代理主码 —— 可以处理所谓的缓慢变化的维度。

     

    事实表 = 将表连接到维度表的外码 + 分析主题相关的度量 + (其他非度量的属性)

    其他非度量的属性,有2种典型的:事物标识码事物时间

    · 事物标识码举例:哪些产品在相同的交易事务中被出售

    · 这种事物标识码的分析一般称为“购物篮数据分析”,也叫做“关联规则挖掘”/“关联性分组”

    · 让事实表包含事物标识码的过程,叫做“退化维度”

     

    有多个事实表的维度模型,又称为星座/星系

     

    事实表分为2中,细节事实表and聚集事实表

     

    事实表的粒度刻画的是事实表中每一行描述的信息。因此,细节事实表具有较好的粒度。但粗糙粒度聚集的事实表查询起来更快。我们可以让两种表并存于同一星座模型中。

     

    细节事实表又可以分为条目级细节事实表事务级细节事实表

    · 条目级细节事实表:每行表示一个事务中的一个条目行

    · 事务级细节事实表:每行表示一个事务

     

    缓慢变化维度 —— 包含可变属性的维度。处理方法:Type1,Type2,Type3.

    · Type1: 最简单的,常用于维度中由于错误而造成的属性值变化

                  简单改变 - 用新值取代旧值(不保存历史信息)

    · Type2: 常用于需要保留历史信息的情况

                  使用新值为代理码创建一个额外的维度记录(产生新的代理码!也就是新的一!)

                  Type2是最常用的处理缓慢变化维度的办法,可以直接处理维度属性改变较多的情况

                  Type2通常与时间戳and行指示符(指示该行是否是current)结合使用

    · Type3: 可用于如下情况:

                  (1)维度中每列可能发生改变的数量确定

                  (2)只对有限历史进行记录

                  Type3会为维度中每个发生改变的列创建一个“历史值”列以及一个“当前值列”(via 添加),Type3也可以和时间戳结合。

     

    n/a 指的是 not applicable。

     

    其他维度建模:雪花模型、立方体。

     

    展开全文
  • 本文是分布式数据库的总纲文章的第一部分,主要探讨分析性分布式数据库的发展技术差异;第二部分则是交易数据库的一些关键特性分析。Ivan开始计划的分布式数据库是不含分析场景的,所以严格来说本篇算是番外篇,...

    写在前面

    本文是分布式数据库的总纲文章的第一部分,主要探讨分析性分布式数据库的发展和技术差异;第二部分则是交易性数据库的一些关键特性分析。Ivan开始计划的分布式数据库是不含分析场景的,所以严格来说本篇算是番外篇,后续待条件具备将以独立主题的方式展开。

    特别说明:本文是原创文章,首发在DBAplus社群,转载须获得作者同意。


    正文

    随着大规模互联网应用的广泛出现,分布式数据库成为近两年的一个热门话题。同样,在银行业主推X86限制主机与小型机的背景下,传统的单机数据库逐渐出现了一些瓶颈,马上会面临是否引入分布式数据库的问题。

    近期,Ivan在个人公众号就“银行引入分布式数据库的必要性”做过一些展望,并收到了一些朋友的反馈,除了对分布式数据库具体技术探讨外,还有一类很有趣的建议,“能不能也讲讲Teradata、Greenplum这类MPP,这些也是分布式数据库,但老板总是认为OLTP场景下的才算数”。

    的确,为了解决OLAP场景需求,其实很早就出现了分布式架构的产品和解决方案,其与目前的OLTP方案有很多共通的地方。而且Ivan相信,今后OLAP和OLTP两个分支技术的发展也必然是交错前行,可以相互借鉴的。

    鉴于此,本文会将OLAP类场景的分布式数据也纳入进来,从两个维度对“分布式数据库”进行拆解,第一部分会横向谈谈不同的“分布式数据库”,把它们分为五类并对其中OLAP场景的三类做概要分析;第二部分结合NoSQL与NewSQL的差异,纵向来谈谈OLTP场景“分布式数据库”实现方案的关键技术要点,是前文的延伸,也是分布式数据库专题文章的一个总纲,其中的要点也都会单独撰文阐述。

    首先,Ivan们从横向谈谈不同的“分布式数据库”:

    一、万法同宗RDBMS

    1990年代开始,关系型数据库(RDBMS)成为主流,典型的产品包括Sybase、Oracle、DB2等,同期大约也是国内IT产业的起步阶段。RDBMS的基本特征已有学术上的定义,这里不再赘述。

    但从实际应用的角度看,Ivan认为有两点最受关注:

    1. 内部以关系模型存储数据,对外支持ANSI SQL接口;

    2. 支持事务管理ACID特性,尤其是强一致性(指事务内的修改要么全部失败要么全部成功,不会出现中间状态)。

    而后出现的各种“分布式数据库”,大多都是在这两点上做权衡以交换其他方面的能力。

    “数据库”虽然有经典定义,但很多大数据产品或许是为了标榜对传统数据库部分功能的替代作用,也借用了“数据库”的名号,导致在实践中这个概念被不断放大,边界越来越模糊。本文一个目标是要厘清这些产品与经典数据库的差异与传承,所以不妨先弱化“数据库”,将其放大为“数据存储”。

    那么怎样才算是“分布式数据存储”系统?

    “分布式”是一种架构风格,用其实现“数据存储”,最现实的目的是为了打开数据库产品的性能天花板,并保证系统的高可靠,进一步展开,“分布式数据库”的必要条件有两点:

    • 支持水平扩展,保证高性能

    通过增加机器节点的方式提升系统整体处理能力,摆脱对专用设备的依赖,并且突破专用设备方案的性能上限。这里的机器节点,通常是要支持X86服务器。

    • 廉价设备+软件,保证高可靠

    在单机可靠性较低的前提下,依靠软件保证系统整体的高可靠,又可以细分为“数据存储的高可靠”和“服务的高可靠”。总之,任何单点的故障,可能会带来短时间、局部的服务水平下降,但不会影响系统整体的正常运转。

    将这两点作为“分布式数据库”的必要条件,Ivan大致归纳了一下,至少有五种不同的“分布式数据库”:

    • NoSQL

    • NewSQL

    • MPP

    • Hadoop技术生态

    • Like-Mesa

    注:也许有些同学会提到Kafka、Zookeeper等,这些虽然也是分布式数据存储,但因为具有鲜明的特点和适用场景,无需再纳入“数据库”概念进行探讨。

    这五类中,前两类以支持OLTP场景为主,后三类则以OLAP场景为主。Ivan将按照时间线,主要对OLAP场景下的三类进行概要分析。

    二、OLAP场景下的分布式数据库

    1990-2000年代,随着应用系统广泛建设与深入使用,数据规模越来越大,国内银行业的“全国大集中”基本都是在这个阶段完成。这期间,RDBMS得到了广泛运用,Oracle也击败Sybase成为数据库领域的王者。

    在满足了基本的交易场景后,数据得到了累积,进一步的分析性需求自然就涌现了出来。单一数据库内同时支持联机交易和分析需求存在很多问题,往往会造成对联机交易的干扰,因此需要新的解决方案。这就为MPP崛起提供了机会。

    1. MPP

    MPP(Massively Parallel Processing)是指多个处理器(或独立的计算机)并行处理一组协同计算[1]。

    为了保证各节点的独立计算能力,MPP数据库通常采用ShareNothing架构,最为典型的产品是Teradata(简称TD),后来也出现Greenplum(简称GPDB)、Vertica、Netezza等竞争者。

    架构特点:

    MPP是多机可水平扩展的架构,符合“分布式”的基本要求,其中TD采用外置集中存储而GPDB直接使用本地磁盘,从这点来说GPDB是更彻底的Share Nothing架构。

    考虑到TD商业策略上采用一体机方案,不具有开放性,而GPDB具有较高的开源程度,下文中通过分析后者架构特点来分析MPP工作机制。

    GPDB属于主从架构[2],Slave称为Segment是主要的数据加工节点,是在PostgreSQL基础上的封装和修改,天然具备事务处理的能力,可进行水平扩展;集群内有唯一Active状态的Master节点,除了元数据存储和调度功能外,同时承担一定的工作负载,即所有外部对集群的数据联机访问都要经过Master节点。

    在高可靠设计方面,首先设置了Standby Master节点,在Master节点宕机时接管其任务,其次将Segment节点则细分为两类不同角色Primary和Mirror,后者是前者的备节点,数据提交时在两者间进行强同步,以此保证Primary宕机时,Mirror可以被调度起来接替前者的任务。



    数据分析性需求对IT能力的要求包括:

    • 复杂查询能力;

    • 批量数据处理;

    • 一定的并发访问能力。

    MPP较好的实现了对上述能力的支撑,在前大数据时代得到了广泛的应用,但这个时期的数据总量相对仍然有限,普遍在TB级别,对应的集群规模也通常在单集群百节点以下。

    随着数据价值关注度的不断提升,越来越多的数据被纳入企业分析范围;同时实际应用中考虑到数据存储和传输成本,往往倾向于将数据集中在一个或少数几个集群中,这样推动了集群规模的快速增长。

    在大规模集群(几百至上千)的使用上,MPP从批处理和联机访问两个方面都显现了一些不足。以下内容主要借鉴了Pivotal(GPDB原厂)的一篇官方博客[3]。

    注:有位同学给出的译文也具有较好的质量,推荐阅读[4]。

    缺陷:

    • 批处理

    MPP架构下,工作负载节点(对GPDB而言是Segment节点)是完全对称的,数据均匀的存储在这些节点,处理过程中每个节点(即该节点上的Executor)使用本地的CPU、内存和磁盘等资源完成本地的数据加工。这个架构虽然提供了较好的扩展性,但隐藏了极大的问题——Straggler,即当某个节点出现问题导致速度比其他节点慢时,该节点会成为Straggler。

    此时,无论集群规模多大,批处理的整体执行速度都由Straggler决定,其他节点上的任务执行完毕后则进入空闲状态等待Straggler,而无法分担其工作。导致节点处理速度降低的原因多数是磁盘等硬件损坏,考虑到磁盘本身的一定故障率(根据Google统计前三个月内2%损坏率,第二年时达到8%)当集群规模达到一定程度时,故障会频繁出现使straggler成为一个常规问题。

    • 并发

    由于MPP的“完全对称性”,即当查询开始执行时,每个节点都在并行的执行完全相同的任务,这意味着MPP支持的并发数和集群的节点数完全无关。根据该文中的测试数据,4个节点的集群和400个节点的集群支持的并发查询数是相同的,随着并发数增加,这二者几乎在相同的时点出现性能骤降。

    传统MPP的联机查询主要面向企业管理层的少数用户,对并发能力的要求较低。而在大数据时代,数据的使用者从战略管理层转向战术执行层乃至一线人员,从孤立的分析场景转向与业务交易场景的融合。对于联机查询的并发能力已经远超MPP时代,成为OLAP场景分布式数据库要考虑的一个重要问题。

    除上述两点以外,GPDB架构中的Master节点承担了一定的工作负载,所有联机查询的数据流都要经过该节点,这样Master也存在一定的性能瓶颈。同时,在实践中GPDB对数据库连接数量的管理也是非常谨慎的。在Ivan曾参与的项目中,Pivotal专家给出了一个建议的最大值且不会随着集群规模扩大而增大。

    综上,大致可以得出结论,MPP(至少是GPDB)在集群规模上是存在一定限制的。

    2000-2010年代,大多数股份制以上银行和少部分城商行都建立了数据仓库或ODS系统,主要采用了MPP产品。可以说,这十余年是MPP产品最辉煌的时代。到目前为止,MPP仍然是银行业建设数据仓库和数据集市类系统的主要技术选择。为了规避MPP并发访问上的缺陷以及批量任务对联机查询的影响,通常会将数据按照应用粒度拆分到不同的单体OLTP数据库中以支持联机查询。

    2. Hadoop生态体系

    MPP在相当长的一段时期内等同于一体机方案(以TD为代表),其价格高昂到普通企业无法承受,多数在银行、电信等行业的头部企业中使用。2010年代,随着大数据时代的开启,Hadoop生态体系以开源优势,获得了蓬勃发展和快速普及。

    Hadoop技术体系大大降低了数据分析类系统的建设成本,数据分析挖掘等工作由此步入“数据民主化”时代。在Hadoop生态体系中,分析需求所需要的能力被拆分为批量加工和联机访问,通过不同的组件搭配实现。批量加工以MapReduce、Tez、Spark等为执行引擎,为了获得友好的语义支持,又增加了Hive、SparkSQL等组件提供SQL访问接口。

    联机访问部分,则从早期Hive过渡到Impala、Hawk以及Kylin、Presto等方案逐渐降低了访问延时。

    • 架构特点:

    Hadoop生态体系下HDFS、Spark、Hive等组件已经有很多文章介绍,本文不再赘述。总的来说,其架构的着力点在于数据高吞吐处理能力,在事务方面相较MPP更简化,仅提供粗粒度的事务管理。

    • 缺陷:

    Hadoop也有其明显的缺陷,主要是三点:

    • 批量加工效率较低

    MPP的拥护者往往会诟病Hadoop计算引擎执行效率低。的确,在同等规模的集群执行相同的数据加工逻辑,即使与Spark对比,MPP所耗费的时间也会明显更少些[3],其主要的原因在于两者对于数据在磁盘和内存中的组织形式不同。

    MPP从RDBMS而来(例如Vertica和GPDB都是基于PostgreSQL开发),对数据的组织形式更贴近传统方式,按区、段、块等单位组织,对数据进行了预处理工作以提升使用时的效率;Hadoop生态体系以HDFS文件存储为基础,HDFS并不像传统数据库那样独立管理一块连续的磁盘空间,而是将数据表直接映射成不同的数据文件,甚至表分区也以目录、文件等方式体现。

    HDFS最简单的txt格式干脆就是平铺的数据文件,处理过程难免要简单粗暴一些,但随着Avro、ORCFile、Parquet等很多新的存储格式相继被引入,基于HDFS的批处理也更加精细。从整体架构来看,Hadoop更加看重大数据量批量处理的吞吐能力。

    同时,Hadoop具备MPP所缺失的批量任务调整能力,数据的多副本存储使其具有更多“本地化”数据加工的备选节点,而且数据加工处理与数据存储并不绑定,可以根据节点的运行效率动态调整任务分布,从而在大规模部署的情况下具有整体上更稳定的效率。相比之下,MPP在相对较小的数据量下具有更好的执行效率。

    • 不能无缝衔接EDW实施方法论

    在长期的实践中,企业级市场的主流集成商针对EDW项目沉淀了一套固定的实施方法,与MPP特性相匹配,但Hadoop并不能与之无缝对接。一个最典型的例子是历史数据的存储,传统方法是采用“拉链表”的形式,即对于当前有效的数据会记录其生效的起始时间,在数据被更改或删除后,在该行记录的另外一列记录失效时间。这样,当前数据即变更为历史数据,通过这种增量的表述方式,节省了大量的存储空间和磁盘IO。

    可以看出,拉链表的设计思想其实与基于时间戳的MVCC机制是相同的。

    HDFS作为Hadoop的存储基础,其本身不提供Update操作,这样所有在数据操作层面的Update最终会被转换为文件层面的Delete和Insert操作,效率上显著降低。据Ivan所知,在很多企业实践中会将这种增量存储转换为全量存储,带来大量数据冗余的同时,也造成实施方法上的变更。

    • 联机查询并发能力不足

    对于联机查询场景,最常见的是SQL on Hadoop方案,将Impala、HAWQ等MPP引擎架设在HDFS基础上,批量数据与联机查询共用一份数据。MPP引擎借鉴了MPP数据库的设计经验,相对Hive等组件提供了更低的延迟。但存在一个与MPP相同的问题,即并发能力不足。

    通过一些项目测试中,Ivan发现在大体相同的数据量和查询逻辑情况下, Impala并发会低于GPDB。其原因可能是多方面的,不排除存在一些调优空间,但在系统架构层面也有值得探讨的内容。例如在元数据读取上,Impala复用了Hive MetaStore,但后者提供的访问服务延时相对较长,这也限制了Impala的并发能力[7]。

    3. Like-Mesa

    Mesa是Google开发的近实时分析型数据仓库,2014年发布了论文披露其设计思想[5],其通过预聚合合并Delta文件等方式减少查询的计算量,提升了并发能力。

    Mesa充分利用了现有的Google技术组件,使用BigTable来存储所有持久化的元数据,使用了Colossus (Google的分布式文件系统)来存储数据文件,使用MapReduce来处理连续的数据。

    Mesa相关的开源产品为Clickhouse[6](2016年Yandex开源)和Palo[7](2017年百度开源)。

    架构特点:

    目前ClickHouse的资料仍以俄语社区为主,为便于大家理解和进一步研究,下面主要以Palo为例进行说明。

    Palo没有完全照搬Mesa的架构设计的思路,其借助了Hadoop的批量处理能力,但将加工结果导入到了Palo自身存储,专注于联机查询场景,在联机查询部分主要借鉴了Impala技术。同时Palo没有复用已有的分布式文件系统和类BigTable系统,而是设计了独立的分布式存储引擎。虽然数据存储上付出了一定的冗余,但在联机查询的低延迟、高并发两方面都得到了很大的改善。

    Palo在事务管理上与Hadoop体系类似,数据更新的原子粒度最小为一个数据加载批次,可以保证多表数据更新的一致性。

    整体架构由Frontend和Backend两部分组成,查询编译、查询执行协调器和存储引擎目录管理被集成到Frontend;查询执行器和数据存储被集成到Backend。Frontend负载较轻,通常配置下,几个节点即可满足要求;而Backend作为工作负载节点会大幅扩展到几十至上百节点。数据处理部分与Mesa相同采用了物化Rollup(上卷表)的方式实现预计算。



    Palo和ClickHouse都宣称实现了MPP Data Warehouse,但从架构上看已经与传统的MPP发生很大的变化,几乎完全舍弃了批量处理,专注于联机部分。

    ClickHouse和Palo作为较晚出现的开源项目,还在进一步发展过程中,设定的使用场景以广告业务时序数据分析为主,存在一定局限性,但值得持续关注。


    文献参考:

    [1] http://en.wikipedia.org/wiki/Massively_parallel

    [2] http://greenplum.org/gpdb-sandbox-tutorials/introduction-greenplum-database-architecture/#ffs-tabbed-11

    [3] Apache HAWQ: Next Step In Massively Parallel Processing,

    https://content.pivotal.io/blog/apache-hawq-next-step-in-massively-parallel-processing

    [4] 对比MPP计算框架和批处理计算框架,

    http://blog.csdn.net/rlnLo2pNEfx9c/article/details/78955006

    [5] A. Gupta and et al., “Mesa: Geo-replicated, near real-time, scalabledata warehousing,”PVLDB, vol. 7, no. 12, pp. 1259–1270, 2014.

    [6] http://clickhouse.yandex

    [7] http://github.com/baidu/palo

    转载于:https://www.cnblogs.com/zzjhn/p/10179822.html

    展开全文
  • 所有软件系统中都必须包含一项关键组件,那就是用于存储、检索和分析数据的数据库。本文中,我们将和大家一起探讨适用于算法交易平台的数据库都会...举例来说,擅长一致和持久事务的关系型数据库可能在性能方面表现...

    所有软件系统中都必须包含一项关键组件,那就是用于存储、检索和分析数据的数据库。本文中,我们将和大家一起探讨适用于算法交易平台的数据库都会有哪些特性?有哪些可选择的数据库?

    从广义层面来看,数据库提供了记录和管理数据(OLTP)和分析数据(OLAP)的能力。大多数数据库会擅长其中一种能力,同时在某些指标具备优势,而在另一些方面则有所欠缺。举例来说,擅长一致和持久事务的关系型数据库可能在性能方面表现不是很好,因为它需要锁定其数据结构并刷新所有磁盘写入。相反,优先考虑性能的数据库可能需要使用宽松的一致性模型。

    根据特定功能和特性的优先级划分,不同种类的数据库适用于不同的场景。

    1算法交易系统的数据存储

    如果我们想追求完美,即持久、一致地存储大量数据并快速进行实时分析,这能做到吗?尽管计算机科学理论警告我们不要太贪心,但是有一些工程思想值得参考。

    主要设计目标包括:

    • 快速将大量事件提取到持久存储中(每天工作数小时,约 250K-1M 个事件 / 秒;我们预期每个事件约为 100-200 字节,并具有 10-30 个字段)

    • 实时分析,包括汇总

    • 能够处理大量模式和趋势历史数据

    基于以上的设计目标,我们可以构建几种解决方案,不过基本上都需要对数据存储进行分层,以提供多种附加能力。

    其中的一种解决方案为:

    1. 将交易系统中的所有事件存储到一个快速数据存储中,例如仅附加文件日志(可能在高可用性系统的多个节点上复制或重新创建)。该文件提供持久存储,但没有真正的查询功能。

    2. 将该日志文件的内容顺序提取到一个内存数据库 / 缓存中。这个步骤可以很快,甚至是实时的,因为在这一层没有一致性检查、复制或持久性要求。该层应提供实时聚合和分析。

    3. 定期将内存数据库的内容持久存储到磁盘(每小时或一天结束时等)。这里使用可以对磁盘上存储的大量数据进行操作的数据库。本质而言,对存储的这些数据进行的操作被视为脱机或批处理模式,并且不期望瞬时响应时间。

    4. (可选)仅将日志文件的相关部分提取到一个关系型数据库中,以提交每日 / 每月报告。例如,只有订单和执行会被加载到关系型数据库中,而市场报价会被跳过。

    另外,这个解决方案也是可以简化的,例如可以将步骤 2、3 和 4 组合起来,使用一个提供多种存储和分析数据模式的工具。

    接下来,我们就来一起讨论一下细分需求下的数据库工作。

    2我们对数据库的要求

    我们对数据库的要求可分为非技术需求和技术需求两部分。

    非技术需求列表:

    成本:作为一家注重成本的初创企业,我们正在寻找免费或相对便宜的产品。鉴于当今有许多 FOSS 方案,我们认为这不是什么疯狂的要求。这也意味着 Oracle 和 MS SQL Server 等标准付费数据库被排除在外了。

    良好的文档和社区支持:如果我们不支付许可和支持费用,就需要良好的文档和另一种解答问题的途径。可行途径可以是邮件列表、活跃的在线社区,也可能只需 StackOverflow 即可。

    运营工具:我们更喜欢相对成熟的产品,自带用于设置、管理和监视部署(包括可能的多节点集群)的工具。

    技术需求:

    快速提取:我们需要数据库能够以每秒 250K 次插入的速度提取,越高越好。如果我们需要批量插入,那是可以接受的;如果我们需要使用多个线程或连接也可以。

    快速聚合:我们打算在系统中使用事件源模式。按照这一架构模式的规定,我们会将系统中的所有状态更改记录为离散的不可变事件。为了从这些事件中重新创建系统的最新状态,我们需要对内存中快速聚合的支持,包括窗口函数、upsert 和其他可能的横截面聚合。

    时间序列操作:支持诸如时间段、移动窗口聚合和 as-of joins 之类的操作。

    表达力强的查询语言:SQL 可以,但对于高级分析来说表达能力还是不够。理想情况下,数据库将使用带有矢量化操作的函数语言支持数据访问和处理。创建用户定义函数或服务端脚本的能力也很有用。

    内存中的表:用于快速分析工作数据集。

    磁盘中的表:我们预期这一类别中的多数数据库使用面向列的存储。

    数据库应支持优化的磁盘数据布局,这会显著提高性能。

    • 数据按日期划分并分段存储,以便数据管理

    • 对于每个分区,数据由 Symbol(交易代码)跨多个节点分片,以实现并行性和冗余

    • 在每个分区和分片中,数据记录按(Symbol + Exchange,代码 + 交易所)进行聚类,以方便顺序读取磁盘

    • 最后,在每个聚簇键的记录中,按时间戳对数据排序,以实现更快的时序操作

    • 此外,可以将数据压缩在磁盘上,以减少从磁盘读取的数据总量

    • 分层数据存储:数据库还可以支持分层存储策略,将较旧的数据移动到速度较慢的存储上,从而降低存储成本。

    下面是我们评估的数据规模估算:

    1. 每日数据增长:50–100 GB(未压缩)〜1B 条记录

    2. 历史数据(最终):100 TB(未压缩)〜1T 条记录

    3如何进行测试?

    我们所有的测试都是在单个或两个 AWS 专用实例(m5n-2xlarge)上进行的。这些实例运行 Amazon Linux 2 AMI,包括 8 个 vCPU、32GB RAM 和 100–200GB SSD 卷。

    我们知道,对于某些参与测试的数据库来说,这些实例不算很大,尤其是在内存指标方面。但我们这样选择也有我们的考量,首先,我们认为这些资源足以进行我们想要的测试,其次,我们想了解在资源不足时,这些工具将如何降级或失败。

    在我们的时间限制内,我们尽了最大的努力来配置各个工具以使其发挥最佳性能,但是我们可能并没有一直使用推荐的配置、硬件或节点数。我们也尝试了遵循文档并以最佳方式设置数据布局(例如分片方案)。

    我们执行的实际测试包括:

    • 加载一天的 NYSE TAQ 数据(20180730 的文件)。这会将 3500 万笔交易加载到一个表中,并将 7.19 亿个报价加载到另一个表中。我们不打算将此数据库用于报价数据分析,但这肯定会成为一个很好的示例数据集。

    • 对于每笔交易,在该交易所在的交易所中找到当前的报价。我们希望对单个繁忙的代码(例如 SPY)的查询将花费不到一分钟的时间,对于所有代码,我们希望查询在 30 分钟内完成。这是对查询语言表示复杂联接的能力,以及数据库在合理时间内执行联接能力的测试。

    • 对于每个交易代码,计算交易日每分钟的交易数量、平均大小和交易量加权平均成交价。我们希望在整个交易表上花费的时间不超过 10 秒。

    • 在交易日的每一分钟计算每个交易代码的 OHLC 条形。

    • 计算交易日每个交易品种的时间加权平均价差。这是一个有趣的测试,其原因有两个:1)确定报价的持续时间需要使用诸如 LEAD 或 next 之类的窗口函数;2)必须处理每个报价,因此这是对原始扫描速度的测试。

    4备选方案

    要说明一下,我们在 kdb+ 上拥有丰富的经验,因此,我们对响应时间的预期大部分来自于这部分经验。在原始单核速度方面,我们还没有发现比 kdb + 更快的工具。但因为价格、陡峭的学习曲线和缺乏可操作工作等原因,我们没有把 kdb+ 列在备选名单中。

    平面文件(Flat File)

    虽然数据库是最常见的数据存储,但是直接处理平面文件是真正关键的竞争优势,因为它提供了存储数据的最大灵活性。如今,有多种工具可以有效操作存储在本地磁盘或 S3 存储桶上的平面文件,例如:Python(带有 Jupyter 的 Pandas)、Apache Spark、Amazon Redshift Spectrum 甚至 clickhouse-local。

    我们在 AWS 上使用 Apache Spark 尝试了 EMR(Elastic Map Reduce)集群,虽然设置起来相对容易,但我们仍旧花了一些时间才弄清楚如何从文件和 JDBC 源加载数据,以及如何使用 Spark 数据集和 PySpark 数据帧。我们的结论是,这可以用于具有适当扩展能力的批处理分析,但不能用作主数据库。不过,我们对 Hadoop 和 Spark 的了解有限,因此对于结论判断也会有所影响。

    不过,我们仍然认为这是一个精心设计的系统,该系统以正确方式组织文件和目录,还带有相应的工具和规划好的作业,对于能够分配适当资源的高级用户而言,这可能是一个可行的选择。但是对于我们来说,我们认为它可能太脆弱且缺乏组织性,我们还需要其他一些花哨的功能。

    MySQL

    我们只把 MySQL 视为一个起点,主要是为了确认传统的 RDBMS 对我们而言并不是真正的正确答案。MySQL 不是时间序列数据库,也不是面向列的,并且不支持我们正在寻找的高级分析特性或性能指标。

    它的优点是免费,还有庞大的社区。它的支持者会声称,只要你知道方法,它就可以做任何事情。在我们的测试中,MySQL(InnoDB 引擎)无法跟上连接池中 250K/ 秒的快速批量插入,并且随着表增加到几百万条记录,插入速率也下降了。磁盘上的数据大小看起来非常大,查询几百万条记录时的响应时间以秒为单位。即使可以添加索引,具有数百万条记录的联接表也无法在可接受的时间内完成。

    在校对本文的草稿时,一位前同事向我们推荐了 MariaDB 列存储,由于时间限制,我们无法对其进行全面评估。

    PostgreSQL 和 TimescaleDB

    在我们的负载测试中,PostgreSQL 比 MySQL 更好,尤其是在插入速率和表大小增加时响应时间的退化水平方面,但对于实际需求而言还不够好。

    TimescaleDB 似乎很有竞争力——它是一个 PostgreSQL 扩展,使用大量常规 PostgreSQL 表创建一个称为超表的虚拟表。在超表上的所有查询和操作都向下传递到适当的块表。这里的主要目的是提高插入速率,并在处理大量数据时提供可预测的查询时间。TimescaleDB 还提供了一些与时间序列相关的功能,以帮助分析。

    宣传的效果很好,但实际跑起来就不行了。最初的插入速率很不错(250K / 秒),但我们无法提取 3500 万笔交易记录——它莫名其妙地耗尽了内存。我们还注意到,文本文件加载器无法利用服务器上所有可用的内核。提取数据时,我们发现服务器上的 IOWait 时间比其他数据库长得多,这可能是由于缺少磁盘压缩所致。磁盘空间使用率也很高——存储的数据比完全未压缩的文本数据占用的空间还要多,这是很奇怪的(也许是因为预分配?)。我们知道最近的版本支持原生压缩了,但是我们无法将其自动用于新提取的数据。

    ClickHouse

    ClickHouse 基本可以算是一个新玩家,几乎拥有我们梦寐以求的所有特性:

    • 它是 FOSS、速度超快、水平可伸缩、容错、硬件支持良好,并且具有磁盘(包括分层存储)上的高级数据管理;

    • 开发过程非常透明,在 Github 上有活跃的社区,并且每 2 至 3 周发布一次更新,其中包含新功能、改进和修复;

    • 文档很好,很容易从维护者那里得到问题的答案。

    ClickHouse 主要是一个 OLAP 引擎,没有真正的事务支持可言——例如,它不支持插入数据的更新和删除,除非通过笨拙的异步 ALTER TABLE 命令。它还不支持窗口函数(neighbor 和 runningAccumulate 这类特殊情况除外),这让人有些惊讶,毕竟它主要针对的是时间序列。

    我们在未启用任何复制功能的单个节点上测试了 ClickHouse。ClickHouse 能够以超过 1M/sec 的速度加载 3500 万笔交易和 7.19 亿笔报价。它使用特殊的磁盘数据结构(MergeTree)将数据尽快写入临时文件,然后在后台合并,从而达到很高的速度。它永远不会用完内存(只有一个例外),并且使用压缩过的源文件节省了将近一半磁盘空间,效率极高。

    遗憾的是,我们无法克服一些关键障碍:

    • 发出查询的唯一方法是使用类似 SQL 的查询语言,但有一些严格的限制:每个请求只能发出一个选择语句,并且不支持用户定义函数(UDF)或存储过程(Stored Procedure)。

    • 他们的哲学可以概括为"只能听我的"。维护人员对一些合理的用户请求(例如支持日期时间数据类型中的亚秒级精度)给出了无法令人满意的答复。公平地说,有些回应也有正当的理由,但是看到这些交流仍然有些令人不安。

    总而言之,我们还是认为 ClickHouse 具有很大的潜力,将密切关注其发展,甚至我们会在系统中的非关键部分部署 ClickHouse。

    DolphinDB

    DolphinDB 是一种奇特的专用产品,在这次评估之前我们完全没注意过它。这是一个快速的分布式时间序列分析数据库,是 kdb+ 的可行替代方案。来自 kdb+ 的背景激发了我们的兴趣,即便它是付费产品,也足以让我们试用一下。

    我们对它的总体印象是积极的。它比 ClickHouse 更快,甚至可能比 kdb+ 更快。它拥有对多节点集群的原生支持、功能丰富的函数式编程语言以及优化的内存上以及磁盘上的数据结构。它仅用 6 秒钟就将我们的 3500 万笔交易载入了一张表!它仅在 358 毫秒内就执行了所有 SPY 交易及其主要报价之间的 as-of join,在 25 秒钟内对所有代码执行了同样的联接,而在 kdb+ 上一次查询大约需要 5 分钟。另外,存储数据的磁盘用量还不到压缩后的源文件的一半。

    它还有一些高级功能(我们未测试)包括:支持流和发布 / 订阅、实时聚合 / 窗口引擎、实时异常检测引擎、高级统计分析函数和机器学习函数

    尽管它表现极佳,但仍有一些我们无法克服的负面因素:

    • 成本:虽然它看起来比 kdb+ 便宜,但对我们来说仍然太贵了;

    • 需要学习非标准语言(尽管比 kdb+ 容易得多),不过,好在它的文档完整出色;

    • 对于关键业务组件,我们真的可以考虑为(对我们而言)未经验证且尚无法判断其局限性的闭源产品付费吗?让人犹豫不决的是,它出现了几次崩溃和莫名其妙的内存不足情况,这都是扣分点。

    不过,看来我们可能已经发现了比 kdb+ 更快、功能更丰富的产品,这一点得分很高。我们将密切注意这款产品,如果对具有这些能力的产品(例如 tick 数据研究环境)有强烈的需求,我们一定会考虑它的。

    MemSQL

    现在要讲的是,我们最终的选择——MemSQL 了。MemSQL 是一种付费产品,但它也为初始集群提供了免费的商业许可证,其最多可包含 4 个节点、128 GB 内存和无限的磁盘数据。我们认为这足以满足我们在考虑付费产品之前的初始需求了。

    MemSQL 将自己定义为名为 HTAP(混合事务 / 分析处理)的新数据库种类。MemSQL 的主要卖点有:它提供快速的分析功能,同时具有丰富的事务支持并充分兼容 SQL。它甚至可以与 MySQL 兼容,因此你可以使用所有 MySQL 工具和驱动程序。与庞大的工具生态系统集成是很棒的,但也存在一些障碍,因为它很难使用纯 SQL 表示某些高级分析。由于它以 UDF 和存储过程提供了对过程语言的全面支持,我们接受了这一特殊缺点 [注意:过程方法比通常的矢量化操作至少慢一个数量级]。

    MemSQL 支持内存上行存储表以及磁盘上列存储表,带有分片、排序和压缩功能(它们最近还发布了混合单存储格式。我们仅使用 Columnstore 进行了测试,特别是考虑到我们的测试实例只有 32GB 内存。就部署、管理、监视、集群设置甚至数据的加载和查询而言,MemSQL 是最容易使用的工具之一。

    我们能够以超过 50 万条记录 / 秒的速度加载交易和报价。我们注意到,服务器上的加载过程能够使用多个内核并行化提取。加载的数据占用的空间与压缩后的源文件大致相同。我们还观察到,使用 JDBC 接口时,外部工具能够以超过 1Gbps 的速度从 MemSQL 读取数据,这特别令人印象深刻。

    大多数单表查询以及多表联接查询的整体性能都很好。它在 as-of joins 中表现不佳,但毕竟它根本不是针对该用例设计的。我们花了很多时间试图以最佳方式在 SQL 中表示一个 as-of join,最后我们强迫引擎执行(相对)快速的 MergeJoin。可以预期,厂商将来可以作为自定义操作添加对 as-of-join 的专门支持。

    总而言之,MemSQL 是我们在调查中可以找到的最平衡解决方案。它很成熟、易于使用、免费(暂时)、快速、高效且可与我们想要的所有标准工具互操作。

    5结果统计

    针对以上测试,我们做了一个详细的数据统计和对比:

    如果想要更详细查看我们的测试结果,可以查看这里:

    https://github.com/prerak-proof/dbtests

    6总结

    我们知道还有其他许多工具可以评估,尤其是各种 NoSQL 数据库。我们的总体感受是,尽管这些选项也可能处理我们的数据规模,但它们大概无法满足我们的性能期望。至少到现在,我们认为 MemSQL 是最适合我们的产品,既能满足我们的需求,也符合我们的约束条件。

     


    =>更多文章请参考《中国互联网业务研发体系架构指南》

    =>更多行业权威架构案例及领域标准、技术趋势请关注微信公众号:

    公众号:关注更多实时动态
    更多权威内容关注公众号:软件真理与光
    展开全文
  • 数据库分析与选择

    2018-08-27 16:05:47
    关系型数据库遵循ACID规则 事务在英文中是transaction,现实世界中的交易很类似,它有如下四个特性:   1、A (Atomicity) 原子性   原子性很容易理解,也就是说事务里的所有操作要么全部做完,要么都不做,...

    关系型数据库遵循ACID规则

    事务在英文中是transaction,和现实世界中的交易很类似,它有如下四个特性:

     

    1、A (Atomicity) 原子性

     

    原子性很容易理解,也就是说事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚。

     

    比如银行转账,从A账户转100元至B账户,分为两个步骤:1)从A账户取100元;2)存入100元至B账户。这两步要么一起完成,要么一起不完成,如果只完成第一步,第二步失败,钱会莫名其妙少了100元。

     

    2、C (Consistency) 一致性

     

    一致性也比较容易理解,也就是说数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束。

     

    例如现有完整性约束a+b=10,如果一个事务改变了a,那么必须得改变b,使得事务结束后依然满足a+b=10,否则事务失败。

     

    3、I (Isolation) 独立性

     

    所谓的独立性是指并发的事务之间不会互相影响,如果一个事务要访问的数据正在被另外一个事务修改,只要另外一个事务未提交,它所访问的数据就不受未提交事务的影响。

     

    比如现在有个交易是从A账户转100元至B账户,在这个交易还未完成的情况下,如果此时B查询自己的账户,是看不到新增加的100元的。

     

    4、D (Durability) 持久性

     

    持久性是指一旦事务提交后,它所做的修改将会永久的保存在数据库上,即使出现宕机也不会丢失。

     

     

     

     

     

    CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,最多只能同时较好的满足两个。

    一致性(Consistency) (所有节点在同一时间具有相同的数据)

    可用性(Availability) (保证每个请求不管成功或者失败都有响应)

    分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

     

    BASE是NoSQL数据库通常对可用性及一致性的弱要求原则:

    Basically Availble --基本可用

    Soft-state --软状态/柔性事务。 "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的

    Eventual Consistency -- 最终一致性, 也是是 ACID 的最终目的。

     

     

     

     

     

     

    NoSql优点:
    1)查询速度:NoSql数据库将数据存储于缓存之中,关系型数据库将数据存储在硬盘中,自然查询速度远不及nosql数据库。并且NOSQL是基于键值对的,查询只需要只要key即可查询出Value,并且不需要经过SQL解析
    2)存储数据的格式:nosql的存储格式是key,value形式、文档形式、图片形式等等,所以可以存储基础类型以及对象或者是集合等各种格式,而数据库则只支持基础类型。
    3)扩展性:关系型数据库有类似join这样的多表查询机制的限制导致扩展很艰难。NoSql可扩展性同样也是因为基于键值对,数据之间没有耦合性,所以非常容易水平扩展,不需要预定义数据的存储模式。


    缺点:
    1)不提供对sql语句的支持,不支持复杂的数据查询

    2)不提供关系型数据库对事务的处理。


     

    关系型数据库把所有的数据都通过行和列的二元表现形式表示出来。

     

    关系型数据库的优势:

    1.遵循ACID规则(一致性,原子性,持久性,独立性)

    2.由于高度组织化结构化数据,因此数据更新的开销很小(相同的字段基本上都只有一处)

    3.支持结构化查询语句(SQL,可以进行Join等复杂查询

    4.支持事务处理,使得对于安全性能很高的数据访问要求得以实现

    其中能够保持数据的一致性是关系型数据库的最大优势。

     

    关系型数据库的不足:

    1. 大量数据的写入处理

    2. 为有数据更新的表做索引或表结构(schema)变更

    3. 字段不固定时应用

    4. 对简单查询需要快速返回结果的处理

    --大量数据的写入处理

    读写集中在一个数据库上让数据库不堪重负,大部分网站已使用主从复制技术实现读写分离,以提高读写性能和读库的可扩展性。

    所以在进行大量数据操作时,会使用数据库主从模式。数据的写入由主数据库负责,数据的读入由从数据库负责,可以比较简单地通过增加从数据库来实现规模化,但是数据的写入却完全没有简单的方法来解决规模化问题。

    第一,要想将数据的写入规模化,可以考虑把主数据库从一台增加到两台,作为互相关联复制的二元主数据库使用,确实这样可以把每台主数据库的负荷减少一半,但是更新处理会发生冲突,可能会造成数据的不一致,为了避免这样的问题,需要把对每个表的请求分别分配给合适的主数据库来处理。

    http://images.cnitblog.com/blog/351150/201303/17093451-f1f05cf6c599495fbd6f95505832f50b.png

    第二,可以考虑把数据库分割开来,分别放在不同的数据库服务器上,比如将不同的表放在不同的数据库服务器上,数据库分割可以减少每台数据库服务器上的数据量,以便减少硬盘IO的输入、输出处理,实现内存上的高速处理。但是由于分别存储字不同服务器上的表之间无法进行Join处理,数据库分割的时候就需要预先考虑这些问题,数据库分割之后,如果一定要进行Join处理,就必须要在程序中进行关联,这是非常困难的。

    http://images.cnitblog.com/blog/351150/201303/17093534-0ea2a003bfeb467d8f5bf5c0e5f192ff.png http://images.cnitblog.com/blog/351150/201303/17093559-c30e983e2bf04558be57acf27e6a4b7f.png

     

    --为有数据更新的表做索引或表结构变更

    在使用关系型数据库时,为了加快查询速度需要创建索引,为了增加必要的字段就一定要改变表结构,为了进行这些处理,需要对表进行共享锁定,这期间数据变更、更新、插入、删除等都是无法进行的。如果需要进行一些耗时操作,例如为数据量比较大的表创建索引或是变更其表结构,就需要特别注意,长时间内数据可能无法进行更新。

    http://images.cnitblog.com/blog/351150/201303/17094227-8cb95651bf824beea01dd152049c5bee.png

     

    --字段不固定时的应用

    如果字段不固定,利用关系型数据库也是比较困难的,有人会说,需要的时候加个字段就可以了,这样的方法也不是不可以,但在实际运用中每次都进行反复的表结构变更是非常痛苦的。你也可以预先设定大量的预备字段,但这样的话,时间一长很容易弄不清除字段和数据的对应状态,即哪个字段保存有哪些数据。

    --对简单查询需要快速返回结果的处理  (这里的简单指的是没有复杂的查询条件)

    这一点称不上是缺点,但不管怎样,关系型数据库并不擅长对简单的查询快速返回结果,因为关系型数据库是使用专门的sql语言进行数据读取的,它需要对sql进行解析,同时还有对表的锁定和解锁等这样的额外开销,这里并不是说关系型数据库的速度太慢,而只是想告诉大家若希望对简单查询进行高速处理,则没有必要非使用关系型数据库不可。

    ---------------------------

    NoSQL数据库

    关系型数据库应用广泛,能进行事务处理和表连接等复杂查询。相对地,NoSQL数据库只应用在特定领域,基本上不进行复杂的处理,但它恰恰弥补了之前所列举的关系型数据库的不足之处。

    优点:

     易于数据的分散

    各个数据之间存在关联是关系型数据库得名的主要原因,为了进行join处理,关系型数据库不得不把数据存储在同一个服务器内,这不利于数据的分散,这也是关系型数据库并不擅长大数据量的写入处理的原因。相反NoSQL数据库原本就不支持Join处理,各个数据都是独立设计的,很容易把数据分散在多个服务器上,故减少了每个服务器上的数据量,即使要处理大量数据的写入,也变得更加容易,数据的读入操作当然也同样容易。

     

    典型的NoSQL数据库

    临时性键值存储(memcachedRedis)、永久性键值存储(ROMARedis)、面向文档的数据库(MongoDBCouchDB)、面向列的数据库(CassandraHBase

    一、 键值存储

    它的数据是以键值的形式存储的,虽然它的速度非常快,但基本上只能通过键的完全一致查询获取数据,根据数据的保存方式可以分为临时性、永久性和两者兼具 三种。

    1)临时性

          所谓临时性就是数据有可能丢失,memcached把所有数据都保存在内存中,这样保存和读取的速度非常快,但是当memcached停止时,数据就不存在了。由于数据保存在内存中,所以无法操作超出内存容量的数据,旧数据会丢失。总结来说:

          。在内存中保存数据

          。可以进行非常快速的保存和读取处理

          。数据有可能丢失

     2)永久性

           所谓永久性就是数据不会丢失,这里的键值存储是把数据保存在硬盘上,与临时性比起来,由于必然要发生对硬盘的IO操作,所以性能上还是有差距的,但数据不会丢失是它最大的优势。总结来说:

           。在硬盘上保存数据

           。可以进行非常快速的保存和读取处理(但无法与memcached相比)

           。数据不会丢失

    3 两者兼备

           Redis属于这种类型。Redis有些特殊,临时性和永久性兼具。Redis首先把数据保存在内存中,在满足特定条件(默认是 15分钟一次以上,5分钟内10个以上,1分钟内10000个以上的键发生变更)的时候将数据写入到硬盘中,这样既确保了内存中数据的处理速度,又可以通过写入硬盘来保证数据的永久性,这种类型的数据库特别适合处理数组类型的数据。总结来说:

           。同时在内存和硬盘上保存数据

           。可以进行非常快速的保存和读取处理

           。保存在硬盘上的数据不会消失(可以恢复)

           。适合于处理数组类型的数据

         

    二、面向文档的数据库

       MongoDBCouchDB属于这种类型,它们属于NoSQL数据库,但与键值存储相异。

       1)不定义表结构

         即使不定义表结构,也可以像定义了表结构一样使用,还省去了变更表结构的麻烦。

       2)可以使用复杂的查询条件 

         跟键值存储不同的是,面向文档的数据库可以通过复杂的查询条件来获取数据,虽然不具备事务处理和Join这些关系型数据库所具有的处理能力,但初次以外的其他处理基本上都能实现。

    三、 面向列的数据库

       CassandraHBaeHyperTable属于这种类型,由于近年来数据量出现爆发性增长,这种类型的NoSQL数据库尤其引入注目。

       普通的关系型数据库都是以行为单位来存储数据的,擅长以行为单位的读入处理,比如特定条件数据的获取。因此,关系型数据库也被成为面向行的数据库。相反,面向列的数据库是以列为单位来存储数据的,擅长以列为单位读入数据。

    http://images.cnitblog.com/blog/351150/201303/17112620-0ac9b1cc1f374a219a982af18ef2ac07.png

    面向列的数据库具有搞扩展性,即使数据增加也不会降低相应的处理速度(特别是写入速度),所以它主要应用于需要处理大量数据的情况。另外,把它作为批处理程序的存储器来对大量数据进行更新也是非常有用的。但由于面向列的数据库跟现行数据库存储的思维方式有很大不同,故应用起来十分困难。

     

     

     

    mongodb

    它是一个内存数据库,数据都是放在内存里面的。

    对数据的操作大部分都在内存中,但mongodb并不是单纯的内存数据库。

    持久化方式:

    mongodb的所有数据实际上是存放在硬盘的,所有要操作的数据通过mmap的方式映射到内存某个区域内。

    然后,mongodb就在这块区域里面进行数据修改,避免了零碎的硬盘操作。

    至于mmap上的内容flush到硬盘就是操作系统的事情了,所以,如果,mongodb在内存中修改了数据后,mmap数据flush到硬盘之前,系统宕机了,数据就会丢失。

    mmap详解链接:http://www.cnblogs.com/techdoc/archive/2010/12/22/1913521.html

    redis

    它就是一个不折不扣的内存数据库了。

    持久化方式:

    redis所有数据都是放在内存中的,持久化是使用RDB方式或者aof方式。

    解密redis持久化:http://blog.nosqlfan.com/html/3813.html

    mysql

    无论数据还是索引都存放在硬盘中。到要使用的时候才交换到内存中。能够处理远超过内存总量的数据。

    数据量和性能:

    当物理内存够用的时候,redis>mongodb>mysql

    当物理内存不够用的时候,redismongodb都会使用虚拟内存。

    实际上如果redis要开始虚拟内存,那很明显要么加内存条,要么你换个数据库了。

    但是,mongodb不一样,只要,业务上能保证,冷热数据的读写比,使得热数据在物理内存中,mmap的交换较少。

    mongodb还是能够保证性能。有人使用mongodb存储了上T的数据。

    mysqlmysql根本就不需要担心数据量跟内存下的关系。不过,内存的量跟热数据的关系会极大地影响性能表现。

    当物理内存和虚拟内存都不够用的时候,估计除了mysql你没什么好选择了。

    其实,从数据存储原理来看,我更倾向于将mongodb归类为硬盘数据库,但是使用了mmap作为加速的手段而已。

     

     

     

    NoSQL数据库在以下的这几种情况下比较适用:

    1、数据模型比较简单;

    2、需要灵活性更强的IT系统;

    3、对数据库性能要求较高;

    4、不需要高度的数据一致性;

    5、对于给定key,比较容易映射复杂值的环境。

     

     

     

     

     

    数据库为什么用B+树而不用hash存储:

    哈希文件也称为散列文件,是利用哈希存储方式组织的文件,亦称为直接存取文件。它类似于哈希表,即根据文件中关键字的特点,设计一个哈希函数和处理冲突的方法,将记录哈希到存储设备上。

    在哈希文件中,是使用一个函数(算法)来完成一种将关键字映射到存储器地址的映射,根据用户给出的关键字,经函数计算得到目标地址,再进行目标的检索。

    转自:http://imysql.com/2016/01/06/mysql-faq-different-between-btree-and-hash-index.shtml

    B+树索引和哈希索引的区别

    一个经典的B+树索引数据结构见下图:

    20160106B树索引
    (图片源自网络)

     

    B+树服从 左节点 < 父节点 < 右节点;最底层叶子节点严格按照从小到大顺序排列。

    B+树是一个平衡的多叉树,从根节点到每个叶子节点的高度差值不超过1,而且同层级的节点间有指针相互链接。

    在B+树上的常规检索,从根节点到叶子节点的搜索效率基本相当,不会出现大幅波动,而且基于索引的顺序扫描时,也可以利用双向指针快速左右移动,效率非常高。因此,B+树索引被广泛应用于数据库、文件系统等场景。

    哈希索引的示意图则是这样的:
    20160106哈希索引
    (图片源自网络)

    简单地说,哈希索引就是采用一定的哈希算法,把键值换算成新的哈希值,检索时不需要类似B+树那样从根节点到叶子节点逐级查找,只需一次哈希算法即可立刻定位到相应的位置,速度非常快。

    从上面的图来看,B+树索引和哈希索引的明显区别是:

    • 如果是等值查询,那么哈希索引明显有绝对优势,因为只需要经过一次算法即可找到相应的键值;当然了,这个前提是,键值都是唯一的。如果键值不是唯一的,就需要先找到该键所在位置,然后再根据链表往后扫描,直到找到相应的数据;
    • 从示意图中也能看到,如果是范围查询检索,这时候哈希索引就毫无用武之地了,因为原先是有序的键值,经过哈希算法后,有可能变成不连续的了,就没办法再利用索引完成范围查询检索;
    • 同理,哈希索引也没办法利用索引完成排序,以及like ‘xxx%’ 这样的部分模糊查询(这种部分模糊查询,其实本质上也是范围查询);
    • 哈希索引也不支持多列联合索引的最左匹配规则
    • B+树索引的关键字检索效率比较平均,不像B树那样波动幅度大,在有大量重复键值情况下,哈希索引的效率也是极低的,因为存在所谓的哈希碰撞问题

    后记

    通常,B+树索引结构适用于绝大多数场景,像下面这种场景用哈希索引才更有优势:

    在HEAP表中,如果存储的数据重复度很低(也就是说基数很大),对该列数据以等值查询为主,没有范围查询、没有排序的时候,特别适合采用哈希索引

    例如这种SQL:
    SELECT … FROM t WHERE C1 = ?; — 仅等值查询

    在大多数场景下,都会有范围查询、排序、分组等查询特征,用B+树索引就可以了。

    展开全文
  • 作者简介:张乐奕,通常使用的网名为kamus,也曾用过seraphim,现在任职于北京某大型软件公司,Oracle数据库DBA,主要负责证券行业的核心交易系统数据库管理及维护工作。热切关注Oracle技术相关操作系统技术,出没...
  • 数据库和数据仓库

    2018-10-17 22:58:05
    数据库:传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。 数据仓库:数据仓库系统的主要应用主要是OLAP(On-Line Analytical Processing),支持复杂的分析操作,侧重决策支持,并且...
  • 在学习使用Hive的时候,把Hive定义为数据仓库而不是数据库。都是用于数据存储的地方,为什么把...我们很熟悉的Oracle、mysql等关系型数据库都是常用的数据库。 数据仓库: 主要是用于数据分析,即OLAP(On-Line An...
  • 摘要中国农业银行(以下简称:农行)在信息化系统建设过程中,先是把关系型数据库作为联机交易型数据库使用,后来为满足分析型应用需要开始使用分析型数据库,近几年来随着应用场景细...
  • 数据库:传统的关系型数据库的应用,主要是基本的、日常的事务处理,更关注业务交易处理(OLTP) 数据仓库:数据仓库支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询效果,更关注数据分析层面(OLAP) ...
  • 如今,多样的交易模式以及大众消费观念的改变使得数据库应用领域不断扩大,现代的大型分布式应用系统的数据膨胀也对数据库的海量数据处理能力并行处理能力提出了更高的要求,如何在数据呈现海量扩张的同时提高...
  • 1、引言如今,多样的交易模式以及大众消费观念的改变使得数据库应用领域不断扩大,现代的大型分布式应用系统的数据膨胀也对数据库的海量数据处理能力并行处理能力提出了更高的要求,如何在数据呈现海量扩张的同时...
  • OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。 OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。 ...
  • 2710-数据库操作OLAP、OLTP的介绍比较 OLTP与OLAP的介绍 数据处理大致可以分成两大类...OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。OLAP是数据仓库系统的主要应用,支持复...
  • OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。OLTP 系统强调数据...
  • 前言 开源分布式数据库中间件...:联机事务处理(OLTP)联机分析处理(OLAP)。 联机事务处理(OLTP):也称为面向交易的处理系统,其基本特征是原始数据可以立即传送到计算中心进行处理,并在很短的时...
  • 数据库的应用类型

    2020-12-14 20:20:23
    OLTP是传统关系型数据库的主要应用,其主要面向基本的、日常的事务处理。OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。  OLTP  OLTP被称为面向交易的处理系统...
  • 数据库(database):传统的关系型数据库的主要应用(OLTP),主要是基本的、日常的事务处理,例如银行交易。 数据仓库(data warehouse):数据仓库系统的主要应用主要是OLAP(On-Line Analytical Processing),...
  • 国产数据库从最初的“饱受争议”到如今的“百花齐放”已经走过了数十个年头,与此同时,银行业遇到了海量数据管理...银行交易型数据库采用较多的是OracleDB2,分析型数据库银行采用较多的是Oracle、DB2以及Teradata。
  • Kdb+ A股数据库

    2016-11-12 11:13:51
    kdb+(基于K语言的db, 增强版,也简称kdb)是非常小众的一个数据库,它有非常高...它通常用于高频交易,非常适用于高速存储,分析,处理检索大型数据集。kdb+能够处理数十亿条记录并分析数据库中的数据。该数据库...
  • 数据库-OLAP-OLTP

    千次阅读 2017-03-01 13:24:23
    当今的数据处理大致可以分成两大类:  OLTP(on-line transaction processing...OLTP是传统的关系型数据库的主要应用模式,主要是基本的、日常的事务处理(插入、修改、查询删除操作),例如银行交易、门票在线销售系统
  • 关系型和NOSQL-->数据切分-->垂直切分+水平切分1、 OLTP 和 OLAP 在互联网时代,海量数据的存储与访问成为系统设计与使用的瓶颈问题,对于海量数据处理,按照使用场景,主要分为两种类型:联机事务处理(OLTP)...

空空如也

空空如也

1 2 3 4 5 ... 14
收藏数 280
精华内容 112
关键字:

交易型和分析型数据库