jsonb và khóa chính/khóa ngoài: hoạt động tốt hơn trong PostgreSQL?

Question

Tôi đang xem xét sử dụng loại cột jsonb của PostgreSQL cho một dự án phụ trợ mới mà chủ yếu sẽ phục vụ như là một API JSON REST-ful. Tôi tin rằng jsonb của PostgreSQL sẽ phù hợp với dự án này vì nó sẽ cung cấp cho tôi các đối tượng JSON mà không cần chuyển đổi trên chương trình phụ trợ.

Tuy nhiên, tôi đã đọc rằng loại dữ liệu jsonb làm chậm khi khóa được thêm vào và lược đồ của tôi sẽ cần sử dụng khóa chính và tham chiếu khóa ngoài. Tôi đã tự hỏi nếu có các khóa chính/khóa ngoài trong cột riêng của chúng (theo cách cơ sở dữ liệu quan hệ tiêu chuẩn) và sau đó có một cột jsonb cho phần còn lại của dữ liệu sẽ mang lại lợi ích, hoặc điều này sẽ gây ra vấn đề (cho dù bây giờ hoặc xuống đường)?

Nói tóm lại, sẽ:

table car(id int, manufacturer_id int, data jsonb) 

thực hiện tốt hơn hoặc tồi tệ hơn:

table car(data jsonb) 

Đặc biệt là khi nhìn lên các phím nước ngoài thường xuyên?
Có những nhược điểm nào cho cái đầu tiên, từ góc độ hiệu suất hoặc lược đồ không?

Answer 1

Tất cả các giá trị tham gia vào một PRIMARY KEY hoặc FOREIGN KEY chế phải được lưu trữ như cột dành riêng (tốt nhất ở dạng bình thường). Ràng buộc và tham chiếu không hoạt động đối với các giá trị được lồng vào nhau bên trong một cột json/jsonb.

Đối với phần còn lại của dữ liệu: phụ thuộc. Có chúng bên trong một giá trị jsonb (tốt hơn) mang những ưu điểm và nhược điểm nổi tiếng của việc lưu trữ dữ liệu kiểu tài liệu không có cấu trúc.

Đối với các thuộc tính hiện diện cho tất cả hoặc hầu hết các hàng, nó có lẽ sẽ tốt hơn (lưu trữ nhanh hơn, gọn hơn, nhỏ hơn) để lưu trữ chúng dưới dạng các cột riêng biệt. Dễ dàng lập chỉ mục và truy vấn đơn giản hơn. Mặc dù jsonb mới có amazing index capabilities, việc lập chỉ mục các cột chuyên dụng vẫn đơn giản/nhanh hơn.

Đối với các thuộc tính ít được sử dụng hoặc tự động xuất hiện hoặc nếu bạn muốn lưu trữ và truy xuất các giá trị JSON mà không cần xử lý nhiều bên trong DB, hãy xem jsonb.

Đối với cơ bản EAV structures với dữ liệu chủ yếu là ký tự, không có lồng nhau và không có kết nối với JSON, tôi sẽ xem xét hstore. Ngoài ra còn có các loại dữ liệu xml (phức tạp và tiết) và json (chủ yếu là thay thế bởi jsonb) đang mất dần.

Answer 2

Điều gì hoạt động tốt hơn? Phụ thuộc vào cách sử dụng. Đó là cùng một câu hỏi, khi bạn so sánh cơ sở dữ liệu SQL (quan hệ) và NoSQL (KeyValue hoặc Tài liệu). Đối với một số trường hợp sử dụng, cơ sở dữ liệu NoSQL hoạt động rất tốt, đối với các trường hợp khác thì không.

khái niệm quan hệ (giản đồ chuẩn hóa) được tối ưu hóa cho việc sử dụng OLTP điển hình - 70% đọc/30% viết, nhiều người dùng, nhiều cập nhật, tính toán báo cáo, một số truy vấn đặc biệt. Khái niệm quan hệ tương đối rộng tổng quát ..với khả năng sử dụng rất rộng (bằng chứng, kế toán, hỗ trợ xử lý, ...). Thông thường nó không phải là quá xấu ở khắp mọi nơi.

Rõ ràng, vì vậy các cơ sở dữ liệu chuyên biệt (Tài liệu, Khóa, Biểu đồ) có thể tốt hơn đáng kể (một đơn đặt hàng nhanh hơn) trong các trường hợp sử dụng chuyên biệt. Nhưng việc sử dụng chúng hẹp hơn đáng kể. Khi bạn ra khỏi trường hợp sử dụng được tối ưu hóa, thì hiệu suất có thể xấu.

Câu hỏi khác là kích thước cơ sở dữ liệu - số bản ghi. Sự khác biệt về hiệu suất trên cơ sở dữ liệu sản xuất có thể có ý nghĩa trong hàng trăm nghìn hàng. Đối với một số cơ sở dữ liệu nhỏ hơn, tác động có thể không đáng kể.

Postgres là cơ sở dữ liệu quan hệ và tùy chọn của tôi là sử dụng giản đồ chuẩn hóa cho tất cả dữ liệu quan trọng trong cơ sở dữ liệu. Khi bạn sử dụng nó tốt, nó là khủng khiếp nhanh chóng. Các kiểu quan hệ không phải là hoàn hảo cho một số dữ liệu mờ (HStore, JSON, XML, Jsonb) - nó là tốt hơn đáng kể so với lược đồ EAV (thực hiện tồi tệ hơn trên dữ liệu lớn hơn).

Nếu bạn cần thực hiện một số quyết định quan trọng, hãy chuẩn bị nguyên mẫu, điền vào dữ liệu dự kiến ​​(3 năm) và kiểm tra tốc độ của một số truy vấn quan trọng cho hệ thống của bạn. Chú ý: tác động mạnh mẽ trên các điểm chuẩn đã sử dụng hw, tải trọng hiện tại, sw hiện tại.