PostgreSQL so với MySQL: so sánh tính năng không gian

Chúng tôi đang trong quá trình xây dựng một ứng dụng web có thành phần dữ liệu không gian. Ban đầu, các so sánh dữ liệu không gian của chúng tôi sẽ lấy một điểm nhất định và trả về các đa giác không gian chồng lấp phù hợp.

Điều đó đang được nói, cơ sở dữ liệu của chúng tôi có nhiều thành phần khác bao gồm tất cả những điều điển hình bạn sẽ tìm thấy trong cơ sở dữ liệu quan hệ chung của bạn.

Chúng tôi đang ở điểm trong dự án của chúng tôi, nơi chúng tôi phải chọn giải pháp cơ sở dữ liệu nào sẽ sử dụng.

Tất cả các thành viên dự án đều quen thuộc hơn với việc triển khai và quản trị MySQL, tuy nhiên tất cả các nghiên cứu cho thấy PostgreQuery là giải pháp tốt hơn - đặc biệt là liên quan đến dữ liệu không gian sử dụng postGIS.

Chúng tôi hy vọng (hy vọng) ứng dụng của chúng tôi sẽ trải nghiệm nhiều hành động với nhiều người dùng đồng thời.

Có ai có kinh nghiệm sử dụng MySQL làm RDBMS của họ với thành phần dữ liệu không gian có bất kỳ lời khuyên / kinh nghiệm dài hạn nào không?

Có bất kỳ nhược điểm nào khi sử dụng PostGIS ngoại trừ sự quen thuộc không?

Tôi không thể nói về ưu điểm / nhược điểm của MySQL, nhưng mã PostGIS được coi là một trong những thứ tốt nhất (về tốc độ / chức năng) và trưởng thành nhất (về kiểm tra / tiếp xúc với thế giới thực ) có sẵn.

Ví dụ, đã có một cuộc nói chuyện tại PGEast 2010 bởi một số người từ FAA về việc chuyển đổi cơ sở dữ liệu sân bay của họ (được sử dụng bởi AeroNav và những người khác để biên dịch biểu đồ) cho Postgres / PostGIS từ Oracle.
Các trang web avationDB cũng được xây dựng trên đầu trang của Postgres (8,0).

Nếu các truy vấn liên quan đến GIS là trung tâm của những gì bạn đang thực hiện thì đề xuất của tôi sẽ là với Postgres. Nó chắc chắn có thể xử lý mọi thứ khác mà bạn thường làm trong cơ sở dữ liệu quan hệ.

Về mặt thực hiện chuyển đổi từ MySQL, tài liệu đằng sau Postgres là ưu tiên hàng đầu, và cũng có một phần của Oostgres Wiki về việc chuyển đổi từ MySQL sang Postgres .
Đường cong học tập ban đầu có thể hơi dốc và bạn có thể cần phải điều chỉnh cơ sở dữ liệu của mình và mọi thủ tục được lưu trữ (nếu bạn đã viết chúng cho MySQL), nhưng đó không phải là một nhiệm vụ không thể vượt qua.

Bạn sẽ có thể nhận đủ để thực hiện chuyển đổi trong một vài tuần và nếu bạn thiết lập cơ sở dữ liệu phát triển, bạn có thể thành thạo các công việc thường xuyên trong vòng một tháng và tự tin rằng bạn biết nơi cần tìm trong hướng dẫn cho những người không thường xuyên

Nói về một số điều rất quan trọng. Dưới đây là danh sách những thứ mà PostGIS hỗ trợ hoàn toàn không có trong MySQL và MariaDB.

• SRID trong tính toán, cung cấp cho điểm của bạn một SRID khác và bạn sẽ nhận lại các giá trị khác nhau. Đây là chức năng tổng hợp prop: theo hiểu biết tốt nhất của tôi, MySQL không cung cấp chức năng tổng hợp không gian

Hàng xóm gần nhất của K: Chỉ PostGIS hỗ trợ KNN. Tìm điểm gần nhất đến bất kỳ điểm nào chỉ bằng một chỉ mục: không cần tính khoảng cách từ tất cả các điểm! Er. MySQL phá vỡ thông số kỹ thuật và chỉ kiểm tra hai giá trị có cùng SRID. PostGIS đi kèm với một cơ sở dữ liệu về các định nghĩa pro4j để cho phép nhận thức SRID liền mạch. Đặt SRID và gọi ST_Transform( một chức năng mà MySQL thiếu ) sẽ từ chối tọa độ của bạn ..

