newsql和nosql的區(qū)別和聯(lián)系

在大數(shù)據(jù)時代，“多種架構(gòu)支持多類應(yīng)用”成為數(shù)據(jù)庫行業(yè)應(yīng)對大數(shù)據(jù)的基本思路，數(shù)據(jù)庫行業(yè)出現(xiàn)互為補(bǔ)充的三大陣營，適用于事務(wù)處理應(yīng)用的OldSQL、適用于數(shù)據(jù)分析應(yīng)用的NewSQL和適用于互聯(lián)網(wǎng)應(yīng)用的NoSQL。但在一些復(fù)雜的應(yīng)用場景中，單一數(shù)據(jù)庫架構(gòu)都不能完全滿足應(yīng)用場景對海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的存儲管理、復(fù)雜分析、關(guān)聯(lián)查詢、實時性處理和控制建設(shè)成本等多方面的需要，因此不同架構(gòu)數(shù)據(jù)庫混合部署應(yīng)用成為滿足復(fù)雜應(yīng)用的必然選擇。不同架構(gòu)數(shù)據(jù)庫混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個案例對不同架構(gòu)數(shù)據(jù)庫的混合應(yīng)用部署進(jìn)行介紹。

成都創(chuàng)新互聯(lián)是一家專業(yè)提供廣信企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站制作、做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設(shè)、H5場景定制、小程序制作等業(yè)務(wù)。10年已為廣信眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。

OldSQL+NewSQL 在數(shù)據(jù)中心類應(yīng)用中混合部署

采用OldSQL+NewSQL模式構(gòu)建數(shù)據(jù)中心，在充分發(fā)揮OldSQL數(shù)據(jù)庫的事務(wù)處理能力的同時，借助NewSQL在實時性、復(fù)雜分析、即席查詢等方面的獨特優(yōu)勢，以及面對海量數(shù)據(jù)時較強(qiáng)的擴(kuò)展能力，滿足數(shù)據(jù)中心對當(dāng)前“熱”數(shù)據(jù)事務(wù)型處理和海量歷史“冷”數(shù)據(jù)分析兩方面的需求。OldSQL+NewSQL模式在數(shù)據(jù)中心類應(yīng)用中的互補(bǔ)作用體現(xiàn)在，OldSQL彌補(bǔ)了NewSQL不適合事務(wù)處理的不足，NewSQL彌補(bǔ)了OldSQL在海量數(shù)據(jù)存儲能力和處理性能方面的缺陷。

商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL數(shù)據(jù)庫滿足各業(yè)務(wù)系統(tǒng)數(shù)據(jù)的歸檔備份和事務(wù)型應(yīng)用，NewSQL MPP數(shù)據(jù)庫集群對即席查詢、多維分析等應(yīng)用提供高性能支持，并且通過MPP集群架構(gòu)實現(xiàn)應(yīng)對海量數(shù)據(jù)存儲的擴(kuò)展能力。

商業(yè)銀行數(shù)據(jù)中心存儲架構(gòu)

與傳統(tǒng)的OldSQL模式相比，商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合搭建模式，數(shù)據(jù)加載性能提升3倍以上，即席查詢和統(tǒng)計分析性能提升6倍以上。NewSQL MPP的高可擴(kuò)展性能夠應(yīng)對新的業(yè)務(wù)需求，可隨著數(shù)據(jù)量的增長采用集群方式構(gòu)建存儲容量更大的數(shù)據(jù)中心。

OldSQL+NoSQL 在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中混合部署

在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中采用OldSQL+NoSQL混合模式，能夠很好的解決互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用對海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行存儲和快速處理的需求。在諸如大型電子商務(wù)平臺、大型SNS平臺等互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用場景中，OldSQL在應(yīng)用中負(fù)責(zé)高價值密度結(jié)構(gòu)化數(shù)據(jù)的存儲和事務(wù)型處理，NoSQL在應(yīng)用中負(fù)責(zé)存儲和處理海量非結(jié)構(gòu)化的數(shù)據(jù)和低價值密度結(jié)構(gòu)化數(shù)據(jù)。OldSQL+NoSQL模式在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中的互補(bǔ)作用體現(xiàn)在，OldSQL彌補(bǔ)了NoSQL在ACID特性和復(fù)雜關(guān)聯(lián)運(yùn)算方面的不足，NoSQL彌補(bǔ)了OldSQL在海量數(shù)據(jù)存儲和非結(jié)構(gòu)化數(shù)據(jù)處理方面的缺陷。

數(shù)據(jù)魔方是淘寶網(wǎng)的一款數(shù)據(jù)產(chǎn)品，主要提供行業(yè)數(shù)據(jù)分析、店鋪數(shù)據(jù)分析。淘寶數(shù)據(jù)產(chǎn)品在存儲層采用OldSQL+NoSQL混合模式，由基于MySQL的分布式關(guān)系型數(shù)據(jù)庫集群MyFOX和基于HBase的NoSQL存儲集群Prom組成。由于OldSQL強(qiáng)大的語義和關(guān)系表達(dá)能力，在應(yīng)用中仍然占據(jù)著重要地位，目前存儲在MyFOX中的統(tǒng)計結(jié)果數(shù)據(jù)已經(jīng)達(dá)到10TB，占據(jù)著數(shù)據(jù)魔方總數(shù)據(jù)量的95%以上。另一方面，NoSQL作為SQL的有益補(bǔ)充，解決了OldSQL數(shù)據(jù)庫無法解決的全屬性選擇器等問題。

淘寶海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)

基于OldSQL+NoSQL混合架構(gòu)的特點，數(shù)據(jù)魔方目前已經(jīng)能夠提供壓縮前80TB的數(shù)據(jù)存儲空間，支持每天4000萬的查詢請求，平均響應(yīng)時間在28毫秒，足以滿足未來一段時間內(nèi)的業(yè)務(wù)增長需求。

NewSQL+NoSQL 在行業(yè)大數(shù)據(jù)應(yīng)用中混合部署

行業(yè)大數(shù)據(jù)與互聯(lián)網(wǎng)大數(shù)據(jù)的區(qū)別在于行業(yè)大數(shù)據(jù)的價值密度更高，并且對結(jié)構(gòu)化數(shù)據(jù)的實時處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強(qiáng)一致性等都比互聯(lián)網(wǎng)大數(shù)據(jù)有更高的要求。行業(yè)大數(shù)據(jù)應(yīng)用場景主要是分析類應(yīng)用，如：電信、金融、政務(wù)、能源等行業(yè)的決策輔助、預(yù)測預(yù)警、統(tǒng)計分析、經(jīng)營分析等。

在行業(yè)大數(shù)據(jù)應(yīng)用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在結(jié)構(gòu)化數(shù)據(jù)分析處理方面的優(yōu)勢，以及NoSQL在非結(jié)構(gòu)數(shù)據(jù)處理方面的優(yōu)勢，實現(xiàn)NewSQL與NoSQL的功能互補(bǔ)，解決行業(yè)大數(shù)據(jù)應(yīng)用對高價值結(jié)構(gòu)化數(shù)據(jù)的實時處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強(qiáng)一致性等要求，以及對海量非結(jié)構(gòu)化數(shù)據(jù)存儲和精確查詢的要求。在應(yīng)用中，NewSQL承擔(dān)高價值密度結(jié)構(gòu)化數(shù)據(jù)的存儲和分析處理工作，NoSQL承擔(dān)存儲和處理海量非結(jié)構(gòu)化數(shù)據(jù)和不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的低價值密度結(jié)構(gòu)化數(shù)據(jù)的工作。

