PostgreSQL的穩定性極強，Innodb等索引在崩潰，斷電之類的災難場景下 抗擊打能力有了長足進步，然而很多 MqSQL用戶 都遇到過 Server級的資料庫丟失的場景 -- MySQL系統庫是 MyISAM，相比之下，PG資料庫這方面要更好一些。
任何系統都有它的性能極限，在高並發讀寫，負載逼近極限下，PG的性能指標仍可以位置雙曲線甚至對數曲線，到 頂峰之後不在下降，而MySQL明顯出現一個波峰後下滑（5.5版本 之後，在企業級版本中有個插件可以改善很多，不過需要付費）。
PG多年來在 GIS（地理信息）領域處於優勢地位，因為它有豐富的幾何類型，PG有大量字典，數組，bitmap等數據類型，相比之下 MySQL就差很多， Instagram就是因為 PG的空間資料庫 擴展 POSTGIS遠遠強於 MySQL的 my spatial 而採用 PgSQL的。
PG的「無鎖定」特性非常突出，甚至包括 vacuum這樣的整理數據空間的操作，這個和PGSQL的MVCC實現有關系。
PG可以使用函數 和 條件索引，這使得 PG資料庫的調優非常靈活， MySQL就沒有這個功能，條件索引在 web應用中 很重要。
PG有極其強悍的 SQL編程能力（9.x 圖靈完備，支持遞歸！），有非常豐富的統計函數和統計語法支持，比如分析函數（Oracle的叫法，PG里叫Window函數），還可以用多種語言來寫存儲過程，對於 R的支持也很好。這一點MySQL就差很多，很多分析功能都不支持，騰訊內部的存儲主要是 MySQL，但是數據分析主要是 Hadoop+ PgSQL。
PG的有多種集群架構可以選擇，plproxy可以之hi語句級的鏡像或分片，slony可以進行欄位級的同步配置，standby 可以構建 WAL文件級或流式的讀寫分離集群，同步頻率和集群策略調整方便。
一般關系型資料庫字元串有長度限制 8k 左右，無限長 TEXT類型的功能受限，只能作為外部大數據訪問。而 PG 的 TEXT 類型 可以直接訪問且無長度限制， SQL語法內置 正則表達式，可以索引，還可以全文檢索，或使用 xml xpath。用 PG的話，文檔資料庫都可以省了。
PgSQL對於 numa 架構的支持比 MySQL強一些，比 MySQL對於讀的性能更好一些， PgSQL提交可以完全非同步提交，而 MySQL的內存表不夠實用（因為表鎖的原因）。
pgsql除了存儲正常的數據類型外，還支持存儲
array，不管是一維數組還是多維數組均支持。
json和jsonb，相比使用 text存儲要高效很多。
json和 jsonb在更高的層面上看起來幾乎是一樣的，但是存儲實現上是不同的。
json存儲完的文本，json列會每次都解析存儲的值，它不支持索引，但 可以為創建表達式索引。
jsonb存儲的二進制格式，避免了重新解析數據結構。它支持索引，這意味著 可以不使用指定索引就能查詢任何路徑。
當我們比較寫入數據速度時，由於數據存儲 的方式的原因，jsonb會比 json 稍微的慢一點。json列會每次都 解析存儲的值，這意味著鍵的順序要和輸入的 時候一樣。但是 jsonb不同，以二進制格式存儲且不保證鍵的順序。因此如果有軟體需要依賴鍵的順序，jsonb可能不是最佳選擇。使用 jsonb的優勢還在於可以輕易的整合關系型數據和非關系型 數據 ，PostgreSQL對於 mongodb這類資料庫是一個不小的威脅，畢竟如果一個表中只有一列數據的類型是半結構化的，沒有必要為了遷就它而整個表的設計都採用 schemaless的結構。
1. CPU限制
PGSQL
沒有CPU核心數限制，有多少CPU核就用多少
MySQL
能用128核CPU，超過128核用不上
2. 配置文件參數
PGSQL
一共有255個參數，用到的大概是80個，參數比較穩定，用上個大版本配置文件也可以啟動當前大版本資料庫
MySQL
一共有707個參數，用到的大概是180個，參數不斷增加，就算小版本也會增加參數，大版本之間會有部分參數不兼容情況
3. 第三方工具依賴情況
PGSQL
只有高可用集群需要依靠第三方中間件，例如：patroni+etcd、repmgr
MySQL
大部分操作都要依靠percona公司的第三方工具（percona-toolkit，XtraBackup），工具命令太多，學習成本高，高可用集群也需要第三方中間件，官方MGR集群還沒成熟
4. 高可用主從復制底層原理
PGSQL
物理流復制，屬於物理復制，跟SQL Server鏡像/AlwaysOn一樣，嚴格一致，沒有任何可能導致不一致，性能和可靠性上，物理復制完勝邏輯復制，維護簡單
MySQL
主從復制，屬於邏輯復制，（sql_log_bin、binlog_format等參數設置不正確都會導致主從不一致）
大事務並行復制效率低，對於重要業務，需要依賴 percona-toolkit的pt-table-checksum和pt-table-sync工具定期比較和修復主從一致
主從復制出錯嚴重時候需要重搭主從
MySQL的邏輯復制並不阻止兩個不一致的資料庫建立復制關系
5. 從庫只讀狀態
PGSQL
系統自動設置從庫默認只讀，不需要人工介入，維護簡單
MySQL
從庫需要手動設置參數super_read_only=on，讓從庫設置為只讀，super_read_only參數有bug，鏈接：https://jiahao..com/s?id=1636644783594388753&wfr=spider&for=pc
6. 版本分支
PGSQL
只有社區版，沒有其他任何分支版本，PGSQL官方統一開發，統一維護，社區版有所有功能，不像SQL Server和MySQL有標准版、企業版、經典版、社區版、開發版、web版之分
國內外還有一些基於PGSQL做二次開發的資料庫廠商，例如：Enterprise DB、瀚高資料庫等等，當然這些只是二次開發並不算獨立分支
MySQL
由於歷史原因，分裂為三個分支版本，MariaDB分支、Percona分支 、Oracle官方分支，發展到目前為止各個分支基本互相不兼容
Oracle官方分支還有版本之分，分為標准版、企業版、經典版、社區版
7. SQL特性支持
PGSQL
SQL特性支持情況支持94種，SQL語法支持最完善，例如：支持公用表表達式（WITH查詢）
MySQL
SQL特性支持情況支持36種，SQL語法支持比較弱，例如：不支持公用表表達式（WITH查詢）
關於SQL特性支持情況的對比，可以參考：http://www.sql-workbench.net/dbms_comparison.html
8. 主從復制安全性
PGSQL
同步流復制、強同步（remote apply)、高安全，不會丟數據
PGSQL同步流復制：所有從庫宕機，主庫會罷工，主庫無法自動切換為非同步流復制（非同步模式），需要通過增加從庫數量來解決，一般生產環境至少有兩個從庫
手動解決：在PG主庫修改參數synchronous_standby_names =''，並執行命令： pgctl reload ，把主庫切換為非同步模式
主從數據完全一致是高可用切換的第一前提，所以PGSQL選擇主庫罷工也是可以理解
MySQL
增強半同步復制 ，mysql5.7版本增強半同步才能保證主從復制時候不丟數據
mysql5.7半同步復制相關參數：
參數rpl_semi_sync_master_wait_for_slave_count 等待至少多少個從庫接收到binlog，主庫才提交事務，一般設置為1，性能最高
參數rpl_semi_sync_master_timeout 等待多少毫秒，從庫無回應自動切換為非同步模式，一般設置為無限大，不讓主庫自動切換為非同步模式
所有從庫宕機，主庫會罷工，因為無法收到任何從庫的應答包
手動解決：在MySQL主庫修改參數rpl_semi_sync_master_wait_for_slave_count=0
9. 多欄位統計信息
PGSQL
支持多欄位統計信息
MySQL
不支持多欄位統計信息
10. 索引類型
PGSQL
多種索引類型（btree , hash , gin , gist , sp-gist , brin , bloom , rum , zombodb , bitmap，部分索引，表達式索引）
MySQL
btree 索引，全文索引（低效），表達式索引(需要建虛擬列)，hash 索引只在內存表
11. 物理表連接演算法
PGSQL
支持 nested-loop join 、hash join 、merge join
MySQL
只支持 nested-loop join
12. 子查詢和視圖性能
PGSQL
子查詢，視圖優化，性能比較高
MySQL
視圖謂詞條件下推限制多，子查詢上拉限制多
13. 執行計劃即時編譯
PGSQL
支持 JIT 執行計劃即時編譯，使用LLVM編譯器
MySQL
不支持執行計劃即時編譯
14. 並行查詢
PGSQL
並行查詢（多種並行查詢優化方法），並行查詢一般多見於商業資料庫，是重量級功能
MySQL
有限，只支持主鍵並行查詢
15. 物化視圖
PGSQL
支持物化視圖
MySQL
不支持物化視圖
16. 插件功能
PGSQL
支持插件功能，可以豐富PGSQL的功能，GIS地理插件，時序資料庫插件， 向量化執行插件等等
MySQL
不支持插件功能
17. check約束
PGSQL
支持check約束
MySQL
不支持check約束，可以寫check約束，但存儲引擎會忽略它的作用，因此check約束並不起作用（mariadb 支持）
18. gpu 加速SQL
PGSQL
可以使用gpu 加速SQL的執行速度
MySQL
不支持gpu 加速SQL 的執行速度
19. 數據類型
PGSQL
數據類型豐富，如 ltree，hstore，數組類型，ip類型，text類型，有了text類型不再需要varchar，text類型欄位最大存儲1GB
MySQL
數據類型不夠豐富
20. 跨庫查詢
PGSQL
不支持跨庫查詢，這個跟Oracle 12C以前一樣
MySQL
可以跨庫查詢
21. 備份還原
PGSQL
備份還原非常簡單，時點還原操作比SQL Server還要簡單，完整備份+wal歸檔備份（增量）
假如有一個三節點的PGSQL主從集群，可以隨便在其中一個節點做完整備份和wal歸檔備份
MySQL
備份還原相對不太簡單，完整備份+binlog備份（增量）
完整備份需要percona的XtraBackup工具做物理備份，MySQL本身不支持物理備份
時點還原操作步驟繁瑣復雜
22. 性能視圖
PGSQL
需要安裝pg_stat_statements插件，pg_stat_statements插件提供了豐富的性能視圖：如：等待事件，系統統計信息等
不好的地方是，安裝插件需要重啟資料庫，並且需要收集性能信息的資料庫需要執行一個命令：create extension pg_stat_statements命令
否則不會收集任何性能信息，比較麻煩
MySQL
自帶PS庫，默認很多功能沒有打開，而且打開PS庫的性能視圖功能對性能有影響（如：內存佔用導致OOM bug）
23. 安裝方式
PGSQL
有各個平台的包rpm包，deb包等等，相比MySQL缺少了二進制包，一般用源碼編譯安裝，安裝時間會長一些，執行命令多一些
MySQL
有各個平台的包rpm包，deb包等等，源碼編譯安裝、二進制包安裝，一般用二進制包安裝，方便快捷
24. DDL操作
PGSQL
加欄位、可變長欄位類型長度改大不會鎖表，所有的DDL操作都不需要藉助第三方工具，並且跟商業資料庫一樣，DDL操作可以回滾，保證事務一致性
MySQL
由於大部分DDL操作都會鎖表，例如加欄位、可變長欄位類型長度改大，所以需要藉助percona-toolkit裡面的pt-online-schema-change工具去完成操作
將影響減少到最低，特別是對大表進行DDL操作
DDL操作不能回滾
25. 大版本發布速度
PGSQL
PGSQL每年一個大版本發布，大版本發布的第二年就可以上生產環境，版本迭代速度很快
PGSQL 9.6正式版推出時間：2016年
PGSQL 10 正式版推出時間：2017年
PGSQL 11 正式版推出時間：2018年
PGSQL 12 正式版推出時間：2019年
MySQL
MySQL的大版本發布一般是2年~3年，一般大版本發布後的第二年才可以上生產環境，避免有坑，版本發布速度比較慢
MySQL5.5正式版推出時間：2010年
MySQL5.6正式版推出時間：2013年
MySQL5.7正式版推出時間：2015年
MySQL8.0正式版推出時間：2018年
26. returning語法
PGSQL
支持returning語法，returning clause 支持 DML 返回 Resultset，減少一次 Client <-> DB Server 交互
MySQL
不支持returning語法
27. 內部架構
PGSQL
多進程架構，並發連接數不能太多，跟Oracle一樣，既然跟Oracle一樣，那麼很多優化方法也是相通的，例如：開啟大頁內存
MySQL
多線程架構，雖然多線程架構，但是官方有限制連接數，原因是系統的並發度是有限的，線程數太多，反而系統的處理能力下降，隨著連接數上升，反而性能下降
一般同時只能處理200 ~300個資料庫連接
28. 聚集索引
PGSQL
不支持聚集索引，PGSQL本身的MVCC的實現機制所導致
MySQL
支持聚集索引
29. 空閑事務終結功能
PGSQL
通過設置 idle_in_transaction_session_timeout 參數來終止空閑事務，比如：應用代碼中忘記關閉已開啟的事務，PGSQL會自動查殺這種類型的會話事務
MySQL
不支持終止空閑事務功能
30. 應付超大數據量
PGSQL
不能應付超大數據量，由於PGSQL本身的MVCC設計問題，需要垃圾回收，只能期待後面的大版本做優化
MySQL
不能應付超大數據量，MySQL自身架構的問題
31. 分布式演進
PGSQL
HTAP資料庫：cockroachDB、騰訊Tbase
分片集群： Postgres-XC、Postgres-XL
MySQL
HTAP資料庫：TiDB
分片集群： 各種各樣的中間件，不一一列舉
32. 資料庫的文件名和命名規律
PGSQL
PGSQL在這方面做的比較不好，DBA不能在操作系統層面（停庫狀態下）看清楚資料庫的文件名和命名規律，文件的數量，文件的大小
一旦操作系統發生文件丟失或硬碟損壞，非常不利於恢復，因為連名字都不知道
PGSQL表數據物理文件的命名/存放規律是： 在一個表空間下面，如果沒有建表空間默認在默認表空間也就是base文件夾下，例如：/data/base/16454/3599
base：默認表空間pg_default所在的物理文件夾
16454：表所在資料庫的oid
3599：就是表對象的oid，當然，一個表的大小超出1GB之後會再生成多個物理文件，還有表的fsm文件和vm文件，所以一個大表實際會有多個物理文件
由於PGSQL的數據文件布局內容太多，大家可以查閱相關資料
當然這也不能全怪PGSQL，作為一個DBA，時刻做好資料庫備份和容災才是正道，做介質恢復一般是萬不得已的情況下才會做
MySQL
資料庫名就是文件夾名，資料庫文件夾下就是表數據文件，但是要注意表名和資料庫名不能有特殊字元或使用中文名，每個表都有對應的frm文件和ibd文件，存儲元數據和表/索引數據，清晰明了，做介質恢復或者表空間傳輸都很方便
33. 許可權設計
PGSQL
PGSQL在許可權設計這塊是比較坑爹，拋開實例許可權和表空間許可權，PGSQL的許可權層次有點像SQL Server，db=》schema=》object
要說許可權，這里要說一下Oracle，用Oracle來類比
在ORACLE 12C之前，實例與資料庫是一對一，也就是說一個實例只能有一個資料庫，不像MySQL和SQL Server一個實例可以有多個資料庫，並且可以隨意跨庫查詢
而PGSQL不能跨庫查詢的原因也是這樣，PGSQL允許建多個資料庫，跟ORACLE類比就是有多個實例（之前說的實例與資料庫是一對一）
一個資料庫相當於一個實例，因為PGSQL允許有多個實例，所以PGSQL單實例不叫一個實例，叫集簇（cluster），集簇這個概念可以查閱PGSQL的相關資料
PGSQL裡面一個實例/資料庫下面的schema相當於資料庫，所以這個schema的概念對應MySQL的database
注意點：正因為是一個資料庫相當於一個實例，PGSQL允許有多個實例/資料庫，所以資料庫之間是互相邏輯隔離的，導致的問題是，不能一次對一個PGSQL集簇下面的所有資料庫做操作
必須要逐個逐個資料庫去操作，例如上面說到的安裝pg_stat_statements插件，如果您需要在PGSQL集簇下面的所有資料庫都做性能收集的話，需要逐個資料庫去執行載入命令
又例如跨庫查詢需要dblink插件或fdw插件，兩個資料庫之間做查詢相當於兩個實例之間做查詢，已經跨越了實例了，所以需要dblink插件或fdw插件，所以道理非常簡單
許可權操作也是一樣逐個資料庫去操作，還有一個就是PGSQL雖然像SQL Server的許可權層次結構db=》schema=》object，但是實際會比SQL Server要復雜一些，還有就是新建的表還要另外授權
在PGSQL裡面，角色和用戶是一樣的，對新手用戶來說有時候會傻傻分不清，也不知道怎麼去用角色，所以PGSQL在許可權設計這一塊確實比較坑爹
MySQL
使用mysql庫下面的5個許可權表去做許可權映射，簡單清晰，唯一問題是缺少許可權角色
user表
db表
host表
tables_priv表
columns_priv表
1. 架構對比
Mysql：多線程
PostgreSql：多進程
多線程架構和多進程架構之間沒有絕對的好壞，例如oracle在unix上是多進程架構，在windows上是多線程架構。
2. 對存儲過程及事務的支持能力
MySql對於無事務的MyISAM表，採用表鎖定，一個長時間運行的查詢很可能會長時間的阻礙，而PostgreSQL不會尊在這種問題。
PostgreSQL支持存儲過程，要比MySql好，具備本地緩存執行計劃的能力。
3. 穩定性及性能
高並發讀寫，負載逼近極限下，PG的性能指標仍可以維持雙曲線甚至對數曲線，到頂峰之後不再下降，而 MySql 明顯出現一個波峰後下滑（5.5版本後Mysql企業版有優化，需要付費）
MySql的InnoDB引擎，可以充分優化利用系統的所有內存，超大內存下PG對內存使用的不那麼充分（需要根據內存情況合理分配）。
4. 高可用
InnoDB的基於回滾實現的 MVCC 機制，對於 PG 新老數據一起放的基於 XID 的 MVCC機制，是占優的。新老數據一起存放，需要定時觸發 VACUUM，會帶來多餘的 IO 和資料庫對象加鎖開銷，引起資料庫整理的並發能力下降。而且 VACUUM 清理不及時，還可能會引發數據膨脹
5. 數據同步方式：
Mysql到現在也是非同步復制，pgsql可以做到同步、非同步、半同步復制。
Mysql同步是基於binlog復制，屬於邏輯復制，類似於oracle golden gate，是基於stream的復制，做到同步很困難，這種方式更加適合非同步復制；
Pgsql的同是基於wal，屬於物理復制，可以做到同步復制。同時，pgsql還提供stream復制。
Mysql的復制可以用多級從庫，但是在9.2之前，PgSql不能用從庫帶從庫。
Pgsql的主從復制屬於物理復制，相對於Mysql基於binlog的邏輯復制，數據的一致性更加可靠，復制性能更高，對主機性能的影響也更小。
6. 許可權控制對比
MySql允許自定義一套不同的數據級、表級和列的許可權，運行指定基於主機的許可權
Mysql的merge表提供了 一個獨特管理多個表的方法。myisampack可以對只讀表進行壓縮，以後仍然可以直接訪問該表中的行。
7. SQL語句支持能力
PG有極其強悍的 SQL 編程能力（9.x 圖靈完備，支持遞歸！），有非常豐富的統計函數和統計語法支持，例如分析函數（Oracle的叫法，PG里叫window函數）
支持用多種語言來寫存儲過程，對於R的支持也很好。這一點上Mysql就差的很遠，很多分析功能都不支持。
PgSql對表名大小寫的處理，只有在Sql語句中，表明加雙引號，才區分大小寫。
在Sql的標准實現上要比Mysql完善，而且功能實現比較嚴謹。
對表連接支持比較完整，優化器的功能比較完整，支持的索引類型很多，復雜查詢能力較強。
Mysql採用索引組織表，這種存儲方式非常適合基於主鍵匹配的查詢、刪改操作，但是對表結果設計存在約束；
Mysql的Join操作的性能非常的差，只支持Nest Join，所以一旦數據量大，性能就非常的差。PostgresSQL除了支持 Nest Join 和 Sort Merge Join，PostgreSQL還支持正則表達式查詢，MySql不支持。
8. 數據類型支持能力
PostgreSQL可以更方便的使用UDF（用戶定義函數）進行擴展。
有豐富的幾何類型，實際上不止集合類型，PG有大量的字典、數組、bitmap等數據類型，因此PG多年來在 GIS 領域處於優勢地位。相比之下Mysql就差很多，instagram就是因為PG的空間數據擴展 PostGIS遠遠強於 MySql的 my spatial 而採用 PgSql的。Mysql中的空間數據類型有4種，分別是 CEOMETRY、POINT、LINESTRING、POLYGON，其空間索引只能在存儲引擎為 MyiSam的表中創建，用SPATIAL關鍵字進行擴展，使得能夠用於創建正規索引類型的語法創建空間索引。創建空間索引的列，必須將其聲明為NOT NULL。不同的存儲親情有差別。MyISAM和InnoDB 都支持 spatial extensions，但差別在於：如果使用MyISAM，可以建立 spatial index，而 InnoDB是不支持的。
pgsql對json支持比較好，還有很逆天的fdw功能，就是把別的資料庫中的表當自己的用。
pgsql的欄位類型支持的多，有很多mysql沒有的類型，但是實際中有時候用到。
一半關系型資料庫的字元串長度8k左右，無限長的 TEXT 類型的功能受限，只能作為外部帶數據訪問。而 PG 的 TEXT 類型可以直接訪問，SQL 語法內置正則表達式，可以索引，還可以全文檢索，或使用 xml xpath。用 PG 的話，文檔資料庫都可以省了。
postgresql 有函數，用於報表、統計很方便
PG支持 R-Trees這樣可擴展的索引類型，可以方便的處理一些特殊數據。
PG可以使用函數和條件所以，使得資料庫的調優非常靈活，mysql就沒有這個功能，條件索引在web應用中很重要。
9. 如可過程容錯能力
大批量數據入庫，PostgreSql要求所有的數據必須完全滿足要求，有一條錯誤，整個數據入庫過程失敗。MySql無此問題。
10. 表組織方式
pgsql用繼承的方式實現分區表，讓分區表的使用不方便且性能差，這點比不上mysql。
pg主表採用堆表存放，MySQL採用索引組織表，能夠支持比MySql更大的數據量。
MySql分區表的實現要優於PG的基於繼承表的分區實現，主要體現在分區個數達到成千上萬後的處理性能差異很大。
11. 開發結構
對於web應用來所，mysql 5.6 的內置 MC API 功能很好用，PgSQL差一些。
PG的「無鎖定」特性非常突出，甚至包括 vacuum 這樣的整理數據空間的操作，這個和 PGSQL的 MVCC 實現有關系。
好文要頂 關注我 收藏該文
茄子777
粉絲 - 0 關注 - 0
+加關注
00
« 上一篇： 多線程中的wait與join
» 下一篇： 負載均衡相關
posted @ 2022-11-02 16:20 茄子777 閱讀(55) 評論(0) 編輯 收藏 舉報
刷新評論刷新頁面返回頂部
登錄後才能查看或發表評論，立即 登錄 或者 逛逛 博客園首頁
【推薦】阿里雲新人特惠，爆款雲伺服器2核4G低至0.46元/天
【推薦】雙十一同價！騰訊雲雲伺服器搶先購，低至4.2元/月
編輯推薦：
· 一個有趣的 nginx HTTP 400 響應問題分析
· 誰說.NET沒有GC調優？只改一行代碼就讓程序不再佔用內存
· 為什麼標准庫的模板變數都是 inline 的
· .net 如何優雅的使用 EFCore
· 在 C# 中使用 Halcon 開發視覺檢測程序
閱讀排行：
· Entity Framework Core 7中高效地進行批量數據插入
· 除了 filter 還有什麼置灰網站的方式？
· 快速繪制流程圖「GitHub 熱點速覽 v.22.47」
· 使用.NET7和C#11打造最快的序列化程序-以MemoryPack為例
· 私藏！資深數據專家SQL效率優化技巧 ⛵
㈡ 15 個開源的頂級人工智慧工具
斯坦福的專家在人工智慧報告中得出的結論："越來越強大的人工智慧應用，可能會對我們的 社會 和經濟產生深遠的積極影響，這將出現在從現在到2030年的時間段里。"
以下這些開源人工智慧應用都處於人工智慧研究的最前沿。
1.Caffe
它是由賈揚清在加州大學伯克利分校的讀博時創造的，Caffe是一個基於表達體系結構和可擴展代碼的深度學習框架。使它聲名鵲起的是它的速度，這讓它受到研究人員和企業用戶的歡迎。根據其網站所言，它可以在一天之內只用一個NVIDIA K40 GPU處理6000萬多個圖像。它是由伯克利視野和學習中心（BVLC）管理的，並且由NVIDIA和亞馬遜等公司資助來支持它的發展。
2. CNTK
它是計算機網路工具包（Computational Network Tookit）的縮寫，CNTK是一個微軟的開源人工智慧工具。不論是在單個CPU、單個GPU、多個GPU或是擁有多個GPU的多台機器上它都有優異的表現。微軟主要用它做語音識別的研究，但是它在機器翻譯、圖像識別、圖像字幕、文本處理、語言理解和語言建模方面都有著良好的應用。
3.Deeplearning4j
Deeplearning4j是一個java虛擬機（JVM）的開源深度學習庫。它運行在分布式環境並且集成在Hadoop和Apache Spark中。這使它可以配置深度神經網路，並且它與Java、Scala和其他JVM語言兼容。
4.DMTK
DMTK分布式集齊學習工具（Distributed Machine Learning Toolkit）的縮寫，和CNTK一樣，是微軟的開源人工智慧工具。作為設計用於大數據的應用程序，它的目標是更快的訓練人工智慧系統。它包括三個主要組件：DMTK框架、LightLDA主題模型演算法和分布式（多義）字嵌入演算法。為了證明它的速度，微軟聲稱在一個八集群的機器上，它能夠"用100萬個主題和1000萬個單詞的詞彙表（總共10萬億參數）訓練一個主題模型，在一個文檔中收集1000億個符號，"。這一成績是別的工具無法比擬的。
5.H20
相比起科研，H2O更注重將AI服務於企業用戶，因此H2O有著大量的公司客戶，比如第一資本金融公司、思科、Nielsen Catalina、PayPal和泛美都是它的用戶。它聲稱任何人都可以利用機器學習和預測分析的力量來解決業務難題。它可以用於預測建模、風險和欺詐分析、保險分析、廣告技術、醫療保健和客戶情報。
它有兩種開源版本：標准版H2O和Sparking Water版，它被集成在Apache Spark中。也有付費的企業用戶支持。
6.Mahout
它是Apache基金會項目，Mahout是一個開源機器學習框架。根據它的網站所言，它有著三個主要的特性：一個構建可擴展演算法的編程環境、像Spark和H2O一樣的預制演算法工具和一個叫Samsara的矢量數學實驗環境。使用Mahout的公司有Adobe、埃森哲咨詢公司、Foursquare、英特爾、領英、Twitter、雅虎和其他許多公司。其網站列了出第三方的專業支持。
7.MLlib
由於其速度，Apache Spark成為一個最流行的大數據處理工具。MLlib是Spark的可擴展機器學習庫。它集成了Hadoop並可以與NumPy和R進行交互操作。它包括了許多機器學習演算法如分類、回歸、決策樹、推薦、集群、主題建模、功能轉換、模型評價、ML管道架構、ML持久、生存分析、頻繁項集和序列模式挖掘、分布式線性代數和統計。
8.NuPIC
由Numenta公司管理的NuPIC是一個基於分層暫時記憶理論的開源人工智慧項目。從本質上講，HTM試圖創建一個計算機系統來模仿人類大腦皮層。他們的目標是創造一個"在許多認知任務上接近或者超越人類認知能力"的機器。
除了開源許可，Numenta還提供NuPic的商業許可協議，並且它還提供技術專利的許可證。
9.OpenNN
作為一個為開發者和科研人員設計的具有高級理解力的人工智慧，OpenNN是一個實現神經網路演算法的c++編程庫。它的關鍵特性包括深度的架構和快速的性能。其網站上可以查到豐富的文檔，包括一個解釋了神經網路的基本知識的入門教程
10.OpenCyc
由Cycorp公司開發的OpenCyc提供了對Cyc知識庫的訪問和常識推理引擎。它擁有超過239,000個條目，大約2,093,000個三元組和大約69,000 owl：這是一種類似於鏈接到外部語義庫的命名空間。它在富領域模型、語義數據集成、文本理解、特殊領域的專家系統和 游戲 AI中有著良好的應用。該公司還提供另外兩個版本的Cyc：一個可免費的用於科研但是不開源，和一個提供給企業的但是需要付費。
11.Oryx 2
構建在Apache Spark和Kafka之上的Oryx 2是一個專門針對大規模機器學習的應用程序開發框架。它採用一個獨特的三層λ架構。開發者可以使用Orys 2創建新的應用程序，另外它還擁有一些預先構建的應用程序可以用於常見的大數據任務比如協同過濾、分類、回歸和聚類。大數據工具供應商Cloudera創造了最初的Oryx 1項目並且一直積極參與持續發展。
12.PredictionIO
今年的二月，Salesforce收購了PredictionIO，接著在七月，它將該平台和商標貢獻給Apache基金會，Apache基金會將其列為孵育計劃。所以當Salesforce利用PredictionIO技術來提升它的機器學習能力時，成效將會同步出現在開源版本中。它可以幫助用戶創建帶有機器學習功能的預測引擎，這可用於部署能夠實時動態查詢的Web服務。
13.SystemML
最初由IBM開發，SystemML現在是一個Apache大數據項目。它提供了一個高度可伸縮的平台，可以實現高等數學運算，並且它的演算法用R或一種類似python的語法寫成。企業已經在使用它來跟蹤 汽車 維修客戶服務、規劃機場交通和連接 社會 媒體數據與銀行客戶。它可以在Spark或Hadoop上運行。
14.TensorFlow
TensorFlow是一個谷歌的開源人工智慧工具。它提供了一個使用數據流圖進行數值計算的庫。它可以運行在多種不同的有著單或多CPU和GPU的系統，甚至可以在移動設備上運行。它擁有深厚的靈活性、真正的可移植性、自動微分功能，並且支持Python和c++。它的網站擁有十分詳細的教程列表來幫助開發者和研究人員沉浸於使用或擴展他的功能。
15.Torch
Torch將自己描述為："一個優先使用GPU的擁有機器學習演算法廣泛支持的科學計算框架"，它的特點是靈活性和速度。此外，它可以很容易的通過軟體包用於機器學習、計算機視覺、信號處理、並行處理、圖像、視頻、音頻和網路等方面。它依賴一個叫做LuaJIT的腳本語言，而LuaJIT是基於Lua的。
歡迎關注~
微信公眾號： IT百戰程序員 ，免費提供人工智慧、大數據、雲計算等資料～～不管你在地球哪個方位，歡迎你的關注！
㈢ GPU演算法工程師是做什麼的
一、演算法工程師簡介（通常是月薪15k以上，年薪18萬以上，只是一個概數，具體薪資可以到招聘網站如拉鉤，獵聘網上看看）演算法工程師目前是一個高端也是相對緊缺的職位；演算法工程師包括音/視頻演算法工程師（通常統稱為語音/視頻/圖形開發工程師）、圖像處理演算法工程師、計算機視覺演算法工程師、通信基帶演算法工程師、信號演算法工程師、射頻/通信演算法工程師、自然語言演算法工程師、數據挖掘演算法工程師、搜索演算法工程師、控制演算法工程師（雲台演算法工程師，飛控演算法工程師，機器人控制演算法）、導航演算法工程師（@之介感謝補充）、其他【其他一切需要復雜演算法的行業】專業要求：計算機、電子、通信、數學等相關專業；學歷要求：本科及其以上的學歷，大多數是碩士學歷及其以上；語言要求：英語要求是熟練，基本上能閱讀國外專業書刊，做這一行經常要讀論文；必須掌握計算機相關知識，熟練使用模擬工具MATLAB等，必須會一門編程語言。演算法工程師的技能樹（不同方向差異較大，此處僅供參考）1 機器學習2 大數據處理：熟悉至少一個分布式計算框架Hadoop/Spark/Storm/ map-rece/MPI3 數據挖掘4 扎實的數學功底5 至少熟悉C/C++或者Java，熟悉至少一門編程語言例如java/python/R加分項：具有較為豐富的項目實踐經驗（不是水論文的哪種）二、演算法工程師大致分類與技術要求（一）圖像演算法/計算機視覺工程師類包括圖像演算法工程師，圖像處理工程師，音/視頻處理演算法工程師，計算機視覺工程師要求l 專業：計算機、數學、統計學相關專業；l 技術領域：機器學習，模式識別l 技術要求：（1） 精通DirectX HLSL和OpenGL GLSL等shader語言，熟悉常見圖像處理演算法GPU實現及優化；（2） 語言：精通C/C++；（3） 工具：Matlab數學軟體，CUDA運算平台，VTK圖像圖形開源軟體【醫學領域：ITK，醫學圖像處理軟體包】（4） 熟悉OpenCV/OpenGL/Caffe等常用開源庫；（5） 有人臉識別，行人檢測，視頻分析，三維建模，動態跟蹤，車識別，目標檢測跟蹤識別經歷的人優先考慮；（6） 熟悉基於GPU的演算法設計與優化和並行優化經驗者優先；（7） 【音/視頻領域】熟悉H.264等視頻編解碼標准和FFMPEG，熟悉rtmp等流媒體傳輸協議，熟悉視頻和音頻解碼演算法，研究各種多媒體文件格式，GPU加速；應用領域：（1） 互聯網：如美顏app（2） 醫學領域：如臨床醫學圖像（3） 汽車領域（4） 人工智慧相關術語：（1） OCR：OCR （Optical Character Recognition，光學字元識別）是指電子設備（例如掃描儀或數碼相機）檢查紙上列印的字元，通過檢測暗、亮的模式確定其形狀，然後用字元識別方法將形狀翻譯成計算機文字的過程（2） Matlab：商業數學軟體；（3） CUDA： (Compute Unified Device Architecture)，是顯卡廠商NVIDIA推出的運算平台（由ISA和GPU構成）。 CUDA™是一種由NVIDIA推出的通用並行計算架構，該架構使GPU能夠解決復雜的計算問題（4） OpenCL: OpenCL是一個為異構平台編寫程序的框架，此異構平台可由CPU，GPU或其他類型的處理器組成。（5） OpenCV：開源計算機視覺庫；OpenGL：開源圖形庫；Caffe：是一個清晰，可讀性高，快速的深度學習框架。（6） CNN：（深度學習）卷積神經網路（Convolutional Neural Network）CNN主要用來識別位移、縮放及其他形式扭曲不變性的二維圖形。（7） 開源庫：指的是計算機行業中對所有人開發的代碼庫，所有人均可以使用並改進代碼演算法。（二）機器學習工程師包括機器學習工程師要求l 專業：計算機、數學、統計學相關專業；l 技術領域：人工智慧，機器學習l 技術要求：（1） 熟悉Hadoop/Hive以及Map-Rece計算模式，熟悉Spark、Shark等尤佳；（2） 大數據挖掘；（3） 高性能、高並發的機器學習、數據挖掘方法及架構的研發；應用領域：（1）人工智慧，比如各類模擬、擬人應用，如機器人（2）醫療用於各類擬合預測（3）金融高頻交易（4）互聯網數據挖掘、關聯推薦（5）無人汽車，無人機相關術語：（1） Map-Rece：MapRece是一種編程模型，用於大規模數據集（大於1TB）的並行運算。概念"Map（映射）"和"Rece（歸約）"，是它們的主要思想，都是從函數式編程語言里借來的，還有從矢量編程語言里借來的特性。（三）自然語言處理工程師包括自然語言處理工程師要求l 專業：計算機相關專業；l 技術領域：文本資料庫l 技術要求：（1） 熟悉中文分詞標注、文本分類、語言模型、實體識別、知識圖譜抽取和推理、問答系統設計、深度問答等NLP 相關演算法；（2） 應用NLP、機器學習等技術解決海量UGC的文本相關性；（3） 分詞、詞性分析、實體識別、新詞發現、語義關聯等NLP基礎性研究與開發；（4） 人工智慧，分布式處理Hadoop；（5） 數據結構和演算法；應用領域：口語輸入、書面語輸入、語言分析和理解、語言生成、口語輸出技術、話語分析與對話、文獻自動處理、多語問題的計算機處理、多模態的計算機處理、信息傳輸與信息存儲 、自然語言處理中的數學方法、語言資源、自然語言處理系統的評測。相關術語：（2） NLP：人工智慧的自然語言處理，NLP (Natural Language Processing) 是人工智慧（AI）的一個子領域。NLP涉及領域很多，最令我感興趣的是「中文自動分詞」（Chinese word segmentation）：結婚的和尚未結婚的【計算機中卻有可能理解為結婚的「和尚「】（四）射頻/通信/信號演算法工程師類包括3G/4G無線通信演算法工程師， 通信基帶演算法工程師，DSP開發工程師（數字信號處理），射頻通信工程師，信號演算法工程師要求l 專業：計算機、通信相關專業；l 技術領域：2G、3G、4G，BlueTooth（藍牙），WLAN，無線移動通信, 網路通信基帶信號處理l 技術要求：（1） 了解2G，3G，4G，BlueTooth，WLAN等無線通信相關知識，熟悉現有的通信系統和標准協議，熟悉常用的無線測試設備；（2） 信號處理技術，通信演算法；（3） 熟悉同步、均衡、信道解碼等演算法的基本原理；（4） 【射頻部分】熟悉射頻前端晶元，扎實的射頻微波理論和測試經驗，熟練使用射頻電路模擬工具（如ADS或MW或Ansoft）；熟練使用cadence、altium designer PCB電路設計軟體；（5） 有扎實的數學基礎，如復變函數、隨機過程、數值計算、矩陣論、離散數學應用領域：通信VR【用於快速傳輸視頻圖像，例如樂客靈境VR公司招募的通信工程師（數據編碼、流數據）】物聯網，車聯網導航，軍事，衛星，雷達相關術語：（1） 基帶信號：指的是沒有經過調制（進行頻譜搬移和變換）的原始電信號。（2） 基帶通信（又稱基帶傳輸）：指傳輸基帶信號。進行基帶傳輸的系統稱為基帶傳輸系統。傳輸介質的整個信道被一個基帶信號佔用.基帶傳輸不需要數據機，設備化費小，具有速率高和誤碼率低等優點,.適合短距離的數據傳輸，傳輸距離在100米內，在音頻市話、計算機網路通信中被廣泛採用。如從計算機到監視器、列印機等外設的信號就是基帶傳輸的。大多數的區域網使用基帶傳輸，如乙太網、令牌環網。（3） 射頻：射頻（RF）是Radio Frequency的縮寫，表示可以輻射到空間的電磁頻率（電磁波），頻率范圍從300KHz～300GHz之間（因為其較高的頻率使其具有遠距離傳輸能力）。射頻簡稱RF射頻就是射頻電流，它是一種高頻交流變化電磁波的簡稱。每秒變化小於1000次的交流電稱為低頻電流，大於10000次的稱為高頻電流，而射頻就是這樣一種高頻電流。高頻(大於10K)；射頻（300K-300G）是高頻的較高頻段；微波頻段（300M-300G）又是射頻的較高頻段。【有線電視就是用射頻傳輸方式】（4） DSP：數字信號處理，也指數字信號處理晶元（五）數據挖掘演算法工程師類包括推薦演算法工程師，數據挖掘演算法工程師要求l 專業：計算機、通信、應用數學、金融數學、模式識別、人工智慧；l 技術領域：機器學習，數據挖掘l 技術要求：（1） 熟悉常用機器學習和數據挖掘演算法，包括但不限於決策樹、Kmeans、SVM、線性回歸、邏輯回歸以及神經網路等演算法；（2） 熟練使用SQL、Matlab、Python等工具優先；（3） 對Hadoop、Spark、Storm等大規模數據存儲與運算平台有實踐經驗【均為分布式計算框架】（4） 數學基礎要好，如高數，統計學，數據結構l 加分項：數據挖掘建模大賽；應用領域（1） 個性化推薦（2） 廣告投放（3） 大數據分析相關術語Map-Rece：MapRece是一種編程模型，用於大規模數據集（大於1TB）的並行運算。概念"Map（映射）"和"Rece（歸約）"，是它們的主要思想，都是從函數式編程語言里借來的，還有從矢量編程語言里借來的特性。（六）搜索演算法工程師要求l 技術領域：自然語言l 技術要求：（1） 數據結構，海量數據處理、高性能計算、大規模分布式系統開發（2） hadoop、lucene（3） 精通Lucene/Solr/Elastic Search等技術，並有二次開發經驗（4） 精通Lucene/Solr/Elastic Search等技術，並有二次開發經驗；（5） 精通倒排索引、全文檢索、分詞、排序等相關技術；（6） 熟悉Java，熟悉Spring、MyBatis、Netty等主流框架；（7） 優秀的資料庫設計和優化能力，精通MySQL資料庫應用 ；（8） 了解推薦引擎和數據挖掘和機器學習的理論知識，有大型搜索應用的開發經驗者優先。（七）控制演算法工程師類包括了雲台控制演算法，飛控控制演算法，機器人控制演算法要求l 專業：計算機，電子信息工程，航天航空，自動化l 技術要求：（1） 精通自動控制原理（如PID）、現代控制理論，精通組合導航原理，姿態融合演算法，電機驅動，電機驅動（2） 卡爾曼濾波，熟悉狀態空間分析法對控制系統進行數學模型建模、分析調試；l 加分項：有電子設計大賽，機器人比賽，robocon等比賽經驗，有硬體設計的基礎；應用領域（1）醫療/工業機械設備（2）工業機器人（3）機器人（4）無人機飛控、雲台控制等（八）導航演算法工程師要求l 專業：計算機，電子信息工程，航天航空，自動化l 技術要求（以公司職位JD為例）公司一（1）精通慣性導航、激光導航、雷達導航等工作原理；（2）精通組合導航演算法設計、精通卡爾曼濾波演算法、精通路徑規劃演算法；（3）具備導航方案設計和實現的工程經驗；（4）熟悉C/C++語言、熟悉至少一種嵌入式系統開發、熟悉Matlab工具；公司二（1）熟悉基於視覺信息的SLAM、定位、導航演算法，有1年以上相關的科研或項目經歷；（2）熟悉慣性導航演算法，熟悉IMU與視覺信息的融合;應用領域無人機、機器人等。
㈣ nvidia/cuda 公開源中的devel和runtime有什麼區別
從很多方面來看，CUDA和OpenCL的關系都和DirectX與OpenGL的關系很相像。如同DirectX和OpenGL一樣，CUDA和OpenCL中，前者是配備完整工具包、針對單一供應商(NVIDIA)的成熟的開發平台，後者是一個開放的標准。
雖然兩者抱著相同的目標：通用並行計算。但是CUDA僅僅能夠在NVIDIA的GPU硬體上運行，而OpenCL的目標是面向任何一種Massively Parallel Processor，期望能夠對不同種類的硬體給出一個相同的編程模型。由於這一根本區別，二者在很多方面都存在不同：
1）開發者友好程度。CUDA在這方面顯然受更多開發者青睞。原因在於其統一的開發套件(CUDA Toolkit, NVIDIA GPU Computing SDK以及NSight等等)、非常豐富的庫(cuFFT, cuBLAS, cuSPARSE, cuRAND, NPP, Thrust)以及NVCC(NVIDIA的CUDA編譯器)所具備的PTX(一種SSA中間表示，為不同的NVIDIA GPU設備提供一套統一的靜態ISA)代碼生成、離線編譯等更成熟的編譯器特性。相比之下，使用OpenCL進行開發，只有AMD對OpenCL的驅動相對成熟。
2）跨平台性和通用性。這一點上OpenCL佔有很大優勢（這也是很多National Laboratory使用OpenCL進行科學計算的最主要原因）。OpenCL支持包括ATI,NVIDIA,Intel,ARM在內的多類處理器，並能支持運行在CPU的並行代碼，同時還獨有Task-Parallel Execution Mode，能夠更好的支持Heterogeneous Computing。這一點是僅僅支持數據級並行並僅能在NVIDIA眾核處理器上運行的CUDA無法做到的。
3）市場佔有率。作為一個開放標准，缺少背後公司的推動，OpenCL顯然沒有占據通用並行計算的主流市場。NVIDIA則憑借CUDA在科學計算、生物、金融等領域的推廣牢牢把握著主流市場。再次想到OpenGL和DirectX的對比，不難發現公司推廣的高效和非盈利機構/標准委員會的低效(抑或謹慎，想想C++0x)。
很多開發者都認為，由於目前獨立顯卡市場的萎縮、新一代處理器架構(AMD的Graphics Core Next (GCN)、Intel的Sandy Bridge以及Ivy Bridge)以及新的SIMD編程模型(Intel的ISPC等)的出現，未來的通用並行計算市場會有很多不確定因素，CUDA和OpenCL都不是終點，我期待未來會有更好的並行編程模型的出現(當然也包括CUDA和OpenCL，如果它們能夠持續發展下去)。