MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
 |
kuxuanDec 4, 2024
1
收藏
|
 |
wowo243Dec 4, 2024
2
这不就是按年分表，分库分表有框架，比如 shardingsphere
|
 |
3
可以用时序数据库，比如 influxdb 之类的
|
 |
akiraDec 4, 2024
4
统计，分组排序 提前算好就行 啦
|
 |
5
10 年才 8000 多万，100 年才 8 亿多。。。。一年建一张表也行，就是分析统计跨年度的时候要额外处理一下。。。
实在不行还可以分区嘛，根据时间分区，这样落在一个数据库文件里的数据量就更有限了。。。 |
 |
linaurorDec 4, 2024
6
都按年存了，其实不必搞什么配置表，直接不让跨年查明细就好了，主要是控制一下明细的时间范围。
统计的话可以单独搞个统计表，每天跑一次之类的，这点数据问题不大 |
 |
MartensDec 4, 2024
7
这种数据可以用时序数据库
|
 |
8
mysql 哪里有这么脆弱啊，单标现在最大都可以支持到几十 TB 了，别被网上的一些垃圾文章误导。直接去买云厂商的产品，几亿条都没问题。
|
 |
yuzo555Dec 4, 2024
9
建议时序数据库
|
 |
HunterPanDec 4, 2024
10
分区吧 10 年数据够用了
|
 |
whoosyDec 4, 2024
11
800w 数据小意思
|
 |
rockdddDec 4, 2024
12
一年才八百万，直接上云服务的数据库，哪怕存几年，这点量 查起来都没什么感觉
|
 |
13
800W ，室温数据，没啥复杂的数据结构，主要是查询（统计），统计提前跑任务，
我觉得时间索引一下，10 年、8 年 归档一下就行了，分啥库分啥表。。。 |
 |
justfinduDec 4, 2024
14
我们有个统计表, 一个月是 4000 万数据, 偷懒单表, 不过可以归档. 3 个月一归档.
|
 |
dddd1919Dec 4, 2024
15
不可变时序数据，上 hive
|
 |
weilai99Dec 4, 2024
16
单表八百万一点问题都没有，我们单表将近两千万都轻轻松松
|
 |
shen13176101Dec 4, 2024
17
想复杂了，业务就那么简单，不相信 mysql 换 pg
|
 |
systemGuestDec 4, 2024
18
你太看不起 mysql 了，我们单表最大 8 亿的设备登录记录，照样正常查。
但是你要做各种复杂统计，就需要把数据同步过去，用 ES 类似专业的玩意。 |
 |
cheng6563Dec 4, 2024
19
一年 800 万...等你一天 800 万在考虑这些吧...
|
 |
jiakmeDec 4, 2024
20
如果允许的话, 可以考虑将 mysql 更换为 pgsql. 简单数据, 单表 1 亿没问题
|
 |
zdw406Dec 4, 2024
21
800w 数据量不算大
统计可以提前跑批，按需求设计专门存统计数据的表 一个主表可以存当前时间往前间隔固定时间（比如当前时间之前 1 年）的数据，历史表分表，这个数据量用不着分库 |
 |
molikaDec 4, 2024
22
docker 里面跑的 mysql 云虚拟机 一年跑了 4000 多 w 条数据 还会连表查询..目前没有任何压力
|
 |
jimrokDec 4, 2024
23
800 万单表存储是没有问题，估计你也不开放查询给用户使用，这种数据最多给建模分析用，但普通的预测模型直接使用文件，pandas 就能很好处理，根本不需要读你的数据库。
|
 |
luziafyDec 4, 2024
24
单表就行 十年后再说
|
 |
cominghomeDec 4, 2024
25
字段不多、对耗时不敏感的话放心用，mysql 配置跟得上单表几千万行没事的。
从架构层面来说，你的方案没有问题。如果用户量级不会急速膨胀也可以考虑按其他因素分表也是可以的，比如按 userid 尾数 0~9 可以分出十个表来，像你这种情况稳定跑个几十年都没事。 |
 |
YukinekoDec 4, 2024
26
按年分区，800w 不是随随便便
|
 |
zhangqian99Dec 4, 2024
27
我司的一张表 8 个字段，运行两年 3 亿 3 千万行数据，占用存储 22G 。你的一年才 800 万行，担心啥，你太小看 mysql 了
|
 |
