產(chǎn)品經(jīng)理是否需要寫數(shù)據(jù)庫備份的需求文檔？關(guān)于這個(gè)問題，不同人可能會(huì)有不一樣的看法?；蛟S在進(jìn)一步探討寫不寫數(shù)據(jù)歸檔需求這個(gè)問題之前，產(chǎn)品經(jīng)理還需要了解下數(shù)據(jù)庫是什么以及為什么要數(shù)據(jù)備份歸檔。一起跟著作者來梳理清楚這個(gè)問題吧。

某個(gè)晚上七點(diǎn)，在下班的地鐵上，一群友發(fā)出了如下的疑問：

“請(qǐng)教個(gè)問題，這數(shù)據(jù)庫備份，各種表的刪除和備份，這種需求文檔也需要產(chǎn)品經(jīng)理來寫？難道不是技術(shù)人員的活兒？”

“什么產(chǎn)品功能都沒有，就是因?yàn)閿?shù)據(jù)庫滿了，內(nèi)存可能不夠了，要?jiǎng)h除一些表，然后備份到別的地方。建議擴(kuò)內(nèi)存，開發(fā)也不聽。我說我寫不了，結(jié)果技術(shù)就讓我看他們以前的留言和代碼截圖，還是英文的，我真的是服了！氣炸了好嗎！就算要寫，也得把前因后果給我講清楚??！什么都不說就讓我寫，我怎么寫？”

產(chǎn)品經(jīng)理是否需要寫數(shù)據(jù)庫備份的需求文檔，這在群里引發(fā)了一場(chǎng)激烈的討論。

一、群友的看法

1. 不寫派

不需要，除非你會(huì)技術(shù)、如果你懂的話，可以出，不懂就讓技術(shù)弄；

不需要寫，懂也不需要寫；

技術(shù)會(huì)鄙視，不該你寫的瞎寫；

這種需求為啥還要產(chǎn)品來寫，要開發(fā)干嘛；

產(chǎn)品的時(shí)間和精力都花在這上面，意味著更有價(jià)值的事情被擱置了，產(chǎn)品的本職工作也沒做。

2. 論事派

這種行為看起來像是甩鍋行為，開發(fā)在推卸責(zé)任。

根據(jù)描述，很明顯是在給題主制造麻煩。退一步說，產(chǎn)品可以做到這種程度，但前提是對(duì)方也要做到這種程度：應(yīng)該清楚地解釋事情的前因后果，不要給截圖，也不要給英文。

3. 要寫派

B這是關(guān)于表數(shù)據(jù)歸集的問題，需要考慮是按月、季度還是年進(jìn)行歸檔。這些歸檔需求都需要產(chǎn)品經(jīng)理來定義。在確定歸檔時(shí)間后，系統(tǒng)中的所有查詢和統(tǒng)計(jì)邏輯都必須考慮到這個(gè)歸檔時(shí)間。數(shù)據(jù)歸檔通常需要拆分一個(gè)菜單或入口進(jìn)行查詢，因此查詢頁面和交互是不同的。

數(shù)據(jù)歸檔由技術(shù)人員負(fù)責(zé)，產(chǎn)品提供規(guī)則。例如，歸檔的頻率、歸檔后的數(shù)據(jù)在哪里可以查詢以及如何處理儀表盤的統(tǒng)計(jì)等。由于核心問題是 SQL 查詢慢，這影響了許多實(shí)時(shí)邏輯，所以說升級(jí)數(shù)據(jù)庫容量不是萬能的。

歸檔的需求不僅需要產(chǎn)品提供良好的支持，而且對(duì)多個(gè)業(yè)務(wù)的影響范圍可能大可能小。如果由于歸檔導(dǎo)致產(chǎn)品出現(xiàn)問題，比如查詢不到訂單等，產(chǎn)品需要進(jìn)行設(shè)計(jì)以解決這些反饋。

二、懂點(diǎn)數(shù)據(jù)庫基本概念

進(jìn)一步探討寫不寫數(shù)據(jù)歸檔需求這個(gè)問題之前，作為產(chǎn)品經(jīng)理，有必要了解下數(shù)據(jù)庫是什么以及為什么要數(shù)據(jù)備份歸檔，什么是磁盤容量、內(nèi)存大小，不然像上文群友一樣以為升級(jí)內(nèi)存就完事了。

