Thực tiễn tốt nhất trong việc thiết kế mô hình dữ liệu Cassandra là gì?

Question

Và những cạm bẫy cần tránh là gì? Có thỏa thuận nào bị phá vỡ cho bạn không? Ví dụ: tôi đã nghe rằng việc xuất/nhập dữ liệu Cassandra rất khó, khiến tôi tự hỏi liệu điều đó có cản trở việc đồng bộ hóa dữ liệu sản xuất với môi trường phát triển hay không.

BTW, rất khó để tìm thấy các hướng dẫn tốt về Cassandra, người duy nhất tôi có http://arin.me/code/wtf-is-a-supercolumn-cassandra-data-model vẫn còn khá cơ bản.

Cảm ơn.

Answer 1

Đối với tôi, điều chính là quyết định có nên sử dụng OrderedPartitioner hoặc RandomPartitioner hay không.

Nếu bạn sử dụng RandomPartitioner, không thể quét phạm vi. Điều này có nghĩa là bạn phải biết khóa chính xác cho bất kỳ hoạt động nào, BAO GỒM Dọn dẹp DỮ LIỆU OLD. Vì vậy, nếu bạn đã có rất nhiều sự khuấy động, trừ khi bạn có một số cách kỳ diệu để biết chính xác chìa khóa bạn đã chèn công cụ, bằng cách sử dụng phân vùng ngẫu nhiên bạn có thể dễ dàng "mất" thứ, gây ra một không gian đĩa rò rỉ và cuối cùng sẽ tiêu thụ tất cả lưu trữ.

Mặt khác, bạn có thể hỏi trình phân vùng đã sắp xếp "Tôi có khóa nào trong Cột X gia đình giữa A và B"? - Và nó sẽ cho bạn biết. Sau đó bạn có thể làm sạch chúng.

Tuy nhiên, có một nhược điểm là tốt. Vì Cassandra không cân bằng tải tự động, nếu bạn sử dụng trình phân vùng có thứ tự, tất cả dữ liệu của bạn sẽ chỉ kết thúc bằng một hoặc hai nút và không có nút nào khác, nghĩa là bạn sẽ lãng phí tài nguyên.

Tôi không có câu trả lời dễ dàng cho điều này, ngoại trừ bạn có thể nhận được "tốt nhất của cả hai thế giới" trong một số trường hợp bằng cách đặt giá trị băm ngắn (một thứ bạn có thể liệt kê dễ dàng từ các nguồn dữ liệu khác) vào đầu các khóa của bạn - ví dụ: mã băm hex 16 bit của ID người dùng - sẽ cung cấp cho bạn 4 chữ số thập phân, theo sau là bất kỳ khóa nào bạn thực sự muốn sử dụng.

Sau đó, nếu bạn có danh sách người dùng bị xóa gần đây, bạn có thể chỉ cần băm ID và quét phạm vi để xóa mọi thứ liên quan đến chúng.

Bit khó tiếp theo là chỉ mục phụ - Cassandra không có bất kỳ - vì vậy nếu bạn cần tra cứu X theo Y, bạn cần chèn dữ liệu dưới cả hai khóa hoặc có con trỏ. Tương tự như vậy, các con trỏ này có thể cần phải được dọn dẹp khi điều chúng trỏ đến không tồn tại, nhưng không có cách dễ dàng để truy vấn các công cụ trên cơ sở này, vì vậy ứng dụng của bạn cần phải nhớ. Và các lỗi ứng dụng có thể để lại các phím mồ côi mà bạn đã quên, và bạn sẽ không có cách nào dễ dàng phát hiện chúng, trừ khi bạn viết một bộ thu gom rác định kỳ quét mọi khóa trong db (điều này sẽ xảy ra). phải mất một thời gian - nhưng bạn có thể làm điều đó theo từng phần) để kiểm tra những thứ không cần thiết nữa.

Không ai trong số này dựa trên việc sử dụng thực tế, chỉ là những gì tôi đã tìm ra trong quá trình nghiên cứu. Chúng tôi không sử dụng Cassandra trong sản xuất.

EDIT: Cassandra hiện có chỉ số phụ trong thân cây.

Answer 2

Một hướng dẫn khác là ở đây: http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/.

Answer 3

Có thỏa thuận nào vi phạm cho bạn không? Không nhất thiết phải đối phó ngắt nhưng một cái gì đó phải nhận thức được

1. Một khách hàng kết nối với một nút gần nhất, trong đó giải quyết nó nên biết trước, tất cả các thông tin liên lạc với tất cả Cassandra khác node proxy thông qua nó. a. lưu lượng đọc/ghi không được phân phối đồng đều giữa các nút - một số nút proxy có nhiều dữ liệu hơn so với lưu trữ b. Nếu nút đi xuống, khách hàng là bất lực, không thể đọc, không thể viết bất cứ nơi nào trong cụm.

