PostgreSQL 對 Vacuum 效能的改善

在「No More Full-Table Vacuums」這邊提到了 PostgreSQL 在 vacuum 時效能的大幅改善,尤其是大型資料庫在 vacuum 時需要對整個表格從頭到尾掃一次以確保 transaction id 的正確性:

Current releases of PostgreSQL need to read every page in the database at least once every 2 billion write transactions (less, with default settings) to verify that there are no old transaction IDs on that page which require "freezing".

這動作在資料量大的機器上就會吃大量資源導致各種討厭的現象:

All of a sudden, when the number of transaction IDs that have been consumed crosses some threshold, autovacuum begins processing one or more tables, reading every page. This consumes much more I/O bandwidth, and exerts much more cache pressure on the system, than a standard vacuum, which reads only recently-modified page.

而作者送了 patch 改成只會讀還沒搞定的部份:

Instead of whole-table vacuums, we now have aggressive vacuums, which will read every page in the table that isn't already known to be entirely frozen.

要注意的是,agreesive vacuum 相較於 vacuum 會多吃很多資源,但可以打散掉 (有點像一次大 GC 導致 lag 與多次 minor GC 讓程式反應時間變得比較順暢的比較):

An aggressive vacuum still figures to read more data than a regular vacuum, possibly a lot more. But at least it won't read the data that hasn't been touched since the last aggressive vacuum, and that's a big improvement.

這個功能預定在 PostgreSQL 9.6 出現,不知道會不會變 default...

Google Chrome 上面的畫面截圖套件

記得之前有提到最多人裝的那幾個 extension 都有嵌入各種 malware 或 spyware,所以試著找有哪個是正常的... 後來想到用 GoogleGitHub 上的 open source 專案,找到這個:「One-click full page screen captures in Google Chrome」,官方說明頁面在「Full Page Screen Capture Chrome Extension」:

It’s open source (on github) and malware free.

看起來這個應該是可以用的... 看起來很久沒更新了,不過實際測試還是會動的 :p

Twitter 的歷史資料企業方案

Twitter 宣佈可以搜尋所有公開的 tweet 了:「Instant and complete access to every historical public Tweet」。

This new product builds off of our existing 30-Day search solution and extends the available window of instant and complete Twitter access to a span of more than nine years… and counting.

提供給 Gnip 的客戶搜尋:(這家公司去年被 Twitter 買下,參考「Twitter buys social data provider Gnip, stock soars」)

The Full-Archive Search API will now allow Gnip customers to immediately search for any historical public Tweet — ever.

看起來是個半獨家生意:

For more technical information about the Full Archive Search API, you can read our support documentation, and contact the Twitter Data Sales team at data-sales@twitter.com to learn how your business can start using this new historical API today.

KKBOX 徵人:平台營運處 (API Team)

索引:


續上篇的「KKBOX 徵人」,順便跟 Client Team 的同事徵文,等他寫完後也會貼出來讓大家知道 Client Team 目前找什麼人。

Server Team 這邊徵人的部份順著每個部門說明,這次先講平台營運處 (API Team)。

曲庫開發部

曲庫開發部,負責接唱片公司所提供的 API 以及 DDEX 資料,將這些資料半自動或是自動化整合到 KKBOX 的系統內。

另外這個部門在某些情況下,會需要寫程式特殊處理曲庫資料。舉例來說,前陣子金牌大風被華納音樂集團併購,這時候就有授權單位轉移的工作要做。

人工上架的系統也是這個部門開發,由公司另外的部門作業。

API 開發部

API 開發部,負責開發與維護 KKBOX 應用程式的 API。

平台開發部

平台開發部,負責系統建制。我用條列的方式試著列一些出來:(應該是列不完)

  • 搜尋引擎的設計與維運,目前現在是使用 Solr,正在研究翻新成 Elasticsearch
  • 與曲庫開發部合作,像是音檔轉檔與 DRM 機制。
  • 與 API 開發部合作,像是依照商業邏輯選擇使用我們自己租用的國際頻寬,或是使用 Akamai 供應音檔。
  • 各種通靈業務。

影音服務開發部

影音相關的研發,也是偏 Server Side 的部份。

找什麼樣的人?

不限於這些,可以是聯集也可以有其他技能:

  • 系統分析、系統設計 (SA & SD),包括了以上業務的分析與設計,主管會調度分配對應的項目。
  • Java 工程師 (以及資深工程師),目前主要是針對平台開發部的搜尋引擎。
  • PHP 工程師 (以及資深工程師),這邊提到的四個部門都有在找。
  • Full Stack Engineer,平台開發部與影音服務開發部都有找。

待續...

冨樫中...

MySQL 5.7 的 InnoDB 的全文搜尋

在「InnoDB Full-Text : N-gram Parser」這邊看到對 MySQL 5.7 InnoDB 的全文搜尋功能介紹。開頭就有很重要的說明:

I’m now very happy to say that in MySQL 5.7.6 we’ve made use of the new pluggable full-text parser support in order to provide you with an n-gram parser that can be used with CJK!

這對資料量在中等或是更少的公司相當方便,你可以架 replication server 專門跑 search,而不需要利用 reliable queue 確保更新後推進 SolrElastic (改名了,之前叫 ElasticSearch)。

不過,如果資料量很大的話應該還是得用 Solr 或 Elastic 的方案...