Điểm của nhiều Cơ sở dữ liệu Redis là gì?

Question

Vì vậy, tôi đã đến một nơi mà tôi muốn phân đoạn dữ liệu mà tôi lưu trữ thành các cơ sở dữ liệu riêng biệt, đôi khi tôi cần sử dụng lệnh khóa trên một loại dữ liệu cụ thể và muốn tách nó ra nhanh hơn.

Nếu tôi phân đoạn thành nhiều cơ sở dữ liệu, mọi thứ vẫn là luồng đơn và tôi vẫn chỉ sử dụng một lõi. Nếu tôi mới khởi động một phiên bản Redis khác trên cùng một ô, tôi sẽ sử dụng thêm một lõi. Ngày đầu đó, tôi không thể đặt tên cho cơ sở dữ liệu Redis, hoặc cung cấp cho họ bất kỳ loại định danh hợp lý nào hơn. Vì vậy, với tất cả những gì đã nói, tại sao/khi nào tôi sẽ muốn sử dụng nhiều cơ sở dữ liệu Redis thay vì chỉ quay lên một trường hợp thêm của Redis cho mỗi cơ sở dữ liệu thêm tôi muốn? Và liên quan, tại sao Redis không cố gắng tận dụng thêm một lõi cho mỗi cơ sở dữ liệu bổ sung mà tôi thêm vào? Lợi thế của việc đơn luồng trên cơ sở dữ liệu là gì?

Answer 1

Về nguyên tắc, cơ sở dữ liệu Redis trên cùng một ví dụ không khác với schema trong cơ sở dữ liệu RDBMS trường hợp.

Như vậy, với tất cả những gì đã nói, tại sao/khi nào mà tôi từng muốn sử dụng nhiều Redis sở dữ liệu thay vì chỉ quay lên một ví dụ thêm Redis cho mỗi cơ sở dữ liệu phụ mà tôi muốn?

Có một lợi thế rõ ràng là sử dụng cơ sở dữ liệu redis trong cùng một trường hợp redis và đó là quản lý. Nếu bạn quay lên một cá thể riêng biệt cho mỗi ứng dụng, và giả sử bạn có 3 ứng dụng, đó là 3 trường hợp redis riêng biệt, mỗi trường hợp có thể cần một slave cho HA trong sản xuất, vì vậy đó là 6 trường hợp. Từ quan điểm quản lý, điều này nhanh chóng thực sự lộn xộn vì bạn cần theo dõi tất cả chúng, thực hiện nâng cấp/vá lỗi, v.v. Nếu bạn không có kế hoạch quá tải redis với I/O cao, một cá thể đơn với slave là đơn giản hơn và dễ quản lý hơn, miễn là nó đáp ứng SLA của bạn.

Answer 2

1. Tôi thực sự không biết bất kỳ lợi ích nào khi có nhiều cơ sở dữ liệu trên một cá thể. Tôi đoán nó hữu ích nếu nhiều dịch vụ sử dụng cùng một máy chủ cơ sở dữ liệu, vì vậy bạn có thể tránh va chạm chính.

2. Tôi sẽ không khuyên bạn nên xây dựng xung quanh bằng cách sử dụng lệnh KEYS, vì đó là O (n) và quy mô không tốt. Bạn đang sử dụng nó cho điều gì bạn có thể thực hiện theo cách khác? Có thể redis không phù hợp nhất với bạn nếu chức năng như KEYS là điều quan trọng.

3. Tôi nghĩ rằng họ đề cập đến lợi ích của một máy chủ luồng đơn trong Câu hỏi thường gặp của họ, nhưng điều chính là đơn giản - bạn không phải bận tâm đến sự đồng thời trong bất kỳ cách thực tế nào. Mọi hành động đều bị chặn, vì vậy không có hai thứ có thể thay đổi cơ sở dữ liệu cùng một lúc. Lý tưởng nhất là bạn sẽ có một (hoặc nhiều) trường hợp trên mỗi lõi của mỗi máy chủ và sử dụng thuật toán băm nhất quán (hoặc proxy) để chia các khóa trong số chúng. Tất nhiên, bạn sẽ mất một số chức năng - đường ống sẽ chỉ làm việc cho những thứ trên cùng một máy chủ, loại trở nên khó khăn hơn, vv

Answer 3

