6 คอขวดที่ซ่อนอยู่ในการย้ายข้อมูลบนคลาวด์

Seth Noble เป็นผู้ก่อตั้งและประธานของ Data Expedition

การย้ายข้อมูลเทราไบต์หรือแม้แต่เพตาไบต์ไปยังระบบคลาวด์เป็นงานที่น่ากลัว แต่สิ่งสำคัญคือต้องมองให้ไกลกว่าจำนวนไบต์ คุณอาจทราบว่าแอปพลิเคชันของคุณจะทำงานแตกต่างกันเมื่อเข้าถึงในระบบคลาวด์โครงสร้างต้นทุนนั้นจะแตกต่างกัน (หวังว่าจะดีกว่านี้) และจะต้องใช้เวลาในการย้ายข้อมูลทั้งหมดนั้น

เนื่องจาก บริษัท ของฉัน Data Expedition อยู่ในธุรกิจการถ่ายโอนข้อมูลประสิทธิภาพสูงลูกค้าจึงมาหาเราเมื่อคาดว่าความเร็วเครือข่ายจะมีปัญหา แต่ในกระบวนการช่วย บริษัท ต่างๆให้เอาชนะปัญหานั้นเราได้เห็นปัจจัยอื่น ๆ อีกมากมายที่คุกคามต่อการโยกย้ายระบบคลาวด์หากมองข้ามไป

การรวบรวมจัดระเบียบจัดรูปแบบและตรวจสอบความถูกต้องของข้อมูลของคุณสามารถนำเสนอความท้าทายที่ยิ่งใหญ่กว่าการย้ายข้อมูล ต่อไปนี้เป็นปัจจัยทั่วไปที่ควรพิจารณาในขั้นตอนการวางแผนของการย้ายระบบคลาวด์เพื่อให้คุณหลีกเลี่ยงปัญหาที่ใช้เวลานานและมีราคาแพงในภายหลังได้

คอขวดการย้ายระบบคลาวด์ # 1: การจัดเก็บข้อมูล

ข้อผิดพลาดที่พบบ่อยที่สุดที่เราเห็นในการย้ายข้อมูลบนคลาวด์คือการผลักข้อมูลไปยังที่เก็บข้อมูลบนคลาวด์โดยไม่พิจารณาว่าจะใช้ข้อมูลนั้นอย่างไร กระบวนการคิดโดยทั่วไปคือ“ ฉันต้องการวางเอกสารและฐานข้อมูลไว้ในระบบคลาวด์และพื้นที่เก็บข้อมูลวัตถุมีราคาถูกดังนั้นฉันจะใส่เอกสารและไฟล์ฐานข้อมูลไว้ที่นั่น” แต่ไฟล์วัตถุและฐานข้อมูลทำงานแตกต่างกันมาก การใส่ไบต์ของคุณผิดอาจทำให้แผนระบบคลาวด์ของคุณเสียหายได้

ไฟล์ถูกจัดระเบียบตามลำดับชั้นของพา ธ ซึ่งเป็นแผนผังไดเร็กทอรี แต่ละไฟล์สามารถเข้าถึงได้อย่างรวดเร็วโดยมีเวลาแฝงน้อยที่สุด (เวลาถึงไบต์แรก) และความเร็วสูง (บิตต่อวินาทีเมื่อข้อมูลเริ่มไหล) ไฟล์แต่ละไฟล์สามารถย้ายเปลี่ยนชื่อและเปลี่ยนแปลงได้อย่างง่ายดายจนถึงระดับไบต์ คุณสามารถมีไฟล์ขนาดเล็กจำนวนมากไฟล์ขนาดใหญ่จำนวนน้อยหรือขนาดและประเภทข้อมูลผสมกันได้ แอปพลิเคชันแบบเดิมสามารถเข้าถึงไฟล์ในระบบคลาวด์ได้เช่นเดียวกับในองค์กรโดยไม่ต้องมีการรับรู้ระบบคลาวด์เป็นพิเศษ

