Home » Posts tagged "db"

AWS 推出 TSDB 服務:Amazon Timestream

AWS 推出了 TSDB 服務 Amazon Timestream:「Announcing Amazon Timestream – Fast, Scalable, Fully Managed Time Series Database – Register for the Preview」。

雖然還在 preview 階段,但從 pricing 頁面可以看出目前只有 us-east-2 (也就是 US East (Ohio) 這區) 有提供服務,跟其他服務不太一樣...

費用的部份,寫入、讀取與儲存是分開收費的,比較特別的是有三種不同的媒體可以存 (不同價錢),分別是 Memory、SSD 以及 Magnetic。然後都不怎麼便宜... 如果只是想找一個 TSDB,而且已經有量的人 (目前還沒量的其實在 MySQL 內跑一跑就好了 XD),可能還是得考慮自己用 Cassandra (或是 ScyllaDB) 之類的架構?

另外一篇相關的是「Amazon Forecast – Time Series Forecasting Made Easy」,透過分析 time series data 進行預測的 Amazon Forecast,看起來也還沒跟 Amazon Timestream 整合?

在 MySQL 上遇到 Replication Lag 的解法

看到 Percona 的 blog 上寫了一篇 MySQL 遇到 replication lag 時要怎麼解決:「MySQL High Availability: Stale Reads and How to Fix Them」,另外在留言也有人提到 Booking.com 的解法:「How Booking.com avoids and deals with replication lag」。

在業務成長到單台 MySQL server 不夠用的情況下,最簡單的擴充方式是架設 slave server,然後把應用程式裡讀取的部份導到 slave 上 (也就是 R/W split),但因為 MySQL 的 replication 是非同步的,所以有可能會發生在 master 寫入資料後 slave 還讀不到剛剛寫的資料,也就是 replication lag。

這就大概有幾種作法,一種是當發現 lag 時就回 master 讀,但通常這都會造成 master 過載... 所以另外一種改善的作法是發現 lag 時就換其他 slave 看看,但這個方法就不保證讀的到東西,因為有可能所有的 slave 都 lag。

以前遇到的時候是拆情境,預設還是 R/W split,但敏感性的資料處理以及金流相關的資料就全部都走 master。

不過文章裡的解法更一般性,在寫入時多寫一份資料,然後在 slave 等這組資料出現。唯一的缺點就是要 GC 把多寫的資料清掉...

同樣的想法,其實可以讓 MySQL 在 commit 時直接提供給 binlog 或 GTID 的資訊,然後在 slave 等待這組 binlog 或 GTID 被執行。

看起來算是很不錯的解法,不知道各家 framework 對這些方式的支援度如何...

Amazon Aurora Global Database

AWSAurora (MySQL) 推出 Amazon Aurora Global Database:「Announcing Amazon Aurora Global Database」。

看起來不是 multi-master (從 secondary region 這個字看),所以寫入的部分還是得送回 primary region 處理:

Aurora Global Database uses storage-based replication with typical latency of less than 1 second, using dedicated infrastructure that leaves your database fully available to serve application workloads. In the unlikely event of a regional degradation or outage, one of the secondary regions can be promoted to full read/write capabilities in less than 1 minute.

應該是單一 endpoint 幫你處理這些雜事...

貴不少的 DynamoDB On-Demand...

DynamoDB 用起來比較困難的部份就是規劃 R/W capacity,所以 AWS 就推出了 DynamoDB On-Demand,直接計算用多少而不用規劃 R/W capacity:「Amazon DynamoDB On-Demand – No Capacity Planning and Pay-Per-Request Pricing」。

先講一下歷史,在 2014 的時候 Jeff Barr 就有在「Auto Scale DynamoDB With Dynamic DynamoDB」這邊提到開一台 t1.micro 在上面跑程式實做 DynamoDB 的 auto scaling。

另外在 2017 年的時候 AWS 自己推出了同樣的功能,就不需要開機器了,交給 AWS 的服務處理就可以了:「New – Auto Scaling for Amazon DynamoDB」。

所以就一般性的需求來說,其實目前的方案夠用:常態性的需求提昇,以及有預期性的活動時可以手動事前提昇。

