Библиотека графиков для обработки большого набора данных - PullRequest
0 голосов
/ 18 мая 2018

Я ищу библиотеку Java, способную обрабатывать большой набор данных наилучшим образом с точки зрения памяти и производительности.

Вот мои требования.Это раннее описание содержимого одного из узлов, который должен содержать конечный граф:

public final class CategoryNode {
    private int    nbPages;
    private int    nbSubCats;
    private String label;

    CategoryNode(String label) {
        this.label = label;
    }

    /** Getters/Setters **/
    public int getNbPages() {
        return nbPages;
    }
    public void setNbPages(int nbPages) {
        this.nbPages = nbPages;
    }
    //
    public int getNbSubCats() {
        return nbSubCats;
    }
    public void setNbSubCats(int nbSubCats) {
        this.nbSubCats = nbSubCats;
    }
    //
    public String getLabel() {
        return label;
    }

    @Override
    public int hashCode() {
        return label.hashCode();
    }

    @Override
    public boolean equals(Object o) {
        return ((CategoryNode) o).getLabel().equals(label);
    }
}

Окончательный граф будет содержать не менее 1,8 миллиона узлов и не менее 200 миллионов ребер.Граф является ориентированным незначным графом и не допускает параллельных ребер.График будет полностью сохранен в оперативной памяти.

Две основные операции будут следующими:

1) Извлечение узлов по метке

2) Извлечение преемников и предшественников каждого узла

Если возможно, для операции 1) я хотел бы использовать встроенный компонент библиотеки, а не внешний набор, которыйочень дорого с точки зрения памяти.

Я уже пытался:

A) Использовать только собственные наборы Java ( HashSet и HashMap ), с небольшим успехом: созданная структура памяти слишком велика и время доступа не оптимально.

B) Использование Koloboke (длябоковой указатель) и графы гуавы .По-прежнему используется много памяти, и я бы предпочел не добавлять в мой проект слишком много зависимостей.

C) Использовать Графы гуавы .ImmutableMap был не совсем тем, что я искал, он не был оптимальным набором для этой проблемы.

Я открыт для всех предложений.

...