我正在收集大量数据,这些数据最有可能是以下格式:
用户1:(a,o,x,y,z,t,h,u)
所有变量在时间上动态变化,除了u - 这用于存储用户名。我想要了解的是因为我的背景在“大数据”中不是非常强烈,当我最终得到我的阵列时,它会非常大,类似于108000 x 3500,因为我将在每个时间步长上执行分析,并绘制图形,管理这个的适当数据库是我想要确定的。由于这是用于科学研究,我正在研究CDF和HDF5,并根据我在此阅读的内容NASA我想我会想要使用CDF。但这是管理此类数据以提高速度和效率的正确方法吗?
最终数据集将所有用户都作为列,并且行将加时间戳,因此我的分析程序将逐行读取以解释数据。并在数据集中输入。也许我应该看看像CouchDB和RDBMS这样的东西,我只是不知道一个好的起点。建议将不胜感激。
答案 0 :(得分:6)
这是一个扩展的评论,而不是一个全面的答案......
相对而言,大小为108000*3500
的数据集目前并不真正符合大数据,除非您省略了GB
之类的单位。如果它只是108000*3500
字节,那只有3GB加上变化。您提到的任何技术都可以轻松应对。我认为您应该根据哪种方法加快开发速度而不是加快执行速度来做出选择。
但是如果你想要进一步的建议,我建议:
答案 1 :(得分:3)
我一直在使用CDF来处理一些类似大小的数据,我认为它应该可以正常工作。不过,您需要记住一些事项。考虑到我并不真正了解您项目的细节,这可能会有所帮助,也可能没有帮助......
3GB的数据正好适用于旧版CDF的文件大小限制,因此请确保您使用的是最新的库。
虽然3GB并不是那么多数据,但根据你的阅读和写作方式,事情可能会很慢。确保尽可能使用超级读/写功能。
CDF支持可以保存用户名和数据描述等信息的元数据(称为全局/变量属性)。
很容易将数据分成多个文件。我建议每个用户使用一个文件。这意味着您只需将整个文件的用户名作为属性编写一次,而不是在每条记录中。
您需要创建一个名为epoch的额外变量。这是每条记录明确定义的时间戳。我不确定你现在的时间戳是否合适,或者你是否需要处理它,但这是你需要考虑的事情。此外,epoch变量需要具有分配给它的特定类型(epoch,epoch16或TT2000)。 TT2000是最新版本,它提供纳秒精度并处理闰秒,但我遇到的大多数CDF阅读器还没有很好地处理它。如果你不需要那种精确度,我推荐epoch16,因为它已经成为标准了一段时间。
希望这有帮助,如果你选择CDF,请随时告诉我你遇到的任何问题。