问题:大规模数据如何检索
- 当系统数据量达到10亿，100亿级别的时候，我们系统该如何去解决这种问题。
- 数据库选择—mysql， sybase，oracle，mongodb，hbase…
- 单点故障如何解决—lvs， F5，A10，Zookeeper，MQ
- 如何保证数据安全----热备，冷备，异地多活
- 如何解决检索难题—数据库中间件mysql-proxy，sharding， cobar， MaxScale
- 如何积极统计分析问题—离线计算，近实时
- 传统数据库的应对解决方案，对于关系型数据库，通常用以下架构解决查询瓶颈
- 通过主从备份解决数据安全性问题
- 通过数据库代理中间件心跳检测，解决单点故障问题
- 通过代理中间件将查询语句分发到每个slave节点查询，并且汇总结果
- 非关系型数据库解决方案，用MongoDB为案例，其他的原理类似
- 通过副本备份积极数据安全性问题
- 通过节点竞选机制解决单点问题
- 先从配置库检索分片信息，让后请求分发到各个节点，最后由路由节点合并汇总结果。
- 用内存数据库
- 不可能完全在内存中放所有数据，单达到PB级别的时候，每个节点按256G，在内存完全装满情况下我们需要如下个机器 1PB = 1024T = 1024*1024G，节点1024 * 4 = 4096个，加上备份的数据，节点应该会超过4096 * 2 = 8192个，太费钱
- 不管是否全部放内存都不能完全解决问题，用一下方式
- 存储数据按有序存储
- 将数据和索引分离、
- 压缩数据
luncene与 ES
- luncene只是一个检索库，要想使用必须用java开发并且集成到你项目中，并且luncene非常复杂，需要深入了解检索的相关知识来理解他是如何工作的。
- Elasticsearch使用luncene作为底层查询，用java开发，通过RESTful api来隐藏Lucene的复杂性，使用只需关注api就行，降低接入成本以及复杂度。
ES主要解决问题
- 检索相关数据
- 返回统计结果
- 速度快
原理
- 当ElasticSearch的节点启动后，会利用多播（multicast）或者单播（配置修改）寻找集群中其他节点，并且建立连接，过程如下：
核心概念
- 集群：ES可以作为独立的搜索服务器，不过处理的数据局限于单点存储功能，可以通过多借点相互合作的多服务器上，实现大小数据集检索，实现容错和高可用。
- 分片：文档巨大，内存限制，磁盘处理能力不足，无法足够快的响应查询，一个节点存储不够。这些情况，数据可以分开成多个较小的分片，每个分片在不同的服务器上。单查询的索引分布在多个分片上，ES会将查询发送给每一个分片，并将结果组合起来，对应用透明。
- 副本：为提供吞吐量或者实现高可用，可以使用分片副本，副本是一个分片的Slave，每个分片可以有多个副本，ES可以有许多相同的分片，其中一个被选中更改索引操作，这种分片是主分片。单主分片丢失，集群将副本某一个提升为主分片
- 全文检索：将内容根据词的意义进行分词，让后分别创建索引例如：
- “你们的动力是因为什么事情来的” 可分为：“你们”，“动力”，“什么事情”，“来”等token，当搜索你们，或者动力时候都会讲这个段搜索出来。
ES数据架构主要概念（mySql对比）
- 关系型数据库中数据库（DB）等价es中索引（index）
- 一个数据库下面N张表（table），等价1个索引下N多属性（Type）
- 一个数据库表（table）下的数据由多行，多列组成，等价es中1个Type由多Document和多个Field组成
- 关系型数据库里面，Schema定义了表，每个表的字段，还有表与字段直接的关系，与之对应的ES中：Mapping定义索引下的Type的字段处理规则，即索引如何建立，索引类型，是否保存原始索引JSON文档，是否压缩原始JSON文档，是否需要分词处理，如何进行分词等。
- 数据库中CURD操作等价ES中 增PUT/POST，删Delete，改_update，查GET(标准RESTful)
ELK： elasticsearch+Logstash+kibana
- elasticsearch:后台分布式存储以及全文检索
- logstash：日志加工，日志统计
- kibana：数据可视化展示
- ELK架构为数据分布式存储，可视化查询和日志解析创建了一个功能强大的管理链，三者相互配合完成分布式大数据处理工作。
[新浪ES 如何分析处理32亿条实时日志 ]( <http://dockone.io/article/505 )
特定优势
- 分布式实时文件存储，索引可到某个字段级别检索
- 实时分析的分布式搜索引擎
- 分布式：索引拆分成多个分片，每个分片可有多个副本，集群每个数据节点都可以承载一个或多个分片，并且协调和处理各种操作。
- 负载再平衡和路由大多数情况自动完成
- 可扩展到上百条服务器，处理PB级别结构化或者非结构化数据，也可单机
- 支持插件机制，分词插件，hadoop插件，可视化插件等
倒排索引
- 搜索引擎通常检索的场景是：给的几个关键字，找出包含关键字的文档。怎么快速找到包含某个关键字的文档就成为搜索的关键，倒排索引源于实际应用中需要根据属性的值来查找记录，lucene是基于倒排索引实现的，这种索引表中的每一项都包括一个属性值和具有改属性值的各个记录的地址，由于不是由记录来确认属性值，而是由属性值来确定记录的位置，所以称为倒排索引
正排索引
- 正排索引是以文档的ID为关键字，表中记录文档中每个字的位置信息，查找时候扫描表中每个文档中字的信息直到找出所有包含查询关键字的文档。查询效率相对来说不高。
总结：倒排索引记录了某个关键字在那些文档中，正排索引记录了文档包含了哪些关键字
问题：倒排索引比关系型数据库的b-tree索引快在哪里？