大量数据的mysql设计_小白请教大量数据的数据库设计问题

各位好。刚刚学习数据库，遇到一个需求，请求大家给建议。

我这里有大量的股票行情数据，格式如下：

股票 1、时间(年月日时分秒毫秒)、当前价、成交量、涨停价、跌停价、买一价、卖一价......

600000、20180604093000000、10.23 、30000、11.00 、9.00 、10.23 、10.34

600000、20180604093000100、10.23 、30000、11.00 、9.00 、10.23 、10.34

600000、20180604093000400、10.23 、30000、11.00 、9.00 、10.23 、10.34

600000、20180604093000700、10.23 、30000、11.00 、9.00 、10.23 、10.34

600000、20180604093000000、10.23 、30000、11.00 、9.00 、10.23 、10.34

600000、20180604093000100、10.23 、30000、11.00 、9.00 、10.23 、10.34

600000、20180604093000400、10.23 、30000、11.00 、9.00 、10.23 、10.34

600000、20180604093000700、10.23 、30000、11.00 、9.00 、10.23 、10.34

600000、20180604093000000、10.23 、30000、11.00 、9.00 、10.23 、10.34

600000、20180604093000100、10.23 、30000、11.00 、9.00 、10.23 、10.34

600000、20180604093000400、10.23 、30000、11.00 、9.00 、10.23 、10.34

600000、20180604093000700、10.23 、30000、11.00 、9.00 、10.23 、10.34

.....

600001、20180604093000000、10.23 、30000、11.00 、9.00 、10.23 、10.34

600001、20180604093000100、10.23 、30000、11.00 、9.00 、10.23 、10.34

600001、20180604093000400、10.23 、30000、11.00 、9.00 、10.23 、10.34

600002、20180604093000000、10.23 、30000、11.00 、9.00 、10.23 、10.34

600002、20180604093000100、10.23 、30000、11.00 、9.00 、10.23 、10.34

600002、20180604093000400、10.23 、30000、11.00 、9.00 、10.23 、10.34

.....

这些行情数据保存的数据库，目前初步想使用 redis+mysql。redis 里加载 mysql 的数据，便于快捷查询。每一条行情大概有 25 个属性

需求是：

( 1 )当前开盘的数据实时更新到数据库(初步打算：先写到 mysql，然后再更新到 redis )

( 2 )每次 redis 里加载的股票的数量不多，大概 20 个。毕竟每次看上的股票不多

( 3 )可以让客户端查询最近最多一个月的行情数据，每次查询的数据可能是某个时间段(例如是当前时间至一小时前)，也可能是查询某一个股票的某一天所有数据。 考虑到内存问题，每次支持查询的时间段长度还要测试测能知道，

( 4 )可以让客户端查询从某个时间段开始或之前的 N 条数据。

目前设计的想法是，使用 list，使用每个股票作为一个 key，然后把每一次的数据都按顺序 push 到列表里，例如把一条行情数据的 25 个属性 push 到 key 里，如果 100 条行情，就有 2500 个元素。30 天的数据大概最多有 8640 万个元素(假设每秒最多 8 次行情数据)

( 1 )如果是查询时间段，那么先在对应 list 里把时间段开始的数据找到，然后把 M 个元素一次读出(时间段的秒数 * 8 * 25 (每条记录有 25 个属性))，取出后，把多余的数据踢掉(因为有些数据可能超过这个时间段)

( 2 )如果查询时间段开始或之前 N 条记录，那么这个好办，在对应 list 里把时间段开始或之前的数据找到，读取 N*8 个元素。

不知道以上的想法是否合理，如果更好的建议，欢迎不吝赐教