ระบบไฟล์สำหรับไฟล์ขนาดเล็กนับล้าน

44

ระบบไฟล์ Linux ใดที่คุณจะเลือกให้เร็วที่สุดในสถานการณ์ต่อไปนี้:

หนึ่งร้อยล้านไฟล์
ขนาดไฟล์เฉลี่ย 2k
> การเข้าถึงการอ่าน 95%
การเข้าถึงแบบสุ่มสวย
ภาวะพร้อมกันสูง (> 100 กระบวนการ)

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

คุณจะวัดมาตรฐานอย่างไร

linux filesystems benchmark

3

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

— Avery Payne

มีการเข้าถึงไฟล์แบบอนุกรมหรือแบบพร้อมกันหรือไม่?

— Steve Schnepp

19

นี่คือผลการเปรียบเทียบลินุกซ์สำคัญทั้งหมดกับ bonnie ++ ที่คุณสามารถใช้เป็นจุดเริ่มต้น

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

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

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

— Andrew Cholakian
แหล่งที่มา

1

ปัญหาของบอนนี่ ++ ก็คือว่ามันไม่ได้ประมาณทดสอบภาพจำลองการใช้งานของฉัน

— Bene

2

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

— แอนดรู Cholakian

7

@AndrewCholakian Link ตายไปแล้ว

— Don Scott

8

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

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

— ไมค์
แหล่งที่มา

3

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

— Mihai Limbăşan

3

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

— Jeroen Landheer
แหล่งที่มา

1

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

— Stu Thompson

3

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

— Jeroen Landheer

1

และง่ายต่อการ "ทำความสะอาด / สูญญากาศ" ไฟล์ db มากกว่าการจัดเรียงข้อมูลระบบไฟล์บน linux fs ส่วนใหญ่ / ทั้งหมดไม่มีฟังก์ชั่นดังกล่าวโดยบอกว่าไม่จำเป็น เมื่อสังเกตความคิดเห็นของ Mihai ข้างต้นแล้วคุณจะเห็นได้ว่ามันไม่เป็นความจริง

— Gringo Suave

3

ใครบางคนบน Unix StackExchange สร้างเกณฑ์มาตรฐาน (พร้อมแหล่งที่มา) เพื่อทดสอบสถานการณ์นี้:

ถาม: ระบบไฟล์ Linux ประสิทธิภาพสูงที่สุดสำหรับการจัดเก็บไฟล์ขนาดเล็กจำนวนมาก (HDD ไม่ใช่ SSD) คืออะไร

ประสิทธิภาพในการอ่านที่ดีที่สุดนั้นมาจาก ReiserFS

— thenickdude
แหล่งที่มา

Btrfs ดูเหมือนจะมีผลลัพธ์ที่ดีกว่าหรือเทียบเท่าในทุกสิ่งยกเว้นการลบ แต่คุณลบไฟล์ 300k บ่อยแค่ไหน? ฉันชอบ RFS ในอดีต แต่ btrfs อาจเป็นทางออกที่ดีกว่าสำหรับอนาคต

— Gringo Suave

3

จากประสบการณ์ของฉัน ext2 เป่า ext4 ออกจากน้ำเพื่อหาไฟล์ขนาดเล็ก หากคุณไม่สนใจเกี่ยวกับความซื่อสัตย์ในการเขียนมันยอดเยี่ยมมาก ตัวอย่างเช่นการโค่นล้มสร้างไฟล์จำนวนมากมากมายและเล็กซึ่ง ext4 และระบบไฟล์อื่น ๆ (XFS) ทำให้หายใจไม่ออก (เรียกใช้งาน cron ที่ rsyncs ข้อมูลไปยัง ext4 จาก ext2 ทุกครึ่งชั่วโมงหรือเพื่อแก้ปัญหา)

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

echo 15 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo "2000" > /proc/sys/vm/vfs_cache_pressure

— เจสันฮอลล์
แหล่งที่มา

1

ฉันเดา ext3 (หรือ ext4) บางที JFS อาจเป็นทางออกที่ดี ฉันจะระวังด้วย ext4 และ btrfs (ระบบไฟล์นั้นยุ่งยาก - เตรียมการสำรองข้อมูลหากคุณต้องการใช้สิ่งล่าสุดและใหม่ล่าสุด)

นอกจากนี้ยังมีพารามิเตอร์ต่างๆที่คุณสามารถปรับแต่งได้ในช่วงเวลา mkfs เพื่อปรับแต่งระบบไฟล์ตามที่คุณต้องการ

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

เพื่อหลีกเลี่ยงปัญหาเกี่ยวกับการค้นหาไดเรกทอรีให้ใช้รูปแบบการตั้งชื่ออัจฉริยะตัวอย่างเช่น

<first letter of id>_<last letter of id>/<id>

หรือโครงร่างที่ซับซ้อนกว่านี้ สิ่งนี้จะเพิ่มความเร็วในการค้นหาไดเรกทอรีของคุณและความเร็วในการเข้าถึง (มันเป็นเคล็ดลับ unix เก่ากลับมาจาก V7 ฉันคิดว่า)

1

อะไรคือข้อดีของการใช้ตัวอักษรตัวแรกและตัวสุดท้ายไม่ใช่แค่ตัวอักษร n ตัวแรก

— ประโยชน์

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

1

FS ส่วนใหญ่จะทำให้หายใจไม่ออกด้วยไฟล์มากกว่า 65K ใน dir ฉันคิดว่ามันยังคงเป็นจริงของ ext4 ระบบไฟล์ของ Reiser ไม่มีขีด จำกัด นั้น (คนที่ mp3.com จ่ายเพื่อให้แน่ใจว่ามัน) ไม่แน่ใจเกี่ยวกับสิ่งอื่นใด แต่เป็นหนึ่งในสถานการณ์การใช้งานที่ ReiserFS สร้างขึ้น

— Ronald Pottol
แหล่งที่มา

1

มัน ReiserFS ไม่ RieserFS

— แดเนียล Rikowski

สุดสัปดาห์นี้ฉันมี dir สำหรับ ext4 ที่มีไฟล์ 1000000 ไฟล์อยู่ ตราบใดที่คุณไม่ทำlsหรือทำแท็บเสร็จมันก็ทำงานได้รวดเร็ว อาจเป็นเพราะดัชนี

— Ole Tange

ext4 มีนามสกุล dir_index ซึ่งเพิ่มความเร็วไฟล์จำนวนมากในไดเรกทอรีเดียว

— alfonx