 |
ershierduV2EX 第 308348 号会员，加入于 2018-04-13 11:17:56 +08:00 |
ershierdu 最近回复了
180 天前 回复了 amirobotics 创建的主题 › 生活 › 媳妇说要将摄像头里的视频存起来，让宝宝长大看…但是一个月的量就有 150gb - 200gb+ |
我倒觉得这个事挺有意思的。楼上说数据量太大没时间看，但即便是现有的 AI 都接近能自动提取精彩内容了，再过几十年这绝对不是问题。重点在于，存储、计算资源只会越来越便宜，检索引擎会越来越智能，但原始数据删掉就没有了。
将来可能用自然语言描述一个场景，AI 就能把所有类似的记录全查出来，难以想象如果我有影像来呼应童年回忆是什么感受。
所以我基本不删任何照片，全部上云……
将来可能用自然语言描述一个场景，AI 就能把所有类似的记录全查出来，难以想象如果我有影像来呼应童年回忆是什么感受。
所以我基本不删任何照片，全部上云……
191 天前 回复了 kernelpanic 创建的主题 › 程序员 › 超过 1TB 的 csv 文件，有没有快速的处理方法 |
不了解最新的分布式架构，但感觉这也太符合 MapReduce 的思路了…
逻辑上：
1. 把文件扫一遍，得到 id->list[pair<content,sort>]的映射。
2. 单独为每个 id 的内容做内部排序。
实现上：
1.无论用什么方法，一轮文件 IO 把数据都进来都是需要的。为了后续处理更方便，再多加一轮 IO ，先把大文件按 1<id<10w, 10w+1<id<20w...切成多个小文件，这样每个小文件都是独立的，后续处理时维护的中间状态会少很多。
2. 每个小文件用一个进程处理，得到 id->list[pair<content,sort>]的中间结果。要么像楼上说的直接进数据库，要么每个 id 的内容放在一个文件里。一个小文件跑完后就可以从中间结果生成最终数据了。
并行度可以在切小文件的时候控制（每个小文件 10w 还是 100w 个 id ）。
前提：
你存放最终结果的数据库需要能承受这么大的最终数据，否则啥办法都白搭。
逻辑上：
1. 把文件扫一遍，得到 id->list[pair<content,sort>]的映射。
2. 单独为每个 id 的内容做内部排序。
实现上：
1.无论用什么方法，一轮文件 IO 把数据都进来都是需要的。为了后续处理更方便，再多加一轮 IO ，先把大文件按 1<id<10w, 10w+1<id<20w...切成多个小文件，这样每个小文件都是独立的，后续处理时维护的中间状态会少很多。
2. 每个小文件用一个进程处理，得到 id->list[pair<content,sort>]的中间结果。要么像楼上说的直接进数据库，要么每个 id 的内容放在一个文件里。一个小文件跑完后就可以从中间结果生成最终数据了。
并行度可以在切小文件的时候控制（每个小文件 10w 还是 100w 个 id ）。
前提：
你存放最终结果的数据库需要能承受这么大的最终数据，否则啥办法都白搭。
Select Language