ฉันเรียกใช้เว็บไซต์ที่มีไฟล์ประมาณ 10 ล้านไฟล์ (ปกหนังสือ) ในไดเรกทอรีย่อย 3 ระดับตั้งแต่ [0-f]:

0/0/0/
0/0/1/
...
f/f/f/

สิ่งนี้นำไปสู่ไฟล์ประมาณ 2400 ไฟล์ต่อไดเรกทอรีซึ่งเร็วมากเมื่อเราต้องการดึงไฟล์หนึ่งไฟล์ นอกจากนี้ยังเป็นการฝึกฝนที่แนะนำโดยคำถามมากมาย

อย่างไรก็ตามเมื่อฉันต้องการสำรองไฟล์เหล่านี้มันใช้เวลาหลายวันเพียงแค่เรียกดูไดเรกทอรี 4k ที่มีไฟล์ขนาด 10 เมตร

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

ข้อเสนอแนะใด ๆ เกี่ยวกับวิธีการทำสิ่งนี้ให้ดีที่สุด? หรือทางเลือกที่ทำงานได้ (noSQL, ... )?

ตัวเลือกสำหรับการเข้าถึงและสำรองไฟล์หลายล้านไฟล์อย่างรวดเร็ว

ยืมจากคนที่มีปัญหาคล้ายกัน

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

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

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

ระบบไฟล์เฉพาะ

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

LVM

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

RAID-1

ฉันแน่ใจว่าคุณคุ้นเคยกับ RAID อยู่แล้วและอาจใช้เพื่อความน่าเชื่อถืออยู่แล้ว แต่ RAID-1 สามารถใช้สำหรับการสำรองข้อมูลได้เช่นกันอย่างน้อยถ้าคุณใช้ซอฟต์แวร์ RAID (คุณสามารถใช้กับฮาร์ดแวร์ RAID ได้ แต่จริงๆแล้ว ช่วยให้คุณมีความน่าเชื่อถือต่ำลงเนื่องจากอาจต้องใช้ตัวควบคุมรุ่น / การแก้ไขเดียวกันเพื่ออ่าน) แนวคิดคือคุณสร้างกลุ่ม RAID-1 ที่มีดิสก์มากกว่าหนึ่งแผ่นที่คุณต้องการเชื่อมต่อกับความต้องการความเชื่อถือได้ตามปกติ (เช่นดิสก์ที่สามหากคุณใช้ซอฟต์แวร์ RAID-1 ที่มีดิสก์สองแผ่นหรืออาจเป็นดิสก์ขนาดใหญ่และฮาร์ดแวร์ - RAID5 ที่มีดิสก์ขนาดเล็กกว่าพร้อมซอฟต์แวร์ RAID-1 ที่ด้านบนของฮาร์ดแวร์ RAID-5) เมื่อถึงเวลาที่ต้องทำการสำรองข้อมูลให้ติดตั้งดิสก์ขอ mdadm เพื่อเพิ่มดิสก์นั้นลงในกลุ่มการโจมตีรอจนกว่ามันจะบ่งบอกถึงความสมบูรณ์เลือกที่จะถามขัดการตรวจสอบแล้วเอาดิสก์ แน่นอน,

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

อีกทางเลือกหนึ่งคือการสำรองข้อมูลอุปกรณ์ทั้งหมดโดยใช้ dd ตัวอย่างเช่นdd if=/dev/my_device of=/path/to/backup.dd.

อย่างที่คุณทราบปัญหาของคุณคือท้องที่ การค้นหาดิสก์โดยทั่วไปใช้เวลา 10ms หรือมากกว่านั้น ดังนั้นเพียงแค่เรียก "stat" (หรือ open ()) บนไฟล์ที่วางแบบสุ่ม 10 ล้านไฟล์ต้องใช้การค้นหา 10 ล้านครั้งหรือประมาณ 100,000 ครั้งหรือประมาณ 30 ชั่วโมง

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

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

