色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

YouTube數(shù)據(jù)庫如何保存巨量視頻文件?

jf_ro2CN3Fa ? 來源:芋道源碼 ? 2023-01-08 11:23 ? 次閱讀

YouTube 是僅次于谷歌的第二大熱門網(wǎng)站。在 2019 年 5 月,每分鐘會有超過 500 小時的視頻內(nèi)容上傳到該平臺。

該視頻共享平臺有超過 20 億的用戶,每天有超過10億小時的視頻被播放,產(chǎn)生數(shù)十億的瀏覽量。這些都是令人難以置信的數(shù)字。

本文會對 YouTube 使用的數(shù)據(jù)庫和后端數(shù)據(jù)基礎(chǔ)設(shè)施進(jìn)行深入講解,它們使得該視頻平臺能夠存儲如此巨量的數(shù)據(jù),并能擴展至數(shù)十億的用戶。

那我們就開始吧。

1.引言

YouTube 的旅程開始于 2005 年。隨著這家由風(fēng)險資本資助的技術(shù)初創(chuàng)公司不斷取得成功,它于 2006 年 11 月被谷歌以 16.5 億美元收購。

在被谷歌收購之前,它們的團隊由以下人員組成:

兩名系統(tǒng)管理員

兩名可擴展性軟件架構(gòu)師

兩名特性開發(fā)人員

兩名網(wǎng)絡(luò)工程師

一名 DBA

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序,支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址:https://github.com/YunaiV/ruoyi-vue-pro

視頻教程:https://doc.iocoder.cn/video/

2.后端基礎(chǔ)設(shè)施

YouTube 的后端微服務(wù)是由Python、數(shù)據(jù)庫、硬件Java(使用了Guice框架)和 Go 編寫的。用戶界面是使用JavaScript編寫的。

主要的數(shù)據(jù)庫是由 Vitess 支撐的 MySQL,Vitess是一個數(shù)據(jù)庫集群系統(tǒng),用于 MySQL 的水平擴展。另外,使用 Memcache 實現(xiàn)緩存并使用 Zookeeper 進(jìn)行節(jié)點的協(xié)調(diào)。

64e97e7a-8ef9-11ed-bfe3-dac502259ad0.jpg

流行的視頻通過 CDN 來提供,而一般的、較少播放的視頻則從數(shù)據(jù)庫中獲取。

每個視頻在上傳的時候,都會賦予一個唯一的標(biāo)識符并且會由一個批處理 job 進(jìn)行處理,該 job 會運行多個自動化的過程,比如生成縮略圖、元數(shù)據(jù)、視頻腳本、編碼、設(shè)置貨幣化狀態(tài)等。

VP9 & H.264/MPEG-4 AVC 高級視頻編碼(Advanced Video Coding codecs)會用于視頻壓縮,它能夠使用其他編碼器一半的帶寬來編碼 HD 和 4K 質(zhì)量的視頻。

視頻流則是使用基于HTTP協(xié)議的動態(tài)自適應(yīng)流(Dynamic Adaptive Streaming),這是一種自適應(yīng)比特率的流媒體技術(shù),能夠從傳統(tǒng)的 HTTP Web 服務(wù)器上實現(xiàn)高質(zhì)量的視頻流。通過這種技術(shù),內(nèi)容可以按照不同的比特率提供給觀眾。YouTube 客戶端會根據(jù)觀看者的互聯(lián)網(wǎng)連接速度自動適應(yīng)視頻渲染,從而盡可能減少緩沖時間。

我曾經(jīng)在一篇專門的文章中討論過 YouTube 的視頻轉(zhuǎn)碼過程,參見“YouTube是如何以低延遲提供高質(zhì)量視頻的”。

所以,這里對平臺的后端技術(shù)有一個快速的介紹。YouTube 主要使用的數(shù)據(jù)庫是 MySQL。現(xiàn)在,我們了解一下 YouTube 的工程團隊為什么覺得有必要編寫 Vitess?他們在最初的 MySQL 環(huán)境中面臨的問題是什么,使他們在此基礎(chǔ)上實現(xiàn)了一個額外的框架?

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序,支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址:https://github.com/YunaiV/yudao-cloud

視頻教程:https://doc.iocoder.cn/video/

3.為何需要 Vitess

網(wǎng)站最初只有一個數(shù)據(jù)庫實例。隨著網(wǎng)站的發(fā)展,為了滿足日益增長的 QPS(每秒查詢次數(shù))需求,開發(fā)人員不得不對數(shù)據(jù)庫進(jìn)行水平擴展。

