sql >> Databasteknik >  >> RDS >> PostgreSQL

Finns det prestandaproblem när filer lagras i PostgreSQL?

Du har i princip två val. Du kan lagra data direkt i raden eller så kan du använda funktionen för stora objekt. Eftersom PostgreSQL nu använder något som heter TOAST för att flytta ut stora fält från tabellen bör det inte finnas någon prestationspåföljd för att lagra stora data i raden direkt. Det återstår en gräns på 1 GB i storleken på ett fält. Om detta är för begränsat eller om du vill ha ett streaming-API kan du använda funktionen för stora objekt, som ger dig något mer som fildeskriptorer i databasen. Du lagrar LO-ID:t i din kolumn och kan läsa och skriva från det ID:t.

Jag personligen skulle föreslå att du undviker anläggningen med stora objekt om du inte absolut behöver det. Med TOAST täcks de flesta användningsfall genom att bara använda databasen som du kan förvänta dig. Med stora föremål ger du dig själv ytterligare underhållsbörda, eftersom du måste hålla reda på de LO-ID:n du har använt och se till att koppla bort dem när de inte används längre (men inte tidigare) annars kommer de att sitta i din datakatalog som tar upp plats för alltid. Det finns också många anläggningar som har exceptionellt beteende runt sig, vars detaljer undkommer mig eftersom jag aldrig använder dem.

För de flesta människor är den stora prestationsstraffen förknippad med att lagra stor data i databasen att din ORM-mjukvara kommer att dra ut big data på varje fråga om du inte specifikt instruerar den att inte göra det. Du bör vara noga med att berätta för Hibernate eller vad du nu använder för att behandla dessa kolumner som stora och bara hämta dem när de specifikt efterfrågas.



  1. Använd `trim()` och `regexp_replace()` på textarray

  2. MySQL-index skapas långsamt (på EC2)

  3. Fel vid konvertering av datatyper vid import från Excel till SQL Server 2008

  4. Hoppa över vissa tabeller med mysqldump