Tôi đã làm việc với cả ba cơ sở dữ liệu và thực hiện việc di chuyển giữa chúng, vì vậy hy vọng tôi vẫn có thể thêm thứ gì đó vào bài đăng cũ. Mười năm trước, tôi được giao nhiệm vụ đưa một tập dữ liệu lớn - 450 triệu đối tượng không gian - từ GML vào cơ sở dữ liệu không gian. Tôi quyết định dùng thử MySQL và Postgis, vào thời điểm đó không có không gian trong SQL Server và chúng tôi có một bầu không khí khởi động nhỏ, vì vậy MySQL có vẻ phù hợp. Sau đó, tôi đã tham gia vào MySQL, tôi đã tham dự / phát biểu tại một vài hội nghị và tham gia rất nhiều vào quá trình thử nghiệm beta của các chức năng tuân thủ GIS hơn trong MySQL cuối cùng đã được phát hành với phiên bản 5.5. Sau đó, tôi đã tham gia vào việc di chuyển dữ liệu không gian của chúng tôi sang Postgis và dữ liệu công ty của chúng tôi (với các yếu tố không gian) sang SQL Server. Đây là những phát hiện của tôi.
MySQL
1). Các vấn đề về độ ổn định. Trong suốt 5 năm, chúng tôi đã gặp một số vấn đề về lỗi cơ sở dữ liệu, vấn đề này chỉ có thể được khắc phục bằng cách chạy myismachk trên tệp chỉ mục, một quá trình có thể mất hơn 24 giờ trên bảng 450 triệu hàng.
2). Cho đến gần đây, chỉ có bảng MyISAM hỗ trợ kiểu dữ liệu không gian. Điều này có nghĩa là nếu bạn muốn hỗ trợ giao dịch, bạn không gặp may. Loại bảng InnoDB hiện hỗ trợ các kiểu không gian, nhưng không hỗ trợ các chỉ mục trên chúng, với kích thước điển hình của các tập dữ liệu không gian, không hữu ích lắm. Xem http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Kinh nghiệm của tôi khi đi dự hội nghị là không gian là một suy nghĩ rất lớn - chúng tôi đã triển khai nhân rộng, phân vùng, v.v. nhưng nó không hoạt động với spatial.
3). Chức năng không gian rất hạn chế so với cả không gian Postgis và SQL Server. Vẫn không có hàm ST_Union nào hoạt động trên toàn bộ trường hình học, một trong những truy vấn tôi thường chạy nhất, tức là bạn không thể viết:
select attribute, ST_Union(geom) from some_table group by some_attribute
rất hữu ích trong bối cảnh GIS. Select ST_Union(geom1, const_geom) from some_table , tức là, một trong những hình học là hình học hằng số được mã hóa cứng thì có một chút hạn chế khi so sánh.
4). Không hỗ trợ cho raster. Có thể thực hiện phân tích vector-raster kết hợp trong một db là chức năng rất hữu ích của GIS.
5). Không hỗ trợ chuyển đổi từ hệ quy chiếu không gian này sang hệ quy chiếu không gian khác.
6). Kể từ khi được Oracle mua lại, không gian đã thực sự bị trì hoãn.
Nhìn chung, công bằng mà nói, MySQL đã hỗ trợ trang web, WMS và xử lý không gian chung của chúng tôi trong vài năm và rất dễ thiết lập. Mặt khác, hỏng dữ liệu là một vấn đề và do bị buộc phải sử dụng bảng MyISAM, bạn đang từ bỏ rất nhiều lợi ích của RDBMS.
Postgis
Với các vấn đề chúng tôi gặp phải với MySQL, cuối cùng chúng tôi đã chuyển đổi sang Postgis. Các điểm chính của kinh nghiệm này là.
1). Cực ổn định. Không có dữ liệu bị hỏng trong 5 năm và hiện chúng tôi có khoảng 25 hộp Postgres / GIS trên máy ảo centos, ở các mức độ tải khác nhau.
2). Tốc độ phát triển nhanh chóng - hỗ trợ raster, cấu trúc liên kết, 3D là những ví dụ gần đây về điều này.
3). Cộng đồng rất năng động. Kênh Postgis irc và danh sách gửi thư là những tài nguyên tuyệt vời. Sách hướng dẫn tham khảo Postgis cũng rất tuyệt vời. http://postgis.net/docs/manual-2.0/
4). Chơi rất tốt với các ứng dụng khác, dưới sự bảo trợ của OSGeo, chẳng hạn như GeoServer và GDAL.
5). Các thủ tục đã lưu trữ có thể được viết bằng nhiều ngôn ngữ, ngoài plpgsql mặc định, chẳng hạn như Python hoặc R.
5). Postgres là một RDBMS rất tuân thủ các tiêu chuẩn, có đầy đủ tính năng, nhằm mục đích bám sát các tiêu chuẩn ANSI.
6). Hỗ trợ các hàm cửa sổ và truy vấn đệ quy - không phải trong MySQL, mà trong SQL Server. Điều này đã làm cho việc viết các truy vấn không gian phức tạp hơn trở nên sạch sẽ hơn.
Máy chủ SQL.
Tôi chỉ mới sử dụng chức năng không gian của SQL Server 2008 và nhiều khó chịu của bản phát hành đó - thiếu hỗ trợ chuyển đổi từ CRS này sang CRS khác, nhu cầu thêm các tham số của riêng bạn vào chỉ mục không gian - hiện đã được giải quyết.
1). Vì các đối tượng không gian trong SQL Server về cơ bản là các đối tượng CLR, nên cú pháp có cảm giác ngược. Thay vì ST_Area (geom), bạn viết geom.STArea () và điều này càng rõ ràng hơn khi bạn xâu chuỗi các hàm lại với nhau. Việc bỏ dấu gạch dưới trong tên hàm chỉ là một khó chịu nhỏ.
2). Tôi đã có một số đa giác không hợp lệ đã được SQL Server chấp nhận và việc thiếu hàm ST_MakeValid có thể khiến việc này hơi khó khăn.
3). Chỉ dành cho Windows. Nói chung, các sản phẩm của Microsoft (như các sản phẩm của ESRI) được thiết kế để hoạt động rất tốt với nhau, nhưng không phải lúc nào các mục tiêu chính cũng lấy sự tuân thủ và khả năng tương tác của tiêu chuẩn làm mục tiêu chính. Nếu bạn đang chạy một cửa hàng chỉ dành cho cửa sổ, thì đây không phải là vấn đề.
CẬP NHẬT :đã chơi một chút với SQL Server 2012, tôi có thể nói rằng nó đã được cải thiện đáng kể. Hiện có một chức năng xác thực hình học tốt, hỗ trợ tốt cho kiểu dữ liệu Địa lý, bao gồm một đối tượng FULL GLOBE, cho phép biểu diễn các đối tượng chiếm nhiều hơn một bán cầu và hỗ trợ cho các Đường cong phức hợp và Chuỗi tròn, rất hữu ích cho việc chính xác và nhỏ gọn đại diện của cung (và vòng tròn) trong số những thứ khác. Việc chuyển đổi tọa độ từ CRS này sang CRS khác vẫn cần được thực hiện trong các thư viện của bên thứ ba, mặc dù đây không phải là một nút hiển thị trong hầu hết các ứng dụng.
Tôi chưa sử dụng SQL Server với các bộ dữ liệu đủ lớn để so sánh từng bộ một với Postgis / MySQL, nhưng từ những gì tôi thấy các chức năng hoạt động chính xác và mặc dù không hoàn toàn có đầy đủ tính năng như Postgis, nhưng đó là một cải tiến lớn đối với các dịch vụ của MySQL .
Xin lỗi vì câu trả lời dài như vậy, tôi hy vọng một số nỗi đau và niềm vui mà tôi đã phải chịu đựng trong nhiều năm qua có thể giúp ích cho ai đó.
