Besoin de stocker beaucoup de données sur l'appareil Android, la pensée d'aller OODB

Question

Je travaille actuellement sur un projet qui est basé sur Android. Sans entrer dans de nombreux détails, le logiciel fonctionnera sur un appareil construit sur mesure. Le matériel ne changera jamais et sera toujours le même. C'est un avantage certain:)

Cela dit, ce projet nous oblige à stocker des charges et des charges de données sur le périphérique - de lignes de Upwards 3m dans certains tableaux. poignées SQLite ce balayage de lignes très bien pour nous, le problème vient quand nous commençons à faire des jointures complexes entre de ramener toutes les données connexes dont nous avons besoin. Nous avons pensé à dénormaliser la base de données, mais peur qui poussera la base de données en dehors du domaine du utilisable.

Nous examinons en utilisant une base de données orientée objet, quelque chose comme db4o ou NeoDatis. Nous espérons que par le stockage d'objets que nous pouvons nous débarrasser de nos relations au niveau de la ligne et de les stocker sur l'objet (comme POO). Le problème est que nous avons pas été en mesure de trouver des repères liés à la performance (au moins et pas les récentes) de ces ODBS en cours d'exécution et utilisés sur Android.

Quelqu'un at-il une expérience avec OODBs sur Android et / ou avec le stockage et l'accès à cette grande quantité de données? Dans ce cas les conseils que vous pourriez fournir serait grandement apprécié.

- Modifier

Voici un exemple du problème auquel nous sommes confrontés. Ce n'est pas lié à notre application (NDA ma dit que je ne peux pas spécifique après quoi que ce soit), mais cet exemple représente bien le problème.

Imaginez que nous construisons une application pour surveiller chaque véhicule qui est conduite sur le New Jersey Turnpike à un moment donné. Pour toute voiture étant donné que nous devons suivre la Marque de voiture et modèle, combien de personnes sont dans la voiture et ce qui est la situation démographique des personnes dans la voiture. Donc, fondamentalement, vous vous retrouvez avec des données qui ressemble à quelque chose comme -

voiture

id | couleur | make_id | in_toll_lane | model_id

make

id | nom

modèle

id | nom | make_id

car_person

id | âge | sexe | is_driver | car_id

toll_lanes

id | cars_in_line | ideal_cars_in_line | ideal_occupants

Ces données va être changer fréquemment. Il va aussi obtenir assez énorme, car il n'y a aucun doute beaucoup de gens qui conduisent sur le NJ Pike à un moment donné.

Avec ces données, nous devons être en mesure d'un tir pression, sur demande, de toute personne qui est conduite sur le brochet. Nous devons également être en mesure de prendre un coup de pression de tous les hommes qui conduisent, ou toutes les femmes sur l'autoroute à péage. Nous devons également être en mesure de rechercher selon l'âge, le sexe, marque, modèle, etc.

Maintenant, imaginez que nous devons comprendre ce péage voie dans chaque voiture devrait entrer en fonction du nombre de personnes dans la voiture, le nombre d'idéal des occupants, le nombre de voitures déjà en ligne, et le nombre d'idéal de voitures qui devrait être en ligne.

Ceci est un exemple très simple, mais assez représentatif de notre problème.

- Fin Modifier

Merci à l'avance!

Answer 1

Voici quelques observations, mais je pense qu'il ne vous aidera pas directement.

Je pense que les principales questions sont les suivantes: Vous allez découvrir vos relations complexes via la logique d'exécution d'applications comme événements génèrent ou des données de changement ou que vous allez devoir seulement des données de sauvegarde dans un magasin, puis découvrir non anticiper les relations via requête ?

Si votre logique métier remplira le modèle que vous pouvez facilement créer des vues à partir de modèles de vos différentes tranches du modèle de données par exemple collections qui connaissent toutes les voitures ayant les conducteurs mâles / femelles. Dans ce cas, au fond, vos relations sont semi-statiques sont rarement modifiés (alors que les valeurs de données à l'autre extrémité de ces relations changent probablement beaucoup). Si tel est le cas, alors pourquoi essayer de stocker les données dans une technologie de base de données qui vous oblige à recalculer en permanence les relations (JOIN). Il est juste un gaspillage de CPU et est la raison pour laquelle vous verrez les mauvaises performances que le modèle devient complexe. Donc, une fois que vous répondez à ces questions, il sera très clair si ODB ou RDB est le meilleur choix.

Maintenant, la question devient, ce qui va fonctionner sur Android et gérer des données énormes? C'est là que je pense que je ne peux pas aider. Je travaille à qui a Versant (db4o et Versant) ODB. Maintenant, va db4o tourner sur Android, mais il est vraiment bon choix pour les données énorme ... Non. Non, sauf si vous avez très isolé des données qui peuvent être dans des bases de données distinctes et accessibles uniquement dans l'isolement et il ne semble pas pour moi comme il est de votre situation. Notre autre base de données, est mean't Versant pour traiter les données énormes en temps quasi réel de, mais seulement le client est 100% Java, le serveur est écrit en C, donc il ne fonctionnera pas sur Android.

Je pense que vous aurez besoin de faire quelques recherches pour voir qui a ODB qui peut traiter des données énormes sur Android.

Best, -Robert

Answer 2

Vous ne dites pas beaucoup sur vos besoins d'accès aux données ou aux données Loadout vraiment.

Si vous avez des lignes principales 3M, puis un tas de petites tables de feuilles, alors vous pouvez juste bien faire en mettant en cache toutes les tables de feuilles en RAM, et « se joindre » à leur disposition par la main. De nombreux systèmes ont de très petites tables de feuilles (en particulier par rapport aux principales données), afin de les charger en RAM, puis les regarder simplement lorsque vous chargez la ligne peut être une grande victoire.

De toute évidence, vous ne le faites pas avec parent- majeur> relations enfants, mais si vous pouvez éliminer la feuille rejoint, puis une lecture devient une seule jointure entre le parent et l'enfant au lieu d'une demi-douzaine de parents, enfants, et les tables de feuilles.

Même si cela ne fonctionne pas pour toutes les tables de feuilles, si elle travaille pour une grande majorité, il pourrait bien être suffisant pour vous sur la bosse.

Answer 3

Parlant au nom de db4o. Nous courons tous nos tests de régression sur Android parce que nous pensons qu'il deviendra une plate-forme très importante pour db4o

db4o fonctionne très bien pour l'ordre de grandeur de 3 millions d'objets.

Nous faisons des tests de référence par rapport à d'autres bases de données sur les http://www.polepos.org/ et nous va bientôt sortir une nouvelle version de l'indice de référence où nous courons une configuration complexe, aussi contre SqlLite. La référence à Portage Android est également une considération.

Si les jointures tuent vos performances et vous avez des données très hétérogènes, db4o pourrait fonctionner mieux qu'une base de données relationnelle.

Votre application semble intéressant. Si vous avez besoin d'aide pour évaluer db4o, juste me donner un cri.

Answer 4

Jason: pour atteindre un membre db4o vous devez utiliser ce modèle: prenom @ db4o.com Le meilleur!