LieEarDec 4, 2024
28
800 万这个级别 mysql 绰绰有余
|
 |
kiwi95Dec 4, 2024
29
加大内存甚至不用分表，节省下来的开发费维护用够加内存的了
|
 |
SoulSleepDec 4, 2024
30
800 万/年。。。一行就几个字段....统计、分组排序.......单表够了
而且你这数据只写不改，如果统计、分组有压力可以做报表预处理，本来数据都是一小时一条....不需要实时查的，跑个 10 年都没压力 |
 |
31
我 MySQL 5.7 老版本，单表 4 亿也没说啥啊，你 800 万零头都不到啊。。。好奇怪的帖子
|
 |
franchiseDec 4, 2024
32
这量级单表，按周期做统计即可
|
 |
YetToComeDec 4, 2024
33
这个数据量，建议不要单表，业务的方向很快就会膨胀到单表支撑不了的。
统计单独写代码提前计算 |
|
wbrobotDec 4, 2024
34
@zhangqian99 确实，我看了一下我的，又一年过去，已经增加到 5 亿 2 千万了，数据 21G,索引 29G ，一台每月 5 刀的 VPS 跑的飞快。。。
|
 |
nanrenleiDec 4, 2024
35
一年 800w 的话 mysql 单表没问题，我们有的单表存储了 2000w ，但是统计全量数据之类的就比较慢了大概需要十来秒中，如果不需要事务的话也可以用 mongodb 存储，mongodb 大概存 10 亿不是问题，也可以使用 influx 这种时序数据库，但要增加学习成本
|
 |
shyrockDec 4, 2024
36
一年八百万，又不是一小时八百万。。。感觉这数据增加十分缓慢啊。。。
建议先用着，等你真正感受到性能瓶颈再说优化的事，记住”提前优化是万恶之源“。 |
 |
pkoukkDec 4, 2024
37
能支撑，索引建好就行
|
 |
JinnrryDec 4, 2024 via iPhone
38
我这里评论表，单表 20 亿
|
 |
cenbiqDec 4, 2024
39
确保你的操作都命中索引，然后把你最经常查询的字段（比如说最经常按数据的采集时间来查询）做成聚集索引，完事。
|
 |
whp1473Dec 4, 2024
40
如果只是简单统计，团队能控住，可以考虑上时序数据库，如果复杂统计不要求事务可以 Starrocks 、Clickhouse 。
如果还是想用 MySQL ，用 MySQL 也可以，单表 mysql 8000 万只简单查询没什么问题的，可以每 10 年一张表，简单检索直接走该表，分表字段为年区间比如 2014-2024 ，现成的框架就有，不用配置表；如果希望复杂维度统计，比如每一栋的室温、峰值、中位数、百分位，并且可以下钻，可以通过每天定时任务定时统计保存，如果数据量非常大了，比如几十亿，可以通过 Datax 抽取到 Hive 中处理跑批处理，如果希望数据实时，可以通过 Kafka+Flink 实时计算，再通过 Hive 或 Spark 批处理校准，批流配合。 |
 |
DreamArchitectDec 4, 2024
41
才 800w 单表足够了 之前开发的系统一年十几亿 单表也没啥问题 复杂查询走 ES 注意磁盘 遇到瓶颈再优化 这点数据 就整分库分表了 不至于吧
|
 |
meeopDec 4, 2024
42
800w 数据，你拿你的手机当服务器都没有问题
现在 2024 年了，任何数据承担 800w 数据都没有任何问题，甚至 800w 数据你全读取到内存里都没问题 哪找你提供的信息，一行数据 id+读数+时间+状态+ext ，算 300 字节，800w 行约 2.2G ，不到一部电影大小 |
 |
yoyolichenDec 4, 2024
43
不管是单表还是分表，统计都建议提取个中间表，每天定时任务跑一下
|
 |
qq135449773Dec 4, 2024
44
存进去是没什么问题，可是之后怎么去用里面的数据，索引怎么设计优化，才是关键的问题。
把这种传统数据库当时序库用，一时间有点想不出来索引怎么去做.... |
 |
noyidoitDec 4, 2024
45
太小看 mysql 了，遇到问题再说吧
|
 |
