後端開發人員如何理解 SQL 查詢將在“產品”上運行良好？ 在大型或快速發展的公司中，並非每個人都可以使用“產品”。 通過訪問，並非所有請求都可以輕鬆檢查，創建數據庫副本通常需要數小時。 為了解決這些問題，我們創造了一個人工DBA——Joe。 目前已經在多家公司成功落地，幫助了十幾家開發者。
視頻：
大家好！ 我的名字是阿納托利·斯坦斯勒。 我在一家公司工作 . 我們致力於通過消除開發人員、DBA 和 QA 與 Postgres 工作相關的延遲來加快開發過程。
我們有很棒的客戶，今天報告的一部分將專門介紹我們在與他們合作時遇到的案例。 我將談談我們如何幫助他們解決相當嚴重的問題。
當我們在開發和進行複雜的高負載遷移時，我們會問自己一個問題：“這個遷移會成功嗎？”。 我們使用審查，我們使用更有經驗的同事、DBA 專家的知識。 他們可以說它是否會飛。
但如果我們可以在全尺寸副本上自己測試它，也許會更好。 今天我們將討論現在有哪些測試方法以及如何更好地完成測試以及使用哪些工具。 我們還將討論這些方法的優缺點，以及我們可以在這裡解決的問題。
有誰直接在prod上做過索引或者做過改動？ 相當的。 這對誰造成了數據丟失或停機？ 然後你知道這種痛苦。 感謝上帝，還有備份。
第一種方法是在產品中進行測試。 或者，當開發人員坐在本地機器上時，他有測試數據，有某種有限的選擇。 我們推出產品，我們得到了這種情況。
很痛，很貴。 最好不要這樣做。
最好的方法是什麼？
讓我們進行分期並在那裡選擇產品的某些部分。 或者充其量，讓我們採用真正的產品，所有數據。 在本地開發完成後，我們將額外檢查階段性。
這將使我們能夠消除一些錯誤，即防止它們出現在產品中。
有什麼問題？
- 問題是我們與同事分享這個階段。 而且經常發生的情況是您進行了某種更改，bam-沒有數據，工作就付諸東流了。 分段是數 TB。 而且你必須等待很長時間才能再次上升。 我們決定明天完成它。 就是這樣，我們有了發展。
- 當然，我們有很多同事在那里工作，有很多團隊。 而且必須手動完成。 這很不方便。
值得一提的是，如果我們想對數據庫進行一些更改，接觸數據，更改結構，我們只有一次嘗試，一次機會。 如果出現問題，如果遷移中出現錯誤，那麼我們將不會快速回滾。
這比以前的方法要好，但仍然很有可能在生產中出現某種錯誤。
是什麼阻止我們給每個開發人員一個測試台，一個全尺寸的副本？ 我認為很明顯是什麼阻礙了我們。
誰擁有超過 TB 的數據庫？ 超過一半的房間。
很明顯，當生產量如此之大時，為每個開發人員保留機器是非常昂貴的，而且還需要很長時間。
我們的客戶已經意識到在全尺寸副本上測試所有更改非常重要，但他們的數據庫不到 XNUMX TB，而且沒有資源為每個開發人員保留一個測試台。 因此，他們必須將轉儲本地下載到他們的機器上並以這種方式進行測試。 這需要很多時間。
即使你在基礎設施內部做，那麼每小時下載 200 TB 的數據就已經很不錯了。 但他們使用邏輯轉儲，他們從雲端下載到本地。 對於他們來說，速度大約是每小時 XNUMX GB。 從邏輯轉儲轉儲、匯總索引等仍然需要時間。
但他們使用這種方法是因為它可以讓他們保持產品的可靠性。
我們可以在這裡做什麼？ 讓我們讓測試台變得便宜，並為每個開發人員提供他們自己的測試台。
這是可能的。
在這種方法中，當我們為每個開發人員製作精簡克隆時，我們可以在一台機器上共享它。 例如，如果您有一個 10TB 的數據庫並想將它提供給 10 個開發人員，則您不需要擁有 XNUMX 個 XNUMXTB 的數據庫。 您只需要一台機器即可為使用一台機器的每個開發人員製作隔離的精簡副本。 稍後我會告訴你它是如何工作的。
真實例子：
-
數據庫 - 4,5 太字節。
-
我們可以在 30 秒內獲得獨立副本。
您不必等待試驗台並取決於它有多大。 你可以在幾秒鐘內得到它。 它將是完全隔離的環境，但它們之間共享數據。
這很棒。 在這裡，我們談論的是魔法和平行宇宙。
在我們的例子中，這可以使用 OpenZFS 系統。
OpenZFS 是一種寫時復製文件系統，支持開箱即用的快照和克隆。 它可靠且可擴展。 她很容易管理。 它實際上可以部署在兩個團隊中。
還有其他選擇：
-
LVM，
-
存儲（例如 Pure Storage）。
我所說的數據庫實驗室是模塊化的。 可以使用這些選項來實現。 但目前，我們專注於 OpenZFS，因為 LVM 存在一些問題。
怎麼運行的？ 我們不是每次更改數據都重寫數據，而是通過簡單地標記這個新數據來自一個新的時間點，一個新的快照來保存它。
並且在未來，當我們想要回滾或者我們想要從某個舊版本創建一個新的克隆時，我們只需說：“好的，給我們這些標記為這樣的數據塊。”
這個用戶將使用這樣的數據集。 他會逐漸改變它們，製作自己的快照。
我們將分支。 在我們的案例中，每個開發人員都將有機會擁有他自己編輯的克隆，並且共享的數據將在每個人之間共享。
要在家裡部署這樣的系統，需要解決兩個問題：
-
第一個是數據的來源，您將從哪裡獲取數據。 您可以設置生產複製。 我希望您已經可以使用您配置的備份。 WAL-E、WAL-G 或 Barman。 即使您正在使用某種雲解決方案，如 RDS 或 Cloud SQL，您也可以使用邏輯轉儲。 但我們仍然建議您使用備份，因為使用這種方法您還將保留文件的物理結構，這將使您能夠更接近您在生產中看到的指標，以便發現那些存在的問題。
-
第二個是您要舉辦數據庫實驗室的地方。 它可以是雲，也可以是內部部署。 這裡有一點很重要，ZFS 支持數據壓縮。 它做得很好。
想像一下，對於每個這樣的克隆，根據我們對基礎所做的操作，某種類型的開發將會增長。 為此，dev 也需要空間。 但由於我們以 4,5 TB 為基礎，ZFS 會將其壓縮為 3,5 TB。 這可能因設置而異。 而且我們還有開發空間。
這樣的系統可以用於不同的情況。
-
這些是用於查詢驗證和優化的開發人員、DBA。
-
這可以在 QA 測試中使用，以在我們將其推出到產品之前測試特定的遷移。 我們還可以使用真實數據為 QA 建立特殊環境，他們可以在其中測試新功能。 而且這將需要幾秒鐘而不是等待數小時，在其他一些不使用精簡副本的情況下可能需要數天。
-
還有一個案例。 如果公司沒有設置分析系統，那麼我們可以隔離產品庫的精簡克隆，並將其提供給可用於分析的長查詢或特殊索引。
使用這種方法：
-
“產品”出錯的可能性很低，因為我們測試了全尺寸數據的所有更改。
-
我們有一種測試文化，因為現在您不必為自己的展台等待數小時。
-
而且沒有障礙，測試之間沒有等待。 其實你可以去看看。 隨著我們加快發展，這種方式會更好。
-
重構會更少。 更少的錯誤最終會出現在產品中。 稍後我們將重構它們。
-
我們可以扭轉不可逆轉的變化。 這不是標準方法。
- 這是有益的，因為我們共享測試平台的資源。
已經很好了，但還有什麼可以加速的？
得益於這樣的系統，我們可以大大降低進入此類測試的門檻。
現在有一個惡性循環，開發人員必須成為專家才能訪問真正的全尺寸數據。 必須信任他有這樣的訪問權限。
但是如果沒有它如何成長。 但是，如果您只有非常少量的測試數據可用怎麼辦？ 那麼你將得不到任何真正的體驗。
如何跳出這個圈子？ 作為第一個界面，方便任何級別的開發人員，我們選擇了 Slack bot。 但它可以是任何其他接口。
它允許你做什麼？ 您可以進行特定查詢並將其發送到數據庫的特殊通道。 我們將在幾秒鐘內自動部署一個精簡克隆。 讓我們運行這個請求。 我們收集指標和建議。 讓我們展示一個可視化。 然後這個克隆將保留下來，以便可以以某種方式優化這個查詢，添加索引等。
Slack 也為我們提供了開箱即用的協作機會。 由於這只是一個渠道，您可以在此類請求的線程中開始討論此請求，聯繫您的同事，公司內部的 DBA。
但是，當然有問題。 因為這是真實世界，而且我們使用的是同時託管許多克隆的服務器，所以我們必須壓縮克隆可用的內存量和 CPU 能力。
但是要使這些測試合理，您需要以某種方式解決這個問題。
很明顯，重要的一點是相同的數據。 但我們已經擁有了。 而我們想要實現相同的配置。 而我們可以給出這樣一個幾乎一模一樣的配置。
擁有與生產中相同的硬件會很酷，但它可能會有所不同。
讓我們記住 Postgres 是如何使用內存的。 我們有兩個緩存。 一種來自文件系統，另一種來自本機 Postgres，即共享緩衝區緩存。
重要的是要注意共享緩衝區緩存是在 Postgres 啟動時分配的，具體取決於您在配置中指定的大小。
第二個緩存使用所有可用空間。
而當我們在一台機器上進行多次克隆時，事實證明我們逐漸填滿了內存。 從好的方面來說，共享緩衝區緩存佔機器上可用內存總量的 25%。
事實證明，如果我們不更改此參數，那麼我們將只能在一台機器上運行 4 個實例，即總共 4 個這些精簡克隆。 當然，這很糟糕，因為我們希望擁有更多。
但另一方面，Buffer Cache是用來執行索引查詢的，也就是說，這個計劃取決於我們的緩存有多大。 而如果我們只取這個參數並減少它，那麼我們的計劃就會有很大的改變。
例如，如果我們在 prod 上有一個很大的緩存，那麼 Postgres 會更喜歡使用索引。 如果沒有，那麼就會有 SeqScan。 如果我們的計劃不一致，那又有什麼意義呢？
但是這裡我們得出一個結論，其實Postgres中的plan並不依賴於plan中Shared Buffer中指定的具體大小，而是依賴於effective_cache_size。
Effective_cache_size 是我們可用的緩存的估計數量，即 Buffer Cache 和文件系統緩存的總和。 這是由配置設置的。 而且這個內存沒有分配。
由於這個參數，我們可以欺騙 Postgres，說我們實際上有很多可用數據，即使我們沒有這些數據。 因此，計劃將與生產完全吻合。
但這會影響時間。 我們通過時間優化查詢，但重要的是時間取決於許多因素：
-
這取決於當前生產的負載。
-
這取決於機器本身的特性。
這是一個間接參數，但實際上我們可以根據此查詢為獲得結果而讀取的數據量進行精確優化。
如果您希望時間接近我們將在產品中看到的時間，那麼我們需要採用最相似的硬件，甚至可能更多，以便所有克隆都適合。 但這是一個妥協，即你會得到相同的計劃，你會看到一個特定的查詢將讀取多少數據，你將能夠得出這個查詢是好（或遷移）還是壞的結論，它仍然需要優化.
我們來看看Joe具體是如何優化的。
讓我們接受來自真實係統的請求。 在本例中，數據庫為 1 TB。 我們想計算點贊次數超過 10 次的新帖子的數量。
我們正在向通道寫入消息，已為我們部署了一個克隆。 我們將看到這樣的請求將在 2,5 分鐘內完成。 這是我們注意到的第一件事。
B Joe 將根據計劃和指標向您展示自動推薦。
我們將看到查詢處理了太多數據以獲取相對較少的行數。 並且需要某種專門的索引，因為我們注意到查詢中過濾的行太多。
讓我們仔細看看發生了什麼。 事實上，我們看到我們已經從文件緩存甚至磁盤中讀取了將近 142 GB 的數據。 這並不好，因為我們只有 XNUMX 行。
而且，看起來，我們在這裡進行了索引掃描，應該很快就能完成，但是由於我們過濾掉了太多的行（我們不得不計算它們），查詢慢慢地完成了。
由於查詢中的條件和索引中的條件部分不匹配，因此計劃中發生了這種情況。
讓我們嘗試使索引更精確，然後看看查詢執行如何變化。
索引的創建花費了相當長的時間，但是現在我們查看查詢發現，時間不是 2,5 分鐘，而是 156 毫秒，已經足夠了。 而我們只讀取了 6 兆字節的數據。
而現在我們只使用索引掃描。
另一個重要的故事是我們希望以更易於理解的方式呈現該計劃。 我們已經使用火焰圖實現了可視化。
這是一個不同的要求，更加強烈。 我們根據兩個參數構建火焰圖：這是特定節點在計劃和時間中統計的數據量，即節點的執行時間。
在這裡，我們可以將特定節點相互比較。 並且它們中的哪一個花費更多或更少會很清楚，這在其他渲染方法中通常很難做到。
當然，每個人都知道 explain.depesz.com。 這種可視化的一個很好的特點是我們保存了文本計劃，並將一些基本參數放入表格中，以便我們進行排序。
尚未深入研究該主題的開發人員也使用 explain.depesz.com，因為他們更容易找出哪些指標重要，哪些不重要。
有一種新的可視化方法 - 這是 explain.dalibo.com。 他們做了一個樹可視化，但是很難將節點相互比較。 在這裡你可以很好地理解結構，但是，如果有一個大的請求，那麼你將需要來回滾動，而且還有一個選項。
合作
而且，正如我所說，Slack 為我們提供了合作的機會。 例如，如果我們遇到一個複雜的查詢，不清楚如何優化，我們可以在 Slack 的一個線程中與我們的同事澄清這個問題。
在我們看來，對全尺寸數據進行測試很重要。 為此，我們製作了更新數據庫實驗室工具，該工具以開源形式提供。 您也可以使用 Joe 機器人。 您可以立即接受並在您的位置實施。 所有指南都可以在那裡找到。
還需要注意的是，解決方案本身並不是革命性的，因為有Delphix，但它是一個企業解決方案。 它是完全封閉的，非常昂貴。 我們專門研究 Postgres。 這些都是開源產品。 加入我們！
這是我結束的地方。 謝謝你！
問題
你好！ 感謝您的報告！ 非常有趣，尤其是對我來說，因為我前段時間解決了同樣的問題。 所以我有很多問題。 希望我至少能得到其中的一部分。
我想知道你如何計算這個環境的地方？ 該技術意味著在某些情況下，您的克隆可以長到最大尺寸。 粗略地說，如果您有一個 10 TB 的數據庫和 10 個克隆，那麼很容易模擬每個克隆權衡 XNUMX 個唯一數據的情況。 你如何計算這個地方，也就是你所說的三角洲，這些克隆人將生活在那裡？
好問題。 在這裡跟踪特定的克隆很重要。 如果一個克隆有一些太大的變化，它開始增長，那麼我們可以首先向用戶發出警告，或者立即停止這個克隆，這樣我們就不會出現失敗的情況。
是的，我有一個嵌套問題。 也就是你如何保證這些模塊的生命週期？ 我們有這個問題和一個完全不同的故事。 這是怎麼發生的？
每個克隆都有一些 ttl。 基本上，我們有一個固定的 ttl。
什麼，如果不是秘密？
1 小時，即空閒 - 1 小時。 如果它沒有被使用，那麼我們就敲它。 但這並不奇怪，因為我們可以在幾秒鐘內培育出克隆體。 如果您再次需要它，請。
我對技術的選擇也很感興趣，因為，例如，我們出於某種原因並行使用多種方法。 為什麼選擇 ZFS？ 為什麼不使用 LVM？ 您提到 LVM 存在問題。 有什麼問題？ 在我看來，就性能而言，最佳選擇是存儲。
ZFS 的主要問題是什麼？ 您必須在同一台主機上運行的事實，即所有實例都將存在於同一操作系統中。 並且在存儲的情況下，可以連接不同的設備。 瓶頸只是存儲系統上的那些塊。 技術選擇的問題很有趣。 為什麼不是 LVM？
具體的，我們可以在meetup上討論LVM。 關於存儲 - 它只是昂貴。 我們可以在任何地方實施 ZFS 系統。 您可以將其部署在您的機器上。 您可以簡單地下載存儲庫並進行部署。 如果我們談論 Linux，則幾乎所有地方都安裝了 ZFS。 也就是說，我們得到了一個非常靈活的解決方案。 ZFS 本身提供了很多開箱即用的功能。 你可以上傳多少數據就多少，連接大量的磁盤，還有快照。 而且，正如我所說，它易於管理。 也就是說，使用起來似乎非常愉快。 他接受了考驗，他已經很多歲了。 他有一個正在成長的非常大的社區。 ZFS 是一個非常可靠的解決方案。
Nikolai Samokhvalov：我可以進一步評論嗎？ 我叫尼古拉，我們和阿納托利一起工作。 我同意存儲很棒。 我們的一些客戶有 Pure Storage 等。
Anatoly 正確地指出我們專注於模塊化。 並且在未來，您可以實現一個接口——拍攝快照、製作克隆、銷毀克隆。 一切都很容易。 如果是的話，存儲也很酷。
但是 ZFS 對每個人都可用。 DelPhix 已經夠用了，他們有 300 個客戶端。 其中，fortune 100有50個客戶，也就是針對NASA等，是時候讓大家掌握這個技術了。 這就是我們擁有開源核心的原因。 我們有一個不開源的接口部分。 這是我們將展示的平台。 但我們希望每個人都可以訪問它。 我們想進行一場革命，讓所有測試人員停止在筆記本電腦上猜測。 我們必須編寫 SELECT 並立即發現它很慢。 停止等待 DBA 告訴您這件事。 這是主要目標。 我認為我們都會做到這一點。 我們讓每個人都擁有這個東西。 因此 ZFS，因為它將隨處可用。 感謝社區解決問題和擁有開源許可證等*
問候！ 感謝您的報告！ 我叫馬克西姆。 我們處理過同樣的問題。 他們自己決定。 您如何在這些克隆之間共享資源？ 每個克隆都可以在任何給定時間做自己的事情：一個測試一個東西，另一個測試另一個，有人建立索引，有人有繁重的工作。 而且如果還可以按CPU劃分，那麼按IO，怎麼劃分？ 這是第一個問題。
第二個問題是關於看台的不同之處。 假設我這裡有 ZFS，一切都很好，但是產品上的客戶端沒有 ZFS，而是 ext4，例如。 在這種情況下如何？
問題非常好。 我提到了這個問題，因為我們共享資源。 解決方案是這樣的。 想像一下，您正在測試分期。 您也可以同時遇到這樣的情況，即有人給一個負載，另一個人。 結果，您會看到難以理解的指標。 甚至同樣的問題也可能出現在產品上。 當您想檢查某個請求並發現它存在問題時 - 它運行緩慢，那麼實際上問題不在請求中，而是存在某種並行負載的事實。
因此，在這裡重要的是要關注計劃是什麼、我們將在計劃中採取哪些步驟以及我們將為此收集多少數據。 例如，我們的磁盤會加載一些東西，這會特別影響時間。 但是我們可以通過數據量來估計這個請求的負載情況。 同時進行某種執行並不那麼重要。
我有兩個問題。 這是非常酷的東西。 是否存在生產數據至關重要的情況，例如信用卡號？ 是否已經準備好了一些東西或者它是一個單獨的任務？ 第二個問題 - MySQL 是否有類似的東西？
關於數據。 我們將進行混淆直到我們這樣做。 但是如果你部署的正是 Joe，如果你不給開發人員訪問權限，那麼就沒有訪問數據的權限。 為什麼？ 因為喬不顯示數據。 它只顯示指標、計劃，僅此而已。 這是故意的，因為這是我們客戶的要求之一。 他們希望能夠在不讓每個人都訪問的情況下進行優化。
關於 MySQL。 該系統可用於在磁盤上存儲狀態的任何事物。 因為我們在做 Postgres，所以我們現在首先為 Postgres 做所有的自動化。 我們希望自動從備份中獲取數據。 我們正在正確配置 Postgres。 我們知道如何使計劃匹配等。
但是由於系統是可擴展的，它也可以用於MySQL。 而且還有這樣的例子。 Yandex 有類似的東西，但他們不會在任何地方發布。 他們在 Yandex.Metrica 中使用它。 還有一個關於 MySQL 的故事。 但技術是相同的，ZFS。
感謝您的報告！ 我也有幾個問題。 您提到克隆可用於分析，例如在那裡構建額外的索引。 您能詳細介紹一下它是如何工作的嗎？
我會立即問第二個問題，關於看台的相似性，計劃的相似性。 該計劃還取決於 Postgres 收集的統計數據。 你怎麼解決這個問題？
根據分析，沒有具體案例，因為我們還沒有用過，但是有這樣的機會。 如果我們談論的是索引，那麼想像一下，一個查詢正在查詢一個有數億條記錄的表和一個通常不會在 prod 中建立索引的列。 我們想在那裡計算一些數據。 如果這個請求發送到prod，那麼有可能在prod上很簡單，因為請求會在那里處理一分鐘。
好吧，讓我們做一個不可怕的瘦克隆，停幾分鐘。 為了使閱讀分析更加舒適，我們將為我們對數據感興趣的那些列添加索引。
每次都會創建索引？
你可以讓我們接觸數據，製作快照，然後我們將從這個快照中恢復並驅動新的請求。 也就是說，您可以這樣做，以便您可以使用已經附加的索引來培育新的克隆。
至於關於統計的問題，如果我們從備份中恢復，如果我們做複製，那麼我們的統計將是完全一樣的。 因為我們擁有完整的物理數據結構，也就是說，我們也會將數據與所有統計指標一起帶來。
這是另一個問題。 如果您使用雲解決方案，那麼那裡只有邏輯轉儲可用，因為谷歌、亞馬遜不允許您獲取物理副本。 就會出現這樣的問題。
感謝您的報告。 這裡有兩個關於 MySQL 和資源共享的好問題。 但是，事實上，這一切都歸結為這樣一個事實，即這不是特定 DBMS 的主題，而是整個文件系統的主題。 並且，相應地，資源共享問題也應該從那裡解決，而不是在它是 Postgres 的最後，而是在文件系統中，在服務器中，例如。
我的問題有點不同。 它更接近於多層數據庫，其中有好幾層。 例如，我們設置了一個 100 TB 的圖像更新，我們正在復制。 我們專門將此解決方案用於數據庫。 正在進行複制，正在更新數據。 這裡有XNUMX名員工並行工作，他們不斷推出這些不同的鏡頭。 該怎麼辦？ 怎麼保證沒有衝突，他們啟動了一個，然後文件系統變了，這些圖片都去了？
他們不會去，因為這就是 ZFS 的工作方式。 我們可以在一個線程中單獨保存因複製而產生的文件系統更改。 並保留開發人員在舊版本數據上使用的克隆。 它對我們有用，一切都井井有條。
事實證明，更新將作為附加層進行，所有新圖片都會基於這一層，對吧？
來自先前複製的先前層。
之前的層會脫落，但它們會參考舊層，它們會從更新中收到的最後一層獲取新圖像嗎？
一般來說，是的。
那麼結果我們將有一個無花果層。 隨著時間的推移，它們將需要被壓縮？
是的，一切都是正確的。 有一些窗口。 我們保留每週快照。 這取決於你有什麼資源。 如果您有存儲大量數據的能力，您可以將快照存儲很長時間。 他們不會自行消失。 不會有數據損壞。 如果快照已過時，就像我們認為的那樣，即這取決於公司的政策，那麼我們可以簡單地刪除它們並釋放空間。
您好，感謝您的舉報！ 關於喬的問題。 你說客戶不想讓每個人都能訪問數據。 嚴格來說，如果一個人有了Explain Analyze的結果，那麼他就可以窺視數據了。
就像那樣。 例如，我們可以寫：“SELECT FROM WHERE email = to that”。 也就是說，我們不會看到數據本身，但是我們可以看到一些間接的跡象。 必須了解這一點。 但另一方面，一切都在那裡。 我們有日誌審計，我們可以控制其他同事，他們也可以看到開發人員在做什麼。 如果有人試圖這樣做，那麼安全部門就會找到他們並解決這個問題。
下午好感謝您的報告！ 我有一個簡短的問題。 如果公司不使用 Slack，現在是否有任何綁定，或者開發人員是否可以部署實例以將測試應用程序連接到數據庫？
現在有 Slack 的鏈接，即沒有其他信使，但我真的很想也支持其他信使。 你能做什麼？ 您可以在沒有 Joe 的情況下部署 DB Lab，借助 REST API 或借助我們的平台，創建克隆並連接 PSQL。 但如果您準備好讓您的開發人員訪問數據，就可以做到這一點，因為將不再有任何屏幕。
我不需要這一層，但我需要這樣的機會。
那麼是的，它可以完成。
來源： www.habr.com