3.1 主-從副本

副本會添加到主數(shù)據(jù)庫實例中。讀取請求會被路由到主數(shù)據(jù)庫和副本上,以減少主數(shù)據(jù)庫的負(fù)載。添加副本有助于緩解瓶頸,增加讀取的吞吐量,并增加系統(tǒng)的持久性。

主節(jié)點處理寫入的流量,主節(jié)點和副本節(jié)點同時處理讀取流量。

65057b5c-8ef9-11ed-bfe3-dac502259ad0.jpg

但是,在這種場景中,有可能會從副本中讀取到陳舊的數(shù)據(jù)。如果在主節(jié)點將信息更新到副本之前,一個請求讀取了副本的數(shù)據(jù),那么觀看者就會得到陳舊的數(shù)據(jù)。

此時,主節(jié)點和副本節(jié)點的數(shù)據(jù)是不一致的。在這種情況下,不一致的數(shù)據(jù)是主節(jié)點和副本節(jié)點上特定視頻的觀看次數(shù)。

其實,這完全沒有問題。觀眾不會介意觀看次數(shù)上略微有點不一致,對吧?更重要的是,視頻能夠在他們的瀏覽器中渲染出來。

主節(jié)點和副本節(jié)點之間的數(shù)據(jù)最終會是一致的。

因此,工程師們覺得非常開心,觀眾們也非常開心。隨著副本的引入,事情進(jìn)展順利。

網(wǎng)站繼續(xù)受到歡迎,QPS 繼續(xù)上升。主-從副本策略現(xiàn)在很難跟上網(wǎng)站流量的增長了。

那現(xiàn)在該怎么辦?

3.2 分片

下一個策略就是對數(shù)據(jù)庫進(jìn)行分片(shard)。分片是除了主-從副本、主-主副本、聯(lián)盟和反范式化(de-normalization) 之外,擴展關(guān)系型數(shù)據(jù)庫的方式之一。

數(shù)據(jù)庫分片并不是一個簡單的過程。它大大增加了系統(tǒng)的復(fù)雜性,并使得管理更加困難。

但是,數(shù)據(jù)庫必須要進(jìn)行分片,以滿足 QPS 的增長。在開發(fā)人員將數(shù)據(jù)庫分片后,數(shù)據(jù)會被分散到多臺機器上。這增加了系統(tǒng)寫入的吞吐量。現(xiàn)在,不再是只有一個主實例處理寫入,寫入操作可以在多臺分片的機器上進(jìn)行。

同時,每臺機器都創(chuàng)建了單獨的副本,以實現(xiàn)冗余和吞吐。

該平臺的受歡迎程度持續(xù)上升,大量的數(shù)據(jù)被內(nèi)容創(chuàng)作者不斷添加到數(shù)據(jù)庫中。

為了防止機器故障或者外部未知事件造成的數(shù)據(jù)丟失或服務(wù)不可用,此時需要在系統(tǒng)中添加災(zāi)難管理的功能了。

3.3 災(zāi)難管理

災(zāi)難管理指的是在面臨停電和自然災(zāi)害(如地震、火災(zāi))時的應(yīng)急措施。它需要進(jìn)行冗余,并將用戶數(shù)據(jù)備份到世界不同地理區(qū)域的數(shù)據(jù)中心。丟失用戶數(shù)據(jù)或服務(wù)不可用是不允許的。

在世界范圍內(nèi)擁有多個數(shù)據(jù)中心也有助于 YouTube 減少系統(tǒng)延遲,因為用戶請求會被路由到最近的數(shù)據(jù)中心,而不是路由到位于不同大陸的原始服務(wù)器。

現(xiàn)在,你可以想象基礎(chǔ)設(shè)施會變得多復(fù)雜。

經(jīng)常會有未經(jīng)優(yōu)化的全表掃描導(dǎo)致整個數(shù)據(jù)庫癱瘓。數(shù)據(jù)庫必須進(jìn)行保護(hù),防止受到不良查詢的影響。所有的服務(wù)器都需要被跟蹤以確保服務(wù)的高效性。

開發(fā)人員需要有一個系統(tǒng)來抽象系統(tǒng)的復(fù)雜性,能夠讓他們解決可擴展性的挑戰(zhàn),并以最小的成本管理該系統(tǒng)。這一切促使 YouTube 開發(fā)了 Vitess。