2. Mặc dù Cassandra tuyên bố rằng "viết không bao giờ thất bại", nhưng họ thất bại, ít nhất là tại thời điểm họ nói. Nếu nút dữ liệu mục tiêu trở nên chậm chạp, yêu cầu thời gian ra ngoài và ghi không thành công. Có nhiều lý do cho một nút trở nên không phản hồi: thu gom rác trong, quá trình nén, bất cứ điều gì… Trong tất cả các trường hợp như vậy, tất cả yêu cầu ghi/đọc đều thất bại. Trong một cơ sở dữ liệu thông thường, các yêu cầu này sẽ trở nên tương đối chậm, nhưng trong Cassandra chúng chỉ thất bại.

3. Có đa-get nhưng không có đa xóa và người ta không thể cắt ngắn ColumnFamily hoặc

4. nên một, nút dữ liệu trống mới nhập cụm, phần dữ liệu từ một nút hàng xóm trên key-ring sẽ chỉ được chuyển. Điều này dẫn đến phân phối dữ liệu không đồng đều và tải không đồng đều. Bạn có thể sửa chữa nó bằng cách luôn luôn tăng gấp đôi số lượng nodes.One cũng nên theo dõi trên thẻ thủ công và chọn chúng một cách khôn ngoan.

Answer 4

Đây là quá dài để thêm như một bình luận, như vậy để làm sáng tỏ một số quan niệm sai lầm từ danh sách-of-vấn đề trả lời:

1. Bất kỳ khách hàng có thể kết nối với bất kỳ nút; nếu nút đầu tiên bạn chọn (hoặc bạn kết nối với thông qua bộ cân bằng tải) sẽ ngừng hoạt động, chỉ cần kết nối với nút khác. Ngoài ra, api "khách hàng chất béo" có sẵn nơi khách hàng có thể trực tiếp tự viết; một ví dụ là trên http://wiki.apache.org/cassandra/ClientExamples

2. Hết thời gian khi máy chủ không hồi đáp thay vì treo vô thời hạn là một tính năng mà hầu hết mọi người đã xử lý hệ thống rdbms quá tải đều mong muốn. Thời gian chờ Cassandra RPC được cấu hình; nếu bạn muốn, bạn có thể tự do đặt nó trong vài ngày và xử lý treo vô thời hạn thay thế. :)

3. Đúng là chưa có hỗ trợ đa điểm hoặc cắt bớt, nhưng có các bản vá cho cả hai đánh giá này. Rõ ràng là một sự cân bằng trong việc giữ cân bằng tải trên các nút cụm: sự cân bằng hoàn hảo hơn bạn cố gắng giữ mọi thứ, càng có nhiều chuyển động dữ liệu mà bạn sẽ thực hiện, điều đó không phải là miễn phí. Theo mặc định, các nút mới trong một cụm Cassandra sẽ di chuyển đến vị trí tối ưu trong vòng mã thông báo để giảm thiểu không đồng đều. Trong thực tế, điều này đã được chứng minh là hoạt động tốt, và cụm của bạn càng lớn, thì việc tăng gấp đôi là tối ưu. Này được bao phủ hơn trong http://wiki.apache.org/cassandra/Operations

Answer 5

Tôi nghĩ rằng đây xứng đáng một bản cập nhật kể từ khi Cassandra 1.2 ra mắt gần đây.

Tôi đã sử dụng Cassandra trong sản xuất trong 18 tháng qua cho các trò chơi xã hội.

Mặc dù tôi là bạn phải sử dụng Cassandra cho những điểm mạnh của nó.Vì vậy, một sự hiểu biết tốt về những gì và làm thế nào nó là nó cần thiết để xem mô hình dữ liệu để sử dụng hoặc thậm chí để xác định nếu một giải pháp DB là hữu ích hơn cho bạn.

OrderedPartitioner chỉ hữu ích nếu ứng dụng của bạn dựa vào các truy vấn phạm vi chính, NHƯNG bạn bỏ một trong những tính năng mạnh mẽ nhất của Cassandra cho điều đó: tự động sharding và cân bằng tải. Thay vì truy vấn phạm vi khóa hàng cố gắng triển khai cùng chức năng bạn cần bằng cách sử dụng phạm vi tên cột trong cùng một hàng. TL; DR đọc/ghi S W KHÔNG được cân bằng giữa các nút bằng cách sử dụng tính năng này.

RandomPartioner (md5 băm) và MurmurPartitioner (Murmur băm, tốt hơn và nhanh hơn) là cách bạn phải đi nếu bạn muốn hỗ trợ dữ liệu lớn và một tần số truy cập cao. Điều duy nhất bạn từ bỏ là các truy vấn phạm vi chính. Mọi thứ nằm trong cùng một hàng vẫn nằm trên cùng một nút trong cụm và bạn có thể sử dụng các truy vấn dãy so sánh và tên cột trên các cụm đó. TL; DR: SỬ DỤNG NÀY CHO CÂU HỎI THƯỜNG GẶP, bạn sẽ từ bỏ không có gì lớn.

---

điều bạn nên biết về cassandra:

