礼品网站建设公司,什么是php网站开发,校园微网站建设方案ppt模板下载,商城网站建设开发公司目录
一、DMP#xff1a;数据管理平台
二、MongoDB 真的万能吗
三、关系型数据库#xff1a;不得不做的随机读写
#xff08;一#xff09;Cassandra#xff1a;顺序写和随机读
1、Cassandra 的数据模型
2、Cassandra 的写操作
3、Cassandra 的读操作
#xff08…目录
一、DMP数据管理平台
二、MongoDB 真的万能吗
三、关系型数据库不得不做的随机读写
一Cassandra顺序写和随机读
1、Cassandra 的数据模型
2、Cassandra 的写操作
3、Cassandra 的读操作
二SSDDBA 们的大救星 一、DMP数据管理平台
DMP 系统的全称叫作数据管理平台Data Management Platform目前广泛应用在互联网的广告定向Ad Targeting、个性化推荐Recommendation这些领域。
DMP 系统会通过处理海量的互联网访问数据以及机器学习算法给一个用户标注上各种各样的标签。然后在做个性化推荐和广告投放的时候再利用这些标签去做实际的广告排序、推荐等工作。无论是 Google 的搜索广告、淘宝里千人千面的商品信息还是抖音里面的信息流推荐背后都会有一个 DMP 系统。
对于外部使用 DMP 的系统或者用户来说可以简单地把 DMP 看成是一个键 - 值对Key-Value数据库。广告系统或者推荐系统可以通过一个客户端输入用户的唯一标识ID然后拿到这个用户的各种信息。
这些信息中有些是用户的人口属性信息Demographic比如性别、年龄有些是非常具体的行为Behavior比如用户最近看过的商品是什么用户的手机型号是什么有一些是通过算法系统计算出来的兴趣Interests比如用户喜欢健身、听音乐还有一些则是完全通过机器学习算法得出的用户向量给后面的推荐算法或者广告算法作为数据输入。
基于此对于这个 KV 数据库我们的期望也很清楚那就是低响应时间Low Response Time、高可用性High Availability、高并发High Concurrency、海量数据Big Data付得起对应的成本Affordable Cost。如果用数字来衡量这些指标那么我们的期望就会具体化成下面这样。
低响应时间一般的广告系统留给整个广告投放决策的时间也就是 10ms 左右所以对于访问 DMP 获取用户数据预期的响应时间都在 1ms 之内。高可用性DMP 常常用在广告系统里面。DMP 系统出问题往往就意味着整个的广告收入在不可用的时间就没了所以对于可用性的追求可谓是没有上限的。Google 2018 年的广告收入是 1160 亿美元折合到每一分钟的收入是 22 万美元。即使我们做到 99.99% 的可用性也意味着每个月我们都会损失 100 万美元。高并发还是以广告系统为例如果每天我们需要响应 100 亿次的广告请求那么我们每秒的并发请求数就在 100 亿 / (86400) ~ 12K 次左右所以DMP 需要支持高并发。数据量如果产品针对中国市场那么需要有 10 亿个 Key对应的假设每个用户有 500 个标签标签有对应的分数。标签和分数都用一个 4 字节Bytes的整数来表示那么一共需要 10 亿 x 500 x (4 4) Bytes 4 TB 的数据。低成本从广告系统的角度来考虑广告系统的收入通常用 CPMCost Per Mille也就是千次曝光来统计。如果千次曝光的利润是 0.10 美元那么每天 100 亿次的曝光就是 100 万美元的利润。这个利润听起来非常高了。但是反过来算一下DMP 每 1000 次的请求的成本不能超过 0.10 美元。最好只有 0.01 美元甚至更低才能尽可能多赚到一点广告利润。为了能够生成这个 KV 数据库我们需要有一个在客户端或者 Web 端的数据采集模块不断采集用户的行为向后端的服务器发送数据。服务器端接收到数据就要把这份数据放到一个数据管道Data Pipeline里面。数据管道的下游需要实际将数据落地到数据仓库Data Warehouse把所有的这些数据结构化地存储起来。后续就可以通过程序去分析这部分日志生成报表或者或者利用数据运行各种机器学习算法。
除了数据仓库之外还会有一个实时数据处理模块Realtime Data Processing也放在数据管道的下游。它同样会读取数据管道里面的数据去进行各种实时计算然后把需要的结果写入到 DMP 的 KV 数据库里面去。
二、MongoDB 真的万能吗
MongoDB 的设计听起来特别厉害不需要预先数据 Schema访问速度很快还能够无限水平扩展。作为 KV 数据库可以把 MongoDB 当作 DMP 里面的 KV 数据库除此之外MongoDB 还能水平扩展、跑 MQL可以把它当作数据仓库来用。至于数据管道只要我们能够不断往 MongoDB 里面插入新的数据就好了。从运维的角度来说只需要维护一种数据库技术栈也变得简单了。看起来MongoDB 这个选择真是相当完美
然而所有的软件系统都有它的适用场景想通过一种解决方案适用三个差异非常大的应用场景显然既不合理又不现实。接下来我们就来仔细看一下这个“不合理”“不现实”在什么地方。
对于数据管道来说我们需要的是高吞吐量它的并发量虽然和 KV 数据库差不多但是在响应时间上要求就没有那么严格了1-2 秒甚至再多几秒的延时都是可以接受的。而且和 KV 数据库不太一样数据管道的数据读写都是顺序读写没有大量的随机读写的需求。
数据仓库就更不一样了数据仓库的数据读取量要比管道大得多。管道的数据读取就是当时写入的数据一天有 10TB 日志数据管道只会写入 10TB。下游的数据仓库存放数据和实时数据模块读取的数据再加上个 2 倍的 10TB也就是 20TB 也就够了。但是数据仓库的数据分析任务要读取的数据量就大多了。一方面我们可能要分析一周、一个月乃至一个季度的数据。这一次分析要读取的数据可不是 10TB而是 100TB 乃至 1PB。我们一天在数据仓库上跑的分析任务也不是 1 个而是成千上万个所以数据的读取量是巨大的。另一方面我们存储在数据仓库里面的数据也不像数据管道一样存放几个小时、最多一天的数据而是往往要存上 3 个月甚至是 1 年的数据。所以我们需要的是 1PB 乃至 5PB 这样的存储空间。 在 KV 数据库的场景下需要支持高并发。那么 MongoDB 需要把更多的数据放在内存里面但是这样存储成本就会特别高了。
在数据管道的场景下需要大量的顺序读写而 MongoDB 则是一个文档数据库系统并没有为顺序写入和吞吐量做过优化看起来也不太适用。
数据仓库的场景下主要的数据读取时顺序读取并且需要海量的存储。MongoDB 这样的文档式数据库也没有为海量的顺序读做过优化仍然不是一个最佳的解决方案。而且文档数据库里总是会有很多冗余的字段的元数据还会浪费更多的存储空间。
那我们该选择什么样的解决方案呢其实并不难找。
对于 KV 数据库最佳的选择方案自然是使用 SSD 硬盘选择 AeroSpike 这样的 KV 数据库。高并发的随机访问并不适合 HDD 的机械硬盘而 400TB 的数据如果用内存的话成本又会显得太高。
对于数据管道最佳选择自然是 Kafka。因为我们追求的是吞吐率采用了 Zero-Copy 和 DMA 机制的 Kafka 最大化了作为数据管道的吞吐率。而且数据管道的读写都是顺序读写所以也不需要对随机读写提供支持用上 HDD 硬盘就好了。
对于数据仓库存放的数据量更大了。2019年的应用场景下看在硬件层面使用 HDD 硬盘成了一个必选项否则存储成本就会差上 10 倍。但是SSD和几年前比已经便宜了很多了而且在PCI-E接口普及的情况下顺序读写速度比起HDD也能拉开差距了所以逐步我们也看到业界开始直接用SSD来部署Kafka也变得比较常见了。
这么大量的数据在存储上我们需要定义清楚 Schema使得每个字段都不需要额外存储元数据能够通过 Avro/Thrift/ProtoBuffer 这样的二进制序列化的方存储下来或者干脆直接使用 Hive 这样明确了字段定义的数据仓库产品。很明显MongoDB 那样不限制 Schema 的数据结构在这个情况下并不好用。
三、关系型数据库不得不做的随机读写
DMP 的 KV 数据库主要的应用场景是根据主键的随机查询。这个需求实际的大型系统中大家都会使用专门的分布式 KV 数据库来满足。
下面看一下Facebook 开源的 Cassandra 的数据存储和读写是怎么做的这些设计是怎么解决高并发的随机读写问题的。
一Cassandra顺序写和随机读
1、Cassandra 的数据模型
作为一个分布式的 KV 数据库Cassandra 的键一般被称为 Row Key。其实就是一个 16 到 36 个字节的字符串。每一个 Row Key 对应的值其实是一个哈希表里面可以用键值对再存入很多需要的数据。
Cassandra 本身不像关系型数据库那样有严格的 Schema在数据库创建的一开始就定义好了有哪些列Column。但是它设计了一个叫作列族Column Family的概念我们需要把经常放在一起使用的字段放在同一个列族里面。比如DMP 里面的人口属性信息我们可以把它当成是一个列族。用户的兴趣信息可以是另外一个列族。这样既保持了不需要严格的 Schema 这样的灵活性也保留了可以把常常一起使用的数据存放在一起的空间局部性。
往 Cassandra 的里面读写数据其实特别简单就好像是在一个巨大的分布式的哈希表里面写数据。指定一个 Row Key然后插入或者更新这个 Row Key 的数据就好了。
2、Cassandra 的写操作 Cassandra 解决随机写入数据的解决方案简单来说就叫作“不随机写只顺序写”。对于 Cassandra 数据库的写操作通常包含两个动作。第一个是往磁盘上写入一条提交日志Commit Log。另一个操作则是直接在内存的数据结构上去更新数据。后面这个往内存的数据结构里面的数据更新只有在提交日志写成功之后才会进行。每台机器上都有一个可靠的硬盘可以让我们去写入提交日志。写入提交日志都是顺序写Sequential Write而不是随机写Random Write最大化了写入的吞吐量。
内存的空间比较有限一旦内存里面的数据量或者条目超过一定的限额Cassandra 就会把内存里面的数据结构 dump 到硬盘上。这个 Dump 的操作也是顺序写而不是随机写所以性能也不会是一个问题。除了 Dump 的数据结构文件Cassandra 还会根据 row key 来生成一个索引文件方便后续基于索引来进行快速查询。
随着硬盘上的 Dump 出来的文件越来越多Cassandra 会在后台进行文件的对比合并。在很多别的 KV 数据库系统里面也有类似这种的合并动作比如 AeroSpike 或者 Google 的 BigTable。这些操作我们一般称之为 Compaction。合并动作同样是顺序读取多个文件在内存里面合并完成再 Dump 出来一个新的文件。整个操作过程中在硬盘层面仍然是顺序读写。
3、Cassandra 的读操作 要从 Cassandra 读数据的时候先从内存里面找再从硬盘读然后把两部分的数据合并成最终结果。这些硬盘上的文件在内存里面会有对应的 Cache只有在 Cache 里面找不到才会去请求硬盘里面的数据。
如果不得不访问硬盘按照时间从新的往旧的里面找因为硬盘里面可能 Dump 了很多个不同时间点的内存数据的快照。
这也就带来另外一个问题——可能要查询很多个 Dump 文件才能找到想要的数据。所以Cassandra 在这一点上又做了一个优化。那就是它会为每一个 Dump 的文件里面所有 Row Key 生成一个 BloomFilter然后把这个 BloomFilter 放在内存里面。这样如果想要查询的 Row Key 在数据文件里面不存在那么 99% 以上的情况下它会被 BloomFilter 过滤掉而不需要访问硬盘。这样只有当数据在内存里面没有并且在硬盘的某个特定文件上的时候才会触发一次对于硬盘的读请求。
二SSDDBA 们的大救星
Cassandra 是 Facebook 在 2008 年开源的。那个时候SSD 硬盘还没有那么普及。可以看到它的读写设计充分考虑了硬件本身的特性。在写入数据进行持久化上Cassandra 没有任何的随机写请求无论是 Commit Log 还是 Dump全部都是顺序写。
在数据读的请求上最新写入的数据都会更新到内存。如果要读取这些数据会优先从内存读到。这相当于是一个使用了 LRU 的缓存机制。只有在万般无奈的情况下才会有对于硬盘的随机读请求。即使在这样的情况下Cassandra 也在文件之前加了一层 BloomFilter把本来因为 Dump 文件带来的需要多次读硬盘的问题简化成多次内存读和一次硬盘读。
这些设计使得 Cassandra 即使是在 HDD 硬盘上也能有不错的访问性能。而对于数据的读就有一些挑战了。如果数据读请求有很强的局部性那内存就能搞定 DMP 需要的访问量。但是DMP 的数据访问分布其实是缺少局部性的。
如果是 Facebook 那样的全球社交网络那可能还有一定的时间局部性。毕竟不同国家的人的时区不一样。我们可以说在印度人民的白天把印度人民的数据加载到内存里面美国人民的数据就放在硬盘上。到了印度人民的晚上再把美国人民的数据换到内存里面来。如果主要业务是在国内那这个时间局部性就没有了。大家的上网高峰时段都是在早上上班路上、中午休息的时候以及晚上下班之后的时间没有什么区分度。
因为缺少时间局部性内存的缓存能够起到的作用就很小了大部分请求最终还是要落到 HDD 硬盘的随机读上。但是HDD 硬盘的随机读的性能太差了。如果全都放内存又太贵了。
幸运的是从 2010 年开始SSD 硬盘的大规模商用帮我们解决了这个问题。它的随机读的访问能力在 HDD 硬盘的百倍以上。同样的价格的 SSD 硬盘容量则是内存的几十倍也能够满足我们的需求用较低的成本存下整个互联网用户信息。
不夸张地说过去十年的“大数据”“高并发”“千人千面”有一半的功劳应该归在让 SSD 容量不断上升、价格不断下降的硬盘产业上。
回到 Cassandra 的读写设计你会发现Cassandra 的写入机制完美匹配SSD 硬盘的优缺点。
在数据写入层面Cassandra 的数据写入都是 Commit Log 的顺序写入也就是不断地在硬盘上往后追加内容而不是去修改现有的文件内容。一旦内存里面的数据超过一定的阈值Cassandra 又会完整地 Dump 一个新文件到文件系统上。这同样是一个追加写入。
数据的对比和紧凑化Compaction同样是读取现有的多个文件然后写一个新的文件出来。写入操作只追加不修改的特性正好天然地符合 SSD 硬盘只能按块进行擦除写入的操作。在这样的写入模式下Cassandra 用到的 SSD 硬盘不需要频繁地进行后台的 Compaction能够最大化 SSD 硬盘的使用寿命。因此Cassandra 在 SSD 硬盘普及之后获得了进一步快速发展。
【推荐阅读】Cassandra - A Decentralized Structured Storage System。读完这篇论文一方面你会对分布式 KV 数据库的设计原则有所了解了解怎么去做好数据分片、故障转移、数据复制这些机制另一方面你可以看到基于内存和硬盘的不同存储设备的特性Cassandra 是怎么有针对性地设计数据读写和持久化的方式的。
课程链接深入浅出计算机组成原理_组成原理_计算机基础-极客时间