當(dāng)前電信運(yùn)營商在集中化BI系統(tǒng)建設(shè)過程中面臨著數(shù)據(jù)規(guī)模大、數(shù)據(jù)處理類型多等問題，并且需要應(yīng)對大量的固定應(yīng)用，以及占統(tǒng)計總數(shù)80%以上的突發(fā)性臨時統(tǒng)計(ad-hoc)需求。在集中化BI系統(tǒng)的建設(shè)中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復(fù)雜分析、即席查詢等方面處理性能的優(yōu)勢，及NoSQL在非結(jié)構(gòu)化數(shù)據(jù)處理和海量數(shù)據(jù)存儲方面的優(yōu)勢，實現(xiàn)高效低成本。

集中化BI系統(tǒng)數(shù)據(jù)存儲架構(gòu)

集中化BI系統(tǒng)按照數(shù)據(jù)類型和處理方式的不同，將結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)分別存儲在不同的系統(tǒng)中：非結(jié)構(gòu)化數(shù)據(jù)在Hadoop平臺上存儲與處理;結(jié)構(gòu)化、不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的數(shù)據(jù)保存在NoSQL數(shù)據(jù)庫或Hadoop平臺;結(jié)構(gòu)化、需要關(guān)聯(lián)分析或經(jīng)常ad-hoc查詢的數(shù)據(jù)，保存在NewSQL MPP數(shù)據(jù)庫中，短期高價值數(shù)據(jù)放在高性能平臺，中長期放在低成本產(chǎn)品中。

結(jié)語

當(dāng)前信息化應(yīng)用的多樣性、復(fù)雜性，以及三種數(shù)據(jù)庫架構(gòu)各自所具有的優(yōu)勢和局限性，造成任何一種架構(gòu)的數(shù)據(jù)庫都不能完全滿足應(yīng)用需求，因此不同架構(gòu)數(shù)據(jù)庫混合使用，從而彌補(bǔ)其他架構(gòu)的不足成為必然選擇。根據(jù)應(yīng)用場景采用不同架構(gòu)數(shù)據(jù)庫進(jìn)行組合搭配，充分發(fā)揮每種架構(gòu)數(shù)據(jù)庫的特點和優(yōu)勢，并且與其他架構(gòu)數(shù)據(jù)庫形成互補(bǔ)，完全涵蓋應(yīng)用需求，保證數(shù)據(jù)資源的最優(yōu)化利用，將成為未來一段時期內(nèi)信息化應(yīng)用主要采用的解決方式。

目前在國內(nèi)市場上，OldSQL主要為Oracle、IBM等國外數(shù)據(jù)庫廠商所壟斷，達(dá)夢、金倉等國產(chǎn)廠商仍處于追趕狀態(tài);南大通用憑借國產(chǎn)新型數(shù)據(jù)庫GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場三強(qiáng);NoSQL方面用戶則大多采用Hadoop開源方案。

ssdb、minio性能測試c

項目上需要找一個硬盤型的NoSQL，用于將 Redis 中的冷數(shù)據(jù)落入硬盤。初步選型了幾款 key-value 類型的NoSQL，分別有 levelDB、 rocksDB、 TiDB、 SSDB、swapDB、 Kvrocks、Tikv 。均為基于 levelDB 開發(fā)的幾款NoSQL。其中因為 levelDB、rocksDB 無網(wǎng)絡(luò)接口，不方便做分布式和高可用。， TiDB 過重，還有 swapDB 社區(qū)不夠活躍且相關(guān)client API不完備。暫時選型 SSDB 。

項目需要存儲的其實是一個略長的二進(jìn)制字符串，初步認(rèn)為，使用 對象存儲 方案其實也可以替代NoSQL，所以壓測對象添加當(dāng)前非常火的云原生對象存儲 MinIO

硬件名|配置 系統(tǒng)| Ubuntu(基于win10 wsl版的docker啟動) 內(nèi)存| 16GB(實際可用6.08G) CPU| Intel i5-8400

測試項目： 1. 寫50M數(shù)據(jù)100次 2. 隨機(jī)讀取任意key 100次（對LRU機(jī)制不友好）

寫

數(shù)據(jù)導(dǎo)入成功！

數(shù)據(jù)序列化成功！

a 數(shù)據(jù)大小:50.99295234680176 MB

第1次寫入總用時: 797 ms

第2次寫入總用時: 848 ms

第3次寫入總用時: 3621 ms

第4次寫入總用時: 813 ms

第5次寫入總用時: 1862 ms

第6次寫入總用時: 838 ms

第7次寫入總用時: 2235 ms

第8次寫入總用時: 836 ms

第9次寫入總用時: 900 ms

第10次寫入總用時: 1027 ms

第11次寫入總用時: 1101 ms

第12次寫入總用時: 880 ms

第13次寫入總用時: 1956 ms

第14次寫入總用時: 866 ms

第15次寫入總用時: 2422 ms

第16次寫入總用時: 852 ms

第17次寫入總用時: 4511 ms

第18次寫入總用時: 875 ms

第19次寫入總用時: 2736 ms

第20次寫入總用時: 814 ms

第21次寫入總用時: 7172 ms

第22次寫入總用時: 891 ms

第23次寫入總用時: 7820 ms

第24次寫入總用時: 836 ms

第25次寫入總用時: 22103 ms

第26次寫入總用時: 877 ms

第27次寫入總用時: 2712 ms

第28次寫入總用時: 841 ms

第29次寫入總用時: 1928 ms

第30次寫入總用時: 916 ms

第31次寫入總用時: 839 ms

第32次寫入總用時: 826 ms

第33次寫入總用時: 7759 ms

第34次寫入總用時: 843 ms

第35次寫入總用時: 10670 ms

第36次寫入總用時: 843 ms

第37次寫入總用時: 9361 ms

第38次寫入總用時: 821 ms

第39次寫入總用時: 810 ms

第40次寫入總用時: 794 ms

第41次寫入總用時: 13281 ms

第42次寫入總用時: 833 ms

第43次寫入總用時: 811 ms

第44次寫入總用時: 798 ms

第45次寫入總用時: 18843 ms

第46次寫入總用時: 911 ms

第47次寫入總用時: 9428 ms

第48次寫入總用時: 898 ms

第49次寫入總用時: 17582 ms

第50次寫入總用時: 903 ms

第51次寫入總用時: 831 ms

第52次寫入總用時: 800 ms

第53次寫入總用時: 14602 ms

第54次寫入總用時: 827 ms

第55次寫入總用時: 5898 ms

第56次寫入總用時: 856 ms

第57次寫入總用時: 5693 ms

第58次寫入總用時: 1050 ms

第59次寫入總用時: 882 ms

第60次寫入總用時: 1020 ms

第61次寫入總用時: 15060 ms

第62次寫入總用時: 902 ms

