lxdlam

@lxdlam 有一定差距 -> 有一定不同

Zookeeper 不是 Paxos ，而是自己发明的协议 ZAB ，跟 Paxos 有一定差距；实现了 Paxos 的系统有很多，比如 Google 的 Chubby 和 Scylla DB 。

同样，根据 DDIA 的说法，现代 CAP 其实逐渐式微，因为现代系统设计里面这三个每一个话题都会有很多需要考虑的问题，不再只是单纯的 3 选 2 了。

@ShinichiYao #28 如果 Key space 足够小且 IV 的 space 也足够小的情况下，知道一定的 plaintext 才是可以攻击出密钥的，这个叫做 Known-plaintext Attack 。

在已知范围内，如果不满足上面的结论，AES （所有模式）都免疫 KPA ，这是因为 KPA 的一种最直接的攻击就是遍历 key 跟 iv space ，尝试每一种可能的 combination ，如果都在 2^16 这个级别，现在的好一点的家用电脑可能不需要一晚上时间。而在现代实践中，AES 一般使用 128bit 及以上的 key ，这种情况下即使 IV space 较小，攻击难度也非常大。跟知道多少 (plaintext, encrypted) 无关。

Reference： https://crypto.stackexchange.com/questions/100521/for-aes-gcm-does-knowing-plaintext-and-ciphertext-allow-attacker-to-learn-the-k

零知识证明。

@kuanat OCaml 有两种数据对象，一种是传统的函数式对象 Record ，这个是 nomimal 的，类型 tag 区分不同类型，而 object 和 module system 是 structural 的，实际上我例子中提到的函数可以这么写：

```ocaml
let print (bar : < foo : string; .. >) = print_endline bar#foo;;
```

注意到这个独特的签名，其实要求 `bar` 需要具有一个特定的 foo 即可，对其他的都不要求。

@lxdlam oops ，应该是 #10 ，看错楼了

@lxdlam 补充一点，Go 的基于 Signature 的 interface matching ，实际上 OCaml 早实现出来了，即使是 First class module ，也是 2011 年引入的，早于 Go 。

```ocaml
module type Foo = sig val foo : string end;;

class a = object method foo = "A" end;;
class b = object method foo = "B" end;;

let print bar = print_endline bar#foo;;

print (new a);; (* "A" *)
print (new b);; (* "B" *)
```

不同意 #14 的说法，实际上 #14 所需要的只是 Composable 的 interface ，而并不是所谓的 duck typing 。

引用原文：

> - Don't implement Interfaces preemptively.

在这里提到的 case 实际上是因为，Java 由于无法对任意 External Type 实现 Internal interface ，所以如果原始的行为 Contract 没有被声明为 Interface ，我们既不能实现我们自己的替代品（有 interface 的情况下，实现一个 Adapter 不就可以了？），也无法使用我们的 interface 去将其替代；而这个限制在 Rust 中已经被放宽到不允许使用 External struct 去实现 External trait （ https://doc.rust-lang.org/book/ch10-02-traits.html#implementing-a-trait-on-a-type ）。

而 Go 这种 Duck typing ，实际上比起 Java 的显式声明，是另一种推卸责任。举个例子，假定我存在两个 interface：

```go
type Visitor interface {
Saw() bool // If we have seen this node
}

type Sawyer interface {
Saw() bool // Can sawyer saw?
}
```

当我实现 `func (???) Saw() bool` 的时候，我究竟在实现谁？这大大加剧了误用几率，反而在工程上是一个 bad practice 。（这种 case 一定存在，参考 Hyrum's Law - https://www.hyrumslaw.com/ ，一个行为只要被足够多的人观察，无论是否跟你的设计和想法保持一致，一定会有人在依赖这个行为）。

如何回避上述行为？一种方案是实现一个空的 method ，限定其在特定 namespace 下面，比如：

```go
type Visitor interface {
Saw() bool

IsVisitorImpl()
}
// ...
```

但这跟 Java 的 `implements XXX` 相比，无非是把这个 Tag 下推到 `interface` 内部了，本质是完全一样的。

而如果实现细粒度的 `interface`，#40 提出了一个很好的例子，我们甚至可以：

```java
public interface Putter {
String put(Item item);
}

public interface Getter {
Item get(String key);
}

public class Storage {
private Putter putter;
private Getter getter;
}
```

虽然有点累赘，一样实现了类似的细粒度接口组合，并未有任何功能上的差异。

看 op 应该是 Oracle

猜测 union 查询命中了联合索引，所以不需要对 `datetime` 排序，只需要决定起始位置就可以直接 fetch 数据；而 IN list 先对命中三个条件的数据进行 merge ，然后 sort 后再筛选，无论是合并、排序操作还是需要扫描的行数（ 8989K > 2123K+180K ）都远比前一个查询计划大。

一种可行的优化可以尝试 over partition 拆成三个子表排序再重新 where 一下，不确定优化效果，需要再 explain 一下看看，参考 https://use-the-index-luke.com/sql/partial-results/window-functions