Wydajność ArcGIS Engine przy użyciu wielu geobaz danych z plikami w przeciwieństwie do jednej?


11

Staram się wybrać najlepszy sposób organizacji moich danych dla aplikacji ArcGIS Engine. Szczególnie interesuje mnie szybkość wyświetlania map i zapytań. Obecnie wszystkie moje dane są podzielone na osobne geobazie plików na podstawie motywu. Mam więc Transport.gdb, Utilities.gdb itp. Dane niekoniecznie muszą być organizowane na podstawie motywów i rozważam umieszczenie ich wszystkich w jednej geobazie pliku.

Będę przeprowadzać własne testy, ale chciałem zadać to pytanie społeczności.

Ogólnie rzecz biorąc, czy korzystanie z geobazy danych z jednego pliku jest szybsze niż używanie wielu (w przybliżeniu 7) mniejszych? Interesują mnie również inne zalety / wady.

UWAGA: oprogramowanie i wszystkie dane będą na lokalnej maszynie klienta. Żadne dane nie są podawane w Internecie ani w sieci, a ilość danych jest dość mała (około 100 000 funkcji).

Odpowiedzi:


5

Idę w drugą stronę i faktycznie mówię, że nie, oddzielenie baz danych GeoDat dla tego konkretnego przypadku użycia, który opisałeś, nie jest dobrym ulepszeniem wydajności .

Musisz pamiętać, że połączenie z DB wiąże się z pewnym kosztem. W przypadku GeoDatabase ładuje wszystkie powiązane tabele metadanych. Tak więc za każdym razem, gdy dzielisz swoje dane na wiele GDB, po prostu zwiększasz ten koszt, ponieważ teraz musisz otworzyć wiele wersji tych tabel (po jednej dla każdego DB). Multipleksowanie w celu przeszukiwania różnych baz danych zwykle może również oznaczać operacje we / wy z pamięcią podręczną, która zostanie unieważniona.

Niemniej jednak istnieje kilka przypadków, w których posiadanie wielu baz danych może działać lepiej. Na przykład. Rozważmy przypadek osobistego gdb (nie filegdb), który ma 700 MB w porównaniu z dwoma, które są 350 MB na sztukę. Sterownik MS Jet (używany do interakcji z plikami .mdb) będzie mapował pamięć plików mniejszych niż 500 MB - więc jeśli maszyna ma wystarczającą ilość pamięci, będziesz wchodził w interakcje z bazami danych w pełni w stosunku do dowolnego dysku we / wy. Znacznie szybciej. Plik 700 MB nie zostanie zmapowany w pamięci.

Biorąc tę ​​sprawę z równania, nie ma sensu robić osobnych dbs. ArcMap, przechodząc między warstwami, będzie kolejno sprawdzał każdą warstwę, więc nie masz żadnej równoległości.

Lepiej zamiast tego odbuduj indeksy FileGDB.

I tak, SSD zdecydowanie by pomógł.


1
O. Mapowanie pamięci <500mb .mdb jest interesujące. Zapisałem osobiste pliki GDB jako nieprzydatne do niczego innego niż zmiana kolejności i zmiana nazw pól w MS-Access zamiast bolesnego procesu dodawania i kopiowania i usuwania wymaganego w Arcgis. Może teraz mam inny powód, aby od czasu do czasu z nich korzystać. Czy plik punktu krytycznego 500mb na rozmiar dysku czy coś innego? (np. plik JPEG może mieć rozmiar 30 KB na dysku, ale zużywa wiele megabajtów pamięci RAM, gdy jest otwarty).
matt wilkie

1
O ile pamiętam, było to zachowanie samego silnika Jet, a nie wywołane przez ESRI. Ponadto był nieco mniejszy niż 500 MB. Dobre pytanie o rozmiar pliku a pamięć. Myślę, że to był rozmiar pliku - ale nie pamiętam dokładnie, szczerze mówiąc
Ragi Yaser Burhum

4