第63次寫入總用時: 1062 ms

第64次寫入總用時: 915 ms

第65次寫入總用時: 7572 ms

第66次寫入總用時: 823 ms

第67次寫入總用時: 9649 ms

第68次寫入總用時: 832 ms

第69次寫入總用時: 10403 ms

第70次寫入總用時: 907 ms

第71次寫入總用時: 978 ms

第72次寫入總用時: 789 ms

第73次寫入總用時: 2111 ms

第74次寫入總用時: 947 ms

第75次寫入總用時: 4675 ms

第76次寫入總用時: 944 ms

第77次寫入總用時: 8592 ms

第78次寫入總用時: 832 ms

第79次寫入總用時: 2940 ms

第80次寫入總用時: 842 ms

第81次寫入總用時: 19835 ms

第82次寫入總用時: 862 ms

第83次寫入總用時: 7646 ms

第84次寫入總用時: 873 ms

第85次寫入總用時: 1002 ms

第86次寫入總用時: 842 ms

第87次寫入總用時: 9057 ms

第88次寫入總用時: 801 ms

第89次寫入總用時: 5117 ms

第90次寫入總用時: 918 ms

第91次寫入總用時: 798 ms

第92次寫入總用時: 853 ms

第93次寫入總用時: 7728 ms

第94次寫入總用時: 810 ms

第95次寫入總用時: 3969 ms

第96次寫入總用時: 814 ms

第97次寫入總用時: 2050 ms

第98次寫入總用時: 819 ms

第99次寫入總用時: 9566 ms

第100次寫入總用時: 833 ms/pre

隨機(jī)讀

第1次讀取 15總用時: 2251 ms

第2次讀取 73總用時: 2045 ms

第3次讀取 98總用時: 1548 ms

第4次讀取 20總用時: 2683 ms

第5次讀取 46總用時: 1156 ms

第6次讀取 69總用時: 1160 ms

第7次讀取 46總用時: 1520 ms

第8次讀取 51總用時: 1381 ms

第9次讀取 48總用時: 1000 ms

第10次讀取 69總用時: 1400 ms

第11次讀取 82總用時: 1236 ms

第12次讀取 22總用時: 1140 ms

第13次讀取 36總用時: 864 ms

第14次讀取 66總用時: 843 ms

第15次讀取 47總用時: 922 ms

第16次讀取 17總用時: 885 ms

第17次讀取 14總用時: 864 ms

第18次讀取 64總用時: 888 ms

第19次讀取 74總用時: 815 ms

第20次讀取 33總用時: 866 ms

第21次讀取 36總用時: 822 ms

第22次讀取 78總用時: 975 ms

第23次讀取 40總用時: 1186 ms

第24次讀取 54總用時: 857 ms

第25次讀取 92總用時: 963 ms

第26次讀取 43總用時: 955 ms

第27次讀取 38總用時: 853 ms

第28次讀取 47總用時: 926 ms

第29次讀取 62總用時: 877 ms

第30次讀取 70總用時: 890 ms

第31次讀取 88總用時: 895 ms

第32次讀取 15總用時: 937 ms

第33次讀取 3總用時: 993 ms

第34次讀取 99總用時: 892 ms

第35次讀取 76總用時: 818 ms

第36次讀取 30總用時: 1020 ms

第37次讀取 89總用時: 863 ms

第38次讀取 99總用時: 819 ms

第39次讀取 62總用時: 818 ms

第40次讀取 1總用時: 871 ms

第41次讀取 66總用時: 809 ms

第42次讀取 68總用時: 847 ms

第43次讀取 72總用時: 910 ms

第44次讀取 50總用時: 1128 ms

第45次讀取 47總用時: 898 ms

第46次讀取 26總用時: 909 ms

第47次讀取 35總用時: 872 ms

第48次讀取 30總用時: 826 ms

第49次讀取 79總用時: 904 ms

第50次讀取 66總用時: 863 ms

第51次讀取 2總用時: 885 ms

第52次讀取 65總用時: 900 ms

第53次讀取 67總用時: 1023 ms

第54次讀取 16總用時: 934 ms

第55次讀取 63總用時: 892 ms

第56次讀取 9總用時: 894 ms

第57次讀取 71總用時: 896 ms

第58次讀取 20總用時: 947 ms

第59次讀取 89總用時: 865 ms

第60次讀取 57總用時: 872 ms

第61次讀取 62總用時: 856 ms

第62次讀取 14總用時: 881 ms

第63次讀取 19總用時: 950 ms

第64次讀取 14總用時: 876 ms

第65次讀取 86總用時: 968 ms

第66次讀取 12總用時: 911 ms

第67次讀取 93總用時: 877 ms

第68次讀取 59總用時: 886 ms

第69次讀取 79總用時: 878 ms

第70次讀取 49總用時: 869 ms

第71次讀取 91總用時: 964 ms

第72次讀取 38總用時: 838 ms

第73次讀取 73總用時: 915 ms

第74次讀取 8總用時: 875 ms

第75次讀取 96總用時: 827 ms

第76次讀取 98總用時: 826 ms

第77次讀取 95總用時: 892 ms

第78次讀取 36總用時: 843 ms

第79次讀取 44總用時: 872 ms

第80次讀取 89總用時: 863 ms

第81次讀取 24總用時: 883 ms

第82次讀取 89總用時: 804 ms

第83次讀取 49總用時: 876 ms

第84次讀取 81總用時: 873 ms

第85次讀取 72總用時: 914 ms

第86次讀取 68總用時: 861 ms

第87次讀取 73總用時: 893 ms

第88次讀取 4總用時: 880 ms

第89次讀取 3總用時: 987 ms

第90次讀取 76總用時: 896 ms

第91次讀取 16總用時: 1010 ms

第92次讀取 73總用時: 903 ms

第93次讀取 83總用時: 933 ms

第94次讀取 52總用時: 945 ms

第95次讀取 48總用時: 901 ms

第96次讀取 26總用時: 942 ms

第97次讀取 37總用時: 883 ms

第98次讀取 44總用時: 866 ms

第99次讀取 89總用時: 921 ms

第100次讀取 61總用時: 896 ms/pre

寫

數(shù)據(jù)導(dǎo)入成功！

第1次寫入總用時: 956 ms

第2次寫入總用時: 912 ms

第3次寫入總用時: 1241 ms

第4次寫入總用時: 1564 ms

第5次寫入總用時: 942 ms

第6次寫入總用時: 3666 ms

第7次寫入總用時: 1629 ms

第8次寫入總用時: 1712 ms

第9次寫入總用時: 977 ms

第10次寫入總用時: 1515 ms

第11次寫入總用時: 911 ms

第12次寫入總用時: 1009 ms

第13次寫入總用時: 1024 ms

第14次寫入總用時: 1206 ms

第15次寫入總用時: 984 ms

第16次寫入總用時: 943 ms

第17次寫入總用時: 954 ms

第18次寫入總用時: 1033 ms

第19次寫入總用時: 1008 ms

第20次寫入總用時: 1121 ms

第21次寫入總用時: 963 ms

第22次寫入總用時: 949 ms

第23次寫入總用時: 889 ms

第24次寫入總用時: 1066 ms

