Używamy Google AppEngine do uruchamiania zapytań przestrzennych / atrybutów, a głównym problemem (od pierwszego dnia) jest sposób indeksowania dużych zestawów linii / wielokątów o dowolnym rozmiarze. Dane punktowe nie są zbyt trudne (patrz geohash, geomodel itp.), Ale zestawy losowo zgrupowanych małych / dużych wielokątów zawsze stanowiły problem (aw niektórych przypadkach nadal występuje)
Wypróbowałem kilka różnych wersji indeksowania przestrzennego na GAE, ale większość z nich to tylko dwa warianty poniżej. Żadne z nich nie było tak szybkie jak bazy danych SQL i wszystkie mają zalety / wady. kompromisy wydają się rozsądne w przypadku większości aplikacji do mapowania przez Internet. Ponadto dwa poniższe muszą być połączone z buforowaniem geometrii w pamięci (poprzez JTS itp.), Aby usunąć wszelkie funkcje, które nie pasują do ostatecznych parametrów wyszukiwania. i wreszcie, opierają się na specyficznych funkcjach GAE, ale jestem pewien, że można by go zastosować do innych architektur (lub użyć TyphoonAE do uruchomienia na klastrze linux, ec2 itp.)
Siatki - spakuj wszystkie funkcje dla określonego obszaru do znanego indeksu siatki. Umieść mały indeks przestrzenny na siatce, aby szybko nawigować po zestawie funkcji, które on zawiera. W przypadku większości zapytań wystarczy wyciągnąć garść siatek, co jest szybkie, ponieważ znasz dokładną konwencję nazewnictwa siatki i jej związek z jednostkami K / V (pobiera, a nie zapytania)
Plusy - dość szybkie, łatwe do wdrożenia, nie zajmują miejsca w pamięci.
Wady - konieczne jest wstępne przetwarzanie, użytkownik musi zdecydować o wielkości siatki, duże geomy są współdzielone na kilku sieciach, klastrowanie może powodować przeciążenie sieci, problemy z serializacją / deserializacją mogą stanowić problem (nawet po skompresowaniu przez bufory protokołu)
QuadKeys - To jest bieżąca implementacja. w zasadzie jest taki sam jak siatki, z tym że nie ma ustalonego poziomu siatki. w miarę dodawania funkcji są one indeksowane według siatki quadkey, która całkowicie zawiera ich granice (lub w niektórych przypadkach, podzielona na dwie części, gdy pojedynczy quadkey nie może być użyty, pomyśl linię danych). Po znalezieniu qk jest on następnie dzielony na maksymalną liczbę mniejszych qk, które zapewniają dokładniejsze odwzorowanie ziarna cechy. wskaźnik / bbox do tej funkcji jest następnie pakowany do lekkiego gridindex (grupa funkcji), do którego można uzyskać zapytanie (oryginalny projekt bezpośrednio sprawdzał funkcje, ale okazało się to zbyt wolne / intensywnie obciążające procesor w przypadkach, gdy zestaw wyników był duży)
Polyline Quadkeys http://www.arc2earth.com/images/help/GAE_QKS_1.png
Polygon Quadkeys http://www.arc2earth.com/images/help/GAE_QKS_2.png
Konwencja nazewnictwa quadkey zastosowana powyżej jest dobrze znana i, co ważniejsze, dąży do zachowania lokalizacji (opisana bardziej tutaj )
Wielokąt powyżej wygląda mniej więcej tak: 0320101013123 03201010131212 03201010131213 0320101013132 0320101013133 03201010131302 03201010131303 032010101313002 032010101313003 032010101313012 032010101311313132010101313131313 03201010131313131320101013131313132010101313131313 03101013133 1313 0310101313131313 0310101313131313 0310101313131313 0310101313131313 03101013133131310101313103
jeśli granice zapytania są wystarczająco małe, możesz bezpośrednio pobrać za pomocą qk. jest to optymalne, ponieważ jest to tylko pojedyncze, wsadowe wywołanie rpc do bazy danych GAE. jeśli granice są na tyle duże, że zawierały zbyt wiele możliwych qk (> 1000), możesz alternatywnie wykonać zapytanie za pomocą filtru (np .: qk> = 0320101013 i qk <= 0320101013 + \ ufffd). Konwencja nazewnictwa quadkey oraz sposób indeksowania ciągów GAE pozwala powyższemu zapytaniu pobrać tylko istniejące siatki, które spadają poniżej tej wartości qk.
istnieją inne zastrzeżenia i problemy z perfem, ale ogólnie jego zdolność do zapytania o quadkeys sprawia, że jest to wykonalne
przykłady - zapytanie o hrabstwa USA: geojson
Plusy - dość szybko, bez konfiguracji rozmiaru siatki, bez pamięci, bez przepełnienia sieci
Wady - konieczne jest wstępne przetwarzanie, możliwe przekroczenie niektórych scenariuszy, brak danych biegunowych
Krzywe wypełniania przestrzeni - spójrz na dyskusję Alfreda na temat zapytań NextGen w Google I / O w tym roku. Włączenie ogólnych krzywych wypełniania przestrzeni / czasu wraz z nowymi operatorami MultiQuery (równolegle) pozwoli na naprawdę fajne zapytania przestrzenne. Czy pobije tradycyjną wydajność SQL? Trudno powiedzieć, ale powinno się dobrze skalować. Szybko zbliżamy się do przyszłości, w której zawsze dostępne urządzenia mobilne wszystkich kształtów i rozmiarów znacznie zwiększą ruch w Twojej witrynie / usłudze.
wreszcie zgodziłbym się również, że powinieneś bardzo uważnie przyjrzeć się swojej domenie problemowej przed wybraniem NoSQL zamiast SQL. W naszym przypadku bardzo podobał mi się model wyceny GAE, więc naprawdę nie było wyboru, ale jeśli nie musisz skalować, zaoszczędź trochę czasu i po prostu użyj standardowej bazy danych sql