分类表的目的是解决两个问题。
第一个问题是数据量太大，查询太慢。 其中我们说的“查询”其实主要是事务中的查询和更新操作。 因为只读查询可以通过缓存和主从分离来解决。 这是在以前的“MySQL如何应对高并发性”两门课中说的。 那就像上节课提到的，解决查询很慢，减少每个查询的数据总量就可以了。 也就是说，可以通过划分表格来解决问题。
二是为了应对高并发性问题。 关于对高并发的响应，正如前面所述，一个数据库实例无法响应，因此必须将并发请求分布在多个实例上。 因此，要解决高并发性问题，就需要划分库。
简而言之，数据量大的话，就划分表格； 合并高的话，分库。
常用的三种分片算法
范围分片容易引起热点问题，但对查询更友好，适用于并发量少的场景
哈希片易于将数据和查询均匀地分布在所有片上
检针法更灵活，但性能有点差。
MySQL to Redis同步
MQ消息同步
使用Binlog实时更新Redis缓存(使用Canal )
如何在不停机的情况下交换数据库？
在线同步程序，用于将数据从旧库复制到新库并实时保持同步；
双写订单服务，只读写旧库；
打开双重写入，同时停止同步过程；
打开比较和补偿流程，确保新旧数据库数据完全相同
逐步向新库提出请求；
下划线比较补偿程序，关闭双灯，读写同时切换到新库；
脱机旧库和订购服务的双写功能。
像“点击流”这样的大量数据应该如何存储？
存储大量原始数据的存储系统需要非常高的写/读性能和几乎无限的容量，因此对数据的查询能力不高。 在生产环境中，可以选择Kafka或HDFS。 Kafka的优点是提高了读写性能，可以在单节点上支持高吞吐量。 HDFS真的提供了无限的存储容量，对查询很有用。
目前有几个开源项目
一个是分布式流数据存储，比较活跃的项目是Pravega和Pulsar存储引擎Apache BookKeeper。 这些分布式流数据存储系统遵循类似Kafka的流存储路线，基于高吞吐量提供真正无限的扩展能力和良好的搜索能力。
另一个是“时间序列数据库”(Time Series Databases )，它有一些活跃的项目，如InfluxDB和OpenTSDB。 这些时间序列数据库不仅具有非常好的读写性能，而且提供了轻松查询和聚合数据的能力。 但是，并不是任何数据都可以存储，而是侧重于具有时间特征、数据内容为数字的数据，如监控数据。 如果需要存储大量监视数据，请关注这些项目。
关于寻找教程网
本网站文章只是代表的观点，不代表本网站的立场，所有文章都是非盈利的、免费共享的。
本网站提供软件编程、网站开发技术、服务器运维、人工智能等IT技术文章。 很多程序员努力学习，希望我们能用科技改变世界。
[海量数据处理] http://www.zyiz.net/tech/detail-142989.html