Czy osobiste geobazy są lepiej dostosowane do szybkiego wyszukiwania indeksowanych atrybutów niż geobazie plików?

Przygotowuję dane dla aplikacji ArcGIS Engine, która wyszukuje dane w celu wyszukania adresu. Czasami szukamy tylko w polu nazwy ulicy, tylko w polu numeru domu lub w obu przypadkach. Korzystając z osobistych geobaz danych lub geobaz danych SDE, oprócz indeksów jednokolumnowych można dodać indeks atrybutów wielokolumnowych. Z jakiegoś powodu, zgodnie z artykułem Tworzenie indeksów atrybutów ESRI, wielokolumnowe indeksy atrybutów nie są możliwe przy użyciu geobaz danych plikowych. Nie wspominają, dlaczego tak jest - może z jakiegoś powodu geobazy plikowe nie potrzebują ich?

Wielokolumnowy indeks pola numeru domu i nazwy ulicy powinien teoretycznie poprawić wydajność moich zapytań podczas wyszukiwania obu pól jednocześnie, ale czy warto przejść na korzystanie z osobistej geobazy? Mam wrażenie, że wady korzystania z osobistej geobazy mogą negować zalety indeksu wielokolumnowego.

Odniosłem wrażenie, że Esri chce, abyśmy odeszli od osobistych geobaz, ale czy jest to przypadek, w którym osobiste geobazie są lepszą opcją? Jeśli masz z tym jakieś doświadczenie, chciałbym wiedzieć.

Aby odpowiedzieć na pierwszą część pytania, myślę, że warto spojrzeć na dodatkowy tekst w pliku pomocy Tworzenie indeksów atrybutów na temat indeksów wielokolumnowych.

Ważna jest kolejność pojawiania się pól w indeksie wielokolumnowym. W indeksie wielokolumnowym z kolumną A poprzedzającą kolumnę B, kolumna A zostanie użyta do przeprowadzenia wstępnego wyszukiwania. Taki indeks będzie także znacznie bardziej użyteczny w przypadku zapytań obejmujących tylko kolumnę A niż w przypadku zapytań obejmujących tylko kolumnę B.
Utwórz indeks wielokolumnowy na A i B. Ten indeks byłby zwykle bardziej wydajny w przypadku zapytań obejmujących obie kolumny. W przypadku zapytań dotyczących tylko A indeks ten byłby wolniejszy niż indeks samego A. Ten indeks byłby mało przydatny w przypadku zapytań obejmujących tylko B. Aby to zrekompensować, można utworzyć dodatkowy indeks na B.

Oba te fragmenty pokazują, że indeksy wielokolumnowe są lepsze do specjalistycznego użytku. Ponadto użycie takiego indeksu do sortowania tylko jednej z uwzględnionych kolumn może faktycznie zaszkodzić wydajności. Z tego powodu prawdopodobne jest, że indeksy poszczególnych kolumn będą konieczne dla każdego z atrybutów zawartych w indeksie wielokolumnowym.

Znalazłem link do starego, ale interesującego dokumentu ESRI, w którym podano 9 powodów, dla których warto wybrać plik zamiast osobistego GDB . Interesujące jest to, że konkretnie określa wydajność jako jeden z powodów. Część tego wzrostu wydajności wynika z systemu pamięci masowej opartego na plikach. Myślę, że może to również mieć wpływ na brak obsługi wielu kolumn. W przeciwieństwie do Personal GDB, który jest pojedynczym plikiem, indeks w pliku GDB jest przechowywany jako osobny plik w strukturze GDB. Oznacza to, że plik indeksu i plik atrybutu dla określonej klasy obiektów będą musiały być połączone i dostępne razem. Widziałem, gdzie indeks wielokolumnowy prowadziłby do przeskakiwania między plikami indeksu i plików atrybutów i potencjalnie powodując wzrost wydajności przewyższający wzrost wydajności indeksowania.

Ponieważ już osiągnięto znaczny wzrost wydajności pliku GDB w porównaniu z osobistym GDB, prawdopodobnie nie było warto wdrożyć indeksu wielokolumnowego.

Z mojego doświadczenia w pracy z obydwoma typami GDB, widziałem, że Personal GDB działa o około 50% większy niż plik. Na podstawie danych podanych w związku z plikiem GDB, gdybyś przekonwertował na PGDB, prawdopodobnie uzyskałbyś około 300 MB osobistego GDB. Z tego, co widziałem, praca z bazami MS Access, zarówno w produktach ESRI, jak i osobno, polega na tym, że zauważasz spadek wydajności, gdy pliki „.mdb” wzrosną znacznie ponad 100 MB.

