基于MySQL性能調(diào)優(yōu)的推薦系統(tǒng)優(yōu)化設(shè)計(jì)

焦 宇，李 民，王 歡，余開朝

（昆明理工大學(xué)機(jī)電工程學(xué)院，云南昆明 650500）

0 引言

隨著大數(shù)據(jù)時(shí)代的到來(lái)，人們每天都會(huì)瀏覽成百上千的數(shù)據(jù)信息，而一些常用的例如淘寶、美團(tuán)、大眾點(diǎn)評(píng)等具備推薦功能的軟件，其中的數(shù)據(jù)量更是每天都以驚人的速度增長(zhǎng)［1］。一個(gè)推薦系統(tǒng)中的數(shù)據(jù)主要存儲(chǔ)在MySQL、Redis、Oracle、SqlServer 等一系列數(shù)據(jù)庫(kù)中，大數(shù)據(jù)的出現(xiàn)使推薦系統(tǒng)得到了迅速發(fā)展，也使人們?cè)谶M(jìn)行網(wǎng)購(gòu)、出行等活動(dòng)時(shí)可通過(guò)推薦系統(tǒng)更好地進(jìn)行選擇［2］。然而，推薦系統(tǒng)中數(shù)據(jù)量增加的同時(shí)也面臨著一系列問(wèn)題，例如數(shù)據(jù)量過(guò)大、數(shù)據(jù)庫(kù)性能不足導(dǎo)致用戶提取數(shù)據(jù)信息效率低下等，從而影響用戶體驗(yàn)［3-5］。在大量人群同時(shí)訪問(wèn)數(shù)據(jù)庫(kù)獲取數(shù)據(jù)時(shí)，MySQL 數(shù)據(jù)庫(kù)的承受壓力有限，甚至?xí)霈F(xiàn)宕機(jī)狀態(tài)。因此，對(duì)推薦系統(tǒng)中的數(shù)據(jù)庫(kù)性能進(jìn)行調(diào)優(yōu)，使其具有更好的性能對(duì)于人們的現(xiàn)實(shí)生活具有重要意義。

1 相關(guān)研究

“數(shù)據(jù)庫(kù)”概念最早在20 世紀(jì)60 年代被提出，目前已經(jīng)歷了半個(gè)多世紀(jì)的發(fā)展，從早期的數(shù)據(jù)庫(kù)到流行至今的關(guān)系型數(shù)據(jù)庫(kù)，發(fā)展異常迅猛［6］。在信息技術(shù)日益成熟的今天，程序員開發(fā)了各式各樣的系統(tǒng)，然而幾乎每一個(gè)系統(tǒng)都離不開數(shù)據(jù)庫(kù)。在大數(shù)據(jù)背景下的信息時(shí)代，人們接觸的信息量與日俱增。為了獲取更加個(gè)性化的信息，推薦系統(tǒng)應(yīng)運(yùn)而生。在推薦系統(tǒng)中，數(shù)據(jù)庫(kù)扮演著重要角色，系統(tǒng)中的各類數(shù)據(jù)信息都存放在數(shù)據(jù)庫(kù)中。因此，如何提升數(shù)據(jù)庫(kù)性能一直是熱門研究話題。

在國(guó)內(nèi)外學(xué)者的研究中，宋永鵬［7］針對(duì)數(shù)據(jù)庫(kù)查詢性能，以天氣圖片資料為環(huán)境背景，對(duì)表中的sql 查詢語(yǔ)句進(jìn)行優(yōu)化，同時(shí)通過(guò)“id”限定查詢，提高了數(shù)據(jù)庫(kù)響應(yīng)速度；王宏偉［8］通過(guò)對(duì)MySQL 數(shù)據(jù)庫(kù)分區(qū)技術(shù)進(jìn)行研究，提高了數(shù)據(jù)庫(kù)的穩(wěn)定性，保障了短信平臺(tái)的穩(wěn)定運(yùn)行；陳素芳［9］從SQL Server 數(shù)據(jù)庫(kù)的基本特點(diǎn)與功能入手，淺析了數(shù)據(jù)庫(kù)性能的優(yōu)化方法；石怡［10］通過(guò)分析SQL 查詢語(yǔ)句實(shí)現(xiàn)過(guò)程，得出影響查詢執(zhí)行效率的客觀因素，并且提出了幾種可行的性能優(yōu)化方法，保證了SQL 語(yǔ)句執(zhí)行的正確性與執(zhí)行效率；Aponso 等［11］通過(guò)遺傳算法策略執(zhí)行查詢語(yǔ)句，縮短了查詢響應(yīng)時(shí)間，提高了準(zhǔn)確性；王寧［12］提出一些改進(jìn)的數(shù)據(jù)庫(kù)查詢優(yōu)化算法，提升了分布式數(shù)據(jù)庫(kù)系統(tǒng)的查詢效率；黃建軍等［13］研究了Oracle 數(shù)據(jù)庫(kù)，首先討論SQL 語(yǔ)言優(yōu)化的必要性，其次對(duì)設(shè)計(jì)原則進(jìn)行分析，最后提出幾種SQL 優(yōu)化策略；Gerardo［14］對(duì)數(shù)據(jù)庫(kù)執(zhí)行的等待時(shí)間進(jìn)行分析，并對(duì)其進(jìn)行改進(jìn)，減少了數(shù)據(jù)查詢時(shí)間；聶小雄［15］通過(guò)改進(jìn)遺傳算法，將其運(yùn)用于分布式部署的數(shù)據(jù)庫(kù)架構(gòu)中，提高了系統(tǒng)查詢效率和運(yùn)行效能；字鳳芹等［16］將圖數(shù)據(jù)庫(kù)與電影推薦系統(tǒng)相結(jié)合，通過(guò)KNN 算法有效解決了信息過(guò)載、難以查詢等問(wèn)題。以上研究大多通過(guò)SQL 語(yǔ)句查詢優(yōu)化或算法優(yōu)化的方式提高數(shù)據(jù)庫(kù)性能，但針對(duì)大量用戶訪問(wèn)時(shí)的數(shù)據(jù)庫(kù)壓力問(wèn)題以及高并發(fā)情況下的數(shù)據(jù)庫(kù)響應(yīng)性能問(wèn)題，學(xué)者們并沒(méi)有作出較為有效的改善。

針對(duì)以上不足，本文對(duì)MySQL 數(shù)據(jù)庫(kù)源碼進(jìn)行深入研究，在了解其執(zhí)行原理的基礎(chǔ)上，對(duì)其源碼進(jìn)行修改與優(yōu)化，并將數(shù)據(jù)庫(kù)從單機(jī)部署方式改成分布式（一主一從）部署方式部署到虛擬機(jī)中，最后結(jié)合本地部署的推薦系統(tǒng)以及其中的數(shù)據(jù)集，運(yùn)用壓測(cè)工具進(jìn)行實(shí)驗(yàn)對(duì)比。實(shí)驗(yàn)結(jié)果表明，優(yōu)化后的數(shù)據(jù)庫(kù)提高了數(shù)據(jù)響應(yīng)能力，抗并發(fā)能力也得到了一定程度提升。

2 關(guān)鍵技術(shù)分析

2.1 MySQL數(shù)據(jù)庫(kù)

數(shù)據(jù)庫(kù)是用來(lái)管理組織數(shù)據(jù)的倉(cāng)庫(kù)，隨著現(xiàn)代網(wǎng)絡(luò)和信息技術(shù)的發(fā)展，數(shù)據(jù)庫(kù)已轉(zhuǎn)變成用戶所迫切需要的數(shù)據(jù)管理工具。其中，MySQL 數(shù)據(jù)庫(kù)是一款高安全性、高效率且可跨平臺(tái)的數(shù)據(jù)庫(kù)系統(tǒng)，同時(shí)可與PHP、Java 等主流編程語(yǔ)言結(jié)合使用，具有很強(qiáng)的兼容性［17］。本文推薦系統(tǒng)的數(shù)據(jù)存儲(chǔ)在MySQL 數(shù)據(jù)庫(kù)中，由于其具有安全性高及存儲(chǔ)容量大的特點(diǎn)，因此成為支撐推薦系統(tǒng)數(shù)據(jù)的不二選擇。本文推薦系統(tǒng)的數(shù)據(jù)庫(kù)設(shè)計(jì)表包括category（類目）、recommend（推薦）、user（用戶）、seller（賣家）與shop（門店）。推薦系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)如圖1所示。

Fig.1 Recommended system database design圖1 推薦系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)

2.2 數(shù)據(jù)庫(kù)主從部署模式

數(shù)據(jù)庫(kù)主從部署模式通常是將“寫”和“讀”操作分別對(duì)應(yīng)到主數(shù)據(jù)庫(kù)和從數(shù)據(jù)庫(kù)中，主服務(wù)器負(fù)責(zé)“寫”操作，從服務(wù)器負(fù)責(zé)“讀”操作，并使主服務(wù)器數(shù)據(jù)與從服務(wù)器數(shù)據(jù)實(shí)現(xiàn)同步更新［18］。主從模式通常分為一主一從、一主多從以及多主多從等設(shè)計(jì)模式，隨著其搭建的復(fù)雜程度逐漸增大，相應(yīng)的穩(wěn)定性也逐漸提高。主從模式的出現(xiàn)可更好地分擔(dān)數(shù)據(jù)庫(kù)壓力，將“讀”“寫”操作分開的設(shè)計(jì)方式有效提高了數(shù)據(jù)庫(kù)性能。對(duì)于一個(gè)數(shù)據(jù)量龐大的推薦系統(tǒng)來(lái)說(shuō)，該部署模式使整個(gè)系統(tǒng)性能得到有效改善。

3 數(shù)據(jù)庫(kù)性能調(diào)優(yōu)以及主從部署

3.1 數(shù)據(jù)庫(kù)執(zhí)行原理解析

對(duì)數(shù)據(jù)庫(kù)執(zhí)行原理進(jìn)行分析：以一個(gè)client 服務(wù)器和一個(gè)MySQL 客戶端為例，通過(guò)tcp connect 進(jìn)行連接。產(chǎn)生一個(gè)socket 進(jìn)行連接，有socket 之后才可以進(jìn)行例如select/insert 等操作。若要寫一個(gè)事務(wù)，需要先發(fā)一個(gè)start transaction 命令來(lái)開啟事務(wù)，對(duì)應(yīng)的sql 語(yǔ)句最終會(huì)反映到執(zhí)行引擎中。MySQL 可以保證事務(wù)ACID 的特性，不至于在事務(wù)提交之后因?yàn)閿嚯姸鴣G失。原因在于MySQL 的InnoDB具有WAL 機(jī)制，執(zhí)行引擎進(jìn)行所有操作之前，先不操作數(shù)據(jù)，而是先記錄日志（undo/redo）。redo 相當(dāng)于重做日志，例如用戶寫了一條insert 語(yǔ)句，對(duì)應(yīng)的redo 寫了一條insert，若過(guò)程掉電，則可以重新做；undo 為事務(wù)回滾的反操作，可將用戶上一步操作對(duì)程序造成的改動(dòng)恢復(fù)到改動(dòng)之前。寫完日志后再操作數(shù)據(jù)，執(zhí)行change data 操作。一旦對(duì)應(yīng)數(shù)據(jù)被改變，寫完日志后，作對(duì)應(yīng)事務(wù)的commit 操作，將事務(wù)真正提交上去。單機(jī)數(shù)據(jù)庫(kù)執(zhí)行原理如圖2所示。

Fig.2 Schematic of stand-alone database execution圖2 單機(jī)數(shù)據(jù)庫(kù)執(zhí)行原理

3.2 數(shù)據(jù)庫(kù)配置參數(shù)優(yōu)化

接下來(lái)需要對(duì)數(shù)據(jù)庫(kù)配置文件中的一些源碼進(jìn)行修改優(yōu)化，并進(jìn)行解析，具體解析與修改內(nèi)容如下：

（1）max_connection=1 000。此行代碼是指socket 端連接客戶端的最大數(shù)量，MySQL 默認(rèn)設(shè)置為200，這顯然對(duì)于一個(gè)推薦系統(tǒng)而言是遠(yuǎn)遠(yuǎn)不夠的。因此，將其設(shè)置為1 000，該數(shù)值對(duì)于后面的壓測(cè)實(shí)驗(yàn)以及聯(lián)系本地部署的推薦系統(tǒng)而言都是十分可行的數(shù)值。

（2）innodb_file_per_table=1。盡管部署的推薦系統(tǒng)中只有5 張表，但若今后數(shù)據(jù)庫(kù)中表數(shù)量以及數(shù)據(jù)量增加，所有數(shù)據(jù)都存儲(chǔ)在datafile 中，此時(shí)數(shù)據(jù)庫(kù)尋址會(huì)變得異常困難。這行代碼是指使用Innodb，保證其對(duì)應(yīng)database 里每一個(gè)table作為一張表，可大大減少尋址難度。

（3）innodb_buffer_pool_size=1G（結(jié)合服務(wù)器實(shí)際情況修改）。Databuffer 的作用在于當(dāng)寫入數(shù)據(jù)時(shí)，先寫入對(duì)應(yīng)的buffer 區(qū)。若該區(qū)域的內(nèi)存足夠大，則命中緩存的概率將足夠高。進(jìn)行“讀”操作時(shí)，若對(duì)應(yīng)主鍵在該區(qū)域中，則可直接讀取。

（4）innodb_log_file_size=256M；innodb_log_buffer_size=16M（結(jié)合服務(wù)器實(shí)際情況修改）。前者是日志內(nèi)容大小，后者是日志buffer大小。當(dāng)事務(wù)不斷向undo/redo 中進(jìn)行寫入操作時(shí)，文件內(nèi)存會(huì)不斷變大。當(dāng)其內(nèi)存超過(guò)256M 時(shí)，此時(shí)文件有一個(gè)重命名動(dòng)作，會(huì)把該文件變成一個(gè)歷史文件，同時(shí)再開一個(gè)日志文件。在此間隙內(nèi)，對(duì)應(yīng)的log 無(wú)法進(jìn)行flush 操作。同樣，對(duì)應(yīng)的write-log-ahead 操作也無(wú)法執(zhí)行，相當(dāng)于client 端的sql 語(yǔ)句無(wú)法實(shí)現(xiàn)，這對(duì)于用戶而言十分不友好，此時(shí)buffer 區(qū)域即發(fā)揮了作用。本文將其修改為大小為16M 的緩沖內(nèi)存，即便在日志發(fā)生切換時(shí)仍可接受16M 的緩沖作對(duì)應(yīng)操作，再向?qū)?yīng)的新文件作flush操作，有效避免了暫時(shí)性的數(shù)據(jù)庫(kù)宕機(jī)而產(chǎn)生的不良影響。

（5）innodb_flush_log_at_trx_commit=2。需要放在［My-SQLd_safe］節(jié)點(diǎn)下進(jìn)行配置，默認(rèn)配置為“1”，現(xiàn)將其數(shù)值改為“2”。修改原因如下：數(shù)值為“1”意味著每次事務(wù)一旦提交，對(duì)應(yīng)地會(huì)將logfile 的buffer 區(qū)刷到磁盤中，只要事務(wù)提交就立馬刷盤，但這樣可能會(huì)發(fā)生意外。例如客戶端發(fā)起commit 操作，也進(jìn)行了刷盤操作，但成功之后response給客戶端時(shí)網(wǎng)絡(luò)斷線，這樣一來(lái)客戶會(huì)認(rèn)為事務(wù)是失敗的，然而實(shí)際上已經(jīng)成功執(zhí)行。當(dāng)數(shù)值為“0”時(shí)，writeahead-log 操作全部寫到buffer 中，MySQL 借助于一個(gè)輪詢的時(shí)間，每隔1s 將buffer 中的內(nèi)容flush 到日志中，使對(duì)應(yīng)client 端的性能得到提高。但是如果遇到操作后下一秒MySQL 出現(xiàn)宕機(jī)的情況，其對(duì)應(yīng)的業(yè)務(wù)丟失就是那1s的數(shù)據(jù)丟失，性能安全性無(wú)法得到保證。將數(shù)值改為“2”后，flush 將會(huì)變?yōu)閣rite 和flush 兩步操作。write 相當(dāng)于將對(duì)應(yīng)文件數(shù)據(jù)寫到操作系統(tǒng)對(duì)這個(gè)文件系統(tǒng)的緩沖池內(nèi)，是硬件級(jí)別的緩沖，此時(shí)對(duì)應(yīng)的write 級(jí)別操作雖然數(shù)據(jù)沒(méi)有進(jìn)入磁盤，但已被操作系統(tǒng)的內(nèi)核進(jìn)行管理。“2”代表client端發(fā)起commit 后寫到buffer 上，再去調(diào)用write 方法，而不調(diào)用flush 方法。對(duì)應(yīng)數(shù)值完全在操作系統(tǒng)的緩存池中后，MySQL 數(shù)據(jù)庫(kù)每隔1s 再調(diào)用flush 操作。對(duì)于Linux 操作系統(tǒng)而言，只要操作系統(tǒng)不宕機(jī)，對(duì)應(yīng)內(nèi)核級(jí)別的buffer 遲早會(huì)在關(guān)機(jī)前被flush 到。在這1s 時(shí)間內(nèi)，就算MySQL 數(shù)據(jù)庫(kù)宕機(jī)，只要系統(tǒng)仍在運(yùn)行中，對(duì)應(yīng)數(shù)據(jù)也不會(huì)丟失。相比于前兩種情況，這一種狀態(tài)更加安全。

之前針對(duì)log 及buffer 級(jí)別作出優(yōu)化后，現(xiàn)在針對(duì)datafile 級(jí)別仍可作出優(yōu)化，修改代碼為：innodb_data_file_path=ibdata1：1G；ibdata2：1G；ibdata3：1G：auto extend。以推薦系統(tǒng)中的user 表為例，該配置代表user 表的數(shù)據(jù)量很大，但當(dāng)其達(dá)到1G 內(nèi)存時(shí)，會(huì)將對(duì)應(yīng)數(shù)據(jù)存放在重新創(chuàng)建的一個(gè)名為ibdata1 的文件中。同理，當(dāng)ibdata1 文件大小達(dá)到1G 時(shí)，會(huì)以同樣的方式繼續(xù)創(chuàng)建MySQL 的文件分區(qū)，有效對(duì)datafile 級(jí)別進(jìn)行了優(yōu)化。

3.3 數(shù)據(jù)庫(kù)主從模式搭建

優(yōu)化完單機(jī)狀態(tài)下MySQL 的性能后，為了支撐線上業(yè)務(wù)需求，仍需要對(duì)數(shù)據(jù)庫(kù)作進(jìn)一步優(yōu)化。接下來(lái)進(jìn)行數(shù)據(jù)庫(kù)分布式部署，即主從模式搭建。主從模式搭建可實(shí)現(xiàn)讀寫分離。在數(shù)據(jù)庫(kù)中開啟bin_log，設(shè)置主從同步賬號(hào)，配置主從同步。Binarylog 是一個(gè)二進(jìn)制log 文件，事務(wù)提交后，所有寫操作都會(huì)被執(zhí)行引擎引入bin_log 中，之后bin_log 記錄這臺(tái)機(jī)器的所有MySQL 數(shù)據(jù)，此時(shí)變成主數(shù)據(jù)庫(kù)（masterMySQL）。對(duì)應(yīng)有一個(gè)從數(shù)據(jù)庫(kù)（slaveMySQL），在主數(shù)據(jù)庫(kù)上開一個(gè)賬號(hào)，賦予密碼，此時(shí)對(duì)應(yīng)的slave-MySQL 通過(guò)唯一權(quán)限連接到bin_log 中，從主數(shù)據(jù)庫(kù)的bin_log 中讀取所有數(shù)據(jù)change，并且進(jìn)行從數(shù)據(jù)庫(kù)變更。由于只在主數(shù)據(jù)庫(kù)中執(zhí)行“寫”操作，在從數(shù)據(jù)庫(kù)中執(zhí)行“讀”操作，使負(fù)載被均衡分配，可極大地緩解數(shù)據(jù)庫(kù)壓力。本文設(shè)計(jì)一主一從的部署模式，該模式下的執(zhí)行原理圖如3所示。

Fig.3 Schematic of master-slave database execution圖3 主從數(shù)據(jù)庫(kù)執(zhí)行原理

3.4 項(xiàng)目啟動(dòng)策略

本文將數(shù)據(jù)庫(kù)主從模式部署到多臺(tái)虛擬機(jī)Linux 系統(tǒng)中，開啟訪問(wèn)權(quán)限和防火墻，運(yùn)用Xshell 實(shí)現(xiàn)本地Windows與Linux 系統(tǒng)的通信連接，從而可對(duì)項(xiàng)目進(jìn)行運(yùn)行操作。項(xiàng)目設(shè)計(jì)如圖4所示。

Fig.4 Project design圖4 項(xiàng)目設(shè)計(jì)

4 項(xiàng)目運(yùn)行及實(shí)驗(yàn)

4.1 實(shí)驗(yàn)設(shè)置

在本地電腦中開啟2 臺(tái)Vmware 虛擬機(jī)，每臺(tái)虛擬機(jī)設(shè)置4 核4G 的配置，將數(shù)據(jù)庫(kù)安裝至兩臺(tái)服務(wù)器中。服務(wù)器靜態(tài)IP地址分別設(shè)置為192.168.157.150 和192.168.157.151，開啟兩臺(tái)服務(wù)器防火墻以便于本地服務(wù)器接入端口，將192.168.157.150 服務(wù)器中的MySQL 設(shè)置為主數(shù)據(jù)庫(kù)。首先打開MySQL 文件夾中的配置文件進(jìn)行參數(shù)優(yōu)化配置，具體配置內(nèi)容如上文所述；然后在數(shù)據(jù)庫(kù)中開啟bin_log，設(shè)置主從同步賬號(hào)，并且配置兩個(gè)數(shù)據(jù)庫(kù)的主從節(jié)點(diǎn)等信息；設(shè)置完成后啟動(dòng)兩臺(tái)數(shù)據(jù)庫(kù)，同時(shí)將本地啟動(dòng)的推薦系統(tǒng)連接到數(shù)據(jù)庫(kù)服務(wù)器所開啟的端口上。通過(guò)測(cè)試，項(xiàng)目可正常運(yùn)行，部署調(diào)試完成后，通過(guò)測(cè)試工具進(jìn)行壓力測(cè)試。

本次測(cè)試主要驗(yàn)證經(jīng)過(guò)數(shù)據(jù)庫(kù)優(yōu)化后推薦系統(tǒng)的數(shù)據(jù)響應(yīng)能力及抗并發(fā)能力，采用Jmeter 工具進(jìn)行測(cè)試。實(shí)驗(yàn)測(cè)試環(huán)境為：i7-10875H/16G 內(nèi)存、Windows10 系統(tǒng)、Centos7.4、JDK1.8、Tomcat8.5、MySQL5.7。

4.2 壓測(cè)實(shí)驗(yàn)結(jié)果

Jmeter 是基于Java 的壓力測(cè)試工具，可對(duì)服務(wù)器進(jìn)行壓力和性能測(cè)試，也可通過(guò)JDBC 對(duì)數(shù)據(jù)庫(kù)進(jìn)行測(cè)試［19-20］。在工具中設(shè)置訪問(wèn)請(qǐng)求http，訪問(wèn)路徑為：localhost：8010/static/index.html。該路徑直接提取數(shù)據(jù)庫(kù)shop 表中的內(nèi)容，并將數(shù)據(jù)返回給前端頁(yè)面，展示給用戶。其中，shop 表中共有1 500 個(gè)商家店面信息。分別設(shè)置測(cè)試用戶為500、600、700 并發(fā)量，啟動(dòng)線程時(shí)間為10s，循環(huán)次數(shù)為10 次進(jìn)行壓力測(cè)試，通過(guò)觀察數(shù)據(jù)響應(yīng)時(shí)間平均值、中位數(shù)、90%線位、錯(cuò)誤率及吞吐量對(duì)比優(yōu)化前后的數(shù)據(jù)庫(kù)性能。圖5-圖7分別是500、600、700并發(fā)量下的測(cè)試結(jié)果。

Fig.5 500 concurrency comparison results圖5 500并發(fā)量對(duì)比結(jié)果

Fig.6 600 concurrency comparison results圖6 600并發(fā)量對(duì)比結(jié)果

Fig.7 700 concurrency comparison results圖7 700并發(fā)量對(duì)比結(jié)果

實(shí)驗(yàn)結(jié)果表明，與未對(duì)數(shù)據(jù)庫(kù)進(jìn)行性能優(yōu)化的系統(tǒng)相比，優(yōu)化后的系統(tǒng)在響應(yīng)時(shí)間方面有了明顯改善，且數(shù)據(jù)庫(kù)承受的并發(fā)能力有一定提高。在并發(fā)量為500 的情況下，吞吐量增加了123/sec、平均響應(yīng)時(shí)間減少了44ms；在并發(fā)量為600 的情況下，吞吐量增加了194/sec、平均響應(yīng)時(shí)間減少了63ms；在并發(fā)量為700 的情況下，吞吐量增加了238/sec、平均響應(yīng)時(shí)間減少了109ms。在錯(cuò)誤率方面，當(dāng)并發(fā)量為500、600 時(shí)錯(cuò)誤率都為0；當(dāng)并發(fā)量為700 時(shí)，優(yōu)化后系統(tǒng)的錯(cuò)誤率為0，原因主要在于數(shù)據(jù)庫(kù)主從部署的存在降低了數(shù)據(jù)庫(kù)負(fù)載，而未進(jìn)行優(yōu)化的系統(tǒng)錯(cuò)誤率達(dá)到0.025%。

5 結(jié)語(yǔ)

本文深度解析了數(shù)據(jù)庫(kù)運(yùn)行原理，從源碼層面對(duì)數(shù)據(jù)庫(kù)的部署參數(shù)進(jìn)行優(yōu)化，并結(jié)合本地設(shè)計(jì)的推薦系統(tǒng)及其數(shù)據(jù)庫(kù)中的數(shù)據(jù)，采用虛擬機(jī)Linux 系統(tǒng)進(jìn)行數(shù)據(jù)庫(kù)主從部署，構(gòu)建了一個(gè)數(shù)據(jù)庫(kù)優(yōu)化后的推薦系統(tǒng)。壓力測(cè)試結(jié)果表明，優(yōu)化后的數(shù)據(jù)庫(kù)在不增加錯(cuò)誤率的情況下，數(shù)據(jù)處理效率有一定提高，并且數(shù)據(jù)庫(kù)的抗并發(fā)能力也有一定提升。然而，本文并未采取多從多主的方式部署數(shù)據(jù)庫(kù)，對(duì)于推薦系統(tǒng)中的推薦算法也未進(jìn)行優(yōu)化以提高推薦精度，因此如何進(jìn)一步提升數(shù)據(jù)庫(kù)性能，以及提高推薦系統(tǒng)的推薦精準(zhǔn)度是接下來(lái)需要深入研究的內(nèi)容。