第25次寫入總用時: 1289 ms

第26次寫入總用時: 1125 ms

第27次寫入總用時: 1111 ms

第28次寫入總用時: 953 ms

第29次寫入總用時: 964 ms

第30次寫入總用時: 1125 ms

第31次寫入總用時: 998 ms

第32次寫入總用時: 1993 ms

第33次寫入總用時: 926 ms

第34次寫入總用時: 920 ms

第35次寫入總用時: 926 ms

第36次寫入總用時: 1169 ms

第37次寫入總用時: 1325 ms

第38次寫入總用時: 1170 ms

第39次寫入總用時: 1074 ms

第40次寫入總用時: 1011 ms

第41次寫入總用時: 931 ms

第42次寫入總用時: 984 ms

第43次寫入總用時: 1563 ms

第44次寫入總用時: 905 ms

第45次寫入總用時: 944 ms

第46次寫入總用時: 1147 ms

第47次寫入總用時: 1429 ms

第48次寫入總用時: 934 ms

第49次寫入總用時: 1133 ms

第50次寫入總用時: 912 ms

第51次寫入總用時: 953 ms

第52次寫入總用時: 1127 ms

第53次寫入總用時: 1065 ms

第54次寫入總用時: 1323 ms

第55次寫入總用時: 1003 ms

第56次寫入總用時: 1489 ms

第57次寫入總用時: 1377 ms

第58次寫入總用時: 940 ms

第59次寫入總用時: 1317 ms

第60次寫入總用時: 912 ms

第61次寫入總用時: 898 ms

第62次寫入總用時: 934 ms

第63次寫入總用時: 1005 ms

第64次寫入總用時: 1729 ms

第65次寫入總用時: 983 ms

第66次寫入總用時: 1684 ms

第67次寫入總用時: 908 ms

第68次寫入總用時: 895 ms

第69次寫入總用時: 1171 ms

第70次寫入總用時: 1372 ms

第71次寫入總用時: 1261 ms

第72次寫入總用時: 1024 ms

第73次寫入總用時: 1048 ms

第74次寫入總用時: 904 ms

第75次寫入總用時: 941 ms

第76次寫入總用時: 928 ms

第77次寫入總用時: 1806 ms

第78次寫入總用時: 1052 ms

第79次寫入總用時: 1030 ms

第80次寫入總用時: 1092 ms

第81次寫入總用時: 1117 ms

第82次寫入總用時: 950 ms

第83次寫入總用時: 933 ms

第84次寫入總用時: 928 ms

第85次寫入總用時: 935 ms

第86次寫入總用時: 1908 ms

第87次寫入總用時: 994 ms

第88次寫入總用時: 1097 ms

第89次寫入總用時: 930 ms

第90次寫入總用時: 1052 ms

第91次寫入總用時: 1119 ms

第92次寫入總用時: 958 ms

第93次寫入總用時: 987 ms

第94次寫入總用時: 973 ms

第95次寫入總用時: 2036 ms

第96次寫入總用時: 891 ms

第97次寫入總用時: 954 ms

第98次寫入總用時: 951 ms

第99次寫入總用時: 1044 ms

第100次寫入總用時: 1366 ms/pre

隨機(jī)讀

第1次讀取 46總用時: 40 ms

第2次讀取 8總用時: 36 ms

第3次讀取 28總用時: 26 ms

第4次讀取 80總用時: 10 ms

第5次讀取 77總用時: 13 ms

第6次讀取 27總用時: 49 ms

第7次讀取 86總用時: 20 ms

第8次讀取 0總用時: 45 ms

第9次讀取 54總用時: 34 ms

第10次讀取 24總用時: 153 ms

第11次讀取 78總用時: 29 ms

第12次讀取 0總用時: 17 ms

第13次讀取 91總用時: 56 ms

第14次讀取 5總用時: 99 ms

第15次讀取 23總用時: 138 ms

第16次讀取 37總用時: 120 ms

第17次讀取 40總用時: 156 ms

第18次讀取 88總用時: 41 ms

第19次讀取 76總用時: 32 ms

第20次讀取 49總用時: 102 ms

第21次讀取 20總用時: 179 ms

第22次讀取 40總用時: 68 ms

第23次讀取 6總用時: 215 ms

第24次讀取 36總用時: 197 ms

第25次讀取 37總用時: 30 ms

第26次讀取 68總用時: 154 ms

第27次讀取 14總用時: 314 ms

第28次讀取 27總用時: 91 ms

第29次讀取 51總用時: 255 ms

第30次讀取 66總用時: 166 ms

第31次讀取 86總用時: 140 ms

第32次讀取 29總用時: 374 ms

第33次讀取 96總用時: 235 ms

第34次讀取 68總用時: 72 ms

第35次讀取 74總用時: 264 ms

第36次讀取 11總用時: 334 ms

第37次讀取 55總用時: 316 ms

第38次讀取 31總用時: 287 ms

第39次讀取 93總用時: 233 ms

第40次讀取 44總用時: 499 ms

第41次讀取 26總用時: 312 ms

第42次讀取 76總用時: 33 ms

第43次讀取 11總用時: 31 ms

第44次讀取 86總用時: 191 ms

第45次讀取 96總用時: 217 ms

第46次讀取 20總用時: 145 ms

第47次讀取 1總用時: 772 ms

第48次讀取 69總用時: 477 ms

第49次讀取 9總用時: 320 ms

第50次讀取 46總用時: 42 ms

第51次讀取 34總用時: 823 ms

第52次讀取 76總用時: 115 ms

第53次讀取 62總用時: 635 ms

第54次讀取 99總用時: 596 ms

第55次讀取 64總用時: 657 ms

第56次讀取 66總用時: 97 ms

第57次讀取 18總用時: 461 ms

第58次讀取 91總用時: 247 ms

第59次讀取 46總用時: 147 ms

第60次讀取 12總用時: 702 ms

第61次讀取 79總用時: 545 ms

第62次讀取 47總用時: 956 ms

第63次讀取 17總用時: 853 ms

第64次讀取 97總用時: 771 ms

第65次讀取 74總用時: 368 ms

第66次讀取 84總用時: 790 ms

第67次讀取 72總用時: 866 ms

第68次讀取 82總用時: 742 ms

第69次讀取 93總用時: 313 ms

第70次讀取 57總用時: 917 ms

第71次讀取 61總用時: 1185 ms

第72次讀取 66總用時: 162 ms

第73次讀取 5總用時: 168 ms

第74次讀取 68總用時: 275 ms

第75次讀取 43總用時: 1108 ms

第76次讀取 74總用時: 281 ms

第77次讀取 65總用時: 955 ms

第78次讀取 22總用時: 1169 ms

第79次讀取 88總用時: 501 ms

第80次讀取 80總用時: 1685 ms

第81次讀取 92總用時: 1286 ms

第82次讀取 89總用時: 1680 ms

第83次讀取 30總用時: 1537 ms

第84次讀取 41總用時: 1576 ms

第85次讀取 2總用時: 2193 ms

第86次讀取 52總用時: 1817 ms

第87次讀取 8總用時: 323 ms

第88次讀取 81總用時: 1409 ms

