Esiste un modo migliore per aggiornare collettivamente i record NoSQL?

3

Quando abbiamo iniziato la nostra applicazione abbiamo avuto la scelta di andare con il tradizionale database normalizzato MS-SQL o con un database NoSQL (RavenDB è ciò che abbiamo provato). Ecco una versione semplificata del nostro schema:

<Order OrderNumber="1000" OrderVersion="1" ...>
  <Products>
    <Product Code="X58" Price="$5.50" Quantity="3" ... />
    <Product Code="X70" Price="$9.99" Quantity="1" ... />
  </Products>
  <Contacts>
    <Contact ... />
    <Contact ... />
  </Contacts>
</Order>

Anche se avremmo potuto utilizzare un database MS-SQL, non lo abbiamo fatto perché volevamo che tutti i nostri dati per un ordine fossero conservati storicamente; non volevamo contattare il contatto, anche se avevano lo stesso nome e indirizzo perché, mentre potrebbe cambiare, l'ordine dovrebbe avere le informazioni di contatto al momento dell'acquisto . Inoltre, sì, potremmo avere i nostri prodotti FK invece di utilizzare il codice per fare riferimento al prodotto, ma i prodotti non vengono mai eliminati, e ancora ... se sono aggiornati, vogliamo acquisire le loro informazioni al tempo di acquisto . Fondamentalmente, ogni Ordine sembra essere un documento autonomo che non dovrebbe mai contare su FK.

OrderVersion serve solo per tenere traccia della nostra versione del processo quando l'ordine è stato creato, potremmo facilmente aver utilizzato OrderDate per monitorare il controllo delle versioni.

Comunque, quindi la nostra decisione era di andare con RavenDB. Abbiamo creato la nostra applicazione e il nostro sito web, e internamente lo stiamo testando. L'unico scenario a cui stiamo imbattendo in problemi è: "Come fai un aggiornamento collettivo su record buono come SQL?"

Ad esempio, se avessimo appena spinto il nostro codice in produzione durante la manutenzione offline e in qualche modo tutti i record da MA con codici postali che hanno uno zero iniziale (0) avevano lo zero tagliato (ovvero il codice postale ora leggeva 1234 invece di 01234 )?

Normalmente, applicheremo le patch immediatamente su un server fail-over alla volta e l'aggiornamento dei record sarebbe facile:

UPDATE c
SET c.ZipCode = ...
FROM Contact c
    INNER JOIN Order o ON c.OrderId = o.OrderId
WHERE o.Version = 1
  AND ...

Tuttavia, sembra che la migliore soluzione che potremmo trovare se usiamo RavenDB è quella di ottenere tutti i documenti, quindi aggiornare i record a livello di codice tramite un'app personalizzata per console C #. Sembra che TSQL sia molto più facile / veloce. Non sono sicuro se ci sia un modo migliore di cui non siamo a conoscenza, o si tratta di un difetto comune nell'uso di RavenDB (o di qualsiasi archivio di documenti NoSQL)?

La mia più grande preoccupazione è che, mentre la nostra app per console sembrava funzionare abbastanza bene con un campione di ordini da 100 K, cosa succede se arriviamo al punto di 50 milioni di ordini !? Oppure, è anche un problema con T-SQL che alla fine dovremmo incontrare con l'esempio che ho dato?

    
posta michael 02.09.2014 - 23:17
fonte

1 risposta

4

Wow, ci sono molte dichiarazioni estranee nella tua domanda. Penso di poterlo ridurre a:

How do I update documents in RavenDB?

Questa domanda ha già avuto risposta su StackOverflow qui e qui , che ti indicherà all'API Patching di RavenDB. C'è anche una vasta documentazione disponibile qui , e puoi anche avviare un'operazione di patch di massa da RavenDB Studio, come descritto qui . (Nessuna app personalizzata richiesta.)

Inoltre, non cadrebbe nella trappola di presupporre che il modo SQL Server sia necessariamente migliore. È solo diverso . Hai mai provato ad aggiornare record 50M + con una singola istruzione di aggiornamento in SQL Server? Penso che scoprirai che il modello di chiusura è abbastanza proibitivo. È probabile che si verifichino timeout o deadlock. Probabilmente dovresti implementare alcune operazioni di batching e retry. Con RavenDB, mentre potrebbe richiedere un po 'di tempo, ti assicuri almeno che l'operazione finirà alla fine e il tuo database rimarrà online durante il processo.

    
risposta data 03.09.2014 - 05:43
fonte

Leggi altre domande sui tag