4.Vitess:用于水平擴展 MySQL 數(shù)據(jù)庫集群的系統(tǒng)

Vitess是一個運行于 MySQL 之上的數(shù)據(jù)庫集群系統(tǒng),能夠使 MySQL 進(jìn)行水平擴展。它有內(nèi)置的分片特性,能夠讓開發(fā)人員擴展數(shù)據(jù)庫,而不必在應(yīng)用中添加任何的分片邏輯。這類似于 NoSQL 的做法。

651d133e-8ef9-11ed-bfe3-dac502259ad0.jpg

Vitess 架構(gòu),圖片來源

Vitess 還會自動處理故障轉(zhuǎn)移和備份。它能夠管理服務(wù)器,通過智能重寫資源密集型的查詢和實現(xiàn)緩存來提高數(shù)據(jù)庫性能。除了 YouTube,該框架還被業(yè)界的其他知名廠商使用,如 GitHub、Slack、Square、New Relic 等。

當(dāng)你需要 ACID 事務(wù)和強一致性的支持,同時又希望像 NoSQL 數(shù)據(jù)庫一樣快速擴展關(guān)系型數(shù)據(jù)庫時,Vitess 就會大顯身手。

在 YouTube,每個 MySQL 連接都有 2MB 的開銷。每一個連接都有可計算出來的成本,而且隨著連接數(shù)量的增加,還必須增加額外的 RAM

通過基于 Go 編程語言并發(fā)支持構(gòu)建的連接池,Vitess 能夠以很低的成本管理這些連接。它使用 Zookeeper 來管理集群,并使其保持最新狀態(tài)。

5.部署到云中

Vitess 是云原生的,很適合云中部署,因為就像云的模式一樣,容量是逐步添加到數(shù)據(jù)庫的。它可以作為一個 Kubernetes 感知(Kubernetes-aware)的云原生分布式數(shù)據(jù)庫運行。

在 YouTube,Vitess 在容器化環(huán)境中運行,并使用 Kubernetes 作為容器編排工具。

在如今的計算時代,每個大規(guī)模的服務(wù)都在分布式環(huán)境的云中運行。在云中運行服務(wù)有許多好處。

Google Cloud Platform是一套云計算服務(wù),它的基礎(chǔ)設(shè)施與谷歌內(nèi)部的終端用戶產(chǎn)品(如谷歌搜索和 YouTube)所用的基礎(chǔ)設(shè)施是相同的。

每個大規(guī)模的在線服務(wù)都有一個多樣化(polyglot)的持久性架構(gòu),因為某一種數(shù)據(jù)模型,無論是關(guān)系型還是 NoSQL,都無法處理服務(wù)的所有使用場景。

在為本文展開的研究中,我無法找到 YouTube 所使用的具體谷歌云數(shù)據(jù)庫的清單,但我非常肯定它會使用 GCP 的特有產(chǎn)品,如 Google Cloud Spanner、Cloud SQL、Cloud Datastore、Memorystore 等來運行服務(wù)的不同特性。

這篇文章詳細(xì)介紹了其他谷歌服務(wù)所使用的數(shù)據(jù)庫,如Google Adwords、Google Finance、Google Trends等。

6.CDN

YouTube 使用谷歌的全球網(wǎng)絡(luò)進(jìn)行低延遲、低成本的內(nèi)容傳輸。借助全球分布的 POP 邊緣點,它能夠使客戶能夠更快地獲取數(shù)據(jù),而不必從原始服務(wù)器獲取。

所以,到此為止,我已經(jīng)談到了 YouTube 使用的數(shù)據(jù)庫、框架和技術(shù)。現(xiàn)在,該談一談存儲問題了。

YouTube 是如何存儲如此巨大的數(shù)據(jù)量的呢(每分鐘上傳 500 小時的視頻內(nèi)容)?

7.數(shù)據(jù)存儲:YouTube 是如何存儲如此巨大的數(shù)據(jù)量的呢?

視頻會存儲在谷歌數(shù)據(jù)中心的硬盤中。這些數(shù)據(jù)由 Google File System 和 BigTable 管理。

GFS Google File System是谷歌開發(fā)的一個分布式文件系統(tǒng),用于管理分布式環(huán)境中的大規(guī)模數(shù)據(jù)。

BigTable是一個建立在 Google File System 上的低延遲分布式數(shù)據(jù)存儲系統(tǒng),用于處理分布在成千上萬臺機器上的 PB 級別的數(shù)據(jù)。60 多個谷歌產(chǎn)品都使用了它。

