投影片在「Diversity of LSM tree shapes」這邊可以看到，在五分鐘內講完的前提下規劃出的重點...
AWS 打算要推出 S3 的新產品，單價更低但反應時間更長的儲存方案：「Coming Soon – S3 Glacier Deep Archive for Long-Term Data Retention」。
It is designed for customers — particularly those in highly-regulated industries, such as the Financial Services, Healthcare, and Public Sectors — that retain data sets for 7-10 years or longer to meet regulatory compliance requirements.
看起來是那種 log 丟著就不會去動的情境... (Write once never read？XD)
Amazon EFS 也要推出 IA (Infrequent Access) 版本了，Infrequent Access 指的是不常存取的資料：「Coming Soon – Amazon EFS Infrequent Access Storage Class」。
這剛好配合上很多人拿 Amazon EFS 來堆 log 的行為... AWS 是說有機會到省到 85%，不過應該是非常大的量才有機會有這個價錢？
EFS IA reduces storage costs for files not accessed every day, with savings up to 85% compared to the EFS Standard storage class.
其實用過 Amazon EFS 的人都對效能抱怨頗嚴重 (透過 NFS 有太多操作沒辦法 cache，於是 network latency issue 就出現了)，堆 log 或是當作跨機器的空間大概是目前的主流用法...
Out of an abundance of caution, we ask that you consider changing your password on all services where you’ve used this password.
雖然使用 bcrypt，但因為透過 log 記錄下了未加密的密碼，所以就中槍了：
We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter’s system. This allows our systems to validate your account credentials without revealing your password. This is an industry standard.
Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.
這時候就要再推 Password manager 這種東西了，在每個站台都使用完全不同的密碼，可以降低這類問題帶來的衝擊...
作者用的參數是一個一個加上去，所以可以一個階段一個階段了解用途。除了可以用作者推薦的 repository 測試外，我建議大家拿個自己比較熟悉的 open source 專案來測 (有用到比較複雜的架構)：
git log git log --oneline git log --oneline --decorate git log --oneline --decorate --all git log --oneline --decorate --all --graph
git l 之類的？保留
git log 本身可以避免一些 script 用到這個指令時因為輸出格式跟預期不一樣而爛掉 XD
UPDATE 時，InnoDB 會把新資料寫到表格內，然後把可能會被 rollback 的舊資料放到表格外：
In InnoDB, only the most recent version of an updated row is retained in the table itself. Old versions of updated rows are moved to the rollback segment, while deleted row versions are left in place and marked for future cleanup. Thus, purge must get rid of any deleted rows from the table itself, and clear out any old versions of updated rows from the rollback segment.
DELETE 清除的資料則是由 purge thread 處理：
All the information necessary to find the deleted records that might need to be purged is also written to the rollback segment, so it's quite easy to find the rows that need to be cleaned out; and the old versions of the updated records are all in the rollback segment itself, so those are easy to find, too.
所以可以在 InnoDB 看到 purge thread 相關的設定：「MySQL :: MySQL 5.7 Reference Manual :: 14.6.11 Configuring InnoDB Purge Scheduling」，負責處理這些東西。
而在 PostgreSQL 的作法則是反過來，舊的資料放在原來地方，新資料另外存：
PostgreSQL takes a completely different approach. There is no rollback tablespace, or anything similar. When a row is updated, the old version is left in place; the new version is simply written into the table along with it.
Lacking a centralized record of what must be purged, PostgreSQL's VACUUM has historically needed to scan the entire table to look for records that might require cleanup.
而在今年 (2018) 的文章裡，EnterpriseDB 就提出了 zheap 的想法，在
UPDATE 時寫到 table 裡，把可能被 rollback 的資料放到 undo log 裡。其實就是把 InnoDB 那套方法拿過來用，只是整篇都沒提到而已 XD：
That brings me to the design which EnterpriseDB is proposing. We are working to build a new table storage format for PostgreSQL, which we’re calling zheap. In a zheap, whenever possible, we handle an UPDATE by moving the old row version to an undo log, and putting the new row version in the place previously occupied by the old one. If the transaction aborts, we retrieve the old row version from undo and put it back in the original location; if a concurrent transaction needs to see the old row version, it can find it in undo. Of course, this doesn’t work when the block is full and the row is getting wider, and there are some other problem cases as well, but it covers many useful cases. In the typical case, therefore, even bulk updates do not force a zheap to grow. Instead, the undo grows. When a transaction commits, all row versions that will become dead are in the undo, not the zheap.
不過馬上就會想到問題，如果要改善問題，不是個找地方記錄哪些位置要回收就好了嗎？順便改變方法是為了避免 fragment 嗎？
ExpressVPN 在土耳其的 VPN server 被抄，為了調查大使的刺殺案件：「VPN Server Seized to Investigate Russian Ambassador’s Assassination」。
A VPN server operated by ExpressVPN was seized by Turkish authorities to investigate the assassination of Andrei Karlov, the Russian Ambassador to Turkey. Authorities hoped to find more information on people who removed digital traces of the assassin, but the server in question held no logs.
ExpressVPN 官方的回覆在「ExpressVPN statement on Andrey Karlov investigation」，主要的部份是：
As we stated to Turkish authorities in January 2017, ExpressVPN does not and has never possessed any customer connection logs that would enable us to know which customer was using the specific IPs cited by the investigators. Furthermore, we were unable to see which customers accessed Gmail or Facebook during the time in question, as we do not keep activity logs. We believe that the investigators’ seizure and inspection of the VPN server in question confirmed these points.
Amazon Elasticsearch Service now supports I3 instances, allowing you to store up to 1.5 petabytes of data in a single Elasticsearch cluster for large log analytics workloads.
i3.16xlarge 單台是 15.2 TB 的硬碟空間，100 台就會是 1.5 PB，不知道跑起來會多慢 XDDD
You can request a service limit increase up to 100 instances per domain by creating a case with the AWS Support Center. With 100 instances, you can allocate about 150 TB of EBS storage to a single domain.
從示意圖可以看到結合了許多 log 資料，然後綜合判斷：
In combination with information gleaned from your VPC Flow Logs, AWS CloudTrail Event Logs, and DNS logs, this allows GuardDuty to detect many different types of dangerous and mischievous behavior including probes for known vulnerabilities, port scans and probes, and access from unusual locations.
所以連 Bitcoin 相關網站也當作條件之一 XD
開了相當多區 (相較於之前 AWS Elemental MediaOOXX 系列...)：
Amazon GuardDuty is available in production form in the US East (Northern Virginia), US East (Ohio), US West (Oregon), US West (Northern California), EU (Ireland), EU (Frankfurt), EU (London), South America (São Paulo), Canada (Central), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Mumbai) Regions and you can start using it today!
但弄到這樣的話，log server 是不是也要有稽核機制？