從「開放網路」到「AI主導」:一場網路內容生態的劇變

1990年代,我初次接觸網路時,那是一個屬於開放網路(Open Web)的黃金時代。無論是BBS的轉信板、Usenet,還是當時親手「烘培」的網頁(homepage),所有內容都沒有一個集中的儲存點,而是分散在網路的各個角落。

這樣的好處是,每個網路參與者都真正「擁有」自己的內容;但相對地,參與者需要具備一定的技術門檻才能儲存或創造內容。也因為內容是如此分散,「搜尋引擎」這項產品應運而生,讓使用者能更輕易地找到所需的資訊。Google也因此在這個開放網路時代,成為了無可爭議的霸主,直到AI時代的來臨。

事實上,Google搜尋的商業模式與開放網路緊密相連。在2000到2010年間,Google推出許多功能與產品,如AdSense、Google Reader、PubSub等,無不希望擴大開放網路的影響力。

封閉花園的崛起、開放和封閉的戰爭

然而,開放網路的局面從2000年代開始有了巨大轉變。隨著社群網路的興起,以及iPhone的橫空出世,「封閉花園(Walled Garden)」模式開始大行其道。這種模式讓服務提供者能更好地控制內容品質,對消費者而言,獲取內容也更加便利。因此,封閉花園模式不斷擴張,Facebook(Meta)和後來的TikTok便是其中的佼佼者。

以網路內容消費的生態系統來看,主要有四個角色:內容生產者、內容消費者、內容分發者和廣告商。由於一般內容消費者不會直接付費,大多數內容都是透過廣告模式來獎勵內容生產者,以維持優質內容的產出。不論是單純的展示廣告、導購連結,甚至是業配,本質上都是讓消費者認識廣告商產品的過程。封閉花園模式大大降低了生產者的製作成本(例如:不需懂架設網站),也降低了消費者的獲取成本(例如:打開App就有大量內容),因此深受生態系參與者的青睞。

AI浪潮下的內容生態巨變

如果沒有AI,或許開放網路還能抵抗這股潮流一陣子。尤其當區塊鏈(Blockchain)興起時,開放網路陣營不斷嘗試,是否能透過區塊鏈這個新技術,讓內容提供者在獲利時不必再被內容分發者抽成。但AI的出現徹底改變了這一切。當消費者可以直接提問,且AI能不厭其煩地給予答案時,誰還會想費力搜尋呢?人性本就懶惰,沒人會想點擊AI回覆下的腳註連回原始內容,那些依附在內容上的聯播網廣告,自然也無人問津,收入也將隨之消逝。

雖然內容依然是王道,但未來的優質內容,很可能將演變成各家AI服務商「付費」取得的局面,變成各家服務商的封閉花園。不再是1990年代那種內容創作者即是內容擁有者的時代了。

僅以此文,致那逝去的美好年代。
(本文在開放網路下的 Blog Software 寫作)

《技術管理觀點》電子報

工作到現在,覺得還是需要把自己的管理觀點寫下來,但又覺得不太適合寫在這個 Blog 內(還是想把這個 Blog 維持比較技術、新產品類的分享)。所以另外開了一個 Substack 的平台:《技術管理觀點》電子報

目前固定週一會推出一篇技術管理的文章,包含軟體工程師的面試報到培育績效評估晉升等。也有不定期出刊的閒聊文章,例如談技術債

如果對管理有興趣,想與我討論的話,可以在平台內留言,或是到 Facebook 粉絲團:技術管理觀點 私訊唷!

MCO Visa debit 卡,在台灣可以申請到的加密貨幣金屬卡

實體的卡片照片,在台灣難得可以拿到的金屬卡

這是一張蠻特別的卡片,由加密貨幣交易所新創 crypto.com 發行。需要抵押 50 MCO(約新台幣 8,000)元六個月,即可取得一張「金屬」的 debit card。六個月後,可以把這 8,000 取回,可以直接刷卡花掉,或是透過 ATM 提領出來(國泰世華ATM不收手續費)。

我在 4 月申請的,因為疫情的關係,卡片五月中才到;但最近改用 DHL 寄送之後,通常兩三天就會到了。

到六月底為止,在家樂福(需用 line pay)、UberEats 消費,皆回饋 10%

你可以透過信用卡儲值(手續費1%)到卡片內,再透過卡片消費,或是將比特幣、以太幣換成法幣後再消費也可以。

如果透過我的連結申請 https://platinum.crypto.com/r/gbb3ut2h5g,當抵押完成後,我們雙方都可以獲得等值美金 50 元的 MCO 幣。你可以直接換成法幣然後在家樂福消費。

使用 pt-stalk 找出 MySQL 效能問題

pt-stalkPercona Toolkit for MySQL 裡面的其中一項工具。它會連到 MySQL Server,監控指定的數值,當超過指定的 Threshold 時,收集當時資料庫執行的資訊(包含正在進行的 transaction、vmstat、lsof,甚至 gdb stack trace),方便分析解決問題。

pt-stalk 需要以 root 權限執行。執行的方法如下:

pt-stalk --daemonize --variable Threads_connected --threshold 400 -- --defaults-file=/etc/mysql/my.cnf

當同時有 400 以上的 Threads 時,便會收集資料,存到 /var/lib/pt-stalk 內。收集的資料範例:

