Тук мога да отговоря само за MongoDB, няма да се преструвам, че знам много за HDFS и други подобни технологии.
Реализацията на GridFs е изцяло от страна на клиента в самия драйвер. Това означава, че няма специално зареждане или разбиране на контекста на обслужване на файлове в самия MongoDB, всъщност самият MongoDB дори не разбира, че това са файлове (http://docs.mongodb.org/manual/applications/gridfs/).
Това означава, че заявката за която и да е част от files или chunks събирането ще доведе до същия процес, както при всяка друга заявка, при което зарежда необходимите данни във вашия работен набор ( http://en.wikipedia.org/wiki/Working_set ), който представлява набор от данни (или всички заредени данни по това време), изисквани от MongoDB в рамките на даден период от време, за да поддържа оптимална производителност. Той прави това, като го поставя в RAM (добре технически, ОС го прави).
Друг момент, който трябва да се вземе предвид, е, че това е внедрен драйвер. Това означава, че спецификацията може да варира, но не мисля, че е така. Всички драйвери ще ви позволят да потърсите набор от документи от files колекция, която съхранява само метаданните на файловете, което ви позволява по-късно да обслужвате самия файл от chunks колекция с една заявка.
Това обаче не е важното, вие искате да обслужвате самия файл, включително неговите данни; това означава, че ще зареждате files колекция и нейните последващи chunks колекция във вашия работен комплект.
Имайки това предвид, вече попаднахме на първата пречка:
Ще се кешират ли файловете от gridfs в RAM и как това ще повлияе на производителността при четене и запис?
Производителността на четене на малки файлове може да бъде страхотна, директно от RAM; записите биха били също толкова добри.
За по-големи файлове не е така. Повечето компютри няма да разполагат с 600 GB RAM и е вероятно, всъщност съвсем нормално, да разполагат с дял от 600 GB от един файл на един mongod екземпляр. Това създава проблем, тъй като този файл, за да бъде обслужен, трябва да се побере във вашия работен комплект, но е невъзможно по-голям от вашата RAM; в този момент може да имате разбиване на страници ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ), при което сървърът просто греши на страницата 24/7, опитвайки се да зареди файла. Писанията тук също не са по-добри.
Единственият начин да заобиколите това е да започнете да поставяте един файл в много фрагменти :\ .
Забележка:още нещо, което трябва да имате предвид, е средният размер по подразбиране на chunks "chunk" е 256KB, така че това е много документи за файл от 600GB. Тази настройка е манипулируема в повечето драйвери.
Какво ще се случи с gridfs, когато се опитам да напиша няколко файла едновременно. Ще има ли заключване за операции за четене/запис? (Ще го използвам само като съхранение на файлове)
GridFS, тъй като е само спецификация, използва същите заключвания като всяка друга колекция, както за четене, така и за запис на ниво база данни (2.2+) или на глобално ниво (преди 2.2). Двете също си пречат един на друг, т.е. как можете да осигурите последователно четене на документ, в който се записва?
Имайки предвид това, съществува възможност за спор въз основа на спецификата на вашия сценарий, трафик, брой едновременни записвания/четения и много други неща, за които нямаме представа.
Може би има някои други решения, които могат да решат проблема ми по-ефективно?
Аз лично открих, че S3 (както каза @mluggy) във формат с намален излишък работи най-добре, като съхранява само част от мета данни за файла в MongoDB, подобно на използването на GridFS, но без колекцията от парчета, нека S3 се справя с цялото това разпространение, архивиране и други неща за вас.
Надявам се, че съм бил ясен, надявам се да помогне.
Редактиране:За разлика от това, което случайно казах, MongoDB няма заключване на ниво колекция, това е заключване на ниво база данни.
