insert

密碼裡面不能有 SELECT/INSERT/UPDATE/DELETE/DROP

這是在 Hacker News 上看到的：「Password may not contain: select, insert, update, delete, drop (uni-lj.si)」，原網站在「Password reset - ID portal」，熱鬧的地方在於原作者 (或是外包商？) 也在 Hacker News 上面回應...

禁止密碼裡面有某些字元還蠻常見的，但這次看到的很有趣 (然後被貼到 Hacker News 上)：

Your password must also not contain the following character combinations: script, select, insert, update, delete, drop, --, ', /*, */.

從網域及英文版的介面可以查到這是盧比安納大學的系統，作者 (或是外包) 在 id=39079030 提到了這是上面的要求：

Oooh! I put that string there! It was a request by management, and I still don't know why. This site doesn't store any passwords, it's basically just a nice interface to external account management.

I heard a rumour that some legacy apps have weird validation on their login fields, so students wouldn't be able to log in with passwords containing certain strings. But I don't actually know of any examples.

就... 很好玩？

快速產生 SQLite 資料的方式：一分鐘內產生十億筆資料

在「Towards Inserting One Billion Rows in SQLite Under A Minute」這邊看到作者想要在一分鐘內在 MBP 2019 上面寫 1B 筆資料進 SQLite，裡面有些方法還蠻值得玩一下的，這台 MBP 2019 機器的規格是：

The machine I am using is MacBook Pro, 2019 (2.4 GHz Quad Core i5, 8GB, 256GB SSD, Big Sur 11.1)

第一版是 Python 寫的，塞 10M 筆花了 15 分鐘：

In this script, I tried to insert 10M rows, one by one, in a for loop. This version took close to 15 minutes, sparked my curiosity and made me explore further to reduce the time.

加了五個 PRAGMA 的版本變成 100M 筆十分鐘：

The naive for loop version took about 10 minutes to insert 100M rows.

用批次處理則可以降到八分半：

The batched version took about 8.5 minutes to insert 100M rows.

再來是拿經典神器 PyPy 出來用，降到兩分半：

All I had to do was run my existing code, without any change, using PyPy. It worked and the speed bump was phenomenal. The batched version took only 2.5 minutes to insert 100M rows. I got close to 3.5x speed :)

接下來就是跳槽到 Rust 了，中間也有不少 tuning 相關的討論，但直接先跳到最後面好了... 最後 100M 只用了 33 秒：

I created a threaded version, where I had one writer thread that received data from a channel and four other threads which pushed data to the channel. This is the current best version which took about 32.37 seconds.

能用 PyPy 的地方還是可以考慮一下的...

Neovim 在選擇檔案名稱時的操作按鍵

在 Neovim 時操作檔案名稱時會是下拉選單，在 insert mode 時的畫面是這樣 (進到 insert mode 後 Ctrl-X + F)：

這時候可以用上下鍵選擇檔案名稱。

在 command mode 下也有類似的功能，像是 :sp 後按 tab 選擇檔案名稱：

問題在於只能用 Ctrl-N 與 Ctrl-P 移動，而不能用上下鍵操作，兩者的 UI 類似但是操作的方式不一樣，於是就翻了翻 manual，找出對應的模式，得到是 command mode，然後用 <expr> + pumvisible() 判斷是否是在 popup menu，接著把上下鍵對應到 Ctrl-N 與 Ctrl-P：

cnoremap <expr> <Down> pumvisible() ? "\<C-n>" : "\<Down>"
cnoremap <expr> <Up> pumvisible() ? "\<C-p>" : "\<Up>"

這樣就搞定了...

InnoDB redo log 大小對效能的影響

在「Benchmark(et)ing with InnoDB redo log size」這邊看到在討論 InnoDB redo log 的大小對效能的影響 (也就是 innodb_log_file_size 與 innodb_log_files_in_group)。

開頭就有先提到重點，在新版 MySQL 裡，幾乎所有的情況比較大的 redo log 有比較好的效能 (平均值)：

tl;dr - conclusions specific to my test

A larger redo log improves throughput
A larger redo log helps more with slower storage than with faster storage because page writeback is more of a bottleneck with slower storage and a larger redo log reduces writeback.
A larger redo log can help more when the working set is cached because there are no stalls from storage reads and storage writes are more likely to be a bottleneck.
InnoDB in MySQL 5.7.17 is much faster than 5.6.35 in all cases except IO-bound + fast SSD

可以看出來平均效能的提昇很顯著，不管是增加 redo log 大小還是升級到 5.7：

但作者也遇到了奇怪的效能問題。雖然平均效能提昇得很顯著，但隨著加入資料的增加，效能的 degradation 其實很嚴重，在原來的網頁上可以看到這些資訊。

