您好我最近需要通过从不同类型的交易所导入并分析它来处理市场数据
市场表非常简单，由下面的列
组成market_name varchar(45) => this will be exchange name
market_type varchar(5) => buy sell bids of asks
currency varchar(8) => cur1_cur2 e.g usd_eur
volume decimal(30,10)
price decimal(30,10)
import_time int => unix time
由于从不同交换机获取数据的协议有一些限制，我最多只能每隔5秒更新一次数据。
现在的问题是：
每交换5秒，我将进口两种市场类型买入和卖出。 每种市场类型都有100条记录。
因此，对于一次交换，我将导入
( 86400 / 5 ) * 2 * 100 = 3,456,000 row
我将导入一个月
3,456,000 * 30 = 10,368,000 row
目前我们有5个兑换，每个货币2个货币，这意味着我们将在一个月内进口约100,368,000行。
现在进行分析，我们将输出以下数据：
您会看到暂时不会使用某些数据，但我们仍需将其保留以备将来使用。
有关处理此问题的最佳方法的建议吗？
目前我总是使用MySQL作为我的数据库，但我不确定它是否是处理此问题的正确数据库。
答案 0 :(得分：1)
步骤1.标准化。将market_name和market_type以及货币从庞大的VARCHAR更改为ENUM或TINYINT。这将把数据量减少一半。 DECIMAL（30,10）需要14个字节，并且具有比所需更高的精度。找出最大的价值。小数位数是否限制为2位数，这在美国目前很常见？或者你需要更多的小数位数。请问FLOAT（4个字节，大约7位有效数字）吗？这种变化也会节省很多。
步骤2.确定您是否“永远”需要数据。如果没有，什么是“清除”政策？ MONTH可能对PARTITION有好处。这样可以轻松快速地进行清除，而且在某些查询中可能会有所帮助。
步骤3.请告诉我们实际的SELECT;我们需要进一步调整它们，再看看可以做些其他收缩/优化/等等。
步骤4.“汇总表”会有帮助吗？也就是说，不是保留上个月的5秒数据，而是1分钟，甚至1小时的数据就足够了吗？这将节省大量空间，并极大地加快了查询速度。
步骤5.在决定PARTITIONing和SELECT之后，让我们讨论一下INDEX。
我可以详细说明其中任何一个;您想了解更多详情？
答案 1 :(得分：0)
第1步：关于标准化的好主意，我可以将小数点设为4左右。我听说Float在计算价格相关数字时声名狼借
第2步：这就是我们还不知道的问题，所以请保留所有内容：D
步骤3：我们通过从5秒内获得OHLC价格来更新为每个只节省15分钟，所以现在应该节省的数据要少得多。
第4步：我给了他们1分钟他们说它慢了，哈哈。
步骤5：几乎索引除价格和数量之外的所有内容
我更喜欢SELECT一个，因为它通常很慢：D，我把选择放在下面的答案中。
答案 2 :(得分：0)
我的数据是对此结构的更改
market_name varchar(45)
market_currency_pair varchar(10)
market_type varchar(5)
market_time datetime
market_position_id int(11)
average_volume decimal(30,10)
open_value decimal(30,10)
high_value decimal(30,10)
low_value decimal(30,10)
close_value decimal(30,10)
我可以减少一些列：D，就像你计算每种类型字节的方式一样？
我还没有选择查询，但这是情景：
选择每个市场过滤器的OHLC价格，根据您想要通过总和average_volume计算的数量来选择。
选择2到4个市场过滤器的O / H / L / C价格，根据您想要看到的平均交易量计算的数量。
我最担心的是我是否保存了正确的数据，这就是我每隔5s就会看到一次（v是音量，p是价格）
market_position_id first 5s second 5s third 5s ... last 5s
1 v:10,p:20 v:11,p:30 v:8,p:16 v:12,p:15
2 v:11,p:30 v:12,p:28 v:10,p:17 v:11,p:14
and so on
然后我总结一下这将保存到上表：
market_position_id average_volume open high low close
1 9.6 20 30 15 15
2 11 30 30 14 14
and so on
答案 3 :(得分：-1)
你下了一个小数...每个交易所每月30 * 3,456,000 = 103,680,000行，不容易索引。有5个交易所和2种货币，即每月1,036,800,000行。
这对我来说是一个bigdata项目的明确开端。它已经完美地适用于任何基于hadoop的解决方案。您将需要查看具有良好分片的宽而浅的集群架构。
根据对事务完整性的需求，hive（针对原始文件转储到HDFS分区的sql），hBase（又名亚马逊技术）或Cassandra（也就是源自Amazon技术的Facebook技术）抽象层可能有意义。在建议跳转的方式之前，我需要了解更多有关该产品的信息。
另一方面，Instagram在postgresql上运行得很好，他们的CTO有一个博客，详细说明了他们为扩展我们所做的工作以及他们必须处理的头痛。