在大數(shù)據(jù)時(shí)代，“多種架構(gòu)支持多類應(yīng)用”成為數(shù)據(jù)庫行業(yè)應(yīng)對(duì)大數(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)用場景對(duì)海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)管理、復(fù)雜分析、關(guān)聯(lián)查詢、實(shí)時(shí)性處理和控制建設(shè)成本等多方面的需要，因此不同架構(gòu)數(shù)據(jù)庫混合部署應(yīng)用成為滿足復(fù)雜應(yīng)用的必然選擇。不同架構(gòu)數(shù)據(jù)庫混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個(gè)案例對(duì)不同架構(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ù)處理能力的同時(shí)，借助NewSQL在實(shí)時(shí)性、復(fù)雜分析、即席查詢等方面的獨(dú)特優(yōu)勢(shì)，以及面對(duì)海量數(shù)據(jù)時(shí)較強(qiáng)的擴(kuò)展能力，滿足數(shù)據(jù)中心對(duì)當(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ù)存儲(chǔ)能力和處理性能方面的缺陷。
商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL數(shù)據(jù)庫滿足各業(yè)務(wù)系統(tǒng)數(shù)據(jù)的歸檔備份和事務(wù)型應(yīng)用，NewSQL MPP數(shù)據(jù)庫集群對(duì)即席查詢、多維分析等應(yīng)用提供高性能支持，并且通過MPP集群架構(gòu)實(shí)現(xiàn)應(yīng)對(duì)海量數(shù)據(jù)存儲(chǔ)的擴(kuò)展能力。
商業(yè)銀行數(shù)據(jù)中心存儲(chǔ)架構(gòu)
與傳統(tǒng)的OldSQL模式相比，商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合搭建模式，數(shù)據(jù)加載性能提升3倍以上，即席查詢和統(tǒng)計(jì)分析性能提升6倍以上。NewSQL MPP的高可擴(kuò)展性能夠應(yīng)對(duì)新的業(yè)務(wù)需求，可隨著數(shù)據(jù)量的增長采用集群方式構(gòu)建存儲(chǔ)容量更大的數(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)用對(duì)海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行存儲(chǔ)和快速處理的需求。在諸如大型電子商務(wù)平臺(tái)、大型SNS平臺(tái)等互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用場景中，OldSQL在應(yīng)用中負(fù)責(zé)高價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和事務(wù)型處理，NoSQL在應(yīng)用中負(fù)責(zé)存儲(chǔ)和處理海量非結(jié)構(gòu)化的數(shù)據(jù)和低價(jià)值密度結(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ù)存儲(chǔ)和非結(jié)構(gòu)化數(shù)據(jù)處理方面的缺陷。
數(shù)據(jù)魔方是淘寶網(wǎng)的一款數(shù)據(jù)產(chǎn)品，主要提供行業(yè)數(shù)據(jù)分析、店鋪數(shù)據(jù)分析。淘寶數(shù)據(jù)產(chǎn)品在存儲(chǔ)層采用OldSQL+NoSQL混合模式，由基于MySQL的分布式關(guān)系型數(shù)據(jù)庫集群MyFOX和基于HBase的NoSQL存儲(chǔ)集群Prom組成。由于OldSQL強(qiáng)大的語義和關(guān)系表達(dá)能力，在應(yīng)用中仍然占據(jù)著重要地位，目前存儲(chǔ)在MyFOX中的統(tǒng)計(jì)結(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)的特點(diǎn)，數(shù)據(jù)魔方目前已經(jīng)能夠提供壓縮前80TB的數(shù)據(jù)存儲(chǔ)空間，支持每天4000萬的查詢請(qǐng)求，平均響應(yīng)時(shí)間在28毫秒，足以滿足未來一段時(shí)間內(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à)值密度更高，并且對(duì)結(jié)構(gòu)化數(shù)據(jù)的實(shí)時(shí)處理、復(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ì)分析、經(jīng)營分析等。
在行業(yè)大數(shù)據(jù)應(yīng)用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在結(jié)構(gòu)化數(shù)據(jù)分析處理方面的優(yōu)勢(shì)，以及NoSQL在非結(jié)構(gòu)數(shù)據(jù)處理方面的優(yōu)勢(shì)，實(shí)現(xiàn)NewSQL與NoSQL的功能互補(bǔ)，解決行業(yè)大數(shù)據(jù)應(yīng)用對(duì)高價(jià)值結(jié)構(gòu)化數(shù)據(jù)的實(shí)時(shí)處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強(qiáng)一致性等要求，以及對(duì)海量非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)和精確查詢的要求。在應(yīng)用中，NewSQL承擔(dān)高價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和分析處理工作，NoSQL承擔(dān)存儲(chǔ)和處理海量非結(jié)構(gòu)化數(shù)據(jù)和不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的低價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的工作。
當(dāng)前電信運(yùn)營商在集中化BI系統(tǒng)建設(shè)過程中面臨著數(shù)據(jù)規(guī)模大、數(shù)據(jù)處理類型多等問題，并且需要應(yīng)對(duì)大量的固定應(yīng)用，以及占統(tǒng)計(jì)總數(shù)80%以上的突發(fā)性臨時(shí)統(tǒng)計(jì)(ad-hoc)需求。在集中化BI系統(tǒng)的建設(shè)中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復(fù)雜分析、即席查詢等方面處理性能的優(yōu)勢(shì)，及NoSQL在非結(jié)構(gòu)化數(shù)據(jù)處理和海量數(shù)據(jù)存儲(chǔ)方面的優(yōu)勢(shì)，實(shí)現(xiàn)高效低成本。
集中化BI系統(tǒng)數(shù)據(jù)存儲(chǔ)架構(gòu)
集中化BI系統(tǒng)按照數(shù)據(jù)類型和處理方式的不同，將結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)分別存儲(chǔ)在不同的系統(tǒng)中：非結(jié)構(gòu)化數(shù)據(jù)在Hadoop平臺(tái)上存儲(chǔ)與處理;結(jié)構(gòu)化、不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的數(shù)據(jù)保存在NoSQL數(shù)據(jù)庫或Hadoop平臺(tái);結(jié)構(gòu)化、需要關(guān)聯(lián)分析或經(jīng)常ad-hoc查詢的數(shù)據(jù)，保存在NewSQL MPP數(shù)據(jù)庫中，短期高價(jià)值數(shù)據(jù)放在高性能平臺(tái)，中長期放在低成本產(chǎn)品中。
結(jié)語
當(dāng)前信息化應(yīng)用的多樣性、復(fù)雜性，以及三種數(shù)據(jù)庫架構(gòu)各自所具有的優(yōu)勢(shì)和局限性，造成任何一種架構(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ù)庫的特點(diǎn)和優(yōu)勢(shì)，并且與其他架構(gòu)數(shù)據(jù)庫形成互補(bǔ)，完全涵蓋應(yīng)用需求，保證數(shù)據(jù)資源的最優(yōu)化利用，將成為未來一段時(shí)期內(nèi)信息化應(yīng)用主要采用的解決方式。
目前在國內(nèi)市場上，OldSQL主要為Oracle、IBM等國外數(shù)據(jù)庫廠商所壟斷，達(dá)夢(mèng)、金倉等國產(chǎn)廠商仍處于追趕狀態(tài);南大通用憑借國產(chǎn)新型數(shù)據(jù)庫GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場三強(qiáng);NoSQL方面用戶則大多采用Hadoop開源方案。
項(xiàng)目上需要找一個(gè)硬盤型的NoSQL，用于將 Redis 中的冷數(shù)據(jù)落入硬盤。初步選型了幾款 key-value 類型的NoSQL，分別有 levelDB、 rocksDB、 TiDB、 SSDB、swapDB、 Kvrocks、Tikv 。均為基于 levelDB 開發(fā)的幾款NoSQL。其中因?yàn)?levelDB、rocksDB 無網(wǎng)絡(luò)接口，不方便做分布式和高可用。， TiDB 過重，還有 swapDB 社區(qū)不夠活躍且相關(guān)client API不完備。暫時(shí)選型 SSDB 。
項(xiàng)目需要存儲(chǔ)的其實(shí)是一個(gè)略長的二進(jìn)制字符串，初步認(rèn)為，使用 對(duì)象存儲(chǔ) 方案其實(shí)也可以替代NoSQL，所以壓測對(duì)象添加當(dāng)前非?；鸬脑圃鷮?duì)象存儲(chǔ) MinIO
硬件名|配置 系統(tǒng)| Ubuntu(基于win10 wsl版的docker啟動(dòng)) 內(nèi)存| 16GB(實(shí)際可用6.08G) CPU| Intel i5-8400
測試項(xiàng)目： 1. 寫50M數(shù)據(jù)100次 2. 隨機(jī)讀取任意key 100次（對(duì)LRU機(jī)制不友好）
寫
數(shù)據(jù)導(dǎo)入成功！
數(shù)據(jù)序列化成功！
a 數(shù)據(jù)大小:50.99295234680176 MB
第1次寫入總用時(shí): 797 ms
第2次寫入總用時(shí): 848 ms
第3次寫入總用時(shí): 3621 ms
第4次寫入總用時(shí): 813 ms
第5次寫入總用時(shí): 1862 ms
第6次寫入總用時(shí): 838 ms
第7次寫入總用時(shí): 2235 ms
第8次寫入總用時(shí): 836 ms
第9次寫入總用時(shí): 900 ms
第10次寫入總用時(shí): 1027 ms
第11次寫入總用時(shí): 1101 ms
第12次寫入總用時(shí): 880 ms
第13次寫入總用時(shí): 1956 ms
第14次寫入總用時(shí): 866 ms
第15次寫入總用時(shí): 2422 ms
第16次寫入總用時(shí): 852 ms
第17次寫入總用時(shí): 4511 ms
第18次寫入總用時(shí): 875 ms
第19次寫入總用時(shí): 2736 ms
第20次寫入總用時(shí): 814 ms
第21次寫入總用時(shí): 7172 ms
第22次寫入總用時(shí): 891 ms
第23次寫入總用時(shí): 7820 ms
第24次寫入總用時(shí): 836 ms
第25次寫入總用時(shí): 22103 ms
第26次寫入總用時(shí): 877 ms
第27次寫入總用時(shí): 2712 ms
第28次寫入總用時(shí): 841 ms
第29次寫入總用時(shí): 1928 ms
第30次寫入總用時(shí): 916 ms
第31次寫入總用時(shí): 839 ms
第32次寫入總用時(shí): 826 ms
第33次寫入總用時(shí): 7759 ms
第34次寫入總用時(shí): 843 ms
第35次寫入總用時(shí): 10670 ms
第36次寫入總用時(shí): 843 ms
第37次寫入總用時(shí): 9361 ms
第38次寫入總用時(shí): 821 ms
第39次寫入總用時(shí): 810 ms
第40次寫入總用時(shí): 794 ms
第41次寫入總用時(shí): 13281 ms
第42次寫入總用時(shí): 833 ms
第43次寫入總用時(shí): 811 ms
第44次寫入總用時(shí): 798 ms
第45次寫入總用時(shí): 18843 ms
第46次寫入總用時(shí): 911 ms
第47次寫入總用時(shí): 9428 ms
第48次寫入總用時(shí): 898 ms
第49次寫入總用時(shí): 17582 ms
第50次寫入總用時(shí): 903 ms
第51次寫入總用時(shí): 831 ms
第52次寫入總用時(shí): 800 ms
第53次寫入總用時(shí): 14602 ms
第54次寫入總用時(shí): 827 ms
第55次寫入總用時(shí): 5898 ms
第56次寫入總用時(shí): 856 ms
第57次寫入總用時(shí): 5693 ms
第58次寫入總用時(shí): 1050 ms
第59次寫入總用時(shí): 882 ms
第60次寫入總用時(shí): 1020 ms
第61次寫入總用時(shí): 15060 ms
第62次寫入總用時(shí): 902 ms
第63次寫入總用時(shí): 1062 ms
第64次寫入總用時(shí): 915 ms
第65次寫入總用時(shí): 7572 ms
第66次寫入總用時(shí): 823 ms
第67次寫入總用時(shí): 9649 ms
第68次寫入總用時(shí): 832 ms
第69次寫入總用時(shí): 10403 ms
第70次寫入總用時(shí): 907 ms
第71次寫入總用時(shí): 978 ms
第72次寫入總用時(shí): 789 ms
第73次寫入總用時(shí): 2111 ms
第74次寫入總用時(shí): 947 ms
第75次寫入總用時(shí): 4675 ms
第76次寫入總用時(shí): 944 ms
第77次寫入總用時(shí): 8592 ms
第78次寫入總用時(shí): 832 ms
第79次寫入總用時(shí): 2940 ms
第80次寫入總用時(shí): 842 ms
第81次寫入總用時(shí): 19835 ms
第82次寫入總用時(shí): 862 ms
第83次寫入總用時(shí): 7646 ms
第84次寫入總用時(shí): 873 ms
第85次寫入總用時(shí): 1002 ms
第86次寫入總用時(shí): 842 ms
第87次寫入總用時(shí): 9057 ms
第88次寫入總用時(shí): 801 ms
第89次寫入總用時(shí): 5117 ms
第90次寫入總用時(shí): 918 ms
第91次寫入總用時(shí): 798 ms
第92次寫入總用時(shí): 853 ms
第93次寫入總用時(shí): 7728 ms
第94次寫入總用時(shí): 810 ms
第95次寫入總用時(shí): 3969 ms
第96次寫入總用時(shí): 814 ms
第97次寫入總用時(shí): 2050 ms
第98次寫入總用時(shí): 819 ms
第99次寫入總用時(shí): 9566 ms
第100次寫入總用時(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
寫
數(shù)據(jù)導(dǎo)入成功！
第1次寫入總用時(shí): 956 ms
第2次寫入總用時(shí): 912 ms
第3次寫入總用時(shí): 1241 ms
第4次寫入總用時(shí): 1564 ms
第5次寫入總用時(shí): 942 ms
第6次寫入總用時(shí): 3666 ms
第7次寫入總用時(shí): 1629 ms
第8次寫入總用時(shí): 1712 ms
第9次寫入總用時(shí): 977 ms
第10次寫入總用時(shí): 1515 ms
第11次寫入總用時(shí): 911 ms
第12次寫入總用時(shí): 1009 ms
第13次寫入總用時(shí): 1024 ms
第14次寫入總用時(shí): 1206 ms
第15次寫入總用時(shí): 984 ms
第16次寫入總用時(shí): 943 ms
第17次寫入總用時(shí): 954 ms
第18次寫入總用時(shí): 1033 ms
第19次寫入總用時(shí): 1008 ms
第20次寫入總用時(shí): 1121 ms
第21次寫入總用時(shí): 963 ms
第22次寫入總用時(shí): 949 ms
第23次寫入總用時(shí): 889 ms
第24次寫入總用時(shí): 1066 ms
第25次寫入總用時(shí): 1289 ms
第26次寫入總用時(shí): 1125 ms
第27次寫入總用時(shí): 1111 ms
第28次寫入總用時(shí): 953 ms
第29次寫入總用時(shí): 964 ms
第30次寫入總用時(shí): 1125 ms
第31次寫入總用時(shí): 998 ms
第32次寫入總用時(shí): 1993 ms
第33次寫入總用時(shí): 926 ms
第34次寫入總用時(shí): 920 ms
第35次寫入總用時(shí): 926 ms
第36次寫入總用時(shí): 1169 ms
第37次寫入總用時(shí): 1325 ms
第38次寫入總用時(shí): 1170 ms
第39次寫入總用時(shí): 1074 ms
第40次寫入總用時(shí): 1011 ms
第41次寫入總用時(shí): 931 ms
第42次寫入總用時(shí): 984 ms
第43次寫入總用時(shí): 1563 ms
第44次寫入總用時(shí): 905 ms
第45次寫入總用時(shí): 944 ms
第46次寫入總用時(shí): 1147 ms
第47次寫入總用時(shí): 1429 ms
第48次寫入總用時(shí): 934 ms
第49次寫入總用時(shí): 1133 ms
第50次寫入總用時(shí): 912 ms
第51次寫入總用時(shí): 953 ms
第52次寫入總用時(shí): 1127 ms
第53次寫入總用時(shí): 1065 ms
第54次寫入總用時(shí): 1323 ms
第55次寫入總用時(shí): 1003 ms
第56次寫入總用時(shí): 1489 ms
第57次寫入總用時(shí): 1377 ms
第58次寫入總用時(shí): 940 ms
第59次寫入總用時(shí): 1317 ms
第60次寫入總用時(shí): 912 ms
第61次寫入總用時(shí): 898 ms
第62次寫入總用時(shí): 934 ms
第63次寫入總用時(shí): 1005 ms
第64次寫入總用時(shí): 1729 ms
第65次寫入總用時(shí): 983 ms
第66次寫入總用時(shí): 1684 ms
第67次寫入總用時(shí): 908 ms
第68次寫入總用時(shí): 895 ms
第69次寫入總用時(shí): 1171 ms
第70次寫入總用時(shí): 1372 ms
第71次寫入總用時(shí): 1261 ms
第72次寫入總用時(shí): 1024 ms
第73次寫入總用時(shí): 1048 ms
第74次寫入總用時(shí): 904 ms
第75次寫入總用時(shí): 941 ms
第76次寫入總用時(shí): 928 ms
第77次寫入總用時(shí): 1806 ms
第78次寫入總用時(shí): 1052 ms
第79次寫入總用時(shí): 1030 ms
第80次寫入總用時(shí): 1092 ms
第81次寫入總用時(shí): 1117 ms
第82次寫入總用時(shí): 950 ms
第83次寫入總用時(shí): 933 ms
第84次寫入總用時(shí): 928 ms
第85次寫入總用時(shí): 935 ms
第86次寫入總用時(shí): 1908 ms
第87次寫入總用時(shí): 994 ms
第88次寫入總用時(shí): 1097 ms
第89次寫入總用時(shí): 930 ms
第90次寫入總用時(shí): 1052 ms
第91次寫入總用時(shí): 1119 ms
第92次寫入總用時(shí): 958 ms
第93次寫入總用時(shí): 987 ms
第94次寫入總用時(shí): 973 ms
第95次寫入總用時(shí): 2036 ms
第96次寫入總用時(shí): 891 ms
第97次寫入總用時(shí): 954 ms
第98次寫入總用時(shí): 951 ms
第99次寫入總用時(shí): 1044 ms
第100次寫入總用時(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 整體性能略優(yōu)于 SSDB 但是理論上不太應(yīng)該， SSDB 怎么說也是半內(nèi)存半硬盤的NoSQL不應(yīng)該比純硬盤的 MinIO 性能要差，有可能是 SSDB 寫到一定數(shù)據(jù)量后把本機(jī)內(nèi)存寫爆了，導(dǎo)致讀寫非常慢。但這變相驗(yàn)證了 SSDB 在極端情況下的不穩(wěn)定。
待遇不錯(cuò)。
tidb和mysql幾乎完全兼容，所以我們的程序沒有任何改動(dòng)就完成了數(shù)據(jù)庫從mysql到TiDb的轉(zhuǎn)換，TiDB 是一個(gè)分布式 NewSQL (SQL 、 NoSQL 和 NewSQL 的優(yōu)缺點(diǎn)比較 )數(shù)據(jù)庫。它支持水平彈性擴(kuò)展、ACID 事務(wù)、標(biāo)準(zhǔn) SQL、MySQL 語法和 MySQL 協(xié)議，具有數(shù)據(jù)強(qiáng)一致的高可用特性，是一個(gè)不僅適合 OLTP 場景還適合 OLAP 場景的混合數(shù)據(jù)庫。
本期目錄
DB-Engines數(shù)據(jù)庫排行榜
新聞快訊
一、RDBMS家族
二、NoSQL家族
三、NewSQL家族
四、時(shí)間序列
五、大數(shù)據(jù)生態(tài)圈
六、國產(chǎn)數(shù)據(jù)庫概覽
七、云數(shù)據(jù)庫
八、推出dbaplus Newsletter的想法
九、感謝名單
為方便閱讀、重點(diǎn)呈現(xiàn)，本期Newsletter（2019年1月）將對(duì)各個(gè)板塊的內(nèi)容進(jìn)行精簡。需要閱讀全文的同學(xué)可點(diǎn)擊文末 【閱讀原文】 或登錄
進(jìn)行下載。
DB-Engines數(shù)據(jù)庫排行榜
以下取自2019年1月的數(shù)據(jù)，具體信息可以參考，數(shù)據(jù)僅供參考。
DB-Engines排名的數(shù)據(jù)依據(jù)5個(gè)不同的因素：
新聞快訊
1、2018年9月24日，微軟公布了SQL Server2019預(yù)覽版，SQL Server 2019將結(jié)合Spark創(chuàng)建統(tǒng)一數(shù)據(jù)平臺(tái)。
2、2018年10月5日，ElasticSearch在美國紐約證券交易所上市。
3、亞馬遜放棄甲骨文數(shù)據(jù)庫軟件，導(dǎo)致最大倉庫之一在黃金時(shí)段宕機(jī)。受此消息影響，亞馬遜盤前股價(jià)小幅跳水，跌超2%。
4、2018年10月31日，Percona發(fā)布了Percona Server 8.0 RC版本，發(fā)布對(duì)MongoDB 4.0的支持，發(fā)布對(duì)XtraBackup測試第二個(gè)版本。
5、2018年10月31日，Gartner陸續(xù)發(fā)布了2018年的數(shù)據(jù)庫系列報(bào)告，包括《數(shù)據(jù)庫魔力象限》、《數(shù)據(jù)庫核心能力》以及《數(shù)據(jù)庫推薦報(bào)告》。
今年的總上榜數(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萬歐元）的價(jià)格收購了Apache Flink商業(yè)公司DataArtisans。
8、2019年1月11日早間消息，亞馬遜宣布推出云數(shù)據(jù)庫軟件，亞馬遜和MongoDB將會(huì)直接競爭。
RDBMS家族
Oracle 發(fā)布18.3版本
2018年7月，Oracle Database 18.3通用版開始提供下載。我們可以將Oracle Database 18c視為采用之前發(fā)布模式的Oracle Database 12c第2版的第一個(gè)補(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)過配置，修改密碼時(shí)，必須帶上原密碼。在之前的版本，用戶登錄之后，就可以修改自己的密碼。這種方式存在一定安全風(fēng)險(xiǎn)。比如用戶登錄上數(shù)據(jù)庫后，中途離開一段時(shí)間，那么非法用戶可能會(huì)修改密碼。由參數(shù)password_require_current控制。
2、配置
Innodb表必須有主鍵。在用戶沒有指定主鍵時(shí)，系統(tǒng)會(huì)生成一個(gè)默認(rèn)的主鍵。但是在主從復(fù)制的場景下，默認(rèn)的主鍵，會(huì)對(duì)叢庫應(yīng)用速度帶來致命的影響。如果設(shè)置sql_require_primary_key，那么數(shù)據(jù)庫會(huì)強(qiáng)制用戶在創(chuàng)建表、修改表時(shí)，加上主鍵。
3、字段默認(rèn)值
BLOB、TEXT、GEOMETRY和JSON字段可以指定默認(rèn)值了。
4、優(yōu)化器
1）Skip Scan
非前綴索引也可以用了。
之前的版本，任何沒有帶上f1字段的查詢，都沒法使用索引。在新的版本中，它可以忽略前面的字段，讓這個(gè)查詢使用到索引。其實(shí)現(xiàn)原理就是把(f1 = 1 AND f2 40) 和(f1 = 2 AND f2 40)的查詢結(jié)果合并。
2）函數(shù)索引
之前版本只能基于某個(gè)列或者多個(gè)列加索引，但是不允許在上面做計(jì)算，如今這個(gè)限制消除了。
5、SQL語法
GROUP BY ASC和GROUP BY DESC語法已經(jīng)被廢棄，要想達(dá)到類似的效果，請(qǐng)使用GROUP BY ORDER BY ASC和GROUP BY ORDER BY DESC。
6、功能變化
1）設(shè)置用戶變量，請(qǐng)使用SET語句
如下類型語句將要被廢棄SELECT @var, @var:=@var+1。
2）新增innodb_fsync_threshold
該變量是控制文件刷新到磁盤的速率，防止磁盤在短時(shí)間內(nèi)飽和。
3）新增會(huì)話級(jí)臨時(shí)表空間
在以往的版本中，當(dāng)執(zhí)行SQL時(shí)，產(chǎn)生的臨時(shí)表都在全局表空間ibtmp1中，及時(shí)執(zhí)行結(jié)束，臨時(shí)表被釋放，空間不會(huì)被回收。新版本中，會(huì)為session從臨時(shí)表空間池中分配一個(gè)臨時(shí)表空間，當(dāng)連接斷開時(shí)，臨時(shí)表空間的磁盤空間被回收。
4）在線切換Group Replication的狀態(tài)
5）新增了group_replication_member_expel_timeout
之前，如果某個(gè)節(jié)點(diǎn)被懷疑有問題，在5秒檢測期結(jié)束之后，那么就直接被驅(qū)逐出這個(gè)集群。即使該節(jié)點(diǎn)恢復(fù)正常時(shí)，也不會(huì)再被加入集群。那么，瞬時(shí)的故障，會(huì)把某些節(jié)點(diǎn)驅(qū)逐出集群。
group_replication_member_expel_timeout讓管理員能更好的依據(jù)自身的場景，做出最合適的配置（建議配置時(shí)間小于一個(gè)小時(shí)）。
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直接報(bào)錯(cuò)
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直接報(bào)錯(cuò)
MariaDB 10.3更新成功
參考：
2、MariaDB10.3增補(bǔ)AliSQL補(bǔ)丁——安全執(zhí)行Online DDL
Online DDL從名字上看很容易誤導(dǎo)新手，以為不論什么情況，修改表結(jié)構(gòu)都不會(huì)鎖表，理想很豐滿，現(xiàn)實(shí)很骨感，注意這個(gè)坑！
有以下兩種情況執(zhí)行DDL操作會(huì)鎖表的，Waiting for table metadata lock（元數(shù)據(jù)表鎖）：
針對(duì)第二種情況，MariaDB10.3增補(bǔ)AliSQL補(bǔ)丁-DDL FAST FAIL，讓其DDL操作快速失敗。
例：
如果線上有某個(gè)慢SQL對(duì)該表進(jìn)行操作，可以使用WAIT n（以秒為單位設(shè)置等待）或NOWAIT在語句中顯式設(shè)置鎖等待超時(shí)，在這種情況下，如果無法獲取鎖，語句將立即失敗。 WAIT 0相當(dāng)于NOWAIT。
參考：
3、MariaDB Window Functions窗口函數(shù)分組取TOP N記錄
窗口函數(shù)在MariaDB10.2版本里實(shí)現(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存儲(chǔ)引擎。相比LevelDB，RocksDB提供了Column-Family，TTL，Transaction，Merge等方面的支持。目前MyRocks，TiKV等底層的存儲(chǔ)都是基于RocksDB來構(gòu)建。
PostgreSQL發(fā)布11版本
2018年10月18日，PostgreSQL 11發(fā)布。
1、PostgreSQL 11的重大增強(qiáng)
2、PostgreSQL 插件動(dòng)態(tài)
1）分布式插件citus發(fā)布 8.1
citus是PostgreSQL的一款sharding插件，目前國內(nèi)蘇寧、鐵總、探探有較大量使用案例。
2）地理信息插件postgis發(fā)布2.5.1
PostGIS是專業(yè)的時(shí)空數(shù)據(jù)庫插件，在測繪、航天、氣象、地震、國土資源、地圖等時(shí)空專業(yè)領(lǐng)域應(yīng)用廣泛。同時(shí)在互聯(lián)網(wǎng)行業(yè)也得到了對(duì)GIS有性能、功能深度要求的客戶青睞，比如共享出行、外賣等客戶。
3）時(shí)序插件timescale發(fā)布1.1.1
timescale是PostgreSQL的一款時(shí)序數(shù)據(jù)庫插件，在IoT行業(yè)中有非常好的應(yīng)用。github star數(shù)目前有5000多，是一個(gè)非?；鸨牟寮?。
4）流計(jì)算插件 pipelinedb 正式插件化
Pipelinedb是PostgreSQL的一款流計(jì)算插件，使用這個(gè)創(chuàng)建可以對(duì)高速寫入的數(shù)據(jù)進(jìn)行實(shí)時(shí)根據(jù)定義的聚合規(guī)則進(jìn)行聚合（支持概率計(jì)算），實(shí)時(shí)根據(jù)定義的規(guī)則觸發(fā)事件（支持事件處理函數(shù)的自定義）?？捎糜贗oT，監(jiān)控，F(xiàn)EED實(shí)時(shí)計(jì)算等場景。
3、PostgreSQL衍生開源產(chǎn)品動(dòng)態(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ù)計(jì)很快會(huì)追上10的PostgreSQL，在TP方面的性能也會(huì)得到顯著提升。
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，包含以下幾方面的改動(dòng)及增強(qiáng)：
1、性能
2、高可用
3、管理視圖
4、應(yīng)用開發(fā)方面
5、聯(lián)邦功能
6、pureScale
NoSQL家族
Redis發(fā)布5.0.3版本
MongoDB升級(jí)更新MongoDB Mobile和MongoDB Stitch
2018年11月21日，MongoDB升級(jí)更新MongoDB Mobile和MongoDB Stitch，助力開發(fā)人員提升工作效率。
MongoDB 公司日前發(fā)布了多項(xiàng)新產(chǎn)品功能，旨在更好地幫助開發(fā)人員在世界各地管理數(shù)據(jù)。通過利用存儲(chǔ)在移動(dòng)設(shè)備和后臺(tái)數(shù)據(jù)庫的數(shù)據(jù)之間的實(shí)時(shí)、自動(dòng)的同步特性，MongoDB Mobile通用版本助力開發(fā)人員構(gòu)建更快捷、反應(yīng)更迅速的應(yīng)用程序。此前，這只能通過在移動(dòng)應(yīng)用內(nèi)部安裝一個(gè)可供選擇或限定功能的數(shù)據(jù)庫來實(shí)現(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ā)包訪問移動(dòng)客戶端或后臺(tái)數(shù)據(jù)，幫助開發(fā)人員通過他們希望的任意方式查詢移動(dòng)終端數(shù)據(jù)和物聯(lián)網(wǎng)數(shù)據(jù)，包括本地讀寫、本地JSON存儲(chǔ)、索引和聚合。通過Stitch移動(dòng)同步功能(現(xiàn)可提供beta版)，用戶可以自動(dòng)對(duì)保存在本地的數(shù)據(jù)以及后臺(tái)數(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ù)庫或鍵值存儲(chǔ)key-value數(shù)據(jù)庫不同，Cassandra使用的是寬列存儲(chǔ)模型(Wide Column Stores)。與BigTable和其模仿者HBase不同，數(shù)據(jù)并不存儲(chǔ)在分布式文件系統(tǒng)如GFS或HDFS中，而是直接存于本地。
Cassandra的系統(tǒng)架構(gòu)與Amazon DynamoDB類似，是基于一致性哈希的完全P2P架構(gòu)，每行數(shù)據(jù)通過哈希來決定應(yīng)該存在哪個(gè)或哪些節(jié)點(diǎn)中。集群沒有master的概念，所有節(jié)點(diǎn)都是同樣的角色，徹底避免了整個(gè)系統(tǒng)的單點(diǎn)問題導(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ǔ)上，對(duì)系統(tǒng)兼容性、穩(wěn)定性做出了改進(jìn)。
TiDB 是一款定位于在線事務(wù)處理/在線分析處理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型數(shù)據(jù)庫產(chǎn)品。除了底層的 RocksDB 存儲(chǔ)引擎之外，分布式SQL層、分布式KV存儲(chǔ)引擎（TiKV）完全自主設(shè)計(jì)和研發(fā)。
TiDB 完全開源，兼容MySQL協(xié)議和語法，可以簡單理解為一個(gè)可以無限水平擴(kuò)展的MySQL，并且提供分布式事務(wù)、跨節(jié)點(diǎn) JOIN、吞吐和存儲(chǔ)容量水平擴(kuò)展、故障自恢復(fù)、高可用等優(yōu)異的特性；對(duì)業(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è)級(jí)產(chǎn)品，EsgynDB 2.5向前邁進(jìn)了一大步，它擁有以下功能和改進(jìn)：
CockroachDB發(fā)布2.1版本
2018年10月30日，CockroachDB正式發(fā)布2.1版本，其新增特性如下：
新增企業(yè)級(jí)特性：
新增SQL特性：
新增內(nèi)核特性：
Admin UI增強(qiáng)：
時(shí)間序列
本期新秀：TimescaleDB發(fā)布1.0版本
10月底，TimescaleDB 1.0宣布正式推出，官方表示該版本已可用于生產(chǎn)環(huán)境，支持完整SQL和擴(kuò)展。
TimescaleDB是基于PostgreSQL數(shù)據(jù)庫開發(fā)的一款時(shí)序數(shù)據(jù)庫，以插件化的形式打包提供，隨著PostgreSQL的版本升級(jí)而升級(jí)，不會(huì)因?yàn)榱砹⒎种砺闊?/p>
TimescaleDB架構(gòu)：
數(shù)據(jù)自動(dòng)按時(shí)間和空間分片(chunk)
更新亮點(diǎn)：
大數(shù)據(jù)生態(tài)圈
Hadoop發(fā)布2.9.2版本
2018年11月中旬，Hadoop在2.9分支上發(fā)布了新的2.9.2版本，該版本進(jìn)行了204個(gè)大大小小的變更，主要變更如下：
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）完整計(jì)算存儲(chǔ)分離架構(gòu)，兼容MySQL協(xié)議、語法
計(jì)算存儲(chǔ)分離體系以松耦合的方式將計(jì)算與存儲(chǔ)層分別部署，通過標(biāo)準(zhǔn)接口或插件對(duì)各個(gè)模塊和組件進(jìn)行無縫替換，在計(jì)算層與存儲(chǔ)層均可實(shí)現(xiàn)自由的彈性伸縮。
SequoiaDB巨杉數(shù)據(jù)庫“計(jì)算-存儲(chǔ)分離”架構(gòu)詳細(xì)示意
用戶可以根據(jù)自身業(yè)務(wù)特征選擇面向交易的SQL解析器（例如MySQL或PGSQL）或面向統(tǒng)計(jì)分析的執(zhí)行引擎（例如SparkSQL）。眾所周知，使用不同的SQL優(yōu)化與執(zhí)行方式，數(shù)據(jù)庫的訪問性能可能會(huì)存在上千上萬倍的差距。計(jì)算存儲(chǔ)分離的核心思想便是在數(shù)據(jù)存儲(chǔ)層面進(jìn)行一體化存儲(chǔ)，在計(jì)算層面則利用每種執(zhí)行引擎的特點(diǎn)針對(duì)不同業(yè)務(wù)場景進(jìn)行選擇和優(yōu)化，用戶可以在存儲(chǔ)層進(jìn)行邏輯與物理的隔離，將面向高頻交易的前端業(yè)務(wù)與面向高吞吐量的統(tǒng)計(jì)分析使用不同的硬件進(jìn)行存儲(chǔ)，確保在多類型數(shù)據(jù)訪問時(shí)互不干擾，以真正達(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è)化三個(gè)迭代，在廣州、上海、北京正式全量商業(yè)化上線。
產(chǎn)品特性：
使用場景：
官網(wǎng)文檔：
3、騰訊自研數(shù)據(jù)庫CynosDB發(fā)布，開啟公測
2018年11月22日，騰訊云召開新一代自研數(shù)據(jù)庫CynosDB發(fā)布會(huì)，業(yè)界第一款全面兼容市面上兩大最主流的開源數(shù)據(jù)庫MySQL和PostgreSQL的高性能企業(yè)級(jí)分布式云數(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)新獎(jiǎng)”。DRDS可實(shí)現(xiàn)海量數(shù)據(jù)下的自動(dòng)分庫分表，具有高性能，分布式，彈性升級(jí)，兼容MySQL等優(yōu)點(diǎn)，適用于高并發(fā)、大規(guī)模數(shù)據(jù)的在線交易， 歷史 數(shù)據(jù)查詢，自動(dòng)數(shù)據(jù)分片等業(yè)務(wù)場景，歷經(jīng)多次618，雙十一的考驗(yàn)，已經(jīng)在京東集團(tuán)內(nèi)大規(guī)模使用。
京東云DRDS產(chǎn)品有以下主要特性
1）自動(dòng)分庫分表
通過簡單的定義即可自動(dòng)實(shí)現(xiàn)分庫分表，將數(shù)據(jù)實(shí)際存放在多個(gè)MySQL實(shí)例的數(shù)據(jù)庫中，但呈現(xiàn)給應(yīng)用程序的依舊是一張表，對(duì)業(yè)務(wù)透明，應(yīng)用程序幾乎無需改動(dòng)，實(shí)現(xiàn)了對(duì)數(shù)據(jù)庫存儲(chǔ)和處理能力的水平擴(kuò)展。
2）分布式架構(gòu)
基于分布式架構(gòu)的集群方案，多個(gè)對(duì)等節(jié)點(diǎn)同時(shí)對(duì)外提供服務(wù)，不但可有效規(guī)避服務(wù)的單點(diǎn)故障，而且更加容易擴(kuò)展。
3）超強(qiáng)性能
具有極高的處理能力，雙節(jié)點(diǎn)即可支持?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ā)展趨勢(shì)，為社區(qū)的技術(shù)發(fā)展提供一個(gè)統(tǒng)一的發(fā)聲平臺(tái)。為此，我們策劃了RDBMS、NoSQL、NewSQL、時(shí)間序列、大數(shù)據(jù)生態(tài)圈、國產(chǎn)數(shù)據(jù)庫、云數(shù)據(jù)庫等幾個(gè)版塊。
我們不以商業(yè)宣傳為目的，不接受任何商業(yè)廣告宣傳，嚴(yán)格審查信息源的可信度和準(zhǔn)確性，力爭為大家提供一個(gè)純凈的技術(shù)學(xué)習(xí)環(huán)境，歡迎大家監(jiān)督指正。
至于Newsletter發(fā)布的周期，目前計(jì)劃是每三個(gè)月左右會(huì)做一次跟進(jìn)， 下期計(jì)劃時(shí)間是2019年4月14日~4月25日， 如果有相關(guān)的信息提供請(qǐng)發(fā)送至郵箱：newsletter@dbaplus.cn
感謝名單
最后要感謝那些提供寶貴信息和建議的專家朋友，排名不分先后。
往期回顧：
↓↓別忘了點(diǎn)這里下載 2019年1月 完整版Newsletter 哦~
TiDB 是國內(nèi) PingCAP 團(tuán)隊(duì)開發(fā)的一個(gè)分布式 SQL 數(shù)據(jù)庫，支持包括傳統(tǒng) RDBMS 和 NoSQL 的特性?，F(xiàn)已將 DM（data migration platform，該數(shù)據(jù)遷移工具）開源。
該數(shù)據(jù)遷移工具遵循 Apache-2.0 開源協(xié)議，允許用戶自由地使用及修改。
據(jù)介紹，DM (Data Migration) 是一體化數(shù)據(jù)同步任務(wù)管理平臺(tái)，支持從 MySQL/MariaDB 到 TiDB 的數(shù)據(jù)遷移、全量備份和 MariaDB/MySQL binlog 增量同步，有助于減少操作成本和簡化錯(cuò)誤處理流程。架構(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ì)的組件功能介紹，可以查閱官方文檔。
重慶分公司
重慶分公司
