一、有沒有什么基于postgresql的newsql

只關心外部接口的話：CockroachDB, YugaByte DB。降低點要求的話，比如MPP數據庫：開源的Greenplum，擴容可以在線進行，但是需要人工介入。最“官方”的的版本應該是 PostgreSQL-XL，也是更新的比較及時的橫向擴展版本，基本能跟上主流版本升級。

重點介紹一下CockroachDB：

說明：

構建于事務處理及強一致性KV存儲上的分布式SQL數據庫，支持水平擴展、自動容錯處理、強一致性事務，并且提供SQL接口用于數據處理，是Google?Spanner/F1的開源實現。?CockroachDB適用于應用對數據要求精確、可靠、完全正確的場景，支持自動復制、均勻分布、基于極小配置的數據恢復，可用于分布式的、可復制的聯機事務處理（OLTP），多數據中心的部署，私有云的基礎構建，它不適用于讀少寫多的場景，可以用內存數據庫來代替，也不適用于復雜的join查詢，重量級的數據分析及聯機分析處理（OLAP）。

特性：

支持PostgreSQL

對標準SQL支持較完善

較穩定

延伸閱讀：

二、TiDB和Cockroach之間的區別

1.用戶界面和生態系統盡管TiDB和CockroachDB都支持SQL，但TiDB與MySQL協議兼容，而Cockroach選擇PostgreSQL。您可以使用任何MySQL客戶端直接連接到TiDB服務器。

2.體系結構整個TiDB項目在邏輯上分為兩部分：無狀態SQL層（TiDB）和分布式存儲層（TiKV）。由于TiDB建立在TiKV之上，開發人員可以根據自己的業務自由選擇使用TiDB或TiKV。如果您只需要分布式鍵值數據庫，則可以單獨使用TiKV以獲得更高的性能和更低的延遲。

總之，我們的系統是高度分層和模塊化的，而CockroachDB是一個P2P系統。我們系統的設計導致我們使用兩種編程語言：Go?for?TiDB和Rust?for?TiKV以提高存儲性能。

并且受益于高度分層的架構，我們構建了另一個項目[1]，以便在TiDB?/?TiKV之上運行Apache?Spark來回答復雜的OLAP查詢。它利用了Spark平臺和分布式TiKV集群的優勢。

3.事務模型盡管CockroachDB和TiDB都支持ACID事務，但TiDB使用了Google的Percolator引入的模型。該模型的關鍵特性是它需要一個獨立的時間戳分配器。與Spanner一樣，TiDB中的每個事務都有一個時間戳來隔離不同的事務。

CockroachDB使用的模型類似于Google在其論文中描述的TrueTime?API。然而，與Google不同，CockroachDB沒有構建原子鐘和GPS接收器來保持不同數據中心的時間一致。相反，它使用NTP進行時鐘同步，這導致了不確定錯誤的問題。為了解決這個問題，CockroachDB采用了混合邏輯時鐘（HLC）算法。

4.編程語言TiDB使用Go作為SQL層，使用Rust作為存儲引擎層。由于Go具有垃圾收集器（GC）和運行時，我們認為調整性能將花費我們幾天的時間。因此，我們對TiKV使用Rust，一種靜態語言。它的表現要好得多。CockroachDB只使用Go。