《 “数据库的分类和选型” 》 有 2 条评论

1. 一文读懂内存数据库
   https://mp.weixin.qq.com/s/MJnGKJutU8EqDeOv9aa7Vg
   `
   # Redis虽然好，但阿里云为何还力推Tair？

   对Key-Value数据库大家可能了解还是比较多，比如：
   Aerospike
   LevelDB
   Scalaris
   Project Voldemort
   HyperDex
   Berkeley DB
   Apache Accumulo
   Apache Cassandra
   Redis
   MongoDB
   Memcached

   其中，在近年来，Redis的表现尤为突出。这是为什么呢？

   没有比较就没有鉴别。那么，我们拿Memcached与Redis做一个简单的对比分析。作为一个高性能的key-value存储系统，Redis和Memcached有点类似，为了保证数据读写效率，在内存中实现了数据的缓存。

   但是，Redis实现了更好的功能。

   Redis虽好，然而开源Redis作为云内存数据库，却有着比较大的局限性。

   其一，在Redis Class下构建大容量服务，成本问题已经出现。在分片数较少，单个分片较大情况下，调用Fork同步操作带来服务不稳，同时持久化带来服务恢复缓慢，虽然采用主多从的形式来保证服务的可用性，但在多实例下，其管理成本和内部通信成本的开销增大。

   其二，Redis本身持久化数据的能力有限，最新版本推出了RDB和AOF两种模式来提升持久化能力。然而在实际应用中，Everysecond每秒持久化的形式十分不利于实际应用，特别是将Redis已经作为最终存储数据的数据库在应用，一旦出现问题，将波及大量的整体数据。“在一个如10万TPS高吞吐的场景下，一秒的数据丢失可能就意味着数万条数据记录的丢失。”对数据可靠性要求很高的用户来说，这是最大的问题。此外Redis缓存+主存储方式来提升持久化，也带来数据一致性、主从数据库开销等系列问题。

   # 青出于蓝而胜于蓝，十二年认真锤炼Tair

   2018年，Tair正式开始投入Intel AEP的研究和使用落地。并成功应用于当年双11的电商商品核心集群中，大幅降低了成本，成为中国首个在生产环境正式部署应用Intel AEP的产品。不过，当时的Tair软件层并没有在AEP上做相关数据持久化和恢复的特性，仅作为缓存使用。

   2019年4月，阿里云的云数据库Redis产品在Redis开源社区贡献排名第三。

   2020年9月，Tair正式推出持久存储系统形态，加速进入多存储引擎时代。随着云上环境的成熟，Tair基于AEP，全新研发了数据持久落地的自研引擎，并融入神龙裸金属服务器和云原生数据库管理系统的技术优势。整体能力上，获得了近似内存的性能，90%的吞吐能力，而成本降低了30%。同时，从内存的易失性到AEP的持久能力，Tair自研引擎的每个操作都能持久化，大幅降低数据丢失的风险。

   ……
   在硬件选择上，持久内存型采用了Intel 傲腾持久内存（AEP），容量存储型采用了阿里云ESSD云盘。

   英特尔傲腾（AEP）持久内存架构的特点突出，在DRAM内存和块存储之间，加入大容量持久内存层，数据不会丢失，同时以高性价比提供出色性能。Tair持久内存型采用Intel 傲腾（AEP）持久内存技术后，兼容绝大部分Redis数据结构和命令，借助AEP的App Direct模式，实现了高性能下的命令级持久化能力。在价格上，Tair持久内存型相当于阿里云社区版Redis价格的70%左右，适用于要求高吞吐、低延迟同时对数据可靠性要求高的热数据存取场景。

   然而，对于温冷数据存取场景，用户要求更高的数据持久化，以及更高的存储密度，数据访问频率也相对较低。基于阿里云ESSD云盘技术，推出的Tair容量存储型，兼容Redis核心数据结构与命令，满足用户超大容量、平均性能有所妥协的温冷数据存取服务。
   ……
   `

   回复

2. 数据仓库–通用的数据仓库分层方法 #nice，详细全面
   https://www.cnblogs.com/itboys/p/10592871.html
   `
   0x01 为什么要进行数据分层？

   数据分层并不能解决所有的数据问题，但是，数据分层却可以给我们带来如下的好处：

   清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解

   减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算

   统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径

   复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题

   0x02 一种通用的数据分层设计

   为了满足前面提到数据分层带来的好处，我们将数据模型分为三层：数据运营层(ODS)、数据仓库层(DW)和数据应用层(APP)。简单来讲，我们可以理解为：**ODS层存放的是接入的原始数据，DW层是存放我们要重点设计的数据仓库中间层数据，APP是面向业务定制的应用数据**。

   一、数据运营层：ODS（Operational Data Store）

   “面向主题的”数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。

   一般来讲，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。

   二、数据仓库层：DW（Data Warehouse）

   数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。DW层又细分为 DWD（Data Warehouse Detail）层、DWM（Data WareHouse Middle）层和DWS（Data WareHouse Servce）层。

   1. 数据明细层：DWD（Data Warehouse Detail）

   该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。

   另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性，后文会举例说明。

   2. 数据中间层：DWM（Data WareHouse Middle）

   该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。

   直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。

   3. 数据服务层：DWS（Data WareHouse Servce）

   又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

   一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。

   在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。

   三、数据应用层：APP（Application）

   在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

   四、维表层（Dimension）

   最后补充一个维表层，维表层主要包含两部分数据：

   高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

   低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。
   `

   回复