Продуктивність ArcGIS Engine з використанням декількох файлових баз геоданих на відміну від однієї?

Я намагаюся вирішити найкращий спосіб впорядкувати свої дані для програми ArcGIS Engine. Мене особливо цікавлять показ карти та швидкість запитів. Наразі всі мої дані розділені на окремі файли геоданих на основі теми. Отже, у мене є Transportation.gdb, Utilities.gdb і т. Д. Дані не обов’язково потрібно організовувати на основі тем, і я розглядаю можливість розмістити все це в одній базі даних геоданих.

Я буду робити власне тестування, але я хотів передати це питання громаді.

Взагалі, чи використовує базу даних геоданих одного файлу швидше, ніж використовувати декілька (приблизно 7) менших? Мене також цікавлять будь-які інші плюси / мінуси.

ПРИМІТКА: програмне забезпечення та всі дані знаходяться на локальній машині замовника. Немає даних, що подаються в Інтернеті або в мережі, а обсяг даних досить малий (приблизно 100 000 функцій).

Я збираюся піти іншим шляхом і фактично скажу, що ні, це не гарне покращення продуктивності, щоб відокремити бази даних GeoData для цього конкретного випадку використання, який ви описали .

Ви повинні пам’ятати, що існує вартість, пов’язана з підключенням до БД. У випадку з GeoDatabase він завантажує всі відповідні таблиці метаданих. Отже, коли ви розділяєте свої дані на кілька GDB, ви просто збільшуєте цю вартість, тому що тепер вам потрібно відкрити кілька версій цих таблиць (по одній для кожної БД). Мультиплексування для запиту різних БД зазвичай також може означати введення / виведення кешу, який стає недійсним.

Тим не менш, є кілька випадків, коли наявність декількох БД може працювати краще. Наприклад. Розглянемо випадок особистого gdb (не filegdb), який становить 700 Мбайт проти двох, що є 350 Мб за штуку. Драйвер MS Jet (який використовується для взаємодії з .mdb-файлами) буде зберігати файли пам'яті розміром менше 500 Мб - тому, якщо у машини достатньо пам'яті, ви будете повністю взаємодіяти з БД в пам'яті проти будь-якого дискового вводу / виводу. Набагато швидше. Файл 700 МБ не буде відображено в пам'яті.

Виймаючи цей випадок із рівняння, тоді не має сенсу робити окремі dbs. ArcMap, переглядаючи шари, запитує кожен шар послідовно, тому у вас не виникає жодного паралелізму.

Вам краще замість цього відновити індекси FileGDB.

І так, SSD напевно допоможе.

Насправді це нормально навпаки; менші бази даних запитують швидше. Це як запитати, чи зможете ви швидше знайти речі, якщо кинути все у великій купі в підвалі, а не розбирати в окремі шафи для подачі. Якщо у вас є окремі бази даних, це як би мати 6 шаф для подачі документів, які ви можете з самого початку знехтувати, і не потрібно їх переглядати. Звичайно, це передбачає, що ви знаєте, яка база даних потребує запитів - якщо вам все одно потрібно переглянути їх, то одна велика може бути швидшою (тому що вона може оптимізувати набір даних у цілому).

Свого часу у мене було подібне налаштування з ArcReader на пристроях, які не дуже добре підходили для GIS і пощастило підтримувати стабільне мережеве з'єднання з GIS-сервером ( ми говоримо про нестабільні провідні з'єднання ... не бездротові ).

У мене були численні бази даних, які, як правило, були порушені "темою", а також частотою оновлення. Я розбивав їх щодня, щомісяця, щорічно чи трирічно (що було графіком оновлення повітря / Планіметричний). Оскільки вони оновлювалися за допомогою роботоскопії, я не хотів переміщувати на ці пристрої будь-які непотрібні дані.

Якщо ви перебуваєте в середовищі, де у вас немає надійної можливості реплікації бази даних геоданих, або ви просто отримуєте файлову базу даних для розповсюдження, вам може бути легше керувати, розбивши таким чином сховище даних.

Щоб відповісти на ваше запитання щодо продуктивності: я ніколи не помічав жодної скорочення, розбиваючи свої сховища даних на окремі файли геоданих. Це не означає, що їх не було, але якщо вони були, це було не сприйнятливо для людини. Варто зазначити, що ці конфігурації мали всі бази даних про геодані на одному жорсткому диску - ви можете отримати підвищення продуктивності, якби вони розповсюдили їх на пристроях SCSI / SSD.

Я колись мав близько п'яти веб-додатків ArcGIS Server WebADF, які охоплювали різні географічні області, але всі вони мали спільні набори даних. Вбивця полягала в тому, що всі програми були динамічними (нічого не було кешовано), і у них були нафтові та газові свердловини, які могли б налічувати сотні тисяч (фактично мільйони для всього США). Здійснення запитів у цілому наборі даних було болісним - насправді вони зазвичай були б лише тимчасовим. Відсікання даних для кожної області та розміщення їх в окремому сховищі даних підтримували нашу ефективність та задовольняли наших клієнтів. Як і ви, ми також зберігали файли геоданих, що зберігаються на жорсткому диску на сервері, що також допомогло ALOT. У нас був автоматизований процес, який кожну ніч вирізав дані з кожної файлової бази даних.

Не зовсім відповідь, а більше тематичне дослідження чимось подібне до того, що ти думаєш робити. Якби у нас не було б так багато динамічних функцій, з якими ми могли б працювати, нам, можливо, не довелося б цього робити. Іноді потрібно робити щось незвичне.