因此,視頻被存儲在硬盤中。關(guān)系、元數(shù)據(jù)、用戶偏好、個人資料信息、賬戶設(shè)置、從存儲中獲取視頻所需的相關(guān)數(shù)據(jù)等都存儲在 MySQL 中。

653d8236-8ef9-11ed-bfe3-dac502259ad0.jpg

7.1 即插即用的商用服務(wù)器

谷歌數(shù)據(jù)中心擁有同質(zhì)化的硬件,軟件則是內(nèi)部構(gòu)建的,管理成千上萬的獨立服務(wù)器集群。

谷歌部署的服務(wù)器,能夠增強數(shù)據(jù)中心的存儲能力,它們都是商用服務(wù)器(commodity server),也被稱為商用現(xiàn)成的服務(wù)器(commercial off-the-shelf server)。這些服務(wù)器價格低廉,可廣泛使用和大量購買,并能以最小的成本和代價替換或配置數(shù)據(jù)中心的相同硬件。

隨著對額外存儲需求的增加,新的商用服務(wù)器會被插入到系統(tǒng)中。

出現(xiàn)問題后,商用服務(wù)器通常會被直接替換,而不是進(jìn)行修理。它們不是定制的,與運行定制的服務(wù)器相比,使用它們能夠使企業(yè)在很大程度上減少基礎(chǔ)設(shè)施成本。

7.2 為數(shù)據(jù)中心設(shè)計的存儲磁盤

YouTube 每天都需要超過一個 PB 的新存儲。旋轉(zhuǎn)硬盤驅(qū)動器是主要的存儲介質(zhì),因為其成本低,可靠性高。

SSD 固態(tài)硬盤比旋轉(zhuǎn)磁盤具有更高的性能,因為它們是基于半導(dǎo)體的,但大規(guī)模使用固態(tài)硬盤并不劃算。

它們相當(dāng)昂貴,也容易隨著時間的推移逐漸丟失數(shù)據(jù)。這使得它們不適合用于歸檔數(shù)據(jù)的存儲。

另外,谷歌正在開發(fā)一個適用于大規(guī)模數(shù)據(jù)中心的新磁盤系列。

有五個關(guān)鍵指標(biāo)可用來判斷為數(shù)據(jù)存儲而構(gòu)建的硬件的質(zhì)量:

硬件應(yīng)該有能力支持秒級的高速度輸入輸出操作。

它應(yīng)該符合組織規(guī)定的安全標(biāo)準(zhǔn)。

與普通存儲硬件相比,它應(yīng)該有更高的存儲容量。

硬件采購成本、電力成本和維護(hù)費用應(yīng)該都是可以接受的。

磁盤應(yīng)該是可靠的,并且延遲是穩(wěn)定的。

審核編輯 :李倩

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 數(shù)據(jù)存儲
    +關(guān)注

    關(guān)注

    5

    文章

    970

    瀏覽量

    50904
  • 數(shù)據(jù)庫
    +關(guān)注

    關(guān)注

    7

    文章

    3798

    瀏覽量

    64370
  • Youtube
    +關(guān)注

    關(guān)注

    0

    文章

    143

    瀏覽量

    15546

原文標(biāo)題:YouTube 數(shù)據(jù)庫如何保存巨量視頻文件?