第89次讀取 40總用時: 577 ms

第90次讀取 88總用時: 598 ms

第91次讀取 19總用時: 2324 ms

第92次讀取 75總用時: 2275 ms

第93次讀取 29總用時: 668 ms

第94次讀取 77總用時: 2773 ms

第95次讀取 62總用時: 484 ms

第96次讀取 84總用時: 883 ms

第97次讀取 32總用時: 2945 ms

第98次讀取 44總用時: 884 ms

第99次讀取 66總用時: 631 ms

第100次讀取 38總用時: 2739 ms/pre

非常奇怪的是 MinIO 整體性能略優(yōu)于 SSDB 但是理論上不太應(yīng)該， SSDB 怎么說也是半內(nèi)存半硬盤的NoSQL不應(yīng)該比純硬盤的 MinIO 性能要差，有可能是 SSDB 寫到一定數(shù)據(jù)量后把本機(jī)內(nèi)存寫爆了，導(dǎo)致讀寫非常慢。但這變相驗證了 SSDB 在極端情況下的不穩(wěn)定。

tidb待遇

待遇不錯。

tidb和mysql幾乎完全兼容，所以我們的程序沒有任何改動就完成了數(shù)據(jù)庫從mysql到TiDb的轉(zhuǎn)換，TiDB 是一個分布式 NewSQL (SQL 、 NoSQL 和 NewSQL 的優(yōu)缺點比較 )數(shù)據(jù)庫。它支持水平彈性擴(kuò)展、ACID 事務(wù)、標(biāo)準(zhǔn) SQL、MySQL 語法和 MySQL 協(xié)議，具有數(shù)據(jù)強(qiáng)一致的高可用特性，是一個不僅適合 OLTP 場景還適合 OLAP 場景的混合數(shù)據(jù)庫。

2019數(shù)據(jù)架構(gòu)選型必讀：1月數(shù)據(jù)庫產(chǎn)品技術(shù)解析

本期目錄

DB-Engines數(shù)據(jù)庫排行榜

新聞快訊

一、RDBMS家族

二、NoSQL家族

三、NewSQL家族

四、時間序列

五、大數(shù)據(jù)生態(tài)圈

六、國產(chǎn)數(shù)據(jù)庫概覽

七、云數(shù)據(jù)庫

八、推出dbaplus Newsletter的想法

九、感謝名單

為方便閱讀、重點呈現(xiàn)，本期Newsletter（2019年1月）將對各個板塊的內(nèi)容進(jìn)行精簡。需要閱讀全文的同學(xué)可點擊文末 【閱讀原文】 或登錄

進(jìn)行下載。

DB-Engines數(shù)據(jù)庫排行榜

以下取自2019年1月的數(shù)據(jù)，具體信息可以參考，數(shù)據(jù)僅供參考。

DB-Engines排名的數(shù)據(jù)依據(jù)5個不同的因素：

新聞快訊

1、2018年9月24日，微軟公布了SQL Server2019預(yù)覽版，SQL Server 2019將結(jié)合Spark創(chuàng)建統(tǒng)一數(shù)據(jù)平臺。

2、2018年10月5日，ElasticSearch在美國紐約證券交易所上市。

3、亞馬遜放棄甲骨文數(shù)據(jù)庫軟件，導(dǎo)致最大倉庫之一在黃金時段宕機(jī)。受此消息影響，亞馬遜盤前股價小幅跳水，跌超2%。

4、2018年10月31日，Percona發(fā)布了Percona Server 8.0 RC版本，發(fā)布對MongoDB 4.0的支持，發(fā)布對XtraBackup測試第二個版本。

5、2018年10月31日，Gartner陸續(xù)發(fā)布了2018年的數(shù)據(jù)庫系列報告，包括《數(shù)據(jù)庫魔力象限》、《數(shù)據(jù)庫核心能力》以及《數(shù)據(jù)庫推薦報告》。

今年的總上榜數(shù)據(jù)庫產(chǎn)品達(dá)到了5家，分別來自：阿里云，華為，巨杉數(shù)據(jù)庫，騰訊云，星環(huán) 科技 。其中阿里云和巨杉數(shù)據(jù)庫已經(jīng)連續(xù)兩年入選。

6、2018年11月初，Neo4j宣布完成E輪8000萬美元融資。11月15日，Neo4j宣布企業(yè)版徹底閉源：

7、2019年1月8日，阿里巴巴以1.033億美元（9000萬歐元）的價格收購了Apache Flink商業(yè)公司DataArtisans。

8、2019年1月11日早間消息，亞馬遜宣布推出云數(shù)據(jù)庫軟件，亞馬遜和MongoDB將會直接競爭。

RDBMS家族

Oracle 發(fā)布18.3版本

2018年7月，Oracle Database 18.3通用版開始提供下載。我們可以將Oracle Database 18c視為采用之前發(fā)布模式的Oracle Database 12c第2版的第一個補(bǔ)丁集。未來，客戶將不再需要等待多年才能用上最新版Oracle數(shù)據(jù)庫，而是每年都可以期待新數(shù)據(jù)庫特性和增強(qiáng)。Database 19c將于2019年Q1率先在Oracle cloud上發(fā)布云版本。

Oracle Database 18c及19c部分關(guān)鍵功能：

1、性能

2、多租戶，大量功能增強(qiáng)及改進(jìn)，大幅節(jié)省成本和提高敏捷性

3、高可用

4、數(shù)據(jù)倉庫和大數(shù)據(jù)

MySQL發(fā)布8.0.13版本

1、賬戶管理

經(jīng)過配置，修改密碼時，必須帶上原密碼。在之前的版本，用戶登錄之后，就可以修改自己的密碼。這種方式存在一定安全風(fēng)險。比如用戶登錄上數(shù)據(jù)庫后，中途離開一段時間，那么非法用戶可能會修改密碼。由參數(shù)password_require_current控制。

2、配置

Innodb表必須有主鍵。在用戶沒有指定主鍵時，系統(tǒng)會生成一個默認(rèn)的主鍵。但是在主從復(fù)制的場景下，默認(rèn)的主鍵，會對叢庫應(yīng)用速度帶來致命的影響。如果設(shè)置sql_require_primary_key，那么數(shù)據(jù)庫會強(qiáng)制用戶在創(chuàng)建表、修改表時，加上主鍵。

3、字段默認(rèn)值

BLOB、TEXT、GEOMETRY和JSON字段可以指定默認(rèn)值了。

4、優(yōu)化器

1）Skip Scan

非前綴索引也可以用了。

之前的版本，任何沒有帶上f1字段的查詢，都沒法使用索引。在新的版本中，它可以忽略前面的字段，讓這個查詢使用到索引。其實現(xiàn)原理就是把(f1 = 1 AND f2 40) 和(f1 = 2 AND f2 40)的查詢結(jié)果合并。

2）函數(shù)索引

之前版本只能基于某個列或者多個列加索引，但是不允許在上面做計算，如今這個限制消除了。

5、SQL語法

GROUP BY ASC和GROUP BY DESC語法已經(jīng)被廢棄，要想達(dá)到類似的效果，請使用GROUP BY ORDER BY ASC和GROUP BY ORDER BY DESC。

6、功能變化