1. 數(shù)據(jù)庫、表、數(shù)據(jù)

數(shù)據(jù)庫就像一個(gè)圖書館，圖書館里面有很多個(gè)書架（數(shù)據(jù)表），存儲(chǔ)著各種書籍（數(shù)據(jù)），每本書都有自己的編號(hào)（主鍵），可以通過編號(hào)快速找到對(duì)應(yīng)的書籍。

2. 磁盤容量

磁盤容量就像圖書館的大小，可以容納的書架數(shù)量以及書架大小，決定了能容納多少本書。數(shù)據(jù)庫的磁盤容量決定了它能存儲(chǔ)多少數(shù)據(jù)。

3. 內(nèi)存大小

內(nèi)存就像圖書館的工作人員，負(fù)責(zé)幫助讀者快速找到需要的書籍。內(nèi)存越大，處理讀者請(qǐng)求的能力越強(qiáng)，查詢速度也越快。

例子：打工馬嘍

假設(shè)某一個(gè)人力資源集團(tuán)有10個(gè)下屬公司（10個(gè)數(shù)據(jù)庫），每個(gè)公司分了10個(gè)部門（10張數(shù)據(jù)表），每個(gè)部門有10個(gè)馬嘍工位（因此該數(shù)據(jù)庫總磁盤容量100GB），工位上記錄著每個(gè)馬嘍的信息，包括姓名、工號(hào)、學(xué)歷、技能等，意味著每個(gè)下屬公司最多可以同時(shí)收納100個(gè)馬嘍（存儲(chǔ)100GB的數(shù)據(jù)，數(shù)據(jù)庫會(huì)從磁盤讀取數(shù)據(jù)，并加載到內(nèi)存中進(jìn)行處理）。

該人力集團(tuán)由于沒有建設(shè)信息化，所以給每個(gè)分公司設(shè)置了10塊大黑板+10個(gè)匹配專工（數(shù)據(jù)庫內(nèi)存是10GB），讓銷售人員接待甲方人力需求的咨詢和下單的時(shí)候用（系統(tǒng)可以使用這10GB內(nèi)存來快速訪問和操作數(shù)據(jù)庫中的數(shù)據(jù)）。

集團(tuán)主要的銷售方式是電呼，當(dāng)有甲方需要咨詢外包需求時(shí)候，銷售人員就會(huì)讓專工根據(jù)客戶需求去工位查詢各個(gè)馬嘍的信息，并且把符合條件的馬嘍信息記錄在大黑板上，以便跟客戶進(jìn)一步溝通。

最終如果某個(gè)馬嘍被外包成交了，最終要去工位修改馬嘍的外包信息，以免后面的銷售判斷錯(cuò)誤。

所以說如果黑板夠大夠多，專工數(shù)量越多，動(dòng)作越快，處理速度就會(huì)更快。也就是內(nèi)存足夠大，系統(tǒng)可以快速找到并返回所需信息。但如果內(nèi)存不足，系統(tǒng)可能需要頻繁地從磁盤讀取數(shù)據(jù)，導(dǎo)致查詢速度變慢。

當(dāng)集團(tuán)業(yè)務(wù)越來越好，招攬的馬嘍越來越多，但是黑板和專工也不可能無限放大（不符合資本性價(jià)比），因此，對(duì)馬嘍的工位和信息進(jìn)行分類、歸檔、遷移，讓專工可以根據(jù)不同的情況，針對(duì)性去不同的地方“找馬嘍”，就可以提高工作速度了。

三、產(chǎn)品歸檔需求怎么接

1. 不歸檔的壞處

一般來說，對(duì)于單表的數(shù)據(jù)量，800萬（800W）到1000萬（1000W）條數(shù)據(jù)是一個(gè)比較合適的范圍。數(shù)據(jù)量太大的話，會(huì)有以下影響：

