張 偉

(中國(guó)大唐集團(tuán)科學(xué)技術(shù)研究院有限公司，北京 100040)

0 引言

中國(guó)人口老齡化加速、慢性病人數(shù)劇增以及社會(huì)生活水平的提高，人們對(duì)醫(yī)療服務(wù)的需求越來(lái)越高，同時(shí)醫(yī)療資源緊缺且分配不均，供需矛盾日益凸顯，利用信息化手段提高醫(yī)療行業(yè)的服務(wù)范圍和服務(wù)水平已經(jīng)迫在眉睫。

醫(yī)療大數(shù)據(jù)平臺(tái)是通過(guò)使用移動(dòng)通信技術(shù)(例如 IPDA、移動(dòng)電話和衛(wèi)星通信)來(lái)提供醫(yī)療服務(wù)和信息。隨著全球智能手機(jī)和新型創(chuàng)新連接設(shè)備普及率的日漸提高以及移動(dòng)寬帶網(wǎng)絡(luò)和服務(wù)的拓展，醫(yī)療大數(shù)據(jù)平臺(tái)無(wú)疑將在未來(lái)的醫(yī)療健康行業(yè)發(fā)揮重要作用。移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)等相關(guān)技術(shù)與預(yù)防及臨床醫(yī)學(xué)相結(jié)合，可以為廣大民眾提供隨時(shí)隨地的健康關(guān)愛(ài)服務(wù)?？梢哉f(shuō)醫(yī)療大數(shù)據(jù)平臺(tái)的出現(xiàn)給整個(gè)醫(yī)療健康行業(yè)帶來(lái)了前所未有的新體驗(yàn)，也促使著醫(yī)療健康行業(yè)面向信息化、移動(dòng)化的方向發(fā)展。

醫(yī)療大數(shù)據(jù)應(yīng)用是典型的面向互聯(lián)網(wǎng)大眾用戶應(yīng)用，因此大數(shù)據(jù)量和高并發(fā)的要求比較高。集群技術(shù)和負(fù)載均衡技術(shù)作為業(yè)界通用的高并發(fā)解決技術(shù)會(huì)有廣泛的用武之地，但這些技術(shù)相對(duì)來(lái)說(shuō)在開(kāi)發(fā)、部署、運(yùn)維等方面需要較高的人工成本和技術(shù)門(mén)檻。近年隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，針對(duì)系統(tǒng)的高并發(fā)問(wèn)題，涌現(xiàn)出越來(lái)越多的開(kāi)源解決方案。這些解決方案在不同的行業(yè)應(yīng)用中已經(jīng)得到了生產(chǎn)環(huán)境的充分驗(yàn)證[1]。作為醫(yī)療業(yè)務(wù)應(yīng)用來(lái)說(shuō)，需要結(jié)合行業(yè)領(lǐng)域的數(shù)據(jù)和業(yè)務(wù)特點(diǎn)，有針對(duì)性地對(duì)技術(shù)進(jìn)行選型。本文將結(jié)合作者近幾年在移動(dòng)健康業(yè)務(wù)系統(tǒng)開(kāi)發(fā)領(lǐng)域的工作實(shí)踐和對(duì)現(xiàn)階段主流開(kāi)源開(kāi)發(fā)技術(shù)的應(yīng)用，在對(duì)移動(dòng)健康業(yè)務(wù)系統(tǒng)的數(shù)據(jù)和業(yè)務(wù)特點(diǎn)深入理解和分析的基礎(chǔ)上，從開(kāi)源技術(shù)角度對(duì)端到端的高并發(fā)問(wèn)題詳細(xì)描述技術(shù)選型和個(gè)人應(yīng)用實(shí)踐經(jīng)驗(yàn)。

1 醫(yī)療大數(shù)據(jù)平臺(tái)高并發(fā)需求分析

1.1 醫(yī)療大數(shù)據(jù)平臺(tái)數(shù)據(jù)和業(yè)務(wù)特點(diǎn)

任何行業(yè)的互聯(lián)網(wǎng)應(yīng)用都面臨著大數(shù)據(jù)和高并發(fā)的挑戰(zhàn)，隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，針對(duì)高并發(fā)問(wèn)題，業(yè)界各類(lèi)互聯(lián)網(wǎng)應(yīng)用充分利用新興互聯(lián)網(wǎng)技術(shù)進(jìn)行了非常有效的實(shí)踐[2]。這些實(shí)踐經(jīng)驗(yàn)和技術(shù)成果對(duì)于我們開(kāi)發(fā)移動(dòng)健康業(yè)務(wù)系統(tǒng)有很好的借鑒意義。但同時(shí)也要看到，醫(yī)療大數(shù)據(jù)平臺(tái)有自己特有的數(shù)據(jù)和業(yè)務(wù)特點(diǎn)，這些特點(diǎn)對(duì)我們解決高并發(fā)問(wèn)題在技術(shù)選型上有重要的指導(dǎo)意義。醫(yī)療大數(shù)據(jù)平臺(tái)的數(shù)據(jù)和業(yè)務(wù)特點(diǎn)如下：

(1)需要采集各種體征數(shù)據(jù)的醫(yī)療業(yè)務(wù)系統(tǒng)需要通過(guò)各類(lèi)便攜式終端采集用戶的體征數(shù)據(jù)，如血壓、血糖、心電、睡眠、運(yùn)動(dòng)情況等。業(yè)務(wù)系統(tǒng)基于這些信息提供各類(lèi)業(yè)務(wù)功能給用戶使用。移動(dòng)健康業(yè)務(wù)系統(tǒng)需要解決好這些數(shù)據(jù)的高并發(fā)傳輸問(wèn)題。

(2)數(shù)據(jù)庫(kù)事務(wù)一致性需求。業(yè)務(wù)系統(tǒng)并不要求嚴(yán)格的數(shù)據(jù)庫(kù)事務(wù)，對(duì)讀一致性的要求很低，有些場(chǎng)合對(duì)寫(xiě)一致性要求也不高。因此數(shù)據(jù)庫(kù)事務(wù)管理成了數(shù)據(jù)庫(kù)高負(fù)載下一個(gè)沉重的負(fù)擔(dān)。

(3)數(shù)據(jù)庫(kù)的寫(xiě)實(shí)時(shí)性和讀實(shí)時(shí)性需求。移動(dòng)健康業(yè)務(wù)系統(tǒng)圍繞體征數(shù)據(jù)展開(kāi)各類(lèi)業(yè)務(wù)流程，在對(duì)數(shù)據(jù)層的查詢(xún)上一般是一次錄入多次讀取，相比其他業(yè)務(wù)系統(tǒng)如銀行、網(wǎng)購(gòu)等行業(yè)應(yīng)用，業(yè)務(wù)系統(tǒng)在數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性要求上也不需要太過(guò)苛刻。對(duì)關(guān)系數(shù)據(jù)庫(kù)來(lái)說(shuō)，插入一條數(shù)據(jù)之后立刻查詢(xún)，可以很快讀出來(lái)這條數(shù)據(jù)，但是對(duì)于移動(dòng)健康業(yè)務(wù)系統(tǒng)來(lái)說(shuō)，并不要求這么高的實(shí)時(shí)性。

(4)對(duì)復(fù)雜的SQL查詢(xún)，特別是多表關(guān)聯(lián)查詢(xún)的需求。任何大數(shù)據(jù)量的Web系統(tǒng)，都非常忌諱多個(gè)大表的關(guān)聯(lián)查詢(xún)以及復(fù)雜的數(shù)據(jù)分析類(lèi)型的復(fù)雜SQL報(bào)表查詢(xún)，從需求以及產(chǎn)品設(shè)計(jì)角度，就避免了這種情況的產(chǎn)生。業(yè)務(wù)系統(tǒng)往往更多地只是單表的主鍵查詢(xún)以及單表的簡(jiǎn)單條件分頁(yè)查詢(xún)，SQL的功能被極大地弱化了。

1.2 醫(yī)療大數(shù)據(jù)平臺(tái)高并發(fā)需求

本小節(jié)對(duì)醫(yī)療大數(shù)據(jù)平臺(tái)的體系架構(gòu)進(jìn)行簡(jiǎn)要描述，并對(duì)分層對(duì)高并發(fā)需求進(jìn)行分析。醫(yī)療大數(shù)據(jù)平臺(tái)典型體系架構(gòu)如圖1所示。

圖1 移動(dòng)健康業(yè)務(wù)系統(tǒng)架構(gòu)圖

圖1中數(shù)據(jù)采集層、數(shù)據(jù)存儲(chǔ)層、業(yè)務(wù)處理層是高并發(fā)問(wèn)題最集中的三層，其高并發(fā)需求的詳細(xì)分析如下：

(1)數(shù)據(jù)采集層：移動(dòng)系統(tǒng)需求采集各類(lèi)可穿戴設(shè)備的體征數(shù)據(jù)，這些設(shè)備包括計(jì)步器、血壓計(jì)、血糖儀、手環(huán)、心電終端、智能手機(jī)等。從數(shù)據(jù)形式上來(lái)看，采集的體征數(shù)據(jù)有二進(jìn)制格式和字符串格式，相應(yīng)的數(shù)據(jù)采集層需要提供TCP/UDP或者HTTP協(xié)議的接口接收數(shù)據(jù)，并根據(jù)相應(yīng)的權(quán)限對(duì)外開(kāi)放查詢(xún)接口供外部系統(tǒng)查詢(xún)，或者傳輸數(shù)據(jù)到某個(gè)具體的業(yè)務(wù)應(yīng)用。

本層的高并發(fā)主要在于數(shù)據(jù)量比較大。以計(jì)步器為例，不考慮重復(fù)上傳和用戶手動(dòng)上傳的情況，每個(gè)計(jì)步器每天需要自動(dòng)定時(shí)上傳5～6條簡(jiǎn)要包數(shù)據(jù)和24條分小時(shí)的詳細(xì)包數(shù)據(jù)。這樣算來(lái)，僅僅1萬(wàn)用戶每天就需要上傳近30萬(wàn)條計(jì)步數(shù)據(jù)，用戶量大的時(shí)候，高并發(fā)需求凸顯。

(2)數(shù)據(jù)存儲(chǔ)層：數(shù)據(jù)存儲(chǔ)層存儲(chǔ)采集層接收到的各類(lèi)體征數(shù)據(jù)以及業(yè)務(wù)處理層生成的各類(lèi)業(yè)務(wù)數(shù)據(jù)，這些數(shù)據(jù)提供了數(shù)據(jù)挖掘和業(yè)務(wù)處理的支撐。數(shù)據(jù)量巨大是本層的主要特點(diǎn)。如果用戶量比較大，在海量數(shù)據(jù)的基礎(chǔ)上進(jìn)行查詢(xún)，數(shù)據(jù)存儲(chǔ)層的查詢(xún)效率將是一個(gè)很大的挑戰(zhàn)，處理不好就會(huì)成為系統(tǒng)的性能瓶頸。

(3)業(yè)務(wù)處理層：業(yè)務(wù)處理層需要基于產(chǎn)品設(shè)計(jì)開(kāi)發(fā)各類(lèi)業(yè)務(wù)應(yīng)用的訪問(wèn)接口，實(shí)現(xiàn)用戶的各類(lèi)業(yè)務(wù)需求。首先是海量用戶的并發(fā)訪問(wèn)給業(yè)務(wù)處理層提出了挑戰(zhàn)，需要充分利用良好的技術(shù)架構(gòu)和緩存技術(shù)進(jìn)行解決[3]。其次，業(yè)務(wù)處理層會(huì)有許多統(tǒng)計(jì)分析類(lèi)功能，它們要在海量數(shù)據(jù)查詢(xún)的基礎(chǔ)之上進(jìn)行大量耗時(shí)比較長(zhǎng)的復(fù)雜運(yùn)算，這些功能需要充分利用分布式并行技術(shù)提高運(yùn)算效率。

2 醫(yī)療大數(shù)據(jù)平臺(tái)高并發(fā)解決方案

2.1 數(shù)據(jù)采集層

2.1.1二進(jìn)制數(shù)據(jù)接收

二進(jìn)制數(shù)據(jù)需要通過(guò)TCP/UDP協(xié)議傳輸，通常的做法是利用socket編程來(lái)實(shí)現(xiàn)。然而不管采用TCP還是UDP協(xié)議的socket編程，可穿戴健康設(shè)備和數(shù)據(jù)采集層接口之間都是同步阻塞式 IO 的，每個(gè)傳輸由單獨(dú)的線程實(shí)現(xiàn)。雖然可以通過(guò)多線程實(shí)現(xiàn)同時(shí)接收多個(gè)客戶端數(shù)據(jù)，但隨著并發(fā)量的增大，服務(wù)器開(kāi)啟的線程數(shù)目會(huì)增多，將會(huì)消耗過(guò)多的服務(wù)器內(nèi)存資源，導(dǎo)致服務(wù)器變慢甚至崩潰。因此在大量可穿戴健康設(shè)備連接數(shù)據(jù)采集層接口的時(shí)候，高并發(fā)問(wèn)題會(huì)凸顯出來(lái)，導(dǎo)致大量的傳輸連接請(qǐng)求被拒絕。

分析可穿戴健康設(shè)備上傳的數(shù)據(jù)不難發(fā)現(xiàn)，單個(gè)客戶端每次傳輸?shù)臄?shù)據(jù)并不大，需要的鏈接時(shí)間很小，但并發(fā)量比較大，非阻塞式IO傳輸正適合此類(lèi)型的數(shù)據(jù)傳輸。作為T(mén)CP/UDP 協(xié)議級(jí)別的非阻塞式IO傳輸，目前比較流行的開(kāi)源框架有Netty和Mina框架。這兩個(gè)框架都是由同一個(gè)人開(kāi)創(chuàng)的，在設(shè)計(jì)理念等方面比較類(lèi)似，并發(fā)性能上都可以滿足實(shí)際需求。

下面以 Mina 為例簡(jiǎn)述一下此開(kāi)源技術(shù)是如何解決高并發(fā)問(wèn)題的。Apache Mina 是一個(gè)網(wǎng)絡(luò)通信應(yīng)用框架，它主要是針對(duì)基于TCP/ UDP協(xié)議棧的通信框架，Mina可以幫助我們快速開(kāi)發(fā)高性能、高擴(kuò)展性的網(wǎng)絡(luò)通信應(yīng)用，提供了事件驅(qū)動(dòng)、異步操作的編程模型。Mina是介于用戶業(yè)務(wù)和底層的socket之間的中間層,它簡(jiǎn)單易用，幫助實(shí)現(xiàn)下層的NIO處理細(xì)節(jié)，讓開(kāi)發(fā)者把關(guān)注點(diǎn)放在具體的業(yè)務(wù)實(shí)現(xiàn)上。

2.1.2字符串?dāng)?shù)據(jù)接收

作為字符串形式的數(shù)據(jù)接收，一般需要高層通信協(xié)議，比如SOAP、HTTP等，通常的架構(gòu)設(shè)計(jì)是采用RPC方式，如圖2所示。

圖2 RPC方式交互數(shù)據(jù)圖

如果使用RPC方式建立可穿戴設(shè)備和服務(wù)器的連接，由于可穿戴設(shè)備必須阻塞式的等待服務(wù)器返回?cái)?shù)據(jù)處理結(jié)果，在高并發(fā)情況下將會(huì)嚴(yán)重影響執(zhí)行效率和資源使用率，給服務(wù)器造成很大壓力。

分析此類(lèi)數(shù)據(jù)不難發(fā)現(xiàn)，可穿戴設(shè)備要把數(shù)據(jù)傳輸給服務(wù)器，只需要把相關(guān)信息封裝到數(shù)據(jù)中，不需要關(guān)心服務(wù)器對(duì)數(shù)據(jù)的接收處理細(xì)節(jié)，因此為了提高并發(fā)能力，需要采用圖3所示松耦合的技術(shù)架構(gòu)。

圖3 消息隊(duì)列方式交互數(shù)據(jù)圖

客戶端A向消息中介(Queue)發(fā)送一條消息，很可能一段時(shí)間之后，客戶端B調(diào)用Queue來(lái)收取消息。任何一個(gè)應(yīng)用程序都不知道對(duì)方是否存在，也不需要阻塞等待。這種通信方式大大縮減了維護(hù)開(kāi)銷(xiāo)，而且對(duì)于一個(gè)應(yīng)用程序的修改對(duì)其他應(yīng)用程序影響極小?；谶@種松耦合的消息方式的開(kāi)源技術(shù)有很多，比如ActiveMQ、RabbitMQ、ZeroMQ等。

以ActiveMQ為例，它是一種開(kāi)源的實(shí)現(xiàn)了JMS1.1規(guī)范的面向消息的中間件，為應(yīng)用程序提供高效、可擴(kuò)展、穩(wěn)定和安全的企業(yè)級(jí)消息通信。它支持兩種截然不同的消息傳送模型：PTP(即點(diǎn)對(duì)點(diǎn)模型)和Pub/Sub(即發(fā)布/訂閱模型，并且可以持久化數(shù)據(jù)，保障數(shù)據(jù)的安全性)。

2.2 數(shù)據(jù)存儲(chǔ)層

移動(dòng)健康業(yè)務(wù)系統(tǒng)作為一個(gè)基于大數(shù)據(jù)高并發(fā)的互聯(lián)網(wǎng)產(chǎn)品，數(shù)據(jù)存儲(chǔ)層的選擇非常關(guān)鍵，如何保障對(duì)業(yè)務(wù)處理層的高并發(fā)的數(shù)據(jù)支持是核心問(wèn)題。目前數(shù)據(jù)存儲(chǔ)層主要有關(guān)系型數(shù)據(jù)庫(kù)和 NOSQL 數(shù)據(jù)庫(kù)。下面將對(duì)兩種數(shù)據(jù)庫(kù)技術(shù)的優(yōu)缺點(diǎn)以及使用注意事項(xiàng)等進(jìn)行分析并給出實(shí)踐經(jīng)驗(yàn)。

2.2.1關(guān)系型數(shù)據(jù)庫(kù)

關(guān)系型數(shù)據(jù)庫(kù)已經(jīng)在信息系統(tǒng)開(kāi)發(fā)領(lǐng)域被使用多年，它基于標(biāo)準(zhǔn)SQL語(yǔ)句實(shí)現(xiàn)了靈活的數(shù)據(jù)增、刪、查、改、統(tǒng)計(jì)等操作，并提供了良好的事務(wù)處理機(jī)制[4]。用的比較多的關(guān)系型數(shù)據(jù)庫(kù)有Oracle、SQL Server、MySQL等。在數(shù)據(jù)量比較大的時(shí)候，雖然數(shù)據(jù)庫(kù)提供了分區(qū)、索引等技術(shù)提高查詢(xún)效率，但性能上還是很難滿足互聯(lián)網(wǎng)業(yè)務(wù)系統(tǒng)的高并發(fā)要求。

在關(guān)系型數(shù)據(jù)庫(kù)支撐高并發(fā)方面，需要充分使用好分區(qū)、索引、集群等技術(shù)。阿里巴巴公司對(duì)MySQL的使用非常成功，他們充分利用MySQL的集群技術(shù)形成了大型關(guān)系數(shù)據(jù)庫(kù)集群，并開(kāi)發(fā)了數(shù)據(jù)庫(kù)和應(yīng)用層之間的中間層，為應(yīng)用層屏蔽了數(shù)據(jù)庫(kù)層的復(fù)雜性。相對(duì)來(lái)說(shuō)，關(guān)系型數(shù)據(jù)庫(kù)的性能優(yōu)化對(duì)技術(shù)的要求比較高，要做到大型關(guān)系型數(shù)據(jù)庫(kù)集群是比較難的。在移動(dòng)健康業(yè)務(wù)系統(tǒng)建設(shè)初期，用戶量還不多，并發(fā)要求還不太高，為了快速開(kāi)發(fā)上線系統(tǒng)，這時(shí)候可以?xún)?yōu)先采用關(guān)系型數(shù)據(jù)庫(kù)。另外需要處理對(duì)于事務(wù)性要求比較高的業(yè)務(wù)時(shí)需要采用關(guān)系型數(shù)據(jù)庫(kù)。

2.2.2非關(guān)系型數(shù)據(jù)庫(kù)

隨著互聯(lián)網(wǎng)Web2.0網(wǎng)站的興起，非關(guān)系型的數(shù)據(jù)庫(kù)現(xiàn)在成了一個(gè)極其熱門(mén)的新領(lǐng)域，非關(guān)系數(shù)據(jù)庫(kù)產(chǎn)品的發(fā)展非常迅速，而傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)在應(yīng)付Web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的Web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問(wèn)題。作為移動(dòng)健康業(yè)務(wù)系統(tǒng)也是如此。

(1)對(duì)數(shù)據(jù)庫(kù)高并發(fā)讀寫(xiě)的需求

因需要根據(jù)用戶個(gè)性化信息來(lái)實(shí)時(shí)生成動(dòng)態(tài)頁(yè)面和提供動(dòng)態(tài)信息，所以基本上無(wú)法使用動(dòng)態(tài)頁(yè)面靜態(tài)化技術(shù)，因此數(shù)據(jù)庫(kù)并發(fā)負(fù)載非常高，往往要達(dá)到每秒上萬(wàn)次讀寫(xiě)請(qǐng)求。關(guān)系型數(shù)據(jù)庫(kù)應(yīng)付上萬(wàn)次SQL查詢(xún)還勉強(qiáng)頂?shù)米?，但是?yīng)付上萬(wàn)次SQL寫(xiě)數(shù)據(jù)請(qǐng)求，硬盤(pán) IO 就已經(jīng)無(wú)法承受了。

(2)對(duì)海量數(shù)據(jù)的高效率存儲(chǔ)和訪問(wèn)的需求

對(duì)于大型網(wǎng)站，每天用戶產(chǎn)生海量的用戶動(dòng)態(tài)信息，以國(guó)外的Friend Feed為例，一個(gè)月就達(dá)到了2.5億條用戶動(dòng)態(tài)數(shù)據(jù)，對(duì)于關(guān)系數(shù)據(jù)庫(kù)來(lái)說(shuō)，在一張具有2.5 億條記錄的表里面進(jìn)行SQL查詢(xún)，效率是極其低下乃至不可忍受的。再例如大型Web網(wǎng)站的用戶登錄系統(tǒng)，例如騰訊、盛大，動(dòng)輒數(shù)以?xún)|計(jì)的賬號(hào)，關(guān)系數(shù)據(jù)庫(kù)也很難應(yīng)付。

(3)對(duì)數(shù)據(jù)庫(kù)的高可擴(kuò)展性和高可用性的需求

在基于Web的架構(gòu)當(dāng)中，數(shù)據(jù)庫(kù)是最難進(jìn)行橫向擴(kuò)展的，當(dāng)一個(gè)應(yīng)用系統(tǒng)的用戶量和訪問(wèn)量與日俱增的時(shí)候，數(shù)據(jù)庫(kù)卻沒(méi)有辦法像Web server和app server那樣簡(jiǎn)單地通過(guò)添加更多的硬件和服務(wù)節(jié)點(diǎn)來(lái)擴(kuò)展性能和負(fù)載能力。對(duì)于很多需要提供 24 小時(shí)不間斷服務(wù)的網(wǎng)站，它們對(duì)數(shù)據(jù)庫(kù)系統(tǒng)進(jìn)行升級(jí)和擴(kuò)展是非常痛苦的事情，往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移，使得公司業(yè)務(wù)中斷，造成經(jīng)濟(jì)損失。

以上提到的“三高”需求是關(guān)系數(shù)據(jù)庫(kù)難以克服的障礙，對(duì)于移動(dòng)健康業(yè)務(wù)系統(tǒng)，關(guān)系數(shù)據(jù)庫(kù)很難滿足這些應(yīng)用需求。而NOSQL數(shù)據(jù)庫(kù)是近些年隨著大數(shù)據(jù)技術(shù)的廣泛應(yīng)用發(fā)展起來(lái)的，因其易于擴(kuò)展、大數(shù)據(jù)量高并發(fā)、高可用性等優(yōu)勢(shì)，目前已被知名的互聯(lián)網(wǎng)公司廣泛使用。例如，列存儲(chǔ)數(shù)據(jù)庫(kù)HBase、文檔型數(shù)據(jù)庫(kù)MongoDB、CouchDB，key-value數(shù)據(jù)庫(kù)MemcacheDB、Redis等。

文檔型數(shù)據(jù)庫(kù)MongoDB可以說(shuō)是最像關(guān)系型數(shù)據(jù)庫(kù)的 NOSQL 數(shù)據(jù)庫(kù)，甚至可以從搜索網(wǎng)站上搜索到MongoDB和常用標(biāo)準(zhǔn)SQL的對(duì)應(yīng)關(guān)系。因此本文重點(diǎn)推薦存儲(chǔ)層用MongoDB 數(shù)據(jù)庫(kù)。

MongoDB是一個(gè)介于關(guān)系數(shù)據(jù)庫(kù)和非關(guān)系數(shù)據(jù)庫(kù)之間的產(chǎn)品，是非關(guān)系數(shù)據(jù)庫(kù)當(dāng)中功能最豐富、最像關(guān)系數(shù)據(jù)庫(kù)的。它支持的數(shù)據(jù)結(jié)構(gòu)非常松散，類(lèi)似JSON的BJSON格式，因此可以存儲(chǔ)比較復(fù)雜的數(shù)據(jù)類(lèi)型。MongoDB最大的特點(diǎn)是支持的查詢(xún)語(yǔ)言非常強(qiáng)大，其語(yǔ)法有點(diǎn)類(lèi)似于面向?qū)ο蟮牟樵?xún)語(yǔ)言，幾乎可以實(shí)現(xiàn)類(lèi)似關(guān)系數(shù)據(jù)庫(kù)單表查詢(xún)的所有功能，而且還支持對(duì)數(shù)據(jù)建立索引。它是一個(gè)面向集合的模式自由的文檔型數(shù)據(jù)庫(kù)。MongoDB 主要功能如下：

(1)完整的索引支持：包括文檔內(nèi)嵌對(duì)象及數(shù)組。MongoDB 的查詢(xún)優(yōu)化器會(huì)分析查詢(xún)表達(dá)式，并生成一個(gè)高效的查詢(xún)計(jì)劃。

(2)復(fù)制及自動(dòng)故障轉(zhuǎn)移：MongoDB 數(shù)據(jù)庫(kù)支持服務(wù)器之間的數(shù)據(jù)復(fù)制，支持主-從模式及服務(wù)器之間的相互復(fù)制。復(fù)制的主要目標(biāo)是提供冗余及自動(dòng)故障轉(zhuǎn)移。

(3)高效的傳統(tǒng)存儲(chǔ)方式：支持二進(jìn)制數(shù)據(jù)及大型對(duì)象(如照片或圖片) 。

(4)自動(dòng)分片和副本集技術(shù)支持云級(jí)別的伸縮性：自動(dòng)分片功能支持水平的數(shù)據(jù)庫(kù)集群，可動(dòng)態(tài)添加額外的機(jī)器。

2.3 業(yè)務(wù)處理層

2.3.1數(shù)據(jù)緩存的使用

數(shù)據(jù)緩存技術(shù)是解決 Web 應(yīng)用程序可擴(kuò)展性、數(shù)據(jù)響應(yīng)及時(shí)性以及減輕服務(wù)器負(fù)載、降低網(wǎng)絡(luò)擁塞的主要手段之一。最常用的場(chǎng)景如下：

(1)緩存數(shù)據(jù)庫(kù)的查詢(xún)結(jié)果，減少數(shù)據(jù)的壓力。

(2)緩存磁盤(pán)文件的數(shù)據(jù)。常用的數(shù)據(jù)可以放到內(nèi)存，不用每次都去讀取磁盤(pán)，特別是密集計(jì)算的程序，比如中文分詞的詞庫(kù)。

(3)緩存某個(gè)耗時(shí)的計(jì)算操作，比如數(shù)據(jù)統(tǒng)計(jì)。

目前流行的應(yīng)用層緩存技術(shù)有Squid、Varnish、nginx等，本文重點(diǎn)推薦內(nèi)存數(shù)據(jù)庫(kù) Redis。Redis數(shù)據(jù)庫(kù)中的所有數(shù)據(jù)都存儲(chǔ)在內(nèi)存中。由于內(nèi)存的讀寫(xiě)速度遠(yuǎn)快于硬盤(pán)，因此 Redis在性能上對(duì)比其他基于硬盤(pán)存儲(chǔ)的數(shù)據(jù)庫(kù)有非常明顯的優(yōu)勢(shì)，在一臺(tái)普通的筆記本電腦上，Redis可以在一秒內(nèi)讀寫(xiě)超過(guò)十萬(wàn)個(gè)鍵值。不過(guò)，將數(shù)據(jù)存儲(chǔ)在內(nèi)存中也有問(wèn)題，例如，程序退出后內(nèi)存中的數(shù)據(jù)會(huì)丟失。為解決這個(gè)問(wèn)題，Redis將可以?xún)?nèi)存中的數(shù)據(jù)異步寫(xiě)入到硬盤(pán)中，同時(shí)不影響繼續(xù)提供服務(wù)。

Redis可以為每個(gè)鍵設(shè)置生存時(shí)間，生存時(shí)間到期后鍵會(huì)自動(dòng)被刪除。這一功能配合出色的性能讓Redis可以作為緩存系統(tǒng)來(lái)使用，而且由于Redis支持持久化和豐富的數(shù)據(jù)類(lèi)型，使其成為了另一個(gè)非常流行的緩存系統(tǒng)Memcached的有力競(jìng)爭(zhēng)者。

作為緩存系統(tǒng)，Redis 還可以限定數(shù)據(jù)占用的最大內(nèi)存空間，在數(shù)據(jù)達(dá)到空間限制后可以按照一定的規(guī)則自動(dòng)淘汰不需要的鍵。

此外，Redis的列表類(lèi)型鍵可以用來(lái)實(shí)現(xiàn)隊(duì)列，并且支持阻塞式讀取，可以很容易地實(shí)現(xiàn)一個(gè)高性能的優(yōu)先級(jí)隊(duì)列。同時(shí)在更高層面上，Redis 還支持“發(fā)布/訂閱”的消息模式。

Redis 提供了幾十種不同編程語(yǔ)言的客戶端庫(kù)，這些庫(kù)都很好地封裝了Redis的命令，使得在程序中與Redis進(jìn)行交互變得更容易。有些庫(kù)還提供了可以將編程語(yǔ)言中的數(shù)據(jù)類(lèi)型直接以相應(yīng)的形式存儲(chǔ)到Redis中(如將數(shù)組直接以列表類(lèi)型存入 Redis)的簡(jiǎn)單方法，使用起來(lái)非常方便。

