在 1C,我們廣泛地使用自己的開發成果來組織公司的工作。尤其,
超過 1 名員工在 11C 使用文件管理。這個資料庫已經變得令人印象深刻(XNUMX 億筆記錄),這意味著它需要更仔細的維護和更強大的設備。
我們的系統是如何運作的,我們在維護資料庫時遇到了哪些困難以及我們如何解決它們(我們使用MS SQL Server作為DBMS)——我們將在文章中告訴你。
適合第一次閱讀 1C 產品的人。
1C:Document Flow 是在開發業務應用程式的框架-1C:Enterprise 平台基礎上實現的應用程式解決方案(配置)。
「1C:文件流程 8」(縮寫為 DO)可讓您在企業中自動化處理文件。員工互動的主要工具之一是電子郵件。除了郵件之外,DO還解決其他問題:
- 時間追蹤
- 員工缺勤追蹤
- 快遞/運輸申請
- 員工工作行事曆
- 信件登記
- 員工聯絡人(地址簿)
- 企業論壇
- 預訂房間
- 活動企劃
- CRM
- 集體處理文件(保存文件版本)
- 等等
我們進入文件管理
感謝我們與文檔流相關的其他產品 -
我們DO中的字母數量已經超過100億,DBMS中一般有超過11億筆記錄。系統總共使用了近 30 TB 的儲存空間:資料庫磁碟區為 7,5 TB,集體工作的檔案單獨存儲,另外佔用 21 TB。
如果我們談論更具體的數字,這是目前的信件和文件數量:
- 發出的電子郵件 – 14,7 萬封。
- 收到的信件 – 85,4 萬封。
- 檔案版本 – 70,8 萬個。
- 內部文件 – 30,6。
DO 不僅僅擁有郵件和文件。以下是其他會計對象的數字:
- 預約會議室 – 52
- 每週報告 – 153
- 每日報告 – 628
- 核准簽證 – 11
- 傳入文件 – 79
- 傳出文件 – 28
- 有關使用者工作日曆中的事件的條目 – 168
- 快遞申請 – 21
- 交易對手 – 81
- 與交易對手的合作記錄 – 45
- 交易對手聯絡人 – 41
- 活動 – 10
- 項目 – 6
- 員工任務 – 245
- 論壇貼文 – 26
- 聊天訊息 – 891 095
- 業務流程 - 109。員工之間的互動是透過流程進行的 - 審核、執行、審核、註冊、簽署等。我們測量流程的持續時間、週期數、參與者數、返回數、更改截止日期的請求數。這些資訊對於分析非常有用,可以了解企業中正在發生哪些流程並提高員工協作的效率。
我們用什麼設備來處理這一切?
這些數字表明任務量令人印象深刻,因此我們需要分配相當高效的設備來滿足內部子公司的需求。目前,其特徵如下:38個核心,240 GB RAM,26 TB磁碟。這是一個伺服器表:
未來,我們計劃增加設備的產能。
伺服器負載情況如何?
網路活動對我們或我們的客戶來說從來都不是問題。一般來說,弱點是處理器和磁碟,因為每個人都已經知道如何處理記憶體不足的問題。以下是資源監視器中我們伺服器的螢幕截圖,這表示我們沒有任何可怕的負載,它非常適中。
例如,在下面的螢幕截圖中,我們看到 SQL 伺服器的 CPU 負載為 23%。這是一個非常好的指標(作為比較:如果負載接近 70%,那麼員工很可能會觀察到工作明顯放緩)。
第二個螢幕截圖顯示了 1C:Enterprise 平台運行的應用程式伺服器 - 它只為使用者會話提供服務。這裡處理器負載稍高——38%,平穩而平靜。雖然有一些磁碟負載,但可以接受。
第三個螢幕截圖顯示了另一個 1C:Enterprise 伺服器(這是第二個,我們叢集中有兩個)。只有前一處為用戶服務,這一處由機器人工作。例如,他們接收郵件、傳送文件、交換資料、計算權利等。所有這些後台活動執行約 90-100 個背景作業。而且該伺服器的負載非常重 - 88%。但這並不影響人,而且它完全實現了文件管理應該做的所有自動化。
衡量績效的指標是什麼?
我們的子公司內建了一個嚴肅的子系統,用於衡量績效指標和計算各種指標。為了了解當下時刻以及從歷史的角度來看,系統中正在發生什麼、什麼正在變得更糟、什麼正在變得更好,這是必要的。監控工具 - 指標和時間測量 - 包含在「1C:文件流程 8」的標準交付中。指標在實施過程中需要定制,但機製本身是標準的。
指標是在某個時間點(例如,平均郵件發送時間為 10 分鐘)對各種業務指標的測量。
其中一項指標顯示資料庫中的活動使用者數量。白天平均有 1000-1400 個。此圖顯示,在截圖時,資料庫中有 2144 個活躍用戶。
這樣的動作有30多個,清單正在刪減中。表
- 登入
- 登出
- 正在載入郵件
- 更改對象的有效性
- 更改存取權限
- 改變進程的主題
- 更改物件的工作群組
- 改變套件的組成
- 更改文件
- 文件導入
- 透過郵件發送
- 移動文件
- 重定向任務
- 簽署電子簽名
- 按詳情搜尋
- 全文搜尋
- 接收文件
- 中斷行程
- 查看
- 解密
- 文件登記
- 掃描
- 取消標記刪除
- 創建對象
- 儲存到磁碟
- 流程開始
- 刪除使用者日誌條目
- 刪除電子簽名
- 設定刪除標記
- 加密
- 匯出資料夾
前一周,我們的平均用戶活動增加了一倍半(如圖中紅色所示)——這是由於大多數員工轉向遠端工作(由於眾所周知的事件)。此外,隨著員工開始積極使用手機:每個行動用戶端都會創建與伺服器的連接,活躍用戶數量增加了 3 倍(螢幕截圖中的藍色部分)。目前,平均每位員工都有 2 個與伺服器的連線。
對於我們作為管理員來說,這是一個訊號,表明我們需要更加關注效能問題,看看情況是否變得更糟。但我們根據其他參數來看這一點。例如,內部路由的郵件傳遞時間如何變化(在下面的螢幕截圖中以藍色顯示)。我們看到今年之前它一直在波動,但現在它是穩定的——對我們來說,這表明系統一切正常。
我們應用的另一個指標是從郵件伺服器下載信件的平均等待時間(在螢幕截圖中以紅色顯示)。粗略地說,這封信會在網路上流傳多久才能到達我們的員工手中。截圖顯示,這個時間最近也沒有任何變化。存在孤立的峰值 - 但它們與延遲無關,而是與郵件伺服器上的時間遺失有關。
或者,例如,另一個指標(在螢幕截圖中以藍色顯示)——更新資料夾中的字母。開啟郵件資料夾是一項非常常見的操作,需要快速完成。我們衡量它的執行速度。此指標針對每個客戶進行測量。您可以看到公司的整體情況和動態,例如單一員工的動態。螢幕截圖顯示,直到今年該指標都是不平衡的,然後我們進行了一些改進,現在它並沒有變得更糟 - 圖表幾乎是平坦的。
指標基本上是管理員用於監視系統的工具,用於快速回應系統行為的任何變化。螢幕截圖顯示了當年的內部子公司指標。圖表的跳躍是由於我們被賦予了發展內部子公司的任務。
這是一些更多指標的清單(在削減範圍內)。
指標
- 使用者活動
- 活躍用戶
- 活躍行程
- 文件數量
- 文件大小(MB)
- 文件數量
- 要傳送給收件人的物件數量
- 交易對手數量
- 未完成的任務
- 過去 10 分鐘內從郵件伺服器下載電子郵件的平均等待時間
- 外部資料緩衝區:檔案數量
- 從目前日期滯後的邊界
- 長隊
- 操作隊列
- 透過外部路由的原始帳戶年齡
- 內部路由接受佇列大小(長隊列)
- 內部路由接受佇列大小(快速佇列)
- 透過內部路由的郵件遞送時間(長隊)
- 透過內部路由的郵件傳送時間(快速佇列)
- 透過外部路由的郵件遞送時間(平均)
- 文件數量 預約
- 文件數量 缺席
- 「與對方合作的記錄」文件數量
- 郵件更新資料夾中的信件
- 郵件 開啟信卡
- 郵件 將信件轉移到資料夾
- 郵件 瀏覽資料夾
我們的系統全天候測量150多個指標,但並非所有指標都能快速監控。從某些歷史角度來看,它們稍後可能會派上用場,您可以專注於對業務最重要的事情。
例如,在其中一項實施中,僅選擇了 5 個指標。客戶設定了一個目標,即創建一組最小的指標,但同時使其涵蓋主要工作場景。將150項指標納入驗收證書是不合理的,因為即使在企業內部也很難就哪些指標被認為可以接受達成一致。他們了解這5個指標,並在實施專案開始前就已經將其呈現給系統,並將其包含在競賽文件中:開卡時間不超過3秒,完成帶文件任務的時間不超過5秒。超過XNUMX秒等在我們的子公司中,我們的指標非常清楚地反映了客戶技術規格的原始要求。
我們也對性能測量進行了概要分析。效能指標是對每個正在進行的操作(向資料庫寫信、向郵件伺服器發送信件等)持續時間的記錄。這是技術人員專用的。我們在我們的計劃中累積了許多績效指標。目前,我們測量了大約 1500 個關鍵操作,這些操作被分成多個設定檔。
對我們來說最重要的資料之一是「從消費者角度來看的郵件關鍵指標清單」。此設定檔包括例如以下指標:
- 執行指令:按標籤選擇
- 開啟表單:清單表單
- 執行命令:按資料夾選擇
- 在閱讀區域顯示字母
- 將信件儲存到您最喜歡的資料夾中
- 按詳細資訊搜尋字母
- 創建一封信
如果我們發現某些業務指標的指標變得太大(例如,特定用戶的信件已經開始到達很長一段時間),我們就開始弄清楚並轉向測量技術操作的時間。我們有一個技術操作「在郵件伺服器上歸檔信件」 - 我們看到上一個時期已經超出了該操作的時間。該操作又被分解為其他操作 - 例如,建立與郵件伺服器的連線。我們看到由於某種原因它突然變得非常大(我們有一個月的所有測量值 - 我們可以比較上週它是 10 毫秒,現在是 1000 毫秒)。我們知道這裡有些東西壞了 - 我們需要修復它。
這麼大的資料庫我們要如何維護呢?
我們的內部 DO 是一個真正有效的高負載項目的例子。我們先來談談它的資料庫的技術特點。
重組大型資料庫表需要多長時間?
SQL 伺服器需要定期維護,使表井井有條。最好每天至少執行一次此操作,對於高需求的表則應該更頻繁地執行此操作。但如果資料庫很大(而且我們的記錄數量已經超過11億筆),那麼照顧它並不容易。
六年前,我們對餐桌進行了重組,但後來開始花費太多時間,以至於我們不再適應每晚的間隔。而且由於這些操作會給 SQL Server 帶來沉重負擔,因此它無法有效地為其他使用者提供服務。
所以,現在我們必須使用各種技巧。例如,我們無法在完整的資料集上執行這些過程。您必須求助於「更新樣本 500000 行」過程 - 這需要 14 分鐘。它不會更新表中所有數據的統計信息,而是選擇 XNUMX 萬行並使用它們來計算用於整個表的統計信息。這是一些假設,但我們不得不這樣做,因為對於一個特定的表,收集整個十億筆記錄的統計數據將花費非常長的時間。
我們也透過部分優化其他維護操作。
維護 DBMS 通常是一項複雜的任務。在員工之間積極互動的情況下,資料庫快速成長,管理員維護它變得越來越困難——更新統計資料、碎片整理、索引。在這裡我們需要應用不同的策略,我們很清楚如何做到這一點,我們有經驗,我們可以分享。
如何對此類卷實施備份?
完整的 DBMS 備份每天晚上執行一次,增量備份則每小時執行一次。另外,每天都會建立一個檔案目錄,它是檔案儲存增量備份的一部分。
完成完整備份需要多長時間?
硬碟的完整備份在三小時內完成,部分備份在一小時內完成。寫入磁帶需要更長的時間(一種特殊設備,可以將備份副本複製到辦公室外儲存的特殊磁帶上;在磁帶上製作可轉移的副本,如果伺服器機房被燒毀,該副本將被保留)。備份是在完全相同的伺服器上進行的,該伺服器的參數更高 - 處理器負載為 20% 的 SQL 伺服器。當然,在備份時,系統會變得更糟,但它仍然可以正常工作。
有重複資料刪除嗎?
是否有唯讀節點?
沒有讀取節點(為那些需要接收任何資料進行讀取的人提供服務的專用系統節點)。 DO 不是一個會計系統放在單獨的 BI 節點上,而是有一個單獨的開發部門節點,與該節點以 JSON 格式交換訊息,典型的複製時間為單位和幾十秒。該節點仍然很小,大約有 800 億筆記錄,但成長很快。
標記為刪除的電子郵件是否根本沒有被刪除?
還沒有。我們的任務不是讓底座變得更輕。有幾個相當嚴重的案例需要引用標記為刪除的字母,其中包括 2009 年。這就是為什麼我們決定暫時保留一切。但當這樣做的成本變得不合理時,我們就會考慮拆除。但是,如果您需要從資料庫中完全刪除單獨的字母以便不留任何痕跡,則可以透過特殊請求來完成。
為什麼要儲存它?您有舊文件存取情況的統計資料嗎?
沒有統計數據。更準確地說,它是用戶日誌的形式,但不會長期儲存。超過一年的條目將從協議中刪除。
有時需要檢索五年前甚至十年前的舊信件。這樣做並不是出於無謂的好奇心,而是為了做出複雜的業務決策。曾經有過這樣的情況:如果沒有通訊記錄,就會做出錯誤的商業決策。
文件的價值如何根據保存期限進行評估和銷毀?
對於紙質文檔,這與其他人一樣以通常的傳統方式完成。我們不會為電子產品這樣做——讓他們自己保留。座位就在這裡。有好處。每個人都很好。
有哪些發展前景?
現在我們的 DO 解決了大約 30 個內部問題,其中一些我們在文章開頭列出了。 DL 也用於準備我們每年為合作夥伴舉行兩次的會議:整個計劃、所有報告、所有平行部分、大廳 - 所有這些都在 DL 中輸入,然後從中下載,以及打印的計劃被製成。
除了已經解決的任務之外,DO 還將面臨更多任務。有全公司範圍的任務,也有隻有特定部門需要的獨特且罕見的任務。有必要幫助他們,這意味著在1C範圍內擴大使用系統的「地理」——擴大應用範圍,解決各部門的問題。這將是性能和可靠性的最佳測試。我希望看到該系統能夠處理數兆筆記錄、數PB 資訊。
來源: www.habr.com