在「Social Media Usage by Age」這邊看到的文章，把美國人使用社群媒體的情況做成圖，資料來源是 Pew Research Center 的「Social Media Fact Sheet」這裡。
很明顯的可以看到 Google (Alphabet) 基本上就是 YouTube 一個產品吃天下，而 Facebook (Meta) 有三個產品在滲透，包括 Facebook、Instagram 與 Whatsapp：
美國人使用社群媒體的情況
Tag: pinterest
Pinterest 對 InnoDB 壓縮的改善
三個月前 Pinterest 提到對 InnoDB 壓縮的改善，講到透過字典的改善方式：「Pinterest 在 InnoDB Compression 的努力」。
而在「Evolving MySQL Compression - Part 2」這邊繼續說明要怎麼生出對 Pinterest 比較有效的字典內容，作者把計算的工具放到 GitHub 上讓其他人可以用 (用 Python 寫的)：「pinterest/mysql_utils/zdict_gen/」。
可以看出來又增加不少壓縮率，這算是針對資料庫壓縮從 A 到 A+ 的行為吧...
Pinterest 在 InnoDB Compression 的努力
Pinterest 用 InnoDB 儲存各式資料，而且使用了 InnoDB Compression 的功能。他們花了不少力氣跟 Percona 合作改善 InnoDB Compression 的效能：「Evolving MySQL Compression - Part 1」。
文章有點長度，重點在於他們在 MySQL 裡面放了大量的 JSON：
A Pin is stored as a 1.2 KB JSON blob in sharded MySQL databases.
他們發現新版 zlib 的 predefined dictionary 可以讓壓縮率變得更高 (從本來的 ~50% 到 ~66%)；而除了壓縮率變高外，由於事先定義了字典內容，對於效能的提昇也不少 (warm up)：
Zlib version 1.2.7.1 was released in early 2013 and added the ability to use a predefined “dictionary” to prefill the lookback window for LZ77. This seemed promising since we could “warm up” the lookback window with field names and other common strings. We ran a few tests using the Python Zlib library with a naive predefined dictionary consisting of an arbitrary Pin JSON blob. The compression savings increased from ~50% to ~66% at what appeared to be relatively little cost.
另外他們做了 read-only 的 benchmark (畢竟這是重點)。圖片資料有點糊，但可以看出 y 軸是 Queries/sec。而 x 軸上則用文字給了些說明，黃色是 TokuDB，紅色是本來的 InnoDB Compression，剩下的都是不同的字典集的成果：
Below is a graph from our presentation which showed a read-only version of our production workload at concurrency of 256, 128, 32, 16, 8, 4 and 1 clients. TokuDB is in yellow, InnoDB page compression is in red and the other lines are column compression with a variety of dictionaries.
整體效率都比之前高不少，尤其是當 concurrent query 的數量偏高的時候差距會很大。
而這個功能將會納入未來的 Percona 版本，對於在 MySQL 裡面會塞 JSON 或是 XML 的人應該會很有幫助：
We worked with Percona to create a specification for column compression with an optional predefined dictionary and then contracted with Percona to build the feature.
Pinterest 對 ZooKeeper 的用法
在「ZooKeeper Resilience at Pinterest」這篇文章裡面，Pinterest 的人說明內部是怎麼使用 ZooKeeper，其中對我來說最重要的是這張圖：
程式不直接接觸 ZooKeeper 取得資料，而是透過 daemon 寫到 local disk 的資料取得。這樣當 ZooKeeper 失敗時仍然可以保持一定的服務 (因為 local disk cache)，而避免服務中斷。
當然，這跟資料的性質有關，不是所有的資料型態都可以接受 cache。這種解法常常是在穩定性不是可以自己控制 (這個例子裡是 ZooKeeper)，而且遇到問題時不希望整個服務就爆炸...
但這個思路每次看過每次都會忘記，寫下來不知道會不會比較容易想起來 :o