想要构建一个简单的股市数据库，老哥们给提点建议？

最近疫情都在远程办公，闲下来的时候想试着开发一下副业。虽然有的老哥说炒股行，有的认为属于赌博，我个人虽然也不太看好真的能赚钱，但是不妨碍先做一些技术性测试么。

目前想实现一个最小需求，先做到能实时监控 A 股所有股票的价格。具体来说就是保存 A 股大约 4000 只个股（只包含个股，不包含基金、指数等）的每分钟 K 线数据，包括开盘价，收盘价，最高价，最低价。并且取数据的话保证每次取到的都是 3-5 秒内的最新数据。

可用性方面目前不考虑多用户，只考虑能负担我一个人的即时存取就可以了。

========================================================================

简单考虑了一下，我目前能考虑到的技术问题有以下这些

1 、后端技术栈选择。我目前能用的技术栈有 java/go/python/node，感觉后两者应该可以直接枪毙，不知道有没有朋友用 go 开发过相关业务，各方面怎么样。

2 、数据库选择。考虑到数据更新频率应该很高，应该尽可能选择性能较高的数据库。我个人不会折腾容器式数据库，所以理想情况下应该是非容器数据库的读写性能能满足要求就最好了。数据库应该选择 Oracle/pg/mysql?mysql 我觉得应该枪毙，在这种场景下应该性能会比较拉胯。

3 、数据库表结构如何设计？

存储 K 线数据，一种情况是设计一张大表，包括股票代码、时间、以及价格这么几项，所有数据放在一块。不过如果考虑到存储粒度是一分钟 K 线的话，A 股每天大概会新增一百万行数据。如果要存历史数据的话，这个表应该会变得无限大，我觉得这么搞不太行。

那么应该如何设计呢？为每个只个股单独建一张表？如果这么设计的话，我觉得要实现每秒持续地，分别在 4000 个表里 update 数据，我没测试过，但我觉得一个表问题不大，4000 个表应该没有数据库扛得住。

3.1 、作为上个问题的衍生，是否需要 nosql 缓存？ 所以折中办法是缓存最近一分钟数据，然后每分钟更新？这样会增加比如取 K 线这种业务代码的复杂度。

4 、是否要设计冗余？

股票的一个特点是，虽然储存的比较细粒度的是每分钟数据，但是经常按日汇总、周汇总、月汇总这样来看，是否将这部分数据单独冗余出来呢，还是取数据的时候现场计算？如果从 5-30-60-120-240 这种分钟级别逐层冗余上去，总体存储体积可能会增加一倍，同时数据即时更新的压力也会增大（原先每分钟只需要更新 4 千张表，现在可能需要更新 4 万张表了）

====================================================

目前大概能想到这么多问题，虽然是跟股票相关但基本还是局限在跟股票没有关系的技术范围内。各位老哥提提意见，谢谢了。

我的想法是先把数据库建起来，然后跑一些历史回测，反正做一个模型看起来不是很花时间的样子。

我知道现在网上有一些免费提供回测能力的项目，但是我本身也在享受自建数据库这个过程，所以不准备用别人做好的服务。