Bạn không muốn sử dụng nhiều cơ sở dữ liệu trong một trường hợp redis duy nhất. Nó không được chấp nhận và, như bạn đã lưu ý, nhiều phiên bản cho phép bạn tận dụng nhiều lõi. Nếu bạn sử dụng lựa chọn cơ sở dữ liệu, bạn sẽ phải cấu trúc lại khi nâng cấp. Giám sát và quản lý nhiều trường hợp không phải là khó khăn cũng không đau đớn.

Thật vậy, bạn sẽ nhận được các số liệu tốt hơn nhiều trên mỗi db bằng cách phân biệt dựa trên cá thể. Mỗi trường hợp sẽ có số liệu thống kê phản ánh phân đoạn dữ liệu đó, có thể cho phép điều chỉnh tốt hơn và theo dõi nhanh hơn và chính xác hơn. Sử dụng phiên bản gần đây và tách riêng dữ liệu của bạn.

Như Jonaton đã nói, không sử dụng lệnh phím. Bạn sẽ tìm thấy hiệu suất tốt hơn nhiều nếu bạn chỉ cần tạo một chỉ mục quan trọng. Bất cứ khi nào thêm một khóa, hãy thêm tên khóa vào một tập hợp. Các lệnh phím không phải là hữu ích khủng khiếp một khi bạn tăng quy mô vì nó sẽ mất thời gian đáng kể để trở lại.

Cho phép mẫu truy cập xác định cách cấu trúc dữ liệu của bạn thay vì lưu trữ dữ liệu theo cách bạn nghĩ và sau đó làm việc về cách truy cập và rút gọn sau này. Bạn sẽ thấy hiệu suất tốt hơn nhiều và tìm mã tiêu thụ dữ liệu thường là sạch hơn và đơn giản hơn nhiều.

Về đơn luồng, hãy xem xét redis được thiết kế cho tốc độ và nguyên tử. Các hành động sửa đổi dữ liệu trong một db không cần phải đợi trên một db khác, nhưng nếu hành động đó được lưu vào tệp kết xuất hoặc xử lý các giao dịch trên các nô lệ thì sao? Tại thời điểm đó bạn bắt đầu nhận được vào cỏ dại của lập trình đồng thời.

Bằng cách sử dụng nhiều phiên bản, bạn chuyển sự phức tạp của luồng đa thành một hệ thống kiểu truyền thông điệp đơn giản hơn.

Answer 4

Tôi đang sử dụng redis để triển khai danh sách đen địa chỉ email và tôi có các giá trị TTL khác nhau cho các cấp độ danh sách cấm khác nhau, vì vậy các DB khác nhau trên cùng một trường hợp giúp tôi rất nhiều.

Answer 5

Cơ sở dữ liệu Redis có thể được sử dụng trong các trường hợp hiếm hoi triển khai phiên bản mới của ứng dụng, trong đó phiên bản mới yêu cầu làm việc với các thực thể khác nhau.

Answer 6

Ngay cả Salvatore Sanfilippo (tác giả của Redis) nghĩ rằng đó là một ý tưởng tồi khi sử dụng nhiều DB trong Redis. Xem comment của mình ở đây:

https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion

tôi hiểu làm thế nào điều này có thể hữu ích, nhưng tiếc là tôi xem xét Redis lỗi nhiều cơ sở dữ liệu quyết định tồi tệ nhất của tôi trong thiết kế Redis tại tất cả ... mà không cần bất kỳ loại thực đạt được, nó làm cho các internals rất nhiều phức tạp hơn . Thực tế là các cơ sở dữ liệu không mở rộng tốt cho số lý do , như hết hạn các khóa và VM đang hoạt động. Nếu lựa chọn DB có thể được thực hiện bằng một chuỗi, tôi có thể thấy tính năng này là được sử dụng làm lớp từ điển có thể mở rộng O (1), thay vào đó là không.

Với số DB, với mặc định là một vài DB, chúng tôi đang liên lạc tốt hơn tính năng này là gì và tôi có thể sử dụng như thế nào. Tôi hy vọng rằng tại một số điểm chúng tôi có thể thả nhiều hỗ trợ DBs ở tất cả, nhưng tôi nghĩ rằng nó có lẽ là quá muộn vì có một số người dựa vào tính năng này cho công việc của họ.