开个脑洞，假设有这么一个实时记录人体各项数据的设备

时序数据库

1. 数据库设计和 hibernate 没关系
2. 无非就是分表， 按人分可以， 按天分也可以， 看你的需求
3. 如果一开始就预期到数据量非常大， 而且不需要事务， 那还是用 nosql，mongodb 之类的数据库

数据在一天之内就破千万并不是什么问题。
我现在这 1 小时近一亿数据，也一样处理计算。
不过不要直接使用 mysql，存储原生数据请使用时序数据库。
mysql 可以用来存储预处理，计算之后的需要的少量数据。

千万级数据库根本不是什么问题。

非要用 mysql，一般是分布式，索引做的好的话查询也是很快的，长期存储的话通常一个人使用一套系统，成本也不是很高。

实际上难点在于如何实现稳定的数据并发。每秒一千多的并发要稳定下来不容易。

低配 InfluxDB
硬件需求：
CPU: 2-4 cores
RAM: 2-4 GB
IOPS: 500

服务能力：
writes per second < 5k
Moderate queries per second < 5
Unique series < 100k

每隔 10 秒采集一次佩戴者的心率，血压等共计 30 多项
人数：12 人
实验组：100 组

1.使用 hibernate+mysql 怎么应该怎么设计数据库——》和往常一样设计 ，但是我的想法是这样的

传输协议：MQTT
采集效率：10 秒 约 30 项
文件格式：csv

采集每一天活动的数据输入 csv 文件中。再将该文件同步到主机，主机取数据分析建模。存档备份。


2.假设采用了某种解决方案可以采集这些情况，以上的假设能否在生活中实现，是否可以根据佩戴者的数据变化及时发现病情，早发现早治疗从而延长人类寿命？

早已经有人实现了。

你来我这，参与下 GPS 实时定位系统的开发。硬件通信为 TCP 长连接，每隔 10s 一个定位点，随便一家平台设计承载量 10 万终端起步，这时候只用一台中等配置物理机就可以承载。

关于连接数：负载均衡+多台虚拟机，用来共同承担连接数，需要注意的是网络设备不能限制并发连接数。比如硬件防火墙。

关于数据库设计：传感器特点结构设计，能用时序数据库更省心，关系型数据库参考 https://www.opengps.cn/Blog/View.aspx?id=422

关于读写性能：再好的设计也抵不过物理管道，好硬盘，多硬盘才是解决之道

最后，这类系统都是需要在开发前就考虑横向扩展，推荐云架构。如果项目抵触公有云也可以自己搭建虚拟化用一堆虚拟机实现

1、需要储存的时候会做 24 小时心电图，这个是一人一台设备的，在医院集中监控没用，需要还原真实场景，而且还要记录下不适的时候，最后和医生的数据一起分析
2、心率和血压实际上也就是苹果表那点东西，专业的心电图机是 12 导联的，没人愿意接那个东西，那东西测一次胸上俩印半天消不掉，而且心电图不是唯一的标准，实际上光一个基本的心脏检查就 100 多快，还得抽血看心肌酶，你 要是会连 12 导联的机器，现在稍微贵一点的机器都可以自动分析，问题是心电图现在还是要人工复查
3、能实时监控，没用，你说的是护士站，机器实时分析+人工核对，什么心跳血氧血压都有，而且排除掉设备损坏或者接触不好的情况，那就请个医生来呗，现在设备早就不是问题，问题是怎么在你发病的时候正确进行心肺复苏，并且把你送到医院，要知道心电图异常可以非常严重，万一是个主动脉夹层啥的。。
楼主怕是对心电图理解有什么问题，如果有问题要么是一瞬间的问题，这种需要做 24 小时心电，如果是毛病或者很严重随时去医院随时测，这不是股票行情，多少天多少个月的数据连起来可以分析出啥规律来

zabbix 监控就是 mysql，数据量也不小，我们 2T 的库默认配置，也没啥感觉

@legiorange 这种服务没有普及么？

@murmur 没有，我医学盲，我只是把我的实际问题抽象成大家能理解的一个方向，没想那么细- _ -