diluDec 4, 2024
47
太小看 mysql 了，第一家公司，7 年前。有一个流水表，十几亿的记录，二十多个字段，加了合适的索引。数据十几个 g ，索引也有十几个 g ，用的还是 4h8g 的配置，不过用的是腾讯云的 mysql 。
app 是 2w 日活左右，正常查询，接口平均都在 1s 以内，一点压力都没有。 |
 |
rickieyDec 4, 2024
48
按年分表也没问题，这些数据是不是收集完后基本不会变，可以存在其他更合适的数据库，比如 clickHouse
|
 |
la2laDec 4, 2024
49
1. 你这个业务场景不涉及到复杂事物场景，1 年 800w 数据 MySQL 完全抗的住
2. 挂个从库统计分析的需求只用从库 或者 通过 ETL 工具实时导入到 OLAP 数据库支持分析操作 3. 一年 800 万数据可以按 5 年分表都行，OLAP 数据库使用月分区 |
 |
reecoDec 4, 2024
50
Mysql 单表 我极限存过 2 亿数据
|
 |
ShinichiYaoDec 4, 2024
51
当年也挺担心 MySQL 的单表大数据性能，10 年前的硬件 6 核 8G 内存，单表每月新增一个分区，最近看了一下，已经 19 亿数据了
|
 |
Rat3Dec 4, 2024
52
每个三到五个供热季分一个表，随便搞
|
 |
badbyeDec 4, 2024
53
一张表存无压力，过几年再看
|
 |
luorixyDec 4, 2024
54
是不是大家都对 MySQL 的性能都很担忧啊 一年才 800 万的量都担心了 MySQL 在大家眼里的性能这么差吗😂
|
 |
xuelu520Dec 4, 2024
55
这才多少数据，单表 10 年都不是问题
|
 |
ltmstDec 4, 2024
56
单表查询没啥问题，做分区就行了
麻烦的是可能有设计复杂的统计 |
 |
deckenDec 4, 2024
57
上亿都没问题 MySQL 性能不差的
|
 |
ymy3232Dec 4, 2024
58
一张表可以用到项目倒闭，你的项目还不一定能活 10 年，能活十年的项目有的是办法优化
|
 |
cutiechiDec 4, 2024
59
一点问题没有
|
 |
THESDZDec 4, 2024
61
与其担心这个，不如担心备份问题。
|
 |
julyclydeDec 4, 2024
62
1 不需要解决
2 用 tsdb 更合适 3 时间长了就可以删了。你又不是气象局，留那么远期的数据干啥？ |
 |
johnlinDec 4, 2024
63
我们 2000w 条数据都存一张表的，800w 可以的。不跨年查询的话，你一下子建 20 张表 [20 年] ，然后建立一个字典，每个年度一张表，后期都不用你维护的
|
 |
cccvno1Dec 4, 2024
64
单表直接存，室温数据分布应该挺密集的，只要索引加好，普通机械硬盘都没有问题。
|
 |
0x663Dec 4, 2024
65
 一年才 800 万至于分表？ |
|
0x663Dec 4, 2024
66
而且一看你这个系统名称我就明白了是绩效项目，《室温采集系统》
估计热不过两年领导升上去了就不会管了。 |
 |
JZenDec 4, 2024
67
800w 应该可以随便跑，以前我的双核垃圾服务器存 2000w 行的表都不慌，要做复杂统计可以把数据 dump 出来，在其他性能更高的机器上做。
|
 |
luciankaltzDec 4, 2024
68
看起来还是一个时序指标的场景
不知道历史的统计要不要频繁查询，不过愿意等的话查询语句写的好应该问题也不大 数据直接存对象存储上，800w/年 的数据放个几年问题都不大（甚至再来几倍都 懒得写重复的回答了，ref https://www.v2ex.com/t/1093560#r_15605476 |
 |
encroDec 4, 2024
69
一年 800 万，啥都不用干分表分区分库都不用管，3 年后再看就是了。。。
统计专门做统计表。 建议采用 postgresql ，哈哈。 |
 |
wangyzjDec 4, 2024
70
你这个类似 iot 场景了，不适合 mysql
|
 |
gerryzhu0033Dec 4, 2024
71
不想麻烦的，直接用 mysql + 分区表，统计分组的话后面加个 clickhouse ，妥妥的
|
 |
