Tag: global

新的 DNS Resolver：9.9.9.9

看到新的 DNS Resolver 服務，也拿到了還不錯的 IP address，9.9.9.9：「New “Quad9” DNS service blocks malicious domains for everyone」，服務網站是「Quad 9 | Internet Security and Privacy in a Few Easy Steps」，主打宣稱過濾已知的危險站台...

由政府單位、IBM 以及 Packet Clearing House 成立的：

The Global Cyber Alliance (GCA)—an organization founded by law enforcement and research organizations to help reduce cyber-crime—has partnered with IBM and Packet Clearing House to launch a free public Domain Name Service system.

也就是說，後面三家都不是專門做網路服務的廠商... 於是就會發現連 Client Subnet in DNS Queries (RFC 7871) 都沒提供，於是查出來的地區都不對，這對使用 DNS resolver 位置分配 CDN 節點的服務很傷啊... (或是其他類似服務)

這是 Google 的 Public DNS (8.8.8.8) 查出來的：

;; ANSWER SECTION:
i.kfs.io.               576     IN      CNAME   kwc.kkcube.com.country.mp.kkcube.com.
kwc.kkcube.com.country.mp.kkcube.com. 21599 IN CNAME TW.kwc.kkcube.com.
TW.kwc.kkcube.com.      188     IN      CNAME   i.kfs.io.cdn.cloudflare.net.
i.kfs.io.cdn.cloudflare.net. 299 IN     A       104.16.244.238
i.kfs.io.cdn.cloudflare.net. 299 IN     A       104.16.245.238

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Nov 18 05:30:23 CST 2017
;; MSG SIZE  rcvd: 181

這是 Quad9 (9.9.9.9) 查出來的：

;; ANSWER SECTION:
i.kfs.io.               1800    IN      CNAME   kwc.kkcube.com.country.mp.kkcube.com.
kwc.kkcube.com.country.mp.kkcube.com. 42702 IN CNAME US.kwc.kkcube.com.
US.kwc.kkcube.com.      300     IN      CNAME   i.kfs.io.cdn.cloudflare.net.
i.kfs.io.cdn.cloudflare.net. 300 IN     A       104.16.245.238
i.kfs.io.cdn.cloudflare.net. 300 IN     A       104.16.244.238

;; Query time: 294 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sat Nov 18 05:30:27 CST 2017
;; MSG SIZE  rcvd: 181

再來一點是，在科技領域相信政府單位通常都是一件錯誤的事情，我 pass... XD

MySQL 總算要拔掉 mysql_query_cache 了

半官方的 MySQL blog 上宣佈了拔掉 mysql_query_cache 的計畫：「MySQL 8.0: Retiring Support for the Query Cache」。

作者開頭引用了 ProxySQL 的人對 MySQL Query Cache 的說明：

Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck.

主要問題在於 MySQL Query Cache 在多 CPU 環境下很難 scale，很容易造成一堆 thread 在搶 lock。而且作者也同意 ProxySQL 的說法，將 cache 放到 client 的效能比較好：

We also agree with Rene’s conclusion, that caching provides the greatest benefit when it is moved closer to the client:

可以看到 Query Cache 在複雜的環境下對效能極傷。而之前也提到過類似的事情了：「Percona 對 mysql_query_cache 的測試 (以 Magento 為例)」、「關閉 MySQL 的 Query Cache」。

一般如果要 cache 的話，透過 InnoDB 裡良好的 index 應該還可以撐不少量起來。

Google 弄出來的 Grumpy：把 Python 2.7 的程式碼轉成 Go...

Google 放出 Grumpy，可以把 Python 2.7 的程式碼轉成 Go：「Grumpy: Go running Python!」。

下面看到一個留言頗有趣的：

This sad to see that Grumpy is mean to be a replacement of CPython 2.7 instead of CPython 3.x . I presume the code from youtube was written in python 2.x hence the reason but I hope we'll see Grumpy supporting python 3.x :)

回到原文，這次的需求主要是出自 YouTube 的需求：

The front-end server that drives youtube.com and YouTube’s APIs is primarily written in Python, and it serves millions of requests per second! YouTube’s front-end runs on CPython 2.7, so we’ve put a ton of work into improving the runtime and adapting our application to work optimally within it.

然後 Python 的 GIL 又被拿出來鞭屍：

除了 C extension 不支援外，還是有些「過於動態」的語法不支援：

exec, eval and compile: These dynamic features of CPython are not supported by Grumpy because Grumpy modules consist of statically compiled Go code. Supporting dynamic execution would require bundling Grumpy programs with the compilation toolchain which would be unwieldy and impractically slow.

這樣可用的範圍少不少，這個專案可以當作 YouTube 這種規模的網站所做的改善，而不是什麼可以拿來用的工具 :o

