Kyoto Cabinet/Berkeley DB: Ograniczenia wielkości tablicy Hash

Question

Mam trudności z przechowywaniem setek milionów par klucz/wartość 16/32 bajtów z tablicą asocjacyjną na moim dysku SSD.

Z szafką z Kyoto: Gdy działa poprawnie, wkłada 70000 rekordów na sekundę. Gdy spadnie, spada do 10-500 rekordów/s. Przy domyślnych ustawieniach spadek następuje po około milionie rekordów. Patrząc na dokumentację, jest to domyślna liczba segmentów w tablicy, więc ma to sens. Zwiększyłem tę liczbę do 25 milionów i rzeczywiście działa dobrze do około 25 milionów rekordów. Problem polega na tym, że jak tylko zwiększę liczbę wiaderek do 30 milionów lub więcej, od początku tempo wstawiania spadnie do 10-500 rekordów/s. Gabinet Kyoto nie jest przeznaczony do zwiększania liczby segmentów po utworzeniu bazy danych, więc nie mogę wstawić więcej niż 25 milionów rekordów.

1/Dlaczego współczynnik wstawiania KC byłby bardzo niski, gdy liczba wiaderek przekroczy 25M?

Z Berkeley DB: Najlepsza prędkość mam jest nieco niższy niż KC, bliżej rekordu 50000/s, ale nadal OK. Przy ustawieniach domyślnych, podobnie jak w przypadku KC, prędkość spada nagle po około milionach rekordów. Wiem, że BDB ma na celu stopniowe zwiększanie liczby wiaderek. Niezależnie od tego, próbował zwiększyć początkowy numer, grając z HashNumElements i FillFactor, ale każda z tych prób pogorszyła sytuację. Wciąż nie mogę wstawić ponad 1-2 milionów rekordów za pomocą DBD. Próbowałem aktywować niezsynchronizowane transakcje, wypróbowałem różne stawki punktów kontrolnych, zwiększono pamięci podręczne. Nic nie poprawia upuszczania.

2/Co może spowodować spadek liczby płytek BDB po 1-2 milionach wstawek?

Uwaga: Pracuję z java, a gdy prędkość spada, użycie procesora obniża się do 0-30%, a na 100% podczas pracy przy prawidłowej prędkości.
Uwaga: Zatrzymanie procesu i wznowienie wstawiania nic nie zmienia. Więc nie sądzę, że jest to związane z limitami pamięci lub zbieraniem śmieci.

Thx.

Answer 1

Poniżej opisałem, w jaki sposób udało mi się przechowywać miliardy rekordów, pomimo ograniczeń pisanych napotkanych w KC.

Z dużym wysiłkiem nadal nie rozwiązałem problemu ani w przypadku Kyoto ani Berkeley DB. Jednak wymyśliłem interesujące obejście przy użyciu Kyoto Cabinet.

Zauważyłem, że nie mogę zapisać więcej niż 25M rekordów na jednym pliku KC, ale odczyt nie ma takiego ograniczenia -jest zawsze szybki, niezależnie od wielkości bazy danych. Rozwiązaniem, które znalazłem, jest utworzenie nowego pliku KC (nowej bazy danych) na każde kolejne 25 milionów rekordów. W ten sposób odczyt odbywa się na wielu plikach KC i jest nadal szybki, a pisanie odbywa się tylko na ostatnio utworzonym pliku i jest również szybkie. Pozostał tylko problem, aby umożliwić aktualizację/usunięcie rekordów z poprzednich plików. Za to ja skopiowane SSTables zbliżyć, który jest:

• Wszystkie 0 do n-1 pliki są tylko do odczytu, plik jest odczytywany N + pisać.
• Dowolny insert/update/deletion jest zapisany w pliku N.
• Czyta zajrzyj do plików N na 0, i zwróć pierwszy zauważony/ostatnio zapisany insert/update/deletion.
• Do każdego pliku dołączony jest filtr kwitnący, aby uniknąć dostępu do pliku, który nie ma pożądanego rekordu.
• Gdy plik N osiągnie 25 MB rekordów, staje się on tylko do odczytu i tworzony jest plik N + 1.

Uwagi:

• Podobnie jak SSTables, Jeśli dużo aktualizacjach/delecji są wykonywane, to może chcieć przeprowadzić ugniatanie. Jednak w przeciwieństwie do SSTables, kompaktowanie tutaj nie wymaga przepisywania pliku. Nieaktualne rekordy są po prostu usuwane z plików KC, a jeśli plik KC jest bardzo mały, można go albo usunąć - przywracając rekordy w pliku N- albo ponownie otwierać w przypadku nowych wstawień - pod warunkiem, że następne pliki są zwarte.
• Usunięcie nie powoduje usunięcia rekordu, ale wpisanie specjalnej wartości, która identyfikuje rekord jako usunięty. Podczas zagęszczania usunięte rekordy są usuwane na stałe.
• Sprawdzenie, czy istnieje zapis, zwykle wymaga przejrzenia bazy danych. Dzięki filtrom kwitnienia większość negatywnych odpowiedzi można uzyskać bez dostępu do dysku.