MySQL InnoDB 與 PostgreSQL 的 Partial Index(es) 是不一樣的東西...

MySQL InnoDB 指的 Partial Index 是:

An index that represents only part of a column value, typically the first N characters (the prefix) of a long VARCHAR value.

PostgreSQL 指的 Partial Indexes 是:

A partial index is an index built over a subset of a table; the subset is defined by a conditional expression (called the predicate of the partial index). The index contains entries only for those table rows that satisfy the predicate. Partial indexes are a specialized feature, but there are several situations in which they are useful.

先講結論,PostgreSQL 可以做掉 MySQL InnoDB 的 Partial Index 想做的事情,而且還更多。

MySQL InnoDB 的 Partial Index 是設定對 prefix index (對字串前面的 n bytes),可能的情況是 CHAR(32) 只對前面 16 bytes 索引。

PostgreSQL 的 Partial Indexes 受益於許多方面而更強大。因為有 Indexes on Expressions,所以除了可以像 MySQL 對 prefix 索引外,也可以索引 suffix,甚至是索引透過 string function 得出來的值。

像是 PostgreSQL 可以設定「我只要索引一月一日出生的人的 username」:

CREATE INDEX test_index ON test_table (username) WHERE birth_month = 1 AND birth_day = 1;

在 MySQL 裡需要反正規化後下 index,或是拆出另外一個表格再下 index 的問題,在善用 PostgreSQL 這些功能就可以省下不少功夫...

PostgreSQL 筆記...

純粹是筆記...

對於架設 server 的文件可以參考 Ubuntu 這份「PostgreSQL - Community Ubuntu Documentation」,雖然 Debian 官方也有一份「PostgreSql - Debian Wiki」,不過沒講到遠端這塊...

設定的部份:

  • 要讓遠端可以存取有兩個地方要開,一個是 postgresql.conflisten_addresses 改成 "*",另外一個是增加 pg_hba.conf 遠端連線的權限。
  • CREATE USER test WITH PASSWORD 'test_password'; 以及 CREATE DATABASE test WITH OWNER = test; 把基本的東西建好。

然後把 firewall 打開,接下來就可以從其他台連進去了。

在 PostgreSQL 上用 GPU 加速計算...

看到 PGStorm 這個 PostgreSQL 上的惡搞套件,可以把本來 CPU 要做的事情丟到 GPU 上加速...

不過例子很怪啊,不是用 R-tree index 解決的事情嗎?PostgreSQL 明明就有支援 R-tree index 啊?為什麼會要這樣設計,然後用 table scan?我再回去想想好了...

PostgreSQL 安全性更新...

PostgreSQL 在官網最明顯的位置上放出更新公告:

說明在「PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released」這頁,更新的版本分別是 9.2.4 (9.2)、9.1.9 (9.1)、9.0.13 (9.0) 與 8.4.17 (8.4)。除了公告外,在 Security Information 的資料也可以交叉看。

這次最嚴重的問題是 CVE-2013-1899,等級分類在最嚴重的 A 級,官方對這個問題的描述是:

A connection request containing a database name that begins with "-" may be crafted to damage or destroy files within a server's data directory

hmmm...

PostgreSQL 對 NoSQL 的看法...

二月的時候 PostgreSQL 的人在 FOSDEM PGDay 2013 上發表了對 NoSQL 的看法 (PDF 投影片):「PostgreSQL as a Schemaless Database.」。

先說明,這投影片相當酸 XD

不過這份投影片說明了大多數人的問題:

  • 其實大多用 NoSQL 的人不知道在用什麼...
  • 就算你知道你在用什麼,你用得很爽的功能其實在「傳統的」「SQL 架構」下效能通常都會更好...

另外我建議可以看看維基百科上的 Entity-attribute-value model,大多數你想用 NoSQL 的情況在這個 case 下就可以解決,而且效能相當好。

PostgreSQL 對 security update 的極端作法...

Hacker News 文摘上看到,PostgreSQL 決定對這次的 security update 採取最極端的作法:「Extra security measures for next week's releases」。

包括全面管制 Git repository 公開資訊:官方的 Git repository 將會在正式釋出修正前限制只有 committer 可以存取,並且暫停 GitHub 以及其他 git mirror 權限。

另外 mailing list 也受到管制,包括了 src commit log 以及 document commit log。

信件開頭就提到這次安全性漏洞足以說服 PostgreSQL 的人採取最極端的作法,避免在有修正方案前造成漏洞洩漏出來被使用:

The core committee has decided that one of the security issues due to be fixed next week is sufficiently bad that we need to take extra measures to prevent it from becoming public before packages containing the fix are available. (This is a scenario we've discussed before, but never had to actually implement.)

不過這反而讓人更關注,甚至上了 Hacker News 熱門榜...

在 PostgreSQL 裡分析 PostgreSQL mailing list 行為...

在「Analyzing PostgreSQL Email Archives with PostgreSQL」這篇文章看到的,用 PostgreSQL 所提供的功能找出一些資訊... (像是 full text search 的功能)

於是就產生出這樣的圖:(應該不用解釋?)

還有「Probability that a new thread gets a response」或是與 Competitors 相關的統計 XD

Stripe 發表了將 MongoDB 資料倒到 PostgreSQL 的工具:MoSQL

Stripe 是家電子付款的新創公司,相較於既有的電子付款機制 (像是 PayPal),Stripe 所提供的工具與介面對開發者與使用者非常友善。

昨天 Stripe 推出了即時將 MongoDB 的資料倒到 PostgreSQL 的工具 MoSQL:「Announcing MoSQL」。

據官方說法,要撈資料的時候用 SQL 比較方便,而且每個人都懂 SQL,所以他們開發了 MoSQL:

The thing is, we also love SQL. We love the ease of doing ad-hoc data analysis over small-to-mid-size datasets in SQL. We love doing JOINs to pull together reports summarizing properties across multiple datasets. We love the fact that virtually every employee we hire already knows SQL and is comfortable using it to ask and answer questions about data.

由於 PostgreSQL 9.2 支援 JSON 資料結構,感覺很像是要逃離 MongoDB 的工具啊... 雖然官方都不承認 XD

Instagram 說明用 PostgreSQL 的五個優點...

先不管 Instagram 最近的負成長以及反駁,剛剛在 Instagram Engineering 上看到對 PostgreSQL 的稱讚:「Handling Growth with Postgres: 5 Tips From Instagram

FacebookMySQL 的領域裡的實力以及貢獻度可是數一數二,但 Instagram 在被 Facebook 買下後仍然繼續使用 PostgreSQL,總是有些原因存在... 雖然真正的原因不一定是技術,但這篇試著用技術解釋的內容還是可以看一看,了解 PostgreSQL 有哪些特點...

第一個是講 partial indexes,這與 MySQL community 常講的 partial index 是不同的東西。

MySQL 的 partial index 是指只 index 某個欄位的一部分,像是 VARCHAR(255) 裡面只 index 前面的 10 chars;而 PostgreSQL 的 partial indexes 則是指符合某個條件的 row 才 index。

第二個是 functional indexes,可以針對欄位計算後再 index。MySQL 的 partial index 在 PostgreSQL 裡可以用 functional indexes + substr() 達到相同的效果,而且還有其他 function 可以用,花樣更多。

兩個都是 MySQL 做不到 (或是做不好),但 PostgreSQL 做的不錯的。一般在 MySQL 要達到 PostgreSQL 的這兩個功能需要另外開一個欄位,在裡面儲存去正規化後的值,再對這個欄位 index。

第三個是講 defrag 的事情,這部份 MySQL 也可以用第三方的工具 Percona Toolkit 搞定。第四個講 PostgreSQL 的 Write-Ahead Log,有點像是 MySQL 的 binlog。最後一個講 Python 上的 psycopg2

看來看去就是 index 那塊最明顯。可以直接減少去正規化的欄位...

看 Mozilla Database Team 的年終報告...

有時候除了可以看介紹新技術的文章學東西外,報告類的文章也可以看得出來目前的趨勢。

像是 Mozilla Database Team 的年終報告描述近況與最後這季做了哪些事情「December News from the Mozilla Database Team」:

  • 之前還在用 MySQL 5.0,現在 Migrate 到 5.1 了,另外正在嘗試 MariaDB 5.5。
  • 很大一部分是在 tune Bugzilla 的效能,包括 SQL query optimization,以及 data partition 計畫。
  • 測試 SSD 覺得不錯,看起來好像也測過 Fusion-io 的產品,不過價錢不太能接受?

另外還有一些 PostgreSQL 的說明,看起來還沒穩下來...

目前已經看到維基百科與 Mozilla 都在嘗試 MariaDB,看了看 MariaDB versus MySQL - Features 發現有趣的東西還不少,除了 Aria 以外,Virtual ColumnsDynamic columns 似乎都是有趣的東西...