1）設(shè)置用戶變量，請使用SET語句

如下類型語句將要被廢棄SELECT @var, @var:=@var+1。

2）新增innodb_fsync_threshold

該變量是控制文件刷新到磁盤的速率，防止磁盤在短時間內(nèi)飽和。

3）新增會話級臨時表空間

在以往的版本中，當(dāng)執(zhí)行SQL時，產(chǎn)生的臨時表都在全局表空間ibtmp1中，及時執(zhí)行結(jié)束，臨時表被釋放，空間不會被回收。新版本中，會為session從臨時表空間池中分配一個臨時表空間，當(dāng)連接斷開時，臨時表空間的磁盤空間被回收。

4）在線切換Group Replication的狀態(tài)

5）新增了group_replication_member_expel_timeout

之前，如果某個節(jié)點被懷疑有問題，在5秒檢測期結(jié)束之后，那么就直接被驅(qū)逐出這個集群。即使該節(jié)點恢復(fù)正常時，也不會再被加入集群。那么，瞬時的故障，會把某些節(jié)點驅(qū)逐出集群。

group_replication_member_expel_timeout讓管理員能更好的依據(jù)自身的場景，做出最合適的配置（建議配置時間小于一個小時）。

MariaDB 10.3版本功能展示

1、MariaDB 10.3支持update多表ORDER BY and LIMIT

1）update連表更新，limit語句

update t1 join t2 on t1.id=t2.id set t1.name='hechunyang' limit 3;

MySQL 8.0直接報錯

MariaDB 10.3更新成功

2）update連表更新，ORDER BY and LIMIT語句

update t1 join t2 on t1.id=t2.id set t1.name='HEchunyang' order by t1.id DESC limit 3;

MySQL 8.0直接報錯

MariaDB 10.3更新成功

參考：

2、MariaDB10.3增補(bǔ)AliSQL補(bǔ)丁——安全執(zhí)行Online DDL

Online DDL從名字上看很容易誤導(dǎo)新手，以為不論什么情況，修改表結(jié)構(gòu)都不會鎖表，理想很豐滿，現(xiàn)實很骨感，注意這個坑！

有以下兩種情況執(zhí)行DDL操作會鎖表的，Waiting for table metadata lock（元數(shù)據(jù)表鎖）：

針對第二種情況，MariaDB10.3增補(bǔ)AliSQL補(bǔ)丁-DDL FAST FAIL，讓其DDL操作快速失敗。

例：

如果線上有某個慢SQL對該表進(jìn)行操作，可以使用WAIT n（以秒為單位設(shè)置等待）或NOWAIT在語句中顯式設(shè)置鎖等待超時，在這種情況下，如果無法獲取鎖，語句將立即失敗。 WAIT 0相當(dāng)于NOWAIT。

參考：

3、MariaDB Window Functions窗口函數(shù)分組取TOP N記錄

窗口函數(shù)在MariaDB10.2版本里實現(xiàn)，其簡化了復(fù)雜SQL的撰寫，提高了可讀性。

參考：

Percona Server發(fā)布8.0 GA版本

2018年12月21日，Percona發(fā)布了Percona Server 8.0 GA版本。

在支持MySQL8.0社區(qū)的基礎(chǔ)版上，Percona Server for MySQL 8.0版本中帶來了許多新功能：

1、安全性和合規(guī)性

2、性能和可擴(kuò)展性

3、可觀察性和可用性

Percona Server for MySQL 8.0中將要被廢用功能：

Percona Server for MySQL 8.0中刪除的功能：

RocksDB發(fā)布V5.17.2版本

2018年10月24日，RocksDB發(fā)布V5.17.2版本。

RocksDB是Facebook在LevelDB基礎(chǔ)上用C++寫的高效內(nèi)嵌式K/V存儲引擎。相比LevelDB，RocksDB提供了Column-Family，TTL，Transaction，Merge等方面的支持。目前MyRocks，TiKV等底層的存儲都是基于RocksDB來構(gòu)建。

PostgreSQL發(fā)布11版本

2018年10月18日，PostgreSQL 11發(fā)布。

1、PostgreSQL 11的重大增強(qiáng)

2、PostgreSQL 插件動態(tài)

1）分布式插件citus發(fā)布 8.1

citus是PostgreSQL的一款sharding插件，目前國內(nèi)蘇寧、鐵總、探探有較大量使用案例。

2）地理信息插件postgis發(fā)布2.5.1

PostGIS是專業(yè)的時空數(shù)據(jù)庫插件，在測繪、航天、氣象、地震、國土資源、地圖等時空專業(yè)領(lǐng)域應(yīng)用廣泛。同時在互聯(lián)網(wǎng)行業(yè)也得到了對GIS有性能、功能深度要求的客戶青睞，比如共享出行、外賣等客戶。

3）時序插件timescale發(fā)布1.1.1

timescale是PostgreSQL的一款時序數(shù)據(jù)庫插件，在IoT行業(yè)中有非常好的應(yīng)用。github star數(shù)目前有5000多，是一個非常火爆的插件。

4）流計算插件 pipelinedb 正式插件化

Pipelinedb是PostgreSQL的一款流計算插件，使用這個創(chuàng)建可以對高速寫入的數(shù)據(jù)進(jìn)行實時根據(jù)定義的聚合規(guī)則進(jìn)行聚合（支持概率計算），實時根據(jù)定義的規(guī)則觸發(fā)事件（支持事件處理函數(shù)的自定義）。可用于IoT，監(jiān)控，F(xiàn)EED實時計算等場景。

3、PostgreSQL衍生開源產(chǎn)品動態(tài)

1）agensgraph發(fā)布 2.0.0版本

agensgraph是兼容PostgreSQL、opencypher的專業(yè)圖數(shù)據(jù)庫，適合圖式關(guān)系的管理。

2）gpdb發(fā)布5.15

gpdb是兼容PostgreSQL的mpp數(shù)據(jù)庫，適合OLAP場景。近兩年，gpdb一直在追趕PostgreSQL的社區(qū)版本，預(yù)計很快會追上10的PostgreSQL，在TP方面的性能也會得到顯著提升。

3）antdb發(fā)布3.2

antdb是以Postgres-XC為基礎(chǔ)開發(fā)的一款PostgreSQL sharding數(shù)據(jù)庫，亞信主導(dǎo)開發(fā)，開源，目前主要服務(wù)于亞信自有客戶。

4）遷移工具M(jìn)TK發(fā)布52版本

MTK是EDB提供的可以將Oracle、PostgreSQL、MySQL、MSSQL、Sybase數(shù)據(jù)庫遷移到PostgreSQL, PPAS的產(chǎn)品，遷移速度可以達(dá)到100萬行/s以上。

DB2發(fā)布 11.1.4.4版本

DB2最新發(fā)布Mod Pack 4 and Fix Pack 4，包含以下幾方面的改動及增強(qiáng)：

1、性能

2、高可用

3、管理視圖

4、應(yīng)用開發(fā)方面

5、聯(lián)邦功能

6、pureScale

NoSQL家族

Redis發(fā)布5.0.3版本

MongoDB升級更新MongoDB Mobile和MongoDB Stitch

