GitHub 自己開發的搜尋引擎

前陣子 GitHub 發了一篇文章,說明自己開發搜尋引擎的心路歷程:「The technology behind GitHub’s new code search」。

看了一下其實就是自己幹了一套 search engine cluster,然後針對 code search 把一些功能放進去。

目前這套 search enginer 還是 beta 版本,全站兩億個 repository 只包括了 4500 萬 (大概 22% 左右),然後已經有 115TB 的程式碼了;另外也題到了先前導入 Elasticsearch 時的數字是 800 萬個 repository:

GitHub’s scale is truly a unique challenge. When we first deployed Elasticsearch, it took months to index all of the code on GitHub (about 8 million repositories at the time). Today, that number is north of 200 million, and that code isn’t static: it’s constantly changing and that’s quite challenging for search engines to handle. For the beta, you can currently search almost 45 million repositories, representing 115 TB of code and 15.5 billion documents.

目前是 32 台機器,沒有特別提到記憶體大小,也沒有提到 replication 之類的數字:

Code search runs on 64 core, 32 machine clusters.

然後各種 inverted index 與各種資料在壓縮後只有 25TB:

There are some big wins on the size of the index as well. Remember that we started with 115 TB of content that we want to search. Content deduplication and delta indexing brings that down to around 28 TB of unique content. And the index itself clocks in at just 25 TB, which includes not only all the indices (including the ngrams), but also a compressed copy of all unique content. This means our total index size including the content is roughly a quarter the size of the original data!

換算一下,就會發現現在已經是「暴力」可以解很多事情的年代了,而這已經是全世界最大的 code hosting。

以前隨便一個主題搞大一點就會撞到 Amdahl's law,現在輕鬆不少...

Elasticsearch 的 Python 套件開始阻擋 OpenSearch 的伺服器了

Hacker News Daily 上看到的:「Official Elasticsearch Python library no longer works with open-source forks (github.com/elastic)」,連結所指向的是 GitHub 上的 pull request,在「Verify connection to Elasticsearch #1623」這邊。

講白了也就是 Elasticsearch 官方的 Python client 開始阻擋 AWS 主推的 OpenSearch

另外 AWS 這邊也出手,把本來的 client 都 fork 出來:「Keeping clients of OpenSearch and Elasticsearch compatible with open source」,這場戰爭還有得打...

AWS 對 Elasticsearch 的戰爭:OpenSearch

AWSElasticsearch 的戰爭繼續升溫,AWS 出來喊,搞了自己的 community 要跟本家 PK:「Introducing OpenSearch」,衍生出來的兩套軟體分別是 OpenSearch (對應 Elasticsearch) 與 OpenSearch Dashboards (對應 Kibana)。

Hacker News 上的討論「OpenSearch: AWS fork of Elasticsearch and Kibana (amazon.com)」裡面有些討論還蠻精彩的,其中這段:

One thing which surprised me: Elastic has a market capitalization of ~$11B.

I think that changes some of the more floaty ethical concerns. This is not a David vs Goliath situation. This is Goliath vs Super-Goliath.

雖然就公司市值比例來看,大約是 100:1 這個數量級的公司在打架 (AWS 的母單位 Amazon 大約在 USD$1T 的等級),但這其實這不是小蝦米被大鯨魚欺負的故事,而是大公司跟暴力超大公司之間的打架。

會怎麼演變其實猜不出來,但因為在 open source search engine 技術這塊的確缺乏其他像樣的競爭者,AWS 這樣丟資源進來未必是件壞事。

另外一方面,這件事情對商業公司在在 open source 的其他領域則是比較負面,很明顯的 Amazon 這樣玩對於其他以 open source 為基礎的商業公司處境就更嚴峻了。

AWS 跳出來決定繼續搞 Elasticsearch 了

先前提到「Elasticsearch 與 Kibana 也變成非 Open Source 軟體」,後來 Elastic 的 CEO (創辦人) 發了一篇「Amazon: NOT OK - why we had to change Elastic licensing」直接批評 AWS

接下來是 AWS 跳出來放話了,基本上也是個新聞稿:「Stepping up for a truly open source Elasticsearch」,大概就是會繼續維護自己的版本,維持本來的 Apache License, Version 2.0,然後批評 Elastic 所說的話不實之類的...

現在還在雙方放話的階段,過一陣子看看有什麼更新...

Elasticsearch 與 Kibana 也變成非 Open Source 軟體

Nuzzel 上看到的消息,ElasticsearchKibana 也變成非 Open Source 軟體了:「Elasticsearch and Kibana are now business risks」,官方的公告在「Upcoming licensing changes to Elasticsearch and Kibana」這邊。

新版將會採用 SSPL (由 MongoDB 設計出來的授權) 與 Elastic License (Elastic 的商用授權) 的雙重授權,不過兩個授權都不是 Open Source 授權。

應該是跟 Amazon Elasticsearch Service 這種搞法加減有些關係?不知道 AWS 這邊後續會怎麼弄...

另外如果不選擇 Elasticsearch 的話,目前好像只有 Solr 算是堪用?不過很久沒回去看 Solr,不知道現在軟體發展到什麼程度...

Amazon Elasticsearch Service 可以利用 S3 當作二級儲存空間了

Amazon Elasticsearch Service 的新功能,使用 Amazon S3 當作第二級儲存空間 (UltraWarm):「Announcing UltraWarm (Preview) for Amazon Elasticsearch Service」。

