Necessità di memorizzare grandi quantità di dati sul dispositivo Android, pensando di andare OODB

Question

Al momento sto lavorando su un progetto che si basa su Android. Senza entrare in molti dettagli, il software verrà eseguito su un dispositivo su misura. L'hardware non cambierà mai e sarà sempre la stessa. Questo è un vantaggio decisivo:)

Detto questo, questo progetto ci sta richiedendo per immagazzinare carichi e carichi di dati sul dispositivo - verso l'alto di righe 3m in alcune tabelle. maniglie SQLite scansione di questo numero di righe bene per noi, il problema arriva quando iniziamo a fare complessa unisce per riportare tutti i dati correlati di cui abbiamo bisogno. Abbiamo pensato a denormalizing il database, ma temiamo che spingerà il database di fuori del regno di utilizzabile.

Stiamo esaminando utilizzando un database Object Oriented, qualcosa come db4o o NeoDatis. La nostra speranza è che memorizzando gli oggetti possiamo sbarazzarci delle nostre relazioni a livello di riga e memorizzarli sull'oggetto (proprio come OOP). Il problema è che non sono stati in grado di trovare qualsiasi benchmark relativi alle prestazioni (almeno quelli non recenti) di questi ODBs in esecuzione e in uso su Android.

Qualcuno ha qualche esperienza con OODBs su Android e / o con l'archiviazione e l'accesso a questo grande quantità di dati? Se è così tutto il consiglio si potrebbe fornire sarebbe molto apprezzato.

- Modifica

Ecco un esempio del problema che stiamo affrontando. Non è legato alla nostra applicazione (il mio NDA dice che posso non postare nulla specifico), ma questo esempio rappresenta bene il problema.

Immaginate che stiamo costruendo un programma che permette ogni veicolo che sta guidando il New Jersey Turnpike in un dato momento. Per ogni dato macchina abbiamo bisogno di monitorare la macchina Marca e modello, quante persone sono in macchina e che cosa è il demografica dei persone in auto. Quindi, in pratica si finisce con dati che sembra qualcosa di simile -

auto

id | colore | make_id | in_toll_lane | model_id

make

id | nome

modello

id | nome | make_id

car_person

id | età | sex | is_driver | car_id

toll_lanes

id | cars_in_line | ideal_cars_in_line | ideal_occupants

Questi dati sta per essere cambiare di frequente. E 'anche intenzione di ottenere piuttosto enorme, in quanto non vi sono dubbi un sacco di gente guida lungo la NJ Pike in un dato momento.

Con questi dati abbiamo bisogno di essere in grado di un'istantanea, a richiesta, di chi ha la guida sul luccio. Abbiamo anche bisogno di essere in grado di prendere un colpo a scatto di tutti i maschi che sono alla guida, o di tutte le femmine in autostrada. Abbiamo anche bisogno di essere in grado di cercare per età, sesso, marca, modello, ecc.

Ora immaginiamo abbiamo bisogno di capire cosa pedaggio corsia ogni auto dovrebbe andare in base al numero di persone in macchina, il numero ideale di occupanti, il numero di auto già in linea, e il numero ideale di vetture che dovrebbero essere in linea.

Questo è un esempio molto semplice, anche se abbastanza rappresentativa del nostro problema.

- Fine Modifica

Grazie in anticipo!

Answer 1

Ecco alcune osservazioni, anche se ho il sospetto che non vi aiuterà direttamente.

Credo che le domande principali sono: stai andando a scoprire le tue relazioni complesse tramite la logica runtime applicativo come eventi generano o dati delle modifiche o stai andando ad avere per dati di dettaglio solo in un negozio e poi scoprire un-anticipare le relazioni tramite interrogazione ?

Se la logica di business compilerà il modello allora si può facilmente creare viste modello in base delle vostre diverse fette di modello di dati per esempio collezioni che conoscono tutte le auto con conducenti di sesso maschile / femminile. In questo caso, in fondo, le vostre relazioni sono semi-statica raramente cambia (mentre i valori dei dati all'altra estremità di questi rapporti sono probabilmente cambiando molto). Se questo è il caso, allora perché cercare di memorizzare i dati in un database di tecnologia che sta costringendo di ricalcolare costantemente i rapporti (join). E 'solo uno spreco di CPU ed è il motivo per cui si vedrà lo scarso rendimento come il modello ottiene complesso. Quindi, una volta che si risponde a queste domande, sarà molto chiaro se ODB o RDB è la scelta migliore.

Ora la questione diventa, che cosa verrà eseguito su Android e gestire i dati enormi? Questo è dove penso che non posso fare. Io lavoro a chi ha Versant (db4o e Versant) ODB. Ora db4o verrà eseguito su Android, ma è in realtà scelta giusta per i dati enorme ... No. A meno che non avete molto di dati che possono essere in database separati e accessibili solo in isolamento isolato e non suona per me come è il vostro situazione. Il nostro altro database, Versant è mean't per gestire enormi di dati in tempo quasi reale, ma solo il cliente è al 100% Java, il server è scritto in C, quindi non verrà eseguito su Android.

Credo che hai bisogno di fare qualche ricerca per vedere chi ha ODB che può gestire dati enorme su Android.

Best, -Robert

Answer 2

Non dice molto circa le vostre esigenze di accesso ai dati o dei dati Loadout davvero.

Se hai 3M righe principali, e poi una serie di tavoli di foglie più piccole, allora si può solo fare bene mettendo in cache tutte le tabelle foglia di RAM, e di "unirsi" per loro mano. Molti sistemi hanno molto piccoli tavoli foglia (in particolare rispetto ai dati principale), in modo da caricare in RAM e poi semplicemente alzando lo sguardo quando si carica la riga può essere una grande vittoria.

Ovviamente, non farlo con i principali genitore> Relazioni bambino, ma se è possibile eliminare la foglia si unisce, poi una lettura diventano un unico join tra il genitore e il bambino, piuttosto che una mezza dozzina di genitore, figlio, e tavoli foglia.

Anche se questo non funziona per tutti i tavoli di foglie, se funziona per una larga maggioranza, può ben essere sufficiente a farti sopra la gobba.

Answer 3

Parlando per db4o:. Corriamo tutti i nostri test di regressione su Android perché pensiamo che diventerà una piattaforma molto importante per db4o

db4o funziona molto bene per l'ordine di grandezza di 3 milioni di oggetti.

Stiamo facendo test di benchmark rispetto alle altre banche dati su http://www.polepos.org/ e noi sarà presto rilasciare una nuova versione del benchmark in cui si corre una configurazione complessa, anche contro SqlLite. Porting il punto di riferimento per Android è anche una considerazione.

Se si unisce stanno uccidendo le prestazioni e si dispone di dati molto eterogenei, db4o potrebbe funzionare meglio di un database relazionale.

La tua app sembra interessante. Se hai bisogno di aiuto valutare db4o, dammi solo un grido.

Answer 4

Jason: per raggiungere qualsiasi membro db4o è necessario utilizzare questo modello: Cognome @ db4o.com Migliore!