Caricamento / recupero rapido per soluzioni dati BLOB

Question

Caricamento / recupero rapido per soluzioni dati BLOB

#1 da (2 voti)

4

problema

Attualmente sto studiando una soluzione per consentire il caricamento veloce (e il recupero) di dati che possono essere implementati tramite NoSQL / SQL o un file system su un server Centos con 64 core CPU con 529 GB di ram.

Il caso è il seguente:

Gli utenti hanno la necessità di tenere traccia dei dati caricati su un server, quindi a un certo punto recuperare tutti i dati memorizzati sul server pronti per l'elaborazione su un sistema diverso.

Le operazioni sui dati riguardano il caricamento / importazione e il download / esportazione.

ogni record caricato varierà tra 4mb-5mb

Opzioni

Per gestire la grande quantità di dati, credo che il server che abbiamo sia più che efficiente per gestire il carico. Tuttavia, stiamo cercando una soluzione che assicuri che la scalabilità e il backup non costituiranno un problema in futuro. Alcune opzioni che ho considerato sono:

mongoDB (GridFS per raggruppare i dati).
Database Oracle (compressione LOB e datafield)

Quali sono le tue opinioni sull'approccio migliore da adottare per questo progetto? Qualcuno ha avuto un dilemma simile e cosa è stato fatto per risolverlo?

Grazie in anticipo per il tuo aiuto.

Modifica più informazioni

I record stimati che ci aspettiamo sono 2400 come lo scenario peggiore 9600-12000mb in un giorno e arriveranno in una raffica. Gli utenti avranno bisogno di una sub-selezione di dati e saranno utilizzati su reti LAN gigabit aziendali con cavi Ethernet standard

database data-structures nosql blob

posta angrymuffins 25.10.2016 - 11:20

fonte

1 risposta

Leggi altre domande sui tag database data-structures nosql blob

Organizzazione di moduli maven e profili a molla Microservizi e ruoli utente

score 2 · Accepted Answer

Un'architettura scalabile dipende dal modo di pensare attraverso ogni componente e dal modo in cui interagiscono, non solo se un determinato componente hardware o software può soddisfare l'esigenza. E come ho detto in un commento, la ridondanza è la risposta standard sia alla scalabilità che alla durata.

Nel tuo caso, i volumi di dati non sono così grandi. Sono sicuro che il tuo hardware può gestirlo, usando Mongo o Oracle. Ma cosa succede se quel server va giù? O perde un disco? O i tuoi volumi crescono.

Ecco le tre aree che vorrei comprendere appieno:

Ingest

Quanti clienti si collegheranno contemporaneamente e quali sono le loro tolleranze per l'attesa? Qualsiasi singolo server potrebbe avere problemi con 2400 caricamenti simultanei, semplicemente a causa del cambio di contesto. La pratica standard consiste nell'avere un gruppo di server front-end con un servizio di bilanciamento del carico di fronte a loro.
Stai utilizzando un front-end HTTP o sono consentite altre tecnologie? Ad esempio, potresti scrivere direttamente in una coda?

archiviazione

Quali sono i requisiti per la durabilità e l'accessibilità e quali opzioni hai per soddisfare tali requisiti? Un volume RAID-5, ad esempio, gestirà un singolo errore del disco ma non un errore dell'host del database. I backup a caldo possono mitigare gli errori dell'host, ma richiedono configurazioni identiche (cioè due o più macchine con le stesse specifiche).
Un database semplificato può migliorare la scalabilità, ma richiede di nuovo hardware aggiuntivo (inclusi i backup).
Quanto tempo devono vivere i dati e quali sono i modelli di accesso a lungo termine? 12 GB / giorno sono veramente piccoli se devono vivere solo una settimana, ma diventano 4 TB / anno, il che non è poi così piccolo.
Hai bisogno di mantenere i dati all'interno del tuo impianto fisico o puoi utilizzare il cloud storage?

Recupero

Gli utenti recupereranno sottoinsiemi di dati in base a criteri o potranno accettare tutti i dati (magari con un intervallo di tempo) e filtrarli localmente? Il primo implica un database con qualche forma di linguaggio di query, mentre il secondo potrebbe essere implementato usando qualcosa come Kafka .
Hai bisogno di analisi avanzate nelle tue query (per esempio, mediane). Questo ti guiderà verso un DBMS SQL tradizionale rispetto a NoSQL (che richiederebbe di eseguire tale analisi sul client).

Finché non hai pensato a quei punti, è difficile se non impossibile dare una risposta valida in questo forum. Ma una cosa che suggerirei di guardare è un database distribuito come Cassandra .