Java - Custom Hash Map / Table Niektóre punkty

W niektórych poprzednich postach zadałem kilka pytań dotyczących kodowania Custom Hash Map / Table w Javie. Teraz, gdy nie mogę go rozwiązać i zapomniałem właściwie wspomnieć o tym, czego naprawdę chcę, podsumowuję je wszystkie, aby było jasne i precyzyjne.

Co ja zrobię:

Próbuję kodować nasz serwer, w którym muszę znaleźć typ dostępu użytkownika według adresu URL.

Teraz mam 1110 milionów adresów URL (około).

Więc co zrobiliśmy

1) Podzieliliśmy bazę danych na 10 części po 110 milionów adresów URL. 2) Budowanie HashMap przy użyciu tablicy równoległej, której kluczem jest jedna część adresu URL (reprezentowana jako LONG), a wartości to inna część adresu URL (reprezentowana jako INT) -klucz może mieć wiele wartości.

3) Następnie przeszukaj HashMap w poszukiwaniu innych adresów URL (miliony adresów URL zapisanych w ciągu jednego dnia) dziennie na początku, gdy system się uruchomi.

Co wypróbowałeś:

1) Próbowałem wielu baz danych NoSQL, jednak okazało się, że nie jest to zbyt dobre dla naszego celu.

2) Zbudowałem naszniestandardowy hashap(używając dwóch równoległych tablic) w tym celu.

Więc o co chodzi:

Po uruchomieniu systemu musimy załadować naszą tablicę hashtable każdej bazy danych i przeprowadzić wyszukiwanie milionów adresów URL:

Teraz problem jest

1) Chociaż wydajność HashTable jest całkiem niezła, podczas ładowania HashTable kod zajmuje więcej czasu (do załadowania używamy pliku File Channel i bufora odwzorowanego w pamięci, co zajmuje 20 sekund, aby załadować HashTable - 220 milionów wpisów - ponieważ współczynnik obciążenia wynosi 0,5,znaleźliśmy to najszybciej)

Tak więc spędzamy czas: (HashTable Load + HashTable Search) * Liczba DB = (5 + 20) * 10 = 250 sekund. Co jest dla nas dość drogie i przez większość czasu (200 z 250 sekund) będzie ładować hashtables.

Czy myślałeś w inny sposób:

Jednym ze sposobów może być:

Nie martwiąc się o ładowanie i przechowywanie, i pozostawienie pamięci podręcznej systemowi operacyjnemu przy użyciu bufora mapowanego w pamięci. Ale ponieważ muszę wyszukiwać miliony kluczy, daje to gorszą wydajność niż powyżej.

Ponieważ okazało się, że wydajność HashTable jest dobra, ale czas ładowania jest wysoki, pomyśleliśmy o odcięciu go w inny sposób:

1) Utwórz tablicę połączonych list o rozmiarze Integer_MAX (moja własna lista niestandardowa).

2) Wstaw wartości (int) do połączonych list, których liczba jest numerem klucza (zmniejszamy rozmiar klucza do INT).

3) Musimy więc przechowywać tylko połączone listy na dyskach.

Problem polega na tym, że tworzenie takiej liczby połączonych list zajmuje dużo czasu, a tworzenie tak dużej liczby połączonych list nie ma znaczenia, jeśli dane nie są dobrze rozpowszechniane.

Jakie są twoje wymagania:

Po prostu moje wymagania:

1) Klawisz z wprowadzaniem i wyszukiwaniem wielu wartości. Szukasz miłej wydajności wyszukiwania. 2) Szybki sposób ładowania (szczególnie) do pamięci.

(klucze są 64-bitowe INT, a wartości 32-bitowe INT, jeden klucz może mieć najwyżej 2-3 wartości. Możemy również sprawić, że nasz klucz będzie 32-bitowy, ale da więcej kolizji, ale jest dla nas możliwy do zaakceptowania, jeśli uda nam się poprawić) .

Czy ktoś może mi pomóc, jak rozwiązać ten lub jakikolwiek komentarz, jak rozwiązać ten problem?

Dzięki.

Uwaga:

1) Zgodnie z wcześniejszymi sugestiami dotyczącymi przepełnienia stosu, dane przed odczytem dla buforowania dysku nie są możliwe, ponieważ po uruchomieniu systemu nasza aplikacja zacznie działać i następnego dnia po uruchomieniu systemu.

2) Nie znaleźliśmy baz danych NoSQL skalują się dobrze, ponieważ nasze wymagania są proste (oznacza po prostu wstawienie wartości klucza hashtable i załadowanie i przeszukanie (pobranie wartości)).

3) Ponieważ nasza aplikacja jest częścią małego projektu i ma być stosowana na małym kampusie, nie sądzę, aby ktokolwiek kupił mi dysk SSD. To jest moje ograniczenie.

4) Używamy również Guava / Trove, ale nie są one w stanie przechowywać tak dużej ilości danych w 16 GB również (korzystamy z 32 GB serwera ubuntu.)

questionAnswers(3)

yourAnswerToTheQuestion