学Python编程能做什么工作？

1.6 大表场景

在未二次开发的 MYSQL 中，上亿的表肯定算大表，这种情况即使在索引、查询层面做到了较好实现，面对频繁聚合操作也可能会出现 IO 或 CPU 瓶颈，即使是单纯查询，效率也会下降。

且 Innodb 每个 B+ 树节点存储容量是 16 KB，理论上可存储 2kw 行左右，这时树高为3层。我们知道，innodb_buffer_pool 用来缓存表及索引，如果索引数据较大，缓存命中率就堪忧，同时 innodb_buffer_pool 采用 LRU 算法进行页面淘汰，如果数据量过大，对老或非热点数据的查询可能就会把热点数据给挤出去。

所以对于大表常见优化即是分库分表和读写分离了。

1.6.1 分库分表

方案

是分库还是分表呢？这要具体分析。

•  如果磁盘或网络有 IO 瓶颈，那就要分库和垂直分表。
•  如果是 CPU 瓶颈，即查询效率偏低，水平分表。

水平即切分数据，分散原有数据到更多的库表中。

垂直即按照业务对库，按字段对表切分。

工具方面有 sharding-sphere、TDDL、Mycat。动起手来需要先评估分库、表数，制定分片规则选 key，再开发和数据迁移，还要考虑扩容问题。

问题

实际运行中，写问题不大，主要问题在于唯一 ID 生成、非 partition key 查询、扩容。

• 唯一 ID 方法很多，DB 自增、Snowflake、号段、一大波GUID算法等。
•  非 partition key 查询常用映射法解决，映射表用到覆盖索引的话还是很快的。或者可以和其他 DB 组合。
•  扩容要根据分片时的策略确定，范围分片的话就很简单，而随机取模分片就要迁移数据了。也可以用范围 + 取模的模式分片，先取模再范围，可以避免一定程度的数据迁移。

当然，如果分库还会面临事务一致性和跨库 join 等问题。

1.6.2 读写分离

为什么要读写分离

分表针对大表解决 CPU 瓶颈，分库解决 IO 瓶颈，二者将存储压力解决了。但查询还不一定。

如果落到 DB 的 QPS 还是很高，且读远大于写，就可以考虑读写分离，基于主从模式将读的压力分摊，避免单机负载过高，同时也保证了高可用，实现了负载均衡。

问题

主要问题有过期读和分配机制。

•  过期读，也就是主从延时问题，这个对于。
•  分配机制，是走主还是从库。可以直接代码中根据语句类型切换或者使用中间件。

1.7 小结

以上列举了 MySQL 常见慢查询原因和处理方法，介绍了应对较大数据场景的常用方法。

分库分表和读写分离是针对大数据或并发场景的，同时也为了提高系统的稳定和拓展性。但也不是所有的问题都最适合这么解决。

2. 如何评价 ElasticSearch

前文有提到对于关键字查询可以使用 ES。那接着聊聊 ES 。

2.1 可以干什么

ES 是基于 Lucene 的近实时分布式搜索引擎。使用场景有全文搜索、NoSQL Json 文档数据库、监控日志、数据采集分析等。

对非数据开发来说，常用的应该就是全文检索和日志了。ES 的使用中，常和 Logstash, Kibana 结合，也成为 ELK 。先来瞧瞧日志怎么用的。

下面是我司日志系统某检索操作：打开 Kibana 在 Discover 页面输入格式如 “xxx” 查询。

该操作可以在 Dev Tools 的控制台替换为：

（编辑：揭阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!