建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
如何根據(jù)性能選擇內(nèi)存NoSQL數(shù)據(jù)庫(kù)
本文主要內(nèi)容是測(cè)試了不同NoSQL數(shù)據(jù)庫(kù)在測(cè)試工具YCSB中的表現(xiàn)。我們選取了3款流行的內(nèi)存(in-memory)數(shù)據(jù)庫(kù)管理系統(tǒng)：Redis，Tarantool 以及 CouchBase，還有緩存系統(tǒng)Memchached。Memchached雖然不屬于數(shù)據(jù)庫(kù)管理系統(tǒng)但常作為快速存儲(chǔ)系統(tǒng)使用。
10年積累的成都做網(wǎng)站、成都網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶(hù)對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶(hù)得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先做網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有香河免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
測(cè)試環(huán)境由4臺(tái)在Microsoft Azure Cloud中的虛擬機(jī)組成的計(jì)算機(jī)組組成。這些虛擬機(jī)同屬于一個(gè)數(shù)據(jù)中心。nosql-1和nosql-2用作測(cè)試Tarantool和CouchBase，nosql-3和nosql-4用作測(cè)試Redis，Azure Redis Cache 以及 Memcached。這些機(jī)器都安裝和配置了相應(yīng)數(shù)據(jù)庫(kù)和測(cè)試項(xiàng)目。虛擬機(jī)的配置為4核A3 CPU，7GB RAM，120GB硬盤(pán)。
數(shù)據(jù)庫(kù)及設(shè)置
內(nèi)存數(shù)據(jù)庫(kù)管理系統(tǒng)會(huì)存儲(chǔ)所有在主內(nèi)存中的數(shù)據(jù)并在磁碟上進(jìn)行持續(xù)更新操作；透過(guò)日志記錄每個(gè)數(shù)據(jù)的修改以確保連貫性。由于是以append-only方式進(jìn)行日志寫(xiě)入，因此它很少遇到瓶頸問(wèn)題；讀取/寫(xiě)入都不會(huì)造成頻繁的磁碟頭移動(dòng)。
Redis在2009推出，目前的最新版本是3.0.5。我們這里使用的版本是3.0.4，以append-only(只附加)方式進(jìn)行數(shù)據(jù)管理，與其配合使用的是Microsoft Azure Redis Cache工具。
Tarantool是一款開(kāi)源NoSQL數(shù)據(jù)庫(kù)管理系統(tǒng)。我們使用的是Tarantool 1.6.7-126-gb35aff9，日志采用write-ahead(先寫(xiě))模式。Memcached是一款分布式內(nèi)存緩存系統(tǒng)，這里使用是Memcached 1.4.14-0ubuntu9。
Couchbase Server是開(kāi)源分布式NoSQL面向文檔數(shù)據(jù)庫(kù)，這里使用的版本是Couchbase 4.0.0-4047-1。
YCSB測(cè)試工具
Yahoo! Cloud Serving Benchmark(YCSB)是功能強(qiáng)大的NoSQL數(shù)據(jù)庫(kù)性能測(cè)試工具，它提供了6種主要的負(fù)載工作類(lèi)型，以字母A到F來(lái)區(qū)分。
負(fù)載A負(fù)責(zé)更新操作，極值是50/50的讀寫(xiě)操作，如用于進(jìn)行新近操作記錄。負(fù)載B負(fù)責(zé)讀取操作，極值是95/5的讀寫(xiě)操作，如用于進(jìn)行圖片標(biāo)簽管理，多進(jìn)行標(biāo)簽讀取操作。負(fù)載C負(fù)載100%的讀取操作，如用于進(jìn)行用戶(hù)屬性獲取。負(fù)載D以先進(jìn)先出方式進(jìn)行插入操作，如用戶(hù)進(jìn)行最新數(shù)據(jù)讀取。負(fù)載E負(fù)責(zé)小范圍記錄讀取而不是單個(gè)記錄讀取，如線程會(huì)話。負(fù)載F負(fù)責(zé)記錄的讀取，修改和寫(xiě)入，如用戶(hù)信息管理。
我們對(duì)配置文件作了兩處參數(shù)修改：數(shù)據(jù)條目recordcount設(shè)為200000，操作條目operationcount設(shè)為5000000。YCSB是多線程工具，我們將以8, 16, 32, 64, 128 及256 線程來(lái)進(jìn)行測(cè)試。詳細(xì)的測(cè)試腳本請(qǐng)點(diǎn)擊這里進(jìn)行下載。
下列測(cè)試結(jié)果圖以顏色進(jìn)行測(cè)試對(duì)象區(qū)分，
Tarantool (HASH) （藍(lán)）
Tarantool (TREE)（淺藍(lán)）
Redis （紅）
Azure Redis Cache （橙）
Memcached （綠）
CouchBase（黑）
更多圖片請(qǐng)點(diǎn)擊［這里］查看。
結(jié)論
Tarantool在所有負(fù)載類(lèi)型測(cè)試中皆取得了最優(yōu)成績(jī)。它創(chuàng)建了一個(gè)無(wú)鎖內(nèi)存引擎，以協(xié)同多任務(wù)方式進(jìn)行操作而不是互斥或并行處理方式。根據(jù)以下性能圖表現(xiàn)，我們的結(jié)論是Tarantool的高吞吐量處理是其最大優(yōu)勢(shì)之一。因此在多數(shù)場(chǎng)合下，Tarantool是用戶(hù)的最佳選擇。
ssdb、minio性能測(cè)試c
項(xiàng)目上需要找一個(gè)硬盤(pán)型的NoSQL，用于將 Redis 中的冷數(shù)據(jù)落入硬盤(pán)。初步選型了幾款 key-value 類(lèi)型的NoSQL，分別有 levelDB、 rocksDB、 TiDB、 SSDB、swapDB、 Kvrocks、Tikv 。均為基于 levelDB 開(kāi)發(fā)的幾款NoSQL。其中因?yàn)?levelDB、rocksDB 無(wú)網(wǎng)絡(luò)接口，不方便做分布式和高可用。， TiDB 過(guò)重，還有 swapDB 社區(qū)不夠活躍且相關(guān)client API不完備。暫時(shí)選型 SSDB 。
項(xiàng)目需要存儲(chǔ)的其實(shí)是一個(gè)略長(zhǎng)的二進(jìn)制字符串，初步認(rèn)為，使用 對(duì)象存儲(chǔ) 方案其實(shí)也可以替代NoSQL，所以壓測(cè)對(duì)象添加當(dāng)前非?；鸬脑圃鷮?duì)象存儲(chǔ) MinIO
硬件名|配置 系統(tǒng)| Ubuntu(基于win10 wsl版的docker啟動(dòng)) 內(nèi)存| 16GB(實(shí)際可用6.08G) CPU| Intel i5-8400
測(cè)試項(xiàng)目： 1. 寫(xiě)50M數(shù)據(jù)100次 2. 隨機(jī)讀取任意key 100次（對(duì)LRU機(jī)制不友好）
寫(xiě)
數(shù)據(jù)導(dǎo)入成功！
數(shù)據(jù)序列化成功！
a 數(shù)據(jù)大小:50.99295234680176 MB
第1次寫(xiě)入總用時(shí): 797 ms
第2次寫(xiě)入總用時(shí): 848 ms
第3次寫(xiě)入總用時(shí): 3621 ms
第4次寫(xiě)入總用時(shí): 813 ms
第5次寫(xiě)入總用時(shí): 1862 ms
第6次寫(xiě)入總用時(shí): 838 ms
第7次寫(xiě)入總用時(shí): 2235 ms
第8次寫(xiě)入總用時(shí): 836 ms
第9次寫(xiě)入總用時(shí): 900 ms
第10次寫(xiě)入總用時(shí): 1027 ms
第11次寫(xiě)入總用時(shí): 1101 ms
第12次寫(xiě)入總用時(shí): 880 ms
第13次寫(xiě)入總用時(shí): 1956 ms
第14次寫(xiě)入總用時(shí): 866 ms
第15次寫(xiě)入總用時(shí): 2422 ms
第16次寫(xiě)入總用時(shí): 852 ms
第17次寫(xiě)入總用時(shí): 4511 ms
第18次寫(xiě)入總用時(shí): 875 ms
第19次寫(xiě)入總用時(shí): 2736 ms
第20次寫(xiě)入總用時(shí): 814 ms
第21次寫(xiě)入總用時(shí): 7172 ms
第22次寫(xiě)入總用時(shí): 891 ms
第23次寫(xiě)入總用時(shí): 7820 ms
第24次寫(xiě)入總用時(shí): 836 ms
第25次寫(xiě)入總用時(shí): 22103 ms
第26次寫(xiě)入總用時(shí): 877 ms
第27次寫(xiě)入總用時(shí): 2712 ms
第28次寫(xiě)入總用時(shí): 841 ms
第29次寫(xiě)入總用時(shí): 1928 ms
第30次寫(xiě)入總用時(shí): 916 ms
第31次寫(xiě)入總用時(shí): 839 ms
第32次寫(xiě)入總用時(shí): 826 ms
第33次寫(xiě)入總用時(shí): 7759 ms
第34次寫(xiě)入總用時(shí): 843 ms
第35次寫(xiě)入總用時(shí): 10670 ms
第36次寫(xiě)入總用時(shí): 843 ms
第37次寫(xiě)入總用時(shí): 9361 ms
第38次寫(xiě)入總用時(shí): 821 ms
第39次寫(xiě)入總用時(shí): 810 ms
第40次寫(xiě)入總用時(shí): 794 ms
第41次寫(xiě)入總用時(shí): 13281 ms
第42次寫(xiě)入總用時(shí): 833 ms
第43次寫(xiě)入總用時(shí): 811 ms
第44次寫(xiě)入總用時(shí): 798 ms
第45次寫(xiě)入總用時(shí): 18843 ms
第46次寫(xiě)入總用時(shí): 911 ms
第47次寫(xiě)入總用時(shí): 9428 ms
第48次寫(xiě)入總用時(shí): 898 ms
第49次寫(xiě)入總用時(shí): 17582 ms
第50次寫(xiě)入總用時(shí): 903 ms
第51次寫(xiě)入總用時(shí): 831 ms
第52次寫(xiě)入總用時(shí): 800 ms
第53次寫(xiě)入總用時(shí): 14602 ms
第54次寫(xiě)入總用時(shí): 827 ms
第55次寫(xiě)入總用時(shí): 5898 ms
第56次寫(xiě)入總用時(shí): 856 ms
第57次寫(xiě)入總用時(shí): 5693 ms
第58次寫(xiě)入總用時(shí): 1050 ms
第59次寫(xiě)入總用時(shí): 882 ms
第60次寫(xiě)入總用時(shí): 1020 ms
第61次寫(xiě)入總用時(shí): 15060 ms
第62次寫(xiě)入總用時(shí): 902 ms
第63次寫(xiě)入總用時(shí): 1062 ms
第64次寫(xiě)入總用時(shí): 915 ms
第65次寫(xiě)入總用時(shí): 7572 ms
第66次寫(xiě)入總用時(shí): 823 ms
第67次寫(xiě)入總用時(shí): 9649 ms
第68次寫(xiě)入總用時(shí): 832 ms
第69次寫(xiě)入總用時(shí): 10403 ms
第70次寫(xiě)入總用時(shí): 907 ms
第71次寫(xiě)入總用時(shí): 978 ms
第72次寫(xiě)入總用時(shí): 789 ms
第73次寫(xiě)入總用時(shí): 2111 ms
第74次寫(xiě)入總用時(shí): 947 ms
第75次寫(xiě)入總用時(shí): 4675 ms
第76次寫(xiě)入總用時(shí): 944 ms
第77次寫(xiě)入總用時(shí): 8592 ms
第78次寫(xiě)入總用時(shí): 832 ms
第79次寫(xiě)入總用時(shí): 2940 ms
第80次寫(xiě)入總用時(shí): 842 ms
第81次寫(xiě)入總用時(shí): 19835 ms
第82次寫(xiě)入總用時(shí): 862 ms
第83次寫(xiě)入總用時(shí): 7646 ms
第84次寫(xiě)入總用時(shí): 873 ms
第85次寫(xiě)入總用時(shí): 1002 ms
第86次寫(xiě)入總用時(shí): 842 ms
第87次寫(xiě)入總用時(shí): 9057 ms
第88次寫(xiě)入總用時(shí): 801 ms
第89次寫(xiě)入總用時(shí): 5117 ms
第90次寫(xiě)入總用時(shí): 918 ms
第91次寫(xiě)入總用時(shí): 798 ms
第92次寫(xiě)入總用時(shí): 853 ms
第93次寫(xiě)入總用時(shí): 7728 ms
第94次寫(xiě)入總用時(shí): 810 ms
第95次寫(xiě)入總用時(shí): 3969 ms
第96次寫(xiě)入總用時(shí): 814 ms
第97次寫(xiě)入總用時(shí): 2050 ms
第98次寫(xiě)入總用時(shí): 819 ms
第99次寫(xiě)入總用時(shí): 9566 ms
第100次寫(xiě)入總用時(shí): 833 ms/pre
隨機(jī)讀
第1次讀取 15總用時(shí): 2251 ms
第2次讀取 73總用時(shí): 2045 ms
第3次讀取 98總用時(shí): 1548 ms
第4次讀取 20總用時(shí): 2683 ms
第5次讀取 46總用時(shí): 1156 ms
第6次讀取 69總用時(shí): 1160 ms
第7次讀取 46總用時(shí): 1520 ms
第8次讀取 51總用時(shí): 1381 ms
第9次讀取 48總用時(shí): 1000 ms
第10次讀取 69總用時(shí): 1400 ms
第11次讀取 82總用時(shí): 1236 ms
第12次讀取 22總用時(shí): 1140 ms
第13次讀取 36總用時(shí): 864 ms
第14次讀取 66總用時(shí): 843 ms
第15次讀取 47總用時(shí): 922 ms
第16次讀取 17總用時(shí): 885 ms
第17次讀取 14總用時(shí): 864 ms
第18次讀取 64總用時(shí): 888 ms
第19次讀取 74總用時(shí): 815 ms
第20次讀取 33總用時(shí): 866 ms
第21次讀取 36總用時(shí): 822 ms
第22次讀取 78總用時(shí): 975 ms
第23次讀取 40總用時(shí): 1186 ms
第24次讀取 54總用時(shí): 857 ms
第25次讀取 92總用時(shí): 963 ms
第26次讀取 43總用時(shí): 955 ms
第27次讀取 38總用時(shí): 853 ms
第28次讀取 47總用時(shí): 926 ms
第29次讀取 62總用時(shí): 877 ms
第30次讀取 70總用時(shí): 890 ms
第31次讀取 88總用時(shí): 895 ms
第32次讀取 15總用時(shí): 937 ms
第33次讀取 3總用時(shí): 993 ms
第34次讀取 99總用時(shí): 892 ms
第35次讀取 76總用時(shí): 818 ms
第36次讀取 30總用時(shí): 1020 ms
第37次讀取 89總用時(shí): 863 ms
第38次讀取 99總用時(shí): 819 ms
第39次讀取 62總用時(shí): 818 ms
第40次讀取 1總用時(shí): 871 ms
第41次讀取 66總用時(shí): 809 ms
第42次讀取 68總用時(shí): 847 ms
第43次讀取 72總用時(shí): 910 ms
第44次讀取 50總用時(shí): 1128 ms
第45次讀取 47總用時(shí): 898 ms
第46次讀取 26總用時(shí): 909 ms
第47次讀取 35總用時(shí): 872 ms
第48次讀取 30總用時(shí): 826 ms
第49次讀取 79總用時(shí): 904 ms
第50次讀取 66總用時(shí): 863 ms
第51次讀取 2總用時(shí): 885 ms
第52次讀取 65總用時(shí): 900 ms
第53次讀取 67總用時(shí): 1023 ms
第54次讀取 16總用時(shí): 934 ms
第55次讀取 63總用時(shí): 892 ms
第56次讀取 9總用時(shí): 894 ms
第57次讀取 71總用時(shí): 896 ms
第58次讀取 20總用時(shí): 947 ms
第59次讀取 89總用時(shí): 865 ms
第60次讀取 57總用時(shí): 872 ms
第61次讀取 62總用時(shí): 856 ms
第62次讀取 14總用時(shí): 881 ms
第63次讀取 19總用時(shí): 950 ms
第64次讀取 14總用時(shí): 876 ms
第65次讀取 86總用時(shí): 968 ms
第66次讀取 12總用時(shí): 911 ms
第67次讀取 93總用時(shí): 877 ms
第68次讀取 59總用時(shí): 886 ms
第69次讀取 79總用時(shí): 878 ms
第70次讀取 49總用時(shí): 869 ms
第71次讀取 91總用時(shí): 964 ms
第72次讀取 38總用時(shí): 838 ms
第73次讀取 73總用時(shí): 915 ms
第74次讀取 8總用時(shí): 875 ms
第75次讀取 96總用時(shí): 827 ms
第76次讀取 98總用時(shí): 826 ms
第77次讀取 95總用時(shí): 892 ms
第78次讀取 36總用時(shí): 843 ms
第79次讀取 44總用時(shí): 872 ms
第80次讀取 89總用時(shí): 863 ms
第81次讀取 24總用時(shí): 883 ms
第82次讀取 89總用時(shí): 804 ms
第83次讀取 49總用時(shí): 876 ms
第84次讀取 81總用時(shí): 873 ms
第85次讀取 72總用時(shí): 914 ms
第86次讀取 68總用時(shí): 861 ms
第87次讀取 73總用時(shí): 893 ms
第88次讀取 4總用時(shí): 880 ms
第89次讀取 3總用時(shí): 987 ms
第90次讀取 76總用時(shí): 896 ms
第91次讀取 16總用時(shí): 1010 ms
第92次讀取 73總用時(shí): 903 ms
第93次讀取 83總用時(shí): 933 ms
第94次讀取 52總用時(shí): 945 ms
第95次讀取 48總用時(shí): 901 ms
第96次讀取 26總用時(shí): 942 ms
第97次讀取 37總用時(shí): 883 ms
第98次讀取 44總用時(shí): 866 ms
第99次讀取 89總用時(shí): 921 ms
第100次讀取 61總用時(shí): 896 ms/pre
寫(xiě)
數(shù)據(jù)導(dǎo)入成功！
第1次寫(xiě)入總用時(shí): 956 ms
第2次寫(xiě)入總用時(shí): 912 ms
第3次寫(xiě)入總用時(shí): 1241 ms
第4次寫(xiě)入總用時(shí): 1564 ms
第5次寫(xiě)入總用時(shí): 942 ms
第6次寫(xiě)入總用時(shí): 3666 ms
第7次寫(xiě)入總用時(shí): 1629 ms
第8次寫(xiě)入總用時(shí): 1712 ms
第9次寫(xiě)入總用時(shí): 977 ms
第10次寫(xiě)入總用時(shí): 1515 ms
第11次寫(xiě)入總用時(shí): 911 ms
第12次寫(xiě)入總用時(shí): 1009 ms
第13次寫(xiě)入總用時(shí): 1024 ms
第14次寫(xiě)入總用時(shí): 1206 ms
第15次寫(xiě)入總用時(shí): 984 ms
第16次寫(xiě)入總用時(shí): 943 ms
第17次寫(xiě)入總用時(shí): 954 ms
第18次寫(xiě)入總用時(shí): 1033 ms
第19次寫(xiě)入總用時(shí): 1008 ms
第20次寫(xiě)入總用時(shí): 1121 ms
第21次寫(xiě)入總用時(shí): 963 ms
第22次寫(xiě)入總用時(shí): 949 ms
第23次寫(xiě)入總用時(shí): 889 ms
第24次寫(xiě)入總用時(shí): 1066 ms
第25次寫(xiě)入總用時(shí): 1289 ms
第26次寫(xiě)入總用時(shí): 1125 ms
第27次寫(xiě)入總用時(shí): 1111 ms
第28次寫(xiě)入總用時(shí): 953 ms
第29次寫(xiě)入總用時(shí): 964 ms
第30次寫(xiě)入總用時(shí): 1125 ms
第31次寫(xiě)入總用時(shí): 998 ms
第32次寫(xiě)入總用時(shí): 1993 ms
第33次寫(xiě)入總用時(shí): 926 ms
第34次寫(xiě)入總用時(shí): 920 ms
第35次寫(xiě)入總用時(shí): 926 ms
第36次寫(xiě)入總用時(shí): 1169 ms
第37次寫(xiě)入總用時(shí): 1325 ms
第38次寫(xiě)入總用時(shí): 1170 ms
第39次寫(xiě)入總用時(shí): 1074 ms
第40次寫(xiě)入總用時(shí): 1011 ms
第41次寫(xiě)入總用時(shí): 931 ms
第42次寫(xiě)入總用時(shí): 984 ms
第43次寫(xiě)入總用時(shí): 1563 ms
第44次寫(xiě)入總用時(shí): 905 ms
第45次寫(xiě)入總用時(shí): 944 ms
第46次寫(xiě)入總用時(shí): 1147 ms
第47次寫(xiě)入總用時(shí): 1429 ms
第48次寫(xiě)入總用時(shí): 934 ms
第49次寫(xiě)入總用時(shí): 1133 ms
第50次寫(xiě)入總用時(shí): 912 ms
第51次寫(xiě)入總用時(shí): 953 ms
第52次寫(xiě)入總用時(shí): 1127 ms
第53次寫(xiě)入總用時(shí): 1065 ms
第54次寫(xiě)入總用時(shí): 1323 ms
第55次寫(xiě)入總用時(shí): 1003 ms
第56次寫(xiě)入總用時(shí): 1489 ms
第57次寫(xiě)入總用時(shí): 1377 ms
第58次寫(xiě)入總用時(shí): 940 ms
第59次寫(xiě)入總用時(shí): 1317 ms
第60次寫(xiě)入總用時(shí): 912 ms
第61次寫(xiě)入總用時(shí): 898 ms
第62次寫(xiě)入總用時(shí): 934 ms
第63次寫(xiě)入總用時(shí): 1005 ms
第64次寫(xiě)入總用時(shí): 1729 ms
第65次寫(xiě)入總用時(shí): 983 ms
第66次寫(xiě)入總用時(shí): 1684 ms
第67次寫(xiě)入總用時(shí): 908 ms
第68次寫(xiě)入總用時(shí): 895 ms
第69次寫(xiě)入總用時(shí): 1171 ms
第70次寫(xiě)入總用時(shí): 1372 ms
第71次寫(xiě)入總用時(shí): 1261 ms
第72次寫(xiě)入總用時(shí): 1024 ms
第73次寫(xiě)入總用時(shí): 1048 ms
第74次寫(xiě)入總用時(shí): 904 ms
第75次寫(xiě)入總用時(shí): 941 ms
第76次寫(xiě)入總用時(shí): 928 ms
第77次寫(xiě)入總用時(shí): 1806 ms
第78次寫(xiě)入總用時(shí): 1052 ms
第79次寫(xiě)入總用時(shí): 1030 ms
第80次寫(xiě)入總用時(shí): 1092 ms
第81次寫(xiě)入總用時(shí): 1117 ms
第82次寫(xiě)入總用時(shí): 950 ms
第83次寫(xiě)入總用時(shí): 933 ms
第84次寫(xiě)入總用時(shí): 928 ms
第85次寫(xiě)入總用時(shí): 935 ms
第86次寫(xiě)入總用時(shí): 1908 ms
第87次寫(xiě)入總用時(shí): 994 ms
第88次寫(xiě)入總用時(shí): 1097 ms
第89次寫(xiě)入總用時(shí): 930 ms
第90次寫(xiě)入總用時(shí): 1052 ms
第91次寫(xiě)入總用時(shí): 1119 ms
第92次寫(xiě)入總用時(shí): 958 ms
第93次寫(xiě)入總用時(shí): 987 ms
第94次寫(xiě)入總用時(shí): 973 ms
第95次寫(xiě)入總用時(shí): 2036 ms
第96次寫(xiě)入總用時(shí): 891 ms
第97次寫(xiě)入總用時(shí): 954 ms
第98次寫(xiě)入總用時(shí): 951 ms
第99次寫(xiě)入總用時(shí): 1044 ms
第100次寫(xiě)入總用時(shí): 1366 ms/pre
隨機(jī)讀
第1次讀取 46總用時(shí): 40 ms
第2次讀取 8總用時(shí): 36 ms
第3次讀取 28總用時(shí): 26 ms
第4次讀取 80總用時(shí): 10 ms
第5次讀取 77總用時(shí): 13 ms
第6次讀取 27總用時(shí): 49 ms
第7次讀取 86總用時(shí): 20 ms
第8次讀取 0總用時(shí): 45 ms
第9次讀取 54總用時(shí): 34 ms
第10次讀取 24總用時(shí): 153 ms
第11次讀取 78總用時(shí): 29 ms
第12次讀取 0總用時(shí): 17 ms
第13次讀取 91總用時(shí): 56 ms
第14次讀取 5總用時(shí): 99 ms
第15次讀取 23總用時(shí): 138 ms
第16次讀取 37總用時(shí): 120 ms
第17次讀取 40總用時(shí): 156 ms
第18次讀取 88總用時(shí): 41 ms
第19次讀取 76總用時(shí): 32 ms
第20次讀取 49總用時(shí): 102 ms
第21次讀取 20總用時(shí): 179 ms
第22次讀取 40總用時(shí): 68 ms
第23次讀取 6總用時(shí): 215 ms
第24次讀取 36總用時(shí): 197 ms
第25次讀取 37總用時(shí): 30 ms
第26次讀取 68總用時(shí): 154 ms
第27次讀取 14總用時(shí): 314 ms
第28次讀取 27總用時(shí): 91 ms
第29次讀取 51總用時(shí): 255 ms
第30次讀取 66總用時(shí): 166 ms
第31次讀取 86總用時(shí): 140 ms
第32次讀取 29總用時(shí): 374 ms
第33次讀取 96總用時(shí): 235 ms
第34次讀取 68總用時(shí): 72 ms
第35次讀取 74總用時(shí): 264 ms
第36次讀取 11總用時(shí): 334 ms
第37次讀取 55總用時(shí): 316 ms
第38次讀取 31總用時(shí): 287 ms
第39次讀取 93總用時(shí): 233 ms
第40次讀取 44總用時(shí): 499 ms
第41次讀取 26總用時(shí): 312 ms
第42次讀取 76總用時(shí): 33 ms
第43次讀取 11總用時(shí): 31 ms
第44次讀取 86總用時(shí): 191 ms
第45次讀取 96總用時(shí): 217 ms
第46次讀取 20總用時(shí): 145 ms
第47次讀取 1總用時(shí): 772 ms
第48次讀取 69總用時(shí): 477 ms
第49次讀取 9總用時(shí): 320 ms
第50次讀取 46總用時(shí): 42 ms
第51次讀取 34總用時(shí): 823 ms
第52次讀取 76總用時(shí): 115 ms
第53次讀取 62總用時(shí): 635 ms
第54次讀取 99總用時(shí): 596 ms
第55次讀取 64總用時(shí): 657 ms
第56次讀取 66總用時(shí): 97 ms
第57次讀取 18總用時(shí): 461 ms
第58次讀取 91總用時(shí): 247 ms
第59次讀取 46總用時(shí): 147 ms
第60次讀取 12總用時(shí): 702 ms
第61次讀取 79總用時(shí): 545 ms
第62次讀取 47總用時(shí): 956 ms
第63次讀取 17總用時(shí): 853 ms
第64次讀取 97總用時(shí): 771 ms
第65次讀取 74總用時(shí): 368 ms
第66次讀取 84總用時(shí): 790 ms
第67次讀取 72總用時(shí): 866 ms
第68次讀取 82總用時(shí): 742 ms
第69次讀取 93總用時(shí): 313 ms
第70次讀取 57總用時(shí): 917 ms
第71次讀取 61總用時(shí): 1185 ms
第72次讀取 66總用時(shí): 162 ms
第73次讀取 5總用時(shí): 168 ms
第74次讀取 68總用時(shí): 275 ms
第75次讀取 43總用時(shí): 1108 ms
第76次讀取 74總用時(shí): 281 ms
第77次讀取 65總用時(shí): 955 ms
第78次讀取 22總用時(shí): 1169 ms
第79次讀取 88總用時(shí): 501 ms
第80次讀取 80總用時(shí): 1685 ms
第81次讀取 92總用時(shí): 1286 ms
第82次讀取 89總用時(shí): 1680 ms
第83次讀取 30總用時(shí): 1537 ms
第84次讀取 41總用時(shí): 1576 ms
第85次讀取 2總用時(shí): 2193 ms
第86次讀取 52總用時(shí): 1817 ms
第87次讀取 8總用時(shí): 323 ms
第88次讀取 81總用時(shí): 1409 ms
第89次讀取 40總用時(shí): 577 ms
第90次讀取 88總用時(shí): 598 ms
第91次讀取 19總用時(shí): 2324 ms
第92次讀取 75總用時(shí): 2275 ms
第93次讀取 29總用時(shí): 668 ms
第94次讀取 77總用時(shí): 2773 ms
第95次讀取 62總用時(shí): 484 ms
第96次讀取 84總用時(shí): 883 ms
第97次讀取 32總用時(shí): 2945 ms
第98次讀取 44總用時(shí): 884 ms
第99次讀取 66總用時(shí): 631 ms
第100次讀取 38總用時(shí): 2739 ms/pre
非常奇怪的是 MinIO 整體性能略?xún)?yōu)于 SSDB 但是理論上不太應(yīng)該， SSDB 怎么說(shuō)也是半內(nèi)存半硬盤(pán)的NoSQL不應(yīng)該比純硬盤(pán)的 MinIO 性能要差，有可能是 SSDB 寫(xiě)到一定數(shù)據(jù)量后把本機(jī)內(nèi)存寫(xiě)爆了，導(dǎo)致讀寫(xiě)非常慢。但這變相驗(yàn)證了 SSDB 在極端情況下的不穩(wěn)定。
分庫(kù)分表 VS newsql數(shù)據(jù)庫(kù)
最近與同行 科技 交流，經(jīng)常被問(wèn)到分庫(kù)分表與分布式數(shù)據(jù)庫(kù)如何選擇，網(wǎng)上也有很多關(guān)于中間件+傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)（分庫(kù)分表）與NewSQL分布式數(shù)據(jù)庫(kù)的文章，但有些觀點(diǎn)與判斷是我覺(jué)得是偏激的，脫離環(huán)境去評(píng)價(jià)方案好壞其實(shí)有失公允。
本文通過(guò)對(duì)兩種模式關(guān)鍵特性實(shí)現(xiàn)原理對(duì)比，希望可以盡可能客觀、中立的闡明各自真實(shí)的優(yōu)缺點(diǎn)以及適用場(chǎng)景。
首先關(guān)于“中間件+關(guān)系數(shù)據(jù)庫(kù)分庫(kù)分表”算不算NewSQL分布式數(shù)據(jù)庫(kù)問(wèn)題，國(guó)外有篇論文pavlo-newsql-sigmodrec，如果根據(jù)該文中的分類(lèi)，Spanner、TiDB、OB算是第一種新架構(gòu)型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種云數(shù)據(jù)庫(kù)，本文暫不詳細(xì)介紹）。
基于中間件（包括SDK和Proxy兩種形式）+傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)（分庫(kù)分表）模式是不是分布式架構(gòu)？我覺(jué)得是的，因?yàn)榇鎯?chǔ)確實(shí)也分布式了，也能實(shí)現(xiàn)橫向擴(kuò)展。但是不是"偽"分布式數(shù)據(jù)庫(kù)？從架構(gòu)先進(jìn)性來(lái)看，這么說(shuō)也有一定道理。"偽"主要體現(xiàn)在中間件層與底層DB重復(fù)的SQL解析與執(zhí)行計(jì)劃生成、存儲(chǔ)引擎基于B+Tree等，這在分布式數(shù)據(jù)庫(kù)架構(gòu)中實(shí)際上冗余低效的。為了避免引起真?zhèn)畏植际綌?shù)據(jù)庫(kù)的口水戰(zhàn)，本文中NewSQL數(shù)據(jù)庫(kù)特指這種新架構(gòu)NewSQL數(shù)據(jù)庫(kù)。
NewSQL數(shù)據(jù)庫(kù)相比中間件+分庫(kù)分表的先進(jìn)在哪兒？畫(huà)一個(gè)簡(jiǎn)單的架構(gòu)對(duì)比圖：
這些大多也是NewSQL數(shù)據(jù)庫(kù)產(chǎn)品主要宣傳的點(diǎn)，不過(guò)這些看起來(lái)很美好的功能是否真的如此？接下來(lái)針對(duì)以上幾點(diǎn)分別闡述下的我的理解。
這是把雙刃劍。
CAP限制
想想更早些出現(xiàn)的NoSQL數(shù)據(jù)庫(kù)為何不支持分布式事務(wù)（最新版的mongoDB等也開(kāi)始支持了），是缺乏理論與實(shí)踐支撐嗎？并不是，原因是CAP定理依然是分布式數(shù)據(jù)庫(kù)頭上的頸箍咒，在保證強(qiáng)一致的同時(shí)必然會(huì)犧牲可用性A或分區(qū)容忍性P。為什么大部分NoSQL不提供分布式事務(wù)？
那么NewSQL數(shù)據(jù)庫(kù)突破CAP定理限制了嗎？并沒(méi)有。NewSQL數(shù)據(jù)庫(kù)的鼻主Google Spanner（目前絕大部分分布式數(shù)據(jù)庫(kù)都是按照Spanner架構(gòu)設(shè)計(jì)的）提供了一致性和大于5個(gè)9的可用性，宣稱(chēng)是一個(gè)“實(shí)際上是CA”的，其真正的含義是 系統(tǒng)處于 CA 狀態(tài)的概率非常高，由于網(wǎng)絡(luò)分區(qū)導(dǎo)致的服務(wù)停用的概率非常小 ，究其真正原因是其打造私有全球網(wǎng)保證了不會(huì)出現(xiàn)網(wǎng)絡(luò)中斷引發(fā)的網(wǎng)絡(luò)分區(qū)，另外就是其高效的運(yùn)維隊(duì)伍,這也是cloud spanner的賣(mài)點(diǎn)。詳細(xì)可見(jiàn)CAP提出者Eric Brewer寫(xiě)的《Spanner, TrueTime 和CAP理論》。
完備性 ：
兩階段提交協(xié)議是否嚴(yán)格支持ACID，各種異常場(chǎng)景是不是都可以覆蓋？
2PC在commit階段發(fā)送異常，其實(shí)跟最大努力一階段提交類(lèi)似也會(huì)有部分可見(jiàn)問(wèn)題，嚴(yán)格講一段時(shí)間內(nèi)并不能保證A原子性和C一致性（待故障恢復(fù)后recovery機(jī)制可以保證最終的A和C）。完備的分布式事務(wù)支持并不是一件簡(jiǎn)單的事情，需要可以應(yīng)對(duì)網(wǎng)絡(luò)以及各種硬件包括網(wǎng)卡、磁盤(pán)、CPU、內(nèi)存、電源等各類(lèi)異常，通過(guò)嚴(yán)格的測(cè)試。之前跟某友商交流，他們甚至說(shuō)目前已知的NewSQL在分布式事務(wù)支持上都是不完整的，他們都有案例跑不過(guò)，圈內(nèi)人士這么篤定，也說(shuō)明了 分布式事務(wù)的支持完整程度其實(shí)是層次不齊的。
但分布式事務(wù)又是這些NewSQL數(shù)據(jù)庫(kù)的一個(gè)非常重要的底層機(jī)制，跨資源的DML、DDL等都依賴(lài)其實(shí)現(xiàn)，如果這塊的性能、完備性打折扣，上層跨分片SQL執(zhí)行的正確性會(huì)受到很大影響。
性能
傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)也支持分布式事務(wù)XA，但為何很少有高并發(fā)場(chǎng)景下用呢？ 因?yàn)閄A的基礎(chǔ)兩階段提交協(xié)議存在網(wǎng)絡(luò)開(kāi)銷(xiāo)大，阻塞時(shí)間長(zhǎng)、死鎖等問(wèn)題，這也導(dǎo)致了其實(shí)際上很少大規(guī)模用在基于傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的OLTP系統(tǒng)中。
NewSQL數(shù)據(jù)庫(kù)的分布式事務(wù)實(shí)現(xiàn)也仍然多基于兩階段提交協(xié)議，例如google percolator分布式事務(wù)模型，
采用原子鐘+MVCC+ Snapshot Isolation（SI），這種方式通過(guò)TSO(Timestamp Oracle)保證了全局一致性，通過(guò)MVCC避免了鎖，另外通過(guò)primary lock和secondary lock將提交的一部分轉(zhuǎn)為異步，相比XA確實(shí)提高了分布式事務(wù)的性能。
但不管如何優(yōu)化，相比于1PC，2PC多出來(lái)的GID獲取、網(wǎng)絡(luò)開(kāi)銷(xiāo)、prepare日志持久化還是會(huì)帶來(lái)很大的性能損失，尤其是跨節(jié)點(diǎn)的數(shù)量比較多時(shí)會(huì)更加顯著，例如在銀行場(chǎng)景做個(gè)批量扣款，一個(gè)文件可能上W個(gè)賬戶(hù)，這樣的場(chǎng)景無(wú)論怎么做還是吞吐都不會(huì)很高。
雖然NewSQL分布式數(shù)據(jù)庫(kù)產(chǎn)品都宣傳完備支持分布式事務(wù)，但這并不是說(shuō)應(yīng)用可以完全不用關(guān)心數(shù)據(jù)拆分，這些數(shù)據(jù)庫(kù)的最佳實(shí)踐中仍然會(huì)寫(xiě)到，應(yīng)用的大部分場(chǎng)景盡可能避免分布式事務(wù)。
既然強(qiáng)一致事務(wù)付出的性能代價(jià)太大，我們可以反思下是否真的需要這種強(qiáng)一致的分布式事務(wù)？尤其是在做微服務(wù)拆分后，很多系統(tǒng)也不太可能放在一個(gè)統(tǒng)一的數(shù)據(jù)庫(kù)中。嘗試將一致性要求弱化，便是柔性事務(wù)，放棄ACID(Atomicity,Consistency, Isolation, Durability)，轉(zhuǎn)投BASE(Basically Available,Soft state,Eventually consistent)，例如Saga、TCC、可靠消息保證最終一致等模型，對(duì)于大規(guī)模高并發(fā)OLTP場(chǎng)景，我個(gè)人更建議使用柔性事務(wù)而非強(qiáng)一致的分布式事務(wù)。關(guān)于柔性事務(wù)，筆者之前也寫(xiě)過(guò)一個(gè)技術(shù)組件，最近幾年也涌現(xiàn)出了一些新的模型與框架（例如阿里剛開(kāi)源的Fescar），限于篇幅不再贅述，有空再單獨(dú)寫(xiě)篇文章。
HA與異地多活
主從模式并不是最優(yōu)的方式，就算是半同步復(fù)制，在極端情況下（半同步轉(zhuǎn)異步）也存在丟數(shù)問(wèn)題，目前業(yè)界公認(rèn)更好的方案是基于paxos分布式一致性協(xié)議或者其它類(lèi)paxos如raft方式，Google Spanner、TiDB、cockcoachDB、OB都采用了這種方式，基于Paxos協(xié)議的多副本存儲(chǔ)，遵循過(guò)半寫(xiě)原則，支持自動(dòng)選主，解決了數(shù)據(jù)的高可靠，縮短了failover時(shí)間，提高了可用性，特別是減少了運(yùn)維的工作量，這種方案技術(shù)上已經(jīng)很成熟，也是NewSQL數(shù)據(jù)庫(kù)底層的標(biāo)配。
當(dāng)然這種方式其實(shí)也可以用在傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)，阿里、微信團(tuán)隊(duì)等也有將MySQL存儲(chǔ)改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，預(yù)計(jì)不遠(yuǎn)的未來(lái)主從模式可能就成為 歷史 了。
需要注意的是很多NewSQL數(shù)據(jù)庫(kù)廠商宣傳基于paxos或raft協(xié)議可以實(shí)現(xiàn)【異地多活】，這個(gè)實(shí)際上是有前提的，那就是異地之間網(wǎng)絡(luò)延遲不能太高 。以銀行“兩地三中心”為例，異地之間多相隔數(shù)千里，延時(shí)達(dá)到數(shù)十毫秒，如果要多活，那便需異地副本也參與數(shù)據(jù)庫(kù)日志過(guò)半確認(rèn)，這樣高的延時(shí)幾乎沒(méi)有OLTP系統(tǒng)可以接受的。
數(shù)據(jù)庫(kù)層面做異地多活是個(gè)美好的愿景，但距離導(dǎo)致的延時(shí)目前并沒(méi)有好的方案。 之前跟螞蟻團(tuán)隊(duì)交流，螞蟻異地多活的方案是在應(yīng)用層通過(guò)MQ同步雙寫(xiě)交易信息，異地DC將交易信息保存在分布式緩存中，一旦發(fā)生異地切換，數(shù)據(jù)庫(kù)同步中間件會(huì)告之?dāng)?shù)據(jù)延遲時(shí)間，應(yīng)用從緩存中讀取交易信息，將這段時(shí)間內(nèi)涉及到的業(yè)務(wù)對(duì)象例如用戶(hù)、賬戶(hù)進(jìn)行黑名單管理，等數(shù)據(jù)同步追上之后再將這些業(yè)務(wù)對(duì)象從黑名單中剔除。由于雙寫(xiě)的不是所有數(shù)據(jù)庫(kù)操作日志而只是交易信息，數(shù)據(jù)延遲只影響一段時(shí)間內(nèi)數(shù)據(jù)，這是目前我覺(jué)得比較靠譜的異地度多活方案。
另外有些系統(tǒng)進(jìn)行了單元化改造，這在paxos選主時(shí)也要結(jié)合考慮進(jìn)去，這也是目前很多NewSQL數(shù)據(jù)庫(kù)欠缺的功能。
Scale橫向擴(kuò)展與分片機(jī)制
paxos算法解決了高可用、高可靠問(wèn)題，并沒(méi)有解決Scale橫向擴(kuò)展的問(wèn)題，所以分片是必須支持的。NewSQL數(shù)據(jù)庫(kù)都是天生內(nèi)置分片機(jī)制的，而且會(huì)根據(jù)每個(gè)分片的數(shù)據(jù)負(fù)載(磁盤(pán)使用率、寫(xiě)入速度等)自動(dòng)識(shí)別熱點(diǎn)，然后進(jìn)行分片的分裂、數(shù)據(jù)遷移、合并，這些過(guò)程應(yīng)用是無(wú)感知的，這省去了DBA的很多運(yùn)維工作量。以TiDB為例，它將數(shù)據(jù)切成region，如果region到64M時(shí)，數(shù)據(jù)自動(dòng)進(jìn)行遷移。
分庫(kù)分表模式下需要應(yīng)用設(shè)計(jì)之初就要明確各表的拆分鍵、拆分方式（range、取模、一致性哈希或者自定義路由表）、路由規(guī)則、拆分庫(kù)表數(shù)量、擴(kuò)容方式等。相比NewSQL數(shù)據(jù)庫(kù)，這種模式給應(yīng)用帶來(lái)了很大侵入和復(fù)雜度，這對(duì)大多數(shù)系統(tǒng)來(lái)說(shuō)也是一大挑戰(zhàn)。
這里有個(gè)問(wèn)題是NewSQL數(shù)據(jù)庫(kù)統(tǒng)一的內(nèi)置分片策略（例如tidb基于range）可能并不是最高效的，因?yàn)榕c領(lǐng)域模型中的劃分要素并不一致，這導(dǎo)致的后果是很多交易會(huì)產(chǎn)生分布式事務(wù)。 舉個(gè)例子，銀行核心業(yè)務(wù)系統(tǒng)是以客戶(hù)為維度，也就是說(shuō)客戶(hù)表、該客戶(hù)的賬戶(hù)表、流水表在絕大部分場(chǎng)景下是一起寫(xiě)的，但如果按照各表主鍵range進(jìn)行分片，這個(gè)交易并不能在一個(gè)分片上完成，這在高頻OLTP系統(tǒng)中會(huì)帶來(lái)性能問(wèn)題。
分布式SQL支持
常見(jiàn)的單分片SQL，這兩者都能很好支持。NewSQL數(shù)據(jù)庫(kù)由于定位與目標(biāo)是一個(gè)通用的數(shù)據(jù)庫(kù)，所以支持的SQL會(huì)更完整，包括跨分片的join、聚合等復(fù)雜SQL。中間件模式多面向應(yīng)用需求設(shè)計(jì)，不過(guò)大部分也支持帶拆分鍵SQL、庫(kù)表遍歷、單庫(kù)join、聚合、排序、分頁(yè)等。但對(duì)跨庫(kù)的join以及聚合支持就不夠了。
NewSQL數(shù)據(jù)庫(kù)一般并不支持存儲(chǔ)過(guò)程、視圖、外鍵等功能，而中間件模式底層就是傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)，這些功能如果只是涉及單庫(kù)是比較容易支持的。
NewSQL數(shù)據(jù)庫(kù)往往選擇兼容MySQL或者PostgreSQL協(xié)議，所以SQL支持僅局限于這兩種，中間件例如驅(qū)動(dòng)模式往往只需做簡(jiǎn)單的SQL解析、計(jì)算路由、SQL重寫(xiě)，所以可以支持更多種類(lèi)的數(shù)據(jù)庫(kù)SQL。
SQL支持的差異主要在于分布式SQL執(zhí)行計(jì)劃生成器，由于NewSQL數(shù)據(jù)庫(kù)具有底層數(shù)據(jù)的分布、統(tǒng)計(jì)信息，因此可以做CBO，生成的執(zhí)行計(jì)劃效率更高，而中間件模式下沒(méi)有這些信息，往往只能基于規(guī)則RBO（Rule-Based-Opimization），這也是為什么中間件模式一般并不支持跨庫(kù)join，因?yàn)閷?shí)現(xiàn)了效率也往往并不高，還不如交給應(yīng)用去做。
存儲(chǔ)引擎
傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的存儲(chǔ)引擎設(shè)計(jì)都是面向磁盤(pán)的，大多都基于B+樹(shù)。B+樹(shù)通過(guò)降低樹(shù)的高度減少隨機(jī)讀、進(jìn)而減少磁盤(pán)尋道次數(shù)，提高讀的性能，但大量的隨機(jī)寫(xiě)會(huì)導(dǎo)致樹(shù)的分裂，從而帶來(lái)隨機(jī)寫(xiě)，導(dǎo)致寫(xiě)性能下降。NewSQL的底層存儲(chǔ)引擎則多采用LSM，相比B+樹(shù)LSM將對(duì)磁盤(pán)的隨機(jī)寫(xiě)變成順序?qū)?，大大提高了?xiě)的性能。不過(guò)LSM的的讀由于需要合并數(shù)據(jù)性能比B+樹(shù)差，一般來(lái)說(shuō)LSM更適合應(yīng)在寫(xiě)大于讀的場(chǎng)景。當(dāng)然這只是單純數(shù)據(jù)結(jié)構(gòu)角度的對(duì)比，在數(shù)據(jù)庫(kù)實(shí)際實(shí)現(xiàn)時(shí)還會(huì)通過(guò)SSD、緩沖、bloom filter等方式優(yōu)化讀寫(xiě)性能，所以讀性能基本不會(huì)下降太多。NewSQL數(shù)據(jù)由于多副本、分布式事務(wù)等開(kāi)銷(xiāo)，相比單機(jī)關(guān)系數(shù)據(jù)庫(kù)SQL的響應(yīng)時(shí)間并不占優(yōu)，但由于集群的彈性擴(kuò)展，整體QPS提升還是很明顯的，這也是NewSQL數(shù)據(jù)庫(kù)廠商說(shuō)分布式數(shù)據(jù)庫(kù)更看重的是吞吐，而不是單筆SQL響應(yīng)時(shí)間的原因。
成熟度與生態(tài)
分布式數(shù)據(jù)庫(kù)是個(gè)新型通用底層軟件，準(zhǔn)確的衡量與評(píng)價(jià)需要一個(gè)多維度的測(cè)試模型，需包括發(fā)展現(xiàn)狀、使用情況、社區(qū)生態(tài)、監(jiān)控運(yùn)維、周邊配套工具、功能滿(mǎn)足度、DBA人才、SQL兼容性、性能測(cè)試、高可用測(cè)試、在線擴(kuò)容、分布式事務(wù)、隔離級(jí)別、在線DDL等等，雖然NewSQL數(shù)據(jù)庫(kù)發(fā)展經(jīng)過(guò)了一定時(shí)間檢驗(yàn)，但多集中在互聯(lián)網(wǎng)以及傳統(tǒng)企業(yè)非核心交易系統(tǒng)中，目前還處于快速迭代、規(guī)模使用不斷優(yōu)化完善的階段。
相比而言，傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)則經(jīng)過(guò)了多年的發(fā)展，通過(guò)完整的評(píng)測(cè)，在成熟度、功能、性能、周邊生態(tài)、風(fēng)險(xiǎn)把控、相關(guān)人才積累等多方面都具有明顯優(yōu)勢(shì)，同時(shí)對(duì)已建系統(tǒng)的兼容性也更好。
對(duì)于互聯(lián)網(wǎng)公司，數(shù)據(jù)量的增長(zhǎng)壓力以及追求新技術(shù)的基因會(huì)更傾向于嘗試NewSQL數(shù)據(jù)庫(kù)，不用再考慮庫(kù)表拆分、應(yīng)用改造、擴(kuò)容、事務(wù)一致性等問(wèn)題怎么看都是非常吸引人的方案。
對(duì)于傳統(tǒng)企業(yè)例如銀行這種風(fēng)險(xiǎn)意識(shí)較高的行業(yè)來(lái)說(shuō)，NewSQL數(shù)據(jù)庫(kù)則可能在未來(lái)一段時(shí)間內(nèi)仍處于 探索 、審慎試點(diǎn)的階段?；谥虚g件+分庫(kù)分表模式架構(gòu)簡(jiǎn)單，技術(shù)門(mén)檻更低，雖然沒(méi)有NewSQL數(shù)據(jù)庫(kù)功能全面，但大部分場(chǎng)景最核心的訴求也就是拆分后SQL的正確路由，而此功能中間件模式應(yīng)對(duì)還是綽綽有余的，可以說(shuō)在大多數(shù)OLTP場(chǎng)景是夠用的。
限于篇幅，其它特性例如在線DDL、數(shù)據(jù)遷移、運(yùn)維工具等特性就不在本文展開(kāi)對(duì)比。
總結(jié)
如果看完以上內(nèi)容，您還不知道選哪種模式，那么結(jié)合以下幾個(gè)問(wèn)題，先思考下NewSQL數(shù)據(jù)庫(kù)解決的點(diǎn)對(duì)于自身是不是真正的痛點(diǎn)：
如果以上有2到3個(gè)是肯定的，那么你可以考慮用NewSQL數(shù)據(jù)庫(kù)了，雖然前期可能需要一定的學(xué)習(xí)成本，但它是數(shù)據(jù)庫(kù)的發(fā)展方向，未來(lái)收益也會(huì)更高，尤其是互聯(lián)網(wǎng)行業(yè)，隨著數(shù)據(jù)量的突飛猛進(jìn)，分庫(kù)分表帶來(lái)的痛苦會(huì)與日俱增。當(dāng)然選擇NewSQL數(shù)據(jù)庫(kù)你也要做好承擔(dān)一定風(fēng)險(xiǎn)的準(zhǔn)備。
如果你還未做出抉擇，不妨再想想下面幾個(gè)問(wèn)題：
如果這些問(wèn)題有多數(shù)是肯定的，那還是分庫(kù)分表吧。在軟件領(lǐng)域很少有完美的解決方案，NewSQL數(shù)據(jù)庫(kù)也不是數(shù)據(jù)分布式架構(gòu)的銀彈。相比而言分庫(kù)分表是一個(gè)代價(jià)更低、風(fēng)險(xiǎn)更小的方案，它最大程度復(fù)用傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)生態(tài)，通過(guò)中間件也可以滿(mǎn)足分庫(kù)分表后的絕大多數(shù)功能，定制化能力更強(qiáng)。 在當(dāng)前NewSQL數(shù)據(jù)庫(kù)還未完全成熟的階段，分庫(kù)分表可以說(shuō)是一個(gè)上限低但下限高的方案，尤其傳統(tǒng)行業(yè)的核心系統(tǒng)，如果你仍然打算把數(shù)據(jù)庫(kù)當(dāng)做一個(gè)黑盒產(chǎn)品來(lái)用，踏踏實(shí)實(shí)用好分庫(kù)分表會(huì)被認(rèn)為是個(gè)穩(wěn)妥的選擇。
很多時(shí)候軟件選型取決于領(lǐng)域特征以及架構(gòu)師風(fēng)格，限于筆者知識(shí)與所屬行業(yè)特點(diǎn)所限，以上僅為個(gè)人粗淺的一些觀點(diǎn)，歡迎討論。
為什么PostgreSQL比MongoDB還快
PostgreSQL9.4帶來(lái)了全新的NoSQL特性，并且根據(jù)EnterpriseDB的測(cè)試，其加載，插入和查詢(xún)的性能都已經(jīng)幾倍于MongoDB了。
雖然我是PG的鐵桿粉絲，但是關(guān)系數(shù)據(jù)庫(kù)背負(fù)了ACID的重型裝甲，在性能上居然能打敗輕裝上陣的NoSQL數(shù)據(jù)庫(kù)總覺(jué)得有點(diǎn)離譜。
所以我在自己的環(huán)境里驗(yàn)證了一下EnterpriseDB的測(cè)試結(jié)果，并且小探一下PG取勝的原因。
1. EnterpriseDB的測(cè)試結(jié)果
以下是EnterpriseDB的測(cè)試結(jié)果(數(shù)據(jù)量為5000萬(wàn))
（還可以參考這篇譯文： ）
2. 我的驗(yàn)證結(jié)果
測(cè)試觀點(diǎn)
為了使測(cè)試結(jié)果更加單純，我準(zhǔn)備單純比拼CPU消耗(盡量排除IO和網(wǎng)絡(luò)的干擾)，設(shè)定以下測(cè)試條件。
1）所有數(shù)據(jù)都要放進(jìn)內(nèi)存
2）C/S都跑在同一臺(tái)單機(jī)上
所以，只在單機(jī)上進(jìn)行10萬(wàn)條小數(shù)據(jù)量的測(cè)試。
注）EnterpriseDB的測(cè)試環(huán)境是32G內(nèi)存的Amazon Web Services M3.2XLARGE實(shí)例，總數(shù)據(jù)量超過(guò)內(nèi)存了。
測(cè)試環(huán)境
測(cè)試環(huán)境為個(gè)人PC上的VMware虛擬機(jī)
PC
CPU:Intel Core i5-3470 3.2G(4核)
MEM:6GB
SSD:OCZ-VERTEX4 128GB(VMware虛擬機(jī)所在磁盤(pán)，非系統(tǒng)盤(pán))
OS:Win7
VMware虛擬機(jī)
CPU:4核
MEM:1GB
OS:CentOS 6.5
PG:PostgreSQL 9.4.0(shared_buffers = 428MB,其他是默認(rèn)值)
MG:MongoDB 3.0.2
測(cè)試步驟
測(cè)試步驟非常簡(jiǎn)單,可以參考：
但是，在測(cè)試前，有些東西要改。
1)把數(shù)據(jù)量減小到10萬(wàn)
pg_nosql_benchmark-master/pg_nosql_benchmark:
declare -a json_rows=(10000000)
==
declare -a json_rows=(100000)
2)修改mongo的一處腳本(注)
pg_nosql_benchmark-master/lib/mongo_func_lib.sh:
collectionsize="$(echo ${output}|awk -F"," '{print $5}'|cut -d":" -f2)"
==
collectionsize="$(echo ${output}|awk -F"," '{print $6}'|cut -d":" -f2)"
注)pg_nosql_benchmark原來(lái)是基于MongoDB 2.6設(shè)計(jì)的，MongoDB 3.0的db.json_tables.stats()輸出可能變了，所以這邊要修改一下。
Renix Perf IP網(wǎng)絡(luò)性能測(cè)試工具及測(cè)試用例參數(shù)詳解
1.1基于軟件的網(wǎng)絡(luò)及應(yīng)用服務(wù)性能測(cè)試工具
雙臂測(cè)試
單臂測(cè)試
1.2通過(guò)測(cè)試端點(diǎn)產(chǎn)生網(wǎng)絡(luò)流量對(duì)網(wǎng)絡(luò)性能進(jìn)行測(cè)量
TCP、UDP、PING
語(yǔ)音、視頻、HTTP、FTP、MAIL、組播
1.3測(cè)試端點(diǎn)軟件可以免費(fèi)安裝部署
局域網(wǎng)公網(wǎng)
2.1控制端（TestConsole）
●安裝于Windows7(64位）
●4核CPU，8GB內(nèi)存以上
150GB硬盤(pán)
2.2測(cè)試端點(diǎn)（TestPoint）
●軟件測(cè)試端點(diǎn)支持Linux、Windows、Android、VxWorks、各種國(guó)產(chǎn)OS
●硬件測(cè)試端點(diǎn)
3.1專(zhuān)有硬件盒子
3.2支持的OS
Windows；Linux；Android；國(guó)產(chǎn)OS
3.3支持的CPU架構(gòu)x86；PCPU；ARM；MIPS；Alpha?
3.4網(wǎng)絡(luò)接口 以太網(wǎng)；WiFi；3G、4G、5G
真實(shí)的協(xié)議棧，有狀態(tài)的Layer3-7應(yīng)用流量的產(chǎn)生和分析
測(cè)試端點(diǎn)支持計(jì)算平臺(tái)廣泛，支持高效的客戶(hù)定制化開(kāi)發(fā)
支持大數(shù)據(jù)量存儲(chǔ)，超長(zhǎng)時(shí)間的不間斷測(cè)試
Windows控制端、SQL及NoSQL數(shù)據(jù)存儲(chǔ)
運(yùn)行于64位 Windows測(cè)試管理測(cè)試端點(diǎn)資源；測(cè)試端點(diǎn)映射；測(cè)試用例測(cè)試報(bào)告
TestPoint輸入測(cè)試控制端IP運(yùn)行后注冊(cè)到測(cè)試控制端顯示每個(gè)TestPoint主機(jī)名、IP等信息
創(chuàng)建邏輯（虛擬）測(cè)試端點(diǎn)
將測(cè)試端點(diǎn)資源中測(cè)試端點(diǎn)映射到邏輯測(cè)試端點(diǎn)
測(cè)試資源與測(cè)試配置解耦合
測(cè)試配置可分享
無(wú)真實(shí)測(cè)試端點(diǎn)可預(yù)先做測(cè)試配置
更換測(cè)試端點(diǎn)后，無(wú)需重新再配置
定義測(cè)試用例名稱(chēng)與測(cè)試時(shí)長(zhǎng)用例依次串行方式執(zhí)行
測(cè)試鏈路配置協(xié)議，測(cè)試端點(diǎn)1和測(cè)試端點(diǎn)2，以及協(xié)議參數(shù)
1.1通過(guò)PC或者手機(jī)的WLAN接口包圍無(wú)線CPE，TestPoint產(chǎn)生流量執(zhí)行CPE性能測(cè)試，
1.2常見(jiàn)測(cè)試項(xiàng)目：
無(wú)線基準(zhǔn)性能測(cè)試
無(wú)線衰減測(cè)試
天線方向性測(cè)試
無(wú)線信道測(cè)試
信道競(jìng)爭(zhēng)測(cè)試
無(wú)線并發(fā)測(cè)試
無(wú)線遠(yuǎn)近距離測(cè)試
穩(wěn)定性測(cè)試
環(huán)境適應(yīng)性測(cè)試
2.1 在虛擬化平臺(tái)的VM中部署TestPoint，測(cè)試vSwitch的交換性能
2.2常見(jiàn)測(cè)試指標(biāo)：吞吐量；時(shí)延；丟失率；亂序
3.1在服務(wù)器不同類(lèi)型OS中部署TestPoint，通過(guò)多對(duì)一的方式測(cè)試服務(wù)器網(wǎng)絡(luò)性能
3.2常見(jiàn)測(cè)試指標(biāo)：吞吐量TCP業(yè)務(wù)交易速率\交易時(shí)間UDP業(yè)務(wù)交易速率\交易時(shí)間
在網(wǎng)絡(luò)端到端兩頭部署TestPoint，通過(guò)一對(duì)一的方式測(cè)試網(wǎng)絡(luò)的承載指標(biāo)常見(jiàn)測(cè)試指標(biāo)：TCP\UDP吞吐量；單向延遲；抖動(dòng)；亂序
本文名稱(chēng)：nosql性能測(cè)試,淺談nosql技術(shù)及應(yīng)用論文
網(wǎng)站URL：http://fisionsoft.com.cn/article/dsicgsh.html
