seaweedfs
3.80
SeaweedFS เป็นโครงการโอเพ่นซอร์สอิสระที่ได้รับลิขสิทธิ์จาก Apache พร้อมการพัฒนาอย่างต่อเนื่องที่ทำให้เป็นไปได้ทั้งหมดด้วยการสนับสนุนของผู้สนับสนุนที่ยอดเยี่ยมเหล่านี้ หากคุณต้องการทำให้ SeaweedFS แข็งแกร่งยิ่งขึ้น โปรดพิจารณาเข้าร่วมเป็นผู้สนับสนุน Patreon ของเรา
การสนับสนุนของคุณจะได้รับการชื่นชมอย่างมากจากฉันและผู้สนับสนุนคนอื่นๆ!
docker run -p 8333:8333 chrislusf/seaweedfs server -s3
weed หรือ weed.exe หรือเรียกใช้ go install github.com/seaweedfs/seaweedfs/weed@latestweed server -dir=/some/data/dir -s3 เพื่อเริ่มต้นหนึ่งเซิร์ฟเวอร์หลัก หนึ่งเซิร์ฟเวอร์โวลุ่ม หนึ่งตัวสร้างไฟล์ และหนึ่งเกตเวย์ S3 นอกจากนี้ หากต้องการเพิ่มความจุ เพียงเพิ่มวอลุ่มเซิร์ฟเวอร์โดยการรัน weed volume -dir="/some/data/dir2" -mserver="<master_host>:9333" -port=8081 ภายในเครื่อง หรือบนเครื่องอื่น หรือบน หลายพันเครื่อง แค่นั้นแหละ!
SeaweedFS เป็นระบบไฟล์แบบกระจายที่เรียบง่ายและปรับขนาดได้สูง มีวัตถุประสงค์สองประการ:
SeaweedFS เริ่มต้นจากการเป็น Object Store เพื่อจัดการไฟล์ขนาดเล็กอย่างมีประสิทธิภาพ แทนที่จะจัดการข้อมูลเมตาของไฟล์ทั้งหมดในต้นแบบส่วนกลาง ต้นแบบกลางจะจัดการเฉพาะวอลุ่มบนเซิร์ฟเวอร์โวลุ่ม และเซิร์ฟเวอร์โวลุ่มเหล่านี้จะจัดการไฟล์และข้อมูลเมตาของไฟล์เหล่านั้น ซึ่งช่วยลดแรงกดดันจากการทำงานพร้อมกันจากต้นแบบส่วนกลาง และกระจายข้อมูลเมตาของไฟล์ไปยังเซิร์ฟเวอร์โวลุ่ม ช่วยให้เข้าถึงไฟล์ได้เร็วขึ้น (O(1) โดยปกติเป็นเพียงการดำเนินการอ่านดิสก์เดียว)
มีพื้นที่เก็บข้อมูลดิสก์เพียง 40 ไบต์สำหรับข้อมูลเมตาของแต่ละไฟล์ การอ่านดิสก์ O(1) เป็นเรื่องง่ายมากจนคุณสามารถท้าทายประสิทธิภาพกับกรณีการใช้งานจริงของคุณได้
SeaweedFS เริ่มต้นด้วยการใช้กระดาษออกแบบ Haystack ของ Facebook นอกจากนี้ SeaweedFS ยังใช้การเขียนโค้ดแบบลบด้วยแนวคิดจาก f4: Warm BLOB Storage System ของ Facebook และมีความคล้ายคลึงกันมากกับระบบไฟล์ Tectonic ของ Facebook
ด้านบนของที่เก็บอ็อบเจ็กต์ Filer เผื่อเลือกสามารถรองรับไดเร็กทอรีและแอ็ตทริบิวต์ POSIX Filer เป็นเซิร์ฟเวอร์ไร้สถานะที่ปรับขนาดเชิงเส้นแยกต่างหากพร้อมที่เก็บเมตาดาต้าที่ปรับแต่งได้ เช่น MySql, Postgres, Redis, Cassandra, HBase, Mongodb, Elastic Search, LevelDB, RocksDB, Sqlite, MemSql, TiDB, Etcd, CockroachDB, YDB เป็นต้น
สำหรับร้านค้าค่าคีย์แบบกระจาย ค่าขนาดใหญ่สามารถออฟโหลดไปยัง SeaweedFS ได้ ด้วยความเร็วการเข้าถึงที่รวดเร็วและความสามารถในการปรับขนาดเชิงเส้น SeaweedFS สามารถทำงานเป็นร้านค้า Key-Large-Value แบบกระจายได้
SeaweedFS สามารถรวมเข้ากับระบบคลาวด์ได้อย่างโปร่งใส ด้วยข้อมูลยอดนิยมบนคลัสเตอร์ท้องถิ่น และข้อมูลอุ่นบนคลาวด์ที่มีเวลาเข้าถึง O(1) SeaweedFS จึงสามารถบรรลุทั้งเวลาการเข้าถึงในท้องถิ่นที่รวดเร็วและความจุการจัดเก็บข้อมูลบนคลาวด์ที่ยืดหยุ่น ยิ่งไปกว่านั้น ต้นทุน API การเข้าถึงพื้นที่เก็บข้อมูลบนคลาวด์ก็ลดลงอีกด้วย เร็วกว่าและถูกกว่าที่เก็บข้อมูลบนคลาวด์โดยตรง!
กลับไปที่สารบบ
กลับไปที่สารบบ
กลับไปที่สารบบ
ตามค่าเริ่มต้น โหนดหลักจะทำงานบนพอร์ต 9333 และโหนดโวลุ่มทำงานบนพอร์ต 8080 มาเริ่มกันที่โหนดหลักหนึ่งโหนด และโหนดโวลุ่มสองโหนดบนพอร์ต 8080 และ 8081 ตามหลักการแล้ว โหนดทั้งสองควรเริ่มจากเครื่องที่แตกต่างกัน เราจะใช้ localhost เป็นตัวอย่าง
SeaweedFS ใช้การดำเนินการ HTTP REST เพื่ออ่าน เขียน และลบ การตอบกลับอยู่ในรูปแบบ JSON หรือ JSONP
> ./weed master
> weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080 &
> weed volume -dir="/tmp/data2" -max=10 -mserver="localhost:9333" -port=8081 &
หากต้องการอัปโหลดไฟล์: ขั้นแรก ให้ส่งคำขอ HTTP POST, PUT หรือ GET ไปที่ /dir/assign เพื่อรับ fid และ URL ของเซิร์ฟเวอร์โวลุ่ม:
> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
ประการที่สอง ในการจัดเก็บเนื้อหาไฟล์ ให้ส่งคำขอ POST แบบหลายส่วน HTTP ไปที่ url + '/' + fid จากการตอบกลับ:
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
หากต้องการอัปเดต ให้ส่งคำขอ POST อีกครั้งพร้อมเนื้อหาไฟล์ที่อัปเดต
สำหรับการลบ ให้ส่งคำขอ HTTP DELETE ไปยัง url + '/' + fid URL เดียวกัน:
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
ตอนนี้คุณสามารถบันทึก fid ในกรณีนี้ 3,01637037d6 ไปยังฟิลด์ฐานข้อมูลได้
หมายเลข 3 ที่จุดเริ่มต้นแสดงถึงรหัสวอลุ่ม หลังเครื่องหมายจุลภาค จะเป็นคีย์ไฟล์เดียว 01 และคุกกี้ไฟล์ 637037d6
ID โวลุ่มเป็นจำนวนเต็ม 32 บิตที่ไม่ได้ลงนาม คีย์ไฟล์เป็นจำนวนเต็ม 64 บิตที่ไม่ได้ลงนาม คุกกี้ไฟล์เป็นจำนวนเต็ม 32 บิตที่ไม่ได้ลงนาม ซึ่งใช้เพื่อป้องกันการคาดเดา URL
คีย์ไฟล์และคุกกี้ไฟล์มีการเข้ารหัสเป็นเลขฐานสิบหก คุณสามารถจัดเก็บทูเปิล <volume id, file key, file cookie> ในรูปแบบของคุณเอง หรือจัดเก็บ fid เป็นสตริงก็ได้
หากเก็บเป็นสตริง ตามทฤษฎี คุณจะต้องมี 8+1+16+8=33 ไบต์ ถ่าน (33) ก็เพียงพอแล้ว หากยังไม่เพียงพอ เนื่องจากการใช้งานส่วนใหญ่ไม่ต้องการปริมาณ 2^32
หากพื้นที่เป็นปัญหาจริงๆ คุณสามารถจัดเก็บรหัสไฟล์ในรูปแบบของคุณเองได้ คุณจะต้องมีเลขจำนวนเต็ม 4 ไบต์หนึ่งตัวสำหรับรหัสวอลุ่ม หมายเลขยาว 8 ไบต์สำหรับคีย์ไฟล์ และจำนวนเต็ม 4 ไบต์สำหรับคุกกี้ของไฟล์ ดังนั้น 16 ไบต์ก็เกินพอแล้ว
นี่คือตัวอย่างวิธีแสดงผล URL
ขั้นแรกให้ค้นหา URL ของโวลุ่มเซิร์ฟเวอร์ตาม VolumeId ของไฟล์:
> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}
เนื่องจาก (โดยปกติ) มีวอลุ่มเซิร์ฟเวอร์ไม่มากเกินไป และโวลุ่มไม่ได้ย้ายบ่อย คุณจึงสามารถแคชผลลัพธ์ได้เกือบตลอดเวลา ขึ้นอยู่กับชนิดของเรพลิเคชัน วอลุ่มหนึ่งสามารถมีตำแหน่งเรพลิกาได้หลายตำแหน่ง เพียงสุ่มเลือกสถานที่ใดสถานที่หนึ่งเพื่ออ่าน
ตอนนี้คุณสามารถใช้ URL สาธารณะ แสดงผล URL หรืออ่านโดยตรงจากเซิร์ฟเวอร์โวลุ่มผ่าน URL:
http://localhost:8080/3,01637037d6.jpg
สังเกตว่าเราเพิ่มนามสกุลไฟล์ ".jpg" ที่นี่ เป็นทางเลือกและเป็นเพียงวิธีเดียวที่ไคลเอ็นต์จะระบุประเภทเนื้อหาไฟล์
หากคุณต้องการ URL ที่ดีกว่า คุณสามารถใช้รูปแบบ URL ทางเลือกเหล่านี้ได้:
http://localhost:8080/3/01637037d6/my_preferred_name.jpg
http://localhost:8080/3/01637037d6.jpg
http://localhost:8080/3,01637037d6.jpg
http://localhost:8080/3/01637037d6
http://localhost:8080/3,01637037d6
หากคุณต้องการได้ภาพที่ปรับขนาดแล้ว คุณสามารถเพิ่มพารามิเตอร์ได้:
http://localhost:8080/3/01637037d6.jpg?height=200&width=200
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fit
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fill
SeaweedFS ใช้กลยุทธ์การจำลองแบบในระดับเสียง ดังนั้น เมื่อคุณได้รับรหัสไฟล์ คุณสามารถระบุกลยุทธ์การจำลองได้ ตัวอย่างเช่น:
curl http://localhost:9333/dir/assign?replication=001
ตัวเลือกพารามิเตอร์การจำลองคือ:
000: no replication
001: replicate once on the same rack
010: replicate once on a different rack, but same data center
100: replicate once on a different data center
200: replicate twice on two different data center
110: replicate once on a different rack, and once on a different data center
รายละเอียดเพิ่มเติมเกี่ยวกับการจำลองแบบสามารถพบได้ในวิกิ
คุณยังสามารถตั้งค่ากลยุทธ์การจำลองแบบเริ่มต้นได้เมื่อเริ่มต้นเซิร์ฟเวอร์หลัก
โวลุ่มเซิร์ฟเวอร์สามารถเริ่มต้นด้วยชื่อศูนย์ข้อมูลเฉพาะ:
weed volume -dir=/tmp/1 -port=8080 -dataCenter=dc1
weed volume -dir=/tmp/2 -port=8081 -dataCenter=dc2
เมื่อขอคีย์ไฟล์ พารามิเตอร์ "dataCenter" ซึ่งเป็นตัวเลือกสามารถจำกัดปริมาณที่กำหนดให้กับศูนย์ข้อมูลเฉพาะได้ ตัวอย่างเช่น ระบุว่าไดรฟ์ข้อมูลที่กำหนดควรจำกัดไว้ที่ 'dc1':
http://localhost:9333/dir/assign?dataCenter=dc1
กลับไปที่สารบบ
โดยปกติระบบไฟล์แบบกระจายจะแยกแต่ละไฟล์ออกเป็นชิ้นๆ ต้นแบบส่วนกลางจะเก็บการจับคู่ชื่อไฟล์ ดัชนีของชิ้นกับที่จับของชิ้น และรวมถึงชิ้นที่แต่ละเซิร์ฟเวอร์ชิ้นมี
ข้อเสียเปรียบหลักคือต้นแบบส่วนกลางไม่สามารถจัดการไฟล์ขนาดเล็กจำนวนมากได้อย่างมีประสิทธิภาพ และเนื่องจากคำขอการอ่านทั้งหมดจำเป็นต้องผ่านคลัสเตอร์มาสเตอร์ ดังนั้นจึงอาจไม่ปรับขนาดได้ดีสำหรับผู้ใช้จำนวนมากพร้อมกัน
แทนที่จะจัดการชิ้นส่วน SeaweedFS จัดการปริมาณข้อมูลในเซิร์ฟเวอร์หลัก แต่ละปริมาณข้อมูลมีขนาด 32GB และสามารถเก็บไฟล์ได้จำนวนมาก และแต่ละโหนดการจัดเก็บข้อมูลสามารถมีปริมาณข้อมูลได้มากมาย ดังนั้นโหนดหลักจำเป็นต้องจัดเก็บข้อมูลเมตาเกี่ยวกับไดรฟ์ข้อมูลเท่านั้น ซึ่งเป็นข้อมูลจำนวนค่อนข้างน้อยและโดยทั่วไปมีความเสถียร
ข้อมูลเมตาของไฟล์จริงจะถูกจัดเก็บไว้ในแต่ละวอลุ่มบนเซิร์ฟเวอร์โวลุ่ม เนื่องจากเซิร์ฟเวอร์โวลุ่มแต่ละเซิร์ฟเวอร์จะจัดการเฉพาะข้อมูลเมตาของไฟล์บนดิสก์ของตัวเอง โดยแต่ละไฟล์มีขนาดเพียง 16 ไบต์ การเข้าถึงไฟล์ทั้งหมดจึงสามารถอ่านข้อมูลเมตาของไฟล์ได้จากหน่วยความจำเท่านั้น และต้องการเพียงการดำเนินการจากดิสก์เพียงครั้งเดียวจึงจะอ่านข้อมูลไฟล์ได้จริง
สำหรับการเปรียบเทียบ ให้พิจารณาว่าโครงสร้าง xfs inode ใน Linux มีขนาด 536 ไบต์
สถาปัตยกรรมค่อนข้างเรียบง่าย ข้อมูลจริงจะถูกจัดเก็บไว้ในวอลุ่มบนโหนดการจัดเก็บข้อมูล เซิร์ฟเวอร์โวลุ่มหนึ่งตัวสามารถมีได้หลายโวลุ่ม และสามารถรองรับการเข้าถึงแบบอ่านและเขียนด้วยการรับรองความถูกต้องขั้นพื้นฐาน
ไดรฟ์ข้อมูลทั้งหมดได้รับการจัดการโดยเซิร์ฟเวอร์หลัก เซิร์ฟเวอร์หลักประกอบด้วย ID วอลุ่มกับการแม็ปเซิร์ฟเวอร์โวลุ่ม นี่เป็นข้อมูลที่ค่อนข้างคงที่และสามารถแคชได้ง่าย
ในคำขอเขียนแต่ละครั้ง เซิร์ฟเวอร์หลักยังสร้างคีย์ไฟล์ ซึ่งเป็นจำนวนเต็ม 64 บิตที่ไม่ได้ลงนามที่เพิ่มขึ้น เนื่องจากโดยทั่วไปคำขอเขียนจะไม่บ่อยเท่ากับคำขออ่าน เซิร์ฟเวอร์หลักหนึ่งเครื่องจึงควรสามารถจัดการการทำงานพร้อมกันได้ดี
เมื่อไคลเอนต์ส่งคำขอเขียน เซิร์ฟเวอร์หลักจะส่งกลับ (รหัสโวลุ่ม, รหัสไฟล์, คุกกี้ของไฟล์, URL ของโหนดโวลุ่ม) สำหรับไฟล์ จากนั้นไคลเอ็นต์จะติดต่อกับโหนดโวลุ่มและ POST เนื้อหาไฟล์
เมื่อไคลเอนต์จำเป็นต้องอ่านไฟล์ตาม (รหัสโวลุ่ม, รหัสไฟล์, คุกกี้ของไฟล์) ไคลเอนต์จะถามเซิร์ฟเวอร์หลักด้วยรหัสโวลุ่มสำหรับ (URL ของโหนดโวลุ่ม, URL สาธารณะของโหนดโวลุ่ม) หรือดึงข้อมูลนี้จากแคช จากนั้นลูกค้าสามารถรับเนื้อหาหรือเพียงแค่แสดง URL บนหน้าเว็บแล้วปล่อยให้เบราว์เซอร์ดึงเนื้อหา
โปรดดูตัวอย่างสำหรับรายละเอียดเกี่ยวกับกระบวนการเขียน-อ่าน
ในการใช้งานปัจจุบัน แต่ละวอลุ่มสามารถเก็บได้ 32 กิบิไบต์ (32GiB หรือ 8x2^32 ไบต์) เนื่องจากเราจัดเนื้อหาให้มีขนาด 8 ไบต์ เราสามารถเพิ่มสิ่งนี้เป็น 64GiB หรือ 128GiB หรือมากกว่านั้นได้อย่างง่ายดายโดยการเปลี่ยนโค้ด 2 บรรทัด โดยเสียพื้นที่ว่างภายในบางส่วนเนื่องจากการจัดตำแหน่ง
สามารถมีวอลุ่มได้ 4 กิบิไบต์ (4GiB หรือ 2^32 ไบต์) ดังนั้นขนาดระบบทั้งหมดคือ 8 x 4GiB x 4GiB ซึ่งก็คือ 128 exbibytes (128EiB หรือ 2^67 ไบต์)
ขนาดไฟล์แต่ละไฟล์จะถูกจำกัดไว้ที่ขนาดวอลุ่ม
ข้อมูลเมตาของไฟล์ทั้งหมดที่จัดเก็บไว้ในโวลุ่มเซิร์ฟเวอร์สามารถอ่านได้จากหน่วยความจำโดยไม่ต้องมีการเข้าถึงดิสก์ แต่ละไฟล์ใช้เวลาเพียงรายการแมป 16 ไบต์ของ <คีย์ 64 บิต, ออฟเซ็ต 32 บิต, ขนาด 32 บิต> แน่นอนว่าแต่ละรายการในแผนที่มีค่าใช้จ่ายพื้นที่สำหรับแผนที่ของตัวเอง แต่โดยปกติแล้วพื้นที่ดิสก์จะหมดก่อนที่หน่วยความจำจะหมด
โวลุ่มเซิร์ฟเวอร์ภายในนั้นเร็วกว่ามาก ในขณะที่พื้นที่จัดเก็บข้อมูลบนคลาวด์มีความจุที่ยืดหยุ่น และจริงๆ แล้วประหยัดต้นทุนมากกว่าหากไม่ได้เข้าถึงบ่อยครั้ง (โดยปกติจะอัปโหลดฟรี แต่มีค่าใช้จ่ายในการเข้าถึงค่อนข้างแพง) ด้วยโครงสร้างแบบต่อท้ายเท่านั้นและเวลาการเข้าถึง O(1) ทำให้ SeaweedFS สามารถใช้ประโยชน์จากพื้นที่จัดเก็บข้อมูลทั้งในระบบและบนคลาวด์โดยการถ่ายโอนข้อมูล warm ไปยังคลาวด์
โดยปกติแล้วข้อมูลที่ร้อนแรงจะเป็นข้อมูลใหม่ และข้อมูลที่อบอุ่นจะเป็นข้อมูลเก่า SeaweedFS วางโวลุ่มที่สร้างขึ้นใหม่บนเซิร์ฟเวอร์ภายในเครื่อง และเลือกอัปโหลดโวลุ่มเก่าบนคลาวด์ได้ หากข้อมูลเก่าเข้าถึงได้ไม่บ่อย สิ่งนี้จะช่วยให้คุณมีความจุไม่จำกัดด้วยเซิร์ฟเวอร์ภายในเครื่องที่จำกัด และยังคงเร็วสำหรับข้อมูลใหม่
ด้วยเวลาการเข้าถึง O(1) ต้นทุนแฝงของเครือข่ายจะถูกเก็บไว้ให้น้อยที่สุด
หากข้อมูลร้อน/อุ่นแบ่งเป็น 20/80 โดยมีเซิร์ฟเวอร์ 20 เครื่อง คุณจะได้รับความจุพื้นที่จัดเก็บข้อมูล 100 เซิร์ฟเวอร์ ประหยัดต้นทุนได้ถึง 80%! หรือคุณสามารถปรับใช้เซิร์ฟเวอร์ 80 เครื่องเพื่อจัดเก็บข้อมูลใหม่ และรับปริมาณงานการจัดเก็บข้อมูล 5 เท่า
กลับไปที่สารบบ
ระบบไฟล์แบบกระจายอื่นๆ ส่วนใหญ่ดูซับซ้อนเกินความจำเป็น
SeaweedFS ได้รับการออกแบบมาให้รวดเร็วและง่ายดายทั้งในด้านการตั้งค่าและการใช้งาน หากคุณไม่เข้าใจวิธีการทำงานเมื่อคุณมาถึงที่นี่ เราล้มเหลว! โปรดแจ้งปัญหาหรืออัปเดตไฟล์นี้พร้อมคำชี้แจง
SeaweedFS ก้าวไปข้างหน้าอย่างต่อเนื่อง เช่นเดียวกับระบบอื่นๆ การเปรียบเทียบเหล่านี้สามารถล้าสมัยได้อย่างรวดเร็ว โปรดช่วยอัปเดตพวกเขาอยู่เสมอ
กลับไปที่สารบบ
HDFS ใช้วิธีการแบบก้อนสำหรับแต่ละไฟล์ และเหมาะสำหรับการจัดเก็บไฟล์ขนาดใหญ่
SeaweedFS เหมาะอย่างยิ่งสำหรับการให้บริการไฟล์ที่มีขนาดค่อนข้างเล็กอย่างรวดเร็วและพร้อมกัน
SeaweedFS ยังสามารถจัดเก็บไฟล์ขนาดใหญ่พิเศษโดยแบ่งออกเป็นส่วนข้อมูลที่สามารถจัดการได้ และจัดเก็บรหัสไฟล์ของข้อมูลเป็นกลุ่ม meta chunk สิ่งนี้ได้รับการจัดการโดยเครื่องมือ "อัปโหลด/ดาวน์โหลด weed" และเซิร์ฟเวอร์หลักหรือเซิร์ฟเวอร์โวลุ่มนั้นไม่เชื่อเรื่องนั้น
กลับไปที่สารบบ
สถาปัตยกรรมส่วนใหญ่จะเหมือนกัน SeaweedFS มุ่งหวังที่จะจัดเก็บและอ่านไฟล์อย่างรวดเร็วด้วยสถาปัตยกรรมที่เรียบง่ายและเรียบๆ ความแตกต่างที่สำคัญคือ
| ระบบ | ข้อมูลเมตาของไฟล์ | อ่านเนื้อหาไฟล์ | POSIX | ส่วนที่เหลือ API | ปรับให้เหมาะสมสำหรับไฟล์ขนาดเล็กจำนวนมาก |
|---|---|---|---|---|---|
| สาหร่ายทะเลFS | รหัสปริมาณการค้นหา สามารถแคชได้ | ค้นหาดิสก์ O (1) | ใช่ | ใช่ | |
| เครื่องกรองสาหร่ายทะเลFS | ปรับขนาดได้เป็นเส้นตรง ปรับแต่งได้ | ค้นหาดิสก์ O (1) | ฟิวส์ | ใช่ | ใช่ |
| กลัสเตอร์เอฟเอส | การคร่ำครวญ | ฟิวส์, NFS | |||
| เซ็ฟ | การแฮช + กฎ | ฟิวส์ | ใช่ | ||
| มูสFS | ในความทรงจำ | ฟิวส์ | เลขที่ | ||
| มินิไอโอ | แยกไฟล์เมตาสำหรับแต่ละไฟล์ | ใช่ | เลขที่ |
กลับไปที่สารบบ
GlusterFS จัดเก็บไฟล์ทั้งไดเร็กทอรีและเนื้อหาในวอลุ่มที่กำหนดค่าได้ที่เรียกว่า "bricks"
GlusterFS แฮชเส้นทางและชื่อไฟล์ลงใน ID และกำหนดให้กับวอลุ่มเสมือน จากนั้นแมปกับ "Bricks"
กลับไปที่สารบบ
MooseFS เลือกที่จะละเลยปัญหาไฟล์ขนาดเล็ก จากคู่มือ moosefs 3.0 "แม้แต่ไฟล์ขนาดเล็กก็ยังใช้พื้นที่ 64KiB บวกกับเช็คซัมอีก 4KiB และ 1KiB สำหรับส่วนหัว" เนื่องจากในตอนแรก "ได้รับการออกแบบมาเพื่อเก็บไฟล์ขนาดใหญ่มาก (เช่นหลายพันไฟล์)"
MooseFS Master Server จะเก็บข้อมูลเมตาทั้งหมดไว้ในหน่วยความจำ ปัญหาเดียวกันกับเนมโหนด HDFS
กลับไปที่สารบบ
Ceph สามารถตั้งค่าได้คล้ายกับ SeaweedFS เป็นคีย์->blob store มันซับซ้อนกว่ามากโดยจำเป็นต้องรองรับเลเยอร์ที่อยู่ด้านบน นี่คือการเปรียบเทียบโดยละเอียดเพิ่มเติม
SeaweedFS มีกลุ่มหลักแบบรวมศูนย์เพื่อค้นหาวอลุ่มฟรี ในขณะที่ Ceph ใช้เซิร์ฟเวอร์แฮชและเมตาดาต้าเพื่อค้นหาอ็อบเจ็กต์ การมีต้นแบบแบบรวมศูนย์ทำให้ง่ายต่อการเขียนโค้ดและจัดการ
Ceph ก็เหมือนกับ SeaweedFS ที่ใช้ RADOS ที่เก็บอ็อบเจ็กต์ Ceph ค่อนข้างซับซ้อนเนื่องจากมีบทวิจารณ์ที่หลากหลาย
Ceph ใช้ CRUSH hashing เพื่อจัดการการจัดวางข้อมูลโดยอัตโนมัติ ซึ่งมีประสิทธิภาพในการค้นหาข้อมูล แต่ต้องวางข้อมูลตามอัลกอริธึม CRUSH การกำหนดค่าที่ไม่ถูกต้องจะทำให้ข้อมูลสูญหาย การเปลี่ยนแปลงโทโพโลยี เช่น การเพิ่มเซิร์ฟเวอร์ใหม่เพื่อเพิ่มความจุ จะทำให้การย้ายข้อมูลที่มีค่าใช้จ่าย IO สูงเพื่อให้เหมาะสมกับอัลกอริธึม CRUSH SeaweedFS วางข้อมูลโดยกำหนดให้กับวอลุ่มที่สามารถเขียนได้ หากการเขียนไปยังโวลุ่มหนึ่งล้มเหลว เพียงเลือกโวลุ่มอื่นที่จะเขียน การเพิ่มปริมาณก็ทำได้ง่ายเช่นกัน
SeaweedFS ได้รับการปรับให้เหมาะสมสำหรับไฟล์ขนาดเล็ก ไฟล์ขนาดเล็กจะถูกจัดเก็บเป็นบล็อกเนื้อหาต่อเนื่องกัน โดยมีขนาดไบต์ที่ไม่ได้ใช้สูงสุด 8 ไบต์ระหว่างไฟล์ การเข้าถึงไฟล์ขนาดเล็กคือการอ่านดิสก์ O(1)
SeaweedFS Filer ใช้ร้านค้าทั่วไป เช่น MySql, Postgres, Sqlite, Mongodb, Redis, Elastic Search, Cassandra, HBase, MemSql, TiDB, CockroachCB, Etcd, YDB เพื่อจัดการไดเร็กทอรีไฟล์ ร้านค้าเหล่านี้ได้รับการพิสูจน์แล้ว ปรับขนาดได้ และจัดการได้ง่ายกว่า
| สาหร่ายทะเลFS | เทียบได้กับเซฟเลย | ข้อได้เปรียบ |
|---|---|---|
| ผู้เชี่ยวชาญ | เอ็มดีเอส | ง่ายกว่า |
| ปริมาณ | OSD | ปรับให้เหมาะสมสำหรับไฟล์ขนาดเล็ก |
| ฟิลเลอร์ | ซีฟ เอฟเอส | ปรับขนาดได้เชิงเส้น, ปรับแต่งได้, O(1) หรือ O(logN) |
กลับไปที่สารบบ
MiniIO ติดตาม AWS S3 อย่างใกล้ชิด และเหมาะสำหรับการทดสอบ S3 API มี UI นโยบาย เวอร์ชัน ฯลฯ ที่ดี SeaweedFS พยายามที่จะตามทันที่นี่ นอกจากนี้ยังเป็นไปได้ที่จะวาง MiniIO เป็นเกตเวย์ต่อหน้า SeaweedFS ในภายหลัง
ข้อมูลเมตา MiniIO อยู่ในไฟล์ธรรมดา การเขียนไฟล์แต่ละครั้งจะต้องมีการเขียนเพิ่มเติมไปยังไฟล์เมตาที่เกี่ยวข้อง
MiniIO ไม่มีการเพิ่มประสิทธิภาพสำหรับไฟล์ขนาดเล็กจำนวนมาก ไฟล์จะถูกจัดเก็บเช่นเดียวกับดิสก์ในเครื่อง นอกจากนี้ ยังมีไฟล์เมตาเพิ่มเติมและชิ้นส่วนสำหรับการลบโค้ด ซึ่งจะช่วยขยายปัญหา LOSF เท่านั้น
MiniIO มีดิสก์ IO หลายตัวเพื่ออ่านไฟล์เดียว SeaweedFS มีการอ่านดิสก์ O(1) แม้ว่าจะลบไฟล์ที่เข้ารหัสก็ตาม
MiniIO มีการเข้ารหัสการลบแบบเต็มเวลา SeaweedFS ใช้การจำลองข้อมูลร้อนเพื่อความเร็วที่เร็วขึ้น และเลือกใช้การเข้ารหัสการลบข้อมูลกับข้อมูลร้อน
MiniIO ไม่มีการรองรับ API ที่เหมือน POSIX
MiniIO มีข้อกำหนดเฉพาะเกี่ยวกับรูปแบบการจัดเก็บข้อมูล ไม่ยืดหยุ่นในการปรับความจุ ใน SeaweedFS เพียงเริ่มต้นเซิร์ฟเวอร์โวลุ่มเดียวโดยชี้ไปที่มาสเตอร์ นั่นคือทั้งหมดที่
นี่เป็นโครงการที่น่าตื่นเต้นสุด ๆ ! และเราต้องการความช่วยเหลือและการสนับสนุน!
กลับไปที่สารบบ
คู่มือการติดตั้งสำหรับผู้ใช้ที่ไม่คุ้นเคยกับ golang
ขั้นตอนที่ 1: ติดตั้ง go บนเครื่องของคุณและตั้งค่าสภาพแวดล้อมโดยทำตามคำแนะนำที่:
https://golang.org/doc/install
อย่าลืมกำหนด $GOPATH ของคุณ
ขั้นตอนที่ 2: ชำระเงิน repo นี้:
git clone https://github.com/seaweedfs/seaweedfs.gitขั้นตอนที่ 3: ดาวน์โหลด คอมไพล์ และติดตั้งโปรเจ็กต์โดยดำเนินการคำสั่งต่อไปนี้
cd seaweedfs/weed && make install เมื่อเสร็จแล้ว คุณจะพบ "weed" ที่สามารถเรียกใช้งานได้ในไดเร็กทอรี $GOPATH/bin ของคุณ
กลับไปที่สารบบ
เมื่อทดสอบประสิทธิภาพการอ่านบน SeaweedFS โดยทั่วไปจะเป็นการทดสอบประสิทธิภาพของความเร็วในการอ่านแบบสุ่มของฮาร์ดไดรฟ์ของคุณ ฮาร์ดไดรฟ์มักจะได้รับ 100MB/s~200MB/s
หากต้องการแก้ไขหรือลบไฟล์ขนาดเล็ก SSD จะต้องลบบล็อกทั้งหมดพร้อมกัน และย้ายเนื้อหาในบล็อกที่มีอยู่ไปยังบล็อกใหม่ SSD จะเร็วเมื่อเป็นของใหม่ แต่จะกระจัดกระจายเมื่อเวลาผ่านไป และคุณต้องรวบรวมขยะและบดอัดบล็อก SeaweedFS เป็นมิตรกับ SSD เนื่องจากเป็นส่วนต่อท้ายเท่านั้น การลบและการบีบอัดจะดำเนินการในระดับเสียงในพื้นหลัง โดยไม่ทำให้การอ่านช้าลงและไม่ทำให้เกิดการแตกแฟรกเมนต์
กลับไปที่สารบบ
ผลลัพธ์ของเครื่องเดียวที่ไม่เป็นไปตามหลักวิทยาศาสตร์ของฉันเองบน Mac Book พร้อม Solid State Disk, CPU: 1 Intel Core i7 2.6GHz
เขียนไฟล์ 1 ล้าน 1KB:
Concurrency Level: 16
Time taken for tests: 66.753 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106789009 bytes
Requests per second: 15708.23 [#/sec]
Transfer rate: 16191.69 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.3 1.0 84.3 0.9
Percentage of the requests served within a certain time (ms)
50% 0.8 ms
66% 1.0 ms
75% 1.1 ms
80% 1.2 ms
90% 1.4 ms
95% 1.7 ms
98% 2.1 ms
99% 2.6 ms
100% 84.3 ms
สุ่มอ่าน 1 ล้านไฟล์:
Concurrency Level: 16
Time taken for tests: 22.301 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106812873 bytes
Requests per second: 47019.38 [#/sec]
Transfer rate: 48467.57 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.0 0.3 54.1 0.2
Percentage of the requests served within a certain time (ms)
50% 0.3 ms
90% 0.4 ms
98% 0.6 ms
99% 0.7 ms
100% 54.1 ms
make benchmark
warp: Benchmark data written to "warp-mixed-2023-10-16[102354]-l70a.csv.zst"
Mixed operations.
Operation: DELETE, 10%, Concurrency: 20, Ran 4m59s.
* Throughput: 6.19 obj/s
Operation: GET, 45%, Concurrency: 20, Ran 5m0s.
* Throughput: 279.85 MiB/s, 27.99 obj/s
Operation: PUT, 15%, Concurrency: 20, Ran 5m0s.
* Throughput: 89.86 MiB/s, 8.99 obj/s
Operation: STAT, 30%, Concurrency: 20, Ran 5m0s.
* Throughput: 18.63 obj/s
Cluster Total: 369.74 MiB/s, 61.79 obj/s, 0 errors over 5m0s.
หากต้องการดูสถิติคำขอแบบแบ่งกลุ่ม ให้ใช้พารามิเตอร์ --analyze.v
warp analyze --analyze.v warp-mixed-2023-10-16[102354]-l70a.csv.zst
18642 operations loaded... Done!
Mixed operations.
----------------------------------------
Operation: DELETE - total: 1854, 10.0%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 6.19 obj/s
Requests considered: 1855:
* Avg: 104ms, 50%: 30ms, 90%: 207ms, 99%: 1.355s, Fastest: 1ms, Slowest: 4.613s, StdDev: 320ms
----------------------------------------
Operation: GET - total: 8388, 45.3%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.12 +0500 +05
* Throughput: 279.77 MiB/s, 27.98 obj/s
Requests considered: 8389:
* Avg: 221ms, 50%: 106ms, 90%: 492ms, 99%: 1.739s, Fastest: 8ms, Slowest: 8.633s, StdDev: 383ms
* TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 171ms, 99th: 669ms, Worst: 4.783s StdDev: 163ms
* First Access: Avg: 240ms, 50%: 105ms, 90%: 511ms, 99%: 2.08s, Fastest: 12ms, Slowest: 8.633s, StdDev: 480ms
* First Access TTFB: Avg: 88ms, Best: 2ms, 25th: 24ms, Median: 38ms, 75th: 64ms, 90th: 179ms, 99th: 919ms, Worst: 4.783s StdDev: 199ms
* Last Access: Avg: 219ms, 50%: 106ms, 90%: 463ms, 99%: 1.782s, Fastest: 9ms, Slowest: 8.633s, StdDev: 416ms
* Last Access TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 161ms, 99th: 657ms, Worst: 4.783s StdDev: 176ms
----------------------------------------
Operation: PUT - total: 2688, 14.5%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 89.83 MiB/s, 8.98 obj/s
Requests considered: 2689:
* Avg: 1.165s, 50%: 878ms, 90%: 2.015s, 99%: 5.74s, Fastest: 99ms, Slowest: 8.264s, StdDev: 968ms
----------------------------------------
Operation: STAT - total: 5586, 30.2%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.113 +0500 +05
* Throughput: 18.63 obj/s
Requests considered: 5587:
* Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 80ms, Fastest: 0s, Slowest: 245ms, StdDev: 17ms
* First Access: Avg: 14ms, 50%: 10ms, 90%: 33ms, 99%: 69ms, Fastest: 0s, Slowest: 203ms, StdDev: 16ms
* Last Access: Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 74ms, Fastest: 0s, Slowest: 203ms, StdDev: 17ms
Cluster Total: 369.64 MiB/s, 61.77 obj/s, 0 errors over 5m0s.
Total Errors:0.
กลับไปที่สารบบ
ได้รับอนุญาตภายใต้ Apache License เวอร์ชัน 2.0 ("ใบอนุญาต"); คุณไม่สามารถใช้ไฟล์นี้ได้เว้นแต่จะเป็นไปตามใบอนุญาต คุณสามารถขอรับสำเนาใบอนุญาตได้ที่
http://www.apache.org/licenses/LICENSE-2.0
เว้นแต่กฎหมายที่ใช้บังคับกำหนดหรือตกลงเป็นลายลักษณ์อักษร ซอฟต์แวร์ที่เผยแพร่ภายใต้ใบอนุญาตนี้จะถูกแจกจ่าย "ตามที่เป็น" โดยไม่มีการรับประกันหรือเงื่อนไขใดๆ ทั้งโดยชัดแจ้งหรือโดยนัย ดูใบอนุญาตสำหรับภาษาเฉพาะที่ควบคุมการอนุญาตและข้อจำกัดภายใต้ใบอนุญาต
ข้อความของหน้านี้พร้อมสำหรับการแก้ไขและนำกลับมาใช้ใหม่ได้ภายใต้เงื่อนไขของ Creative Commons Attribution-Sharealike 3.0 Unported License และ GNU Free Documentation License (ไม่มีเวอร์ชัน โดยไม่มีส่วนที่ไม่เปลี่ยนแปลง ข้อความปกหน้า หรือข้อความปกหลัง)
กลับไปที่สารบบ
