Việc sử dụng địa chỉ IP làm khóa chính có phải là một cách thực hành tốt trong scylla db không?


8

Tôi đang sử dụng scylla db và có một bảng sử dụng địa chỉ IP làm khóa chính. RF cho cụm là 3. Tôi thấy một số nút có tải nhiều hơn (chiếm nhiều dung lượng đĩa hơn) so với các nút khác ngay cả khi ownschỉ số gần (31% ~ 35%)

Tôi tự hỏi là bởi vì tôi đang sử dụng địa chỉ IP làm khóa chính và một số địa chỉ IP nóng hơn các địa chỉ khác (như cập nhật nhiều hơn về các IP đó)?


1
Cân nhắc sử dụng toppartitions để xem ai là diễn viên nghịch ngợm nhất.
Peter Corless

Câu trả lời:


2

Thực tế là một số địa chỉ IP nóng hơn - nhận được nhiều lượt đọc hoặc ghi hơn so với các địa chỉ khác - thường không phải là vấn đề lớn và là điều khá bình thường. Scylla sẽ phân chia chúng ngẫu nhiên giữa các nút khác nhau (và lõi trên mỗi nút) và miễn là bạn có nhiều phân vùng nóng hơn đáng kể so với các lõi trong cụm của bạn, tải - và mức sử dụng đĩa - sẽ khá cân bằng.

Mọi thứ có thể trở nên khác nhau trong các trường hợp cực đoan, chẳng hạn như khi mỗi bản cập nhật phát triển một phân vùng (nghĩa là thêm một hàng vào đó) và chỉ một vài phân vùng cực kỳ nóng. Ví dụ: bạn có thể tưởng tượng một cơ sở dữ liệu được sử dụng để ghi nhật ký yêu cầu và ngoài một triệu khách hàng bình thường với 10 yêu cầu mỗi ngày, nó cũng có 10 "kẻ tấn công" thực hiện một triệu yêu cầu mỗi ngày. Trong những trường hợp cực đoan như vậy, bạn có thể thấy mình có một số nút mang tải không gian và / hoặc không gian đĩa nhiều hơn đáng kể so với các nút khác. Các trường hợp cực đoan như vậy cũng có thể gây ra các vấn đề khác: Mặc dù sự hỗ trợ của Scylla cho các phân vùng lớn đã được cải thiện gần đây, nhưng nó vẫn không hoàn hảo, và nếu bạn có thể tránh các trường hợp cực đoan như vậy, thì tốt hơn.

Cuối cùng, nếu tôi quay lại câu hỏi ban đầu của bạn, "Việc sử dụng địa chỉ IP làm khóa chính có phải là một cách thực hành tốt trong scylla db không?", Câu trả lời là "có, nhưng":

Đó là "có" vì Scylla không có vấn đề cụ thể với địa chỉ IP làm khóa - nó phân phối địa chỉ IP khác nhau cho các nút khác nhau một cách ngẫu nhiên (sử dụng hàm băm "murmur3") nên không có vấn đề cụ thể nào về việc địa chỉ IP bị vón cục cùng nhau (ví dụ: nhiều máy khách từ cùng một mạng con không được gửi đến cùng một nút cụm).

Đó là "nhưng" bởi vì vấn đề không phải là địa chỉ IP dưới dạng khóa, mà là nội dung của phân vùng bạn dự định lưu trữ và tần suất cập nhật - và kích thước - cho các phân vùng khác nhau.

Ồ, và một lưu ý cuối cùng:

Nếu bạn đang sử dụng Chiến lược nén cấp bậc (STCS), mức sử dụng không gian đĩa tối đa tại bất kỳ thời điểm cụ thể nào có thể khá cao hơn lượng dữ liệu thực tế được lưu trữ. Nếu khối lượng công việc của bạn quá nhiều ghi đè (dữ liệu không được thêm vào, nhưng thay vào đó, bị xóa, v.v.), trước khi quá trình nén hoàn thành công việc, dữ liệu trên đĩa rất có thể gấp đôi lượng dữ liệu thực. Nếu đây là trường hợp, nếu bạn kiểm tra hệ thống tại một thời điểm ngẫu nhiên, bạn sẽlưu ý rằng một số nút có nhiều dữ liệu trên đĩa hơn các nút khác, tùy thuộc vào vị trí ngẫu nhiên của chúng trong công việc nén khi bạn thực hiện phép đo này. Một cái gì đó bạn có thể làm để xác minh xem đây có phải là thứ bạn đang thấy là để gọi "nén chính" trên tất cả các nút và đo mức sử dụng đĩa sau đó - hy vọng sẽ thấy mức sử dụng không gian đĩa đồng đều hơn nhiều trên các nút.


