Home » Posts tagged "virtual"

AWS 的 BYOIP 服務開放一般使用了...

先前提到的「AWS 提供自帶 IP 到 AWS 上的服務了...」只能在 us-west-2 上使用 (需要申請),現在則是開放一般使用了:「Announcing the general availability of Bring Your Own IP for Amazon Virtual Private Cloud」。

而且範圍也增加了,除了本來測試的區域 us-west-2,現在 us-east-1us-east-2 都可以用:

This feature is now publicly available in US East (N. Virginia), US East (Ohio) and US West (Oregon) AWS Regions.

費用方面也都不需要額外費用:

There is no additional charge to use the BYOIP feature. Also, you don’t have to pay for Elastic IP addresses that you create from BYOIP address prefixes.

從文件上看起來目前只支援 IPv4,每段最少需要 /24,而且每個 region 最多五個 range,另外保留使用權 (如果 IP 網段之前有很多不良記錄時 AWS 可以拒絕)。

AWS 提供自帶 IP 到 AWS 上的服務了...

AWS 宣佈提供自帶 IP 到 AWS 上的服務了:「Announcing Bring Your Own IP for Amazon Virtual Private Cloud (Preview)」。

目前只在 us-west-2 有,另外需要申請:

Bring Your Own IP is available for preview in the US West (Oregon) region. You can request access to this feature by completing this request form.

不知道是不是直接放 routing 出來?如果是的話,照慣例 IPv4 應該是至少要 /24?從申請表格上看起來像是這樣沒錯:

IPv4 Prefix you want to onboard. You need a minimum of /24 ARIN registered prefix. The Net Type should either be Allocated or Assigned:

MySQL 5.7 的 VIRTUAL column 與 index

看到 Percona 的「Using ProxySQL and VIRTUAL Columns to Solve ORM Issues」這篇後去找 VIRTUAL 的資料,發現其實以前就寫過了,而且是兩年前寫的了:「MySQL 5.7 的 JSON、Virtual Column 以及 Index」。

2NF 的規範中會禁止資料的重複性以及可推導性。以這樣的資料結構開始:

CREATE TABLE t1 (
    id INT PRIMARY KEY AUTO_INCREMENT,
    birth DATE
);

與後者這樣延伸出來的資料結構:

CREATE TABLE t2 (
    id INT PRIMARY KEY AUTO_INCREMENT,
    birth DATE,
    year INT,
    month INT,
    day INT
);

其中 t2 裡的 yearmonthday 都可以被 birth 推導,這就卡到 2NF... 會有 t2 這樣的資料結構通常都是因為效能而需要的設計。

像是 SELECT * FROM t1 WHERE MONTH(birth) = 12; 這樣的 SQL query,即使在 birth 加上 index 也沒用,因為查詢條件不是某個連續的區間。另外建出 month 欄位,再對 month 建立 index 後,SELECT * FROM t2 WHERE month = 12; 才能利用這組 index 提昇效能。

但後者的設計會導致兩個問題,一個是空間的增加,另外一個是資料一致性管理的成本。

空間的增加還蠻好解釋的,來自於多了 yearmonthday 這些欄位要儲存。而資料一致性管理的成本是因為你沒有強制性的方式讓 yearmonthday 的值與 birth 的內容一致,也就是資料庫內有可能會有 birth2018-01-01,但 month 裡卻是 2 之類的數字。

一致性在 PostgreSQL 有 constraint 與 function 計算可以擋下,但對應到 MySQL 的 constraint 就沒辦法用 function 判斷條件,變成需要在 MySQL 外的地方 workaround 確保一致性...

而這次標題提到的 VIRTUAL column 算是 MySQL 5.7 推出來解這個問題的想法,我們可以這樣設計資料結構:

CREATE TABLE t3 (
    id INT PRIMARY KEY AUTO_INCREMENT,
    birth DATE,
    year INT AS (YEAR(birth)) VIRTUAL,
    month INT AS (MONTH(birth)) VIRTUAL,
    day INT AS (DAY(birth)) VIRTUAL
);

然後對 month 建立 index:

ALTER TABLE t3 ADD INDEX idx__month (month);

接著塞資料進去測試:

INSERT INTO t3 (birth) VALUES ('2018-01-02');
INSERT INTO t3 (birth) VALUES ('2018-01-03');

拉資料可以看到,雖然塞資料進去時沒有指定 yearmonthday,但拉資料時會計算出來:

mysql> SELECT * FROM t3;
+----+------------+------+-------+------+
| id | birth      | year | month | day  |
+----+------------+------+-------+------+
|  1 | 2018-01-02 | 2018 |     1 |    2 |
|  2 | 2018-01-03 | 2018 |     1 |    3 |
+----+------------+------+-------+------+
2 rows in set (0.00 sec)

也可以看到 VIRTUAL column 的唯讀特性:

mysql> INSERT INTO t3 (year) VALUES (2018);
ERROR 3105 (HY000): The value specified for generated column 'year' in table 't3' is not allowed.

當你資料量夠多時,可以用 EXPLAIN 看 MySQL 的 optimizer 會使用哪個 index (太少的時候會 table scan...):

mysql> EXPLAIN SELECT * FROM t3 WHERE month = 2 \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t3
   partitions: NULL
         type: ref
possible_keys: idx__month
          key: idx__month
      key_len: 5
          ref: const
         rows: 4
     filtered: 100.00
        Extra: NULL
1 row in set, 1 warning (0.00 sec)

在這個例子裡用的欄位比較簡單,但如果在更複雜的案例裡面,應該會有更多地方可以發揮 (因為可以用 function 計算,這使得很多可能性跑出來),像是 Percona 的原文是以 application 沒辦法修改程式碼的前提下,可以在 ProxySQL 與 MySQL 端做出哪些改變讓效能變好。