มีสองตัวเลือก ที่ง่ายที่สุดและควรทำงานกับระบบไฟล์ Linux ทั้งหมดคือการddคัดลอกพาร์ทิชันทั้งหมด ( /dev/sdb3หรือ/dev/mapper/Data-ImageVol) ไปยังภาพเดียวและเก็บภาพนั้นไว้ ในกรณีที่กู้คืนไฟล์เอกพจน์ให้ลูปแบ็คอิมเมจ ( mount -o loop /usr/path/to/file /mountpoint) และคัดลอกไฟล์ที่คุณต้องการ สำหรับการกู้คืนพาร์ติชันแบบเต็มคุณสามารถย้อนกลับทิศทางของddคำสั่งเริ่มต้นได้แต่คุณต้องใช้พาร์ติชันที่มีขนาดเท่ากันจริงๆ

ตัดสินจากการใช้งานของคุณฉันเดาว่าการกู้คืนไฟล์แต่ละไฟล์นั้นเป็นเหตุการณ์ที่เกิดขึ้นไม่บ่อยนักหากพวกเขาเคยเกิดขึ้นมาทั้งหมด นี่คือเหตุผลว่าทำไมการสำรองข้อมูลแบบรูปภาพจึงสมเหตุสมผล หากคุณต้องการกู้คืนข้อมูลส่วนบุคคลบ่อยครั้งการใช้สแนปชอต LVM แบบฉากจะสะดวกกว่ามาก แต่คุณยังต้องทำการสำรองข้อมูลแบบรูปภาพสำหรับภัยพิบัติที่สำคัญ "เราแพ้ทุกอย่าง" ภาพที่ใช้คืนมักจะไปมากเร็วกว่าคืน tar-based เพียงเพราะมันเป็นเพียงแค่การเรียกคืนบล็อกมันจะไม่เกิดขึ้นไม่น้อยของการดำเนินงานเมตาดาต้าที่มีทุก fopen / fclose และยังสามารถเป็นลำดับสูงดิสก์การดำเนินงาน ความเร็วเพิ่มขึ้นอีก

อีกวิธีหนึ่งคือ Google วิดีโอ @casey ชี้ไปที่ประมาณครึ่งทาง XFS เป็นระบบไฟล์ที่ยอดเยี่ยม (ถ้าซับซ้อน) หนึ่งในxfsdumpยูทิลิตี้ดีกว่าที่มี XFS คือยูทิลิตี้ซึ่งจะถ่ายโอนระบบไฟล์ทั้งหมดไปยังไฟล์เดียวและโดยทั่วไปจะทำได้เร็วกว่าที่tarทำได้ มันเป็นยูทิลิตีเฉพาะระบบไฟล์ดังนั้นสามารถใช้ประโยชน์จาก fs internals ในรูปแบบที่ไม่สามารถทำได้

ฉันขอแนะนำให้คุณลองอัปเกรดเป็น EXT4 ก่อนหากคุณยังไม่ได้ใช้งาน

Google ได้ทำมากของการวิจัยเข้าไปทำไม Ext4 เป็นความคิดที่ดี

หลังจากนั้นคุณควรตรวจสอบการปรับใช้สถาปัตยกรรมระบบไฟล์แบบกระจาย ตัวอย่างเช่น:

• http://www.xtreemfs.org/
• http://code.google.com/p/kosmosfs/
• http://hadoop.apache.org/hdfs/

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

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

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

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

มีคุณสมบัติสองสามอย่างที่จะช่วยแก้ไขปัญหาของคุณ

• รุ่น Enterprise รองรับรูปแบบของการจำลองแบบระยะไกลโดยยึดตามสแน็ปช็อตซึ่งไม่จำเป็นต้องสแกนผ่านระบบไฟล์ทั้งหมด

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

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

มีความสอดคล้องกันเป็นยูทิลิตี้สำหรับการสำรองข้อมูลการกู้คืนที่สร้างขึ้นโดยrestoredump

