Poprawnie zauważyłeś, że dokumenty będą miały inny rozmiar. Więc zaoszczędzisz co najmniej 15 bytes na dokument (60% dla podobnych dokumentów), jeśli zdecydujesz się na przyjęcie drugiego schematu. Skończy się to na mniej więcej 140MB za twoje 10 million dokumentacja. Daje to następujące korzyści:
- Oszczędności na dyskach twardych. Jedynym problemem jest to, że patrząc na ceny obecnych dysków twardych, jest to w większości bezużyteczne.
- Oszczędzanie pamięci RAM. W porównaniu z dyskami twardymi może to być przydatne do indeksowania. W mongodb zestaw indeksy powinien zmieścić się w pamięci RAM, aby uzyskać dobry wydajność
. Więc jeśli będziesz miał indeksy na tych dwóch polach, nie tylko zaoszczędzisz
140MBmiejsca na dysku, ale także140MBpotencjalnej przestrzeni RAM (co jest faktycznie zauważalne). - I/O . Wiele wąskich gardeł powstaje z powodu ograniczeń systemu wejścia/wyjścia (ograniczona jest prędkość odczytu/zapisu z dysku). W przypadku Twoich dokumentów oznacza to, że ze schematem 2 możesz potencjalnie czytać/zapisywać
twice as many documentsna 1 sekundę. - sieć . W wielu sytuacjach sieć jest nawet znacznie wolniejsza niż IO, a jeśli serwer DB znajduje się na innej maszynie, to serwer aplikacji dane muszą być przesyłane przez sieć. Będziesz także mógł wysłać dwa razy więcej danych.
Po omówieniu zalet, muszę powiedzieć Wam wadę małych kluczy:
- czytelność bazy danych. Kiedy wykonujesz
db.coll.findOne()i widzi{_id: 1, t: 13423, a: 3, b:0.2}dość trudno jest zrozumieć, co dokładnie jest tutaj przechowywane. - czytelność aplikacji podobnie z bazą danych, ale przynajmniej tutaj możesz mieć rozwiązanie. Z logiką mapowania, która przekształca
currentDatedocipricedopmożesz napisać czysty kod i mieć krótki schemat.
