Cách tốt nhất để quản lý khóa trong kho khóa-giá trị là gì?

Question

Cố gắng xác định một số chính sách cho các khóa trong kho khóa-giá trị (chúng tôi đang sử dụng Redis). Các keyspace nên là:

• Shardable (có thể giới thiệu nhiều máy chủ và lây lan ra các keyspace giữa chúng)

• namespaced (không nên có một số cơ chế để "nhóm" chìa khóa lại với nhau một cách hợp lý, ví dụ theo tên miền hoặc các khái niệm liên quan)

• Hiệu quả (cố gắng sử dụng ít nhất có thể trong không gian DB cho khóa, để cho phép nhiều một càng tốt)

• Như va chạm ít càng tốt (tránh phím cho hai đối tượng khác nhau để được bình đẳng)

Hai lựa chọn thay thế mà tôi đã coi là những:

1. Sử dụng các tiền tố cho không gian tên, được phân cách bằng một số ký tự (như human_resources:person:<some_id>). Mặt khác của điều này là nó khá dễ mở rộng và dễ hiểu. Nhược điểm sẽ là xung đột có thể tùy thuộc vào dấu phân cách (nếu id có ký tự : trong đó?), Và có thể hiệu quả kích thước (quá nhiều vùng tên lồng nhau có thể tạo khóa rất dài).

2. Sử dụng một số cấu trúc dữ liệu (như Đặt hàng hoặc Đặt hàng) để lưu trữ không gian tên. Nhược điểm chính của việc này là mất "tính dễ bị tổn thương", vì cấu trúc để lưu trữ các không gian tên sẽ cần phải nằm trong một cơ sở dữ liệu duy nhất.

Câu hỏi: Điều gì sẽ là một cách tốt để quản lý một keyspace trong một thiết lập sharded? Chúng ta có nên sử dụng một trong những lựa chọn thay thế này, hoặc có một số mô hình khác tốt hơn mà chúng ta chưa xem xét?

Cảm ơn rất nhiều!

Answer 1

Quy ước được chấp nhận chung trong thế giới Redis là tùy chọn 1 - tức là không gian tên được phân tách bằng ký tự như dấu hai chấm. Điều đó nói rằng, các không gian tên hầu như luôn luôn là một cấp độ sâu. Ví dụ: person:12321 thay vì human_resources:person:12321.

Tính năng này hoạt động như thế nào với 4 nguyên tắc bạn đã đặt?

Shardable - Cách tiếp cận này là không thể thực hiện được. Mỗi phím có thể đi vào một phân đoạn khác hoặc cùng một mảnh tùy thuộc vào cách bạn thiết lập nó.

Không gian tên Không gian tên như một cách để tránh va chạm hoạt động với phương pháp này. Tuy nhiên, không gian tên như một cách để nhóm các phím không hoạt động. Nói chung, sử dụng các phím như một cách để nhóm dữ liệu là một ý tưởng tồi. Ví dụ, nếu người di chuyển từ bộ phận này sang bộ phận khác thì sao? Nếu bạn thay đổi khóa, bạn sẽ phải cập nhật tất cả các tham chiếu - và điều đó trở nên phức tạp.

Cách tốt nhất để đảm bảo khóa không bao giờ thay đổi đối tượng.Việc nhóm có thể được xử lý bên ngoài bằng cách tạo một chỉ mục riêng biệt.

Ví dụ: giả sử bạn muốn nhóm mọi người theo bộ phận, theo phạm vi tiền lương, theo vị trí. Đây là cách bạn muốn làm điều đó -

1. người cá nhân đi vào băm riêng biệt với các phím persons:12321
2. Tạo một set cho mỗi nhóm bằng - Ví dụ: persons_by:department - và chỉ lưu trữ các định dạng số cho mỗi người trong này bộ. Ví dụ [12321, 43432]. Bằng cách này, bạn sẽ có được những lợi thế của Integer Set Redis'

hiệu quả Phương pháp này giải thích ở trên là bộ nhớ khá hiệu quả khôn ngoan. Để tiết kiệm thêm bộ nhớ, bạn có thể nén thêm các phím ở phía ứng dụng. Ví dụ: bạn có thể lưu trữ p:12321 thay vì persons:12321. Bạn nên làm điều này chỉ khi bạn đã xác định thông qua hồ sơ mà bạn cần tiết kiệm bộ nhớ như vậy. Nói chung, nó không đáng giá.

Va chạm miễn phí Điều này tùy thuộc vào đơn đăng ký của bạn. Mỗi Người dùng hoặc Người phải có khóa chính không bao giờ thay đổi. Sử dụng điều này trong khóa Redis của bạn, và bạn sẽ không có va chạm.

Bạn nói hai vấn đề với cách tiếp cận này, và tôi sẽ cố gắng giải quyết chúng

gì nếu id có dấu hai chấm?

Tất nhiên là có thể, nhưng thiết kế ứng dụng của bạn nên ngăn chặn nó. Tốt nhất là không cho phép các ký tự đặc biệt trong số nhận dạng - vì chúng sẽ được sử dụng trên nhiều hệ thống. Ví dụ: số nhận dạng rất có thể sẽ là một phần của URL và dấu hai chấm là ký tự dành riêng ngay cả đối với các url.

Nếu bạn thực sự phải cho phép các ký tự đặc biệt trong số nhận dạng của mình, bạn sẽ phải viết một trình bao bọc nhỏ trong mã của bạn mã hóa các ký tự đặc biệt. Mã hóa URL hoàn toàn có khả năng xử lý việc này.

Kích Hiệu quả

Có một chi phí để phím dài, tuy nhiên nó không phải là quá nhiều. Nói chung, bạn nên lo lắng về kích thước dữ liệu của các giá trị của bạn chứ không phải là các khóa. Nếu bạn nghĩ rằng khóa đang tiêu thụ quá nhiều bộ nhớ, hãy lập hồ sơ cơ sở dữ liệu bằng cách sử dụng một công cụ như redis-rdb-tools.

Nếu bạn xác định rằng kích thước khóa là vấn đề và muốn lưu bộ nhớ, bạn có thể viết một trình bao bọc nhỏ viết lại các khóa bằng bí danh.