ข้อดีทั้งหมดนี้ทำให้การจัดเก็บไฟล์เป็นตัวเลือกที่แพงที่สุด แต่การจัดเก็บไฟล์ในระบบคลาวด์มีข้อเสียอื่น ๆ อีกเล็กน้อย เพื่อให้ได้ประสิทธิภาพสูงระบบไฟล์บนคลาวด์ส่วนใหญ่ (เช่น Amazon EBS) สามารถเข้าถึงได้โดยเครื่องเสมือนบนคลาวด์เพียงเครื่องเดียวในแต่ละครั้งซึ่งหมายความว่าแอปพลิเคชันทั้งหมดที่ต้องการข้อมูลนั้นจะต้องทำงานบน VM บนคลาวด์เดียว ในการให้บริการ VM หลายเครื่อง (เช่น Azure Files) จำเป็นต้องมีการจัดเก็บข้อมูลด้วยโปรโตคอล NAS (ที่เก็บข้อมูลที่เชื่อมต่อกับเครือข่าย) เช่น SMB ซึ่งอาจ จำกัด ประสิทธิภาพอย่างมาก ระบบไฟล์มีความรวดเร็วยืดหยุ่นและเข้ากันได้กับระบบเดิม แต่มีราคาแพงมีประโยชน์เฉพาะกับแอปพลิเคชันที่ทำงานในระบบคลาวด์และปรับขนาดได้ไม่ดี

วัตถุไม่ใช่ไฟล์ จำไว้เพราะมันลืมง่าย ออบเจ็กต์อาศัยอยู่ในเนมสเปซแบบแบนเช่นไดเร็กทอรีขนาดยักษ์ เวลาในการตอบสนองสูงบางครั้งหลายร้อยหรือหลายพันมิลลิวินาทีและปริมาณงานต่ำโดยมักจะเพิ่มขึ้นประมาณ 150 เมกะบิตต่อวินาทีเว้นแต่จะใช้กลอุบายที่ชาญฉลาด หลายอย่างเกี่ยวกับการเข้าถึงวัตถุมาพร้อมกับเทคนิคที่ชาญฉลาดเช่นการอัปโหลดหลายส่วนการเข้าถึงช่วงไบต์และการเพิ่มประสิทธิภาพชื่อคีย์ อ็อบเจ็กต์สามารถอ่านได้โดยแอพพลิเคชั่นบนคลาวด์เนทีฟและบนเว็บพร้อมกันทั้งจากภายในและภายนอกคลาวด์ แต่แอพพลิเคชั่นแบบเดิมต้องการวิธีแก้ปัญหาที่ทำให้ประสิทธิภาพการทำงานหมดไป อินเทอร์เฟซส่วนใหญ่สำหรับการเข้าถึงที่เก็บอ็อบเจ็กต์ทำให้อ็อบเจ็กต์ดูเหมือนไฟล์: ชื่อคีย์จะถูกกรองโดยคำนำหน้าเพื่อให้ดูเหมือนโฟลเดอร์, เมทาดาทาที่กำหนดเองจะถูกแนบกับอ็อบเจ็กต์เพื่อให้ดูเหมือนข้อมูลเมตาของไฟล์,และบางระบบเช่น FUSE cache object บนระบบไฟล์ VM เพื่อให้แอปพลิเคชันแบบเดิมเข้าถึงได้ แต่วิธีแก้ปัญหาดังกล่าวมีความเปราะและประสิทธิภาพที่ดี ที่เก็บข้อมูลบนคลาวด์มีราคาถูกปรับขนาดได้และระบบคลาวด์เนทีฟ แต่ก็ช้าและเข้าถึงยากเช่นกัน

ฐานข้อมูลมีโครงสร้างที่ซับซ้อนเป็นของตัวเองและเข้าถึงได้โดยภาษาแบบสอบถามเช่น SQL ฐานข้อมูลแบบดั้งเดิมอาจได้รับการสนับสนุนโดยการจัดเก็บไฟล์ แต่ต้องใช้กระบวนการฐานข้อมูลแบบสดเพื่อตอบสนองการสืบค้น สิ่งนี้สามารถยกขึ้นสู่ระบบคลาวด์ได้โดยการคัดลอกไฟล์ฐานข้อมูลและแอปพลิเคชันไปยัง VM หรือโดยการย้ายข้อมูลไปยังบริการฐานข้อมูลบนคลาวด์ แต่การคัดลอกไฟล์ฐานข้อมูลไปยังที่จัดเก็บอ็อบเจ็กต์จะมีประโยชน์ในการสำรองข้อมูลแบบออฟไลน์เท่านั้น ฐานข้อมูลปรับขนาดและเป็นส่วนหนึ่งของบริการที่โฮสต์บนคลาวด์ แต่สิ่งสำคัญคือต้องตรวจสอบให้แน่ใจว่าแอปพลิเคชันและกระบวนการที่ขึ้นอยู่กับฐานข้อมูลนั้นเข้ากันได้อย่างสมบูรณ์และเป็นระบบคลาวด์ การจัดเก็บฐานข้อมูลมีความเชี่ยวชาญสูงและเฉพาะแอปพลิเคชัน