2014_01_13_00_25_09-df              2014_01_13_00_25_09-lock-waits      2014_01_13_00_25_09-netstat         2014_01_13_00_25_09-ps
2014_01_13_00_25_09-disk-space      2014_01_13_00_25_09-log_error       2014_01_13_00_25_09-netstat_s       2014_01_13_00_25_09-slabinfo
2014_01_13_00_25_09-diskstats       2014_01_13_00_25_09-lsof            2014_01_13_00_25_09-opentables1     2014_01_13_00_25_09-sysctl
2014_01_13_00_25_09-hostname        2014_01_13_00_25_09-meminfo         2014_01_13_00_25_09-opentables2     2014_01_13_00_25_09-top
2014_01_13_00_25_09-innodbstatus1   2014_01_13_00_25_09-mpstat          2014_01_13_00_25_09-output          2014_01_13_00_25_09-transactions
2014_01_13_00_25_09-innodbstatus2   2014_01_13_00_25_09-mpstat-overall  2014_01_13_00_25_09-pmap            2014_01_13_00_25_09-trigger
2014_01_13_00_25_09-interrupts      2014_01_13_00_25_09-mutex-status1   2014_01_13_00_25_09-processlist     2014_01_13_00_25_09-variables
2014_01_13_00_25_09-iostat          2014_01_13_00_25_09-mutex-status2   2014_01_13_00_25_09-procstat        2014_01_13_00_25_09-vmstat
2014_01_13_00_25_09-iostat-overall  2014_01_13_00_25_09-mysqladmin      2014_01_13_00_25_09-procvmstat      2014_01_13_00_25_09-vmstat-overall

然後看 InnoDB status,可以看到很多 transaction 正在等 query cache lock:

MySQL thread id 688253701, OS thread handle 0x7f6a591c9700, query id
19004545452 10.1.1.94 pixblog Waiting for query cache lock
SELECT * FROM `blogarticle` WHERE (`blogarticle_blogid` = 3835626) AND
(`blogarticle_date` < 1388605724) AND (`blogarticle_status` IN (2,3,5,7))
ORDER BY `blogarticle_date` desc, `blogarticle_id` desc LIMIT 1
---TRANSACTION 144B7B32FC, not started
MySQL thread id 688253702, OS thread handle 0x7f6a787bc700, query id
19004544621 10.1.1.191 pixblog Waiting for query cache lock
SELECT * FROM `blog` WHERE `blog_id` = 3126963
---TRANSACTION 144B7B32FD, not started
MySQL thread id 688253706, OS thread handle 0x7f6a887e2700, query id
19004544620 10.1.1.166 pixblog Waiting for query cache lock
SELECT * FROM `bloglayout` WHERE `bloglayout_id` = 3063007
---TRANSACTION 144B7B33C7, not started starting index read
mysql tables in use 1, locked 0

發生問題的當時確實有一個跑統計報表的 Slow Query 正在執行,於是要求該 Query 不使用 Query Cache1 來解決問題。

AWS AutoScaling 終於有 Web 管理介面了…

連結:AWS 推出 AutoScaling 管理介面

使用 IaaS 這類的服務,最方便的地方就是:當有緊急需求需要增加伺服器的時候,可以直接在網頁上點一點就完成增加的動作。但是,如果收到簡訊告警的時候,剛好在沒有網路的地方,就只好遠端電話遙控同事到網頁上操作,總覺得不是那麼方便。AWS 提供的 AutoScaling 服務,可以預先設定一些條件(例如 CPU 使用率超過多少,或是 Elastic Load Balance 的 Requests/sec 數量超過多少),當滿足這些條件時,自動增加(或減少)伺服器。原本這個功能只能透過 API 設定,今天終於有網頁版了…

使用 AutoScaling 網頁介面,除了可以開一般的 Instance 以外,還可以開 Spot Instance。對於需要大量運算資源,但是即時性要求不那麼高的服務來說,可以省下不少費用。

MySQL 5.5 的 InnoDB Memcached Plugin

之前曾經提過 HandlerSocket – A NoSQL Plugin for MySQL,可以透過類似 NoSQL 的方式存取 InnoDB,效能會比普通 SQL 更好。後來 Oracle 在 MySQL 5.5 推出的時候,直接使用 Memcached Protocol,理論上應該是更方便(因為 Memcached Adapter 到處都有…)。

於是最近仔細的研究了一下,發現要使用 MySQL 5.5 的 InnoDB Memcached Plugin,要注意以下的地方:

  1. 如果要使用自行指定的 Table,需要參考 Internals of the InnoDB memcached Plugin,在 innodb_memcache.containers 設定 key 與 column 的對應表。
  2. 預設是使用 containers Table 裡面 name 為 default 的 Table。
  3. 如果要指定 Table,要在 GET 或 SET 指令前,下 GET @@nameSET @@name 將之後的 Request 都切換到 name 這個 Table。
  4. 如果需要 Replication,記得要設定 innodb_api_enable_binlog 這個值。

大概重點就這些了,如果還有玩到別的再來補充。

徵才:PIXNET 徵網路系統工程師一名

我現在服務的公司 PIXNET 要徵求一名 System Administrator:

工作內容:

  • 伺服器 (主要為 FreeBSD 與 Debian、Ubuntu 系統) 系統維護,包括套件 (ports 與 apt/deb) 維護
  • 機房與辦公室網路設備 (Cisco/Juniper Router、Switch、VPN) 維護。

工作時間:9:30 ~ 18:30 (一~五),特殊狀況時 (例如晚上處理緊急事件,或是凌晨停機等) 另外補休。
就職日:可馬上就職,或 2012 年二月到職即可。
地點:台北市中山區 (捷運行天宮站旁),機房於台北市內湖區。
需求:熟悉 UNIX-like 系統,Script (Perl, Python 或 shell script 之一) 撰寫。熟 Cisco 網路設備操作者佳。
薪資:約 40k/month,其他技能面議另談。

有意者請聯絡 techjob@pixnet.tw