2011-10-20, 18:20
#1
Hej,
Jag har ett problem med läckande GridFS-filer i MongoDB. Pratar med MongoDB via Python's pymongo, men det tror jag egentligen inte är relevant.
Problemet grundar sig i MongoDBs gräns på 16 MB stora dokument. Datan vi skall spara blir ibland större, och man måste då ta till GridFS. Detta görs f.t. genom att jag, precis innan ett dokument skickas till MongoDB undersöker dokumentet, och letar upp element som verkar farligt stora, skapar GridFS-filer för dem och sparar en referens till filen istället.
Tänk ett dokument: {_id: 1, foo: {bar: <20MB data>}}
Detta undersöks, och resulterar i slutändan i:
- En ny GridFS-fil
- Dokumentet: {_id: 1, foo: {bar: {typ: ey-kika-i-gridfs, id: <id på gridfs-fil>}}}
Allt frid och fröjd, när jag läser upp dokumentet ser jag den magiska "typ"-flaggan, och läser upp filen.
Nu kommer dock, helt från vänster, annan ondskefull kod och gör en av två följande operationer:
- remove({_id: 1})
- update({_id: 1}, {$set: {foo.bar: "gurkmos"}})
Vips så har min länk till GridFS-filen försvunnit - men filen i sig är kvar. Läckage.
Varje angrepp jag försöker göra på problemet resulterar i kod som måste kunna inte bara datamodellen för alla dokument som kan tänkas få GridFS-filer länkade till sig, utan till och med även MongoDBs olika operatorer (så den vet vilka "farliga" operatorer den måste hålla utkik efter).
Någon bra ide? Jag kan leva med ett cron-job som letar efter borttappade länkar lite då och då. Det är inte tokviktigt att överbliven data rensas omedelbart. Men jag lyckas inte formulera en fråga som hittar referenser på godtyckligt djup i ett dokument (min MongoDB fu är svag).
Lutar för tillfället åt att bygga ett index med alla dokument som någonstans innehåller en GridFS-länk, och varje gång man pillar på ett dokument som förekommer i det indexet så undersöker man det i detalj efteråt för att se om en fil har blivit avlänkad... men det känns väldigt bökigt, så jag hoppas på att komma undan billigare på något vis.
Jag har ett problem med läckande GridFS-filer i MongoDB. Pratar med MongoDB via Python's pymongo, men det tror jag egentligen inte är relevant.
Problemet grundar sig i MongoDBs gräns på 16 MB stora dokument. Datan vi skall spara blir ibland större, och man måste då ta till GridFS. Detta görs f.t. genom att jag, precis innan ett dokument skickas till MongoDB undersöker dokumentet, och letar upp element som verkar farligt stora, skapar GridFS-filer för dem och sparar en referens till filen istället.
Tänk ett dokument: {_id: 1, foo: {bar: <20MB data>}}
Detta undersöks, och resulterar i slutändan i:
- En ny GridFS-fil
- Dokumentet: {_id: 1, foo: {bar: {typ: ey-kika-i-gridfs, id: <id på gridfs-fil>}}}
Allt frid och fröjd, när jag läser upp dokumentet ser jag den magiska "typ"-flaggan, och läser upp filen.
Nu kommer dock, helt från vänster, annan ondskefull kod och gör en av två följande operationer:
- remove({_id: 1})
- update({_id: 1}, {$set: {foo.bar: "gurkmos"}})
Vips så har min länk till GridFS-filen försvunnit - men filen i sig är kvar. Läckage.
Varje angrepp jag försöker göra på problemet resulterar i kod som måste kunna inte bara datamodellen för alla dokument som kan tänkas få GridFS-filer länkade till sig, utan till och med även MongoDBs olika operatorer (så den vet vilka "farliga" operatorer den måste hålla utkik efter).
Någon bra ide? Jag kan leva med ett cron-job som letar efter borttappade länkar lite då och då. Det är inte tokviktigt att överbliven data rensas omedelbart. Men jag lyckas inte formulera en fråga som hittar referenser på godtyckligt djup i ett dokument (min MongoDB fu är svag).
Lutar för tillfället åt att bygga ett index med alla dokument som någonstans innehåller en GridFS-länk, och varje gång man pillar på ett dokument som förekommer i det indexet så undersöker man det i detalj efteråt för att se om en fil har blivit avlänkad... men det känns väldigt bökigt, så jag hoppas på att komma undan billigare på något vis.