文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    數(shù)據(jù)庫加密辦法

    ,當(dāng)我們聊到數(shù)據(jù)加密的時候,可以從這些角度入手來提高數(shù)據(jù)的安全性。 TDE手段 TDE也就是透明數(shù)據(jù)加密,是一種在數(shù)據(jù)庫級別進(jìn)行加密的技術(shù)。它對整個
    的頭像 發(fā)表于 12-24 09:47 ?21次閱讀

    如何使用cmp進(jìn)行數(shù)據(jù)庫管理的技巧

    使用 cmp 命令進(jìn)行數(shù)據(jù)庫管理可能不是最直觀的方法,因為 cmp 通常用于比較兩個文件是否相同。然而,如果你的意圖是使用 cmp 來檢查數(shù)據(jù)庫文件或備份文件的一致性,以下是一些技巧和
    的頭像 發(fā)表于 12-17 09:31 ?92次閱讀

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—Mysql數(shù)據(jù)庫表記錄丟失的數(shù)據(jù)恢復(fù)流程

    Mysql數(shù)據(jù)庫故障: Mysql數(shù)據(jù)庫表記錄丟失。 Mysql數(shù)據(jù)庫故障表現(xiàn): 1、Mysql數(shù)據(jù)庫表中無任何數(shù)據(jù)或只有部分
    的頭像 發(fā)表于 12-16 11:05 ?127次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—Mysql<b class='flag-5'>數(shù)據(jù)庫</b>表記錄丟失的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)流程

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—MYSQL數(shù)據(jù)庫ibdata1文件損壞的數(shù)據(jù)恢復(fù)案例

    mysql數(shù)據(jù)庫故障: mysql數(shù)據(jù)庫文件ibdata1、MYI、MYD損壞。 故障表現(xiàn):1、數(shù)據(jù)庫無法進(jìn)行查詢等操作;2、使用mysqlcheck和myisamchk無法修復(fù)數(shù)據(jù)庫
    的頭像 發(fā)表于 12-09 11:05 ?147次閱讀

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—通過拼接數(shù)據(jù)庫碎片恢復(fù)SQLserver數(shù)據(jù)庫

    一個運行在存儲上的SQLServer數(shù)據(jù)庫,有1000多個文件,大小幾十TB。數(shù)據(jù)庫每10天生成一個NDF文件,每個NDF幾百GB大小。數(shù)據(jù)庫
    的頭像 發(fā)表于 10-31 13:21 ?206次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—通過拼接<b class='flag-5'>數(shù)據(jù)庫</b>碎片恢復(fù)SQLserver<b class='flag-5'>數(shù)據(jù)庫</b>

    Oracle數(shù)據(jù)恢復(fù)—異常斷電后Oracle數(shù)據(jù)庫報錯的數(shù)據(jù)恢復(fù)案例

    Oracle數(shù)據(jù)庫的在線文件,需要恢復(fù)zxfg用戶的數(shù)據(jù)。 Oracle數(shù)據(jù)庫恢復(fù)方案: 檢測數(shù)據(jù)庫故障;嘗試掛起并修復(fù)
    的頭像 發(fā)表于 09-30 13:31 ?300次閱讀
    Oracle<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—異常斷電后Oracle<b class='flag-5'>數(shù)據(jù)庫</b>啟<b class='flag-5'>庫</b>報錯的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—Oracle數(shù)據(jù)庫文件system01.dbf損壞的數(shù)據(jù)恢復(fù)案例

    打開oracle數(shù)據(jù)庫報錯“system01.dbf需要更多的恢復(fù)來保持一致性,數(shù)據(jù)庫無法打開”。
    的頭像 發(fā)表于 09-21 14:25 ?331次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—Oracle<b class='flag-5'>數(shù)據(jù)庫文件</b>system01.dbf損壞的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—SQL Server數(shù)據(jù)庫出現(xiàn)823錯誤的數(shù)據(jù)恢復(fù)案例

    SQL Server數(shù)據(jù)庫故障: SQL Server附加數(shù)據(jù)庫出現(xiàn)錯誤823,附加數(shù)據(jù)庫失敗。數(shù)據(jù)庫沒有備份,無法通過備份恢復(fù)數(shù)據(jù)庫
    的頭像 發(fā)表于 09-20 11:46 ?342次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—SQL Server<b class='flag-5'>數(shù)據(jù)庫</b>出現(xiàn)823錯誤的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—SqlServer數(shù)據(jù)庫底層File Record被截斷為0的數(shù)據(jù)恢復(fù)案例

    SQL Server數(shù)據(jù)庫數(shù)據(jù)無法被讀取。 經(jīng)過數(shù)據(jù)庫數(shù)據(jù)恢復(fù)工程師的初步檢測,發(fā)現(xiàn)SQL Server數(shù)據(jù)庫文件無法被讀取的原因是底層
    的頭像 發(fā)表于 07-26 11:27 ?380次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—SqlServer<b class='flag-5'>數(shù)據(jù)庫</b>底層File Record被截斷為0的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—SQL Server數(shù)據(jù)庫所在分區(qū)空間不足報錯的數(shù)據(jù)恢復(fù)案例

    Server數(shù)據(jù)庫故障: 存放SQL Server數(shù)據(jù)庫的D盤分區(qū)容量不足,管理員在E盤中生成了一個.ndf的文件并且將數(shù)據(jù)庫路徑指向E盤繼續(xù)使用。
    的頭像 發(fā)表于 07-10 13:54 ?486次閱讀

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—raid5陣列上層Sql Server數(shù)據(jù)庫數(shù)據(jù)恢復(fù)案例

    數(shù)據(jù)庫故障: 數(shù)據(jù)庫文件丟失,主要涉及3個數(shù)據(jù)庫,數(shù)千張表。數(shù)據(jù)庫文件丟失原因未知,不能確定丟失的數(shù)據(jù)庫文件的存放位置。
    的頭像 發(fā)表于 05-08 11:43 ?505次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—raid5陣列上層Sql Server<b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—ndf文件大小變?yōu)?KB的數(shù)據(jù)恢復(fù)案例

    存儲設(shè)備損壞導(dǎo)致存儲中SQL Server數(shù)據(jù)庫崩潰。對數(shù)據(jù)庫文件進(jìn)行恢復(fù)后,用戶發(fā)現(xiàn)有4個ndf文件的大小變?yōu)?KB。該SQL Server數(shù)據(jù)庫每10天生成一個大小相同的NDF
    的頭像 發(fā)表于 05-07 11:19 ?416次閱讀

    MongoDB數(shù)據(jù)恢復(fù)—MongoDB數(shù)據(jù)庫文件損壞的數(shù)據(jù)恢復(fù)案例

    的情況下,將數(shù)據(jù)庫文件拷貝到其他分區(qū)。拷貝完成后將原MongoDB數(shù)據(jù)庫所在分區(qū)進(jìn)行了格式化操作,然后將數(shù)據(jù)庫文件拷回原分區(qū),重新啟動MongoDB服務(wù),服務(wù)無法啟動。
    的頭像 發(fā)表于 04-23 14:48 ?401次閱讀
    MongoDB<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—MongoDB<b class='flag-5'>數(shù)據(jù)庫文件</b>損壞的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)—Sql Server數(shù)據(jù)庫文件丟失的數(shù)據(jù)恢復(fù)案例

    。存儲空間LUN劃分了兩個邏輯分區(qū)。 服務(wù)器故障&初檢: 由于未知原因,Sql Server數(shù)據(jù)庫文件丟失,丟失數(shù)據(jù)涉及到3個,表的數(shù)量有3000左右。數(shù)據(jù)庫文件丟失原因還沒
    的頭像 發(fā)表于 04-11 15:38 ?884次閱讀
    <b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—Sql Server<b class='flag-5'>數(shù)據(jù)庫文件</b>丟失的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    數(shù)據(jù)庫數(shù)據(jù)恢復(fù)】Oracle數(shù)據(jù)庫ASM實例無法掛載的數(shù)據(jù)恢復(fù)案例

    oracle數(shù)據(jù)庫ASM磁盤組掉線,ASM實例不能掛載。數(shù)據(jù)庫管理員嘗試修復(fù)數(shù)據(jù)庫,但是沒有成功。
    的頭像 發(fā)表于 02-01 17:39 ?521次閱讀
    【<b class='flag-5'>數(shù)據(jù)庫</b><b class='flag-5'>數(shù)據(jù)</b>恢復(fù)】Oracle<b class='flag-5'>數(shù)據(jù)庫</b>ASM實例無法掛載的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例
    主站蜘蛛池模板: 色美妞论坛| 亚洲精品久久国产高清| 亚洲妈妈精品一区二区三区| 2020最新无码国产在线视频| 国产AV99激情久久无码天堂| 久久精品国产免费播放| 色老汉网址导航| 51国产午夜精品免费视频| 国产精品国产三级国产专区53| 老年日本老年daddy| 无羞耻肉动漫在线观看| 99国产精品久久人妻| 国产午夜精品一区理论片飘花| 欧美14videosex性欧美成人| 亚洲嫩草AV永久无码精品无码| 成人国产精品视频频| 久久亚洲AV无码精品午色夜麻豆| 四房播播开心色播| aaa级黄影片| 久久久黄色片| 性与肉体电影免费观看| yy4408午夜场理论片| 久久看片网| 亚洲高清国产拍精品5g| 成人在线免费视频播放| 久热这里只有精品99国产6| 亚洲VA天堂VA欧美VA在线| 不卡的在线AV网站| 麻花传媒XK在线观看| 亚洲欧美无码2017在线| 国产成人理在线观看视频| 欧美日韩另类在线观看视频 | 无码中文字幕热热久久| 99精品视频在线观看| 久久国产精品久久国产精品| 微福利92合集| 动漫在线观看免费肉肉| 亲胸摸下面激烈免费网站| 7777色鬼xxxx欧美色夫| 久久99精品国产自在自线| 亚洲AV成人无码网天堂|