方丈的寺院

摘要在上一篇中我们介绍了数据迁移的套路，但是没有介绍具体的方案，这篇着重介绍下具体的数据迁移方案一. 设计目标设计一个数据迁移的方案，需要实现以下目标迁移速度qps 需要达到1k，这样能保证1亿的数据能够在1~2天内跑完迁移qps可控迁移有可能对线上服务有影响，需要可动态调整qps数据完整，不丢失不能遗漏数据，虽然事后我们有数据校验的过程，但是设计数据迁移方案时，需要尽可能的包装数据不丢失。进度可控迁移过程可中断，可重试。比如先迁移10分之一的数据，再继续来二.

数据迁移的类型随着业务的发展，存储也会经常性的需要迁移。以下场景是我们开发过程中经常遇到的业务、团队在快速扩张，需要适当时机进行微服务的拆分，需要独立的数据库，将数据从源数据库迁移到新的数据库单表的记录数比较大，需要进行分库分表。需要将老表的数据迁移到新的分表中。存储选型不对，比如关系型数据库的相互迁移， PG, MySQL,Oracle的相互迁移。NoSQL的Mongo,Cassand...

摘要在存储优化(2)-排序引起的慢查询优化中我们提到过排序对查询选择索引的影响。但是的解决办法就是增加一个索引。在线上给mongo的大表增加一个索引要慎重。在增加索引的过程中也遇到了一些问题，这边进行相关的记录与分析。问题描述表结构_id,biz_Id,version,name索引1. 主键索引2. biz_id,version联合索引查询语句"query":{"fin...

摘要排序引起的慢查询，通常不是那么容易发现,经常和数据分布有关系。往往在业务刚开始时并没有什么问题，但是随着业务的发展，数据分布呈现一种特定的规律，导致了慢查询，或者并不是什么慢查询，但是随着并发请求数增加，数据库的IOPS使用率变高，进一步导致cpu/内存使用率飙高。造成线上故障。问题因为排序引起的问题遇到很多次例1：某日收到线上cpu告警然后查看慢sql日志大量的慢查询指向了这个查...

摘要最近遇到一个慢sql，在排查过程中发现和分库分表后的索引设置有关系，总结了下问题。问题在进行应用健康度盘点时，发现有个慢sql如下select brandgoodid from brandgood_0020where userid = xxx ANDbrandgoodid in("xxx1","xxx2")表结构,按照userid进行的分表。CREATE TABLE`b...

摘要之前写过一篇ElasticSearch初识之吐槽,不知觉竟然过去了两年了。哎，时光催人老啊。最近又用到了ES，想找找过去的总结文档，居然只有一篇，搞了半年的ES，遇到那么多的问题，产出只有这么点，真是说不过去啊。只好又重新捡起ES，发现ES槽点依然很多，不兼容的更新太多了，各个版本之间的差异不小，感觉ES就是偏理论算法的人设计出来的，而不是工程学家写的。非常像公司里面，算法工程师吐槽后端应用...

摘要面试候选人关于mysql索引问题时，发现有些人能够涛涛不绝的说出B+树和B树，平衡二叉树的区别，却说不出B+树和hash索引的区别。这种一看就知道是死记硬背，没有理解索引的本质。本文旨在剖析这背后的原理，欢迎留言探讨问题如果对以下问题感到困惑或一知半解，请继续看下去，相信本文一定会对你有帮助mysql 索引如何实现mysql 索引结构B+树与hash有何区别。分别适用于什么场景数...

摘要IN 一定走索引吗？那当然了，不走索引还能全部扫描吗？好像之前有看到过什么Exist,IN走不走索引的讨论。但是好像看的太久了，又忘记了。哈哈，如果你也忘记了MySQL中IN是如何查询的，就来复习下吧。问题问题要从之前的统计店铺数关注人数说起SELECT shop_id, count(user_Id) as attentionNumberFROM shop_attentionWHE...

摘要我们经常使用useGenerateKeys来返回自增主键，避免多一次查询。也会经常使用on duplicate key update，来进行insertOrUpdate，来避免先query 在insert/update。用起来很爽，但是经常踩坑，还不知为何。本篇就是深入分析获取自增主键的原理。问题首先摘两段我司一些老代码的bug批量插入用户收藏for (tries = 0; trie...