InnoDB 的 BLOB field 存放的方式

這邊的 BLOB field 指的包括 VARCHAR、VARBINARY、BLOB、TEXT 這些常常被拿來放大物件的類型:「Externally Stored Fields in InnoDB」。

這跟 InnoDB 存放的格式 (ROW_FORMAT) 也有關,對於不同的格式都需要分開討論。

看之前需要帶一些背景知識,像是 Database index 裡面講到 index 種類時所提到的 Clustered。

看完後對 MySQL InnoDB 的運作方式會更了解一些,對於規劃 schema 也加減有些幫助。

Percona 講 TokuDB

Percona 的「Getting to know TokuDB for MySQL」這篇文章雖然標題是想要宣傳 TokuDB,但其實把 MySQL 的歷史也講了一遍...

前面講到 InnoDB 的崛起時,就有提到就算你不使用 InnoDB 提供的 transaction,他的 crash-safe 性質也仍然是許多人選用 InnoDB 的重要因素之一:

Even those that don’t really need transactions rejoice in the crash resistance strength of InnoDB.

後面提到 TokuDB 時當然都會提到 Fractal Tree Indexes 這個資料結構對於現代硬體設備的優點。而英文版維基百科在今年三月時總算建立了 Fractal tree index 這個條目,整理的還算完整,之前是去看投影片了解這個資料結構的特性...

Percona 目前對 TokuDB 的等級是放在 beta 版,等 GA 後再來完整的測過一次,另外也想要測能不能在同一個 transaction 內使用 InnoDB table & TokuDB table,這對 zero-downtime migration 還蠻重要的,如果不可行的話工程就比較大了...

資料結構、RDBMS、ORM

欠了很久的雜記。既然是雜記,只是把一些事情記錄下來,許多句子的主題會跳來跳去,請多見諒。

先解釋標題的三個詞彙。這邊要講的是三種存取資料的方式:

  • 資料結構:直接操作最底層的資料結構。
  • RDBMS (Relational Database Management System,關聯式資料庫):透過 RDBMS 存取資料的方式,在 open source 領域比較常遇到 MySQLPostgreSQL。由於與下面的 ORM 比較,這一條指的是透過 SQL query 去存取資料。
  • ORM (Object-Relational Mapping):透過程式語言的 object 以及 object 之間的關聯性存取資料。

彈性最高、效能也最好的是直接的資料存取,但寫起來也最複雜;而 ORM 大致上就是反過來。

現代的 RDBMS 大多都有實做 ACID,在自己操作資料結構時考慮這塊會比較辛苦。兩個層級之間有一些 library 試著解決這個問題 (像是 BerkeleyDB 或是 LevelDB),不過這篇文章暫時跳過。

MySQL 與其他的 RDBMS 比較起來欠了許多東西,但 High Availability 的成熟度以及效能而成為 open source 的第一選項。而也因為許多人使用,大家都知道 MySQL 的先天限制,也有許多 workaround 出現,所以大多數的狀況下這不是問題。

MySQL 的 InnoDB 其實寫的相當不錯,但 MySQL 的 SQL parser 一直都是 MySQL 的痛處,所以許多人使用 MySQL 時會儘量使用 simple query,而 ORM 的特性剛好可以搭上風。

使用 ORM 時最常見要避免的是 N+1 的問題,其他常見到的問題大多都不是 ORM 專有的。

先整理到這邊。

RAID 卡的電池維護

實際的世界都是由 workaround 疊 workaround 解決問題的...

MySQL 資料庫一般都用 RAID 10,利用 RAID 1 的特性保護資料,並且利用 RAID 0 的特性提昇 IOPS 能力。

而這些 RAID 卡通常都會提供 cache,預設應該都會開 read cache,可以大幅增加 random read 的速度。而另外也可以打開 write cache (也就是 write-back),寫入時先寫到 cache 裡,RAID 卡馬上就會跟作業系統回報完成,藉以加速 random write 的速度。

但這樣就會有風險,當資料還沒寫入硬碟就斷電時就會遺失資料。所以在設定 write-back 的 RAID 卡上安裝電池就變成解法之一。

而電池會有壽命問題,所以配電池的 RAID 卡會每隔一陣子就放電測試電池可以撐多久,但在放電測試時,如果斷電就有可能造成資料遺失,於是又冒出很多方法解決。

