查询sql数据库中的索引表与使用自己的HashMap
我有一个关于java的性能问题。
我在 sql 数据库中有一个大型索引表（在本例中是 H2 数据库，但问题可以应用于任何 sql 数据库）。
我必须经常通过这个索引在这个表中查找项目。
现在我想知道什么更快：
- 对 sql 数据库的查询
- 为我最常使用的字段制作自己的哈希图
有人对此有任何想法吗？ （在创建一些速度测试并亲自找出之前）。
I have a performance question in java.
I have a large indexed table in a sql database (in this case a H2 Database, but the question can be applied to any sql database).
I have to find items in this table by this index often.
Now I wonder what is quicker:
- the query on the sql database
- making your own hashmap for the fields I use most freqently
Does anyone have an idea about this? (before creating some speed tests and find out for myselve).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在 HashMap 中查找会更快，但如果数据发生变化，您将需要管理数据和更新缓存的开销，更不用说决定要缓存哪些数据位了。
请注意，您的数据库可能会对自己进行一些缓存，并且常见查询可能会非常快速地返回数据，甚至无需通过查询解析器，更不用说访问磁盘了。
Looking up in the HashMap will be quicker, but if the data changes you have the overhead of managing the data and updating your cache, not to mention deciding on which bits of data you are going to cache.
Note that your database will probably do some caching of its own and common queries will probably return data very quickly without even going through the query parser, never mind hitting the disk.
您应该能够在 1-10 毫秒内实现索引 SQL 查询，并且 HashMap 上的查找应该小于 1 微秒。
如果您已经有一个 SQL 数据库，我只会使用它，除非您知道必须在内存中复制数据。
You should be able to achieve an indexed SQL query in 1-10 milli-seconds, and a lookup on a HashMap should be less than 1 micro-second.
If you have an SQL database already, I would just use that unless you know you have to replicate the data in memory.
使用你自己的HashMap来维护会让你的生活变得艰难
如果内存中无法容纳太多条目怎么办
如果您的应用程序重新启动怎么办？
如果您需要搜索一个您没有想到的参数怎么办？
如果您需要像 param1=val1 和 param2=val2 这样的搜索怎么办？
如果您维护正确的索引集，DB 会提供开箱即用的这些内容。
大多数现代数据库将频繁查询的数据保存在缓存中，因此速度应该更快。
Using Your own HashMap to maintain will make you life tough
What if you have too many entries to accommodate in memory
What if your application is re-started?
What if you need search on one more parameter you didn't think of?
What if you need to search like param1=val1 and param2=val2
DB provides these things out of the box if you maintain right set of indexes.
And most modern DB keeps frequently queried data in its cache so thing should be faster.