不知道業(yè)務(wù)具體情況如何，數(shù)據(jù)量如何，處在哪一種場景下。小T也是在數(shù)據(jù)庫行業(yè)的，我們做的是時(shí)序數(shù)據(jù)庫TDengine，主攻物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)等場景下海量爆發(fā)的時(shí)序數(shù)據(jù)的處理，對數(shù)據(jù)庫產(chǎn)品還是有一定的研究的。先來講講我司專業(yè)人士匯總的數(shù)據(jù)庫選型原則，如有不同意見敬請指教：

1、如果是事務(wù)的：

• 單機(jī)扛得住的，MySQL/PG 都可以選擇

• 單機(jī)扛不住，但是好分片的，同上一條

• 不好分片，那可以考慮 TiDB 這種分布式事務(wù)的 HTAP

2、對于非事務(wù)，基本上就是各種 MPP 型的 OLAP：

• 多維分析為主，不知道自己什么已知維度的分析，就用 ClickHouse/Doris 這種通用的 OLAP

• 有場景特色的，就選場景通用的，例如?TDengine?做時(shí)序場景，Neo4j 做圖計(jì)算

3、分布式數(shù)據(jù)庫，看幾點(diǎn)：

• Sharding + Partition 策略：這一點(diǎn)基本上決定了性能的上下限

• 分布式架構(gòu)：這一點(diǎn)影響系統(tǒng)的容量上限/瓶頸模塊

• 計(jì)算函數(shù)：這一點(diǎn)決定好不好用，能不能減輕業(yè)務(wù)開發(fā)的工作量。不然都只有讀寫沒計(jì)算，啥計(jì)算都自己寫肯定是不合適的。

MySQL 和 PostgreSQL 這兩款數(shù)據(jù)庫作為 SQL 類數(shù)據(jù)庫，存儲結(jié)構(gòu)化數(shù)據(jù)是很合適的。那如果是時(shí)序數(shù)據(jù)呢，以車聯(lián)網(wǎng)場景為例，其 GPS 產(chǎn)生的時(shí)序數(shù)據(jù)量級通常都達(dá)到了億級，高效寫入、存儲和快速查詢是最基本的數(shù)據(jù)處理要求，但在具體實(shí)踐上這卻不是一件容易實(shí)現(xiàn)的事情。我們之前就遇到過這樣一個(gè)案例：

某企業(yè)服務(wù)端接收存儲 GPS 相關(guān)數(shù)據(jù)，按 1 次/30 秒的上傳頻率，一天的數(shù)據(jù)條數(shù)估計(jì)在 1.2 億條，其想要實(shí)現(xiàn)后臺的實(shí)時(shí)監(jiān)控和歷史軌跡查詢，如何選用數(shù)據(jù)庫？

我們看一下每秒的寫入量：平均 10W/30 = 3333 rows/s，最大值 10W rows/s，由于車聯(lián)網(wǎng)本身會出現(xiàn)“車機(jī)在一段時(shí)間內(nèi)斷網(wǎng)補(bǔ)傳數(shù)據(jù)”、“車機(jī)上傳按時(shí)鐘定時(shí)”等特點(diǎn)，會有一定概率觸發(fā)最大值寫入量，甚至超過最大值。因此選用的數(shù)據(jù)庫必須具備高吞吐能力，而且還得留有余力供后續(xù)擴(kuò)容。用過 MySQL 的開發(fā)者都會有體驗(yàn)，在沒調(diào)優(yōu)的情況下，這種 2KB 的行寫入，1k tps 基本把單個(gè)節(jié)點(diǎn)打滿了。

另外一方面，我們一般都會建立索引，至少建立時(shí)間戳的索引用于按時(shí)間段查找數(shù)據(jù)。而當(dāng)我們用 B+ 樹存儲索引，在單表數(shù)據(jù)量達(dá)到 2000W 行時(shí)，索引的維護(hù)會導(dǎo)致寫入速度的下降，單從這一點(diǎn)看就很難運(yùn)維，更不要說在建立更多索引的情況下。

再者，MySQL 的橫向擴(kuò)展只能靠中間件來實(shí)現(xiàn)，沒有更好的方式了，這種分布式的橫向擴(kuò)展能力也為其打了個(gè)折扣。正是基于此，PostgreSQL 才會單獨(dú)出了一個(gè)分支來存儲時(shí)序數(shù)據(jù)。但 PostgreSQL 畢竟不是專業(yè)的，也并不能很好地實(shí)現(xiàn)數(shù)據(jù)處理要求。以一個(gè)真實(shí)案例為例：

此前蘇州大學(xué)為保障全校系統(tǒng)以及網(wǎng)絡(luò)、服務(wù)器硬件、操作系統(tǒng)的可用性、可靠性和安全性，打造了蘇州大學(xué)智慧運(yùn)維管理平臺，除了要對幾千臺攝像頭進(jìn)行數(shù)據(jù)采集加在線檢測，其還有 1500 多臺交換機(jī)和 4000 多臺服務(wù)器，在數(shù)據(jù)庫的選擇上，它需要在扛住如此大量設(shè)備 24 * 7 高頻長期寫入的同時(shí)，還要確保相當(dāng)出色的查詢效率。他們原本使用的就是 PostgreSQL，但當(dāng)數(shù)據(jù)量達(dá)到億級時(shí)，PostgreSQL 查詢分析延遲會達(dá)到大幾秒，壓縮率上也不太理想，占用存儲空間超過了200GB，無法撐起一個(gè)全域一體化運(yùn)維監(jiān)控平臺的持續(xù)運(yùn)行。

這個(gè)數(shù)字沒有對比大家也可能產(chǎn)生不了太深刻的認(rèn)知，下面我們就來對比看一下。在集成到TDengine之后，TDengine 存儲的大概 2 億行數(shù)據(jù)，實(shí)際占用存儲空間不過 2GB，比起 PostgreSQL 占用的超過 200GB 的空間，幾乎可以忽略不計(jì)；PostgreSQL 的很多查詢都需要幾秒返回結(jié)果，而TDengine 都是毫秒級別。