• 性能下降：隨著數(shù)據(jù)量的增加，查詢、插入、更新和刪除操作的性能可能會(huì)受到影響。大量的數(shù)據(jù)可能導(dǎo)致數(shù)據(jù)庫的響應(yīng)時(shí)間變慢，尤其是在執(zhí)行復(fù)雜查詢或涉及大量數(shù)據(jù)的操作時(shí)。
• 存儲(chǔ)和內(nèi)存需求加大：大量的數(shù)據(jù)需要更多的存儲(chǔ)空間和內(nèi)存來存儲(chǔ)和處理。這可能對(duì)硬件資源造成壓力，并可能導(dǎo)致存儲(chǔ)成本的增加。
• 數(shù)據(jù)管理和維護(hù)困難：處理大量的數(shù)據(jù)可能會(huì)使數(shù)據(jù)管理、備份和恢復(fù)變得更加復(fù)雜和耗時(shí)。
• 索引和查詢優(yōu)化困難：對(duì)于大型數(shù)據(jù)表，索引的維護(hù)和查詢優(yōu)化可能變得更具挑戰(zhàn)性，需要更多的關(guān)注和優(yōu)化工作。

最直接的表象，就是用戶在做各種查詢、統(tǒng)計(jì)、導(dǎo)出操作的時(shí)候，會(huì)巨慢、奇卡無比，甚至?xí)僮魇　?/p>

2. 歸檔需求怎么做提

站在產(chǎn)品經(jīng)理角度，歸檔先分兩種情況。

1）歷史功能或是自身不熟悉的功能

像上文那種情況，針對(duì)歷史功能需要進(jìn)行歸檔，筆者先站個(gè)觀點(diǎn)：一個(gè)盡職的產(chǎn)品經(jīng)理還是要把需求接下來，以推動(dòng)工作的展開。

但是，像這種歷史功能，開發(fā)不是很配合，又有明顯的推諉行為，那就需要跟開發(fā)溝通，讓開發(fā)梳理出對(duì)應(yīng)需要?dú)w檔的表涉及到哪些依賴關(guān)系、有什么接口在調(diào)用，整理后書面發(fā)出來，然后大家再一起評(píng)估下有無遺漏，要注意的點(diǎn)之后，再繼續(xù)推進(jìn)。

因?yàn)闅w檔數(shù)據(jù)對(duì)業(yè)務(wù)影響可大可小，在不熟悉的情況下千萬別貿(mào)然推進(jìn)，搞不好成為背鍋對(duì)象。

2）新功能需求或自身很熟悉的功能

自己很熟悉的功能，或者是規(guī)劃新需求，可以先自行梳理后，再跟開發(fā)、測(cè)試、業(yè)務(wù)等人員多視角一起評(píng)估。

確定分表策略：產(chǎn)品經(jīng)理確定好數(shù)據(jù)庫分表的策略，包括分表的依據(jù)字段、分表的規(guī)則，是按時(shí)間來歸檔，還是按某個(gè)數(shù)據(jù)狀態(tài)來分表。初步擬定后需要與技術(shù)團(tuán)隊(duì)一起溝通評(píng)估。

分表分析溝通：產(chǎn)品經(jīng)理需要和技術(shù)團(tuán)隊(duì)對(duì)數(shù)據(jù)庫分表的影響進(jìn)行充分的分析，并與相關(guān)利益相關(guān)者進(jìn)行溝通和確認(rèn)，以確保分表的過程對(duì)系統(tǒng)的影響可控。

輸出分表需求：分表之后，歸檔的數(shù)據(jù)是否允許前端查看，如果需要查看，是分多個(gè)菜單，還是在原來的菜單，篩選條件是否針對(duì)性進(jìn)行限制，比如只能按月篩選查看數(shù)據(jù)，或者按某個(gè)狀態(tài)篩選查看篩選數(shù)據(jù)。并羅列清楚對(duì)應(yīng)的修改點(diǎn)、修改功能有哪些，需要怎么修改，怎么取數(shù)等。

通過合理的數(shù)據(jù)分表歸檔策略，能夠更好地管理和利用數(shù)據(jù)，提高系統(tǒng)的性能和可維護(hù)性。期待與各位讀者共同分享和探討更多關(guān)于數(shù)據(jù)管理的經(jīng)驗(yàn)和思考。