mysql 查询最新数据分组优化 mysql查询表里的重复数据方法？
mysql查询表里的重复数据方法？
MySQL里去查询表里的反复重复数据记录：
先栏里点再重复一遍的原始数据：
如何设计每秒十万查询的高并发架构？
简单重新回顾看看，整个架构右侧部分自然演进到的那个程度，总之早就太的比较好了，因为百亿流量，一秒内十万级并发中写入的场景，可以使用MQ限流控制削峰、分布式系统KV集群给抗住了。紧接着可以使用了可以计算与存储只是分离的架构，每个Slave算出节点会共同负责提纯数据到内存中，实现自研的SQL内存可以计算引擎成功可以计算。另外采用了数据动静分离的架构，静态数据全部缓存，闪图数据自动启动再提取，保证了尽很可能把网络帮忙开销减低到最少。
另，实际自研的分布式系统架构，以及数据分片和计算任务分布式执行、韧度资源调度、分布式高容错机制、主备自动切换机制，都能能保证整套系统的不可以按需快速扩容，高性能、高可用的的运行。
下一步怎么办，咱们得来研究什么研究架构里左侧的部分了。
二、日趋膨胀的离线计算结果
其实大家会尽量到，在左侧另外一个MySQL，那个MySQL就是用处支撑起实时计算结果和离线模式可以计算结果放进里面信息汇总的。
终端的商家用户就可以不随手的查询MySQL里的数据分析结果，勉力支撑自己的决策，他可以不看当天的数据分析报告，也可以不看历史上任何一段时期内的数据分析报告。
可是那个MySQL在早期很有可能而且有一些，只不过当然贮放在这个MySQL里的数据量相对于要小一点，虽说是计算后的一些结果罢了。但到了中后期，这个MySQL不过也危机重重了。
给大家举一个例子，不联网计算链路里，如果不是每天增量数据是1000万，这样每天晚上换算完以后的结果大概仅有50万，每天晚上50万新增加数据放入后MySQL，总之我还是这个可以接受的。
可是如果每天晚上增量数据是10亿，那你早上计算完以后的结果大概会是千万级，你也可以算他是算出结果有5000万条数据吧，每天晚上5000万增量数据写入到左侧的MySQL中，你都觉得是啥感觉？
可以不给大家说说系统当时的情况，大部分那就是，单台MySQL服务器的磁盘存储空间马上现在就要距离满掉，但单表数据量大都几亿、甚至于十亿的级别。
这种量级的单表数据量，你觉得用户去查询数据分析报告的时候，可以体验能好么？基本都当时三次去查询都是几秒钟的级别。很慢。
倒也罢了，会出现过用户一次查询要十秒的级别，哪怕几十秒，上分钟的级别。很混乱，用户体验非常差，远远的达不到免费的产品的级别。
所以我帮忙解决了右侧的存储和计算的问题之后，左侧的网上查询的问题也迫在眉睫。新一轮的重构，势在必行！
三、分库分表读写分离
首先是新瓶装旧酒，分库分表读写分离，这个都差不多是基于MySQL的架构中，必经之路了，不过可以实行站了起来难度并非特别的高，并且速度较快，效果都很特别显著。
整个的思路和之前第一篇文章（《大型系统架构演进之如何支撑百亿级数据的存储与计算》）讲的基本是一致。
说白了，那就是分库后，每台主库是可以承载部分写入到压力，单库的写并发会降低；其次是单个主库的磁盘空间也可以减少负载的数据量，不当然了迅速就满了；
而分表之后，单个数据表的数据量这个可以减低到百万级别，这个是抵挡海量数据和能保证更高性能的最佳实践，基本是两三百万的单表数据量级我还是比较合理的。
然后读写分离之后，就这个可以将单库的读写负载压力分离的过程到主库和从库多台机器上去，主库就唤起写负载，从库就容纳读负载端，这样的话尽量减少单库原先机器的读写负载过热，可能导致CPU负载、IO电流值、网络负载过低，结果搞得数据库机器宕机。
简单的方法这么说全面重构看看数据库层面的架构之后，效果就好的多了。而且单表数据量会降低了，那你用户网站查询的性能能够得到很大的提升，基本可以不提升到1秒以内的效果。
四、一秒内10万网站查询的高并发挑战
上面那套正式的分库分表读写分离的架构确实抵挡了一段时间，但是渐渐地的那套架构又不暴漏不出来了弊端出来了，是因为商家用户是开了数据分析页面之后，页面上有js脚本会每隔几秒钟就发送中两次只是请求到后端来读取比较新的数据分析结果。
此时就有一个问题了，慢慢的的查询MySQL的压力越来越大，大部分可预见的范围是朝着远处速度1010级别去走。
可是我们总结了再看看，总之99%的查询，是页面JS脚本自动启动嘶嘶刷新当日数据的查询。唯有1%的查询是针对昨天以前的历史数据，用户不自动重新指定去查询范围后来网上查询的。
只不过现在的这个架构之下，我们是把当日实时数据计算结果（属於了热数据）和历史离线状态算出结果（代表了冷数据）都放在互相的，所以大家可以想像之中帮一下忙，热数据和冷数据放到在一起，然后对热数据的高并发网上查询占到了99%，那这样的架构还合不合理吗？
肯定不合理不，我们要又一次重构软件架构。
五、数据的冷热只是分离架构
因为上列说过的问题，很的确做好的一个架构重构是冷热数据只是分离。也就是说，将今日实时计算进去的热数据放进一个MySQL集群里，将离线可以计算出来的冷数据装在另外一个MySQL集群里。
后再变更土地性质一个数据查询平台，标准封装底层的多个MySQL集群，参照去查询条件动态路由到热数据存储或者是冷数据存储。
按照这个步骤的重构，我们就可以不有效的将热数据存储中单表的数据量减少到更少更少，有的单表数据量很有可能就几十万，而且将不联网算出的大量数据结果从表里剥离出去后了，放另外一个集群里去。此时大家可想而知，效果不过是要好了。
是因为热数据的单表数据量减少了很多，当时的一个最明显的效果，那就是用户99%的查询都是根据热数据存储率先发动的，性能从原先的1秒左右降底到了200毫秒以内，用户体验提升到，大家觉得更好了。
六、自研ElasticsearchHBase纯内存的查询引擎
架构实践到这里，感觉起来好像听说还比较不错，但是其实问题我还是很多。而且到了这个阶段，系统碰上另一个少见相当严重的问题：冷数据存储，如果没有已经用MySQL来唤起是很不可靠的。冷数据的数据量是日增长不断增强，而且增速一下子，每隔一天都新增加几千万。
而你的MySQL服务器城就会遭遇不断地的需要内存量的问题，并且要是替能支撑这1%的冷数据查询各位，不时的快速扩容提升高配置的MySQL服务器，大家感觉靠谱不么？
估计是不合适的！
要很清楚，大量分库分表后，MySQL大量的库和表以维护出声是相当麻烦的，可以修改个字段？加个索引？这全是场麻烦您事儿。
当然了，是因为对冷数据的查询，一般大都因为大量数据的查询，诸如用户会中,选择过去几个月，甚至于一年的数据进行分析查询，此时要是纯用MySQL我还是挺灾难性的。
而且当时明显发现，是对海量数据场景下，顿时查询总结几个月或则几年的数据，性能是极差的，应该非常容易搞成几秒钟甚至几十秒才出结果。
因此针对这个冷数据的存储和网站查询的问题，我们最终你选了自研一套基于组件NoSQL来存储，然后把基于条件NoSQL内存的SQL计算引擎。
具体来说，我们会将冷数据所有常规ESHBase来通过存储，ES中比较多贮存要对冷数据接受再次筛选的各种条件索引，比如日期和各种维度的数据，然后HBase中会贮存全量的数据字段。
因为ES和HBase的原生SQL意见都不是太好，并且我们就自研了另外一套SQL引擎，一类允许这种特定的事件的场景，那就是都差不多没有多表关联，应该是对单个数据集通过查询和分析，然后接受NoSQL存储内存计算出。
这里有一个先决条件，那就是如果不是要能做到对冷数据彻底是单表类的数据集查询，可以要在冷数据进入NoSQL存储文件的时候，全部基于组件ES和HBase的特性能够做到多表入库时关联，进数据存储就全部可以做成大宽表的状态，将数据关联所有上推到入库时能完成，而不是在查询时并且。
对冷数据的查询，我们自研的SQL引擎简单会依据什么各种where条件先走ES的分布式低功耗索引可以查询，ES可以不针对海量数据低性能的检索系统出去不需要的那部分数据，这个过程用ES做是最合适的。
而后是将检索系统出的数据对应的完整的各个数据字段，从HBase里再提取出来，拼接成完成的数据。
后再是将这份数据集放在内存里，并且急切的函数计算、分组情况聚合这些排序等操作。
上述事项操作，完全实现自研的根据这个场景的查询引擎结束，底层设计和实现Elasticsearch、HBase、纯内存来实现方法。
七、实时动态数据存储化入缓存集群
好了，告一段落，冷数据的海量数据存储、集高性能网站查询的问题，就能解决了。接着回过头来看一下当日实时数据的查询，总之实时数据的每月十五算出结果肯定不会太多，并且中写入并发应该不会特别尤其的高，每秒钟上万也就也差不多了。
所以这个背景下，是用MySQL分库分表来抵挡数据的写入、存储和查询，都没问题啊。
可是有一个小问题，那就是说每个商家的实时数据总之不是什么正常的变更的，在一段时间内，可能压根就不知道没变化，而不不需要高并发请求，每秒钟10万级别的全部落地之前到数据库层面吧？要全部落地之前到数据库层面，那很可能要给每个主库武器挂架很多从库来能支撑高并发读。
而这里我们化入了一个缓存集群，实时数据每次自动更新后中写入的时候，大都写数据库集群另外还写缓存集群的，是双写的。
然后再可以查询的时候是不优先从缓存集群来走，此时大部分90的高并发去查询都走缓存集群了，然后再只有10%的查询会落地后到数据库集群。
八、阶段性总结
那样最好，此事到此为止，这个架构基本都左边也都重新架构之后：
热数据实现缓存集群数据库集群来盛载高并发的每秒十万级别的查询冷数据基于ESHBase内存换算的自研去查询引擎来勉力支撑海量数据存储包括高性能网站查询。经实践，整个效果非常的好。用户对热数据的查询基本是多是几十毫秒的响应速度，对冷数据的查询基本大都200毫秒以内的响应速度。
九、下一阶段的展望
当然系统架构到这里也很不大容易了，而且本是这么说两张图，里面涉及到无数的细节和技术方案的落地，要一个团队极耗起码1年的时间才能能做到这个程度。
不过这一次，我们要对于的，就是高可用的问题，是因为付费级的产品，我们必须要只要暴高的可用性，99.99%的可用性，甚至连是99.999%的可用性。
但是越是复杂的系统，越容易直接出现问题，对应的高可用架构就越是急切至极
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
