幹壞事是進步最大的原動力
看到「Turn the web into a database: An alternative to web crawling/scraping」這篇，在介紹自家 Mixnode 這個產品，看起來是提供 SQL 界面分析整個 Web 的服務...
這類服務最重要的反而不是搜尋界面 (有可以讓程式接的 API 其實就 ok 了)，重要的是後面的資料庫有多豐富...
在「用 PublicWWW 分析網站」這邊有提到類似的服務 PublicWWW，而且也一樣有提供 API，先把 Mixnode 丟著記錄起來就好，等有需要的時候再去申請 trial account...
Google 總算提供把 Cloud SQL 放進內部網路的選項了，雖然目前還是 beta 版本在測試：「Introducing private networking connection for Cloud SQL」。
透過 VPC peering 把自己的網路與 Cloud SQL 的網路接起來，就不需要有 Public Endpoint，於是就有更低的 latency 與更好的安全性。
Amazon Aurora 推出了 Parallel Query，可以加速計算速度：「New – Parallel Query for Amazon Aurora」。原理是利用 Aurora 把 storage 層打散的前提，所以有機會透過螞蟻雄兵處理：
官方給的範例可以連到原文去看，可以看到有打開 aurora_pq 與沒打開的效能差異：
15 rows in set (1 min 53.36 sec)
15 rows in set (1 hour 25 min 51.89 sec)
打開後大約是原來的 1/45 時間，提昇超多...
不過還是有些限制，我最在意的就是目前只支援相容於 MySQL 5.6 的版本 (居然不是先支援 5.7)：
Engine Support – We are launching with support for MySQL 5.6, and are working on support for MySQL 5.7 and PostgreSQL.
然後沒有多餘費用，只是 i/o cost 可能會增加：
Cost – You can make use of Parallel Query at no extra charge. However, because it makes direct access to storage, there is a possibility that your IO cost will increase.
看到「SQL Style Guide」這個網站，把 SQL 常見的行為都列出來，寫了一份規範... 每個團隊未必都要照這個規範走，可以透過他條列的項目思考，再改成自己團隊的規範。
附註一下，最底下有繁體中文的翻譯版本，如果懶的看英文的版本可以看這份：「SQL樣式指南 · SQL Style Guide」。
剛好今天才被問是不是可以在 Amazon Aurora (MySQL-Compatible Edition) 裡面翻出有哪些 Slow Query，剛好想到這幾天發表了這個功能：「Amazon Aurora Publishes General, Slow Query and Error Logs to Amazon CloudWatch」。
You can now configure the MySQL-compatible edition of Amazon Aurora to publish general logs, slow query logs, and error logs to Amazon CloudWatch Logs. Previously, you could only publish audit logs.
看起來是要另外開 (畢竟 CloudWatch Logs 不是免費的 XD)，不過以這類型的 log 產生速度與數量來說應該還行...
Percona 的「Leveraging ProxySQL with AWS Aurora to Improve Performance, Or How ProxySQL Out-performs Native Aurora Cluster Endpoints」這篇有夠長的，其實就是發現 AWS 的 Amazon Aurora 只使用 Cluster Endpoint 無法壓榨出所有效能，只有當你讀寫分離拆開 Cluster endpoint 與 Reader endpoint 時才能提昇效能。主要是在推銷 ProxySQL 啦，其他的軟體應該也能達到類似的效果...
然後這張怪怪的，應該是 copy & paste 上去的關係？
因為事後再疊 ProxySQL 進去不會太困難，一般還是建議先直接用服務本身提供的 endpoint (少了一層要維護的設備)，等到有遇到效能問題時再來看是卡在哪邊，如果是 R/W split 可以解決的，才用 ProxySQL 或是其他軟體來解...
AWS 宣佈 Microsoft SQL Server 可以跑在 t2 系列的機器上了：「Amazon EC2 T2 instance types are now supported on Windows with SQL Server Enterprise」。
不過應該是因為記憶體限制，目前只開放 t2.xlarge (8GB RAM) 與 t2.2xlarge (16GB RAM) 上可以跑：
Windows with SQL Server Enterprise Edition is now available on t2.xlarge and t2.2xlarge instance types.
馬上可以想到的是測試環境，另外就是某些不能關機的內部系統，可以用離峰時間累積 CPU credit 之類的應用？
就如同上一篇提到的，Trac 在 1.1.1 後新增了 time 格式，所以本來的 DateFieldPlugin 有些資料要轉換。我這邊只有用在 Due Date，所以就是轉 due_date 的資料而已。
先把 due_date 都改成 due_date_bak：
UPDATE ticket_custom SET name = 'due_date_bak' WHERE name = 'due_date';
然後重新計算資料，這邊是因為所有的系統都是 UTC，所以直接轉就可以了：
INSERT INTO ticket_custom (ticket, name, value) SELECT ticket, 'due_date', LPAD(UNIX_TIMESTAMP(STR_TO_DATE(value, '%Y-%m-%d')) * 1000000, 18, '0') FROM ticket_custom WHERE name = 'due_date_bak';
而我的 Report 有用到 due_date 欄位的東西，本來是 c.value 直接輸出，現在要改成：
FROM_UNIXTIME(CONVERT(c.value / 1000000, UNSIGNED INTEGER), '%Y-%m-%d') AS due_date
Trac 1.2 相較於 1.0 最不習慣的地方應該是修改界面的位置改變了，現在 Add Comment 變成在 Modify 下面，有點不太習慣，但之後用久了應該就會習慣了。其他的修一修改一改都會動了...
AWS 宣佈了 Amazon Aurora (MySQL) 支援 Parallel Query：「Amazon Aurora Parallel Query is Available for Preview」。
這邊提到的 Parallel Query 比較像是 Amazon Athena，直接把單一 Query 打散到多台機器上跑：
Amazon Aurora Parallel Query improves the performance of large analytic queries by pushing processing down to the Aurora storage layer, spreading processing across hundreds of nodes.
也就是說，這算是單一 SQL Query 平行運算的進階版本。
在這之前，AWS 都已經支援單一 Query 在單台機器上利用多 CPU 平行運算。其中 PostgreSQL 是 9.6+ 本身就有支援。Amazon Aurora (MySQL) 則是在 2016 時透過 Parallel Read Ahead 支援某些情境下的的單一 Query 多 CPU 運算了 (發現之前沒寫到...)：「Amazon Aurora Update – Parallel Read Ahead, Faster Indexing, NUMA Awareness」。
這個功能目前是 Preview 階段，然後開在這些地區讓大家測試使用：
The preview is available for the MySQL-compatible edition of Amazon Aurora, and is currently available in the US East (N. Virginia), US East (Ohio), US West (Oregon), and Europe (Ireland) Regions. Sign up to get access.
這個功能提供了想要提昇效能，但懶得改架構的人可以用錢直接硬換出來...
看到「That time Larry Ellison allegedly tried to have a professor fired for benchmarking Oracle」這篇文章的講古，想起很久前就有聽過 Microsoft 有這樣的條款 (禁止未經原廠同意公開 benchmark 結果)，原來是 Oracle 在三十幾年前創出來的？而且這種條款還有專有名詞「DeWitt Clauses」，出自當初被搞的教授 David DeWitt...
Microsoft 的條款是這樣：
You may not disclose the results of any benchmark test … without Microsoft’s prior written approval
Oracle 的則是：
You may not disclose results of any Program benchmark tests without Oracle’s prior consent
IBM 的反而在 license 裡面直接允許：
Licensee may disclose the results of any benchmark test of the Program or its subcomponents to any third party provided that Licensee (A) publicly discloses the complete methodology used in the benchmark test (for example, hardware and software setup, installation procedure and configuration files), (B) performs Licensee’s benchmark testing running the Program in its Specified Operating Environment using the latest applicable updates, patches and fixes available for the Program from IBM or third parties that provide IBM products (“Third Parties”), and © follows any and all performance tuning and “best practices” guidance available in the Program’s documentation and on IBM’s support web sites for the Program…