การปรับสมดุลการประหยัดต้นทุนที่ชัดเจนของพื้นที่จัดเก็บอ็อบเจ็กต์เทียบกับการทำงานของไฟล์และฐานข้อมูลจำเป็นต้องพิจารณาอย่างรอบคอบว่าฟังก์ชันใดที่จำเป็นต้องใช้ ตัวอย่างเช่นหากคุณต้องการจัดเก็บและแจกจ่ายไฟล์ขนาดเล็กจำนวนมากให้เก็บถาวรเป็นไฟล์ ZIP และจัดเก็บเป็นวัตถุเดียวแทนที่จะพยายามจัดเก็บไฟล์แต่ละไฟล์เป็นวัตถุแยกกัน ตัวเลือกการจัดเก็บที่ไม่ถูกต้องอาจนำไปสู่การอ้างอิงที่ซับซ้อนซึ่งยากและมีราคาแพงในการเปลี่ยนแปลงในภายหลัง

คอขวดการย้ายระบบคลาวด์ # 2: การเตรียมข้อมูล

การย้ายข้อมูลไปยังระบบคลาวด์ไม่ง่ายเหมือนการคัดลอกไบต์ไปยังประเภทพื้นที่จัดเก็บที่กำหนด ต้องมีการเตรียมการมากมายก่อนที่จะลอกเลียนแบบและเวลานั้นต้องใช้งบประมาณอย่างรอบคอบ โครงการพิสูจน์แนวคิดมักเพิกเฉยต่อขั้นตอนนี้ซึ่งอาจนำไปสู่การหักล้างค่าใช้จ่ายในภายหลัง

การกรองข้อมูลที่ไม่จำเป็นออกจะช่วยประหยัดเวลาและต้นทุนในการจัดเก็บได้มาก ตัวอย่างเช่นชุดข้อมูลอาจมีการสำรองข้อมูลเวอร์ชันก่อนหน้าหรือไฟล์ขูดที่ไม่จำเป็นต้องเป็นส่วนหนึ่งของเวิร์กโฟลว์ระบบคลาวด์ บางทีส่วนที่สำคัญที่สุดของการกรองคือการจัดลำดับความสำคัญของข้อมูลที่ต้องย้ายก่อน ข้อมูลที่มีการใช้งานอยู่จะไม่ยอมให้มีการซิงค์ไม่ได้ภายในสัปดาห์เดือนหรือปีที่ใช้ในการดำเนินการย้ายข้อมูลทั้งหมด กุญแจสำคัญในที่นี้คือการใช้วิธีการอัตโนมัติในการเลือกว่าจะส่งข้อมูลใดและเมื่อใดจากนั้นเก็บบันทึกอย่างรอบคอบเกี่ยวกับทุกสิ่งที่มีและไม่ได้ทำ

เวิร์กโฟลว์ระบบคลาวด์ที่แตกต่างกันอาจต้องการให้ข้อมูลอยู่ในรูปแบบหรือองค์กรที่แตกต่างจากแอปพลิเคชันในองค์กร ตัวอย่างเช่นเวิร์กโฟลว์ทางกฎหมายอาจต้องมีการแปลเอกสาร Word หรือ PDF ขนาดเล็กหลายพันรายการและบรรจุในไฟล์ ZIP เวิร์กโฟลว์สื่ออาจเกี่ยวข้องกับการแปลงรหัสและการบรรจุข้อมูลเมตาและขั้นตอนการทำงานด้านชีวสารสนเทศอาจต้องมีการเลือกและจัดเตรียมข้อมูลจีโนมิกระดับเทราไบต์ การจัดรูปแบบดังกล่าวอาจเป็นกระบวนการที่ต้องใช้เวลามากและต้องใช้เวลานาน อาจต้องใช้การทดลองจำนวนมากพื้นที่เก็บข้อมูลชั่วคราวจำนวนมากและการจัดการข้อยกเว้นจำนวนมาก บางครั้งอาจเป็นเรื่องที่อยากจะเลื่อนการจัดรูปแบบใหม่ไปยังสภาพแวดล้อมระบบคลาวด์ แต่อย่าลืมว่าวิธีนี้ไม่สามารถแก้ปัญหาได้ แต่เพียงแค่เปลี่ยนให้เป็นสภาพแวดล้อมที่ทรัพยากรทั้งหมดที่คุณใช้มีราคา

