Alla moderna databassystem med unicode-stöd kommer att kunna hantera detta enkelt, prestationsvinster kommer att göras i optimeringen av index och ett korrekt databasschema. Att dela upp saker i flera tabeller / databaser med hjälp av naturliga kluster hjälper också till med prestanda.

Det handlar inte bara om responstid som begär data utan också uppdatering. För en massbelastning av flera objekt tyckte jag generellt sett att det var mycket bättre att inaktivera indexering tills laddningen är klar, sedan indexera igen ... och ännu bättre att gå till mindre undertabeller med logiska kluster.

Prova svårast att undvika att använda strängar / varchar / guidvärden som en nyckel i ett index. Använd en int eller int64. Jag vet att uuid är "statistiskt unika" och verkar som en bra sak att använda för ett unikt ID ... men kollisioner händer, och du måste vara beredd på dem och kostnaden för att kontrollera en. Om du behöver indexera på något vanligt är det bättre att placera det vanliga i en separat tabell och länka till posten med hjälp av ett heltal främmande nyckel och indexera det främmande nyckelfältet.

Varför inte en NOSQL-databas?

Jag tror att det kan finnas bättre svarstider på en dokumentbaserad no-sql-databas som MongoDB. Det gör det möjligt att fritt forma (tänk dig att det finns hotell som till exempel inte har alla fält du letar efter). Dokumenten och replikering är väldigt enkelt, vilket ger ett integritetslager, eftersom det är möjligt att ha replikuppsättningar i olika servrar som är transparenta för programmeraren.

Sagt, du måste vara riktigt försiktig med datastrukturen, eftersom det inte finns några strukturkontroller eller PK eller FK.

Postgres JSONB

Om du skrapar olika typer av data från olika källor för att lagras tillsammans men tillräckligt varierande eller ändras tillräckligt ofta för att du inte vill definiera specifika tabeller för varje källa, och de strukturerade uppgifterna du får är tillräckligt enkla för att representeras som JSON, då föreslår jag att du överväger Postgres.

De senaste versionerna av Postgres har en ny inbyggd datatyp som heter JSONB, där B betyder binär. När du skickar in ett JSON-värde analyserar Postgres det i de olika fälten och lagrar dessa delar på ett intelligent sätt i ett internt definierat binärt format. Denna process ger Postgres möjlighet att indexera JSON-fälten. Det betyder onda snabba prestanda som kan överträffa olika “NO-SQL” -system. Och till skillnad från de andra systemen får du ACID -kompatibel tillförlitlighet och dataintegritet med Postgres.

Denna JSONB-typ ersätter PostSgres ursprungliga JSON-stöd liksom dess äldre HSTORE-typ.

För mer information, se:

• Förklaring av JSONB introducerad av PostgreSQL
• Vad är nytt i Postgres 9.4
• Vad är nytt i Postgres 9.5
• NoSQL med PostgreSQL 9.4 och JSONB
• Prestanda av JSONB-typ i PostgreSQL 9.4
• PostgreSQL 9.4: s hemliga vapen? JA, DET ÄR ETT NYTT FILFORMAT!

Kinesisk text

Postgres kan hantera kinesisk text, med fullt stöd av Unicode. Var noga med att skapa databasen / katalogen för att specificera UTF-8 -kodning.

Naturligtvis måste databasdrivrutinen och klientappen också stödja UTF- 8.

Datavolym

Postgres kan enkelt hantera tiotals miljoner rader och infogar eller uppdaterar en miljon i veckan.

Om du laddar många rader samtidigt, titta på alternativ till att ringa INSERT en rad i taget, till exempel kommandot COPY .

Postgres är som standard konfigurerad för att inte påverka värdmaskinen negativt. Om du vet att du har ytterligare minne och CPU tillgängligt kan du utforska de olika Postgres-inställningarna.