Flickr 的八卦故事

Hacker News 上的討論「Whatever happened to Flickr? (」出現了不少相關的人,比原文章寫的東西更精彩一些...

可以看一下「1024core」這串,另外「simonw」這串也頗有趣的 (Simon Willison 之前也在 Yahoo! 待過),「petilon」這串也有不少討論... 但要記得這些都是八卦 XD

這幾年 Microsoft 在併購後的策略就軟多了,從 LinkedInGitHub 可以看出來...

為資料庫提案新的 UUID 格式

前幾天在 Hacker News Daily 上看到的東西,今年四月的時候有人針對資料庫提案新的 UUID 格式:「New UUID Formats – IETF Draft (」。

在 draft 開頭有說明這個提案的目標:

This document presents new time-based UUID formats which are suited for use as a database key.

A common case for modern applications is to create a unique identifier for use as a primary key in a database table. This identifier usually implements an embedded timestamp that is sortable using the monotonic creation time in the most significant bits. In addition the identifier is highly collision resistant, difficult to guess, and provides minimal security attack surfaces. None of the existing UUID versions, including UUIDv1, fulfill each of these requirements in the most efficient possible way. This document is a proposal to update [RFC4122] with three new UUID versions that address these concerns, each with different trade-offs.

另外在 Hacker News 上有人整理出來,可以直接理解提案所提出的新格式是什麼:

A somewhat oversimplified summary of the new UUID formats:

UUID6: a timestamp with a weird epoch and 100 ns precision like in UUID1, but in a big-endian order that sorts naturally by time, plus some random bits instead of a predictable MAC address.

UUID7: like UUID6, but uses normal Unix timestamps and allows more timestamp precision.

UUID8: like UUID7, but relaxes requirements on where the timestamp is coming from. Want to use a custom epoch or NTP timestamps or something? UUID8 allows it for the sake of flexibility and future-proofing, but the downside is that there's no standard way to parse the time from one of these -- the time source could be anything monotonic.

這在不同的 storage engine 上面會有不同的討論,這邊先討論 MySQL 系列的 InnoDB,至於 PostgreSQL 的 engine 以及其他資料庫系統,就另外讓更熟悉的人討論了。

InnoDB 採用了 clustered index (可以參考「Database index」這邊的說明),也就是資料本體是以某種定義的大小順序存放。

在 InnoDB 裡面則是用 primary key 的順序來存放資料 (沒有指定 primary key 時會有 fallback 行為),其他的 unique key 與 index key 則是指到 primary key,所以你可以看到 primary key 的大小也會影響到其他的 index key。

所以 128 bits 的 UUID 在大型的 MySQL ecosystem 實在不怎麼受歡迎,在 2010 年的時候 FlickrTwitter 都有發表過 ticket system:「Ticket Servers: Distributed Unique Primary Keys on the Cheap」、「Announcing Snowflake」,兩個系統有不同的需求,但都是產生 64 bits 的 unique id。

其中 Flickr 的系統算是很簡單的,沒有要保證時間順序 (i.e. 先取的號碼一定比較小,以及後取的號碼一定比較大),就用兩台 MySQL 跑 active-active 架構,然後錯開產生的值:

auto-increment-increment = 2
auto-increment-offset = 1

auto-increment-increment = 2
auto-increment-offset = 2


Flickr 限縮免費帳號的容量

Flickr 在今年四月的時候放出消息被 SmugMug 收購後 (參考先前的文章「SmugMug 買下 Flickr」),過了半年總算是有新的動作了,跟 SmugMug 完全走使用者付費的想法類似,這次將免費帳號的容量大幅限縮,從本來的 1TB 空間變成 1000 張照片,在 2019/01/08 將會生效:「Why we’re changing Flickr free accounts」。

Beginning January 8, 2019, Free accounts will be limited to 1,000 photos and videos. If you need unlimited storage, you’ll need to upgrade to Flickr Pro.

現在點進去看 Flickr Pro 的費用是 USD$35/year。我在 2005 年以 USD$59.95/year 買過當時的 Flickr Pro... 特別有印象是因為剛好是宣佈被 Yahoo! 收購的前幾天買的訂閱,在被收購後 Flickr 宣佈降價,而先前買的人直接多一年。


We are currently offering an introductory Pro Account special -- Buy yourself (or a friend) an annual Pro Account for US$41.77 and save yourself around 30% from the anticipated annual price of $59.95. That's less than $3.50 a month!

不過現在好像也用不到這個平台了... 反正都公開的資料,也許資料拉一拉丟到其他地方吧,或是想看看要怎麼放。

SmugMug 買下 Flickr

SmugMug 買下 Flickr,這應該算是好消息 (吧):「Exclusive: Flickr bought by SmugMug, which vows to revitalize the photo service」。

雙方的新聞稿是:「SmugMug acquires Flickr: Two passionate communities together at last.」與「Together is where photographers belong!」。

時代的眼淚啊... 還在交大的時候買了 Pro,後來被併進 Y! 後沒續約了。丟著直到 Instagram 可以同步上去時又有更新,然後 Instagram 停止分享到 Flickr 的功能後又改找 IFTTT 同步。

而本來做 Flickr 的那群人後來跑去做 Slack... (包括 Stewart ButterfieldCal Henderson XD)

來看看後續會有什麼改變... 第一波應該是帳號系統的轉移?然後再來是 pricing model 的改變?

Flickr 用 GPU 產生縮圖

Flickr 說明了用 GPU 產生縮圖的技術:「Real-time Resizing of Flickr Images Using GPUs」。

這邊可以看到是透過 apache module 再轉到 resize worker:

成果就是讓縮圖的產生時間縮短很多,以 2048px 轉到 1600px 為例,速度快了 15 倍,即使是與 Yahoo 自己最佳化過的版本相比,也快了 10 倍:

而 GPU-based 的架構每台 server 可以支撐 300 resizes/sec:

Equally noteworthy, at peak load, each resize server can perform over 300 resizes per second.

Flickr 也支援 OAuth Core 1.0a 了...

Flickr 宣佈支援 OAuth Core 1.0a 了:「Flickr now Supports OAuth 1.0a」,同時也宣佈舊的 API 將在 2012 年的上半年停用。文件在「User Authentication」這邊可以看到。

另外,除了推出新的 API 以外,Flickr 也提供用舊的 token 直接取得 OAuth Core 1.0a 的 access token 的 API call:

Transition from the old Authentication API

You can exchange an old auth token from the old Authentication API, to an OAuth access token token. The process simply requires that you make an authenticated request to the flickr.auth.oauth.getAccessToken API, which will exchange the old token used to make the request, with a new OAuth access token.

Please note, that the old auth token will be deleted 24 hours after calling this API method.

這個方法讓現有的應用可以直接轉換到新的 OAuth Core 1.0a API 上,不需要再認證一次。