คำถามส่วนหนึ่งของการจัดเก็บและการจัดรูปแบบอาจเกี่ยวข้องกับการตัดสินใจเกี่ยวกับการบีบอัดและการเก็บถาวร ตัวอย่างเช่นควร ZIP ไฟล์ข้อความขนาดเล็กหลายล้านไฟล์ก่อนที่จะส่งไปยังระบบคลาวด์ แต่ไม่ใช่ไฟล์สื่อที่มีขนาดหลายกิกะไบต์ การเก็บถาวรและการบีบอัดข้อมูลช่วยให้ถ่ายโอนและจัดเก็บข้อมูลได้ง่ายขึ้น แต่ต้องคำนึงถึงเวลาและพื้นที่จัดเก็บที่ใช้ในการแพ็คและคลายไฟล์ที่เก็บถาวรเหล่านั้นเมื่อสิ้นสุด

คอขวดการย้ายระบบคลาวด์ # 3: การตรวจสอบข้อมูล

การตรวจสอบความถูกต้องเป็นขั้นตอนเดียวที่สำคัญที่สุดและยังผิดพลาดได้ง่ายที่สุด บ่อยครั้งที่มีการสันนิษฐานว่าความเสียหายจะเกิดขึ้นระหว่างการขนส่งข้อมูลไม่ว่าจะเกิดจากสื่อทางกายภาพหรือการถ่ายโอนเครือข่ายและสามารถตรวจจับได้โดยการดำเนินการเช็คซัมก่อนและหลัง Checksums เป็นส่วนสำคัญของกระบวนการนี้ แต่จริงๆแล้วเป็นการเตรียมและนำเข้าข้อมูลที่คุณมีแนวโน้มว่าจะสูญเสียหรือเสียหายมากที่สุด

เมื่อข้อมูลมีการเปลี่ยนรูปแบบและแอปพลิเคชันความหมายและฟังก์ชันการทำงานอาจสูญหายไปแม้ว่าไบต์จะเหมือนกัน ความเข้ากันไม่ได้อย่างง่าย ๆ ระหว่างเวอร์ชันซอฟต์แวร์อาจทำให้ข้อมูล "ถูกต้อง" เพตาไบต์ไม่มีประโยชน์ การสร้างกระบวนการที่ปรับขนาดได้เพื่อตรวจสอบว่าข้อมูลของคุณทั้งถูกต้องและใช้งานได้อาจเป็นงานที่น่ากลัว อย่างเลวร้ายที่สุดก็อาจกลายเป็นกระบวนการที่ต้องใช้แรงงานมากและไม่ชัดเจนในเรื่อง“ มันดูโอเคสำหรับฉัน” แต่ถึงอย่างนั้นก็ดีกว่าไม่มีการตรวจสอบความถูกต้องเลย สิ่งที่สำคัญที่สุดคือเพื่อให้แน่ใจว่าคุณจะสามารถรับรู้ปัญหาก่อนที่ระบบเดิมจะเลิกใช้งาน!

คอขวดการย้ายระบบคลาวด์ # 4: โอนย้ายมาร์แชล

เมื่อยกระบบเดียวไปยังคลาวด์มันค่อนข้างง่ายเพียงแค่คัดลอกข้อมูลที่เตรียมไว้ไปยังสื่อทางกายภาพหรือส่งผ่านอินเทอร์เน็ต แต่กระบวนการนี้สามารถปรับขนาดได้ยากโดยเฉพาะอย่างยิ่งสำหรับสื่อทางกายภาพ สิ่งที่ดูเหมือน“ เรียบง่าย” ในแนวคิดที่พิสูจน์ได้สามารถทำให้เกิด“ ฝันร้าย” ได้เมื่อมีระบบมากมายและหลากหลายเข้ามามีบทบาท

ต้องเชื่อมต่ออุปกรณ์สื่อเช่น AWS Snowball กับแต่ละเครื่อง นั่นอาจหมายถึงการเดินอุปกรณ์ไปรอบ ๆ ศูนย์ข้อมูลอย่างน้อยหนึ่งศูนย์การเล่นกลตัวเชื่อมต่อการอัปเดตไดรเวอร์และการติดตั้งซอฟต์แวร์ การเชื่อมต่อผ่านเครือข่ายท้องถิ่นจะช่วยประหยัดการเคลื่อนไหวทางกายภาพ แต่การตั้งค่าซอฟต์แวร์ยังคงเป็นเรื่องที่ท้าทายและความเร็วในการคัดลอกอาจลดลงจนต่ำกว่าสิ่งที่สามารถทำได้ด้วยการอัปโหลดทางอินเทอร์เน็ตโดยตรง การถ่ายโอนข้อมูลโดยตรงจากแต่ละเครื่องผ่านอินเทอร์เน็ตจะช่วยประหยัดขั้นตอนได้มากโดยเฉพาะอย่างยิ่งหากข้อมูลนั้นพร้อมใช้งานบนคลาวด์