go522000Dec 4, 2024
72
看到大家的数据都到亿了，真强大。
我之前一台轻量服务器，2C4G ，MYSQL 是那种官网直接下载安装的，没有修改配置，单表超过 200M 就会卡，是需要什么优化吗？ |
 |
chengxiaoDec 4, 2024
73
是不是看多了那个什么单表 2000w ,思维固化了
要知道技术和硬件这些年都在进步 ,单表 2000w 都快 10 年前的事了 |
 |
fengpan567Dec 4, 2024
74
Mysql:看不起谁呢？
|
 |
GreenHandDec 4, 2024
75
我记得十年前我们单表就存了 10 亿级别的数据了
|
 |
FightPigDec 4, 2024
76
800w 没问题吧，我没怎么用 mysql,我们的 pg 现在单表上亿，没发现什么毛病
|
 |
soul11201Dec 4, 2024 via Android
77
这点数据很多吗？
|
 |
RangerWolfDec 4, 2024
78
我们单点 mysql 存储了 1T+的数据（没有分布式、也没有主从，只要每天备份）
只要不是频繁用来做数据分析，加上索引设计合理，800W 一年应该毫无压力 |
 |
ksc010Dec 4, 2024
79
一年 800w 不算事
|
 |
realpgDec 4, 2024
80
我的单表一天就八百万数据
不过会把 30 天后的转到归档表 |
|
realpgDec 4, 2024
81
每时每刻都在嗷嗷新增数据 不过晚上新增速度比较少
 一直在新增 count 就比较慢 |
 |
mingtdlbDec 4, 2024
82
来到我司后，我想明白了我司 几乎所有的研发 做事风格都是顾前不顾后，工作量自己创造。
渐渐的我也想明白了，明年都不一定在这公司了，前人栽树 后人凉，埋点坑问题不大，何况你这个不算坑 |
 |
w3cllDec 4, 2024
83
才 800w 而已，你是有多看不起 MySQL ？我们这边单表三四千万都轻轻松松
|
 |
mooyoDec 4, 2024
84
八百万啊，你等八千万了再回来问吧。。
|
 |
XhackDec 4, 2024
85
@zhangqian99 主键用的啥
|
 |
RicardoYDec 5, 2024
86
@CodeCodeStudy 没必要没必要，这才多少点数据量
|
 |
kkbearDec 5, 2024
87
一年 800w ？？ mysql 被黑成这样了吗？
|
 |
eseeDec 5, 2024 via Android
88
你是不是没有正经做过项目都是写个 demo 就没了。mysql 没这么脆弱，我一个表两三年时间了三四亿行数据了，现在也没性能瓶颈。
|
 |
open9527Dec 5, 2024
89
这个项目能坚持十年吗
|
 |
yufeng0681Dec 5, 2024
90
@zdw406 #21 题主一个回复都没有，感觉浪费了大家一腔热情。
没有明确好需求，就开始设计表。 扩展性也是基于未来可能的新需求来考虑，而不是过度设计。 固定的业务统计报表需求，肯定会把数据采集计算形成统计使用的表结构 基于某 1 个用户的详情查询，用户 ID 做索引，查询速度没问题。 |
 |
iv8dDec 5, 2024
91
一年上亿了再喊我，##
|
 |
visperDec 5, 2024
92
干十年八千万了，你也离职了，留给后人烦恼，说不定项目已经被停归档了。
|
 |
bthuluDec 5, 2024
93
目前八亿单表没问题, 等你数据到八亿了, 硬件也早就日新月异了, 更不用担心了
|
 |
onesurenDec 5, 2024
94
这个场景 时序数据库比较合适。
|
 |
NoKeyDec 5, 2024
95
我们用的 pgsql ，一年 2 亿多数据，现在 2 年了，还是单表，除了一些改字段，大批量更新很慢之外，正常写入查询几乎感觉不到啥性能问题。所以，先找目标数据库进行压测，测试完了看结果再说，网上一些老八股文讲的什么几百万分库，都是早些年的环境下的结论了
|
 |
JingKeWuDec 5, 2024
96
 一年的数据 单表 都是热数据 |
|
JingKeWuDec 5, 2024
98
  |
 |
sazimaDec 5, 2024
100
之前做物联网相关的，一天 6000w 数据， 单表。
|
2
Select Language