2010-09-29 17 views
6

Właśnie zacząłem grać z Berkeley DB kilka dni temu, więc próbuję sprawdzić, czy czegoś brakuje, jeśli chodzi o przechowywanie danych tak szybko, jak to możliwe.Optymalizowanie wydajności w Berkeley DB

Oto kilka informacji na temat danych: - chodzi w 512 bajtowych kawałkami - kawałki przychodzą w celu - kawałki zostaną usunięte w FIFO celu - jeśli mogę stracić niektóre dane z końca z powodu awarii zasilania, która jest OK tak długo, jak cały db nie jest uszkodzony

Po przeczytaniu całej dokumentacji wyglądało na to, że kolejka db była dokładnie tym, czego chciałem.

Jednak po wypróbowaniu kodu testowego moje najszybsze wyniki wynosiły około 1 MB na sekundę, po prostu przepuszczając przez DB-> zestaw z zestawem DB_APPEND. Próbowałem również używać transakcji i masowych putów, ale oba te spowolniły znacznie, więc nie ścigałem ich przez dłuższy czas. Wstawiałem do nowej bazy danych utworzonej na chipie NANDFlash na mojej płycie Freescale i.MX35.

Ponieważ chcemy uzyskać prędkość zapisu na poziomie co najmniej 2 MB na sekundę, zastanawiałem się, czy jest coś, co pominąłem, co może poprawić szybkość, ponieważ wiem, że mój sprzęt potrafi pisać szybciej.

Odpowiedz

8

spróbuj umieścić to w swoim DB_CONFIG:

set_flags DB_TXN_WRITE_NOSYNC 
set_flags DB_TXN_NOSYNC 

Z mojego doświadczenia, to zwiększenie wydajności zapisu dużo.


DB_TXN_NOSYNC Jeśli ustawione, Berkeley DB nie będzie pisać lub synchronicznie wylewać na dziennik transakcji popełnienia lub przygotowanie. Oznacza to, że transakcje wykazują właściwości ACI (atomowość, spójność i izolacja), ale nie D (trwałość); oznacza to, że integralność bazy danych zostanie zachowana, ale jeśli aplikacja lub system ulegnie awarii, możliwe jest, że niektóre z ostatnio zatwierdzonych transakcji mogą zostać cofnięte podczas odzyskiwania. Liczba transakcji podlegających ryzyku zależy od tego, ile aktualizacji dziennika może zmieścić się w buforze dziennika, jak często system operacyjny przekazuje brudne bufory na dysk i jak często log jest sprawdzany. Wywołanie DB_ENV-> set_flags z flagą DB_TXN_NOSYNC wpływa tylko na określony uchwyt DB_ENV (i dowolne inne uchwyty DB Berkeley otwarte w ramach tego uchwytu). Aby zachować spójne zachowanie w środowisku, wszystkie uchwyty DB_ENV otwarte w środowisku muszą albo ustawić flagę DB_TXN_NOSYNC, albo określić flagę w pliku konfiguracyjnym DB_CONFIG.

Flaga DB_TXN_NOSYNC może być używana do konfiguracji Berkeley DB w dowolnym momencie w trakcie działania aplikacji.


DB_TXN_WRITE_NOSYNC Jeśli zestaw, Berkeley DB będzie pisać, ale nie będzie synchronicznie równo, dziennik transakcji na popełnienia lub przygotować. Oznacza to, że transakcje wykazują właściwości ACI (atomowość, spójność i izolacja), ale nie D (trwałość); Oznacza to, że integralność bazy danych zostanie utrzymana, ale jeśli system zawiedzie, możliwe jest, że niektóre z ostatnio zatwierdzonych transakcji mogą zostać cofnięte podczas odzyskiwania. Liczba transakcji obciążonych ryzykiem zależy od tego, jak często system przesyła brudne bufory na dysk i jak często log jest sprawdzany. Wywołanie DB_ENV-> set_flags z flagą DB_TXN_WRITE_NOSYNC dotyczy tylko określonego uchwytu DB_ENV (i wszelkich innych uchwytów Berkeley DB otwartych w ramach tego uchwytu).Dla zgodnego zachowania w środowisku, wszystkie DB_ENV uchwyty otwarty w środowisku musi albo ustawić flagę DB_TXN_WRITE_NOSYNC lub flagi powinny być określone w pliku konfiguracyjnym DB_CONFIG.

DB_TXN_WRITE_NOSYNC flaga może być używana do konfiguracji Berkeley DB w dowolnym momencie w czasie trwania aplikacji.

Aby uzyskać więcej informacji, zobacz http://www.mathematik.uni-ulm.de/help/BerkeleyDB/api_c/env_set_flags.html.

+0

Dzięki za komentarz. Jednakże odkryłem, że po prostu umożliwienie środowisku powoduje zbyt dużą degradację wydajności w porównaniu z nieużywaniem. Myślę, że ma to związek z WAL, więc te flagi pomogłyby mi, ale nawet bez środowiska wszystko jest zbyt wolne. – jjfine

+0

@jjfine: Wierzę, że środowisko jest używane niejawnie z anonimowymi transakcjami (auto-commit), jeśli nie robisz tego wyraźnie. Więc nie korzystanie ze środowiska nie pomoże. –

+0

@VladLazarenko, więc jeśli mogę ustawić jedną z tych 2 flagami, gdy zamknę db Berkeley, będzie cache być zaczerwieniona z powrotem na dysk? – Alcott

1

Proponuję użyć magazynu danych transakcje/TDS, jeśli wspomniałeś, że nie można odtworzyć bazy danych (to znaczy nie jest to tylko lokalna pamięć podręczna), jeśli zostanie uszkodzona. Jeśli nie dbają o tracąc kilka elementów w przypadku awarii awarii/zasilania następnie DB_TXN_WRITE_NOSYNC poprawi wydajność TDS, to baza danych nadal będą integralną i zwrotowi. Jeśli przechowujesz użyciu btree i wskaźnik liczbowy (jeśli nie masz klucza naturalnego) i zwrócić uwagę na kwestie endian więc masz dobry klucz lokalizację i wysokie wykorzystanie strona to powinieneś być w stanie uzyskać o wiele więcej niż 2000 wstawia drugi, szczególnie na SSD, szczególnie jeśli użyjesz DbMultileKeyDataBuilder do wstawiania luzem.