The results above show average throughput and that hides a lot of interesting behavior. We expect throughput over time to not suffer from variance -- for both InnoDB and for MyRocks. For many of the results below there is a lot of variance (jitter).

所以也許現階段先加大就好 (至少寫入的效能會提昇)，不需要把這個特性當作升級 MySQL 的理由。

MyRocks 與 InnoDB 在 INSERT 效能的比較

MyRocks 的 Mark Callaghan 對 INSERT 效率整理出來的比較：「Insert benchmark, MyRocks and InnoDB」。

當資料比記憶體小的時候，InnoDB 效能比較好。但超過記憶體大小時就是 MyRocks 效能比較好。另外 InnoDB 在 MySQL 5.7 的效率比 5.6 好不少。

兩張圖來自相同資料，只是 x 軸不太一樣。

是從 16 台 client 裡面抽一台的量出來，這樣就可以解釋後面那段爬上來... (其他台跑完了，所以這台的 insert 速度變快了)

This is for data from one of the 16 clients rather than the global rate because my test script forgot to collect that.

While it is odd that the throughput rate for InnoDB 5.7 picks up at test end, that can occur if the thread I monitored ran longer than other threads and had less competition for HW resources near test end.

PostgreSQL 9.5 釋出，UPSERT！

PostgreSQL 9.5 正式發行，這次新增了大家期待已久的 UPSERT 功能：「PostgreSQL 9.5: UPSERT, Row Level Security, and Big Data」。

SQL:2003 正式定義出 UPSERT，被稱為 Merge，不過看網路上一般還是比較習慣 UPSERT 這個用法：

A relational database management system uses SQL MERGE (also called upsert) statements to INSERT new records or UPDATE existing records depending on whether condition matches.

也就是當沒資料的時候就 INSERT，有資料的時候就 UPDATE 的語法。常見的使用情境是拿來當 counter 用 (雖然這很傷資料庫的效能)。

沒有 UPSERT 的時候只能用 transaction 或是 store procedure 搭出來，效能上會比在 database engine 裡實作來的差，所以 UPSERT 還是被實作出來了。

PostgreSQL 9.5 的 UPSERT

在「Upsert Lands in PostgreSQL 9.5 – a First Look」這邊提到了 PostgreSQL 9.5 支援的 UPSERT 操作。

UPSERT 的定義是：

(computing, database) An operation that inserts rows into a database table if they do not already exist, or updates them if they do.

如果不存在就 INSERT，如果存在就 UPDATE，然後取一部分的字變成 UPSERT。由於要偵測「存在」，只能用在有 primary key 或是有 unique 條件時的表格上。

作者給的範例講解了 PostgreSQL 9.5 上的語法：

INSERT INTO products (
    upc,
    title,
    description,
    link)
VALUES (
    123456789,
    ‘Figment #1 of 5’,
    ‘THE NEXT DISNEY ADVENTURE IS HERE - STARRING ONE OF DISNEY'S MOST POPULAR CHARACTERS! ’,
    ‘http://www.amazon.com/dp/B00KGJVRNE?tag=mypred-20'
    )
ON CONFLICT DO UPDATE SET description=excluded.description;

這邊用的是 ON CONLIFCT DO UPDATE SET，在 MySQL 則是用 ON DUPLICATE UPDATE。

UPSERT

維基百科對 UPSERT 的說明：(取自「Merge (SQL)」條目)

A relational database management system uses SQL MERGE (also called upsert) statements to INSERT new records or UPDATE existing records depending on whether or not a condition matches.

在 MySQL 裡的兩種語法其實就是在實做這個需求：

REPLACE INTO ...
INSERT INTO ... ON DUPLICATE KEY UPDATE ...

而前者其實是後者的一個特例 (當 INSERT 發現有 dupe key 時把現有的 record 改成與 INSERT 時相同的條件)。

而計數器是後者常見的 case 之一：當 record 不存在的時候塞一筆進去，並且將 counter 設為 1；當 record 存在的時候對 counter 加一更新。像是這樣的 SQL query：

INSERT INTO my_table SET id = ?, num = 1 ON DUPLICATE KEY UPDATE num = num + 1;

由於這是常見的需求，使得這個語法是目前少數 MySQL 比 PostgreSQL 好用的地方。

在「A Case for Upserts」這篇就看到抱怨 PostgreSQL 不實做這個功能...

不過我覺得作者寫得有點誇張，INSERT INTO ... ON DUPLICATE KEY UPDATE ... 應該是可以模擬出來的功能：當 INSERT 失敗後再跑 UPDATE。而 REPLACE INTO ... 是特例，也就當然可以模擬出來。