2018年11月21日，MongoDB升級更新MongoDB Mobile和MongoDB Stitch，助力開發(fā)人員提升工作效率。

MongoDB 公司日前發(fā)布了多項新產(chǎn)品功能，旨在更好地幫助開發(fā)人員在世界各地管理數(shù)據(jù)。通過利用存儲在移動設(shè)備和后臺數(shù)據(jù)庫的數(shù)據(jù)之間的實時、自動的同步特性，MongoDB Mobile通用版本助力開發(fā)人員構(gòu)建更快捷、反應(yīng)更迅速的應(yīng)用程序。此前，這只能通過在移動應(yīng)用內(nèi)部安裝一個可供選擇或限定功能的數(shù)據(jù)庫來實現(xiàn)。

MongoDB Mobile在為客戶提供隨處運(yùn)行的自由度方面更進(jìn)了一步。用戶在iOS和安卓終端設(shè)備上可擁有MongoDB所有功能，將網(wǎng)絡(luò)邊界擴(kuò)展到其物聯(lián)網(wǎng)資產(chǎn)范疇。應(yīng)用系統(tǒng)還可以使用MongoDB Stitch的軟件開發(fā)包訪問移動客戶端或后臺數(shù)據(jù)，幫助開發(fā)人員通過他們希望的任意方式查詢移動終端數(shù)據(jù)和物聯(lián)網(wǎng)數(shù)據(jù)，包括本地讀寫、本地JSON存儲、索引和聚合。通過Stitch移動同步功能(現(xiàn)可提供beta版)，用戶可以自動對保存在本地的數(shù)據(jù)以及后臺數(shù)據(jù)庫的數(shù)據(jù)進(jìn)行同步。

本期新秀：Cassandra發(fā)布3.11.3版本

2018年8月11日，Cassandra發(fā)布正式版3.11.3。

Apache Cassandra是一款開源分布式NoSQL數(shù)據(jù)庫系統(tǒng)，使用了基于Google BigTable的數(shù)據(jù)模型，與面向行(row)的傳統(tǒng)關(guān)系型數(shù)據(jù)庫或鍵值存儲key-value數(shù)據(jù)庫不同，Cassandra使用的是寬列存儲模型(Wide Column Stores)。與BigTable和其模仿者HBase不同，數(shù)據(jù)并不存儲在分布式文件系統(tǒng)如GFS或HDFS中，而是直接存于本地。

Cassandra的系統(tǒng)架構(gòu)與Amazon DynamoDB類似，是基于一致性哈希的完全P2P架構(gòu)，每行數(shù)據(jù)通過哈希來決定應(yīng)該存在哪個或哪些節(jié)點中。集群沒有master的概念，所有節(jié)點都是同樣的角色，徹底避免了整個系統(tǒng)的單點問題導(dǎo)致的不穩(wěn)定性，集群間的狀態(tài)同步通過Gossip協(xié)議來進(jìn)行P2P的通信。

3.11.3版本的一些bug fix和改進(jìn)：

NewSQL家族

TiDB 發(fā)布2.1.2版本

2018 年 12 月 22 日，TiDB 發(fā)布 2.1.2 版，TiDB-Ansible 相應(yīng)發(fā)布 2.1.2 版本。該版本在 2.1.1 版的基礎(chǔ)上，對系統(tǒng)兼容性、穩(wěn)定性做出了改進(jìn)。

TiDB 是一款定位于在線事務(wù)處理/在線分析處理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型數(shù)據(jù)庫產(chǎn)品。除了底層的 RocksDB 存儲引擎之外，分布式SQL層、分布式KV存儲引擎（TiKV）完全自主設(shè)計和研發(fā)。

TiDB 完全開源，兼容MySQL協(xié)議和語法，可以簡單理解為一個可以無限水平擴(kuò)展的MySQL，并且提供分布式事務(wù)、跨節(jié)點 JOIN、吞吐和存儲容量水平擴(kuò)展、故障自恢復(fù)、高可用等優(yōu)異的特性；對業(yè)務(wù)沒有任何侵入性，簡化開發(fā)，利于維護(hù)和平滑遷移。

TiDB：

PD：

TiKV：

Tools：

1）TiDB-Lightning

2）TiDB-Binlog

EsgynDB發(fā)布R2.5版本

2018年12月22日，EsgynDB R2.5版本正式發(fā)布。

作為企業(yè)級產(chǎn)品，EsgynDB 2.5向前邁進(jìn)了一大步，它擁有以下功能和改進(jìn)：

CockroachDB發(fā)布2.1版本

2018年10月30日，CockroachDB正式發(fā)布2.1版本，其新增特性如下：

新增企業(yè)級特性：

新增SQL特性：

新增內(nèi)核特性：

Admin UI增強(qiáng)：

時間序列

本期新秀：TimescaleDB發(fā)布1.0版本

10月底，TimescaleDB 1.0宣布正式推出，官方表示該版本已可用于生產(chǎn)環(huán)境，支持完整SQL和擴(kuò)展。

TimescaleDB是基于PostgreSQL數(shù)據(jù)庫開發(fā)的一款時序數(shù)據(jù)庫，以插件化的形式打包提供，隨著PostgreSQL的版本升級而升級，不會因為另立分支帶來麻煩。

TimescaleDB架構(gòu)：

數(shù)據(jù)自動按時間和空間分片(chunk)

更新亮點：

大數(shù)據(jù)生態(tài)圈

Hadoop發(fā)布2.9.2版本

2018年11月中旬，Hadoop在2.9分支上發(fā)布了新的2.9.2版本，該版本進(jìn)行了204個大大小小的變更，主要變更如下：

Greenplum 發(fā)布5.15版本

Greenplum最新的5.15版本中發(fā)布了流式數(shù)據(jù)加載工具。

該版本中的Greenplum Streem Server組件已經(jīng)集成了Kafka流式加載功能，并通過了Confluent官方的集成認(rèn)證，其支持的主要功能如下：

國產(chǎn)數(shù)據(jù)庫概覽

K-DB發(fā)布數(shù)據(jù)庫一體機(jī)版

2018年11月7日，K-DB發(fā)布了數(shù)據(jù)庫一體機(jī)版。該版本更新情況如下：

OceanBase遷移服務(wù)發(fā)布1.0版本

1月4日，OceanBase 正式發(fā)布OMS遷移服務(wù)1.0版本。

以下內(nèi)容包含 OceanBase 遷移服務(wù)的重要特性和功能：

SequoiaDB發(fā)布3.0.1新版本

1、架構(gòu)

1）完整計算存儲分離架構(gòu)，兼容MySQL協(xié)議、語法

計算存儲分離體系以松耦合的方式將計算與存儲層分別部署，通過標(biāo)準(zhǔn)接口或插件對各個模塊和組件進(jìn)行無縫替換，在計算層與存儲層均可實現(xiàn)自由的彈性伸縮。

SequoiaDB巨杉數(shù)據(jù)庫“計算-存儲分離”架構(gòu)詳細(xì)示意