Innym problemem byłoby prawdopodobnie to, że nawet gdybyś mógł przyspieszyć wyszukiwanie atrybutów, zobaczyłbyś duży spadek wydajności związany z poruszaniem się w ramce danych i odświeżaniem widoku. Warstwa po prostu nie rysowałaby tak szybko, gdyby była w PGDB. W tym artykule porównującym typy Geodat baz danych podano więcej informacji na temat różnic w wydajności.

Podobnie jak w przypadku wielu rzeczy, najlepszy wybór ostatecznie sprowadza się do Twojego przypadku użycia. Jeśli istnieje wiele operacji specyficznych dla bazy danych, które chcesz wykonać, takich jak zapytania i aktualizacje, które możesz wykonać w interfejsie Access, to Personal GDB może być lepszy. Jeśli planujesz tylko wykonać kilka zapytań, ale przede wszystkim będziesz wizualizować dane przestrzenne, wydajność zdecydowanie spada na stronę pliku GDB.

Istnieje co najmniej 9 głównych powodów, dla których warto korzystać z Geobazy Plików zamiast Geobazy Osobistej. Niestety, wciąż istnieje wiele innych powodów, aby trzymać stary PGDB w pobliżu; twój dylemat jest jednym z nich. (brak publikacji ESRI na ten temat)

Uważam, że głównym celem FGDB nad PGDB jest pojemność pamięci i wydajność danych przestrzennych (szybkość rysowania, pobieranie, indeksowanie przestrzenne, zapytania przestrzenne itp.), A nie funkcjonalność, taka jak indeksy „atrybutów” w wielu kolumnach i inne zaawansowane funkcje SQL, które są zwykle taką integralną częścią każdego DBMS. (Czym jest PGDB oparty na MS Access, a FGDB natywny ESRI nie jest) Na marginesie; Maksymalny rozmiar pliku bazy danych MS Access wynosi 2 GB, co jest również maksymalnym rozmiarem dowolnego pojedynczego PGDB. Natomiast limit rozmiaru pliku FGDB wynosi od 1 TB do 256 TB.

ESRI stwierdza również, że: Składnia używana do budowy wyrażenia SQL różni się w zależności od źródła danych. Wynika to z faktu, że chociaż SQL jest standardem, nie wszystkie programy baz danych implementują ten sam dialekt SQL. oraz Aby wyszukiwać dane oparte na plikach, w tym geobazy danych, pokrycia, pliki kształtów, tabele INFO, tabele dBASE, dane CAD i VPF, używasz dialektu SQL zaimplementowanego w ArcGIS, który obsługuje podzbiór funkcji i funkcji dostępnych osobiście i Geobazy ArcSDE.

Innymi słowy (a PGDB i ArcSDE GDB są tego dowodem), jeśli geobaza bazowa DBMS obsługuje tę funkcjonalność, powinna być dostępna . Prawdopodobnie dlatego możesz utworzyć indeks wielokolumnowy w PGDB, który ma bazową bazę danych MS Access. To samo z każdą geobazą ArcSDE z bazowym DBMS, który obsługuje tę funkcjonalność.

Jeśli chodzi o geodazę plików ; w wersji 9.2 FGDB ESRI sugeruje, że niektóre z tych funkcji i funkcji mogą zostać dodane w przyszłych wersjach FGDB, cytując; „Geobazie plików nie obsługują wszystkich funkcji i funkcji dostępnych w osobistych geobazach. W ArcGIS 9.2 najczęściej używane funkcje nieobsługiwane przez geobazie plików to DISTINCT, GROUP BY i ORDER BY, a ustawione funkcje AVG, COUNT, MIN, MAX i SUM nie są obsługiwane poza podkwerendami. Obsługa niektórych z nich prawdopodobnie zostanie dodana w przyszłych wydaniach. ”

Cztery lata później w wersji 10 żadna z tych funkcji i funkcji nie jest dostępna. ( Lista dostępnych funkcji )

Wydaje się, że FGDB jest w toku i potrzebuje indeksowania wielokolumnowego w takim samym stopniu, jak potrzebuje wszystkich niezbędnych funkcji SQL DBMS. Chyba utkniemy w PGDB, dopóki programiści ESRI nie zdecydują, że ważne jest rozszerzenie jego funkcjonalności na FGDB.

Wznawiając ten wątek / problem, zauważyłem, że przydatne może być połączenie FGDB i PGDB. Na przykład uczynienie z bazy danych od podstaw PGDB znacznie pomogło w wydajności zapytań. Rozmiar PGDB nie powinien zbytnio wzrosnąć, jak wspomniano powyżej.