Home » Posts tagged "index"

Amazon Aurora 的 MySQL-Compatible Edition 開始提供相容於 MySQL 5.7 的服務

Amazon AuroraMySQL-Compatible Edition 開始支援相容 MySQL 5.7 的服務:「Announcing Preview of Amazon Aurora with MySQL 5.7 Compatibility」。

Amazon Aurora with MySQL 5.7 compatibility offers enhancements such as JSON support, spatial indexes, generated columns and performance improvement of 5x over MySQL 5.7, and up to 10x for spatial datasets.

雖然目前還在 Preview (需要申請才能用),而且開放區域有限,但總算是有消息了:

The preview is currently available in US East (N. Virginia), US East (Ohio), US West (Oregon), and Canada (Montreal).

會一定要 5.7 的,主要的需求應該是在 spatial index 上吧... JSON 反倒還好。

InnoDB 的 MVCC 繁忙時的效能問題

Facebook 上看到 Percona 的人修正了 InnoDB 的 MVCC 在繁忙時會有 O(n^2) 的效能問題:

MySQL 官方的 bug tracking system 是「InnoDB's MVCC has O(N^2) behaviors」這個,可以看到給的重製範例是在 transaction 內大量塞 INSERT 進去後,另外一個 transaction 使用 secondary index 就會受到影響。

裡面也有提到「Secondary index updates make consistent reads do O(N^2) undo page lookups」,雖然修正了,但看起來跟當時實做的規劃有關?所以導致許多地方都是 O(n^2)...

這個 bug 感覺是批次作業的行為?因為批次作業可能會用 transaction 包起來,一次寫入萬筆資料後再 COMMIT 進去。而這個行為很有機會觸發這個 bug,導致影響到線上的服務...

機器學習與情色產業的問題

Bruce Schneier 提到了最近幾個剛好相關的議題,關於機器學習在情色產業使用時遇到的隱私議題:「Technology to Out Sex Workers」。

第一個提到的是 PornHub 用機器學習辨識演員以及各種「其他資訊」,這邊引用的報導是 TechCrunch 的「PornHub uses computer vision to ID actors, acts in its videos」:

PornHub is using machine learning algorithms to identify actors in different videos, so as to better index them.

The computer vision system can identify specific actors in scenes and even identifies various positions and… attributes.

第二個提到的是花名與真實身份連在一起的問題:

People are worried that it can really identify them, by linking their stage names to their real names.

最後是提到 Facebook 已經有能力這樣做,而且已經發生了:

Facebook somehow managed to link a sex worker's clients under her fake name to her real profile.

Her sex-work identity is not on the social network at all; for it, she uses a different email address, a different phone number, and a different name. Yet earlier this year, looking at Facebook’s “People You May Know” recommendations, Leila (a name I’m using using in place of either of the names she uses) was shocked to see some of her regular sex-work clients.

這個議題與 Mass surveillance 有點像...。

MySQL 8.0 的功能

之前陸陸續續寫了一些關於 MySQL 8.0 的新改善 (參考「MySQL 8.0 的 performance_schema 加上 index 了...」、「MySQL 8.0 將會實作「真正的」Descending Indexes」、「MySQL 8.0 對 4 bytes UTF-8 的效能改善」),官方在 RC1 的時候整理了一篇出來:「MySQL 8.0 RC1 – Highlights」。

我覺得比較值得看的是「Better Handling of Hot Rows」、「Invisible Indexes」這兩個吧,前面這點對於效能可以有些幫助 (針對某些情境不要 waiting,直接 skip lock),後面這點對於維運應該也有不錯的幫助 (像是拔掉 index 的過渡驗證階段)。

當 MySQL 8.0 真的出了之後,Percona 應該也會出文章,到時候可以看出從不同面向的觀察與想法...

ScyllaDB 2.0 要引入 Cassandra 3.0+ 的 Materialized View

最近 ScyllaDB 的網站改版了... (有種不習慣的感覺)

ScyllaDB 2.0 打算要引入 Materialized View (出自 Apache Cassandra 3.0+):「Materialized Views preview in Scylla 2.0」。

一般 Materialized View 的實做方式是另外存一份,所以你可以在上面加 Index 之類的設定讓存取速度變快...

不過 Cassandra 不是本來就以讀慢寫快為優勢嗎,要速度可以考慮用 cache 疊出來,或是其他方式,當初 Cassandra 會開發這個功能就有點... XDDD

Pinboard 放出使用的 Database Schema

Twitter 上看到 Pinboard 放出他們的 DB Schema,可以看出他怎麼設計一個 bookmark site 的:

檔案在 Pinboard Database Schema 這邊可以看到。

比較好奇的是沒有用 utf8mb4,這代表 4 bytes 的 UTF-8 資料存不進去。另外是 user_tags 這個表格的設計方式,當初在使用 MySQL 設計 tag 架構也有類似的作法...

然後有些 index key 是多餘的 XDDD

MongoDB 的 Index 種類

Percona 的人寫了一篇簡單的文章介紹 MongoDB 的 Index:「MongoDB Indexing Types: How, When and Where Should They Be Used?」。

官方文件的「Indexes」算清楚,不過有些地雷沒講,像是 Unique Indexes 只這樣說:

The unique property for an index causes MongoDB to reject duplicate values for the indexed field. Other than the unique constraint, unique indexes are functionally interchangeable with other MongoDB indexes.

但 Percona 的人就有說出「地雷」,算是不錯的補充教材 XDDD

Unique indexes work as in relational databases. They guarantee that the value doesn’t repeat and raise an error when we try to insert a duplicated value. Unique doesn’t work across shards.

話說前陣子聽到傳言抱怨,MongoDB 的文件是行銷 & 團隊寫出來的,一堆限制都沒寫在明顯的地方... XD

在 Production 上惡搞 PostgreSQL,建立一千萬筆 Index...

在「Running 10 Million PostgreSQL Indexes In Production (And Counting)」這邊看到 Heap 他們在 PostgreSQL 上惡搞的方式。

為了效能,所以在上面建立了大量的 Partial index。像是這樣的條件 (所以其實每個都不算太大):

CREATE INDEX ON events (time) WHERE type = ‘click’ AND text = ‘login’

要注意的是 MySQL 的 Partial index 其實是 prefix index,用以減少 index 的空間要求,這在 VARCHAR(255) 以及 MD5 後的欄位還蠻有幫助的。而 PostgreSQL 的 Partial index 則是指條件式,兩者不太一樣。

不過他們還是有遇到「建立 index」這件事情的效能問題 (以及 workaround 的方式)。

不太常看到這樣惡搞,看到這篇的時候在電腦前笑的頗開心的 XDDD

MySQL 總算要拔掉 mysql_query_cache 了

半官方的 MySQL blog 上宣佈了拔掉 mysql_query_cache 的計畫:「MySQL 8.0: Retiring Support for the Query Cache」。

作者開頭引用了 ProxySQL 的人對 MySQL Query Cache 的說明:

Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck.

主要問題在於 MySQL Query Cache 在多 CPU 環境下很難 scale,很容易造成一堆 thread 在搶 lock。而且作者也同意 ProxySQL 的說法,將 cache 放到 client 的效能比較好:

We also agree with Rene’s conclusion, that caching provides the greatest benefit when it is moved closer to the client:

可以看到 Query Cache 在複雜的環境下對效能極傷。而之前也提到過類似的事情了:「Percona 對 mysql_query_cache 的測試 (以 Magento 為例)」、「關閉 MySQL 的 Query Cache」。

一般如果要 cache 的話,透過 InnoDB 裡良好的 index 應該還可以撐不少量起來。

Archives