Przechowywanie na dużą skalę dla dokumentów dodawanych przyrostowo?

Question

Potrzebuję przechowywać setki tysięcy (w tej chwili, potencjalnie wiele milionów) dokumentów, które zaczynają się puste i są często dodawane, ale nigdy nie są aktualizowane inaczej lub usunięte. Te dokumenty nie są w żaden sposób powiązane, a dostęp do nich wymaga posiadania unikalnego identyfikatora.

Dostęp do odczytu to pewien podzbiór dokumentu, który prawie zawsze zaczyna się w połowie w niektórych indeksowanych lokalizacjach (np. "Dokument nr 4324319, zapisz numer # 53 do końca").

Te dokumenty zaczynają się bardzo małe, o kilku KB. Zwykle osiągają ostateczny rozmiar około 500 KB, ale wiele z nich osiąga 10 MB lub więcej.

Aktualnie używam MySQL (InnoDB) do przechowywania tych dokumentów. Każdy z przyrostowych zapisów jest po prostu zrzucany do jednej dużej tabeli z identyfikatorem dokumentu, do którego należy, więc czytanie części dokumentu wygląda jak "wybierz * z zapisów, gdzie id_dokumentu = 14 i save_id> 53 uporządkuj według save_id", a następnie ręcznie połącz je wszyscy razem w kodzie.

Idealnie chciałbym, aby rozwiązanie do przechowywania było łatwo skalowalne w poziomie, z redundancją między serwerami (np. Każdy dokument przechowywany na co najmniej 3 węzłach) z łatwym odzyskiwaniem uszkodzonych serwerów.

Spojrzałem na CouchDB i MongoDB jako możliwe zamienniki dla MySQL, ale nie jestem pewien, czy któryś z nich ma sens dla tej konkretnej aplikacji, chociaż jestem otwarty na to, że jestem przekonany.

Jakieś wejście na dobrym rozwiązaniu do przechowywania danych?

Answer 1

Brzmi jak idealny problem do rozwiązania przez HBase (Over HDFS).

Wadą jest nieco stroma krzywa uczenia się, między innymi.

Answer 2

Czy istnieje jakiś powód, dla którego w ogóle potrzebujesz bazy danych?

Opisujesz "system do przechowywania dokumentów o unikalnych nazwach", więc zacząłem myśleć "system plików". Może coś w rodzaju serwera/serwerów klasy korporacyjnej (oszacowałem maksymalnie około 200 TiB danych), gdzie unikalny ID jest katalogiem i nazwą pliku w sieci.

Answer 3

Moja bezpośrednia myśl, to dlaczego przechowywać je w bazie danych? Czy przechowywanie ich w bazie danych zapewnia lepszą wydajność wyszukiwania niż system plików w przypadku tak wielu plików?

Uważam, że przechowywanie ich w systemie plików w haszowanej strukturze katalogów byłoby lepsze. Możesz używać bazy danych do przechowywania tylko danych meta (katalogi główne, identyfikator dokumentu, identyfikator zapisu, lokalizacja względem katalogu głównego).

Katalogi główne (węzły) byłyby osobną tabelą i mogłyby być używane podczas zapisywania (wyliczanie i zapisywanie we wszystkich lokalizacjach), a następnie zaokrąglania (lub innego algorytmu równoważenia obciążenia) do odczytu.

Jeśli węzeł jest nieosiągalny lub plik nie istnieje, równoważenie obciążenia może się "zepsuć" do następnego w linii. Katalogi główne mogą być również oznaczone jako offline dla planowanych przestojów, jeśli kod odczytu/zapisu je przestrzegał. To samo może być również użyte do partycjonowania, gdzie x liczba katalogów głównych wyświetla nieparzyste id's, a liczba x podaje nawet identyfikatory id jako prosty przykład.

Zapewnienie synchronizacji węzłów można również zakodować przy użyciu metadanych.

Zaliczam tylko 2 centy, ponieważ nigdy wcześniej nie zajmowałem się tym tomem plików.

Answer 4

OK, najpierw zastrzeżenie, MongoDB ma ograniczenie rozmiaru dokumentu. Jednak najnowsza wersja obejmie Twój rozmiar 10 MB.

Więc kilka przydatnych punktów dla MongoDB.

Idealnie, ja jak roztwór do przechowywania łatwo skalowalne poziomo z redundancji pomiędzy serwerami (np każdy dokument przechowywany w co najmniej 3 węzły) z łatwego odzyskiwania uszkodzonych serwerów.

Do replikacji MongoDB obsługuje replica sets. Zestawy replik są replikami single-master. Jeśli master przejdzie w dół, system automatycznie wybierze nowego mastera (easy recovery). Dodanie nowego węzła jest tak proste, jak uruchomienie nowego serwera i wskazanie istniejącego zestawu.

Dla poziomej skalowalności, MongoDB obsługuje sharding. Sharding jest nieco bardziej złożony, ale działa tak, jak byś tego oczekiwał, dzieląc zapisy na wiele maszyn (lub wiele zestawów replik).

muszę przechowywać setki tysięcy (teraz, potencjalnie wiele milionów) dokumentów, które zaczynają się pusty i są dołączane do często

Kilka firm Mongo uruchomiony miliardy dokumentów w produkcji.

Mongo dostarcza serię update modifiers, które są bardzo przydatne w przypadku "dołączonej do". W szczególności sprawdź operatora $ push, który dodaje do końca tablicy. Powinno być dokładnie to, czego potrzebujesz.

lektura dostępy są niektóre podzbiór dokumentu, który prawie zawsze zaczyna się w połowie w pewnym indeksowanej lokalizacji (na przykład „dokument # 4324319, zapisz nr 53 do końca”).

MongoDB pozwala na zwrot tylko wybranych pól (zgodnie z oczekiwaniami). W zależności od układu możesz użyć dot notation, aby pobrać tylko niektóre dokumenty podrzędne. Jeśli aktualizacje są zaimplementowane jako tablice, można również użyć parametru $slice command, który jest dobrze dopasowany do zapytania, które wymieniono powyżej.

Uważam, że MongoDB spełnia tutaj wszystkie podstawowe potrzeby. Łatwe dołączanie, łatwe sprawdzanie tych załączników i wbudowana replikacja. Otrzymujesz poziome skalowanie za pomocą shardingu (spróbuj najpierw z repliką).

Answer 5

Sprawdź nasz wirtualny system plików SolFS. Będzie dobrze działać w waszych warunkach.