หากการเตรียมข้อมูลเกี่ยวข้องกับการคัดลอกการส่งออกการจัดรูปแบบใหม่หรือการเก็บถาวรการจัดเก็บข้อมูลในเครื่องอาจกลายเป็นปัญหาคอขวด อาจจำเป็นต้องตั้งค่าพื้นที่จัดเก็บเฉพาะเพื่อจัดเตรียมข้อมูลที่เตรียมไว้ สิ่งนี้มีข้อดีคือการอนุญาตให้หลายระบบดำเนินการเตรียมการพร้อมกันและลดจุดติดต่อสำหรับสื่อที่จัดส่งได้และซอฟต์แวร์ถ่ายโอนข้อมูลให้เหลือเพียงระบบเดียว

คอขวดการย้ายระบบคลาวด์ # 5: การถ่ายโอนข้อมูล

เมื่อเปรียบเทียบการถ่ายโอนเครือข่ายกับการจัดส่งสื่อการให้ความสำคัญกับเวลาในการจัดส่งเป็นเรื่องง่าย ตัวอย่างเช่นอุปกรณ์ AWS Snowball 80 เทราไบต์อาจถูกส่งโดยผู้ให้บริการจัดส่งในวันถัดไปซึ่งมีอัตราข้อมูลที่ชัดเจนมากกว่าแปดกิกะบิตต่อวินาที แต่สิ่งนี้จะไม่สนใจเวลาที่ต้องใช้ในการรับอุปกรณ์กำหนดค่าและโหลดเตรียมส่งคืนและอนุญาตให้ผู้จำหน่ายระบบคลาวด์คัดลอกข้อมูลออกจากส่วนหลัง ลูกค้าของเราที่ทำเช่นนี้เป็นประจำรายงานว่าเวลาตอบสนองสี่สัปดาห์ (จากการสั่งซื้ออุปกรณ์ไปจนถึงข้อมูลที่มีอยู่ในระบบคลาวด์) เป็นเรื่องปกติ นั่นทำให้อัตราการถ่ายโอนข้อมูลที่แท้จริงของการจัดส่งอุปกรณ์ลดลงเหลือเพียง 300 เมกะบิตต่อวินาทีซึ่งน้อยกว่ามากหากอุปกรณ์ไม่ได้รับการเติมเต็ม

ความเร็วในการถ่ายโอนเครือข่ายก็ขึ้นอยู่กับปัจจัยหลายประการซึ่งสำคัญที่สุดคือการอัปลิงค์ในพื้นที่ คุณไม่สามารถส่งข้อมูลได้เร็วกว่าอัตราบิตจริงแม้ว่าการเตรียมข้อมูลอย่างรอบคอบจะช่วยลดปริมาณข้อมูลที่คุณต้องส่งได้ โปรโตคอลเดิมรวมถึงโปรโตคอลที่ผู้จำหน่ายระบบคลาวด์ใช้เป็นค่าเริ่มต้นสำหรับพื้นที่จัดเก็บอ็อบเจ็กต์มีปัญหาในเรื่องความเร็วและความน่าเชื่อถือในเส้นทางอินเทอร์เน็ตทางไกลซึ่งอาจทำให้การบรรลุอัตราบิตนั้นเป็นเรื่องยาก ฉันสามารถเขียนบทความมากมายเกี่ยวกับความท้าทายที่เกี่ยวข้องที่นี่ แต่เป็นบทความที่คุณไม่ต้องแก้ปัญหาด้วยตัวเอง Data Expedition เป็นหนึ่งใน บริษัท ไม่กี่แห่งที่มีความเชี่ยวชาญในการตรวจสอบว่ามีการใช้เส้นทางอย่างเต็มที่ไม่ว่าข้อมูลของคุณจะอยู่ห่างจากปลายทางระบบคลาวด์แค่ไหนก็ตาม ตัวอย่างเช่นการเชื่อมต่ออินเทอร์เน็ตแบบกิกะบิตพร้อมซอฟต์แวร์เร่งความเร็วเช่น CloudDat ให้ผล 900 เมกะบิตต่อวินาทีสามเท่าของปริมาณงานสุทธิของ AWS Snowball

