Yandex 對以下資料庫的貢獻將受到審查。
- 點擊之家
- 奧德賽
- 恢復到某個時間點 (WAL-G)
- PostgreSQL（包括 logerrors、Amcheck、heapcheck）
- 綠梅
視頻：
你好世界！ 我叫安德烈·鮑羅丁。 我在 Yandex.Cloud 所做的工作是為了 Yandex.Cloud 和 Yandex.Cloud 客戶的利益開發開放關係資料庫。
在本次演講中，我們將討論大規模開放資料庫面臨的挑戰。 為什麼它如此重要？ 因為很小很小的問題，就像蚊子一樣，然後就會變成大象。 當你有很多集群時它們就會變大。
但這不是主要的事情。 不可思議的事情發生了。 百萬分之一的情況下發生的事。 在雲端環境中，您必須為此做好準備，因為當某些事物大規模存在時，令人難以置信的事情就變得很有可能發生。
但！ 開放資料庫有什麼好處？ 事實上，理論上你有機會處理任何問題。 你有原始碼，你有程式設計知識。 我們把它結合起來，它就起作用了。
開發開源軟體有哪些方法？
- 最直接的方法是使用軟體。 如果您使用協議，如果您使用標準，如果您使用格式，如果您在開源軟體中編寫查詢，那麼您已經支援它。
- 你正在使其生態系統變得更大。 您可以提高早期發現錯誤的可能性。 您可以提高該系統的可靠性。 您可以增加市場上開發人員的可用性。 你改進這個軟體。 如果你只是做出了風格並在那裡修改了一些東西，那麼你已經是一個貢獻者了。
- 另一個可以理解的方法是贊助開源軟體。 例如，著名的Google程式設計之夏計劃，Google向來自世界各地的大量學生支付了可以理解的資金，以便他們開發滿足某些許可要求的開放軟體專案。
- 這是一種非常有趣的方法，因為它允許軟體在不將焦點從社區轉移的情況下不斷發展。 谷歌作為科技巨頭，並沒有說我們想要這個功能，我們想要修復這個bug，這就是我們需要挖掘的地方。 谷歌說：「做你該做的事。 只要繼續按照你一直以來的方式工作，一切都會好起來的。”
- 參與開源的下一個方法是參與。 當你在開源軟體中遇到問題並且有開發人員時，你的開發人員就開始解決問題。 它們開始使您的基礎設施更加高效，您的程式更快、更可靠。
開源軟體領域中最著名的 Yandex 專案之一是 ClickHouse。 這是一個資料庫，是為了應對 Yandex.Metrica 面臨的挑戰而誕生的。
作為一個資料庫，它是開源的，目的是創建一個生態系統並與其他開發人員（不僅在 Yandex 內部）一起開發。 現在這是一個大項目，許多不同的公司都參與其中。
在 Yandex.Cloud 中，我們在 Yandex 物件儲存（即雲端儲存之上）創建了 ClickHouse。
為什麼這在雲端很重要？ 因為任何資料庫都在這個三角形、這個金字塔、這個記憶體類型的層次結構中運作。 你有快速但小寄存器和便宜的大但慢的 SSD、硬碟和一些其他區塊設備。 如果您在金字塔頂端的效率很高，那麼您就擁有一個快速的資料庫。 如果您在金字塔底部的效率很高，那麼您就擁有了一個可擴展的資料庫。 在這方面，從下面添加另一層是提高資料庫可擴展性的邏輯方法。
怎麼可能呢？ 這是本報告的一個重要觀點。
- 我們可以透過 MDS 實現 ClickHouse。 MDS 是 Yandex 內部雲端儲存介面。 它比常見的S3協定更複雜，但更適合區塊設備。 更適合記錄數據。 它需要更多的程式設計。 程式設計師會編程，這還不錯，還很有趣。
- S3 是一種更常見的方法，它使介面更簡單，但代價是對某些類型的工作負載的適應較少。
當然，為了向整個 ClickHouse 生態系統提供功能並完成 Yandex.Cloud 內部所需的任務，我們決定確保整個 ClickHouse 社群都能從中受益。 我們透過 S3 實現了 ClickHouse，而不是透過 MDS 實現了 ClickHouse。 這是一項繁重的工作。
引用：
“檔案系統抽象層”
“AWS SDK S3 整合”
“S3 的 IDisk 介面的基本實作”
“日誌儲存引擎與 IDisk 介面的整合”
“對 S3 和 SeekableReadBuffer 的日誌引擎支援”
“儲存條帶日誌 S3 支援”
“Storage MergeTree 對 S3 的初步支持”
“MergeTree 完全支援 S3”
“支援 S3 上的 ReplicatedMergeTree”
“為 s3 儲存新增預設憑證和自訂標頭”
“具有動態代理配置的 S3”
“帶有代理解析器的 S3”
這是一個用於在 ClickHouse 中實作虛擬檔案系統的拉取請求清單。 這是大量的拉取請求。
引用：
《DiskS3硬連結優化實現》
“S3 HTTP 用戶端 — 避免將回應流複製到記憶體中”
「避免將整個回應流複製到 S3 HTTP 記憶體中
客戶”
“能夠為 S3 磁碟快取標記和索引檔案”
“並行地將部分從 DiskLocal 移動到 DiskS3”
但工作並沒有就此結束。 該功能完成後，還需要做一些工作來優化該功能。
引用：
“新增 SelectedRows 和 SelectedBytes 事件”
“將 S3 請求中的分析事件新增至 system.events”
“新增 QueryTimeMicroSeconds、SelectQueryTimeMicroSeconds 和 InsertQueryTimeMicroSeconds”
然後有必要使其可診斷、設定監控並使其易於管理。
而這一切都是為了讓整個社區、整個ClickHouse生態系統都收到這項工作的成果。
讓我們繼續討論事務資料庫、OLTP 資料庫，這些資料庫與我個人更接近。
這是開源DBMS 開發部門。 這些人正在施展街頭魔法來改進事務性開放資料庫。
其中一個項目是 Postgres 中的連接池，我們可以透過一個範例來討論我們的工作方式和內容。
Postgres 是一個行程資料庫。 這意味著資料庫應該具有盡可能少的處理事務的網路連線。
另一方面，在雲端環境中，典型的情況是一千個連接同時到達一個叢集。 而連接池器的任務就是將一千個連線打包成少量的伺服器連線。
我們可以說連接池程式是重新排列位元組以便它們有效地到達資料庫的電話接線員。
不幸的是，連接池沒有一個好的俄語單字。 有時它被稱為多路復用器連接。 如果您知道如何稱呼連接池，那麼請務必告訴我，我將非常樂意說正確的俄語技術語言。
我們研究了適合託管 postgres 叢集的連接池。 PgBouncer 是我們的最佳選擇。 但我們在使用 PgBouncer 時遇到了一些問題。 許多年前，Volodya Borodin 報告說我們使用 PgBouncer，我們喜歡一切，但也有細微差別，還有一些需要改進的地方。
我們工作了。 我們解決了遇到的問題，修補了 Bouncer，並嘗試將拉取請求推送到上游。 但基本的單線程很難使用。
我們必須從打過補丁的保鑣中收集級聯。 當我們有很多單執行緒 Bouncer 時，頂層的連線會轉移到 Bouncer 的內層。 這是一個管理不善的系統，難以建構和擴展。
我們得出的結論是，我們創建了自己的連接池，稱為 Odyssey。 我們從頭開始寫它。
2019 年，在 PgCon 會議上，我向開發者社群展示了這個池化器。 現在我們在 GitHub 上的 star 數字已經不到 2 了，也就是說這個計畫還活著，這個計畫很受歡迎。
如果您在 Yandex.Cloud 中建立 Postgres 集群，那麼它將是一個內建 Odyssey 的集群，在來回擴展集群時會重新配置。
我們從這個計畫中學到了什麼？ 啟動競爭項目始終是一種激進的步驟，當我們說有些問題沒有得到足夠快的解決，沒有在適合我們的時間間隔內得到解決時，這是一種極端的措施。 但這是一個有效的措施。
PgBouncer 開始發展得更快。
現在其他項目也出現了。 例如，pgagroal，它是由 Red Hat 開發人員開發的。 他們追求相似的目標並實現相似的想法，但是，當然，他們有自己的具體細節，更接近 pgagroal 開發人員。
與 postgres 社群合作的另一個案例是恢復到某個時間點。 這是故障後的恢復，這是從備份中恢復。
備份有很多，而且都不同。 幾乎每個 Postgres 供應商都有自己的備份解決方案。
如果你拿所有的備份系統，創建一個特徵矩陣，並開玩笑地計算這個矩陣中的行列式，它將為零。 這是什麼意思？ 如果您取得特定的備份文件，那麼它無法由所有其他文件的片段組合而成，該怎麼辦？ 它的實施是獨特的，其目的是獨特的，其所蘊含的想法是獨特的。 而且它們都是具體的。
當我們致力於解決這個問題時，CitusData 啟動了 WAL-G 專案。 這是一個著眼於雲端環境而設計的備份系統。 現在 CitusData 已經成為 Microsoft 的一部分。 在那一刻，我們真的很喜歡 WAL-G 最初版本中提出的想法。 我們開始為這個專案做出貢獻。
現在這個專案有幾十個開發者，但 WAL-G 的前 10 名貢獻者包括 6 個 Yandexoid。 我們在那裡帶來了很多想法。 當然，我們自己實現它們，自己測試它們，自己將它們投入生產，我們自己使用它們，我們自己弄清楚下一步該往哪裡走，同時與大型 WAL-G 社區互動。
從我們的角度來看，現在這個備份系統，包括考慮到我們的努力，已經成為雲端環境的最佳選擇。 這是在雲端備份 Postgres 的最佳成本。
這是什麼意思？ 我們正在推廣一個相當大的想法：備份應該安全、操作成本低且恢復速度盡可能快。
為什麼營運成本應該便宜？ 當沒有任何損壞時，您不應該知道自己有備份。 一切運作正常，浪費盡可能少的 CPU，使用盡可能少的磁碟資源，並向網路發送盡可能少的字節，以免干擾有價值服務的有效負載。
當一切都崩潰時，例如，管理員刪除了數據，出了問題，你迫切需要回到過去，你用所有的錢來恢復，因為你希望你的數據快速完整地恢復。
我們推廣了這個簡單的想法。 而且，在我們看來，我們成功地實現了它。
但這還不是全部。 我們還想要一件小事。 我們需要許多不同的資料庫。 並非我們所有的客戶都使用 Postgres。 有些人使用 MySQL、MongoDB。 在社區中，其他開發者也支持了 FoundationDB。 而且這個名單還在不斷擴大中。
社群喜歡資料庫在雲端中的託管環境中運行的想法。 而開發者維護他們的資料庫，可以透過我們的備份系統與Postgres一起統一備份。
我們從這個故事學到了什麼？ 作為開發部門，我們的產品不是程式碼行，不是語句，不是文件。 我們的產品不是拉取請求。 這些都是我們向社區傳達的想法。 這是技術專業知識和技術向雲端環境的發展。
有Postgres這樣的資料庫。 我最喜歡 Postgres 核心。 我花了很多時間與社區一起開發 Postgres 核心。
但這裡必須指出的是，Yandex.Cloud 內部安裝了託管資料庫。 很久以前，Yandex.Mail 就開始這麼做了。 現在導致託管 Postgres 的專業知識是在郵件想要遷移到 Postgres 時累積的。
郵件與雲端的要求非常相似。 它需要您能夠在數據的任何點實現意外的指數增長。 而且郵件已經承載了數億個郵箱，其中有大量用戶不斷發出許多請求。
這對於開發 Postgres 的團隊來說是一個相當嚴峻的挑戰。 當時，我們遇到的任何問題都會向社區報告。 這些問題得到了糾正，並且在某些地方被社區糾正了，甚至達到了對其他一些資料庫的付費支援甚至更好的程度。 也就是說，您可以向 PgSQL 駭客發送一封信，並在 40 分鐘內收到回覆。 某些資料庫中的付費支援可能會認為有比您的錯誤更優先的事情。
現在 Postgres 的內部安裝有一些 PB 的資料。 每秒有數百萬個請求。 這是數千個集群。 規模非常大。
但有一個細微差別。 它並不依賴精美的網路驅動器，而是依賴相當簡單的硬體。 並且有專門針對有趣的新事物的測試環境。
在測試環境中的某個時刻，我們收到一則訊息，表示資料庫索引的內部不變量被違反。
不變量是我們期望始終保持的某種關係。
對我們來說，情況非常危急。 這表示某些資料可能已遺失。 資料遺失絕對是災難性的。
我們在託管資料庫中遵循的總體想法是，即使付出努力，也很難丟失資料。 即使你故意刪除它們，你仍然需要在很長一段時間內忽略它們的缺失。 資料安全是我們孜孜以求的信仰。
這裡出現的情況表明我們可能沒有做好準備。 我們開始為這種情況做準備。
我們做的第一件事就是掩埋這數千個群集的日誌。 我們發現哪些叢集所在的磁碟上存在有問題的固件，導致資料頁更新遺失。 標記了所有 Postgres 資料代碼。 我們用旨在偵測資料損壞的程式碼標記了那些表示違反內部不變量的訊息。
這個補丁實際上沒有經過太多討論就被社區接受了，因為在每個特定的情況下，很明顯發生了一些不好的事情並且需要報告到日誌中。
之後，我們就開始監控掃描日誌了。 如果有可疑訊息，他會叫醒值班人員，然後值班人員進行修復。
但！ 掃描日誌在一個叢集上是一項便宜的操作，但對於一千個叢集來說卻是災難性的昂貴操作。
我們寫了一個擴展名為 。 它創建了一個資料庫視圖，您可以在其中廉價且快速地選擇有關過去錯誤的統計資料。 如果我們需要喚醒值班人員，那麼我們無需掃描千兆位元組的文件，而是透過從雜湊表中提取幾個位元組來找出這一點。
例如，此擴充功能已在儲存庫中採用 。 如果你想使用它，你可以自己安裝。 當然它是開源的。
但這還不是全部。 我們開始使用 Amcheck（一個社群建構的擴充）來尋找索引中的不變違規。
我們發現，如果大規模操作，就會出現錯誤。 我們開始修復它們。 我們的更正已被接受。
我們發現此擴充無法分析 GiST 和 GIT 索引。 我們讓他們支持。 但社群仍在討論這種支持，因為這是一個相對較新的功能，並且有許多細節。
我們還發現，在檢查複製領導者、主伺服器上的索引是否違規時，一切正常，但在副本、追隨者上，搜尋損壞並不那麼有效。 並非所有不變量都會被檢查。 有一個不變量讓我們非常困擾。 為了啟用對副本的檢查，我們花了一年半的時間與社區溝通。
我們編寫的程式碼應該遵循所有可以...協議。 我們與來自 Crunchy Data 的 Peter Gaghan 討論了這個補丁很長一段時間。 他必須稍微修改 Postgres 中現有的 B 樹才能接受此補丁。 他被接受了。 現在檢查副本上的索引也變得足夠有效，可以檢測我們遇到的違規行為。 也就是說，這些違規可能是由磁碟韌體錯誤、Postgres 中的錯誤、Linux 核心中的錯誤以及硬體問題引起的。 我們正在準備的問題來源的清單相當廣泛。
但除了索引之外，還有堆這樣的部分，就是儲存資料的地方。 而且可以檢查的不變量並不多。
我們有一個名為 Heapcheck 的擴充功能。 我們開始開發它。 同時，EnterpriseDB公司也和我們一起開始寫一個模組，他們以同樣的方式稱之為Heapcheck。 只是我們稱之為 PgHeapcheck，而他們只是稱之為 Heapcheck。 他們的功能相似，簽名略有不同，但想法相同。 他們在某些地方實施得更好一些。 他們之前將其發佈在開源中。
而現在我們正在發展他們的擴張，因為這不再是他們的擴張，而是社區的擴張。 並且在未來，這是核心的一部分，將提供給大家，以便他們可以提前了解未來的問題。
在一些地方，我們甚至得出結論，我們的監控系統有誤報。 例如1C系統。 使用資料庫時，Postgres有時會向其中寫入它可以讀取的數據，但pg_dump無法讀取。
對於我們的問題檢測系統來說，這種情況看起來像是腐敗。 值班人員被吵醒了。 值班人員看著發生了什麼事。 過了一段時間，有個客戶過來告訴我有問題。 服務生解釋了問題所在。 但問題出在 Postgres 核心。
我找到了關於此功能的討論。 他寫道，我們遇到了這個功能，這令人不愉快，一個人在晚上醒來才能弄清楚它是什麼。
社區回應道：“哦，我們真的需要解決這個問題。”
我有一個簡單的比喻。 如果你穿著裡面有沙粒的鞋子走路，那麼原則上你可以繼續前進——沒問題。 如果你把靴子賣給成千上萬的人，那麼我們就製作完全不用沙子的靴子。 如果你的鞋子的用戶要跑馬拉松，那麼你想要製造非常好的鞋子，然後將其擴展到所有用戶。 而這樣的意外用戶總是在雲端環境。 總有使用者以某種原始的方式利用叢集。 你必須時時為此做好準備。
我們在這裡學到了什麼？ 我們學到了一件簡單的事：最重要的是向社區解釋有問題。 如果社區已經認識到這個問題，那麼就會出現解決問題的自然競爭。 因為每個人都想解決一個重要的問題。 所有廠商、所有駭客都明白，他們自己也能踩到這個耙子，所以他們想要消滅他們。
如果你正在解決一個問題，但除了你之外沒有人困擾，但你係統地解決它並且最終被認為是一個問題，那麼你的拉取請求肯定會被接受。 您的補丁將被接受，您的改進甚至改進請求將由社群審核。 最終，我們讓資料庫對彼此來說變得更好。
Greenplum 是一個有趣的資料庫。 它是一個基於Postgres程式碼庫的高度並行資料庫，我非常熟悉。
Greenplum 有有趣的功能 - 附加優化表。 您可以快速新增這些表。 它們可以是柱狀或行狀。
但是沒有集群，即沒有可以根據索引之一中的順序排列表中資料的功能。
計程車上的人走過來對我說：「Andrey，你知道 Postgres。 這裡幾乎是一樣的。 切換到20分鐘。 你接受它並去做。” 我想是的，我知道 Postgres，切換 20 分鐘 - 我需要這樣做。
但不，這不是 20 分鐘，而是我花了幾個月的時間寫的。 在 PgConf.Russia 會議上，我聯繫 Pivotal 的 Heikki Linakangas 並問道：「這有問題嗎？ 為什麼沒有追加優化的表集群？” 他說：「你獲取數據。 你排序，你重新排列。 這只是一份工作。” 我：“哦，是的，你只需要接受並去做就可以了。” 他說：“是的，我們需要騰出雙手來做這件事。” 我想我絕對需要這樣做。
幾個月後，我提交了一個實現此功能的拉取請求。 此拉取請求由 Pivotal 與社區一起審核。 當然，也有錯誤。
但最有趣的是，當這個 pull request 被合併時，Greenplum 本身就發現了 bug。 我們發現堆表在叢集時有時會破壞事務性。 這是一個需要解決的問題。 而她就在我剛才碰過的地方。 我的自然反應是——好吧，讓我也這樣做吧。
我修復了這個錯誤。 向修復者發送了拉取請求。 他被殺了。
後來發現這個功能需要在 PostgreSQL 12 的 Greenplum 版本中取得。也就是說，20 分鐘的冒險繼續著新的有趣的冒險。 接觸當前的開發是很有趣的，社區正在削減新的和最重要的功能。 它被凍結了。
但事情並沒有就此結束。 畢竟，我們需要為這一切編寫文件。
我開始寫文檔。 幸運的是，Pivotal 的紀錄片製片人出現了。 英語是他們的母語。 他們幫我處理文件。 事實上，他們自己將我的建議改寫成真正的英語了。
到這裡，冒險似乎就結束了。 你知道當時發生了什麼事嗎？ 出租車上的人過來對我說：“還有兩次冒險，每次10分鐘。” 我該告訴他們什麼？ 我說現在我會做一個規模報告，然後我們會看到你的冒險經歷，因為這是一項有趣的工作。
我們從這個案例中學到了什麼？ 因為與開源合作總是與特定的人合作，所以總是與社群合作。 因為在每個階段我都會與一些開發人員、一些測試人員、一些駭客、一些紀錄片製作人、一些架構師一起工作。 我沒有與 Greenplum 合作，我與 Greenplum 周圍的人一起工作。
但！ 還有一點很重要——這只是工作。 也就是說，你來，喝咖啡，寫程式。 各種簡單的不變量都有效。 正常地做－會沒事的！ 這是一項非常有趣的工作。 Yandex.Cloud 客戶（Yandex 內部和外部的叢集使用者）提出了這項工作的請求。 而且我認為我們參與的計畫數量將會增加，參與的深度也會增加。
就這樣。 讓我們繼續討論問題。
提問環節
你好！ 我們還有另一個問答環節。 在安德烈·鮑羅丁工作室。 這是剛才跟大家介紹Yandex.Cloud和Yandex對開源的貢獻的人。 我們現在的報告並不完全是關於雲端的，但同時我們也是基於這樣的技術。 如果沒有您在 Yandex 中所做的事情，Yandex.Cloud 中就不會有服務，所以我個人感謝您。 廣播中的第一個問題是：“你提到的每個項目都寫了什麼？”
WAL-G中的備份系統是用Go寫的。 這是我們開展的較新項目之一。 他其實只有3歲。 資料庫通常與可靠性有關。 這意味著這些資料庫相當古老，通常是用 C 語言編寫的。 Postgres 專案大約開始於 30 年前。 那麼C89就是正確的選擇。 上面寫著Postgres。 較現代的資料庫（例如 ClickHouse）通常是用 C++ 編寫的。 所有系統開發均基於 C 和 C++。
我們負責 Cloud 費用的財務經理提出了一個問題：“為什麼 Cloud 花錢支持開源？”
這裡給財務經理一個簡單的答案。 我們這樣做是為了讓我們的服務變得更好。 我們可以在哪些方面做得更好？ 我們可以更有效率、更快地做事，並使事情更具可擴展性。 但對我們來說，這個故事主要是關於可靠性。 例如，在備份系統中，我們會 100% 審查適用於該系統的修補程式。 我們知道代碼是什麼。 我們更願意將新版本投入生產。 也就是說，首先是關於信心、關於發展準備和關於可靠性
另一個問題：“居住在 Yandex.Cloud 中的外部用戶的要求與居住在內部雲端的內部用戶的要求是否不同？”
當然，負載曲線是不同的。 但從我的部門的角度來看，所有特殊和有趣的案例都是在非標準負載上創建的。 具有想像力的開發人員、做出意想不到的開發人員，在內部和外部都可能被發現。 在這一點上，我們都是大致相同的。 而且，Yandex 資料庫操作中唯一重要的功能可能是在 Yandex 內部我們有一個教學。 在某些時候，某些可用區域完全進入陰影狀態，儘管如此，所有 Yandex 服務都必須以某種方式繼續運作。 這是一個很小的差異。 但它在資料庫和網路堆疊的介面方面創造了大量的研究開發。 否則，外部和內部安裝會產生相同的功能請求以及類似的提高可靠性和效能的請求。
下一個問題：“您個人對您所做的大部分內容被其他雲端使用這一事實有何看法？” 我們不會透露特定的名稱，但許多在 Yandex.Cloud 中完成的項目都在其他人的雲端中使用。
這很酷。 首先，這表示我們做了正確的事。 它會傷害自我。 我們更加確信我們做了正確的決定。 另一方面，這是希望未來這會為我們帶來新的想法，來自第三方用戶的新要求。 GitHub 上的大多數問題都是由個體系統管理員、個體DBA、個體架構師、個體工程師創建的，但有時有系統經驗的人會說，在30% 的某些情況下我們會遇到這個問題，讓我們考慮一下如何解決它。 這是我們最期待的。 我們期待與其他雲端平台分享經驗。
你談了很多關於馬拉鬆的事情。 我知道你在莫斯科跑過馬拉松。 因此？ 超越了 PostgreSQL 的傢伙？
不，奧列格·巴圖諾夫跑得很快。 他比我早一個小時完成。 總的來說，我對自己所取得的進展感到滿意。 對我來說，完成任務就是一項成就。 總的來說，postgres 社群中有如此多的跑者是令人驚訝的。 在我看來，有氧運動和對系統程式設計的渴望之間存在著某種關係。
你是說ClickHouse沒有跑者嗎？
我確信他們就在那裡。 ClickHouse也是一個資料庫。 順便說一句，奧列格現在給我寫信：“我們聽完報告後去跑步嗎？” 這是一個好主意。
Nikita 廣播中的另一個問題：“為什麼你自己修復了 Greenplum 中的 bug，而不把它交給後輩？” 確實，目前還不清楚該錯誤是什麼以及在哪個服務中，但它可能意味著您談到的那個錯誤。
是的，原則上，它可以給某人。 這只是我剛剛更改的程式碼。 很自然地立即繼續這樣做。 原則上，與團隊分享專業知識的想法是一個好主意。 我們一定會在我們部門的所有成員之間分擔 Greenplum 任務。
既然我們談論的是青少年，那麼這裡有一個問題。 該人決定在 Postgres 中建立第一個提交。 他需要做什麼才能進行第一次提交？
這是一個有趣的問題：“從哪裡開始？” 從核心中的某些東西開始通常是相當困難的。 例如，在 Postgres 中，有一個待辦事項清單。 但事實上，這就是他們試圖做的事情，但沒有成功。 這些都是複雜的事情。 通常你可以在生態系統中找到一些實用程序，一些可以改進的擴展，但很少受到核心開發人員的關注。 因此，那裡還有更多的成長點。 在 Google 代碼之夏計畫中，postgres 社群每年都會提出許多可以解決的不同主題。 我想今年我們有三個學生。 有人甚至在 WAL-G 上撰寫了對 Yandex 來說很重要的主題。 在 Greenplum 中，一切都比在 Postgres 社群中更簡單，因為 Greenplum 駭客很好地對待拉取請求並立即開始審查。 向 Postgres 發送補丁需要幾個月的時間，但 Greenplum 會在一天內過來看看你做了什麼。 另外一點就是Greenplum需要解決目前的問題。 Greenplum 的使用並不廣泛，所以找到你的問題是相當困難的。 當然，首先我們需要解決問題。
來源： www.habr.com