ที่ 1C เราใช้การพัฒนาของเราเองอย่างกว้างขวางเพื่อจัดระเบียบงานของบริษัท โดยเฉพาะอย่างยิ่ง, . นอกจากการจัดการเอกสาร (ตามชื่อแล้ว) ยังมีความทันสมัยอีกด้วย -system (การจัดการเนื้อหาองค์กร - การจัดการเนื้อหาองค์กร) พร้อมฟังก์ชันที่หลากหลาย - อีเมล ปฏิทินการทำงานของพนักงาน การจัดการการเข้าถึงทรัพยากรร่วมกัน (เช่น การจองห้องประชุม) การติดตามเวลา ฟอรัมองค์กร และอื่นๆ อีกมากมาย
พนักงานมากกว่าหนึ่งพันคนใช้การจัดการเอกสารที่ 1C ฐานข้อมูลกลายเป็นที่น่าประทับใจแล้ว (11 พันล้านบันทึก) ซึ่งหมายความว่าต้องได้รับการดูแลอย่างระมัดระวังและอุปกรณ์ที่ทรงพลังยิ่งขึ้น
ระบบของเราทำงานอย่างไร เราพบปัญหาอะไรบ้างในการบำรุงรักษาฐานข้อมูลและวิธีแก้ปัญหา (เราใช้ MS SQL Server เป็น DBMS) - เราจะบอกคุณในบทความ
สำหรับผู้ที่อ่านเกี่ยวกับผลิตภัณฑ์ 1C เป็นครั้งแรก
1C:Document Flow เป็นโซลูชันแอปพลิเคชัน (การกำหนดค่า) ที่ใช้งานบนพื้นฐานของกรอบงานสำหรับการพัฒนาแอปพลิเคชันทางธุรกิจ - แพลตฟอร์ม 1C:Enterprise
“ 1C: Document Flow 8” (ย่อว่า DO) ช่วยให้คุณทำงานกับเอกสารในองค์กรได้โดยอัตโนมัติ เครื่องมือหลักประการหนึ่งสำหรับการโต้ตอบของพนักงานคืออีเมล นอกจากเมลแล้ว DO ยังแก้ปัญหาอื่นๆ ด้วย:
- การติดตามเวลา
- การติดตามการขาดงานของพนักงาน
- แอปพลิเคชันสำหรับบริการจัดส่ง/ขนส่ง
- ปฏิทินการทำงานของพนักงาน
- การลงทะเบียนการติดต่อทางจดหมาย
- ข้อมูลติดต่อของพนักงาน (สมุดที่อยู่)
- ฟอรั่มองค์กร
- จองห้องพัก
- การวางแผนงาน
- CRM
- การทำงานร่วมกันกับไฟล์ (พร้อมการบันทึกเวอร์ชันไฟล์)
- เป็นต้น
เราเข้าสู่การจัดการเอกสาร (แอปพลิเคชันปฏิบัติการดั้งเดิม) จาก Windows, Linux, macOS, (จากเบราว์เซอร์) และ - ขึ้นอยู่กับสถานการณ์
และต้องขอบคุณผลิตภัณฑ์อื่น ๆ ของเราที่เชื่อมต่อกับ Document Flow - – เราได้รับฟังก์ชันการทำงานของ Messenger โดยตรงใน Document Flow – การแชท การโทรด้วยเสียงและวิดีโอ (รวมถึงการโทรแบบกลุ่ม ซึ่งขณะนี้มีความสำคัญเป็นพิเศษ รวมถึงจากไคลเอนต์มือถือ) การแลกเปลี่ยนไฟล์ที่รวดเร็วบวกกับความสามารถในการเขียนแชทบอทที่ทำให้ง่ายขึ้น ทำงานกับระบบ ข้อดีอีกประการหนึ่งของการใช้ระบบโต้ตอบ (เมื่อเปรียบเทียบกับโปรแกรมส่งข้อความอื่นๆ) คือความสามารถในการดำเนินการสนทนาตามบริบทที่เชื่อมโยงกับออบเจ็กต์ Document Flow เฉพาะ เช่น เอกสาร กิจกรรม ฯลฯ นั่นคือ ระบบโต้ตอบได้รับการบูรณาการอย่างลึกซึ้งกับแอปพลิเคชันเป้าหมาย และไม่ได้ทำหน้าที่เป็นเพียง "ปุ่มแยก"
จำนวนตัวอักษรใน DO ของเราเกิน 100 ล้านตัวแล้ว และโดยทั่วไปมีบันทึกมากกว่า 11 พันล้านรายการใน DBMS โดยรวมแล้ว ระบบใช้พื้นที่จัดเก็บเกือบ 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 คอร์, RAM 240 GB, ดิสก์ 26 TB นี่คือตารางเซิร์ฟเวอร์:
ในอนาคตเราวางแผนที่จะเพิ่มขีดความสามารถของอุปกรณ์
เกิดอะไรขึ้นกับการโหลดเซิร์ฟเวอร์?
กิจกรรมเครือข่ายไม่เคยเป็นปัญหาสำหรับเราหรือลูกค้าของเรา ตามกฎแล้วจุดอ่อนคือโปรเซสเซอร์และดิสก์เนื่องจากทุกคนรู้วิธีจัดการกับหน่วยความจำไม่เพียงพออยู่แล้ว นี่คือภาพหน้าจอของเซิร์ฟเวอร์ของเราจาก Resource Monitor ซึ่งแสดงให้เห็นว่าเราไม่มีภาระงานที่แย่มาก แต่ก็ค่อนข้างเรียบง่ายมาก
ตัวอย่างเช่น ในภาพหน้าจอด้านล่าง เราเห็นเซิร์ฟเวอร์ SQL ที่โหลด CPU อยู่ที่ 23% และนี่เป็นตัวบ่งชี้ที่ดีมาก (สำหรับการเปรียบเทียบ: หากภาระงานเข้าใกล้ 70% พนักงานส่วนใหญ่จะสังเกตเห็นการชะลอตัวในการทำงานอย่างมีนัยสำคัญ)
ภาพหน้าจอที่สองแสดงแอปพลิเคชันเซิร์ฟเวอร์ที่แพลตฟอร์ม 1C:Enterprise ทำงาน - ให้บริการเฉพาะเซสชันผู้ใช้เท่านั้น ที่นี่โหลดโปรเซสเซอร์สูงขึ้นเล็กน้อย - 38% มันราบรื่นและสงบ มีการโหลดดิสก์บ้าง แต่ก็ยอมรับได้
ภาพหน้าจอที่สามแสดงเซิร์ฟเวอร์ 1C:Enterprise อีกเครื่องหนึ่ง (เป็นเซิร์ฟเวอร์ที่สอง เรามีสองเซิร์ฟเวอร์ในคลัสเตอร์) เฉพาะอันก่อนหน้านี้ให้บริการผู้ใช้ และโรบ็อตก็ทำงานกับอันนี้ ตัวอย่างเช่น รับจดหมาย เอกสารเส้นทาง แลกเปลี่ยนข้อมูล คำนวณสิทธิ์ เป็นต้น กิจกรรมเบื้องหลังทั้งหมดนี้ทำงานเบื้องหลังประมาณ 90-100 งาน และเซิร์ฟเวอร์นี้โหลดหนักมาก - 88% แต่สิ่งนี้จะไม่ส่งผลกระทบต่อผู้คน และจะใช้ระบบอัตโนมัติทั้งหมดที่การจัดการเอกสารควรทำ
ตัวชี้วัดในการวัดประสิทธิภาพคืออะไร?
เรามีระบบย่อยที่จริงจังสร้างขึ้นในบริษัทในเครือของเราสำหรับการวัดตัวชี้วัดประสิทธิภาพและการคำนวณตัวชี้วัดต่างๆ นี่เป็นสิ่งจำเป็นเพื่อที่จะเข้าใจทั้งในปัจจุบันในเวลาและจากมุมมองทางประวัติศาสตร์ว่าเกิดอะไรขึ้นในระบบ อะไรแย่ลง อะไรกำลังดีขึ้น เครื่องมือตรวจสอบ - หน่วยเมตริกและการวัดเวลา - รวมอยู่ในการจัดส่งมาตรฐานของ "1C: Document Flow 8" หน่วยวัดจำเป็นต้องมีการปรับแต่งระหว่างการใช้งาน แต่กลไกนั้นถือเป็นมาตรฐาน
ตัวชี้วัดคือการวัดตัวชี้วัดทางธุรกิจต่างๆ ณ จุดใดจุดหนึ่ง (เช่น เวลาจัดส่งไปรษณีย์โดยเฉลี่ยคือ 10 นาที)
เมตริกตัวใดตัวหนึ่งแสดงจำนวนผู้ใช้ที่ใช้งานอยู่ในฐานข้อมูล โดยเฉลี่ยจะมี 1000-1400 ตัวในระหว่างวัน กราฟแสดงให้เห็นว่าในขณะที่จับภาพหน้าจอมีผู้ใช้งาน 2144 รายในฐานข้อมูล
มีการดำเนินการดังกล่าวมากกว่า 30 รายการ รายการอยู่ระหว่างการตัดรายการ
- เข้าสู่ระบบ
- ออกจากระบบ
- กำลังโหลดจดหมาย
- การเปลี่ยนแปลงความถูกต้องของวัตถุ
- การเปลี่ยนแปลงสิทธิ์การเข้าถึง
- การเปลี่ยนเรื่องของกระบวนการ
- การเปลี่ยนกลุ่มงานของวัตถุ
- การเปลี่ยนองค์ประกอบของชุดอุปกรณ์
- การเปลี่ยนไฟล์
- นำเข้าไฟล์
- ส่งทางไปรษณีย์
- การย้ายไฟล์
- การเปลี่ยนเส้นทางงาน
- การลงนามในลายเซ็นอิเล็กทรอนิกส์
- ค้นหาตามรายละเอียด
- ค้นหาข้อความแบบเต็ม
- กำลังรับไฟล์
- ขัดจังหวะกระบวนการ
- ทบทวน
- การถอดรหัส
- การลงทะเบียนเอกสาร
- การสแกน
- กำลังยกเลิกการทำเครื่องหมายการลบ
- การสร้างวัตถุ
- กำลังบันทึกลงดิสก์
- จุดเริ่มต้นของกระบวนการ
- การลบรายการบันทึกของผู้ใช้
- การลบลายเซ็นอิเล็กทรอนิกส์
- การตั้งค่าเครื่องหมายการลบ
- การเข้ารหัส
- ส่งออกโฟลเดอร์
สัปดาห์ก่อนกิจกรรมผู้ใช้โดยเฉลี่ยของเราเพิ่มขึ้นหนึ่งเท่าครึ่ง (แสดงเป็นสีแดงบนกราฟ) ซึ่งเป็นผลมาจากการเปลี่ยนผ่านของพนักงานส่วนใหญ่ไปทำงานจากระยะไกล (เนื่องจากกิจกรรมที่รู้จักกันดี) นอกจากนี้ จำนวนผู้ใช้งานเพิ่มขึ้น 3 เท่า (แสดงเป็นสีน้ำเงินในภาพหน้าจอ) เนื่องจากพนักงานเริ่มใช้โทรศัพท์มือถืออย่างแข็งขัน: ไคลเอนต์มือถือแต่ละรายสร้างการเชื่อมต่อกับเซิร์ฟเวอร์ โดยเฉลี่ยแล้ว พนักงานของเราแต่ละคนมีการเชื่อมต่อกับเซิร์ฟเวอร์ 2 ครั้ง
สำหรับเราในฐานะผู้ดูแลระบบ นี่เป็นสัญญาณว่าเราจำเป็นต้องใส่ใจกับปัญหาด้านประสิทธิภาพมากขึ้น และดูว่าสิ่งต่างๆ แย่ลงหรือไม่ แต่เราดูสิ่งนี้ตามพารามิเตอร์อื่น ตัวอย่างเช่น เวลาในการส่งอีเมลสำหรับการกำหนดเส้นทางภายในมีการเปลี่ยนแปลงอย่างไร (แสดงเป็นสีน้ำเงินในภาพหน้าจอด้านล่าง) เราเห็นว่าผันผวนจนถึงปีนี้ แต่ตอนนี้มีเสถียรภาพ - สำหรับเรานี่คือตัวบ่งชี้ว่าทุกอย่างเป็นไปตามระบบ
ตัวชี้วัดที่ใช้อีกประการหนึ่งสำหรับเราคือเวลารอโดยเฉลี่ยในการดาวน์โหลดจดหมายจากเซิร์ฟเวอร์อีเมล (แสดงเป็นสีแดงในภาพหน้าจอ) พูดคร่าวๆ ก็คือ จดหมายจะลอยอยู่บนอินเทอร์เน็ตนานแค่ไหนก่อนที่จะถึงพนักงานของเรา ภาพหน้าจอแสดงให้เห็นว่าเวลานี้ยังไม่มีการเปลี่ยนแปลงแต่อย่างใด มีเดือยแหลมที่แยกได้ - แต่ไม่เกี่ยวข้องกับความล่าช้า แต่ด้วยความจริงที่ว่าเวลาหายไปบนเมลเซิร์ฟเวอร์
หรือ ตัวอย่างเช่น เมตริกอื่น (แสดงเป็นสีน้ำเงินในภาพหน้าจอ) – อัปเดตตัวอักษรในโฟลเดอร์ การเปิดโฟลเดอร์เมลเป็นการดำเนินการทั่วไปและจำเป็นต้องดำเนินการอย่างรวดเร็ว เราวัดว่าดำเนินการได้เร็วแค่ไหน ตัวบ่งชี้นี้วัดสำหรับลูกค้าแต่ละราย คุณสามารถดูทั้งภาพรวมของบริษัทและการเปลี่ยนแปลง เช่น สำหรับพนักงานแต่ละคน ภาพหน้าจอแสดงให้เห็นว่าจนถึงปีนี้ ตัวชี้วัดยังไม่สมดุล จากนั้นเราได้ทำการปรับปรุงหลายประการ และตอนนี้ก็ไม่ได้แย่ลงไปกว่านี้อีกแล้ว - กราฟเกือบจะราบเรียบ
โดยพื้นฐานแล้ว ตัวชี้วัดเป็นเครื่องมือของผู้ดูแลระบบในการตรวจสอบระบบ เพื่อตอบสนองต่อการเปลี่ยนแปลงพฤติกรรมของระบบอย่างรวดเร็ว ภาพหน้าจอแสดงการวัดย่อยภายในสำหรับปี การเพิ่มขึ้นอย่างรวดเร็วของกราฟเกิดจากการที่เราได้รับมอบหมายงานในการพัฒนาบริษัทในเครือภายใน
นี่คือรายการเมตริกเพิ่มเติมบางส่วน (อยู่ระหว่างการตัด)
เมตริก
- กิจกรรมของผู้ใช้
- ผู้ใช้ที่ใช้งานอยู่
- กระบวนการที่ใช้งานอยู่
- จำนวนไฟล์
- ขนาดไฟล์ (MB)
- จำนวนเอกสาร
- จำนวนออบเจ็กต์ที่จะส่งถึงผู้รับ
- จำนวนคู่สัญญา
- งานที่ยังไม่เสร็จ
- เวลารอโดยเฉลี่ยในการดาวน์โหลดอีเมลจากเซิร์ฟเวอร์เมลในช่วง 10 นาทีที่ผ่านมา
- บัฟเฟอร์ข้อมูลภายนอก: จำนวนไฟล์
- ล้าหลังจากวันที่ปัจจุบัน
- คิวยาว
- คิวปฏิบัติการ
- อายุบัญชี Raw ตามการกำหนดเส้นทางภายนอก
- ขนาดคิวการยอมรับการกำหนดเส้นทางภายใน (คิวยาว)
- ขนาดคิวการยอมรับการกำหนดเส้นทางภายใน (คิวด่วน)
- เวลาส่งเมลผ่านเส้นทางภายใน (คิวยาว)
- เวลาส่งไปรษณีย์ผ่านเส้นทางภายใน (คิวเร็ว)
- เวลาส่งเมลผ่านเส้นทางภายนอก (โดยเฉลี่ย)
- จำนวนเอกสารการจอง
- จำนวนเอกสารที่ขาด
- จำนวนเอกสาร “บันทึกการทำงานร่วมกับคู่สัญญา”
- Mail Update จดหมายในโฟลเดอร์
- จดหมาย การเปิดบัตรจดหมาย
- เมล โอนจดหมายไปยังโฟลเดอร์
- Mail นำทางผ่านโฟลเดอร์
ระบบของเราวัดตัวบ่งชี้มากกว่า 150 ตัวตลอดเวลา แต่ไม่ใช่ทั้งหมดที่จะสามารถตรวจสอบได้อย่างรวดเร็ว อาจมีประโยชน์ในภายหลังในมุมมองทางประวัติศาสตร์ และคุณสามารถมุ่งเน้นไปที่สิ่งที่สำคัญที่สุดสำหรับธุรกิจได้
ตัวอย่างเช่นในการใช้งานประการหนึ่ง มีการเลือกตัวบ่งชี้เพียง 5 ตัวเท่านั้น ลูกค้าตั้งเป้าหมายในการสร้างชุดตัวบ่งชี้ขั้นต่ำ แต่ในขณะเดียวกันก็ครอบคลุมสถานการณ์การทำงานหลักด้วย การรวมตัวบ่งชี้ 150 รายการไว้ในใบรับรองการยอมรับจะไม่ยุติธรรมเพราะแม้แต่ภายในองค์กรก็ยากที่จะตกลงกันว่าตัวบ่งชี้ใดที่ถือว่าเป็นที่ยอมรับ และได้ทราบตัวบ่งชี้ทั้ง 5 ตัวนี้แล้ว และได้นำเสนอต่อระบบแล้วก่อนเริ่มโครงการดำเนินงาน รวมทั้งในเอกสารประกอบการแข่งขัน ได้แก่ เวลาเปิดการ์ดไม่เกิน 3 วินาที เวลาในการทำงานให้เสร็จสิ้นด้วยไฟล์หมายเลข มากกว่า 5 วินาที ฯลฯ ในบริษัทสาขาของเรา เรามีหน่วยวัดที่สะท้อนคำขอเริ่มแรกจากข้อกำหนดทางเทคนิคของลูกค้าอย่างชัดเจน
นอกจากนี้เรายังมีการวิเคราะห์โปรไฟล์ของการวัดประสิทธิภาพอีกด้วย ตัวบ่งชี้ประสิทธิภาพคือการบันทึกระยะเวลาของการดำเนินการที่กำลังดำเนินอยู่แต่ละครั้ง (การเขียนจดหมายไปยังฐานข้อมูล การส่งจดหมายไปยังเซิร์ฟเวอร์อีเมล ฯลฯ) สิ่งนี้ถูกใช้โดยช่างเทคนิคเท่านั้น เราสะสมตัวชี้วัดประสิทธิภาพไว้มากมายในโปรแกรมของเรา ขณะนี้เราวัดการดำเนินงานหลักประมาณ 1500 รายการ ซึ่งแบ่งออกเป็นโปรไฟล์
หนึ่งในโปรไฟล์ที่สำคัญที่สุดสำหรับเราคือ “รายการตัวบ่งชี้สำคัญของจดหมายจากมุมมองของผู้บริโภค” โปรไฟล์นี้รวมถึงตัวบ่งชี้ดังต่อไปนี้:
- การดำเนินการคำสั่ง: เลือกตามแท็ก
- การเปิดแบบฟอร์ม: แบบฟอร์มรายการ
- การดำเนินการคำสั่ง: เลือกตามโฟลเดอร์
- การแสดงตัวอักษรในพื้นที่อ่านหนังสือ
- บันทึกจดหมายลงในโฟลเดอร์ที่คุณชื่นชอบ
- ค้นหาตัวอักษรตามรายละเอียด
- การสร้างจดหมาย
หากเราเห็นว่าตัวชี้วัดสำหรับตัวบ่งชี้ธุรกิจบางตัวมีขนาดใหญ่เกินไป (เช่น จดหมายจากผู้ใช้รายใดรายหนึ่งเริ่มมาถึงเป็นเวลานานมาก) เราจะเริ่มคิดออกและหันไปวัดเวลาของการดำเนินการทางเทคนิค เรามีการดำเนินการด้านเทคนิค "การเก็บถาวรจดหมายบนเซิร์ฟเวอร์อีเมล" - เราเห็นว่าเกินเวลาสำหรับการดำเนินการนี้ในช่วงสุดท้าย การดำเนินการนี้จะถูกแยกย่อยเป็นการดำเนินการอื่น ตัวอย่างเช่น การสร้างการเชื่อมต่อกับเซิร์ฟเวอร์อีเมล เราเห็นว่าจู่ๆ ก็มีขนาดใหญ่ขึ้นด้วยเหตุผลบางอย่าง (เรามีการวัดทั้งหมดเป็นเวลาหนึ่งเดือน - เราสามารถเปรียบเทียบได้ว่าสัปดาห์ที่แล้วคือ 10 มิลลิวินาที และตอนนี้คือ 1000 มิลลิวินาที) และเราเข้าใจว่ามีบางอย่างเสียหายที่นี่ - เราต้องแก้ไขมัน
เราจะรักษาฐานข้อมูลขนาดใหญ่เช่นนี้ได้อย่างไร?
DO ภายในของเราเป็นตัวอย่างหนึ่งของโครงการที่มีภาระงานสูงที่ใช้งานได้จริง เรามาพูดถึงคุณสมบัติทางเทคนิคของฐานข้อมูลกันดีกว่า
การปรับโครงสร้างตารางฐานข้อมูลขนาดใหญ่ใช้เวลานานเท่าใด
เซิร์ฟเวอร์ SQL ต้องการการบำรุงรักษาเป็นระยะ โดยจัดตารางให้เป็นระเบียบ ในทางที่ดี ควรทำอย่างน้อยวันละครั้ง และบ่อยกว่านั้นสำหรับโต๊ะที่มีความต้องการสูง แต่หากฐานข้อมูลมีขนาดใหญ่ (และจำนวนบันทึกของเรามีเกิน 11 พันล้านรายการแล้ว) การดูแลก็ไม่ใช่เรื่องง่าย
เราทำการปรับโครงสร้างตารางเมื่อ 6 ปีที่แล้ว แต่แล้วมันก็เริ่มใช้เวลานานมากจนเราไม่สามารถเข้ากับช่วงเวลากลางคืนได้อีกต่อไป และเนื่องจากการดำเนินการเหล่านี้โหลดเซิร์ฟเวอร์ SQL จำนวนมาก จึงไม่สามารถให้บริการผู้ใช้รายอื่นได้อย่างมีประสิทธิภาพ
ดังนั้นตอนนี้เราเลยต้องใช้ลูกเล่นต่างๆ ตัวอย่างเช่น เราไม่สามารถดำเนินการตามขั้นตอนเหล่านี้กับชุดข้อมูลที่สมบูรณ์ได้ คุณต้องหันไปใช้กระบวนงานอัปเดตตัวอย่าง 500000 แถว - ใช้เวลา 14 นาที จะไม่อัปเดตสถิติของข้อมูลทั้งหมดในตาราง แต่จะเลือกครึ่งล้านแถวแล้วใช้เพื่อคำนวณสถิติที่ใช้สำหรับทั้งตาราง นี่เป็นข้อสันนิษฐานบางประการ แต่เราถูกบังคับให้ทำ เนื่องจากสำหรับตารางใดตารางหนึ่ง การรวบรวมสถิติจากบันทึกทั้งพันล้านรายการจะใช้เวลานานอย่างไม่อาจยอมรับได้
นอกจากนี้เรายังเพิ่มประสิทธิภาพการดำเนินการบำรุงรักษาอื่นๆ ด้วยการทำให้เป็นบางส่วน
โดยทั่วไปการบำรุงรักษา DBMS นั้นเป็นงานที่ซับซ้อน ในกรณีที่มีการโต้ตอบกันระหว่างพนักงาน ฐานข้อมูลจะเติบโตอย่างรวดเร็ว และผู้ดูแลระบบจะดูแลรักษาได้ยากขึ้น เช่น อัปเดตสถิติ การจัดเรียงข้อมูล การจัดทำดัชนี ที่นี่เราจำเป็นต้องใช้กลยุทธ์ที่แตกต่างกัน เรารู้ดีว่าต้องทำอย่างไร เรามีประสบการณ์ เราสามารถแบ่งปันได้
การสำรองข้อมูลมีการใช้งานกับวอลุ่มดังกล่าวอย่างไร
การสำรองข้อมูล DBMS แบบเต็มจะดำเนินการวันละครั้งในเวลากลางคืน โดยเพิ่มขึ้นทุกๆ ชั่วโมง นอกจากนี้ ไดเร็กทอรีไฟล์จะถูกสร้างขึ้นทุกวัน และเป็นส่วนหนึ่งของการสำรองข้อมูลส่วนเพิ่มของพื้นที่จัดเก็บไฟล์
การสำรองข้อมูลทั้งหมดจะใช้เวลานานเท่าใด?
การสำรองข้อมูลทั้งหมดไปยังฮาร์ดไดรฟ์จะเสร็จสิ้นภายในสามชั่วโมง และการสำรองข้อมูลบางส่วนภายในหนึ่งชั่วโมง การเขียนลงเทปจะใช้เวลานานกว่า (อุปกรณ์พิเศษที่ทำสำเนาสำรองลงในเทปคาสเซ็ตพิเศษที่เก็บไว้นอกสำนักงาน สำเนาที่ถ่ายโอนได้จะถูกสร้างขึ้นบนเทป ซึ่งจะถูกเก็บรักษาไว้ เช่น ในกรณีที่ ห้องเซิร์ฟเวอร์เกิดไฟไหม้) การสำรองข้อมูลเกิดขึ้นบนเซิร์ฟเวอร์เดียวกันทุกประการซึ่งมีพารามิเตอร์ที่สูงกว่า - เซิร์ฟเวอร์ SQL ที่มีโหลดตัวประมวลผล 20% แน่นอนว่าในขณะที่ทำการสำรองข้อมูล ระบบจะแย่ลงมาก แต่ก็ยังใช้งานได้อยู่
มีการขจัดข้อมูลซ้ำซ้อนหรือไม่?
มีไฟล์อยู่มากมาย เราจะทดสอบด้วยตัวเอง และเร็วๆ นี้มันจะรวมอยู่ในการจัดการเอกสารเวอร์ชันใหม่ เรากำลังทดสอบกลไกการขจัดข้อมูลซ้ำซ้อนของคู่สัญญาด้วย ไม่มีการขจัดข้อมูลซ้ำซ้อนของบันทึกในระดับ DBMS เนื่องจากไม่จำเป็น แพลตฟอร์ม 1C:Enterprise จัดเก็บอ็อบเจ็กต์ไว้ใน DBMS และมีเพียงแพลตฟอร์มเท่านั้นที่สามารถรับผิดชอบต่อความสอดคล้องของวัตถุได้
มีโหนดแบบอ่านอย่างเดียวหรือไม่
ไม่มีโหนดการอ่าน (โหนดระบบเฉพาะที่ให้บริการผู้ที่ต้องการรับข้อมูลสำหรับการอ่าน) DO ไม่ใช่ระบบบัญชีที่จะวางบนโหนด BI แยกต่างหาก แต่มีโหนดแยกต่างหากสำหรับแผนกพัฒนา ซึ่งมีการแลกเปลี่ยนข้อความในรูปแบบ JSON และเวลาการจำลองโดยทั่วไปคือหน่วยและสิบวินาที โหนดยังเล็ก มีบันทึกประมาณ 800 ล้านรายการ แต่มีการเติบโตอย่างรวดเร็ว
อีเมลที่ถูกทำเครื่องหมายเพื่อลบจะไม่ถูกลบเลยใช่ไหม
ยัง. เราไม่มีภารกิจในการทำให้ฐานสว่างขึ้น มีหลายกรณีที่ค่อนข้างร้ายแรงเมื่อจำเป็นต้องอ้างถึงตัวอักษรที่ถูกทำเครื่องหมายเพื่อลบ รวมถึงปี 2009 ด้วย นั่นเป็นเหตุผลที่เราตัดสินใจเก็บทุกอย่างไว้ก่อนตอนนี้ แต่เมื่อต้นทุนนี้ไม่ยุติธรรม เราจะคิดถึงการกำจัด แต่ถ้าคุณต้องการลบจดหมายแยกต่างหากออกจากฐานข้อมูลโดยสมบูรณ์เพื่อไม่ให้มีร่องรอยก็สามารถทำได้โดยการร้องขอพิเศษ
เก็บไว้ทำไม? คุณมีสถิติการเข้าถึงเอกสารเก่าหรือไม่?
ไม่มีสถิติ แม่นยำยิ่งขึ้นคืออยู่ในรูปแบบของบันทึกผู้ใช้ แต่จะเก็บไว้ได้ไม่นาน รายการที่เก่ากว่าหนึ่งปีจะถูกลบออกจากโปรโตคอล
มีสถานการณ์ที่จำเป็นต้องเรียกคืนจดหมายเก่าเมื่อห้าหรือสิบปีก่อน และสิ่งนี้ไม่ได้ทำด้วยความอยากรู้อยากเห็น แต่เพื่อการตัดสินใจทางธุรกิจที่ซับซ้อน มีกรณีที่หากไม่มีประวัติการติดต่อทางจดหมาย อาจเกิดการตัดสินใจทางธุรกิจที่ผิดพลาดได้
มูลค่าของเอกสารประเมินและทำลายตามระยะเวลาการจัดเก็บอย่างไร
สำหรับเอกสารที่เป็นกระดาษ ขั้นตอนนี้จะกระทำในวิธีดั้งเดิมตามปกติ เช่นเดียวกับคนอื่นๆ เราไม่ทำเพื่ออุปกรณ์อิเล็กทรอนิกส์ - ปล่อยให้พวกเขาเก็บไว้ใช้เอง ที่นั่งอยู่ที่นี่ มีประโยชน์มากมาย ทุกคนสบายดี
มีแนวโน้มการพัฒนาอะไรบ้าง?
ตอนนี้ DO ของเราจะแก้ไขปัญหาภายในได้ประมาณ 30 ปัญหา ซึ่งบางปัญหาเราได้ระบุไว้ในตอนต้นของบทความ DL ยังใช้เพื่อเตรียมการประชุมที่เราจัดขึ้นปีละสองครั้งสำหรับพันธมิตรของเรา: โปรแกรมทั้งหมด, รายงานทั้งหมด, ส่วนคู่ขนานทั้งหมด, ห้องโถง - ทั้งหมดนี้พิมพ์ลงใน DL จากนั้นดาวน์โหลดจากนั้น และโปรแกรมที่พิมพ์ออกมา ทำ.
ยังมีงานอื่นๆ อีกหลายอย่างในการดำเนินการสำหรับ DO นอกเหนือจากงานที่ได้รับการแก้ไขแล้ว มีงานทั่วทั้งบริษัท และมีงานพิเศษและหายากซึ่งจำเป็นสำหรับแผนกใดแผนกหนึ่งเท่านั้น จำเป็นต้องช่วยเหลือพวกเขาซึ่งหมายถึงการขยาย "ภูมิศาสตร์" ของการใช้ระบบภายใน 1C - ขยายขอบเขตการใช้งานแก้ไขปัญหาของทุกแผนก นี่จะเป็นการทดสอบประสิทธิภาพและความน่าเชื่อถือที่ดีที่สุด ฉันอยากเห็นระบบทำงานกับบันทึกนับล้านล้านรายการ หรือข้อมูลหลายเพตะไบต์
ที่มา: will.com