Tag: ansi

又一份講基本 RDBMS 的文件

前幾天在 Hacker News Daily 看到「Things You Should Know About Databases」這篇文章，裡面講了很多基本的 RDBMS 的概念，另外 Hacker News 上對應的討論在「Things to know about databases (architecturenotes.co)」這邊。

裡面講了 B-tree 與 B+tree 的差異：

不過這點在維基百科上也蠻清楚的文字說明：

A B+ tree can be viewed as a B-tree in which each node contains only keys (not key–value pairs), and to which an additional level is added at the bottom with linked leaves.

另外裡面的 sorted 的那張圖：

這邊的說明不完全正確，在維基百科上的「Database index」這個條目裡面有提到 Non-clustered、Clustered 與 Cluster 三種架構，這邊圖片所表示的是 Non-clustered。在 InnoDB 裡面 data 是照 primary key 順序存放的 (沒有指定時會有一套邏輯選出哪個欄位當 PK，最後的情況是有 hidden key)。

再來就是提到 isolation，這邊也講的比較淺，只提到 ANSI 標準裡面的 SERIALIZABLE、REPEATABLE READ (RR)、READ COMMITTED (RC) 與 READ UNCOMMITTED (RU) 四個，但沒提到像是 SNAPSHOT ISOLATION (SI) 這類的也很常見的標準。

說到 SI，在查 Snapshot isolation 的資料時整理了一下 PostgreSQL 的混亂情況。

在 PostgreSQL 9.0 以及更早前的版本，你指定 SERIALIZABLE 其實只有做到 Snapshot isolation 的等級，到了 9.1+ 後，SERIALIZABLE 才是真正做到 ANSI 定義的強度：

Snapshot isolation is called "serializable" mode in Oracle and PostgreSQL versions prior to 9.1, which may cause confusion with the "real serializability" mode.

另外 ANSI 定義的 isolation level 很難「用」 (但還是值得學起來，算是基本的東西)，實際上的使用都是看各家資料庫對 isolation level 的保證程度來設計。

SQL-92 裡定義 Isolation Level 的背景

在 Twitter 上看到這則推，講到在 SQL-92 裡面 Isolation Level 定義的背景：

先是講了為什麼有 SERIALIZABLE、REPEATABLE READ 與 READ COMMITTED，然後講為什麼是用 anomalies 定義 (除了 SERIALIZABLE)，也因此造成了定義不清楚而導致問題。

SQL-92 的 isolation 問題後來在其他文件裡面有被討論，像是 1995 年的「A Critique of ANSI SQL Isolation Levels」，以及 2000 年的論文「Generalized Isolation Level Definitions」，過了二十年後的現在，大家也都大概知道有哪些雷區了。

另外講到 Isolation Level，實務上會希望知道 database 與標準之間的差異，在「Hermitage: Testing transaction isolation levels」這篇可以看到各家 RDBMS 在不同設定下實際的 isolation level，包括了 open source 的 MySQL 與 PostgreSQL 與商用常遇到的 Oracle 與 Microsoft SQL Server。

MySQL 的 REPEATABLE READ 因為 SQL-92 的定義不清楚，所以大概知道這邊本來就有爭議，比較意外的反倒是 Oracle 裡面的 SERIALIZABLE 實際上是 Snapshot Isolation，沒有辦法達到 SQL-92 裡面最高等級的 Isolation Level。

然後發現有些知識還是有漏，趁這個機會補...

The DUHK Attack：因為亂數產生器的問題而造成的安全漏洞

在 Bruce Schneier 那邊看到的：「Attack on Old ANSI Random Number Generator」，攻擊的網站在「The DUHK Attack」，論文在「Practical state recovery attacks against legacy RNG implementations (PDF)」。

攻擊的對象是 ANSI X9.31 Random Number Generator：

DUHK (Don't Use Hard-coded Keys) is a vulnerability that affects devices using the ANSI X9.31 Random Number Generator (RNG) in conjunction with a hard-coded seed key.

然後攻擊的對象是 Fortinet 的 FortiOS：

Traffic from any VPN using FortiOS 4.3.0 to FortiOS 4.3.18 can be decrypted by a passive network adversary who can observe the encrypted handshake traffic.

如果照說明的只到 4.3.18，那麼去年 11 月更新的 4.3.19 (參考「FortiOS 4.3.19 Release Notes」) 應該是修正了？不過裡面沒翻到類似的資料，是剛好把 RNG 換掉了嗎？