sort -uo 一个1T的文件，让最高配的google cloud instance (48 core/512G)崩溃了~~~，可惜了我的$30，白白跑了那么长时间~~~

网上搜索都是how to sort a big file，那我这个属于very very very big big big file了~~

不管是并行也好，管道也好，用了各种奇技淫巧就是敌不过人家 very very big~

不要跟我谈什么外排，归并，位图，bloom filter，redis hash去重，我就是不想折腾，最后只有分割手动外排搞定~~

把大象装进冰箱分为几步？

三步:

1
2
3
4
5

split -l 1000000000 huge-file small-chunk

for X in small-chunk*; do sort -u < $X > sorted-$X; done

sort -u -m sorted-small-chunk* > sorted-huge-file && rm -rf small-chunk* sorted-small-chunk*

小TIPS:

可以利用awk的数组是内存hash表的特性，直接awk来做，前提是你内存够大，瞎估估需要十倍于数据的内存吧:

1

cat xxxxx zzz | awk '{ if (!seen[$0]++) { print $0; } }' > xxx_zzz.uniq.txt

PS:

我后来又看了一下GNU Sort的实现描述，它说已经用了外排了，但是实际使用还是不给力，暂时迷惑中

两个大文件，a.txt和b.txt两个文件的数据都是逐行呈现的， 如何求他们的交集、并集和差集。

用sort+uniq直接搞定:

交集

1
2
3

$ sort a.txt | uniq > aa.txt
$ sort b.txt | uniq > bb.txt
$ cat aa.txt bb.txt | sort | uniq -d

并集

1

cat a.txt b.txt | sort | uniq

差集

1
2
3

$ sort a.txt | uniq > aa.txt
$ sort b.txt | uniq > bb.txt
$ cat aa.txt bb.txt bb.txt | sort | uniq -u

• 在开搞 bloom filter或者bitmap 或者grep -f之前可以先组合工具来一个

grep 一个100GB的文件总是很有压力，怎么才能提速呢?

瞎优化

1

LC_ALL=C fgrep -A 5 -B 5 'xxxxx.password' allpassseed.txt

• LC_ALL=C比LC_ALL=UTF-8要块

• 不需要正则的话，用fgrep可以提速

不过这样优化总是治标不治本，下面隆重推出linux 里面parallel all cmds的perl工具

1

cat allpassseed.txt |parallel  --pipe  --no-notice grep -f xxxxx.password

使用parallel ，和不使用parallel直接grep。结果显而易见，相差 20 倍。这比用啥 ack，ag优化效果明显多了

xargs也有一个-n的多核选项，可以作为备用

1
2
3
4
5

$ time echo {1..5} |xargs -n 1  sleep

real    0m15.005s
user    0m0.000s
sys 0m0.000s

这一条xargs把每个echo的数作为参数传给sleep ，所以一共sleep了 1+2+3+4+5=15秒。

如果使用 -P 参数分给5个核，每个核各sleep 1,2,3,4,5秒，所以执行完之后总共sleep的5秒。

1
2
3
4
5

$ time echo {1..5} |xargs -n 1 -P 5 sleep

real    0m5.003s
user    0m0.000s
sys 0m0.000s

• 引自:

https://www.jianshu.com/p/c5a2369fa613

有时候想在xargs后面接多条命令，这个时候直接加;是不行的，要这样做:

1

cat a.txt | xargs -I@  sh -c 'command1; command2; ...'

有时候find的所有文件要合并为一个argv管道到一个命令里面:

1

find /path/to/directory/ -name *.csv -print0 | xargs -0 -I file cat file > merged.file

在linux要排序一个100G的文件，压力比较大

并行解决之:

1

sort -S 50% --parallel=2 -uo list-sorted.txt list.txt

注意这一招在管道里面行不通，所以要用管道的话一定要先重定向到一个文件里面中转一下。

在之前的谈谈比特币的地址安全问题这篇文章中，我们谈到一个名为”LBC”的项目，这个项目通过暴力碰撞企图打捞到一些什么东西。

令人惊奇的是，他们真的碰到了几个地址。对他们最近发现的4个地址做了一下分析，发现了更让人惊奇的事情。

他们最近的四个发现是:

有时候gitignore没做好，一不小心就又进来一个二进制文件

在重复了N次Google之后，还是记一下吧

比特币的地址生成过程分为以下几个步骤:

1. 随机生成一个32字节(256bits)的私钥k

2. 采用椭圆曲线算法，以私钥k为起点，将其与曲线上预定的生成点G相乘以获得曲线上的另一点，也就是相应的公钥 K

3. 进一步SHA256=>RIPEMD160 得到地址原始值A: A = RIPEMD160(SHA256(K))

4. 对A进行Base58Check编码，添加前置版本号后Double SHA256取最后四个字节作为校验位，最后 Base58Check(前缀+Base58Check(A)+校验)得到最终地址

整个过程中，私钥的生成空间有256bits，由私钥推出地址过程中，由于用到了RIPEMD160散列，所以生成空间共有160bits。

也就是说，去除版本号变化，某一类型的比特币地址最多有 2^160个。

为什么有步骤3呢，不光增加了地址复杂度，还降低了HASH碰撞空间(从256bits降到160bits)。

所以中本聪的选择只是带来了不必要的复杂度和浪费吗？最后证明，答案是否定的。有另外一个非常好的理由去使用这个”公钥的哈希值”的地址结构：量子加密技术。量子计算机可以破解椭圆曲线数字签名算法（也就是说，给定一个公钥，量子计算机可以相当快速的找到对应的私钥），但它们不能相类似的逆转哈希算法（或者说他们可以，但是将需要花掉280个步骤来完成一个比特币地址的破解，这仍然是相当不可行的）。因此，如果你的比特币资金存放在一个你没有支出过的地址里（这意味着公钥是没有公开的），它们在量子计算机面前也就是安全的，至少在你把它们花掉之前。有理论上的途径可以让比特币完全免于量子计算机的威胁，但一个地址只是一个公钥的哈希值的事实，意味着一旦量子计算机真的出现了，在我们全面切换之前攻击者可以造成的损失要小得多。

请参考:

http://www.8btc.com/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet