當前位置:首頁 » 數據倉庫 » 資料庫不停擴容會怎麼樣
擴展閱讀
固態硬碟sj 2022-11-27 21:08:44
西部數碼硬碟 2022-11-27 21:08:34
海康初始密碼忘記多少 2022-11-27 21:06:45

資料庫不停擴容會怎麼樣

發布時間: 2022-10-03 13:33:01

1. 資料庫id自動增長,數據不停的刪除和插入,這樣的話id欄位會不斷的變大,直到溢出這個問題是怎麼解決的

這個看情況了,首先看看是不是有使用自增列的必要,如果有必要前期要有預見性,對於可能會出現溢出的情況,則盡量使用bigint類型,當然這個要多佔用存儲空間。如果刪除操作比較規則,比如會定期刪除較早的數據,那麼可以在id即將溢出的時候重置種子,從頭開始自增,如果不能循環使用id值得話只能在即將溢出的時候修改表,用更大的數據類型來作為自增列的類型,這個過程因為涉及大量的數據更新插入操作,速度會很慢,通常盡量避免。如果id快溢出了,最好新建一個表來存儲新增的數據。

2. 企業數據運維場景復雜會帶來什麼風險呢

在安華金和公眾號文章里看到說在數據運維場景中,分兩個方向考慮,一個是數據運維場景復雜,一個是運維人員許可權寬泛。隨著企業發展,機房建設、人員波動、業務系統擴容會變得愈加頻繁,帶來了復雜的運維場景,例如公用資料庫賬號、公用運維主機、公用的操作系統賬號等;與此同時,數據的運維管理工作仍是傳統的「企業運維人員+一大堆第三方廠商人員」模式。面對如此復雜、混亂的運維場景,如果不具備有效的、細粒度的管控能力,那麼諸如數據被誤操作、惡意批量刪除、高許可權用戶的濫用、敏感數據的泄露等數據安全事件的發生,將難以避免,並對企業造成不可估量的經濟損失與聲譽損害。我知道安華金和有專門針對資料庫運維場景的管控產品,你去問問他們~

3. 超詳細Mysql資料庫優化

資料庫優化一方面是找出系統的瓶頸,提高MySQL資料庫的整體性能,而另一方面需要合理的結構設計和參數調整,以提高用戶的相應速度,同時還要盡可能的節約系統資源,以便讓系統提供更大的負荷.

1. 優化一覽圖

2. 優化

筆者將優化分為了兩大類,軟優化和硬優化,軟優化一般是操作資料庫即可,而硬優化則是操作伺服器硬體及參數設置.

2.1 軟優化

2.1.1 查詢語句優化

1.首先我們可以用EXPLAIN或DESCRIBE(簡寫:DESC)命令分析一條查詢語句的執行信息.

2.例:

顯示:

其中會顯示索引和查詢數據讀取數據條數等信息.

2.1.2 優化子查詢

在MySQL中,盡量使用JOIN來代替子查詢.因為子查詢需要嵌套查詢,嵌套查詢時會建立一張臨時表,臨時表的建立和刪除都會有較大的系統開銷,而連接查詢不會創建臨時表,因此效率比嵌套子查詢高.

2.1.3 使用索引

索引是提高資料庫查詢速度最重要的方法之一,關於索引可以參高筆者<MySQL資料庫索引>一文,介紹比較詳細,此處記錄使用索引的三大注意事項:

2.1.4 分解表

對於欄位較多的表,如果某些欄位使用頻率較低,此時應當,將其分離出來從而形成新的表,

2.1.5 中間表

對於將大量連接查詢的表可以創建中間表,從而減少在查詢時造成的連接耗時.

2.1.6 增加冗餘欄位

類似於創建中間表,增加冗餘也是為了減少連接查詢.

2.1.7 分析表,,檢查表,優化表

分析表主要是分析表中關鍵字的分布,檢查表主要是檢查表中是否存在錯誤,優化表主要是消除刪除或更新造成的表空間浪費.

1. 分析表: 使用 ANALYZE 關鍵字,如ANALYZE TABLE user;

2. 檢查表: 使用 CHECK關鍵字,如CHECK TABLE user [option]

option 只對MyISAM有效,共五個參數值:

3. 優化表:使用OPTIMIZE關鍵字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;

LOCAL|NO_WRITE_TO_BINLOG都是表示不寫入日誌.,優化表只對VARCHAR,BLOB和TEXT有效,通過OPTIMIZE TABLE語句可以消除文件碎片,在執行過程中會加上只讀鎖.

2.2 硬優化

2.2.1 硬體三件套

1.配置多核心和頻率高的cpu,多核心可以執行多個線程.

2.配置大內存,提高內存,即可提高緩存區容量,因此能減少磁碟I/O時間,從而提高響應速度.

3.配置高速磁碟或合理分布磁碟:高速磁碟提高I/O,分布磁碟能提高並行操作的能力.

2.2.2 優化資料庫參數

優化資料庫參數可以提高資源利用率,從而提高MySQL伺服器性能.MySQL服務的配置參數都在my.cnf或my.ini,下面列出性能影響較大的幾個參數.

2.2.3 分庫分表

因為資料庫壓力過大,首先一個問題就是高峰期系統性能可能會降低,因為資料庫負載過高對性能會有影響。另外一個,壓力過大把你的資料庫給搞掛了怎麼辦?所以此時你必須得對系統做分庫分表 + 讀寫分離,也就是把一個庫拆分為多個庫,部署在多個資料庫服務上,這時作為主庫承載寫入請求。然後每個主庫都掛載至少一個從庫,由從庫來承載讀請求。

2.2.4 緩存集群

如果用戶量越來越大,此時你可以不停的加機器,比如說系統層面不停加機器,就可以承載更高的並發請求。然後資料庫層面如果寫入並發越來越高,就擴容加資料庫伺服器,通過分庫分表是可以支持擴容機器的,如果資料庫層面的讀並發越來越高,就擴容加更多的從庫。但是這里有一個很大的問題:資料庫其實本身不是用來承載高並發請求的,所以通常來說,資料庫單機每秒承載的並發就在幾千的數量級,而且資料庫使用的機器都是比較高配置,比較昂貴的機器,成本很高。如果你就是簡單的不停的加機器,其實是不對的。所以在高並發架構里通常都有緩存這個環節,緩存系統的設計就是為了承載高並發而生。所以單機承載的並發量都在每秒幾萬,甚至每秒數十萬,對高並發的承載能力比資料庫系統要高出一到兩個數量級。所以你完全可以根據系統的業務特性,對那種寫少讀多的請求,引入緩存集群。具體來說,就是在寫資料庫的時候同時寫一份數據到緩存集群里,然後用緩存集群來承載大部分的讀請求。這樣的話,通過緩存集群,就可以用更少的機器資源承載更高的並發。

一個完整而復雜的高並發系統架構中,一定會包含:各種復雜的自研基礎架構系統。各種精妙的架構設計.因此一篇小文頂多具有拋磚引玉的效果,但是資料庫優化的思想差不多就這些了.

4. 如何進行mysql的動態擴容和縮容

mysql在線擴容和縮容一般涉及到的內容,主要包括三個方面,1.在線也就意味著需要把增量的數據重新分布到新的拓撲結構中,我們一般稱做增量復制,2.原有的數據需要一條不漏的掃出來重新分布到新的拓撲結構中,這個一般叫做全量復制,3.全量做完,增量正在同步,把應用的數據路由拓撲切到新的路由拓撲上來,並且做到無數據丟失,這個我們叫做停寫切換。做好這三個方面的工作,能夠達到的效果就是應用在最後切換數據分布拓撲的時刻,只要停寫非常短的時間(秒級別)就能夠做到無數據丟失的擴容和縮容。

增量同步一般有2種方式,一種是應用端或者資料庫前端做trigger,記錄變更數據的特徵值log(比如pk,sharding key),然後非同步復制到新的拓撲結構中。另外一種方式是通過分析mysql的binlog再進行不同數據拓撲的復制。兩者本質上來說應該是一樣的,後者可能更加簡便,並且對應用無侵入,前者雖然也能夠做到,實際實現或者推廣和操作上都有不少阻力,最起碼解析binlog方式是mysql一上去,更新的log已經天然存在與binlog中了。

增量同步的兩種方式如果要考慮到同步的可伸縮性(也就是多台機器可以同時消費相同的變更日誌),需要在原數據中添加數據的版本信息防止更新亂序,或者通過唯一鍵進行復制機器的sharding,也就是不同進程(線程)同時消費相同的更新日誌,必須讓同一條記錄的更新落在同一個線程裡面,如果還需要保證復制的事務,那麼實現會非常復雜,一般不會去支持多線程下復制的事務。

全量復制,也就是掃描需要復制的表的數據進行重新分布,主要存在的問題是復制速度和對資料庫的寫入壓力的矛盾,其實能夠做到整個拓撲連資料庫都全部換掉,來達到對正在使用資料庫的0影響,這個是一種可行的方案,另外是分時段調整復制線程數,一般單線程復制對於資料庫的影響不會很大,在凌晨再轉換成多線程方式達到提速的目標。

擴容或者縮容在最後階段如何切換,這個涉及到的問題主要是如何避免新更新進來以至於增量沒完沒了,方式有很多,最簡單的方法就是停掉應用,一般時間只有幾分鍾是可以接受的。另外一種是邏輯停寫,因為我們遷移的時候是有一個規則去重新散列數據,也就是如果新的規則和舊的規則兩者算出來的結果不一致,那麼這個數據就是需要被遷移的,如果在停寫的時刻,向前端拋錯即可。邏輯停寫最大的好處就是避免PE的介入,並且配合動態的數據路由數據推送,可以完全避免重新發布達到擴容或者縮容,這個就是真正的在線擴容,停寫不可避免(等待延遲的增量同步完成),但是不影響讀。

數據擴容或者縮容,我們覺得不應該排入業務的開發日程中,而是由數據管理團隊對應用透明地進行這種操作,最後介入的人員只是DBA而已。但是不像一些nosql一樣按容量或者完全透明的split,資料庫的sharding還是按照應用的數據特性(pk,user_id,gmt_create等等不同欄位,自選策略)進行sharding,應用知道他們的某條數據具體存在哪個機器哪張表上,這個無論對於開發還是測試或者DBA都是一件不錯的事情。