整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
文分享自華為云社區《GaussDB(DWS)性能調優系列實戰篇七：十八般武藝之GUC參數調優-云社區-華為云》，作者： 黎明的風。
GaussDB(DWS)性能調優系列專題文章，介紹了數據庫性能調優的思路和總體策略。在系統級調優中數據庫全局的GUC參數對整體性能的提升至關重要，而在語句級調優中GUC參數可以調整估算模型，選擇查詢計劃中算子的類型，或者選擇不同的執行計劃。因此在SQL調優過程中合理的設置GUC參數十分重要。
在GaussDB(DWS)中，SQL語句的執行所需要經歷的步驟如下圖所示，其中紅色部分為DBA可以介入實施調優的環節。
查詢計劃的生成是基于一定的模型和統計信息進行代碼估算，在某些場景由于統計信息不準確或者代價估算有偏差時，就需要通過GUC參數設置的的方式選擇更優的查詢計劃。
在GaussDB(DWS)中，和SQL執行性能相關的GUC參數主要有以下幾個：
GaussDB(DWS)是分布式的數據庫集群，數據計算盡量在各個DN上并行計算，可以得到最優的性能，在Stream框架下Agg操作可以分為兩個場景。
Agg下層算子輸出結果集的分布列是Group By列的子集。
這種場景，直接對下層結果集進行匯聚的結果就是正確的匯聚結果，生成算子直接使用即可。例如以下語句，lineitem的分布列是l_orderkey，它是Group By的列。
select
l_orderkey,
count(*) as count_order
from
lineitem
group by
l_orderkey;
查詢計劃如下：
Agg下層算子輸出結果集的分布列不是Group By列的子集。
對于這種場景Stream下的聚集（Agg）操作，優化器可以生成以下三種形態的查詢計劃：
通常優化器總會選擇最優的執行計劃，但是眾所周知代價估算，尤其是中間結果集的代價估算有時會有比較大的偏差。這種比較大的偏差就可能會導致聚集（agg）的計算方式出現比較大的偏差，這時候就需要通過best_agg_plan參數進行聚集計算模型的干預。
以下通過TPC-H Q1語句分析三種形態的查詢計劃：
-- TPC-H Q1
select
l_returnflag,
l_linestatus,
sum(l_quantity) as sum_qty,
sum(l_extendedprice) as sum_base_price,
sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
avg(l_quantity) as avg_qty,
avg(l_extendedprice) as avg_price,
avg(l_discount) as avg_disc,
count(*) as count_order
from
lineitem
where
l_shipdate <=date '1998-12-01' - interval '90' day (3)
group by
l_returnflag,
l_linestatus
order by
l_returnflag,
l_linestatus;
}
當best_agg_plan=1時，在DN上進行了一次聚集，然后結果通過GATHER算子匯總到CN上進行了二次聚集，對應的查詢計劃如下：
該方法適用于DN第一次聚集后結果集較少并且DN數較少的場景，在CN上進行第二次聚集時的結果集小，CN不會成為計算瓶頸。
當best_agg_plan=2時，在DN上先按照Group By的列進行數據重分布，然后在DN上進行聚集操作，將匯總的結果返回給CN，對應的查詢計劃如下：
該方法適用于DN第一次聚集后結果集縮減不明顯的場景，因為這樣可以省略DN上的第一次聚集操作。
當best_agg_plan=3時，在DN上進行一次聚集，然后將聚集結果按照Group By的列進行數據重分布，之后在DN上進行二次聚集得到結果，對應的查詢計劃如下：
該方法使用于DN第一次聚集后中間結果縮減明顯，但最終結果行數比較大的場景。
GaussDB(DWS)中，以上三種方法的選擇是根據代價來自動選擇。在實際的SQL調優時，如果遇到有聚集方式不合理的場景，可以通過嘗試設置best_agg_plan參數，選擇最優的聚集方式。
GaussDB(DWS)中實現分組聚集操作有兩種方法：
以下面的SQL為例：
select
l_orderkey,
count(*) as count_order
from
lineitem
group by
l_orderkey;
如果使用Sort + GroupAgg的方式，在Sort排序算子里執行時間比較長，因為需要對大量數據進行排序操作。
以上這種場景，可以關閉enable_sort參數，選擇使用HashAgg的方式來實現聚集操作，可以獲得較好的執行性能。
GaussDB(DWS)中通過count distinct來統計多個列的數據時，通常會使用HashAgg來實現每一個列的統計聚集操作，然后將結果通過Join方式關聯起來得到最終結果。
以下面的SQL為例：
select
l_orderkey,
count(distinct l_partkey) as count_partkey,
count(distinct l_suppkey) as count_suppkey,
count(distinct l_linenumber) as count_linenumber,
count(distinct l_returnflag) as count_returnflag,
count(distinct l_linestatus) as count_linestatus,
count(distinct l_shipmode) as count_shipmode
from
lineitem
group by
l_orderkey;
從查詢計劃來看，通過count distinct統計了lineitem表中的6列數據，是通過6個HashAgg操作來實現的，該SQL執行時消耗的資源相對較高。
如果關閉enable_hashagg參數，優化器會選擇Sort + GroupAgg的方式，該SQL執行時消耗的資源相對較少。
在應用開發時，可以根據SQL并發和資源使用情況，通過設置enable_hashagg參數來選擇合適的執行計劃。
GaussDB(DWS)支持行存儲和列存儲兩種存儲模型，用戶可以根據應用場景，建表的時候選擇行存儲還是列存儲表。向量化執行將傳統的執行模式由一次一元組的模型修改為一次一批元組，配合列存特性，可以帶來巨大的性能提升。
如果使用行存表或者是行列混存的場景，由于行存表默認走的是行存執行引擎，最終查詢無法走向量化執行引擎。
以下面的SQL為例：
select
l_orderkey,
sum(l_extendedprice * (1 - l_discount)) as revenue,
o_orderdate,
o_shippriority
from
customer_row,
orders,
lineitem
where
c_mktsegment='BUILDING'
and c_custkey=o_custkey
and l_orderkey=o_orderkey
and o_orderdate < date '1995-03-15'
and l_shipdate > date '1995-03-15'
group by
l_orderkey,
o_orderdate,
o_shippriority
order by
revenue desc,
o_orderdate
limit 10;
SQL語句中的customer_row表為行存表，orders和lineitem為列存表，該場景在默認參數的情況下無法走向量化引擎，Row Adapter算子表示將列存數據轉為行存數據，對應的查詢計劃為：
這種場景，可以選擇開啟enable_force_vector_engine參數，通過向量化執行引擎來執行，Vector Adapter算子表示將行存數據轉換為列存數據，每個算子前面的Vector表示改算子為向量化引擎的執行器算子，對應的查詢計劃為：
從上述計劃可以看出，向量化引擎相比行執行引擎，執行性能有數倍的提升效果。
GaussDB(DWS)支持并行計算技術，當系統的CPU、內存、I/O和網絡帶寬等資源充足時，可以充分利用富余硬件資源，提升語句的執行速度。在GaussDB(DWS)中，通過query_dop參數，來控制語句的并行度，取值如下：
query_dop參數設置的一些原則：
設置query_dop=0可以實現自適應調優，在部分場景下語句執行的并行度沒有達到最優，這種情況可以考慮通過query_dop參數設置并行度。
例如下面的SQL：
select count(*) from
(
select
l_orderkey,
count(*) as count_order
from
lineitem
group by
l_orderkey
);
在query_dop=0時使用的并行度為2。
設置query_dop=4時使用的并行度為4，執行時間相比并行度為2時有明顯的提升。
在使用GaussDB(DWS)時，全局的GUC參數對集群整體性能影響很大，這里介紹一些常用參數以及推薦的配置。
影響數據庫性能的五大內存參數有：max_process_memory、shared_buffers、cstore_buffers、work_mem和maintenance_work_mem。
max_process_memory
max_process_memory是邏輯內存管理參數，主要功能是控制單個CN/DN上可用內存的最大峰值。
計算公式：max_process_memory=物理內存*0.665/(1+主DN個數)。
shared_buffers
設置DWS使用的共享內存大小。增加此參數的值會使DWS比系統默認設置需要更多的System V共享內存。
建議設置shared_buffers值為內存的40%以內。主要用于行存表scan。計算公式：shared_buffers=(單服務器內存/單服務器DN個數)0.40.25
cstore_buffers
設置列存和OBS、HDFS外表列存格式（orc、parquet、carbondata）所使用的共享緩沖區的大小。
計算公式可參考shared_buffers。
work_mem
設置內部排序操作和Hash表在開始寫入臨時磁盤文件之前使用的內存大小。
ORDER BY，DISTINCT和merge joins都要用到排序操作。Hash表在散列連接、散列為基礎的聚集、散列為基礎的IN子查詢處理中都要用到。
對于復雜的查詢，可能會同時并發運行好幾個排序或者散列操作，每個都可以使用此參數所聲明的內存量，不足時會使用臨時文件。同樣，好幾個正在運行的會話可能會同時進行排序操作。因此使用的總內存可能是work_mem的好幾倍。
計算公式：
對于串行無并發的復雜查詢場景，平均每個查詢有5-10關聯操作，建議work_mem=50%內存/10。
對于串行無并發的簡單查詢場景，平均每個查詢有2-5個關聯操作，建議work_mem=50%內存/5。
對于并發場景，建議work_mem=串行下的work_mem/物理并發數。
maintenance_work_mem
maintenance_work_mem用來設置維護性操作（比如VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY等）中可使用的最大的內存。
當自動清理進程運行時，autovacuum_max_workers倍數的內存將會被分配，所以此時設置maintenance_work_mem的值應該不小于work_mem。
連接相關的參數有兩個：max_connections和max_prepared_transactions
max_connections
允許和數據庫連接的最大并發連接數。此參數會影響集群的并發能力。
設置建議：
CN中此參數建議保持默認值。DN中此參數建議設置為CN的個數乘以CN中此參數的值。
增大這個參數可能導致GaussDB(DWS)要求更多的System V共享內存或者信號量，可能超過操作系統缺省配置的最大值。這種情況下，請酌情對數值加以調整。
max_prepared_transactions
設置可以同時處于"預備"狀態的事務的最大數目。增加此參數的值會使GaussDB(DWS)比系統默認設置需要更多的System V共享內存。
NOTICE:
max_connections取值的設置受max_prepared_transactions的影響，在設
max_connections之前，應確保max_prepared_transactions的值大于或等
max_connections的值，這樣可確保每個會話都有一個等待中的預備事務。
max_active_statements
設置全局的最大并發數量。此參數只應用到CN，且針對一個CN上的執行作業。
需根據系統資源（如CPU資源、IO資源和內存資源）情況，調整此數值大小，使得系統支持最大限度的并發作業，且防止并發執行作業過多，引起系統崩潰。
當取值-1或者0時，不限制全局并發數。
在點查詢的場景下，參數建議設置為100。
在分析類查詢的場景下，參數的值設置為CPU的核數除以DN個數，一般可以設置5~8個。
bulk_write_ring_size
數據并行導入使用的環形緩沖區大小。
該參數主要影響入庫性能，建議導入壓力大的場景增加DN上的該參數配置。
checkpoint_completion_target
指定檢查點完成的目標。
含義是每個checkpoint需要在checkpoints間隔時間的50%內完成。
默認值為0.5，為提高性能可改成0.9。
data_replicate_buffer_size
發送端與接收端傳遞數據頁時，隊列占用內存的大小。此參數會影響主備之間復制的緩沖大小。
默認值為128MB，若服務器內存為256G，可適當增大到512MB。
wal_receiver_buffer_size
備機與從備接收Xlog存放到內存緩沖區的大小。
默認值為64MB，若服務器內存為256G，可適當增大到128MB
本篇文章主要介紹了GaussDB(DWS)性能調優涉及到的優化器和系統級GUC參數，通過合理配置這些GUC參數，能夠充分利用好CPU、內存、磁盤IO和網絡IO等資源，提升語句的執行性能和GaussDB(DWS)集群的整體性能。
關注@華為云開發者聯盟點擊下方，第一時間了解華為云新鮮技術~
華為云博客_大數據博客_AI博客_云計算博客_開發者中心-華為云
器之心報道
作者：蛋醬
在近日公布的 MSU 2020 比賽結果中，首次亮相的字節跳動 BVC2.0 編碼器一舉收獲了「四個第一」。
首先，讓我們看兩張圖片：
(a) BVC2.0 處理后的圖像。
(b) x265 處理后的圖像。
上面兩張圖片是在相同壓縮比情況下，x265 和 BVC2.0 的壓縮圖像效果。這樣的對比場景，是否似曾相識？
沒錯，讓人想起了視頻網站中「流暢」和「高清」的對比。受移動互聯網發展、移動智能終端普及等因素的推動，短視頻和直播行業近年來實現了爆發式的增長，但對于業務方來說，存儲空間和帶寬資源的成本仍然高昂；對于普通用戶來說，不清晰的畫質和卡頓問題還十分普遍。這些目前所存在的挑戰，都對視頻編解碼技術提出了更高的要求。
從 2005 年開始，俄羅斯莫斯科國立大學（Mosow State University，MSU）每年定期在全球范圍內征集各大公司及相關機構研發的視頻編碼器，在不同的應用場景下對其進行綜合測評。視頻編碼器（Video Codecs Comparison）大賽迄今已連續舉辦十五屆，是視頻編碼行業內影響力最大的比賽。與往年一樣，今年也有很多國內外的頂尖技術團隊參賽，分別來自谷歌、英特爾、百度、阿里、騰訊等科技公司，且擁有豐富的比賽經驗。
在本年度 MSU2020 offline （1fps）視頻編碼器比賽中，字節跳動先進視頻團隊（Advanced Video Group）自主研發的 BVC2.0 編碼器從競爭中脫穎而出：在 VMAF、PSNR avg. MSE 兩個準則測試中摘得第一名的成績。同時也在 PSNR avg. log、SSIM 兩個準則測試中獲得并列第一的排名。
四個「第一」
近日，MSU2020 主辦方公開了 20 個團隊的測試結果，在 VMAF 準則測試中，字節跳動的 BVC2.0 編碼器領先第二名 8％，領先第三名 15%；在 PSNR avg. MSE 準則測試中，則是領先第二名 6％。而在 PSNR avg. log 和 SSIM 準則測試中， BVC2.0 編碼器以極微小的差距與阿里、微幀的產品并列第一。
VMAF 準則測試，測試數據越小表示壓縮率越高，成績越好。
PSNR avg. MSE 準則測試，測試數據越小表示壓縮率越高，成績越好。
上圖為 PSNR avg. log 準則測試，測試數據越小表示壓縮率越高，成績越好。
上圖為 SSIM 準則測試，測試數據越小表示壓縮率越高，成績越好。
據了解，BVC2.0 編碼器從框架到算法搭建完全由字節跳動先進視頻團隊自研，盡管參與人員少，開發周期短，但得益于公司在視頻壓縮標準領域的技術儲備，以及算法方面的創新，最終表現出了更好的壓縮性能。
目前 BVC2.0 編碼器完全基于傳統視頻編碼和優化技術，隨著學界和業界越來越多地使用卷積神經網絡等深度學習技術以提高壓縮效率、編碼優化和視頻處理能力。字節跳動先進視頻團隊表示，團隊的相關領域成果未來將融合在下一版本的 BVC2.0 編碼器中。
帶寬成本大幅降低，畫質更清晰，更流暢
未來，BVC2.0 編碼器可應用于字節跳動旗下大部分產品，包括抖音、西瓜視頻、等 App 的視頻類內容處理，以及云計算、云游戲等基礎架構領域。
字節跳動也正在計劃將 BVC2.0 編碼器開放給合作伙伴使用。先進視頻團隊的張莉博士表示：「將 BVC2.0 編碼器應用到公司業務中后，將能夠節省 20%-50% 的流量帶寬和存儲成本。假設一年的帶寬成本為 10 億，那么使用 BVC2.0 編碼器有望比目前最優的編碼器節省 2-5 億。」
除了幫助業務節省成本外，對于短視頻行業的用戶，BVC2.0 編碼器也很有意義。在有限的網絡帶寬資源條件下，BVC2.0 的轉碼能力，可以讓普通用戶獲得更高畫質、更流暢的視頻體驗。例如，原來只能看標清的用戶，現在可以獲得高清的體驗。
在國內視頻編解碼技術標準領域，字節跳動也有著很高的貢獻度。2002 年，數字音視頻編解碼技術標準工作組（AVS）的成立標志著中國視頻標準化工作的正式起步，迄今 AVS 音視頻編碼標準已經發展到第三代。經過十幾年的發展，AVS 視頻編碼標準的壓縮性已經實現了大幅提升。作為 AVS 第三代視頻編碼標準的重要技術貢獻者之一，字節跳動一直通過組織 AVS3 技術研討會、分享 AVS3 先進技術等各種形式向工業界和學術界推廣 AVS 標準。
去年，字節跳動先進視頻團隊也曾因視頻編碼國家標準 AVS 方面的技術功效，獲得了「2019 年度 AVS 產業技術創新獎」，字節跳動也是該獎項中的唯一一家互聯網公司。
此外，字節跳動先進視頻團隊成員也在多個國際標準化工作組中擔任重要角色，如 VVC、H.265/HEVC、H.264/AVC 等多項標準文本主編及編委等，同時，也是多項多媒體國際標準的重要貢獻者之一，包括視頻編碼標準、系統標準、傳輸協議、文件格式等。過去兩年間，字節跳動先進視頻團隊累計遞交了 260 項以上 H.266/VVC 技術提案，被采納數量超過 130 項。
張莉博士表示：「視頻編碼優化和傳輸是一項重要且非常有挑戰的工作，只有持續創新，才能保持不斷推動技術升級。我們希望與行業一起，為大家提供更好的視頻編碼技術能力，提升用戶的視頻體驗。」
參考鏈接：https://www.compression.ru/video/codec_comparison/hevc_2020/main_report.html
譯局是36氪旗下編譯團隊，關注科技、商業、職場、生活等領域，重點介紹國外的新技術、新觀點、新風向。
編者按：Marc Andreessen十年前說的“軟件蠶食世界”不僅完全正確，而且似乎不僅如此：軟件正在重塑世界。人類世界的運轉已經無法離開軟件。在浩如煙海的軟件代碼當中，哪些對我們起到了關鍵作用呢？Slate網站邀請了各方人士對那些改變了一切的代碼進行評選，這里篩選出36個代碼片段。如果你有更好的選項，不妨在評論區留下你的意見。原文作者是Future Tense，標題是：The Lines of Code That Changed Everything。鑒于篇幅太長，我們將分三部分刊出，此為第三部分。
人類歷史上最重要的36個代碼片段（一）
人類歷史上最重要的36個代碼片段（二）
年代：1990年代中期
它讓網站最平凡的元素也能酷炫起來。
JSFX.FireSpark.prototype.changeColour=function
{
var colour="";
r2=Math.random*255;
g2=r2;
b2=0;
if(!(r2 | g2 | b2))
{
r2=255;
g2=255;
b2=0;
}
colour="#" + dec2hex(r2) + dec2hex(g2) + dec2hex(b2);
this.setBgColor(colour);
}
Roy Whittle
Douglas Englebart和Bill English在1960年代后期發明的鼠標改變了我們與計算機溝通的方式。盡管使用鼠標很直觀，但當時的顯示技術通常無法跟上鼠標的快速移動。操作系統開發人員于是添加了鼠標軌跡，也就是瞬時的陰影圖像，顯示出光標在之前的位置，從而更易于跟蹤和查找。
在1990年代中期，GeoCities 是第一個提供免費服務，讓用戶可以輕松創建自己的Web內容的公司。GeoCities 所見即所得（WYSIWYG）的編輯器使得創建者可以輕松地拖拽內容，添加自定義的代碼段，包括用于定制訪問者看到的鼠標軌跡的代碼。在GeoCities的網頁上，你的光標可以留下童話般的灰塵、氣泡或小小的萬圣節蝙蝠的痕跡。這些絢麗的像素是一個時代的縮影，說明我們已經能夠自己建立自己的“網絡空間”——Nikki Stevens，亞利桑那州立大學博士研究生
年代：1999
讓大家在一個地方就能閱讀《紐約時報》、Gizmodo 以及Garfield Minus Garfield。
http://www.example.com/main.html
http://www.example.com/blog/post/1
維基百科
通過將新聞報道、博客、blawgs（法律博客）、播客以及其它web內容形式發布成標準格式，RSS代碼讓你可以用一種簡單、有效以及高效的方式去消費各種信息來源。在巔峰時期，大概是從2005年Google Reader推出到2013年Aaron Swartz（致力于RSS 1.0開發的互聯網自由主義者）不幸去世的這段時間內，RSS幾乎就相當于在去中心化的互聯網上發布的代名詞。盡管Google Reader已經不復存在，但從新聞聚合器到播客應用，RSS依舊站在可用互聯網的最前沿。——David S. Levine，埃隆大學法學院副教授
年代：1999
一個數學錯誤導致一項任務失敗
1999年9月23日，NASA的科學家與價值1.25億美元的火星氣候軌道器失去了聯系。經過調查，確定了失聯的原因：一家承包商用英制單位給軌道器寫了程序，但是NASA的軟件用的卻是公制。就因為兩段代碼之間簡單的溝通錯誤，導致軌道器飛到了未知的地方。
很容易會把這種公制——英制的錯誤當作意外錯誤而一筆勾銷，但這說明了當今軟件互聯的世界是多么的脆弱。所有的連接技術（電話、宇宙飛船、機器人榨汁機等等）都要靠接口來定義與它者的通信方式。哪怕是最小的差錯也會導致混亂。——Charles Duan
年代：大約2000–2001年
開辟了無人機戰爭的先河。
“捕食者”無人機早期版本的武器化是個標志性的時刻，不僅在技術史上如此，在軍事和政治史上亦然。現在，無人系統已經遍布整個戰場，重塑了士兵的作戰方式，甚至改變士兵的來源。捕食者的武器化也使得美國進入了“無人機戰爭”的時代。而且，隨著鑒于機器人日益自動化、武器化引起的問題，我們現在才剛剛開始。一個簡單的程序可能就會帶來法律上、道德上甚至是生存性的問題。——PW Singer，《連線戰爭：21世紀的機器人革命與沖突》作者
年代：2002
為技術（和貓）在現實世界的移動建立了新途徑
(define-behavior (bounce
:start-when (or (bump?)
bounce-trigger? )
:abort-when (bump-edge?)
:onetime? t
)
)
iRobot
你永遠也不會忘記自己的第一臺Roomba：我的大概是在17年前在一個朋友家。當它在房子里面嗡嗡地由著自己的性子轉來轉去時，我正坐在沙發上哈哈大笑。這是機器人革命的曙光，一場看起來很蠢但是又很認真的革命。（跟炸彈清理機器有著一樣DNA的機器人正在數百萬個家庭里面吸塵，這一點著實讓人吃驚。）從那以后，別人再也難以復制它的成功。Roomba證明，盡管我們的注意力重心已經開始向硬件傾斜（比如波士頓動力怪異的膝蓋向后彎、會開門的機器狗）上，但軟件對于一件產品的廣泛采用可能更為重要。阿西莫夫化的iRobot并沒有創造出第一個真空吸塵機器人，但是Roomba成為一個必備的利基產品不是因為它吸塵效果好，而是因為它在房間里面的導航效果不錯。就像成千上萬的小貓視頻可以證明那樣，在現代計算時代，幾乎沒有什么東西能比看著Roomba撞到桌腿、轉圈一周然后前進更令人滿足的了。——Lowen Liu，Slate
年代：約2003年
令手機網絡成為可能的解決方案
[~, b_user]=max(drc(i, :)/_avg_thruput(i, :));
avg_thruput(i+1, :)=(i/(i+1))*avg_thruput(i, :);
avg_thruput(i+1, b_user)=(i/(i+1))*avg_thruput(i, b_user)+drc(i, b_user)/(i+1);
“使用路徑分集公平地最大化吞吐量的定向發射機多接收機系統”，美國專利第6444990號，2002年9月10日
任何時候在任何一個地方，手機的數量通常都要比基站數量多。如果不進行調解的話，所有的傳輸都會相互干擾并阻礙信息的可靠接收。因此，基站需要解決優先級問題：確保所有用戶都能完成通話，同時還要考慮到在嘈雜環境的用戶需要賦予更多資源才能得到同樣服務質量這一點。解決方案？要在個體用戶需求與網絡整體性能之間進行折衷。比例公平調度可確保所有用戶至少享有最低級別的服務，同時最大程度地提高總的網絡吞吐量。這是通過將較低的優先級賦予預期需要更多資源的用戶來實現的。僅三行代碼就讓全球所有的3G和4G無線網絡正常工作。——Lav Varshney
年代：2008年
激發大家對一種貨幣的信心的代碼，沒有它就沒有這種貨幣
double AttackerSuccessProbability(double q, int z)
{
double p=1.0 - q;
double lambda=z * (q / p);
double sum=1.0;
int i, k;
for (k=0; k {
double poisson=exp(-lambda);
for (i=1; i poisson *=lambda / i;
sum -=poisson * (1 - pow(q / p, z - k));
}
return sum;
}
中本聰
不管你是比特幣的布道者還是懷疑者，或者不大確定它是什么，你大概都知道這可是個大事物。比特幣本身已經獲得了數千億美元的直接投資，但是也許更重要的是，其基礎的技術原理，也就是區塊鏈，似乎有著無窮無盡的應用，從確保民主選舉到結束非自愿的性接觸等等都在它的應用范圍。
這一切始于2008年，當匿名的中本聰發表了一份白皮書，宣布要推出比特幣。上述代碼就是實現的一部分，這些代碼的作用是計算出攻擊者接管比特幣區塊鏈的可能性極小。這里的數學讓世界相信，由不可靠的人組成的系統仍然可以信任，這為至少2777種其他加密貨幣的創建鋪平了道路。——Elena Botella
年代：2008年10月至2009年
把受感染的計算機變成惡意的機器人大軍，同時又保護其他的一些計算機
; BOOL __cdecl HasUkrainianLocale
push ebx
mov ebx, ds:GetKeyboardLayoutList
push ebp
push esi
xor ebp, ebp
push ebp
push ebp
call ebx
mov esi, eax
cmp esi, ebp
jz short loc_37680A
這段代碼是安全研究人員Tillmann Werner和Felix Leder 編寫的，后來還進行了功能等效性測試，為的是理解和對抗Conficker 蠕蟲。
Tillmann Werner和Felix Leder
十年前，感染Conficker的計算機數量多達1500萬臺。這是一種利用Windows操作系統的漏洞的病毒。這種病毒雖然令人恐懼，但也因為它的老辣而備受推崇：它會邀請每一臺計算機加入到龐大的僵尸大軍，等候命令下達，還會阻止受感染的計算機打開安全程序或下載可以清除病毒的補丁程序。其最早版本還有一個非常有趣且很能說明問題的怪癖：如果駐留在任何使用烏克蘭鍵盤或烏克蘭IP地址的系統就會自毀。多年后，對該病毒進行逆向工程的主管部門和研究人員得出結論，Conficker的開發者確實是烏克蘭人，他們這樣設計病毒是為了避免違反自己國家的法律。幸運的是，這些黑客一直都沒有動用過那支僵尸大軍來作惡，截至到2018年，估計仍有35萬臺計算機感染這種病毒，這提醒我們嫻熟的程序員要想發動國際攻擊，有選擇地對用戶造成破壞可以是多么的容易。——Jane C. Hu
年代：2009
它催生了監視經濟。
{"__typename":"PageLikeAction","action_type":"LIKE","label":{"text":"Like"}
2019年9月的Facebook.com 網站
Facebook把點“贊”按鈕當作向世界展示我們喜歡辛普森一家或炸薯條的一種手段來兜售。。但實際上，它利用了我們的認知偏見，以及設計的力量，去誘使我們分享更多的信息。由于有了前面Sara Wachter-Boettcher介紹過的像素跟蹤，它跟蹤我們在互聯網的行蹤，收集有關我們瀏覽習慣的數據。Facebook拿走這些信息，再把自己的行為定向廣告算法賣給廣告主。如果一家戶外用品公司想要做廣告，Facebook可以鎖定那些以前“贊”過遠足的文章，訪問過露營網站以及有戶外朋友的人。當這些用戶“贊”了相關公司的廣告時，這些信息就會反饋會定向廣告算法里面。這樣一來，監視和商業操縱就形成了周而復始的循環。這一切都是因為一個小小的藍色大拇指。——Ari Ezra Waldman，紐約法學院教授
年代：2009年左右
默認開啟安全通道來保護網站安全
Strict-Transport-Security: max-age=31536000; includeSubDomains
Mozilla開發人員指南
當你通過普通HTTP協議將信息發送到網站時，這是會泄漏的——別人可能會攔截這段信息并竊聽你的信用卡、健康信息以及伴侶的寵物名什么的。HTTPS可以加密你的流量，避免別人窺探信息，但是很長一段時間以來，使用這種更先進的協議一直都是可選的。因此就有了HTTP Strict Transport Security，此這種安全措施可確保從一開始往來該網站的流量就是加密的。如果你想要訪問http://google.com，它會自動將你重定向到https://google.com。這就是HSTS的作用。
HSTS還沒有普及：估計只有11.1％的網站用到。但2015年春天，重要一刻降臨，美國聯邦政府和行業合作伙伴對19個政府領域實施HSTS，其中包括Whitehouse.gov，AIDS.gov和donotcall.gov。此后不久，所有聯邦機構均要求采用該標準。——Rusty D. Pickens，奧巴馬政府白宮前代理新媒體總監
年代：2012年編寫，2014年被發現
計算史上傳播最廣、危害最大的安全漏洞之一
buffer=OPENSSL_malloc(1 + 2 + payload + padding);
bp=buffer;
/* Enter response type, length and copy payload */
*bp++=TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);
bp +=payload;
/* Random padding */
RAND_pseudo_bytes(bp, padding);
來自Naked Security
2014年，安全研究人員在OpenSSL（一個非常受歡迎的開源庫）中發現了一個漏洞，大約有三分之二的網站（包括DropBox ，Twitter，Yahoo和GitHub）都用到它——用于在兩臺計算機之間進行在線通信。Heartbleed使得犯罪分子可以通過影響數百萬臺設備的緩沖區讀取漏洞來竊取未加密的機密信息，包括憑據和加密密鑰等。這讓大家注意到了依靠開源軟件來實現關鍵安全功能所帶來的風險，以及識別已被使用多年的代碼漏洞的挑戰。從更積極的意義上來說，Heartbleed的發現也引發了迅速而有效的全球反應，包括在全球范圍內進行的協調宣傳和補救工作，其力度和廣度均遠遠超出了以前針對早期漏洞的許多同類行動。-塔夫茨大學助理教授Josephine Wolff
年代：2017年推出
軟件錯誤，加上企業的貪婪，導致數百人喪生，以及大批飛機停飛。
2018年10月，獅航610航班起飛后不久就發生了一次似乎非常怪異的事故，然后墜入海中。波音向公眾保證飛機是安全的，并表示需要進行更多的飛行員培訓以及“軟件升級”。但是僅僅四個月后，埃塞俄比亞航空的一名飛行員抬升機頭的努力做了20次，但飛機的自動系統仍然把機頭往下推。起飛后的幾分鐘內，機上所有人員均告死亡。作為對事故的響應，全球的民航當局這這一型號的飛機都停飛了。調查顯示，墜機事故是因為737 Max的設計引起的，尤其是鮮為人知，了解程度不高的軟件，可能會強制飛機反復做俯沖動作。——技術史學家，《寫入程序的不平等》作者Mar Hicks
譯者：boxi。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