UltraWarm 需要不同的機器 (跑不同版本?),機器的規格 (vCPU 與記憶體的比率) 接近 Memory Optimized 的版本,但是貴了不少,所以需要夠大的資料量才會打平回來...

us-east-1 來看,SSD EBS 的空間成本就是 USD$0.135/GB,而傳統磁性硬碟是 USD$0.067/GB (不知道收不收 I/O 費用?),但 storage 的價錢是 USD$0.024/GB。這邊值得一提的是 Amazon S3 是 USD$0.023/GB,看起來是直接包括了 API 的呼叫費用?

Amazon 的 Elasticsearch 服務提供十四天免費 hourly snapshot

Amazon Elasticsearch Service 提供 14 天免費的 hourly snapshot:「Amazon Elasticsearch Service increases data protection with automated hourly snapshots at no extra charge」。

Amazon Elasticsearch Service has increased its snapshot frequency from daily to hourly, providing more granular recovery points. If you need to restore your cluster, you now have numerous, recent snapshots to choose from. These automated snapshots are retained for 14 days at no extra charge.

不過這是 5.3+ 版本才有,舊版只有 daily:

  • For domains running Elasticsearch 5.3 and later, Amazon ES takes hourly automated snapshots and retains up to 336 of them for 14 days.
  • For domains running Elasticsearch 5.1 and earlier, Amazon ES takes daily automated snapshots (during the hour you specify) and retains up to 14 of them for 30 days.

In both cases, the service stores the snapshots in a preconfigured Amazon S3 bucket at no additional charge. You can use these automated snapshots to restore domains.

算是方便管理...

Elasticsearch 提供免費版本的安全功能

Elasticsearch 決定將基本的安全功能從付費功能轉為免費釋出,很明顯的是受到 Open Distro for Elasticsearch 的壓力而做出的改變:「Security for Elasticsearch is now free」。

要注意的是這不是 open source 版本,只是將這些功能放到 basic tier 裡讓使用者免費使用:

Previously, these core security features required a paid Gold subscription. Now they are free as a part of the Basic tier. Note that our advanced security features — from single sign-on and Active Directory/LDAP authentication to field- and document-level security — remain paid features.

這代表 Open Distro for Elasticsearch 提供的還是比較多:

With Open Distro for Elasticsearch, you can leverage your existing authentication infrastructure such as LDAP/Active Directory, SAML, Kerberos, JSON web tokens, TLS certificates, and Proxy authentication/SSO for user authentication. An internal user repository with support for basic HTTP authentication is also avaliable for easy setup and evaluation.

Granular, role-based access control enables you to control the actions a user can perform on your Elasticsearch cluster. Roles control cluster operations, access to indices, and even the fields and documents users can access. Open Distro for Elasticsearch also supports multi-tenant environments, allowing multiple teams to share the same cluster while only being able to access their team's data and dashboards.

目前看起來還是可以朝 Open Distro for Elasticsearch 靠過去...

改 Open Distro for Elasticsearch 預設密碼的方式

AWS 弄出來的 Open Distro for Elasticsearch 因為內建了安全性的功能 (參考「AWS 對 Elastic Stack 實作免費的開源版本 Open Distro for Elasticsearch」),應該是目前新架設 Elasticsearch 的首選。

不過裝好後預設有五個帳號,但從 Open Distro 的 Kibana 介面無法修改改其中兩個使用者的密碼 (adminkibanaserver),要修改密碼發現得花不少功夫,不知道為什麼要這樣設計 :/

這邊講的是透過 RPM (以及 deb) 的方式的修改方式,如果是 Docker 的方式請參考後面提到在 AWS blog 上的文章:「Change your Admin Passwords in Open Distro for Elasticsearch」。

首先先透過 hash.sh 產生 bcrypt 的 hash,像是這樣 (輸入 password 當密碼):

bash /usr/share/elasticsearch/plugins/opendistro_security/tools/hash.sh
WARNING: JAVA_HOME not set, will use /usr/bin/java
[Password:]
$2y$12$QchkpgY8y/.0TL7wruWq4egBDrlpIaURiBYKoZD50G/twdylgwuhG

然後修改 /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml 檔案裡面的值,順便改掉 readonly 的部分。

接下來是把這個 internal_users.yml 檔案的設定更新到 Elasticsearch 裡。由於這邊需要讀 /etc/elasticsearch/ 的東西,所以偷懶用 root 跑:

sudo bash /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -cd ../securityconfig/ -icl -nhnv -cacert /etc/elasticsearch/root-ca.pem -cert /etc/elasticsearch/kirk.pem -key /etc/elasticsearch/kirk-key.pem

做完後可能要重跑 Elasticsearch 與 Kibana:

sudo service elasticsearch restart
sudo service kibana restart

或是重開機... 順便測試看看重開後有沒有生效。理論上修改完成後,就是用新的帳號密碼連到 Kibana。

上面的方法是參考了「Default Password Reset」(先找到這篇) 與「change admin password」(後來在 AWS blog 的文章上發現的 GitHub issue 連結) 這邊的資訊。

官方的說明文件則是在寫這篇文章時才找到的,平常搜尋時不太會出現:「Apply configuration changes」。

Open Distro for Elasticsearch 的比較

先前提到的「AWS 對 Elastic Stack 實作免費的開源版本 Open Distro for Elasticsearch」,在「Open Distro for Elasticsearch Review」這邊有整理了一份重點:

可以看到主要重點都在安全性那塊...