5

Bạn có thể đúng, tốt hơn nên thêm một lĩnh vực khác để truyền bá dữ liệu tốt hơn


3

Việc sử dụng địa chỉ IP làm khóa chính có phải là một cách thực hành tốt trong scylla db không?

Trả lời câu hỏi của bạn một mình, giả sử địa chỉ IP được phân phối đồng đều và các mẫu truy cập của bạn được phân phối đồng đều, điều đó hoàn toàn tốt cho bất kỳ cơ sở dữ liệu nào có bảo vệ dữ liệu. Trong rất nhiều trường hợp khi bản phân phối của bạn không đồng đều, nó cũng sẽ ổn. ví dụ: mẫu truy cập của bạn chạm vào một số IP nhiều hơn các IP khác.

Tùy thuộc vào chiến lược bảo vệ cơ sở dữ liệu, nó tạo ra sự khác biệt nếu bạn sử dụng các giá trị tăng đơn điệu (ví dụ: IP tuần tự) (MongoDB, Spanner, DataStore, v.v.). Nhưng trong trường hợp của ScyllaDB, Scylla băm từng khóa Phân vùng bằng MurMurHash3 theo mặc định để bạn có thể cho rằng việc nhập dữ liệu của bạn được phân phối đồng đều trên vòng mã thông báo.

Dù sao, nếu bạn cần đọc / ghi bằng Key == IP, bạn không có nhiều sự lựa chọn. Nó có thể phụ thuộc vào chi tiết cụ thể của nhiệm vụ của bạn mặc dù.

tìm một số nút có cách tải nhiều hơn (chiếm nhiều dung lượng đĩa hơn) so với các nút khác ngay cả khi chỉ số sở hữu gần (31% ~ 35%)

Tải thường đo thông lượng là IOPS trên đĩa hoặc Yêu cầu ứng dụng / giây hoặc sử dụng theo%. Nếu bạn xem xét việc sử dụng không gian đĩa thì đó là một câu chuyện hoàn toàn khác.

Nếu bạn có nghĩa là sử dụng các nút thông lượng tương đối thì nó có thể là:

  • phân phối dữ liệu của bạn
  • phân phối tải của bạn (truy cập) trong không gian phím, mối quan hệ của việc đọc và tự viết
  • phân phối các mã thông báo nút, có thể cung cấp% phương sai một mình

Nếu bạn có nghĩa là không gian đĩa, ngoài những gì tôi đã đề cập, còn có rất nhiều yếu tố khác:

  • gợi ý
  • trường hợp chưa sửa chữa, lịch trình sửa chữa
  • bia mộ, gc, tính toán

Tôi tự hỏi là bởi vì tôi đang sử dụng địa chỉ IP làm khóa chính

Không.

và một số địa chỉ IP nóng hơn các địa chỉ khác (như cập nhật nhiều hơn về các IP đó)?

Nó phụ thuộc vào các yếu tố được đề cập ở trên và ý nghĩa của tải trọng. Nếu bạn có nghĩa là không gian đĩa, truy cập đọc của bạn không ảnh hưởng đến nó. Viết có thể.


-1

Có địa chỉ IP là khóa chính là một thực tế xấu vì những lý do này.

  1. Địa chỉ IP có thể thay đổi. nếu điều đó xảy ra tôi không chắc làm thế nào bạn có thể truy vấn bằng địa chỉ IP cũ.
  2. Nếu bạn đã dành riêng địa chỉ IP (tĩnh và không thay đổi), thì, nếu bạn nhận được nhiều yêu cầu hơn từ một vài IP thì bạn không tạo các nút phân bổ đều.
  3. Thêm một lĩnh vực khác có thể làm cho mọi thứ tốt hơn tuy nhiên, tôi không thể đề xuất nó trừ khi tôi biết mẫu truy cập.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.