Slack 支援多人討論群組

Slack 宣佈支援多人討論群組了:「Group Messages Come to Slack」。之前要找一群人討論事情必須要開一個 Private Channel,但每次開 channel 都要想一個名字出來很討厭,後來都用 #test_201510290916 這種沒有意義的名字,而現在可以直接拉人進來了:

另外一個是跟著的改變:「Private Groups become Private Channels」。

With the introduction of group DMs, which will cover many of the use cases that previously required private groups, we’ve transformed private groups into the brand new “private channels”. Private channels will be shown mixed in with your existing open channels alphabetically, with small lock icons next to the private ones. When the time comes to create a new channel, you’ll find a new public/private toggle on the configuration screen.

原先的 Private Channel 就跟 Public Channel 混在一起了...

MySQL 在處理 GROUP BY 時選擇 index 的效率問題

Percona 的「Speed up GROUP BY queries with subselects in MySQL」這篇講了 MySQL 在處理 GROUP BY 的效率問題。

舉原文的例子,也就是這樣的 SQL query:(我把 command 都改成大寫,其他部份都改成小寫)

SELECT a.name, SUM(a.count) a_sum, AVG(a.position) a_avg, b.col1, c.col2, d.col3
FROM
a JOIN
b ON (a.bid = b.id) JOIN
c ON (a.cid = c.id) JOIN
d ON (a.did = d.id) GROUP BY a.name, b.id, c.id, d.id

其中 TABLE a 有 1.3M rows,而 b、c、d 都只有 5 rows。

由於會需要計算每組 (a.name, b.id, c.id, d.id)SUM(a.count)AVG(a.position),不可避免的是需要對 TABLE a 完整的掃一次。所以效能的改善會在於可以減少 temporily table 的大小。

上面這組 SQL query 會先 JOIN 完後再 GROUP BY,也就是會全部先展開後再 GROUP BY

由於 GROUP BY 所使用到的條件都可以在 TABLE a 裡面找到,所以這邊可以先 GROUP BY 後再 JOIN,降低 temporily table 的大小:

SELECT a.name, a_sum, a_avg, b.col1, c.col2, d.col3
FROM
(SELECT name, SUM(count) a_sum, AVG(position) a_avg, bid, cid, did
 FROM a
 GROUP BY name, bid, cid, did) a JOIN
 b ON (a.bid = b.id) JOIN
 c ON (a.cid = c.id) JOIN
 d ON (a.did = d.id)

原文測試出來的結果是從 2.3 秒降到 1.8 秒:

The first query took 2.3 sec avg and the optimized query took 1.8 sec average, half a second faster.

另外一個改善是再加上 covering index:

ALTER TABLE a ADD INDEX (name, bid, cid, did, count, position);

加上去之後,原來的 query 變成 1.9 秒,而改善後的變成 0.7 秒,速度快很多。不過這是 trade-off,多了這個 index 在寫入時的成本也會增加。

PostgreSQL 9.5 的 GROUPING SETS 以及 CUBE 與 ROLLUP

Zite 上看到的「Postgres finally has CUBE / ROLLUP / GROUPING SETS !」。

直接看 PostgreSQL 的文件「7.2.4. GROUPING SETS, CUBE, and ROLLUP」就可以知道用法:

=> SELECT * FROM items_sold;
 brand | size | sales
-------+------+-------
 Foo   | L    |  10
 Foo   | M    |  20
 Bar   | M    |  15
 Bar   | L    |  5
(4 rows)

=> SELECT brand, size, sum(sales) FROM items_sold GROUP BY GROUPING SETS ((brand), (size), ());
 brand | size | sum
-------+------+-----
 Foo   |      |  30
 Bar   |      |  20
       | L    |  15
       | M    |  35
       |      |  50
(5 rows)

結果就是分次 GROUP BY 的聯集。而 CUBEROLLUP 則是提供列舉的方式。

ROLLUP 的部份:

ROLLUP ( e1, e2, e3, ... )

表示階層式的列舉:

GROUPING SETS (
    ( e1, e2, e3, ... ),
    ...
    ( e1, e2 )
    ( e1 )
    ( )
)

CUBE

CUBE ( a, b, c )

則是表示 power set (所有的組合):

GROUPING SETS (
    ( a, b, c ),
    ( a, b    ),
    ( a,    c ),
    ( a       ),
    (    b, c ),
    (    b    ),
    (       c ),
    (         ),
)

也有更複雜的 CUBE ( (a,b), (c,d) )GROUP BY a, CUBE(b,c), GROUPING SETS ((d), (e)) 可以用,參考文件裡的範例即可 :p

Group.NCTU.edu.tw (2003~2013)

2003 年寫的 Group.NCTU.edu.tw,在歷經 10 年後終於歸西:

2003 年時要跨 BBS 站轉信,除了直接 innbbsd 對接外,另外一種方式是架設 News Server,讓各站透過 News Server 轉信。前者用在轉信站比較少的情境下 (因為是 O(n^2) 的設定成本),後者則是用在轉信站比較多的時候 (是 O(n) 的設定成本)。

當時幾個大站都有自己的 News Server 可以提供這項服務,包括 Ptt 的 Wrap,KKCity 的 news.kkcity.com.tw,以及無名小站 BBS 的 News Server。但即使如此,這些站台都是人工設定,每設定一次轉信要花不少時間。

