我创建了许多地理数据对象（名称、邮政编码、纬度、经度）。现在我想将它们放入一个集合中，以便以后搜索不同的条目。
一切都应该发生在面向对象/内存中，因此不需要关系数据库。
这样的查询看起来像：
- 按名称或 plz 查找 lat 和 lon
- 查找 LAT1、LAT2 和 LON1、LON2 之间的对象
对于这种“简单”数据结构，什么集合是最好的？
这样的查询需要什么复杂度？
多线程可以带来好处吗？如果是，哪个集合最适合线程安全？
是否有机会在 key=>value 数据库中编写此类查询？
I've created many Geodata objects (name,postalCode,lat,lon). Now I want to put them into a collection to search for different entries later.
Everything should happen objectOriented/in-memory, so there shouln't be a need for a relational database.
Such a Query looks like:
- Find lat and lon by name or plz
- Find objects between LAT1,LAT2 and LON1,LON2
What collection is the best one for such a "simple" datastructure?
What complexity is needed for such a query?
Can multithreading be a benefit? If it is, which collection is used at best for thread safety?
Is there a chance to write such queries in a key=>value database?
发布评论
评论（1）
您可以使用内存数据库。
这很好，因为关系数据库适合这样的关系查询......:-)
对于自制的纯 Java，您可以使用：
Map，名称为作为键Map，以 plz 作为键List，其中 LAT 为第一个列表，LON 为第二个列表。两者都是排序的，因此您可以使用二分搜索来搜索每个值，并使用
subList有效地返回一个区间。这相当于键的重复，但不是所有对象的重复，因为您可以在所有这些情况下重用相同的实例对象。
多线程是可以接受的（如果您出于其他原因需要它），但我怀疑您需要引入它来提高单个搜索的性能。提到的数据结构应该在不到一毫秒的时间内给出正确的答案！
线程安全对于这些数据结构来说不是问题，因为您的用例似乎是只读的。如果在某些情况下需要修改“对象”，那么您只能保护“对象”本身，而不能保护用于搜索的数据结构。
You could use an in-memory database.
This is good as relational databases are good for relational queries like these.... :-)
For home-made pure Java, you could use:
Map, with the name as keyMap, with the plz as keyList<List<"object">>with LAT for the first list, LON for the second list.Both are sorted, so for each you can search for a value using binary-search, and return an interval efficiently with
subList.This amounts to a duplication for the keys, but not for all objects, as you can reuse the same instance objects in all of these cases.
Multi-threading is acceptable (if your need it for other reasons), but I doubt you need to introduce it to improve the performance of a single search. The data structures mentioned should deliver the correct answers in less than a millisecond !
Thread-safety is not a problem for these data structures, as your use case seem to be read-only. If you need to modify the "objects" in some case, then you can only protect the "objects" themselves, not the data structures used for searching.