用戶可以根據(jù)自身業(yè)務(wù)特征選擇面向交易的SQL解析器（例如MySQL或PGSQL）或面向統(tǒng)計分析的執(zhí)行引擎（例如SparkSQL）。眾所周知，使用不同的SQL優(yōu)化與執(zhí)行方式，數(shù)據(jù)庫的訪問性能可能會存在上千上萬倍的差距。計算存儲分離的核心思想便是在數(shù)據(jù)存儲層面進(jìn)行一體化存儲，在計算層面則利用每種執(zhí)行引擎的特點針對不同業(yè)務(wù)場景進(jìn)行選擇和優(yōu)化，用戶可以在存儲層進(jìn)行邏輯與物理的隔離，將面向高頻交易的前端業(yè)務(wù)與面向高吞吐量的統(tǒng)計分析使用不同的硬件進(jìn)行存儲，確保在多類型數(shù)據(jù)訪問時互不干擾，以真正達(dá)到生產(chǎn)環(huán)境可用的多租戶與HTAP能力。

2、其他更新信息

1）接口變更：

2）主要特性：

云數(shù)據(jù)庫

本期新秀：騰訊發(fā)布數(shù)據(jù)庫CynosDB，開啟公測

1、News

1）騰訊云數(shù)據(jù)庫MySQL2018年重大更新：

2）騰訊云數(shù)據(jù)庫MongoDB2018年重大更新：

3）騰訊云數(shù)據(jù)庫Redis/CKV+2018年重大更新：

4）騰訊云數(shù)據(jù)庫CTSDB2018年重大更新：

2、Redis 4.0集群版商業(yè)化上線

2018年10月，騰訊云數(shù)據(jù)庫Redis 4.0集群版完成邀測、公測、商業(yè)化三個迭代，在廣州、上海、北京正式全量商業(yè)化上線。

產(chǎn)品特性：

使用場景：

官網(wǎng)文檔：

3、騰訊自研數(shù)據(jù)庫CynosDB發(fā)布，開啟公測

2018年11月22日，騰訊云召開新一代自研數(shù)據(jù)庫CynosDB發(fā)布會，業(yè)界第一款全面兼容市面上兩大最主流的開源數(shù)據(jù)庫MySQL和PostgreSQL的高性能企業(yè)級分布式云數(shù)據(jù)庫。

本期新秀：京東云DRDS發(fā)布1.0版本

12月24日，京東云分布式關(guān)系型數(shù)據(jù)庫DRDS正式發(fā)布1.0版本。

DRDS是京東云精心自研的數(shù)據(jù)庫中間件產(chǎn)品，獲得了2018年 ”可信云技術(shù)創(chuàng)新獎”。DRDS可實現(xiàn)海量數(shù)據(jù)下的自動分庫分表，具有高性能，分布式，彈性升級，兼容MySQL等優(yōu)點，適用于高并發(fā)、大規(guī)模數(shù)據(jù)的在線交易， 歷史 數(shù)據(jù)查詢，自動數(shù)據(jù)分片等業(yè)務(wù)場景，歷經(jīng)多次618，雙十一的考驗，已經(jīng)在京東集團(tuán)內(nèi)大規(guī)模使用。

京東云DRDS產(chǎn)品有以下主要特性

1）自動分庫分表

通過簡單的定義即可自動實現(xiàn)分庫分表，將數(shù)據(jù)實際存放在多個MySQL實例的數(shù)據(jù)庫中，但呈現(xiàn)給應(yīng)用程序的依舊是一張表，對業(yè)務(wù)透明，應(yīng)用程序幾乎無需改動，實現(xiàn)了對數(shù)據(jù)庫存儲和處理能力的水平擴(kuò)展。

2）分布式架構(gòu)

基于分布式架構(gòu)的集群方案，多個對等節(jié)點同時對外提供服務(wù)，不但可有效規(guī)避服務(wù)的單點故障，而且更加容易擴(kuò)展。

3）超強(qiáng)性能

具有極高的處理能力，雙節(jié)點即可支持?jǐn)?shù)萬QPS，滿足用戶超大規(guī)模處理能力的需求。

4）兼容MySQL

兼容絕大部分MySQL語法，包括MySQL語法、數(shù)據(jù)類型、索引、常用函數(shù)、排序、關(guān)聯(lián)等DDL，DML語句，使用成本低。

參考鏈接：

RadonDB發(fā)布1.0.3版本

2018年12月26日，MyNewSQL領(lǐng)域的RadonDB云數(shù)據(jù)庫發(fā)布1.0.3版本。

推出dbaplus Newsletter的想法

dbaplus Newsletter旨在向廣大技術(shù)愛好者提供數(shù)據(jù)庫行業(yè)的最新技術(shù)發(fā)展趨勢，為社區(qū)的技術(shù)發(fā)展提供一個統(tǒng)一的發(fā)聲平臺。為此，我們策劃了RDBMS、NoSQL、NewSQL、時間序列、大數(shù)據(jù)生態(tài)圈、國產(chǎn)數(shù)據(jù)庫、云數(shù)據(jù)庫等幾個版塊。

我們不以商業(yè)宣傳為目的，不接受任何商業(yè)廣告宣傳，嚴(yán)格審查信息源的可信度和準(zhǔn)確性，力爭為大家提供一個純凈的技術(shù)學(xué)習(xí)環(huán)境，歡迎大家監(jiān)督指正。

至于Newsletter發(fā)布的周期，目前計劃是每三個月左右會做一次跟進(jìn)， 下期計劃時間是2019年4月14日~4月25日， 如果有相關(guān)的信息提供請發(fā)送至郵箱：newsletter@dbaplus.cn

感謝名單

最后要感謝那些提供寶貴信息和建議的專家朋友，排名不分先后。

往期回顧：

↓↓別忘了點這里下載 2019年1月 完整版Newsletter 哦~

TiDB 的數(shù)據(jù)遷移工具現(xiàn)已開源

TiDB 是國內(nèi) PingCAP 團(tuán)隊開發(fā)的一個分布式 SQL 數(shù)據(jù)庫，支持包括傳統(tǒng) RDBMS 和 NoSQL 的特性。現(xiàn)已將 DM（data migration platform，該數(shù)據(jù)遷移工具）開源。

該數(shù)據(jù)遷移工具遵循 Apache-2.0 開源協(xié)議，允許用戶自由地使用及修改。

據(jù)介紹，DM (Data Migration) 是一體化數(shù)據(jù)同步任務(wù)管理平臺，支持從 MySQL/MariaDB 到 TiDB 的數(shù)據(jù)遷移、全量備份和 MariaDB/MySQL binlog 增量同步，有助于減少操作成本和簡化錯誤處理流程。架構(gòu)圖如下所示：

從架構(gòu)圖可以看到，DM 包括三大組件：DM-master、DM-worker 和 dmctl。其中，DM-master 管理和調(diào)度數(shù)據(jù)同步任務(wù)的操作、DM-worker 執(zhí)行特定的數(shù)據(jù)同步任務(wù)、dmctl 則是控制 DM 集群的命令行工具。更詳細(xì)的組件功能介紹，可以查閱官方文檔。

文章題目：tidbnosql的簡單介紹
URL網(wǎng)址：http://chinadenli.net/article5/dsgdsoi.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、建站公司、品牌網(wǎng)站設(shè)計、網(wǎng)站導(dǎo)航、域名注冊、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)