W rzeczywistości jest to na odwrót; mniejsze bazy danych odpytują szybciej. To tak, jakby pytać, czy możesz szybciej znaleźć rzeczy, jeśli rzucisz wszystko na dużą kupę w piwnicy, zamiast sortować je do pojedynczych szafek na dokumenty. Gdy masz indywidualne bazy danych, to tak, jakbyś miał 6 szafek na dokumenty, których możesz zignorować od samego początku i nie musisz się przez nie przeglądać. Oczywiście zakłada to, że wiesz, która baza danych wymaga odpytywania - jeśli i tak musisz je wszystkie przejrzeć, to jeden duży może rzeczywiście być szybszy (ponieważ może zoptymalizować zestaw danych jako całość).


3

Kiedyś miałem podobną konfigurację z ArcReaderem na urządzeniach, które nie były zbyt dobrze dostosowane do GIS i miały szczęście utrzymywać stabilne połączenie sieciowe z serwerem GIS ( mówimy o niestabilnych połączeniach przewodowych ... nie bezprzewodowych ).

Miałem wiele baz danych, które były ogólnie podzielone według „tematu”, a także częstotliwości aktualizacji. Rozbijałem je codziennie, co miesiąc, co roku lub co trzy lata (co było harmonogramem aktualizacji z lotu / planimetrycznego). Ponieważ zostały zaktualizowane za pomocą robocopy, nie chciałem przenosić żadnych niepotrzebnych danych na te urządzenia.

Jeśli znajdujesz się w środowisku, w którym nie masz solidnych możliwości replikacji geobazy, lub po prostu otrzymujesz geobazę plików do dystrybucji, łatwiej jest zarządzać, dzieląc pamięć na dane w ten sposób.

Aby odpowiedzieć na pytanie dotyczące wydajności: Nigdy nie zauważyłem zmniejszenia prędkości, dzieląc moje magazyny danych na osobne geobazie plików. To nie znaczy, że ich nie było, ale jeśli tak, to nie było to odczuwalne przez ludzi. Warto zauważyć, że te konfiguracje miały wszystkie geobazy plików na 1 dysku twardym - możesz uzyskać wzrost wydajności, gdybyś miał je rozproszone na urządzeniach SCSI / SSD.


2

Kiedyś miałem około pięciu aplikacji WebADF ArcGIS Server, z których każda obejmowała inny obszar geograficzny, ale wszystkie one miały wspólne zestawy danych. Zabójca polegał na tym, że wszystkie aplikacje były dynamiczne (nic nie było buforowane), a my mieliśmy w nich studnie ropy i gazu, które mogą być liczone w setkach tysięcy (w rzeczywistości milionów w całym USA). Wykonywanie zapytań dotyczących całego zestawu danych było bolesne - w rzeczywistości zwykle przekraczały limit czasu. Wycięcie danych dla każdego obszaru i umieszczenie ich w osobnym magazynie danych pozwoliło nam zwiększyć wydajność i zadowolić naszych klientów. Podobnie jak Ty, zachowaliśmy również geobazy danych przechowywane na dysku twardym na serwerze, co również pomogło ALOT. Mieliśmy zautomatyzowany proces, który każdej nocy przenosił dane do każdej geobazy danych pliku.

Nie do końca odpowiedź, ale raczej studium przypadku w czymś podobnym do tego, o czym myślisz. Gdybyśmy nie mieli do czynienia z tak wieloma dynamicznymi funkcjami, moglibyśmy tego nie robić. Czasami konieczne jest robienie rzeczy nieco niestandardowych.


Dziękuję za odpowiedź. Nie do końca pasuje do mojej sytuacji, ale jest dobry wgląd dla innych osób w podobnej sytuacji. Nie wspomniałem, że wszystkie dane będą wraz z oprogramowaniem na lokalnej maszynie klienta. Żadne dane nie są podawane przez Internet (inne niż wtedy, gdy trzeba zainstalować aktualizacje oprogramowania). Ponadto ilość danych, z którymi pracuję, to niewielki ułamek ilości, z którą pracujesz.
Tanner

4
Nie sądziłem, że służysz przez Internet, ale nawet posiadanie FGDB w udziale sieciowym może spowolnić proces przesyłania danych. Jeśli nie pracujesz z ogromnymi zestawami danych, nie sądzę, aby osobne FGDB przyniosłyby ci wiele dobrego - może to być bardziej bolesne niż warte.
Chad Cooper
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.