Skalning NoSQL - dummies

Ett vanligt inslag i NoSQL-system är deras förmåga att skala över många råvararservrar. Dessa relativt billiga plattformar innebär att du kan skala upp databaser genom att lägga till en ny server istället för att ersätta gammal hårdvara med ny, kraftfullare hårdvara i ett enda skott.

Det finns högvolym användningsfall som snabbt kommer att tvinga dig att skala ut. Dessa inkluderar

• Du får statusrapporter och loggmeddelanden från ett IT-landskap. Detta scenario kräver snabba ingestider, men det kräver förmodligen inte avancerat analysstöd.

• Du vill ha snabb cachning för komplexa frågor. Kanske vill du få de senaste nyheterna på en webbplats. Här läser cachar framträdande över förfrågan eller ingest hastigheter.

Det enda som är gemensamt för alla NoSQL-databaser är att du inte kan förlita dig på publicerade data - ingen av det - för att ta reda på vad prestationen sannolikt kommer att vara på dina data, för eget bruk.

Du kan verkligen inte lita på en viss databasleverantörs löfte om prestanda! Många leverantörer citerar höga intagshastigheter mot ett konstgjort användningsfall som inte är en realistisk användning av databasen, som bevis på deras databas överhöghet.

Problemet är emellertid att dessa samma studier helt kan ignorera sökhastigheten. Vad är meningen med att lagra data om du aldrig använder den?

Dessa studier kan också göras på system där nyckelfunktioner är inaktiverade. Säkerhetsindex kanske inte aktiveras, eller kanske ACID-transaktionsstöd är avstängt under studien så att data sparas snabbt, men det finns ingen garanti för att den är säker.

Allt detta innebär att du måste göra din egen testning, vilket är tillräckligt enkelt, men var noga med att testet är så nära ditt slutliga system som möjligt. Det finns till exempel ingen anledning att testa en enda server om du planerar att skala till 20 servrar. Särskilt var noga med att ha en exakt blandning av inmatning, modifiering och frågande data.

Överväg att fråga din NoSQL-leverantör om dessa frågor:

• Kan du se till att alla storlekar och prestationsfigurer citerade är för system som säkerställer ACID-transaktioner under intag som stöder realtidsindexering och som innehåller en realistisk blandning av intag och läsning / fråga förfrågningar?

• Ger din produkt funktioner som gör det enkelt att öka serverns kapacitet?

• Ger din produkt funktioner som gör det enkelt att ta bort oanvänd serverkapacitet?

• Är din produkts sökhastighet begränsad av hur mycket information som ska cachas i RAM?

• Använder din produkt en minneskarta strategi som kräver att alla index hålls i RAM för tillräcklig prestanda (minneskortning betyder att den maximala mängd data som lagras är densamma som mängden fysiskt RAM installerat)?

• Kan din databas upprätthålla andra sekunders svarstidstider när du mottar högfrekventa uppdateringar?

• Säkerställer systemet att ingen nedetid krävs för att lägga till eller ta bort serverkapacitet?

• Säkerställer systemet att information omedelbart är tillgänglig för fråga efter att den läggs till i databasen?

• Säkerställer systemet att datasäkerheten bibehålls utan att det påverkar sökhastigheten negativt?

• Säkerställer systemet att databasens skala och utskalningsfunktioner är skriptbara och att de kommer att integreras med din valda serverleveransprogramvara (till exempel VMWare och Amazon Cloud Formation)?