我需要存储大约10万个代表用户的对象。这些用户拥有用户名，年龄，性别，城市和国家。（Java）存储大量带有索引属性的对象集合
用户应该是可搜索的一系列年龄和任何其他属性，但也是属性的组合（例如布鲁塞尔30至35岁之间的女性）。结果应该很快找到，因为它是许多连接客户端的服务器服务之一）。用户只能被删除或添加，而不能更新。
我想过用索引的属性快速的数据库（如H2 DB这似乎是相当快的，我已经看到他们有一个内存模式）
我想知道是否有任何其他选项在去DB之前是可以的。
谢谢你的任何想法！
你的服务器有多少内存？这些物体占用多少内存？把它们全部留在记忆中是否可行？你是否真的需要加速保持内存，而不是在数据库中进行推送？它确实使它更加复杂以保存在内存中，并且确实增加了硬件需求......您确定需要它吗？
因为你描述的所有内容都可以在一个非常简单的服务器上运行，并放入一个非常简单的数据库中，并按照每个请求100毫秒的顺序给出结果。你需要超过100毫秒的响应时间？为什么？
对象是简单的POJO包含一些整数和字符串，也许是一个小的字符串列表也。不是太贵，我猜，但是可能有10万个。我真的不能猜测这是否会占用体面的计算机上的大量内存。 我在考虑替代品，因为SQL查询将主要涉及I/O磁盘操作。从内存中获取结果将会快很多。现在，如果没有任何简单的替代品（也许我错过了易用的东西），那么当然我会去DB。 – Matthew 2010-07-25 16:38:56
数据库自然会将正在使用的内容保存在内存中。它还将使用索引来加快查询速度。对于几条100k简单记录，您可以查询和检索100ms内的信息。十分之一秒太长？在记忆中这样做没有任何问题，但是你真的需要快速的要求（可能是1/100秒和1/10秒）来解决这个问题。 – bwawok 2010-07-25 17:57:20
绝对是一个关系数据库。有了这个大小，你将需要一个客户端 - 服务器系统，而不是像Sqlite那样嵌入的东西。根据进一步的要求选择一个系统。索引是一项基本功能，大多数系统都支持它。就我个人而言，我会尝试一些非常流行和免费的东西，例如MySQL或PostgreSQL，这样您可以更轻松地通过Google找到解决问题的方法。如果你使你的SQL查询足够通用（没有供应商特定的结构），你可以切换系统而不会有太大的痛苦。我同意bwawok，试试标准设置是否足够好，然后再考虑优化。
为什么不嵌入一些东西？它不是更快吗？你能澄清一下吗？我正在寻找像H2 DB这样的东西。 – Matthew 2010-07-25 16:41:14
H2可能会也可能不会更快。但是，在你走上这条路之前，你真的需要业务需要，因为你最终可能会将自己装进未来的角落。 – bwawok 2010-07-25 17:58:25
我必须说，我从来没有尝试使用Sqlite 3的100K行表，也许它工作正常，只要你没有多个用户同时尝试更新数据库。但它将全部放在常规文件系统的单个常规文件中，对我来说似乎很腥。尽一切办法尝试一下;您还可以尝试Firebird，它支持嵌入式和客户端 - 服务器访问，并且具有一些强大的功能，但不像其他系统那么受欢迎。 – reinierpost 2010-07-25 23:33:09
我会使用RDBMS--有很多好的ORM可用，比如Hibernate，它们允许你透明地将POJO填充到数据库中。一旦将数据访问抽象出来，您就可以自由决定如何最好地保存数据。
对于这个规模的项目，我会使用H2 database。它具有嵌入式和客户端/服务器两种模式，可以从磁盘或完全在内存中运行。
如果在内存中存储是需求，则用于内存数据库的+1。由于对象模型是微不足道的（1个表/类），因此不推荐使用hibernate作为这种情况。 – 2010-07-25 20:14:33
我在考虑可搜索因素--Hibernate标准API比动态构建SQL查询更容易构建对任意属性和值的搜索。此外，hibernate随着您的项目带来有用的功能而增长，特别是与Spring结合使用时（声明式事务，审计和插入持久层的各种钩子 - 拦截器）有助于实现良好的结构。 – mdma 2010-07-26 18:47:46
您是否想过使用EHCache或Memcached等缓存系统？ 另外如果你有足够的内存，你可以使用像TreeMap这样的一些排序的集合作为索引映射，或者使用HashMap来按名称搜索用户（每个字段单独映射）。这将需要更多的记忆，但可以有效。您还可以根据用户查询体验找到具有最佳选择性的最常用查询，并根据此查询创建比较器。在这种情况下，元素的子集不会很大，并且可以快速过滤而不需要任何额外的优化。
听起来像是一个数据库... 0034 – 2010-07-25 22:28:47