幹壞事是進步最大的原動力
剛好今天才被問是不是可以在 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…
Twitter 上看到會場的照片，Amazon S3 單一 region 就有 37 Tb/sec 的量：
um, a baking powder?
37 Tb/s is part of S3 traffic in a single region?!?!?#reinvent pic.twitter.com/rWpnBE20HU
— Mark Nunnikhoven (@marknca) November 29, 2017
在這種量下面對 DDoS 沒什麼感覺 XDDD
另外是 Amazon S3 與 Amazon Glacier 都推出了 Select 功能：「S3 Select and Glacier Select – Retrieving Subsets of Objects」。
看示範的程式碼就可以看出用途了，原文中間那段有 sytax error，我這邊就幫忙修掉了：
handler = PrintingResponseHandler()
s3 = boto3.client('s3')
response = s3.select_object_content(
Bucket="super-secret-reinvent-stuff",
Key="stuff.csv",
SelectRequest={
'ExpressionType': 'SQL',
'Expression': 'SELECT s._1 FROM S3Object AS s',
'InputSerialization': {
'CompressionType': 'NONE',
'CSV': {
'FileHeaderInfo': 'IGNORE',
'RecordDelimiter': '\n',
'FieldDelimiter': ',',
}
},
'OutputSerialization': {
'CSV': {
'RecordDelimiter': '\n',
'FieldDelimiter': ',',
}
}
}
)這樣可以大幅降低 I/O，節省成本：
Glacier Select 也是類似的想法，不需要整包拉出來再處理，可以在一開始就設定條件。
自從 Microsoft SQL Server 宣佈可以在 Linux 上跑後 (參考「Microsoft SQL Server 出 Linux 版...」)，就沒看到什麼 Linux 上跑 SQL Server 的消息了... 結果在這波 AWS 的活動上推出了 RHEL 上跑 SQL Server 的消息：「Amazon EC2 now offers SQL Server 2017 with Red Hat Enterprise Linux 7.4」。
SQL Server 2017 is now available for Amazon EC2 instances running Red Hat Enterprise Linux (RHEL) 7.4 as an Amazon Machine Image (AMI) from the AWS Marketplace. With this release, you can now launch RHEL instances on-demand using SQL Server 2017 Enterprise License Included AMIs without having to bring your own license. SQL Server 2017 on RHEL 7.4 AMI is available in all public AWS regions starting today.
這個消息看到的時候嚇了一跳...
Amazon Aurora (MySQL) 推出新的效能改善，可以改善 JOIN 時的效能：「Amazon Aurora (MySQL) Speeds Join Queries by More than 10x with Asynchronous Key Prefetch」。
看起來像是某個情況的 optimization，將可能的 random access 換成 sequential access 而得到大量的效能：
This feature applies to queries that require use of the Batched Key Access (BKA) join algorithm and Multi-Range Read (MRR) optimization, and improves performance when the underlying data set is not in the main memory buffer pool or query cache.
其實記憶體還是最好用的加速器，能加大硬拼就先硬拼... XD
在 Facebook 上看到 Percona 的人修正了 InnoDB 的 MVCC 在繁忙時會有 
在 MySQL 官方的 bug tracking system 是「InnoDB's MVCC has O(N^2) behaviors」這個，可以看到給的重製範例是在 transaction 內大量塞 INSERT 進去後，另外一個 transaction 使用 secondary index 就會受到影響。
裡面也有提到「Secondary index updates make consistent reads do O(N^2) undo page lookups」，雖然修正了，但看起來跟當時實做的規劃有關？所以導致許多地方都是
這個 bug 感覺是批次作業的行為？因為批次作業可能會用 transaction 包起來，一次寫入萬筆資料後再 COMMIT 進去。而這個行為很有機會觸發這個 bug，導致影響到線上的服務...