也就是在「Learning to Deal With Learning」這篇提到 RAID 卡電池維護的事情。

每一層都是 workaround 想辦法解決問題,然後再用 workaround 解決前面造成的問題...

Anyway,有幾種解法,其中仍然對上層作業系統與應用程式透明的解法是:

  • 雙電池架構,很明顯的可以一次只測一顆。
  • 改用 NVRAM,就不需要電池了,不過速度以及成本會是另外一個問題。

另外,對上層作業系統與應用程式有影響的方式:

  • 放電測試時將 write cache 關閉,切回 write-through。這點在原文裡也有提到,效能其實會受到蠻大的影響。
  • 不放電測試了,但這樣的缺點就是拿安全性交換,當斷電時不知道能不撐過去。
  • 或是自己控制放電測試的時間,這可以配合上面切回 write-through 的方式,挑負載比較輕的離峰時間做。

看了下來雙電池架構還不錯,增加的成本還算可以接受,而且因為效能不受到影響,也確保資料安全性,整體維護起來比較簡單。而之後在規模更大的時候,應該就會直接考慮跳到自己放電測試的方式來處理電池問題...

美國 2013 年行動數據使用量增加了近一倍...

Slashdot 上消化新聞的時候看到的:「U.S. Mobile Internet Traffic Nearly Doubled This Year」。引用的報導是「U.S. Mobile Internet Traffic Nearly Doubled This Year」,原始的報導在「2013 – The year in mobile」。

全球的平均值從 2012 年的 140MB/month 變成 240MB/month。而美國從 690MB/month (2012) 成長為 1.2GB/month,瑞典的用量則是到 7GB/month。LTE 成為趨勢,電信商也不斷地在升級...

智慧型手機方面,AppleSamsung 獨佔市場,其他的牌子愈來愈小。

看起來台灣離全球的差距愈來愈大了...

NSA 每天從全世界的基地台蒐集行動電話資料,所以全民公敵裡演的都是真的嘛...

雖然也不怎麼意外了,不過看到還是想要碎碎唸一下...

NSA 每天從「全世界的」基地台蒐集五十億筆資料:「NSA Tracking Cellphone Locations Worldwide」。

全世界啊... 感覺 Hadoop 之類的 big data 技術論壇找 NSA 很有看頭啊 @_@

Update:有人給了模擬案例了「Meet Jack. Or, What The Government Could Do With All That Location Data」:

Linux kernel 內的資料結構與演算法...

Theoretical Computer Science Stack Exchange 上,有人問到有沒有哪些軟硬體的 source code 是可以跟學生說明某些經典演算法的重要性:「Core algorithms deployed」。

下面就有人列了 Linux kernel 內的演算法,以及對應的程式碼。相當長的一份列表...

除了 Linux kernel 外,也還有其他大型 open source 專案用到的資料結構與演算法...

不過看到 Bubble sort 是怎樣呢... XD

Galera Cluster 3.x 的設定...

Percona XtraDB Cluster 5.6 用的是 Galera Cluster 3.x 的 patch,所以 Percona 的人寫了一篇介紹 3.x 有哪些設定:「New wsrep_provider_options in Galera 3.x and Percona XtraDB Cluster 5.6」。

看起來來比較有影響的是 gmcast.segment=0,用在跨機房之間的判斷。

看起來應該是同一個機房要設一樣的 gmcast.segment。這個值會用在兩個地方:第一個是跨 segment 的 replication 流量會試著盡可能小。第二個是同步時的 Donor 會優先選擇同機房的節點。

其他的用預設值應該就 okay...

NSA 聽 Google 與 Yahoo! 跨機房的 LAN...

最近幾天揭露的文件顯示 NSA 在監聽 GoogleYahoo! 在內部機房內的通訊:「NSA infiltrates links to Yahoo, Google data centers worldwide, Snowden documents say」。

不是 Google 與 Yahoo! 之間的通訊,而是 Google 自家資料中心之間交換的資料 (以及 Yahoo! 自家資料中心交換的資料),像是這樣:

重點在右半塊的內部通訊內容未必會被加密...

Switch 與 Router 要內建 Wirespeed IPsec 的時代要來臨了嗎... 40Gbps (甚至 100Gbps) 的 IPsec 能力!XDDD