應該是有不少情境可以用,再多想看看好了...

Linode 記憶體升級,以及新的日本機房計畫

Linode 的 13 歲禮物:「Linode’s 13th Birthday – Gifts for All!」。包括了記憶體的升級計畫:

Old PlanNew PlanPrice
Linode 1 GBLinode 2 GB$10/mo ($0.015/hr)
Linode 2 GBLinode 4 GB$20/mo ($0.03/hr)
Linode 4 GBLinode 8 GB$40/mo ($0.06/hr)
Linode 8 GBLinode 12 GB$80/mo ($0.12/hr)
Linode 16 GBLinode 24 GB$160/mo ($0.24/hr)
Linode 32 GBLinode 48 GB$320/mo ($0.48/hr)
Linode 48 GBLinode 64 GB$480/mo ($0.72/hr)
Linode 64 GBLinode 80 GB$640/mo ($0.96/hr)
Linode 96 GBLinode 120 GB$960/mo ($1.44/hr)

比較小的機器都是 double RAM,比較大的機器就沒那麼明顯了... 但這樣就超越 DigitalOcean 的規格,而且還領先其他 VPS 不少。

不過由於東京機房已經滿了,這次升級不包括在內,但也透漏了東京的新機房將會在今年年底前啟用:

Unfortunately, since Tokyo is sold out, the upgrade is not available there. We hope to have our second Tokyo facility online before the end of the year.

是個好消息 XD

MySQL 5.7 的 JSON、Virtual Column 以及 Index

Percona 提到了 MySQL 5.7 的 JSON 與 virtual column,再加上 index 後的效能提昇:「JSON document fast lookup with MySQL 5.7」。

每一家都把這些功能給做出來了,在 MySQL 5.7 提供了 JSON 格式:

CREATE TABLE `test_features` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `feature` json NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

而你可以對 JSON 欄位運算,拉出資料後產生出 virtual column:

ALTER TABLE test_features ADD COLUMN street VARCHAR(30) GENERATED ALWAYS AS (json_unquote(json_extract(`feature`,'$.properties.STREET'))) VIRTUAL;

然後就可以對 virtual column 下 index:

ALTER TABLE test_features ADD KEY `street` (`street`);

接著對 virtual column 查詢的速度就會超快:

SELECT count(*) FROM test_features WHERE street = 'BEACH';

其實不一定要 JSON,光是 virtual column 與 index 就可以解決老問題:

已經有使用者所在的國家,想要快速查詢使用者是住在哪個洲 (亞洲、歐洲、美洲、...)。

以前是另外拆出一個欄位來做,用 trigger 更新確保資料正確性後,再對拆出來的欄位下 index。現在可以用 virtual column 建立出來下 index。

Google 的 Load balancer:Seesaw

前幾天因為流感而睡太多,來消化一些文章。

上個星期 Google 放出一套用 Go 寫的 Load balancer,叫 Seesaw:「Seesaw: scalable and robust load balancing」。

比較有趣的是 BGP 與 anycast VIP 的能力:

Seesaw v2 provides full support for anycast VIPs - that is, it will advertise an anycast VIP when it becomes available and will withdraw the anycast VIP if it becomes unavailable.

Google 這個規模玩的是不同 scale 的花樣...

Minecraft 與 Bitcoin 的結合?

VentureBeat 的這篇「How Minecraft may make bitcoin the ‘official currency of virtual worlds’」讓人想了一下遊戲的虛擬貨幣與 Bitcoin 的結合...

與以往的不一樣的情況:

  • 不需要找金流系統接,Bitcoin 可以直接獨立運作,馬上可以想到不少方法利用 Bitcoin 的架構來規劃虛擬貨幣。
  • 法令更不容易管制,如果遊戲本身再透過 Tor 隱藏在 Tor network 裡的話就更完整。以往在最後要換錢的部份都還會經過金流系統與實體界接,現在連這個部分都避開了。

再來是 Bitcoin 的中立性,跨遊戲之間的交易也許是另外一個可能的強大之處?

不過 Bitcoin 的 n=6 確認應該會讓人感覺到愈來愈痛,不知道後面會怎麼解決...

Instagram 從 AWS 搬到 Facebook 機房

InstagramInstagram Engineering Blog 上宣佈的消息:「Migrating From AWS to FB」。

整個 migration 的過程是採取不停機轉移,所以 effort 比直接停機轉移高很多:

The main blocker to this easy migration was that Facebook’s private IP space conflicts with that of EC2. We had but one route: migrate to Amazon’s Virtual Private Cloud (VPC) first, followed by a subsequent migration to Facebook using Amazon Direct Connect. Amazon’s VPC offered the addressing flexibility necessary to avoid conflicts with Facebook’s private network.

先把整個系統轉移到 Amazon VPC 裡,然後再拉 AWS Direct Connect 串起來,接下來才是慢慢把 instance 轉移到 Facebook 的機房內。

中間也有一些工作:

To provide portability for our provisioning tools, all of the Instagram-specific software now runs inside of a Linux Container (LXC) on the servers in Facebook’s data centers.

所以已經導入 LXC 了...

HHVM 2.3.0 支援 FastCGI...

HHVM 官方的 blog 上看到 2.3.0 的消息:「HHVM 2.3.0 and Travis CI」。

GitHub 上的「FastCGI」這頁就有提到要怎麼透過 FastCGI 界面跟 Apache 配合,熟悉 nginx 的人也應該可以輕鬆對應過去。

另外一個重要的事情是 Travis CI 支援 HHVM 了,可以看到大量的專案加上 HHVM 測試:YiiSlimphpBBJoomlaDoctrineCodeIgniterIdiormPHPUnitParis

既然支援 FastCGI 了,來找機會測試看看...

Archives