PostgreSQL та MySQL: порівняння просторових характеристик

Ми зараз розробляємо веб-додаток, який містить компонент просторових даних. На початку наші порівняння просторових даних візьмуть задану точку і повернуть збігаються перекриваються просторові багатокутники.

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

Ми перебуваємо в точці нашого проекту, де ми повинні вибрати, яке рішення для бази даних використовувати.

Усі учасники проекту більше знайомі з впровадженням та адмініструванням MySQL, але всі дослідження говорять про те, що PostgreSQL є кращим рішенням - особливо щодо просторових даних, що використовують postGIS.

Ми сподіваємось (сподіваємось), що наш додаток переживе багато дій із великою кількістю одночасних користувачів.

Хто-небудь із досвідом використання MySQL в якості RDBMS з компонентом просторових даних має якісь довгострокові поради / досвід?

Чи є недоліки використання PostGIS за винятком ознайомлення?

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

Для прикладу, на PGEast 2010 року деякі люди з FAA розмовляли про перетворення їх бази аеропортів (що використовується AeroNav та інші для складання графіків) у Postgres / PostGIS від Oracle.
Сайт avationDB також побудований поверх Postgres (8.0).

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

Що стосується переходу з MySQL, документація за Postgres є першокласною, а також є розділ Oostgres Wiki про перехід від MySQL до Postgres .
Початкова крива навчання може бути трохи крутою, і вам може знадобитися налаштувати вашу базу даних і будь-які збережені процедури (якщо ви їх вже написали для MySQL), але це не є непереборним завданням.

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

Якщо говорити про деякі дуже важливі речі. Ось список речей, які підтримує PostGIS, які повністю відсутні в MySQL та MariaDB.

• SRID в розрахунках, дайте своїм балам інший SRID, і ви отримаєте різні значення назад. Це функції сукупності опор: наскільки мені відомо, MySQL не пропонує функцій просторових агрегатів

До найближчого сусіда: Тільки PostGIS підтримує KNN. Знайдіть найближчу до будь-якої точки, використовуючи лише індекс: не потрібно обчислювати відстань від усіх точок! Er. MySQL розбиває spec і перевіряє, чи мають два значення однаковий SRID. PostGIS постачається з базою даних визначень pro4j для забезпечення безперебійної обізнаності про SRID. Встановлення SRID та виклик ST_Transform( функція MySQL відсутня ) відхилить ваші координати.

У MySQL всі обчислення проводяться з урахуванням SRID 0, незалежно від фактичного значення SRID. SRID 0 являє собою нескінченну плоску декартову площину без одиниць, присвоєних її осям. Надалі для обчислень можуть використовуватися вказані значення SRID. Для забезпечення поведінки SRID 0 створіть значення геометрії за допомогою SRID 0. SRID 0 є типовим для нових значень геометрії, якщо SRID не вказано.

• Растри : тут є безліч особливостей від генерації растру до видобутку. Ви можете генерувати теплові карти тощо.

• Географія , PostGIS підтримує непрогнозований тип географії, який взагалі не використовує декартову математику. Він має цілу повільність асоційованих функцій, які діють на облітерованих сфероїдах. MySQL навпаки не може навіть створити обмежувальне поле в географічному SRS з двох точок.

• Топологія , відмінна від векторної геометрії, топогеоми зберігають вузли та відносини. Перемістіть вузол, край теж переміститься, і ви отримаєте нове обличчя. Це також змушує спрямовувати краї, що робить їх ідеальними для маршрутизації. Оскільки підпункт 100% того, що робить PgRouting , недоступний для MySQL - так що ви просто не можете створити Карти Google тощо.

• Геокодування: у каталозі contrib є розширення геокодера, яке працює з переписом даних, і завантажувач для встановлення цих даних.

• Стандартизація адрес: є розширення, яке обробляє нормалізуючі адреси для легкого розбору, зберігання та порівняння.

• Функції SQL-MM ви просто не знайдете CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVEабо не MULTISURFACEв MySQL.

• й шнури: PostGIS може підтримувати 3dm, 3dz та 4d фігури та точки MySQL просто не може

• MySQL підтримує лише індекси r-дерева. PostGIS підтримує r-дерево (gist / gin) та BRIN (для великих таблиць геометрії)

• Функції сукупності : наскільки мені відомо, MySQL не пропонує функцій просторових агрегатів

• До найближчого сусіда: Тільки PostGIS підтримує KNN . Знайдіть найближчу до будь-якої точки, використовуючи лише індекс: не потрібно обчислювати відстань від усіх точок!

• Індексація. PostgreSQL дозволяє зберігати будь-які дані у вашому просторовому індексі (що є індексом gist / gin). Наприклад, ви можете зберігати year(або інші непросторові дані) і geomтой самий індекс. Див. btree_ginТа btree_gistдля отримання додаткової інформації про те, як це зробити.

Також, ймовірно, є 200 або більше функцій підтримуються PostGIS.

Якщо коротко, MySQL не влаштовує PostGIS, і він це знає. PostGIS - звір. Просто хотів пояснити деякі з цього матеріалу.

Я повністю погоджуюся з усіма твердженнями першої відповіді, але ділюсь власним досвідом - Я це зробив у Національній адміністрації доріг моєї країни: критик виробництва, сайт з високим трафіком. Я пропоную подавати веб-додаток MySQL та PostgreSQL / PostGIS.

Для всіх "типових" речей веб-додаток працює бездоганно з CMS на базі MySQL. Для всіх просторових завдань той самий веб-додаток працює - також бездоганно;) з PostgreSQL / PostGIS обґрунтованою спеціальною розробкою. Перший компонент був розроблений і без особливих зусиль підтримується нормальними навичками MySQL. Другий компонент передбачав трохи більше наукових зусиль на початку.

Вам не доведеться змушувати дорого реалізовувати типові речі в не дуже знайомому PostgreSQL / PostGIS, і вам не доведеться примусово виконувати неоптимальну реалізацію геопросторових речей у MySQL. Нехай кожен гравець грає там, де може вдарити.