这是一个创建于 1630 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，最近有一个业务需求是需要存储全国各地的历史天气数据，精确到县级市（大约三千个左右）。粗略估算了一下，就算只存 20 年的历史数据，行数也要有千万级了，这种情况下该如何设计呢？
表的字段设计应该就是一列 ID （主键自增）、地名、日期（地名和日期合成唯一索引）、天气代号，这样四列。但是现在有一个问题就是，并不是所有地区的数据都能获取完全，比如北京上海这种地方可以获取到很久以前的天气，但是很多县级市只能获取到最近几年的数据，所以对于每个地方而言，需要存储的长度是不相等的。这就导致没办法直接按时间划分，比如每五年的数据分一个区，如果这么干的话会导致各分区大小差别很大。我经验比较浅薄，不知道这种时候该怎么设计了，有带佬指点一下吗
===============
当然还有一些比较取巧的办法，比如天气通常都是连续的，只存每一段天气的开头和结尾日期的话存储端的压力会小很多，但是这样会增加业务端的复杂的，除非存储端搞不定，否则目前暂时不想这么做。
 |
1
reself 2020-06-05 16:39:32 +08:00
分库分表，稍微具体描述点的话，可以垂直切分或(和)水平切分。
水平切分的话，根据业务集中度可以平均切分或(和)热点切分，热点可以按访问量、按访问的地理差异、按网络延迟等。 垂直切分的话，其实类似于读写分离，将写少读多和写多读少的拆开，拆的时候可以是业务级、表级甚至字段级。 |
 |
2
binux 2020-06-05 16:43:01 +08:00 via Android  2
千万很大吗？
|
 |
3
shiny 2020-06-05 16:45:19 +08:00
线上 MySQL 单表三千万记录，也没什么问题
|
 |
4
escapemars 2020-06-05 16:46:34 +08:00
大表的存储不是问题，问题是如何查询。所以核心是你的业务需要怎么使用这些数据，比如说直接地名和日期做查询，那我觉得走索引以后不用分库分表都可以搞定。如果要做其他的查询，比如说只安装日期查，那就按照日期做水平分库，只按照地名查，那就按照地名做水平分库。
|
 |
5
lordofhollows 2020-06-05 16:59:14 +08:00
想太多了，20 年数据才千万，哪用得着什么妙招
|
 |
6
dbskcnc 2020-06-05 17:11:33 +08:00
做表分区就可以了，根据业务需要确定分区方式，列不确定加个 Json 字段
|
 |
7
optional 2020-06-05 17:13:02 +08:00 via iPhone
不用分区，加内存保证放得下索引就行。
|
 |
8
qloog 2020-06-05 17:14:02 +08:00
一般情况下分表就可以了，常用的分表：根据 id 取模就搞定了，90%的场景都合适。
|
 |
9
roundgis 2020-06-05 17:14:26 +08:00 via Android
單表過億都沒問題
|
 |
10
kiracyan 2020-06-05 17:14:58 +08:00
可以做归档机制，涉及归档数据的时候单独处理
|
 |
11
qiayue 2020-06-05 17:15:29 +08:00
一个城市一张表，数据互不干扰
|
 |
12
UserNameisNull 2020-06-05 17:16:24 +08:00
我之前单表 1.5 亿数据，没分表，🤣
|
 |
13
sayhello1991 2020-06-05 17:19:40 +08:00
注意你的历史天气数据是不会变的， 想想空间就很大了
|
 |
14
yukiloh 2020-06-05 17:21:00 +08:00
以前听说三千万以上是瓶颈,欸,原来上 e 都没关系吗
|
 |
15
glancer 2020-06-05 17:30:22 +08:00
tidb 也很香吧？
|
 |
16
kanepan19 2020-06-05 17:32:26 +08:00 1
@yukiloh 三千万 是因为到这个体量， 不好维护， 比如加索引、加字段、迁移等。
只要索引合适，查询还是没问题的。 |
 |
17
dog82 2020-06-05 17:56:34 +08:00
如果只有 3kw 的数据，不分区也行。——仅仅主键查询的话。
hash 分区不行吗？ |
|
18
escapemars 2020-06-05 18:54:47 +08:00
@sayhello1991 对，不会变的历史天气数据的特点是只增加不修改，完全没必要用 mysql，用 clickhouse，分库分表啥都不用考虑，无脑存，随便一台垃圾配置的机器单表几十亿数据查起来都轻轻松松的。
|
 |
19
594duck 2020-06-06 09:21:44 +08:00 via iPhone
你的历史数据不会改变而且是增量的可以走时间序列数据库。比如 influxdb 。
如果一定要是 mysql 。按照你的描述没几列。完全支撑得住。千万数据还可以。 而且你的数据是可以拆分的按年份按城市来做归档表就好。 加一层 redis cache 也可以。这个优化好做。现在服务器不值钱，redis 在虚拟机就可以了不要放 docker 也可以直接走阿里的 drds （必要性不大） |
 |
21
louislivi 2020-06-06 10:05:23 +08:00
千万还好，上亿级就确实需要好好设计架构一下了
|
|
22
594duck 2020-06-06 15:12:42 +08:00 via iPhone
@69partner 他这要求肯定是有自己服务器的企业了。没必要用 docker 。数据量 redis cluster 5 分区，每分区 30G 足够了。而且就算是 redis 数据也是长久存储的，要什么 docker 直接 vm 跑着就好了。
对了虚拟化用 vmware 家的省心。 |
 |
23
sagaxu 2020-06-06 16:41:05 +08:00
我是穿越回 2000 了吗？ 1000 万也算大表了吗？现在是 2020 年，10 个字段单表 1 亿行也不算大。
线上单表 2 亿，加字段加索引并不会锁表。迁移的话，10 张 1000 万的表，比 1 张 1 亿的表更麻烦。 |
 |
24
Coolha 2020-06-06 16:49:23 +08:00
千万没必要吧...只有设计好索引，不影响使用的
|
 |
25
opengps 2020-06-07 08:41:01 +08:00 via Android
合理的设计就没有上限，每次看到这类话题我都秀一下我的这篇文章 https://www.opengps.cn/Blog/View.aspx?id=284&from=v2ex
|
Select Language