Trong MySQL, tất cả các tính toán được thực hiện với giả định SRID 0, bất kể giá trị SRID thực tế. SRID 0 đại diện cho một mặt phẳng Cartesian phẳng vô hạn không có đơn vị nào được gán cho trục của nó. Trong tương lai, các tính toán có thể sử dụng các giá trị SRID được chỉ định. Để đảm bảo hành vi SRID 0, tạo các giá trị hình học bằng SRID 0. SRID 0 là mặc định cho các giá trị hình học mới nếu không có SRID được chỉ định.

• Raster : có rất nhiều tính năng ở đây từ thế hệ raster đến trích xuất. Bạn có thể tạo ra bản đồ nhiệt và những thứ tương tự.

• Địa lý , PostGIS hỗ trợ một loại địa lý chưa được cung cấp mà hoàn toàn không sử dụng toán học Cartesian. Nó có toàn bộ chậm các chức năng liên quan hoạt động trên các hình cầu bắt buộc. Ngược lại, MySQL thậm chí không thể tạo hộp giới hạn trong SRS địa lý từ hai điểm.

• Cấu trúc liên kết , khác biệt với hình học vector, địa chất topo lưu trữ các nút và quan hệ. Di chuyển một nút, cạnh cũng di chuyển và bạn có một khuôn mặt mới. Điều này cũng buộc các cạnh phải được định hướng khiến chúng trở nên lý tưởng cho việc định tuyến. Là một điểm phụ 100% những gì PGRouting không có sẵn cho MySQL - vì vậy bạn không thể tạo Google Maps hoặc những thứ tương tự ở trên nó.

• Mã hóa địa lý: có bộ giải mã trình mã hóa địa lý trong thư mục contrib hoạt động với dữ liệu điều tra dân số và trình tải để cài đặt dữ liệu đó.

• Địa chỉ tiêu chuẩn: có một phần mở rộng mà địa chỉ xử lý bình thường hóa cho phân tích cú pháp dễ dàng, lưu trữ, và so sánh.

• Các tính năng SQL-MM , đơn giản là bạn sẽ không tìm thấy CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVEhoặc MULTISURFACEtrong MySQL.

• dây thứ hai: PostGIS có thể hỗ trợ các hình dạng 3dm, 3dz và 4d và các điểm MySQL đơn giản là không thể

• MySQL chỉ hỗ trợ các chỉ mục r-tree. PostGIS hỗ trợ r-tree (gist / gin) và BRIN (cho các bảng hình học lớn)

• Chức năng tổng hợp: để sự hiểu biết MySQL hàng của mình không có uẩn không gian chức năng

• Hàng xóm gần nhất của K: Chỉ PostGIS hỗ trợ KNN . Tìm điểm gần nhất đến bất kỳ điểm nào chỉ bằng một chỉ mục: không cần tính khoảng cách từ tất cả các điểm!

• Lập chỉ mục. PostgreSQL cho phép bạn lưu trữ bất kỳ dữ liệu nào trên chỉ mục không gian của bạn (là chỉ số chính / gin). Ví dụ: bạn có thể lưu trữ year(hoặc dữ liệu phi không gian khác) và geomtrên cùng một chỉ mục. Xem btree_ginvà btree_gistđể biết thêm thông tin về cách làm điều này.

Ngoài ra, có thể có hơn 200 chức năng được PostGIS hỗ trợ.

Nói tóm lại, MySQL không giữ riêng cho PostGIS và nó biết điều đó. PostGIS là một con thú. Chỉ muốn giải thích một số thứ này.

Tôi hoàn toàn đồng ý với tất cả các tuyên bố về câu trả lời đầu tiên, nhưng chia sẻ kinh nghiệm của riêng tôi - Tôi đã thực hiện điều này trên Cơ quan Quản lý Đường bộ Quốc gia của tôi: nhà phê bình sản xuất, trang web có lưu lượng truy cập cao. Tôi đề nghị một ứng dụng web được cung cấp bởi cả MySQL và PostgreSQL / PostGIS.

Đối với tất cả những thứ "điển hình", ứng dụng web hoạt động hoàn hảo với CMS dựa trên MySQL. Đối với tất cả các tác vụ không gian, cùng một ứng dụng web hoạt động - cũng hoàn hảo;) với sự phát triển tùy chỉnh có căn cứ của PostgreQuery / PostGIS. Thành phần đầu tiên được phát triển và duy trì dễ dàng với các kỹ năng MySQL thông thường. Thành phần thứ hai liên quan đến nỗ lực nghiên cứu nhiều hơn một chút lúc đầu.

Bạn không cần phải thực hiện toàn bộ chi phí thực hiện tốn kém của các công cụ điển hình trong PostgreQuery / PostGIS không quen thuộc và bạn cũng không phải ép buộc triển khai tối ưu các công cụ không gian địa lý trong MySQL. Hãy để mọi người chơi chơi ở nơi nó có thể đánh.