peq*_*uod 7 sql csv performance bigdata
我写了一个程序来计算一组200万个文档中的相似之处.该程序有效,但我无法存储结果.我不需要经常访问结果,但有时需要查询它们并提取子集进行分析.输出基本上如下所示:
1,2,0.35
1,3,0.42
1,4,0.99
1,5,0.04
1,6,0.45
1,7,0.38
1,8,0.22
1,9,0.76
.
.
.
第1列和第2列是文档ID,第3列是相似性得分.由于相似性得分是对称的,我不需要全部计算它们,但这仍然留给我2000000*(2000000-1)/2≈2,000,000,000,000行记录.
一百万行记录的文本文件已经是9MB.外推,这意味着我需要17 TB来存储这样的结果(在平面文本文件中).
是否有更有效的方法来存储这些类型的数据？我可以为每个文档创建一行,并在第一列中删除重复的文档ID.但那只是到目前为止.那么文件格式或特殊数据库系统呢？这必须是"大数据"中的常见问题; 我看过报道类似分析的论文/博客,但没有人讨论像存储这样的实际维度.
免责声明：我对此没有任何实践经验，但这是一个有趣的练习，经过一番思考，这就是我想到的：
由于您有 2.000.000 个文档，因此您可能会被一个整数作为文档 ID 所困扰；这就是 4 个字节 + 4 个字节；比较似乎在 0.00 和 1.00 之间，我猜想一个字节可以通过将 0.00-1.00 编码为 0..100 来完成。
所以你的表将是：id1，id2，relationship_value
这使得每条记录恰好有 9 个字节。因此（没有任何开销）需要 ((2 * 10^6)^2)*9/2bytes，大约是 17Tb。
当然，如果你只有一张基本的桌子的话。由于您不打算经常查询它，我想性能并不是什么大问题。因此，您可以通过“水平”存储值来发挥“创意”。简化一下，您可以将这些值存储在 200 万乘 200 万的正方形中，每个“交集”将是一个表示它们坐标之间关系的字节。这“仅”需要大约 3.6Tb，但维护起来会很痛苦，而且它也没有利用关系对称的事实。
所以我建议使用混合方法，即包含两列的表格。第一列将保存“左”文档 ID（4 个字节），第二列将使用 varbinary 保存以第一列中 id 上方的 id 开头的所有文档值的字符串。由于 varbinary 只占用它所需的空间，这有助于我们赢回关系对称性提供的一些空间。
换句话说，
这样，您应该能够使用 2Tb（包括开销）之类的东西来存储信息。对其进行压缩，我很确定您可以将其存储在现代磁盘上。
当然，该系统远非最佳。事实上，查询信息需要一些耐心，因为您无法处理基于集合的事物，并且您几乎必须逐字节扫描事物。这种方法的一个很好的“好处”是，您可以通过向每个记录的字符串添加一个新字节以及最后的 1 个额外记录来轻松添加新文档。类似这样的操作成本高昂，因为它会导致页面拆分；但至少不必完全重写该表是可能的。但随着时间的推移，它会导致相当多的碎片，您可能需要偶尔重建表以使其再次更加“对齐”。啊..技术细节。
选择和更新将需要对 SubString() 操作进行一些创造性的使用，但没什么太复杂的。
PS：严格来说，对于 0..100 你只需要 7 个字节，所以如果你真的想挤出最后一点，你实际上可以在 7 个字节中存储 8 个值并节省另外约 300Mb，但这会让事情变得相当有点复杂......话又说回来，数据无论如何都不会是人类可读的 =)
PS：这种思路完全是为了减少所需的空间量，同时在更新数据方面保持实用性。我并不是说它会很快；而是说它会很快。事实上，如果您要搜索关系值为 0.89 或以上的所有文档，系统将必须扫描整个表，即使使用现代磁盘也需要一段时间。
请注意，这一切都是半个小时头脑风暴的结果；我实际上希望有人能用更简洁的方法插话 =)
| 归档时间： |
|
| 查看次数： |
151 次 |
| 最近记录： |