MongoDB i używanie DBRef z danymi przestrzennymi

Question

Mam kolekcję ze 100 milionami dokumentów geometrii.

Mam drugą kolekcję z danymi czasowymi związanymi z każdą inną geometrią. To będzie 365 * 96 * 100 milionów lub 3,5 tryliona dokumentów.

Zamiast przechowywać 100 milionów wpisów (365 * 96) razy więcej niż potrzeba, chcę zachować je w osobnych kolekcjach i wykonać typ JOIN/DBRef/Cokolwiek mogę w MongoDB.

Przede wszystkim chcę uzyskać listę GUID z kolekcji geometrii za pomocą geointerpozycji. Spowoduje to odfiltrowanie go do wartości 100 milionów do 5000. Następnie za pomocą tych 5000 przewodników geometrii chcę odfiltrować 3,5 tryliona dokumentów w oparciu o 5000 goemetrii i dodatkowe kryteria dat, które określam i agreguję dane i znajduję średnią. Zostało ci 5000 geometrii i 5000 średnich dla określonych przez ciebie kryteriów daty.

Jest to zasadniczo JOIN, jak wiem to w SQL, jest to możliwe w MongoDB i można to zrobić optymalnie, powiedzmy, mniej niż 10 sekund.

Wyjaśnienie: jak rozumiem, do tego właśnie służy DBrefs, ale czytałem, że nie jest ono w ogóle skuteczne, a przy zajmowaniu się tak dużą ilością danych nie byłoby to odpowiednie.

Answer 1

Jeśli masz zamiar zajmować się danymi z serii czasowej razem, to warto przechowywać je w tym samym dokumencie. Wartość warta lat w 15-minutowych przyrostach nie jest zabójcza - a na pewno nie chcesz mieć dokumentu na każde wejście serii czasowej! Ponieważ możesz odzyskać wszystko, co chcesz operować jako dokument o pojedynczej geometrii, jest to duża wygrana. Zauważ, że to także pozwala ci rozkleić rzeczy na brakujące dane. Dane można zakodować inaczej, jeśli są raczej rzadkie, a nie indeksowane w macierzy slotowej 35040.

A $ geoIntersects na dużym stosie danych geometrii będzie jednak problemem z wydajnością. Upewnij się, że masz indeksowanie (np. 2dsphere), aby przyspieszyć działanie.

Jeśli istnieje sposób, w jaki można zbudować dodatkowe kwalifikatory w zapytaniu, które mogłyby tanio wyeliminować członków z droższego wyszukiwania, można zrobić rzeczy zippiera. Jak, powiedzmy, wyszukiwania trafią państwa w USA. Możesz najpierw przeciąć wyszukiwanie z granicami stanu, aby znaleźć stany zawierające dane geograficzne i użyć czegoś takiego, jak kod pocztowy, aby zakwalifikować dokumenty. To byłoby naprawdę szybkie wstępne przeszukanie na podstawie 50 dokumentów. Jeśli granica wyszukiwania została po raz pierwszy określona jako trafienie w 2 stany, a rekordy danych geolokalizacyjnych zawierały pole stanu, po prostu wyrzuciłeś 96 milionów rekordów (wszystkie rzeczy są równe) przed droższą częścią geo zapytania. Jeśli przecinasz się z mniejszymi współrzędnymi siatki, być może uda ci się ją przeszukać jeszcze przed rozpatrzeniem danych geo.

Oczywiście posunięcie zbyt daleko zwiększa obciążenie. Jeśli potrafisz poprawnie dostroić system do gęstości 100 milionów geometrii, możesz uzyskać dość niski czas. Ale bez rzeczywistej pracy ze specyfiką problemu, trudno o tym wiedzieć. Tyle danych prawdopodobnie wymaga pewnych konkretnych eksperymentów, zamiast polegać na ogólnym rozwiązaniu.