【问题标题】:Better data structure for faster reads in Map of Map of Map of Lists更好的数据结构,可在 Map of Lists Map of Lists 中更快地读取
【发布时间】:2011-11-27 13:50:38
【问题描述】:

我有一个场景,我需要存储数据层次结构的ma​​p of list of list,以便在内存中进行处理。而且,目前我正在考虑将数据结构实现为

Map<Integer, Map<String, Map<Integer, List<String> > > >

具体的类型是,

HashMap<stdIdInt, HashMap<libraryNameStr, HashMap<topicIdInt, ArrayList<bookNameStr> > > >

由于我不需要维护任何特定的顺序,我还考虑将 List 替换为 Set (HashSet),这可能会提高性能。

虽然到目前为止我已经尝试过了,但我也认为使用 Google 的 Guava Multimap 是一个可行的替代方案,但我不确定。

背景:我需要存储每个学生id和他们感兴趣的的详细信息>书名按其主题类型分类的信息,这些信息将按图书馆名称进一步组织。我需要处理数据和显示书名,主要是通过学生 ID 和其他时间通过图书馆名称和主题类型。一旦书名显示给用户,我需要从 书名 列表中删除该条目。

数据结构需要高速保存和处理数以千计的条目,并将保存数据的时间更长。

请提出更快处理的方法或其他数据结构,以及数据结构/集合类的类型及其使用组合。

(请注意,我上面描述的场景并不完全正确,但我已尽力抽象出数据层次结构的复杂性)

【问题讨论】:

  • “高率”和“长时间”是什么意思?对我来说,这一切开始听起来像是一个数据库。
  • @skaffman 请求将在高峰时间达到约 1000+/秒,并且该数据将保留大约一天,之后第二天将有新数据。是的,我正在尝试应该在数据库中完成的工作,因为每次访问数据库时都知道所有数据都只用于处理,而不是用于永久存储。
  • 这听起来像是过早的优化。我会采纳@Tomasz 的建议来改进抽象,然后通过一些基准测试确定数据结构是否能够充分执行。如果不是,请找出速度太慢的部分并加以改进。

标签: java performance data-structures collections


【解决方案1】:

我认为您在这里遗漏了很多抽象。经验法则是:每当一个集合持有另一个集合时,就应该引入中间对象

在你的情况下,这是我建议的 OO 设计:

class Student {
    private int id;
    private Map<Integer, Library> libraries;
    private getLibrary(int id) {return libraries.get(id);}
}

class Library {
    private int id;
    private Map<Integer, Topic> topics;
    private getTopic(int id) {return topics.get(id);}
}

class Topic {
    private int id;
    private Map<Integer, Book> books;
    private getBook(int id) {return books.get(id);}
}

class Book {
    private int id;
    private String name;
}

及用法:

Map<Integer, Student> students = //...
students.get(6).getLibrary(5).getTopic(4).getBook(3)

当然,这段代码需要进一步改进。例如。你不应该在一行中需要多个.。但它已经比以下更具可读性了:

students.get(6).get(5).get(4).get(3)

【讨论】:

  • 我完全同意你的观点,我已经抽象出超出要求的复杂性。我确实有类似的面向对象设计。但我的疑问是数据结构/集合类的类型及其使用组合
  • 我想Topic 需要有List&lt;String&gt;List&lt;Book&gt; 作为书名
  • 我最终使用了具有类似 VO 的 List,因为后来我发现我需要一次又一次地遍历列表。
猜你喜欢
  • 1970-01-01
  • 2014-06-05
  • 1970-01-01
  • 1970-01-01
  • 2022-12-02
  • 2021-06-22
  • 1970-01-01
  • 1970-01-01
  • 2022-12-01
相关资源
最近更新 更多