Limiti per i database partizionati

I database partizionati hanno limiti sul numero di indici e sulla dimensione totale di tutti i documenti con la stessa chiave di partizione tutti i documenti con la stessa chiave di partizione.

Le interrogazioni con partizione hanno un timeout forzato dal servizio più breve rispetto alle interrogazioni globali e un limite minore sul totale dei documenti che possono essere recuperati in una sola volta e un limite minore al totale dei documenti che possono essere recuperati in una sola richiesta HTTP richiesta.

Per maggiori dettagli su queste restrizioni, consultare il sito IBM Cloudant.

Motivi per utilizzare un database partizionato

I database partizionati sono ideali quando l'applicazione trae vantaggio dal raggruppamento di documenti correlati e necessita di prestazioni di interrogazione prevedibili e scalabili.

Un database partizionato consente di eseguire sia query a livello di partizione che query globali. L'interrogazione su partizione sfrutta la co-locazione dei documenti con una determinata chiave di partizione, consentendo prestazioni di interrogazione più efficienti e scalabili una determinata chiave di partizione, consentendo prestazioni di interrogazione più efficienti e scalabili. Per i carichi di lavoro che possono essere espressi in termini di chiave di partizione, ciò può ridurre significativamente la latenza delle query e i costi ridurre significativamente la latenza delle query e i costi.

Il partizionamento è particolarmente utile quando l'applicazione necessita di prestazioni prevedibili su scala prestazioni prevedibili su scala. Le interrogazioni con partizione che utilizzano in modo efficace gli indici indici rimangono veloci anche quando il set di dati cresce e possono scalare in modo efficiente fino a 64 shard. Questo fa sì che i database partizionati siano particolarmente adatti a carichi di lavoro ad alta velocità e bassa latenza.

In genere, quando l'insieme di dati richiede molti shard del database, le applicazioni usano query con scansione a partizione per le operazioni sensibili alla latenza, mentre le query globali sono riservate a operazioni meno critiche in termini di tempo, come l'elaborazione batch.

Motivi per cui i database partizionati potrebbero non essere adatti

I database partizionati richiedono un'attenta modellazione dei dati e possono richiedere la duplicazione degli indici indici. Per molti casi d'uso, questo sforzo in più non ripaga.

Sebbene i database partizionati offrano vantaggi in termini di prestazioni se usati in modo appropriato, introducono vincoli che potrebbero non essere adatti a tutti i carichi di lavoro. È necessario definire una chiave di partizione significativa per le applicazioni, che raggruppi i documenti correlati e documenti correlati e che supporti un'interrogazione efficiente. Se ogni documento ha una chiave unica o se le chiavi di partizione sono troppo poche, è probabile che i database partizionati abbiano prestazioni peggio dei database non partizionati.

Le query con partizione richiedono la creazione di indici partizionati. Questo può di indici globali e partizionati, a seconda dei modelli di accesso dell'applicazione dell'applicazione.

Determinare l'idoneità dei database partizionati

Ora si conoscono i vantaggi e gli svantaggi dei database partizionati, il passo successivo consiste nel capire se il vostro modello di dati funzionerà bene con un database database partizionato.

Valutate il vostro modello di dati e le vostre esigenze applicative rispetto a questi criteri per per determinare l'idoneità dei database partizionati:

1. È essenziale un'elevata cardinalità delle chiavi di partizione: il numero di chiavi di partizione distinte deve essere di gran lunga superiore al numero di frammenti.
2. Il carico delle query deve essere distribuito in modo uniforme: se la maggior parte delle query si rivolge a un'unica chiave di partizione, si possono creare hot-spot e peggiorare le prestazioni.
3. Le chiavi di partizione devono raggruppare i documenti correlati: se ogni chiave corrisponde a un solo documento, la partizione offre pochi vantaggi.

Creazione di database e indici partizionati

È necessario decidere se partizionare al momento della creazione del database. Quando si crea un database, utilizzare il parametro della stringa di query partitioned per specificare se il database deve essere partizionato. L'impostazione predefinita per partitioned è false.

Allo stesso modo, un indice può essere globale o partizionato creare un indice utilizzando il campo partitioned nel documento di progettazione. Tutti tutti gli indici del documento di progettazione ereditano il campo partitioned del documento di progettazione del documento di progettazione. Quando si esegue un'interrogazione su un indice partizionato, si utilizzano query che includono la chiave di partizione da interrogare nella richiesta.

Il tipo di partizionamento di un indice o di un database non può essere modificato dopo la sua creazione.

Le query con scansione della partizione possono essere eseguite solo su indici partizionati. Allo stesso modo, possono essere eseguite solo su indici globali.

{
  "options": {
    "partitioned": false
  },
  "views": {
    "by-device": {
      "map": "function(doc) { emit(doc.deviceID, doc.infrastructureID) }"
    }
  }
}

{
  "options": {
    "partitioned": true
  },
  "views": {
    "by-device": {
      "map": "function(doc) { emit(doc.deviceID, doc.infrastructureID) }"
    }
  }
}

Tutorial sui database partizionati

I database partizionati possono essere difficili da capire in astratto. Potete vedere i concetti in azione in questi due esempi:

1. Leggete Creazione di uno storico IoT utilizzando database partizionati per un'immersione profonda nei database partizionati con esempi in diversi linguaggi di programmazione.
2. Leggete i database partizionati e Node.js in questo articolo del blog che include come creare un database partizionato, ricerche, viste e un indice globale.