(Java) Stocker une énorme collection d'objets avec des attributs indexés

J'ai besoin de stocker environ 100 milliers d'objets représentant les utilisateurs. Ces utilisateurs ont un nom d'utilisateur, l'âge, le sexe, la ville et le pays.(Java) Stocker une énorme collection d'objets avec des attributs indexés

Les utilisateurs doivent être consultable par une plage d'âge et l'un des autres attributs, mais également une combinaison d'attributs (par exemple les femmes entre 30 et 35 ans de Bruxelles). Les résultats devraient être trouvés rapidement car c'est l'un des services du serveur pour de nombreux clients connectés). Les utilisateurs ne peuvent être supprimés ou ajoutés, pas mis à jour.

J'ai pensé à une base de données rapide avec des attributs indexés (comme h2 db qui semble être assez rapide, et je l'ai vu qu'ils ont un mode en mémoire)

Je me demandais si une autre option était possible avant d'aller à la DB.

Merci pour vos idées!

Source

2010-07-25 Matthew

Semble comme une base de données à mé ..... –

De combien de mémoire votre serveur dispose-t-il? Combien de mémoire ces objets prendraient-ils? Est-il faisable de les garder tous en mémoire, ou pas? Avez-vous vraiment besoin de l'accélération de garder en mémoire, vs bousculer dans une base de données? Cela le rend plus complexe à garder en mémoire, et cela augmente les besoins en matériel ... êtes-vous sûr de l'avoir besoin? Parce que tout ce que vous décrivez peut être exécuté sur un serveur très simple et mettre dans une base de données très simple et vous donner les résultats que vous voulez de l'ordre de 100ms par requête. Avez-vous besoin d'un temps de réponse supérieur à 100 ms? Pourquoi?

Source

2010-07-25 16:27:29 bwawok

Les objets sont de simples POJO contenant des entiers et des chaînes, peut-être aussi une petite liste de chaînes. Pas trop cher je suppose, mais il peut y avoir 100 milliers d'entre eux. Je ne peux vraiment pas deviner si cela va prendre une énorme quantité de RAM sur un coputer décent. Je pensais à des alternatives car les requêtes SQL impliqueront principalement des opérations de disque d'E/S. Obtenir le résultat de la mémoire sera beaucoup plus rapide.Maintenant, s'il n'y a pas d'alternatives faciles (peut-être qu'il me manquait quelque chose de facile à utiliser), alors bien sûr, je vais aller à la DB. – Matthew

La base de données gardera naturellement les choses utilisées en mémoire. Il utilisera également des index pour accélérer vos requêtes. Pour quelques enregistrements simples de 100k, vous pouvez interroger et récupérer les informations dans, de l'ordre de, 100ms. Est-ce que 1/10ème de seconde est trop long? Il n'y a rien de mal à le faire en mémoire, mais vous avez vraiment besoin d'une exigence de rapide (peut-être 1/100ème de seconde contre 1/10ème de seconde) de s'en soucier. – bwawok

Très certainement une base de données relationnelle. Avec cette taille, vous aurez besoin d'un système client-serveur, pas quelque chose d'intégré comme Sqlite. Choisissez un système en fonction d'autres exigences. L'indexation est une fonctionnalité de base, la plupart des systèmes la prennent en charge. Personnellement, j'essaierais quelque chose qui est populaire et gratuit, comme MySQL ou PostgreSQL, pour que vous puissiez plus facilement trouver des solutions à vos problèmes. Si vous générez suffisamment de requêtes SQL (pas de construction spécifique au fournisseur), vous pouvez changer de système sans trop de peine. Je suis d'accord avec bwawok, essayez si une configuration standard est assez bonne et pensez à des optimisations plus tard.

Source

2010-07-25 16:30:57 reinierpost

Pourquoi pas quelque chose d'intégré? N'est-ce pas plus rapide? Pourriez-vous clarifier cela? J'allais pour quelque chose comme H2 DB. – Matthew

H2 peut ou peut ne pas être plus rapide. Mais vous avez vraiment besoin des besoins de l'entreprise avant de suivre cette voie, car vous pourriez vous retrouver dans un coin dans le futur. – bwawok

Je dois dire que je n'ai jamais essayé une table en ligne 100K avec Sqlite 3, peut-être que cela fonctionne très bien, tant que vous n'avez jamais plusieurs utilisateurs essayant simultanément de mettre à jour la base de données. Mais tout sera dans un seul fichier régulier sur votre système de fichiers habituel, il me semble juste louche. De toute façon, essayez-le; vous pouvez également essayer Firebird qui prend en charge à la fois l'accès intégré et client-serveur et possède quelques fonctionnalités intéressantes, mais n'est pas aussi populaire que certains autres systèmes. – reinierpost

Je voudrais utiliser un SGBDR - il y a beaucoup de bons ORMs disponibles, tels que Hibernate, qui vous permettent d'insérer de manière transparente les POJOs dans un db. Une fois l'accès aux données résumé, vous avez la liberté de décider de la meilleure façon de conserver les données.

Pour cette taille de projet, j'utiliser les H2 database. Il a à la fois des modes embarqués et client/serveur, et peut fonctionner à partir du disque ou entièrement en mémoire.

Source

2010-07-25 17:08:33 mdma

+1 pour la mémoire morte en mémoire s'il est nécessaire de stocker en mémoire. Je ne recommanderais pas d'utiliser hibernate pour ce cas car le modèle objet est trivial (1 table/classe). –

Je pensais au facteur de recherche - l'API des critères d'hibernation facilite la recherche de propriétés sur des attributs et des valeurs arbitraires plus facilement que la construction dynamique d'une requête SQL. En outre, hibernate grandit avec votre projet apportant des fonctionnalités utiles, en particulier lorsqu'il est combiné avec Spring (transactions déclaratives, audit, et divers hooks pour se connecter à la couche de persistance - Interceptors) qui aident à imposer une bonne structure. – mdma

Avez-vous pensé à utiliser un système de cache comme EHCache ou Memcached? Aussi si vous avez assez de mémoire, vous pouvez utiliser une collection triée comme TreeMap comme carte d'index, ou HashMap pour rechercher l'utilisateur par son nom (carte séparée par champ). Cela prendra plus de mémoire mais peut être efficace. Vous pouvez également trouver sur la base de l'expérience de requête utilisateur la requête la plus fréquemment utilisée avec la meilleure sélectivité et créer un comparateur basé sur cette requête onli. Dans ce cas, le sous-ensemble de l'élément ne sera pas grand et peut être filtrer rapidement sans aucune optimisation supplémentaire.

Source

2011-08-11 21:06:05

(Java) Stocker une énorme collection d'objets avec des attributs indexés

Répondre

Questions connexes