Redis支持五種的數(shù)據(jù)類(lèi)型，針對(duì)移動(dòng)健康業(yè)務(wù)系統(tǒng)來(lái)分析這五種類(lèi)型的應(yīng)用場(chǎng)景如下：

(1)字符串類(lèi)型：每一行對(duì)應(yīng)一個(gè)key，value值存可以統(tǒng)一存取的序列號(hào)的對(duì)象值(鏈表或散列存更方便)，如文章閱讀量等數(shù)據(jù)。

(2)散列類(lèi)型：每行對(duì)應(yīng)一個(gè)key，value值類(lèi)似一個(gè)map，適合緩存多種數(shù)據(jù)列的實(shí)體數(shù)據(jù)。

(3)鏈表類(lèi)型：適合緩存實(shí)現(xiàn)鏈表和堆棧效果的數(shù)據(jù)，比如實(shí)現(xiàn)分頁(yè)、限制某個(gè)IP的訪問(wèn)頻率等功能比較方便。

(4)集合類(lèi)型：適合緩存無(wú)順序要求，并需要執(zhí)行并、交、差等集合操作的數(shù)據(jù)，如頁(yè)面的標(biāo)簽類(lèi)型等信息。

(5)有序集合類(lèi)型：適合緩存有順序要求，而且需要執(zhí)行集合操作的數(shù)據(jù)。

2.3.2并行計(jì)算技術(shù)的使用

在移動(dòng)健康業(yè)務(wù)系統(tǒng)中難免有需要處理耗時(shí)較長(zhǎng)的各類(lèi)統(tǒng)計(jì)分析操作，為提高此類(lèi)功能的運(yùn)行效率，可以采用并行計(jì)算技術(shù)，如MapReduce。

MapReduce是一種編程模型，用于大規(guī)模數(shù)據(jù)集(大于1 TB)的并行運(yùn)算。概念“Map(映射)”和“Reduce(歸約)”是它的主要思想。它極大地方便了編程人員在不會(huì)分布式并行編程的情況下，將自己的程序運(yùn)行在分布式系統(tǒng)上[5]。當(dāng)前的軟件實(shí)現(xiàn)是指定一個(gè)Map(映射)函數(shù)，用來(lái)把一組鍵值對(duì)映射成一組新的鍵值對(duì)，指定并發(fā)的Reduce(歸約)函數(shù)，用來(lái)保證所有映射的鍵值對(duì)中的每一個(gè)共享相同的鍵組。

3 結(jié)論

醫(yī)療健康大數(shù)據(jù)和個(gè)人密切相關(guān)，其安全和隱私保護(hù)問(wèn)題從保障技術(shù)和管理制度兩方面都顯得尤為重要。未來(lái)醫(yī)療大數(shù)據(jù)處理可以基于云計(jì)算平臺(tái)實(shí)現(xiàn)，作為云計(jì)算平臺(tái)的一種服務(wù)?；谠朴?jì)算平臺(tái)的開(kāi)發(fā)和應(yīng)用使得很多數(shù)據(jù)被存儲(chǔ)在云端進(jìn)行處理、查詢(xún)和搜索[6]。因此，除了要解決醫(yī)療大數(shù)據(jù)搜索的可擴(kuò)展性、可靠性和效率外,必須考慮數(shù)據(jù)搜索和使用的安全和隱私問(wèn)題。

參考文獻(xiàn)

[1] 劉智慧,張泉靈.大數(shù)據(jù)技術(shù)研究綜述[J].浙江大學(xué)學(xué)報(bào)(工學(xué)版),2014,48(6):957-972.

[2] 王藝,任淑霞.醫(yī)療大數(shù)據(jù)可視化研究綜述[J].計(jì)算機(jī)科學(xué)與探索,2017,11(5):681-699.

[3] 馬燦.國(guó)內(nèi)外醫(yī)療大數(shù)據(jù)資源共享比較研究[J].情報(bào)資料工作,2016,37(3):63-67.

[4] 宋波,楊艷利,馮云霞.醫(yī)療大數(shù)據(jù)研究進(jìn)展[J].轉(zhuǎn)化醫(yī)學(xué)雜志,2016,5(5):298-300.

[5] 魏建兵.基于云計(jì)算的醫(yī)療大數(shù)據(jù)系統(tǒng)架構(gòu)研究[J].電腦知識(shí)與技術(shù),2016,12(7):21-23.

[6] 孫艷秋,王甜宇,曹文聰. 基于云計(jì)算的醫(yī)療大數(shù)據(jù)的挖掘研究[J].計(jì)算機(jī)光盤(pán)軟件與應(yīng)用,2015 (2):11-11.