Zrozumienie limitu rozmiaru dokumentu MongoDB BSON

Z MongoDB The Definitive Guide:

Dokumenty większe niż 4 MB (po konwersji na BSON) nie mogą być zapisywane w bazie danych. Jest to nieco arbitralny limit (i może zostać podniesiony w przyszłości); Ma to głównie na celu zapobieganie złemu projektowi schematu i zapewnienie stałej wydajności.

Nie rozumiem tego ograniczenia, czy to oznacza, że ​​dokument zawierający post na blogu z wieloma komentarzami, który tak się składa, że ​​jest większy niż 4 MB, nie może być przechowywany jako pojedynczy dokument?

Czy obejmuje to również zagnieżdżone dokumenty?

A co jeśli chciałbym mieć dokument, który kontroluje zmiany wartości. (W końcu może wzrosnąć, przekraczając limit 4 MB).

Mam nadzieję, że ktoś wyjaśni to poprawnie.

Właśnie zacząłem czytać o MongoDB (pierwsza baza danych nosql, o której się uczę).

Dziękuję Ci.

Po pierwsze, to faktycznie jest podnoszone w następnej wersji do 8MBlub 16MB... ale myślę, że patrząc z perspektywy, Eliot z 10gen (który opracował MongoDB) ujął to najlepiej:

EDYTOWAĆ: Rozmiar został oficjalnie „podniesiony” do16MB

Tak więc na przykładzie Twojego bloga 4 MB to w rzeczywistości dużo. Na przykład pełny, nieskompresowany tekst „Wojny światów” to tylko 364 kB (html): http://www.gutenberg.org/etext/36

Jeśli Twój post na blogu jest tak długi i zawiera tak wiele komentarzy, na przykład nie zamierzam go czytać :)

W przypadku trackbacków, jeśli przeznaczysz im 1 MB, możesz z łatwością mieć więcej niż 10k (prawdopodobnie bliżej 20k)

Więc poza naprawdę dziwacznymi sytuacjami będzie działać świetnie. A w wyjątkowych przypadkach lub w przypadku spamu naprawdę nie sądzę, abyś i tak chciał mieć obiekt o wielkości 20 MB. Myślę, że ograniczenie trackbacków do 15k lub więcej ma sens bez względu na wydajność. Albo przynajmniej specjalna obudowa, jeśli to się kiedykolwiek zdarzy.

-Eliot

Myślę, że osiągnięcie limitu byłoby bardzo trudne ... az czasem, jeśli uaktualnisz ... będziesz musiał się coraz mniej martwić.

Głównym punktem limitu jest to, aby nie zużywać całej pamięci RAM na serwerze (ponieważ musisz załadować wszystkie MBpliki dokumentu do pamięci RAM, gdy go wysyłasz).

Tak więc limit to pewien% normalnej użytecznej pamięci RAM we wspólnym systemie ... który będzie rosnąć z roku na rok.

Uwaga dotycząca przechowywania plików w MongoDB

Jeśli potrzebujesz przechowywać dokumenty (lub pliki) większe niż 16MBmożesz skorzystać z GridFS API, które automatycznie podzieli dane na segmenty i przesyła je z powrotem do Ciebie (unikając w ten sposób problemu z limitami rozmiaru / pamięcią RAM).

Zamiast przechowywać plik w pojedynczym dokumencie, GridFS dzieli plik na części lub porcje i przechowuje każdą porcję jako oddzielny dokument.

GridFS używa dwóch kolekcji do przechowywania plików. Jedna kolekcja przechowuje fragmenty plików, a druga przechowuje metadane plików.

Możesz użyć tej metody do przechowywania obrazów, plików, filmów itp. W bazie danych, podobnie jak w bazie danych SQL. Używałem tego nawet do przechowywania plików wideo o wielkości wielu gigabajtów.

Wiele osób w społeczności wolałoby ostrzeżenia o wydajności bez ograniczeń, w tym komentarzu znajdziesz dobrze uzasadniony argument: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin. system.issuetabpanels: comment-tabpanel # comment-22283

Moim zdaniem główni programiści są uparci w tej kwestii, ponieważ wcześnie zdecydowali, że jest to ważna „funkcja”. Nie zamierzają tego zmienić w najbliższym czasie, ponieważ ich uczucia są zranione, że ktoś to kwestionuje. Kolejny przykład osobowości i polityki, która szkodzi produktowi w społecznościach open source, ale nie jest to tak naprawdę problem paraliżujący.

Aby zamieścić tutaj wyjaśnienie odpowiedzi dla tych, którzy zostali skierowani tutaj przez Google.

Rozmiar dokumentu obejmuje wszystko w dokumencie, w tym dokumenty podrzędne, obiekty zagnieżdżone itp.

A więc dokument:

{
    _id:{},
    na: [1,2,3],
    naa: [
        {w:1,v:2,b:[1,2,3]},
        {w:5,b:2,h:[{d:5,g:7},{}]}
    ]
}

Ma maksymalny rozmiar 16meg.

Sbudocuments i obiekty zagnieżdżone są wliczane do rozmiaru dokumentu.

Nie widziałem jeszcze problemu z limitem, który nie obejmował dużych plików przechowywanych w samym dokumencie. Istnieje już wiele różnych baz danych, które są bardzo wydajne w przechowywaniu / odzyskiwaniu dużych plików; nazywane są systemami operacyjnymi. Baza danych istnieje jako warstwa systemu operacyjnego. Jeśli używasz rozwiązania NoSQL ze względu na wydajność, dlaczego miałbyś chcieć dodać dodatkowe obciążenie związane z przetwarzaniem do dostępu do danych, umieszczając warstwę DB między aplikacją a danymi?

JSON to format tekstowy. Tak więc, jeśli uzyskujesz dostęp do swoich danych przez JSON, jest to szczególnie ważne, jeśli masz pliki binarne, ponieważ muszą być zakodowane w uuencode, szesnastkowym lub Base 64. Ścieżka konwersji może wyglądać następująco:

plik binarny <> JSON (zakodowany) <> BSON (zakodowany)

Bardziej wydajne byłoby umieszczenie ścieżki (adresu URL) do pliku danych w dokumencie i przechowywanie danych w postaci binarnej.

Jeśli naprawdę chcesz zachować te pliki o nieznanej długości w swojej bazie danych, prawdopodobnie lepiej byłoby umieścić je w GridFS i nie ryzykować utraty współbieżności podczas uzyskiwania dostępu do dużych plików.

Zagnieżdżona głębokość dla dokumentów BSON: MongoDB obsługuje nie więcej niż 100 poziomów zagnieżdżenia dla dokumentów BSON.

Więcej informacji na vist

Być może przechowywanie posta na blogu -> relacja komentarzy w nierelacyjnej bazie danych nie jest najlepszym projektem.

Prawdopodobnie i tak powinieneś przechowywać komentarze w osobnej kolekcji dla postów na blogu.

[edytować]

Zobacz komentarze poniżej, aby uzyskać dalszą dyskusję.

Według https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1

Jeśli spodziewasz się, że wpis na blogu może przekroczyć limit 16 MB dokumentów, powinieneś wyodrębnić komentarze do osobnej kolekcji i odnieść się do wpisu na blogu z komentarza i wykonać sprzężenie na poziomie aplikacji.

// posts
[
  {
    _id: ObjectID('AAAA'),
    text: 'a post',
    ...
  }
]

// comments
[
  {
    text: 'a comment'
    post: ObjectID('AAAA')
  },
  {
    text: 'another comment'
    post: ObjectID('AAAA')
  }
]