mirror of
https://github.com/chai2010/advanced-go-programming-book.git
synced 2025-05-29 16:22:21 +00:00
22 lines
2.2 KiB
Markdown
22 lines
2.2 KiB
Markdown
# 6.x. 分布式搜索引擎
|
||
|
||
在 web 一章中，我们提到 MySQL 很脆弱。数据库系统本身要保证实时和强一致性，所以其功能设计上都是为了满足这种一致性需求。比如 write ahead log 的设计，基于 B+ 树实现的索引和数据组织，以及基于 MVCC 实现的事务等等。
|
||
|
||
关系型数据库一般被用于实现 OLTP 系统，所谓 OLTP，援引 wikipedia:
|
||
|
||
> 在线交易处理（OLTP, Online transaction processing）是指透过信息系统、电脑网络及数据库，以线上交易的方式处理一般即时性的作业数据，和更早期传统数据库系统大量批量的作业方式并不相同。OLTP通常被运用于自动化的数据处理工作，如订单输入、金融业务…等反复性的日常性交易活动。和其相对的是属于决策分析层次的联机分析处理（OLAP）。
|
||
|
||
在互联网的业务场景中，也有一些实时性要求不高(可以接受多 s 的延迟)，但是查询复杂性却很高的场景。举个例子，在电商的 wms 系统中，或者在大多数业务场景丰富的 crm 或者客服系统中，可能需要提供几十个字段的随意组合查询功能。这种系统的数据维度天生众多，比如一个电商的 wms 中对一件货物的描述，可能有下面这些字段：
|
||
|
||
> 仓库 id，入库时间，库位分区 id，储存货架 id，入库操作员 id，出库操作员 id，库存数量，过期时间，sku 类型，产品品牌，产品分类，内件数量
|
||
|
||
除了上述信息，如果商品在仓库内有流转。可能还有有关联的流程 id，当前的流转状态等等。
|
||
|
||
想像一下，如果我们所经营的是一个大型电商，每天有千万级别的订单，那么在这个数据库中查询和建立合适的索引都是一件非常难的事情。
|
||
|
||
在 CRM 或客服类系统中，常常有根据关键字进行搜索的需求，大型互联网公司每天会接收数以万计的用户投诉。而考虑到事件溯源，用户的投诉至少要存 2~3 年。又是千万级甚至上亿的数据。根据关键字进行一次 like 查询，可能整个 MySQL 就直接挂掉了。
|
||
|
||
这时候我们就需要搜索引擎来救场了。
|
||
|
||
## 搜索引擎
|