當時剛好舊的 ccreader.nctu.edu.tw 退役 (印象中是一台 Pentium III 450 與 512MB RAM 的機器,掛著 10 顆各 4.3GB 的 SCSI 硬碟),就跟 cschen 要了一個 IP 與 domain,把原來的 ccreader 重新整理後,用 PHP 寫網頁的部份,Perl 拿來處理後端對 INN 的操作。而使用條款則是自己胡亂寫一通後就上線了...

上線後除了我自己的站丟上去用以外,我就開始找人用。因為當時 Ptt 的 Wrap 常常掛掉,就跑去找 in2 講,馬上就搬過來了:


原來在 SYSOP 板的那篇找不到了,只找到這篇...

過沒多久我就跑去找簡志宇問他要不要把無名的轉信 policy 也換過來。然後隔年我去 KKCity 打工的時候也說服當時站方把 news.kkcity.com.tw 凍結。

到這邊之後,就很少看到台灣還有在自己架 News Server 了... (掩面)

之後 Group.NCTU.edu.tw 再加上 RSS 的功能 (後來爛掉了),以及加上 e-mail to usenet 功能 (這功能我自己一直在用,所以沒讓他爛掉),開發完這兩個功能後也就丟著沒開發了。最多就是想到的時候上去更新 OS & ports。

後來出社會工作,再加上 twbbs.org 商業化其實我不是很開心。整個系統放著 10 顆 SCSI 硬碟跑 RAID0,雖然有備份,但其實已經沒打算要在上面弄東西了,只是沒想到最後居然是掛在 SCSI 卡上面... 這批硬碟除了這十年外,還得加上先前 ccreader 的使用,差不多十五年還沒壞,早期的硬碟真的很神猛...

掛掉後有人問我為什麼不把備份資料弄一弄再開站,除了上面講的原因外,現在交大的環境也不適合再弄這樣的服務了... 如果要繼續服務的話我希望在外面重新寫一份,而不是拿原來的資料與架構繼續做。

最後,還是得感謝當年交大計中願意提供資源讓架設這個服務。當年我從上面學到很多東西,不僅僅是程式而已,還包括第一線客服並且了解使用者想要什麼。

Percona 的「Advanced MySQL Query Tuning」...

先前在「Percona 要講進階的 MySQL Query Tuning...」提到 Percona 所辦的 Webniar「Advanced MySQL Query Tuning」的投影片放出來了:「Advanced MySQL Query Tuning」。

這份內容需要 B+Tree 操作的背景知識才能了解。裡面講了很多 GROUP BYORDER BY 混用時的 index 技巧,以及各種奇怪的 hack 方式。

內容很有用,能吸收多少就看個人造化 :p

YouTube (Google) 允許環球唱片 (Universal Music Group,UMG) 直接移除非 UMG 所擁有版權的影片

依照環球唱片 (Universal Music Group,UMG) 提供給法院的文件中,YouTube (也就是 Google) 允許 UMG 透過 YouTube 的 CMS (Content Management System) 移除「不屬於 UMG 的影片」:「Google Deal Allegedly Lets UMG Wipe YouTube Videos It Doesn't Own」,文件 (PDF) 在:「gov.uscourts.cand.248875.14.0.pdf」這邊可以下載取得。

重點在於這份文件中第四頁的這段:

The UMG-YouTube agreement grants UMG rights to effect the removal of user-posted videos through YouTube’s Content Management System (“CMS”), based on a number of contractually specified criteria that are not limited to the infringements of copyrights owned or controlled by UMG. Klaus Decl., Ex. 4 (Klaus to Kavanaugh letter, Dec. 14, 2011). Dotcom speculates in his declaration that Universal must have sent a so-called “DMCA notification form,” such as the one he printed and attached at Ex. E to his declaration, to YouTube. Doctcom Decl. ¶ 11. But UMG (which interacts with YouTube) does not use that form when requesting the removal of material pursuant to UMG’s contract with YouTube. UMG uses YouTube’s automated CMS system.

繼續來看後續吧...

INN 裡 mailpost 需要修正的部份...

上個禮拜把 Group.NCTU.edu.tw 遠端升級到 7.4-RELEASE (從 6.4-STABLE),但有人寫信反應,從 Ptt 透過信件貼到板上會失敗,找不到之前 patch 的重點,只好從頭開始一個一個解,總算是解決了:

  • 當信件內沒有 Date header 時,mailpost 會送出錯誤的 Date 欄位。目前的解法是直接不送 Date 欄位。
  • 當同一封信件寄到不同信箱時 Message-ID 會相同,不能直接帶入 newsgroup 中。目前的解法是無視信件內的 Message-ID,自己生一個。

現在這樣應該是正常了...

話說 Group.NCTU.edu.tw 最近被提說要換機器...

計中寫信來問 Group.NCTU.edu.tw 那台機器有點舊了,要不要換機器...

連進去看一下,這系統好舊啊... XD

CPU: Intel Celeron (601.37-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x68a Stepping = 10
Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
real memory = 520081408 (495 MB)
avail memory = 495312896 (472 MB)

換機器的時候順便來重寫吧,有些 plan 想做... 其中最想做的就是抽走 twbbs.org。

當初會用 twbbs.org 當其中一道 backend 的時候是因為當時 twbbs.org 是由 Ptt 的人代為管理,結果現在亂七八糟的,早點抽掉會比較好...