สนับสนุนการสำรองข้อมูลส่วนเพิ่มโดยใช้ระดับการสำรองข้อมูลระดับ 1 ซึ่งแก้ไขจากการสำรองข้อมูลระดับ 0 ล่าสุด (เต็ม) ระดับ 2 - แก้ไขจากการสำรองข้อมูลระดับ 1 และอื่น ๆ

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

โปรดทราบว่าเพื่อให้newfilesต้นไม้เล็กก่อนที่จะทำการสำรองข้อมูลใหม่ของต้นไม้หลักคุณสามารถล้างต้นไม้ newfiles:

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

เมื่อคุณทำเช่นนี้แน่นอนคุณจะต้องสร้างการสำรองข้อมูลใหม่ของต้นไม้หลัก

การเพิ่มการทำงานพร้อมกันเล็กน้อยมักจะช่วยได้

ฉันมีปัญหาคล้ายกันกับคุณ ในกรณีของฉันฉันต้องสำรองไฟล์ประมาณ 30 ล้านไฟล์ส่วนใหญ่เป็นไฟล์ HTML, PHP หรือ JPEG สำหรับฉันBackupPC + rsync ผ่าน ssh ใช้งานได้ดี การสำรองข้อมูลเต็มรูปแบบใช้เวลาประมาณหนึ่งวัน แต่โดยปกติแล้วการเพิ่มจะเสร็จสิ้นภายในสองสามชั่วโมง

เคล็ดลับคือการเพิ่มแต่ละไดเรกทอรีระดับหลัก (0, 1, 2 ... a, b, c ... ) เป็นเป้าหมายใหม่ในการคัดลอกใน BackupPC และปล่อยให้มันทำการสำรองข้อมูลแบบขนานดังนั้นจึงสำรองไดเรกทอรีพร้อมกัน a / , b / , c / * และอื่น ๆ ทั้งนี้ขึ้นอยู่กับระบบย่อยดิสก์ของคุณระหว่างกระบวนการสองถึง 10 กระบวนการอาจเป็นวิธีที่เร็วที่สุดในการสำรองข้อมูล

LVM snapshots และการสำรองข้อมูลระดับบล็อกยังเป็นตัวเลือกอีกด้วย แต่ด้วย BackuPC และการสำรองข้อมูลระดับไฟล์คุณยังสามารถเรียกคืนไฟล์หรือไดเรกทอรีแต่ละไฟล์ได้หากจำเป็น

เบนจามิน

ฉันคิดว่าปัญหาของคุณสามารถแก้ไขได้ที่จำนวนไฟล์ต่อระดับไดเรกทอรี!

เวลาในการเข้าถึงเปลี่ยนแปลงโดยปัจจัยสำคัญหรือไม่หากคุณเก็บไฟล์ 20,000 ไฟล์ในไดเรกทอรี

คุณคิดยังเก็บเมตาดาต้าระบบแฟ้มไว้ในไดรฟ์เข้าถึงที่เร็วกว่าหรือไม่ (เช่น SSD)

ฉันขอแนะนำฐานข้อมูลเชิงสัมพันธ์เก่าที่ดีแทน

ฉันจะใช้ PostgreSQL กับ, พูด, 256 พาร์ติชันตาราง (cover_00, cover_01, ... , cover_ff) กับข้อมูลภาพเป็นbyteaคอลัมน์ (ไบนารี) พร้อมที่เก็บข้อมูลภายนอก, พร้อมตัวระบุไฟล์เป็นคีย์หลัก การดึงภาพจะรวดเร็ว (ต้องขอบคุณดัชนีในคีย์หลัก) ความสมบูรณ์ของข้อมูลจะได้รับการรับประกัน (ฐานข้อมูลที่สอดคล้องกับ ACID) การสำรองข้อมูลจะอยู่ในลำดับของดิสก์ดังนั้นจึงไม่ต้องการการค้นหามากเกินไป