Dropbox 在全球建機房加速...

Dropbox 為了加速傳輸，在全球到處建機房降低 latency：「Infrastructure Update: Pushing the edges of our global performance」。

就他們測試發現，透過 proxy server 降低 latency 的效果很不錯：

We’ve tested and applied this configuration in various markets in Europe and Asia. In France, for example, median download speeds are 40% faster after introducing proxy servers, while median upload speeds are approximately 90% faster. In Japan, median download speeds have doubled, while median upload speeds are three times as fast.

亞洲區是效能增加最多的...

關閉 MySQL 的 Query Cache

MySQL 的 Query Cache 是目前已知效能不好的主要因素之一 (global mutex lock 的緣故)，在正式環境裡的 best practice 一般都是關閉，之前測過也是一開下去效能就會狂掉...

而 Percona 的人在討論要怎麼樣才能完全關閉 MySQL 的 Query Cache：「Is Your Query Cache Really Disabled?」，而他們發現只有在 query_cache_type 與 query_cache_size 都設為 0，而且重開 MySQL 才能完全避免 global mutex lock：

[W]e can see it is not possible to fully disable the query cache on the fly by changing query_cache_type or/and query_cache_size to 0. Based on the code and the tests, if you want to make sure the query cache is fully disabled, change query_cache_size and query_cache_type to 0 and restart MySQL.

應該是要再修正 my.cnf 的 template 了...

Netflix 開發的 Delayed Queue

原來這個叫做 Delayed Queue，難怪之前用其他關鍵字都找不到什麼資料... (就不講其他關鍵字了 XD)

Netflix 發表了他們自己所開發的 Delayed Queue：「Distributed delay queues based on Dynomite」。

本來的架構是用 Cassandra + Zookeeper 來做：

Traditionally, we have been using a Cassandra based queue recipe along with Zookeeper for distributed locks, since Cassandra is the de facto storage engine at Netflix.

但可以馬上想到不少問題，就如同 Netflix 提到的：

Using Cassandra for queue like data structure is a known anti-pattern, also using a global lock on queue while polling, limits the amount of concurrency on the consumer side as the lock ensures only one consumer can poll from the queue at a time.

所以就改放到 Netflix 另外開發的 Dynamite 上：

Dynomite, inspired by Dynamo whitepaper, is a thin, distributed dynamo layer for different storage engines and protocols. Currently these include Redis and Memcached. Dynomite supports multi-datacenter replication and is designed for high availability.

後端是 Redis 與 Memcached 的系統，可以對抗整個機房從 internet 上消失的狀態。

在設計上則是「保證會跑一次」，也就是有可能會有多次的情況，用 Dyno Queues 系統的人必需要考慮進去：

4. At-least-once delivery semantics

雖然整篇講的頗輕鬆，但實際看起來還是很厚重... 暫時還是不會用吧 :o

Percona 對 mysql_query_cache 的測試 (以 Magento 為例)

Percona 的人以現在的觀點來看 mysql_query_cache：「The MySQL query cache: Worst enemy or best friend?」。

起因主要也是懷疑 query cache 是 global mutex 在現在的硬體架構 (主要是 CPU 數量成長) 應該是個負面的影響，但不確定影響多少：

The query cache is well known for its contentions: a global mutex has to be acquired for any read or write operation, which means that any access is serialized. This was not an issue 15 years ago, but with today’s multi-core servers, such serialization is the best way to kill performance.

這邊就有點怪了，PK search 應該是個位數 ms 等級才對 (一般 EC 網站的資料量都應該可以 memory fit)，不知道他是怎麼測的：

However from a performance point of view, any query cache hit is served in a few tens of microseconds while the fastest access with InnoDB (primary lookup) still requires several hundreds of microseconds. Yes, the query cache is at least an order of magnitude faster than any query that goes to InnoDB.

anyway，他實際測試兩個不同的 configuration，首先是打開 query cache 的：

再來是關閉 query cache 的：

測試的方式在原文有提到，這邊就不抄過來了。測試的結果可以看到關閉 query cache 得到比較好的 thoughput：

Throughput scales well up to somewhere between 10 and 20 threads (for the record the server I was using had 16 cores). But more importantly, even at the higher concurrencies, the overall throughput continued to increase: at 20 concurrent threads, MySQL was able to serve nearly 3x more queries without the query cache.

跟預期的差不多，硬體的改變使得演算法也必須跟著改，不然就會遇到問題...

DynamoDB 的 Online Indexing 與 Reserved Capacity

剛剛看到 DynamoDB 的新功能以及購買 Reserved Capacity 的計費模式：「Amazon DynamoDB Update – Online Indexing & Reserved Capacity Improvements」。

可以動態增加 Global Secondary Indexes 有點像是「總算可以 ALTER TABLE 了！！！」的感覺 XDDD