目前想到唯一會炸掉的情境應該是突然被熱門媒體報導,而導致大量的 guest session 衝進來,而且架構上又沒有針對 guest session 用 cache 擋住 (Amazon DynamoDB Accelerator 也是個選項),導致壓力就全部到後端的 DynamoDB,而 auto scaling 機制需要時間看到量才會調整,在這段時間就有可能短時間倒站。

回來看這次的 On-Demand 提出來的價錢。以 us-east-1 的價錢來看:

Write request units$1.25 per million write request units
Read request units$0.25 per million read request units

而本來要自己規劃 R/W capacity 的價錢是 (這邊是 hourly):

Write capacity unit (WCU)$0.00065 per WCU
Read capacity unit (RCU)$0.00013 per RCU

由於不管是 On-Demand 還是本來的規劃,Read 價錢都是 Write 的 1/5,所以只要看 Write 一樣可以知道差距。

接下來把 On-Demand 的價錢換算成 3600 個 request units 就可以比較單價,是 $0.0045 (Write),大約是本來版本 6.92 倍的費用...

而且對於已經有規模的應用,這邊還沒算 Reserved Capacity 會有折扣的部份?

這個定價策略讓我想到 AWS Fargate 的情況... 如果你可以接受這個價錢,你可以平常就開五倍的 R/W capacity 在上面啊 XDDD

Amazon Lightsail 也把 RDS 拿出來賣了...

RDS (MySQL) 也被 Amazon Lightsail 包裝出來賣了:「New – Managed Databases for Amazon Lightsail」。

目前支援 MySQL 5.6 與 MySQL 5.7:

We are launching with support for MySQL 5.6 and 5.7, and will add support for PostgreSQL 9.6 and 10 very soon.

然後規格與價位,其中頻寬費用是指不同區時的頻寬 (同一區內的不計費):

Data Transfer – Data transfer to and from Lightsail instances in the same AWS Region does not count against the usage that is included in your plan.

這個服務應該是目前其他 VPS 沒提供的,這樣可以預期其他 VPS 應該也會被迫推出類似的服務?然後 AWS 也會再搬其他的服務出來賣?

Cloudflare 的 Workers KV

Cloudflare 推出了 Workers KV 服務:「Building With Workers KV, a Fast Distributed Key-Value Store」。

是個 key-value 結構服務 (全球性,eventually consistent,約 10 秒的同步時間),key 的限制是 2KB,value 是 64KB,一個 namespace 最多 10 億筆資料。

讀取可以到 100k+ read/s,但寫入是 1 write/s/key,可以看出來主要是為了讀取資料而設計的。

現有的 worker ($5/month) 會送一些量,包括 1GB 的空間與一千萬次的讀取:

Your $5 monthly Workers compute minimum includes 1 GB of KV storage and up to 10 million KV reads. If you use less than the 10 million included Worker requests now, you can use KV without paying a single cent more.

超過的部份另外再收:

Beyond the minimums, Workers KV is billed at $0.50 per GB-month of additional storage and $0.50 per million additional KV reads.

這樣好像整個 blog 的基本功能都可以直接在上面跑了... 而搜尋靠外部服務,圖片與影音也可以靠外部空間協助?

Amazon Aurora 支援 Parallel Query 加速

Amazon Aurora 推出了 Parallel Query,可以加速計算速度:「New – Parallel Query for Amazon Aurora」。原理是利用 Aurora 把 storage 層打散的前提,所以有機會透過螞蟻雄兵處理:

官方給的範例可以連到原文去看,可以看到有打開 aurora_pq 與沒打開的效能差異:

15 rows in set (1 min 53.36 sec)
15 rows in set (1 hour 25 min 51.89 sec)

打開後大約是原來的 1/45 時間,提昇超多...

不過還是有些限制,我最在意的就是目前只支援相容於 MySQL 5.6 的版本 (居然不是先支援 5.7):

Engine Support – We are launching with support for MySQL 5.6, and are working on support for MySQL 5.7 and PostgreSQL.

然後沒有多餘費用,只是 i/o cost 可能會增加:

Cost – You can make use of Parallel Query at no extra charge. However, because it makes direct access to storage, there is a possibility that your IO cost will increase.

Archives