https://www.cnblogs.com/darcy-yuan/category/2257608.html
最近阅读了elasticsearch的官方文档，学习了它的很多特性，发现elasticsearch和mysql有很多地方类似，也有很多地方不同。这里做一个对比，帮助大家加深对elasticsearch的理解。
|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| 特性 | elasticsearch | mysql | 备注 |
| 场景 | 全文搜索，日志处理，空间数据分析 | 表结构存储 | es 不适合做join操作，mysql 不适合做全文检索 |
| 扩展性 | 动态扩展，能够通过添加node快速提升性能 | mysql cluster | |
| master 选举 | bully 算法，比较id选出master | master-slave结构，无需选举 | es中master选举可能会出现脑裂问题，配置 minimum_master_nodes参数确保过半选举决定机制 |
| 路由算法 | routing_factor = num_routing_shards / num_primary_shards shard_num = (hash(_routing) % num_routing_shards) / routing_factor 指定路由分片： my-index-000001/_doc/1?routing=user1&refresh=true | 手动路由，或者使用路由组件sharding-jdbc | |
| 可靠性 | Cross-cluster replication (CCR)， 双集群设计 | 主从复制，双数据中心 | |
| 内存配置 | heap size 推荐 32g，但不要超过内存的一半, 其他需要用到堆外内存的地方，网络，文件缓存，jvm的栈 | 物理内存的80% | 单独的服务器 |
| 缓存 | filesystem cache, request cahce, query cache 所有cache都是基于node | query cache (deprecated) | |
| 数据块大小 | 分片大小 几g ~ 几十g， time based data， 20g ~ 40g 分片数量，每g内存小于20分片 shard越多，维护索引成本越高 shard越大，rebalance越慢 | 单表数据不超过2kw，3层b+树能存储的数据大概是2kw，如果b+层级变高，查询速度会显著降低 | |
| 数据结构 | json，底层是lucene | table，底层是b+ tree | |
| 索引 | 倒排表，fst 正向文件，分块 + 压缩 DocValues, 映射文件 + 压缩 | b+数，聚簇/非聚簇索引 | |
| 定义数据结构的方式 | mapping (dynamic mapping & static mapping) | schema | |
| 支持自动创建数据结构 | 是 | 否 | |
| 事务 | near real-time，需要refresh才可以查询到 | reaptable read，高级事务 | |
| 锁 | Index blocks，比如 index.blocks.read_only，索引只读 | 丰富的锁机制，表锁，行锁，间隙锁 | |
| 文件系统 | 默认mmapfs，采用内存映射方式访问文件，也支持其他的文件系统，比如fs, niofs, hybirdfs | fs | |
| 数据恢复 | es在写入之前会先将数据写入到translog，用来对异常情况进恢复 flush，lucene 进行提交，并且同时重新开启一段 translog index.translog.sync_interval，持久化translog 间隔，5s index.translog.flush_threshold_size， flush translog阈值大小，512m | redo log采用的是WAL（Write-ahead logging，预写式日志），所有修改先写入日志，再更新到Buffer Pool，保证了数据不会因MySQL宕机而丢失，从而满足了持久性要求 | es 和 mysql 处理数据恢复的模式基本一致 |
| flush机制 | 从内存缓存写入磁盘缓存memorybuffer -> filesystem cache（refresh） 刷盘，filesystem cache -> disk ( flush) 定时触发或者 translog > 512M | buffer pool -> disk 当redo log满了，或者buffer pool空间不足 | es 和 mysql 刷盘模式基本一致 |
| 备份 | snapshot | mysqldump -u root -h host -p --all-databases > backdb.sql | |
| 慢日志 | 比如 index.search.slowlog.threshold.query.warn: 10s | long_query_time=10 | |
| 服务调用方式 | rest api | mysql connection + sql | |
| 数据类型 | 较为丰富的数据类型，boolean, keyword, long, data, object, nested, range, ip, text, arrays | int, data, varchar | es 提供了非常多的数据类型，一些是为了支持全文检索，一些能够方便查询，比如range，ip |
| 数据属性 | analyzer，分词器 index，是否被索引，没有被索引的字段不可查询 fielddata，如果想对text类型的字段进行聚合，排序，或者执行脚本，就必须设置fielddata属性 doc_values，将_source 转化为表结构放在磁盘上，方便聚合，排序，或者脚本操作，默认支持除了text类型的所有类型 ... | 主键索引, 可空，唯一值，自增，默认值 | es的数据属性更复杂 |
| 查询超时 | 设置 query timeout | set wait_timeout = 10 | |
| context | es查询需要区分query context， 还是 filter context，前者会进行打分，后者只进行过滤 | 不需要区分 | |
| 打分查询 | 比如match，match_phrase | 不支持 | |
| runtime field | 使用script 创建临时字段 | 语法支持 select concat (a, b) as c | script更灵活，但是性能会降低 |
| 精确查询 | 比如term, terms, ids, exists | 语法支持 | mysql使用起来更方便 |
| 分组聚合查询 | 比如histogram aggs，terms aggs | group by | es支持的类型稍微丰富一些，方便开发 |
| 指标聚合查询 | avg, max, min, sum ,count, cardinality aggs，percentile aggs | 语法支持, count(*), distinct | es是分布式的，聚合的时候存在一些精度问题 |
| 分页 | from + size （不适合深分页，有去重问题） search_after + PIT （推荐） scroll (不适合深分页) | limit + size 或者进行条件关联，书签 | 在深分页上的处理方案上基本一致 |
| profile | { "profile": true, "query" : { "match" : { "message" : "GET /search" } } } | explain | |
| script支持 | painless script | 不支持 | |