大数据引擎简单理解
大数据引擎简单理解
大数据引擎简单理解
Hbase
1.通过ZK来给客户端分配HRegionServer
2.整个架构为ZK->HRegionServer->HRegion->Store->HFile
2.HRegion为一个分区，可通过加盐的方式避免热点分区
3.Store对应一个列族来管理存储，一个HRegion内可有多个Store
4.HFile对应存储的所有key-Value，key 由RowKey(行键)+ColumnFamily（列族）+Column Qualifier（列修饰符）+TimeStamp（时间戳–版本）+KeyType（类型）组成 ,基于 时间戳顺序排列
5.会将变动缓存起来， 当MemStore超过一定阈值，就会将内存中的数据刷写到硬盘上，形成
StoreFile
，而StoreFile底层是以
HFile
的格式保存 。
6.Hlog把操作记录顺序写磁盘防止宕机
7.Hbase的增删改查是通过追加记录+合并文件完成的
8.每次查询都会遍历Store中对应的所有记录（HFile），从最新的开始查询，查到就返回。查询的时候会做性能优化，HFile自带布隆过滤器，有序遍历也有优化。
9.增删改都是生成新文件记录，其中删除时生成一条给key打删除标记的记录，然后在合并小HFile的过程中再删除旧记录， HBase中实现这种机制采用的是LSM树（ 日志结构合并树 ,一种NOSQL系统广泛使用的结构），LSM能够将多个内部key有序的小HFile文件合并生成一个大的HFile文件 。
**缺点：**查询效率不够稳定，偶尔数据由于布隆过滤器或者藏得比较深的原因可能耗时就比较大。依赖Hadoop环境导致使用起来比较复杂，配置的东西多。
Apache Phoenix
RocksDb
1.内嵌特性，典型使用，flink的状态存储引擎，多用在ssd硬盘上
- 该数据库没有独立进程，而是被集成进应用中，和应用共享内存等资源，从而避免了跨进程通信的开销
- 它没有内置服务器，无法通过网络进行远程访问。
- 它不是分布式的，这意味着它不提供容错性、冗余或分片（sharding）机制。
2.基于LSM树， MemTable 是一个内存缓冲区 ，和hbase的MemStore一样，缓存完毕就刷到磁盘中了
3.增删改查都是以日志的格式追加的
4.同样有预写日志机制， RocksDB 会将所有更新写入到磁盘上的预写日志（WAL，Write-ahead log）中
5.RocksDB 使用一个专门的后台线程定期地把不可变的 MemTable 从内存持久化到磁盘。一旦刷盘（flush）完成，不可变的 MemTa 入新的 WAL、MemTable。每次刷盘都会在 L0 层上产生一个新的 SST 文件。该文件一旦写入磁盘后，就不再会修改。
RocksDB 的 MemTable 的默认基于跳表实现。该数据结构是一个具有额外采样层的链表，从而允许快速、有序地查询和插入数据。有序性使得 MemTable 刷盘时更高效，因为可以直接按顺序迭代键值对顺序写入磁盘。 将随机写变为顺序写是 LSM-Tree 的核心设计之一 。
6.尽管 SST 中的 kv 对是有序的，我们也并非总能进行二分查找，尤其是数据块在压缩过后，会使得查找很低效。RocksDB 使用索引来优化查询，存储在紧邻数据块之后的索引块。I ndex 会把每个 block 数据中最后一个 key 映射到它在磁盘上的对应偏移量 。同样地，index 中的 key 也是有序的，因此我们可以通过二分搜索快速找到某个 key。
7.RocksDB 引入了压实（ Compaction ）机制，可以降低空间放大和读放大，但代价是更高的写放大。Compaction 会将某层的 SST 文件合并，并在这个过程中丢弃已删除和被覆盖的无效 key。Compaction 会在后台专用的线程池中运行，从而保证了 RocksDB 可以在做 Compaction 时能够正常处理用户的读写请求。
Leveled Compaction 是 RocksDB 中的默认 Compaction 策略。使用 Leveled Compaction，L0 层中的不同 SST 文件键范围会重叠。L1 层及以下层会被组织为包含多个 SST 文件的序列，并保证同层级内的所有 SST 在键范围上没有交叠，且 SST 文件之间有序。Compaction 时，会选择性地将某层的 SST 文件与下一层的 key 范围有重叠 SST 文件进行合并。
MongoDB
我理解，业务场景就是，一个key，把一个场景下所有要用的数据全部查询出来！。
网站数据：Mongo 非常适合实时的插入,更新与查询，并具备网站实时数据存储所需的复制及高 度伸缩性。
● 缓存：由于性能很高，Mongo 也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo 搭建的持久化缓存层可以避免下层的数据源过载。
● 大尺寸、低价值的数据：使用传统的关系型数据库存储一些大尺寸低价值数据时会比较浪费， 在此之前，很多时候程序员往往会选择传统的文件进行存储。
● 高伸缩性的场景：Mongo 非常适合由数十或数百台服务器组成的数据库，Mongo 的路线图中 已经包含对MapReduce 引擎的内置支持以及集群高可用的解决方案。
● 用于对象及JSON 数据的存储：Mongo 的BSON 数据格式非常适合文档化格式的存储及查询。
1）游戏场景，使用 MongoDB 存储游戏用户信息，用户的装备、积分等直接以内嵌文档的形式存 储，方便查询、更新。
2）物流场景，使用 MongoDB 存储订单信息，订单状态在运送过程中会不断更新，以 MongoDB 内 嵌数组的形式来存储，一次查询就能将订单所有的变更读取出来。
3）社交场景，使用 MongoDB 存储存储用户信息，以及用户发表的朋友圈信息，通过地理位置索引 实现附近的人、地点等功能。
4）物联网场景，使用 MongoDB 存储所有接入的智能设备信息，以及设备汇报的日志信息，并对这 些信息进行多维度的分析。
5）直播，使用 MongoDB 存储用户信息、礼物信息等。
使用条件
ES与mongodb区别
MongoDB 是一个典型的NoSQL（not only sql）数据库是开源的面向文档的数据库管理系统，主要实现NoSQL数据库管理系统，用于存储海量数据（humongous，Mongo名称的由来）。。
ElasticSearch是基于Apache Lucene 的RESTful 实时搜索和分析引擎。ES基于数据抽取一些值，提供实时存储、索引、搜索和分析数据功能，这些数据收集自其他数据源(包括MongoDB)，可以直接存储在Elasticsearch集群中。 一、共同点：
面向文档存储，无Schema，分布式数据存储，高可用性，分片和复制等。虽然使用ElasticSearch作为主数据存储是可行的，但一般做为主数据库的辅助数据库。
二、不同点：
1、Elasticsearch是java编写，通过RESTFul接口操作数据。MongoDB是C++编写，通过driver操作数据。
2、MongoDB的分片有hash和range两种方式，Elasticsearch只有hash一种。
3、Elasticsearch是天生分布式，主副分片自动分配和复制，开箱即用。MongoDB的分布式是由“前置查询路由+配置服务+shard集合”，需要手动配置集群服务。
4、内部存储ES是倒排索引+docvalues+fielddata。
5、Elasticsearch全文检索有强大的分析器且可以灵活组合，查询时智能匹配。MongoDB的全文检索字段个数有限制。
6、Elasticsearch所有字段自动索引，MongoDB的字段需要手动索引。Elasticsearch 使用 Apache Lucene 实现索引，而 MongoDB 索引是基于传统的B+ 树结构。Elasticsearch利用Lucene实现实时索引和搜索功能，默认支持在文档的每个字段上创建索引。而 MongoDB,我们必须定义索引用于提升查询性能，但会影响写操作。
7、Elasticsearch非实时有数据丢失窗口。mongodb实时理论上无数据丢失风险。
8、文档 - Elasticsearch 存储 JSON 文档, MongoDB 采用BSON格式存储 (Binary JSON)。
9、REST 接口 - Elasticsearch 提供 RESTful接口，MongoDB 不提供 RESTful接口。
10、MapReduce - MongoDB 支持 MapReduce 数据操作。 Elasticsearch 不支持 MapReduce。
三、使用场景：
MongoDB是通用功能的非RESTful风格的 NoSQL 数据库. 文档以 BSON 格式存储，主要用于存储数据。
Elasticsearch 是分布式全文检索引擎，可以提供实时Restful风格API处理海量面向文档的数据。文档使用JSON格式，主要用于基于文本的数据搜索。
在实际应用中两者通常同时使用，Elasticsearch一般不作为主存储数据库，而是和SQL & NoSQL数据库一起使用，作为辅助数据库。 与MongoDb不同, Elasticsearch 默认没有提供安全特性，如认证和授权。Elasticsearch和 Logstash & Kibana 一起称为ELK stack，用于快速查询数据并可视化展现分析数据。
Elasticsearch 非常适合需要基于文本进行快速索引然后进行检索，其查询速度非常快，大多数情况速度最多几十毫秒。
因此，Elasticsearch 通常作为主数据库存储的辅助存储库。一般数据库系统更聚焦于约束、准确性和健壮性。当主记录在事务中更新时，其会同时被推送至Elasticsearch中。
一般典型使用PostgreSQL 和 ZooKeeper 负责数据的存储, 同时提供给Elasticsearch实现实时检索。
hbase 和 MongoDB 对比
HBase 和 MongoDB 都是NoSQL数据库，它们在很多方面都有相似的特点，也存在一些不同。以下是它们的对比：
\1. 数据模型
HBase 的数据模型类似于关系型数据库的表格结构，具有列族和列的概念。MongoDB 的数据模型是基于文档的，数据以 BSON 格式存储，不需要固定的模式。
\2. 数据存储
HBase 的数据存储在 HDFS 文件系统中，数据量较大时性能较好。MongoDB 默认使用单个节点的方式存储数据，适合小数据量应用。
\3. 数据一致性
HBase 保证强一致性，即所有节点的数据都是一致的；MongoDB 提供的是最终一致性，即数据在一段时间后会达成一致。
\4. 查询
HBase 支持复杂查询，但在大数据量场景下性能会有所下降；MongoDB 支持更加灵活的查询方式，具有更好的性能表现。
\5. 数据分区和分片
HBase 具有自动分区和分布式的能力，可以针对集群节点进行数据分散。MongoDB 具有自动分片和副本集的能力，可以更好的应对大规模数据和高吞吐量的应用场景。
总之，HBase 更适合大规模数据的存储和高吞吐量的应用场景，但在查询上不如 MongoDB；MongoDB 更加灵活和易于使用，适合小数据量的应用场景，但在数据分布和一致性上不如 HBase。
各种数据库适用场景
Redis、MongoDB、MySQL和Elasticsearch（ES）都是常用的数据库系统，各有不同的特点和适用场景，具体区别如下：
Redis：
Redis是一种高性能键值存储数据库，基于 内存操作 ，支持数据持久化，支持数据类型丰富灵活，如字符串、哈希、列表、集合、有序集合等。Redis还提供了订阅/发布、事务、Lua脚本、主从同步等功能，适用于访问频繁、数据量较小，对性能要求较高的业务场景，如缓存、队列、计数器、排行榜等应用。
MongoDB：
MongoDB是一种面向文档的NoSQL数据库系统， 数据存储方式为文档格式 ，支持嵌套结构和灵活的数据模型，方便开发者存储、查询和修改数据。MongoDB还提供了分布式存储、数据复制、故障转移等高可用性功能，适用于对数据结构灵活性要求较高、数据量较大的业务场景，如日志、社交网络、推荐系统等应用。
MySQL：
MySQL是一种流行的 关系型数据库系统 ，采用SQL语言进行数据操作，支持多表关联、事务、索引等高级功能。MySQL适用于高度结构化的数据存储，支持大规模数据集的管理和复杂的查询，适用于数据量不大但是交互频繁的应用，如电子商务、ERP系统等。
Elasticsearch（ES）：
ES是基于文档的 全文搜索引擎 ，可以对文本数据进行实时分析和搜索处理，具有高效的数据检索和聚合分析能力。ES基于倒排索引实现搜索、文本分析、动态映射、高亮显示等功能，适用于需要实时搜索和分析数据的业务场景，如日志分析、搜索引擎、多语言全文检索等应用。
概念
空间放大、读放大
空间放大（space amplifications）和读放大（read amplifications）。空间放大是存储数据所用实际空间与逻辑上数据大小的比值。假设一个数据库需要 2 MB 磁盘空间来存储逻辑上的 1 MB 大小的键值对是，那么它的空间放大率是 2。类似地，读放大用来衡量用户执行一次逻辑上的读操作，系统内所需进行的实际 IO 次数。
跳表和B+树的优劣
Mysql的索引为什么使用B+树而不使用跳表？
B+树 是多叉树结构，每个结点都是一个16k的数据页，能存放较多索引信息。 三层 左右就可以存储2kw左右的数据。也就是说查询一次数据，如果这些数据页都在磁盘里，那么 最多需要查询三次磁盘IO 。
跳表 是链表结构，一条数据一个结点，如果最底层要存放2kw数据，且每次查询都要能达到 二分查找 的效果，2kw大概在2的24次方左右，所以，跳表大概高度在 24层 左右。最坏情况下，这24层数据会分散在不同的数据页里，也即是 查一次数据会经历24次磁盘IO 。
因此存放同样量级的数据，B+树的高度比跳表的要少，如果放在mysql数据库上来说，就是 磁盘IO次数更少，因此B+树查询更快 。
而针对 写操作 ，B+树需要拆分合并索引数据页，跳表则独立插入，并根据随机函数确定层数，没有旋转和维持平衡的开销，因此 跳表的写入性能会比B+树要好。
redis为什么使用跳表而不使用B+树或二叉树呢？
redis支持多种数据结构，里面有个 有序集合 ，也叫 ZSET 。内部实现就是 跳表 。那为什么要 用跳表而不用B+树等结构呢？
大家知道，redis 是纯纯的内存数据库。进行读写数据都是操作内存，跟磁盘没啥关系，因此也 不存在磁盘IO 了，所以层高就不再是跳表的劣势了。并且前面也提到B+树是有一系列合并拆分操作的，换成红黑树或者其他AVL树的话也是各种旋转，目的也是 为了保持树的平衡 。而跳表插入数据时，只需要随机一下，就知道自己要不要往上加索引，根本不用考虑前后结点的感受，也就 少了旋转平衡的开销 。因此，redis选了跳表，而不是B+树。