ความแตกต่างที่ใหญ่ที่สุดระหว่างการขนส่งทางกายภาพและการโอนย้ายเครือข่ายยังเป็นหนึ่งในความแตกต่างที่มักถูกมองข้ามในระหว่างการพิสูจน์แนวคิด ในการจัดส่งทางกายภาพไบต์แรกที่คุณโหลดลงในอุปกรณ์จะต้องรอจนกว่าจะโหลดไบต์สุดท้ายก่อนจึงจะสามารถจัดส่งได้ ซึ่งหมายความว่าหากต้องใช้เวลาหลายสัปดาห์ในการโหลดอุปกรณ์ข้อมูลบางส่วนของคุณจะล้าสมัยไปหลายสัปดาห์ตามเวลาที่มาถึงในระบบคลาวด์ แม้ว่าชุดข้อมูลจะถึงระดับเพตะไบต์ซึ่งการจัดส่งทางกายภาพอาจเร็วกว่า แต่ความสามารถในการรักษาข้อมูลลำดับความสำคัญให้เป็นปัจจุบันในระหว่างขั้นตอนการย้ายข้อมูลอาจยังคงเป็นประโยชน์ต่อการถ่ายโอนเครือข่ายสำหรับทรัพย์สินหลัก การวางแผนอย่างรอบคอบในระหว่างขั้นตอนการกรองและการจัดลำดับความสำคัญของการเตรียมข้อมูลเป็นสิ่งสำคัญและอาจเปิดโอกาสให้ใช้วิธีการแบบผสมผสาน

การนำข้อมูลเข้าสู่ผู้ให้บริการระบบคลาวด์อาจไม่ใช่จุดสิ้นสุดของขั้นตอนการถ่ายโอนข้อมูล หากจำเป็นต้องจำลองแบบไปยังหลายภูมิภาคหรือผู้ให้บริการให้วางแผนอย่างรอบคอบว่าจะไปที่นั่นได้อย่างไร การอัปโหลดทางอินเทอร์เน็ตนั้นฟรีในขณะที่ AWS จะเรียกเก็บเงินไม่เกินสองเซนต์ต่อกิกะไบต์สำหรับการถ่ายโอนข้อมูลระหว่างภูมิภาคและเก้าเซนต์ต่อกิกะไบต์สำหรับการถ่ายโอนไปยังผู้ให้บริการคลาวด์รายอื่น ทั้งสองวิธีจะเผชิญกับข้อ จำกัด แบนด์วิดท์ที่อาจได้รับประโยชน์จากการเร่งความเร็วในการขนส่งเช่น CloudDat

คอขวดการย้ายระบบคลาวด์ # 6: การปรับขนาดเมฆ

เมื่อข้อมูลมาถึงปลายทางในระบบคลาวด์กระบวนการย้ายข้อมูลจะเสร็จสิ้นเพียงครึ่งเดียว Checksums มาก่อน: ตรวจสอบให้แน่ใจว่าไบต์ที่มาถึงตรงกับที่ถูกส่ง สิ่งนี้อาจยุ่งยากกว่าที่คุณคิด การจัดเก็บไฟล์ใช้เลเยอร์ของแคชที่สามารถซ่อนความเสียหายของข้อมูลที่เพิ่งอัปโหลด ความเสียหายดังกล่าวเป็นของหายาก แต่จนกว่าคุณจะได้เคลียร์ทั้งหมดของแคชและอีกครั้งอ่านไฟล์ที่คุณไม่สามารถตรวจสอบของ checksums ใด ๆ การรีบูตอินสแตนซ์หรือการยกเลิกการต่อเชื่อมที่เก็บข้อมูลจะช่วยล้างแคชได้

การตรวจสอบความถูกต้องของการตรวจสอบการจัดเก็บอ็อบเจ็กต์ต้องการให้แต่ละอ็อบเจ็กต์ถูกอ่านออกเป็นอินสแตนซ์สำหรับการคำนวณ ตรงกันข้ามกับความเชื่อที่นิยมวัตถุ "E-tags" ไม่มีประโยชน์ในการตรวจสอบ ออบเจ็กต์ที่อัปโหลดโดยใช้เทคนิคหลายส่วนโดยเฉพาะสามารถตรวจสอบได้โดยการอ่านย้อนกลับเท่านั้น