Cassandra là cuối cùng nhất quán. Cassandra đã chọn để thương mại nhất quán cho tính sẵn sàng cao và phân vùng tuyệt vời (http://en.wikipedia.org/wiki/CAP_theorem). NHƯNG bạn có thể nhận được sự nhất quán từ cassandra, đó là tất cả về chính sách nhất quán của bạn khi bạn đọc và viết cho nó. Đây là một chủ đề khá quan trọng và phức tạp khi nói về việc sử dụng cassandra nhưng bạn có thể đọc chi tiết ở đây http://www.datastax.com/docs/1.2/dml/data_consistency.

Như một quy tắc chung (và để đơn giản) tôi đọc và viết tại QUORUM ConsistencyLevel (vì trong các ứng dụng của tôi đọc có xu hướng có cùng thứ tự tần suất như viết). Nếu ứng dụng của bạn là cực kỳ viết nặng và đọc xảy ra ít hơn rất nhiều sau đó sử dụng viết tại ONE và đọc tại TẤT CẢ. Hoặc nếu trường hợp sử dụng của bạn là ngược lại (viết ít thường xuyên hơn nhiều lần đọc) thì bạn có thể thử đọc trên ONE và viết trên TẤT CẢ. Sử dụng BẤT CỨ làm mức độ nhất quán để viết không phải là một ý tưởng tuyệt vời nếu tính nhất quán là những gì bạn đang cố gắng giải quyết, vì nó đảm bảo rằng đột biến đã đạt đến cụm nhưng không phải là nó đã được viết ở bất kỳ đâu. Đây là trường hợp duy nhất tôi ghi âm thầm vào cassandra.

Đó là những quy tắc đơn giản giúp bạn dễ dàng bắt đầu phát triển cassandra. Để có được sự nhất quán và hiệu suất nhất có thể từ một cụm sản xuất, bạn nên nghiên cứu chủ đề này một cách khó khăn và thực sự hiểu nó.

Nếu bạn cần một mô hình dữ liệu có thể đọc được con người với quan hệ phức tạp giữa các thực thể (bảng) thì tôi không nghĩ Cassandra là dành cho bạn. MySQL và có lẽ NewSQL có thể hữu ích hơn cho trường hợp sử dụng của bạn.

Điều tốt cần biết là cách, gần như, cassandra lưu và đọc dữ liệu. Bất cứ khi nào bạn viết (xóa thực sự là viết của một giá trị "tombstone" trong cassandra), hệ thống sẽ đặt giá trị mới và dấu thời gian của nó ở một vị trí vật lý mới.

Khi bạn đọc, cassandra cố gắng kéo tất cả ghi cho một vị trí khóa/cột nhất định và trả lại cho bạn gần đây nhất có thể tìm thấy (dấu có dấu thời gian cao nhất mà khách hàng đã cung cấp). Vì vậy, bộ nhớ cần thiết bởi một nút phụ thuộc trực tiếp vào tần số ghi. Có một quá trình nén chặt trong cassandra giúp chăm sóc làm sạch các đột biến cũ. Cassandra có một bộ nhớ đệm nội bộ được cập nhật trên lần đọc với giá trị mới nhất của vị trí.

Việc hợp nhất/nén chặt trên đĩa của SSTables (các cấu trúc dữ liệu lưu giữ dữ liệu) có thể bị kích động bởi các lần đọc, nhưng tốt hơn là không nên đếm nó. Việc làm sạch bia mộ và các cột hết hạn (sử dụng chức năng thời gian để sống) là một cơ chế khác được quản lý bởi bộ thu gom rác (xem cài đặt thời gian gia hạn GC để biết thêm chi tiết).

---

Điều này mang lại cho tôi điểm cuối cùng tôi muốn thực hiện: Đảm bảo rằng việc viết và đọc của bạn sẽ được cân bằng trên cụm của bạn!

Giả sử rằng tất cả người dùng của bạn cần phải cập nhật một vị trí duy nhất rất thường xuyên.
KHÔNG lập bản đồ vị trí đơn lý thuyết đó chỉ với một khóa hàng! Điều này sẽ làm cho tất cả các bài viết của bạn chỉ rơi vào một nút trong cụm của bạn. Nếu nó không mang lại mọi thứ xuống (bởi vì bạn có sysops rockstar) nó ít nhất sẽ làm tê liệt hiệu suất của cluster.
Lời khuyên của tôi là viết các bài viết của bạn vào đủ các khóa hàng khác nhau mà bạn sẽ phân phối các bài viết của bạn trên tất cả các nút trong cụm. Để lấy tất cả dữ liệu cho vị trí lý thuyết duy nhất đó, hãy sử dụng một multi_get trên tất cả các "khóa hàng phụ".

Ví dụ:
Tôi muốn có danh sách tất cả các phiên http đang hoạt động (có uuid được chỉ định cho họ). Không lưu tất cả vào một khóa hàng "phiên". Những gì tôi sử dụng như là một phím hàng cho cụm cassandra của tôi của 6 nút là: _sessions. Sau đó, tôi có một 16 phím nhỏ multi_get để lấy tất cả các phiên hoạt động, hoặc tôi vẫn có thể nói nếu một phiên hoạt động bằng cách sử dụng một đơn giản nhận được (nếu tôi biết uuid của khóa học). Nếu cụm của bạn lớn hơn rất nhiều, bạn có thể muốn sử dụng hàm băm cho các khóa nhóm tạo.