GridFS รวดเร็วและเชื่อถือได้เพียงพอสำหรับการผลิตหรือไม่?

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

Benchmarks ที่มี GridFS ให้บริการโดย nginx ระบุว่ามันไม่เร็วเท่ากับระบบไฟล์ปกติที่ให้บริการโดย nginx

เกณฑ์มาตรฐานกับ nginx

มีใครบ้างที่ใช้ GridFS อยู่แล้วในสภาพแวดล้อมการใช้งานจริงหรือจะใช้สำหรับโครงการใหม่

ฉันใช้ gridfs ในที่ทำงานบนเซิร์ฟเวอร์ของเราซึ่งเป็นส่วนหนึ่งของเว็บไซต์เปรียบเทียบราคาที่มีสถิติการเข้าชมที่น่ายกย่อง (มีผู้เข้าชมประมาณ 25,000 คนต่อวัน) เซิร์ฟเวอร์มี RAM ไม่มาก 2gigs และแม้แต่ cpu ก็ไม่เร็วมาก (Core 2 duo 1.8Ghz) แต่เซิร์ฟเวอร์มีพื้นที่เก็บข้อมูลมากมาย: 10Tb (sata) ในการกำหนดค่า raid 0 งานที่เซิร์ฟเวอร์ทำนั้นง่ายมาก:

ผลิตภัณฑ์แต่ละชิ้นในเครื่องเปรียบเทียบราคาของเรามีรูปภาพ (มีผลิตภัณฑ์ประมาณ 10 ล้านรายการตามฐานข้อมูลผลิตภัณฑ์ของเรา) และหน้าที่ของเซิร์ฟเวอร์คือการดาวน์โหลดรูปภาพปรับขนาดจัดเก็บไว้ใน gridfs และส่งไปยังเบราว์เซอร์ของผู้เยี่ยมชม .. หากไม่มีอยู่ในกริด ... หรือ ... ส่งไปยังเบราว์เซอร์ผู้เยี่ยมชมหากเก็บไว้ในตารางแล้ว ดังนั้นสิ่งนี้อาจเรียกได้ว่าเป็น 'สคีมา cdn ดั้งเดิม'

เราได้จัดเก็บและประมวลผลภาพ 4 ล้านภาพบนเซิร์ฟเวอร์นี้ตั้งแต่เปิดใช้งาน การปรับขนาดและจัดเก็บสิ่งต่างๆทำได้โดยสคริปต์ php ธรรมดา ๆ ... แต่แน่นอนว่าสคริปต์ python หรือ java อาจเร็วกว่า

ขนาดข้อมูลปัจจุบัน: 11.23g

ขนาดเก็บปัจจุบัน: 12.5g

ดัชนี: 5

ขนาดอินเด็กซ์: 849.65m

เกี่ยวกับความน่าเชื่อถือ: นี่น่าเชื่อถือมาก เซิร์ฟเวอร์ไม่โหลดขนาดดัชนีก็โอเคการสืบค้นรวดเร็ว

เกี่ยวกับความเร็ว: แน่นอนว่ามันไม่เร็วเท่ากับการจัดเก็บไฟล์ในเครื่องหรืออาจจะช้ากว่า 10% แต่ก็เร็วพอที่จะใช้แบบเรียลไทม์แม้ว่าจะต้องประมวลผลภาพก็ตามซึ่งในกรณีของเรานั้นขึ้นอยู่กับ php มาก เวลาในการบำรุงรักษาและการพัฒนาก็ลดลงเช่นกันการลบภาพเดียวหรือหลายภาพทำได้ง่ายมากเพียงแค่ค้นหาฐานข้อมูลด้วยคำสั่งลบง่ายๆ สิ่งที่น่าสนใจอีกประการหนึ่ง: เมื่อเรารีบูตเซิร์ฟเวอร์เก่าของเราด้วยที่เก็บไฟล์ในเครื่อง (ดังนั้นล้านไฟล์ในหลายพันโฟลเดอร์) บางครั้งก็ค้างเป็นเวลาหลายชั่วโมงทำให้ระบบทำการตรวจสอบความสมบูรณ์ของไฟล์ (ซึ่งใช้เวลาหลายชั่วโมง ... ) เราไม่มีปัญหานี้อีกต่อไปกับ gridfs ขณะนี้ภาพของเราถูกเก็บไว้ใน mongodb ชิ้นใหญ่ (ไฟล์ 2gb)

ดังนั้น ... ในใจ ... ใช่ gridfs รวดเร็วและเชื่อถือได้เพียงพอที่จะใช้ในการผลิต

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

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

โปรดทราบเกี่ยวกับการซ่อมแซมฐานข้อมูลขนาดใหญ่ - ระบบใหม่ที่เรากำลังพัฒนา mongo ไม่ได้ออกอย่างหมดจดและการซ่อมแซม GridFS ขนาด 7TB ดูเหมือนว่าจะใช้เวลา 130 ชม.

ด้วยเหตุนี้ฉันจึงคิดว่าจะเปลี่ยนไปใช้ OpenStack Swift หรือ Ceph ถึงตอนนั้นก็ดีแล้ว และโมดูล nginx-gridfs นั้นหวาน

โมดูล nginx-gridfs ของ mdirolf นั้นยอดเยี่ยมและค่อนข้างง่ายในการติดตั้ง เรากำลังใช้มันในการผลิตที่paint.lyเพื่อให้บริการภาพวาดทั้งหมดและยังไม่มีปัญหาใด ๆ

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

1. ไดรเวอร์ในภาษาต่างๆอาจอ่านทั้งไฟล์ (เช่นชิ้นส่วน) เมื่ออ่านส่วนเล็ก ๆ ของไฟล์
2. การแก้ไขไฟล์อาจส่งผลต่อชิ้นส่วนทั้งหมดและเพิ่มการโหลดฐานข้อมูลหากระบบไฟล์ของคุณเติบโตขึ้นคุณจะต้องตัดสินใจที่จะแบ่ง gridfs ระวัง! ไม่รับประกันความสม่ำเสมอเมื่อเริ่มต้นการชาร์ด!

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

หวังว่านี่จะช่วยได้