JSONB với lập chỉ mục so với hstore

Tôi đang cố gắng quyết định thiết kế cơ sở dữ liệu, với càng ít giả định (liên quan đến cách ứng dụng web thực sự phát triển) càng tốt ở giai đoạn này.

Bước đầu tiên, hiểu rằng THAM GIA rất tốn kém, tôi đang xem xét một số lượng nhỏ các bảng nguyên khối trái ngược với một số lượng lớn các bảng nhỏ hơn được chuẩn hóa. Như một điểm thứ hai, tôi nhầm lẫn giữa việc sử dụng hstore so với các bảng thông thường so với JSONB (với lập chỉ mục GiST).

AFAIK (xin vui lòng sửa):

1. Nói chung, trong Postgres, hstore được biết là hoạt động tốt hơn các loại dữ liệu khác. Bài thuyết trình này từ FOSDEM PGDAY có một số thống kê thú vị (trong nửa sau của các slide). https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf

2. Một lợi thế với hstore là lập chỉ mục nhanh (GiN hoặc GiST). Tuy nhiên, với JSONB, lập chỉ mục GiN và GiST cũng có thể được áp dụng cho dữ liệu JSON.

3. Blog này từ một chuyên gia tại 2nd Quadrant cho biết "Tại thời điểm này, có lẽ nên thay thế việc sử dụng hstore bằng jsonb trong tất cả các ứng dụng mới" (cuộn đến cuối): http://blog.2ndquadrant.com/postgresql-anti-potypes-unn cần thiết -jsonhstore-Dynamic-cột /

Vì vậy, tôi muốn quyết định như sau:

1. Đối với phần chính (có cấu trúc) của dữ liệu: nó có nên đi vào một vài bảng quan hệ (tương đối lớn với nhiều cột) hay nên là một số cửa hàng khóa-giá trị sử dụng hstore?
2. Đối với dữ liệu ad hoc (do người dùng đóng góp / không có cấu trúc), dữ liệu đó có phải trong kho lưu trữ giá trị khóa JSON hoặc ad hoc trong hstore (với các khóa được lưu trữ trong một trong các bảng quan hệ chính) không?

Cơ sở dữ liệu quan hệ được thiết kế xung quanh các phép nối và được tối ưu hóa để thực hiện chúng tốt.

Trừ khi bạn có lý do chính đáng để không sử dụng thiết kế chuẩn hóa, hãy sử dụng thiết kế chuẩn hóa.

jsonbvà những thứ như hstorelà tốt khi bạn không thể sử dụng mô hình dữ liệu được chuẩn hóa, chẳng hạn như khi mô hình dữ liệu thay đổi nhanh chóng và được người dùng xác định.

Nếu bạn có thể mô hình hóa nó một cách tương đối, mô hình hóa nó một cách tương đối. Nếu bạn không thể, hãy xem xét json, v.v ... Nếu bạn chọn giữa json / jsonb / hstore, thường chọn jsonb trừ khi bạn có lý do để không.

Đó là những gì tôi đã nói trong bài viết trên blog của mình , chỉ đề cập đến chủ đề này. Xin vui lòng đọc toàn bộ bài . Đoạn bạn trích dẫn chỉ ra rằng nếu bạn chọn cấu trúc động, bạn nên chọn jsonb trên hstore, nhưng phần còn lại của bài đăng trên blog là về lý do tại sao bạn thường thích mô hình hóa một cách tương đối nếu bạn có thể.

Vì thế. Mô hình phần cấu trúc chính liên quan. Nếu các bảng thực sự rộng với nhiều cột, đây có thể là dấu hiệu cần phải chuẩn hóa thêm. Đừng sợ tham gia. Học cách yêu tham gia. Tham gia nhiều bảng nhỏ thường sẽ nhanh hơn truy vấn và duy trì các bảng không chuẩn hóa lớn. Chỉ chuẩn hóa nếu bạn cần cho các trường hợp cụ thể và tốt nhất là thông qua các quan điểm cụ thể hóa ... nhưng đừng làm điều đó cho đến khi bạn biết bạn cần và có một vấn đề cụ thể thực tế để giải quyết.

Đối với dữ liệu do người dùng đóng góp là dạng tự do và không có cấu trúc, hãy sử dụng jsonb. Nó sẽ hoạt động tốt như hstore, nhưng nó linh hoạt hơn và dễ làm việc hơn.

Một điều có liên quan để hiểu: Gist và GIN các chỉ mục như sử dụng trên jsonb nói chung là nhiều ít hiệu quả hơn so với một chỉ số b-tree đồng bằng. Chúng linh hoạt hơn, nhưng chỉ số b-cây trên một cột bình thường sẽ hầu như luôn luôn nhanh hơn nhiều.