而 Reserved Capacity 好像是第一次把 Capacity 類的費用 commit 化？我記得 EBS 沒有這種計費...

Amazon DynamoDB 筆記

Amazon DynamoDB 頁面上的介紹：

Amazon DynamoDB is a fast and flexible NoSQL database service for all applications that need consistent, single-digit millisecond latency at any scale.

資料型態的部份就跳過去了，這篇筆記的重點在於 index 的部份 (了解他如何 scale)，尤其是對 RDBMS 有了解的人要如何從他所設計的架構理解 DynamoDB 的 index。

理論基礎是 Amazon 在 2007 年丟出的論文「Dynamo: Amazon’s Highly Available Key-value Store」，這篇論文影響了很多 open source project。

DynamoDB 的 index 有 Primary Key、Local Secondary Index Key (LSI) 以及 Global Index Key (GSI)，在「DynamoDB Data Model」這篇有介紹。

這邊會拿 Blogger.com 這種多人的 Blog Hosting 當例子：

  • 一個 user 可以有很多 blog。(table user)
  • 一個 blog 可以有很多 post。(table blog)
  • 一篇 post 可以有很多 comment。(table post)

接下來就從 Primary Key 開始講。

Primary Key

Primary Key 保證唯一，這也是 DynamoDB 裡面可以達到 RDBMS 的 UNIQUE KEY 效果的最佳方式。

有兩種 Primary Key 的型態，一種叫做 Hash，另外一種叫做 Hash-Range。

兩種都需要指定某一個欄位是 Hash-based column，當作切割 (partition) 的依據。

第一種：Hash

以 table user 來說，可以拿 user_id 來當作 Hash-based column，裡面有 blog_id 的 list。

以 table blog 來說，可以拿 blog_id 來當作 Hash-based column，裡面有 post_id 的 list。

要注意的是，如果表格 PK 是 Hash，那麼就不能使用 LSI 與 GSI 了。只有另外一種型態 (Hash-Range) 才可以用 LSI 與 GSI。

相對的，Hash-based 的表格因為功能有限，效率通常很好 XDDD

第二種：Hash-Range

其實 Hash-Range 是一種別的 LSI，兩者最大的差異就是唯一性了。

另外一種 Primary Key 是 Hash-Range，他需要指定兩個欄位，其中其中 Hash 的欄位就如同上面的解釋，當作資料切割的依據。這邊的唯一性是指 (Hash column, Range column) 唯一，而非只有 Hash 唯一或是 Range 唯一。

剛剛說到需要指定的另外一個欄位，被稱為「Range」的原因是因為他可以有效率的以 hash + range query 查詢資料。

以 table post 來說，可以拿 blog_id 當作 Hash-based column，再拿 post_id 當作 Range-based column，等下我們介紹 LSI 時再拿發表時間欄位排序。

同理，table comment 可以拿 (post_id, commend_id) 當 PK。

Query

PK 是 Hash 的當然就是指定 Hash-based column 直接查，條件只能是等號。

PK 是 Hash-Range 的除了可以用 Hash-based column 直接查 (還是只能用等號)，另外可以用 Hash-based column + Range-based column 查。

以 SQL 的想法就像是 WHERE hash_col = 123 AND range_col BETWEEN (123, 456) 的感覺。反正 Hash-based column 一定要等號。

講到這邊，其實讀過上面提到的 Amazon 那篇論文應該就大概有感覺架構是怎麼搞的了：(這是推敲出來的，未必是實際架構)

  • 用 Hash-based column 切 consistent hash ring 塞到不同機器上。PK 是 Hash 的到這邊就搞定了。
  • PK 是 Hash-Range 的，還是照上面一條提到的，用 Hash-based column 切開，所以同樣的 Hash-based column 的資料都會塞到同一台機器上，於是就可以用有效率的 ordered tree 來存放 Range-based column 的資料，這樣就可以提供 query 了。

當然，考慮到需要實做 rebalance 機制以逐步擴充，這邊 consistent hash ring 的部份的作法可以更細膩，不過就不是這篇要談的重點了。

接下來要講重頭戲 LSI 與 GSI 了。

Local Secondary Index (LSI) 與 Global Secondary Index (GSI)

前面有提到 LSI 與 GSI 必須 PK 是 Hash-Range 的情況下能用，兩者都不強制唯一性。

LSI 與 GSI 都是 (Hash-column based, Range-column based) 的形式，差別在 LSI 的 Hash-column based column 必須跟 PK 的相同，GSI 的可以不用一樣。

所以對於 table post 可以加一個 LSI (blog_id, post_datetime)，就可以用 WHERE blog_id = 123 ORDER BY post_datetime DESC 拉出對應的文章了。

同理，table comment 是 (post_id, comment_datetime)。