Khi nào KHÔNG sử dụng Cassandra?

Gần đây đã có rất nhiều cuộc nói chuyện liên quan đến Cassandra .

Twitter, Digg, Facebook, v.v ... đều sử dụng nó.

Khi nào nó có ý nghĩa với:

• sử dụng Cassandra,
• không sử dụng Cassandra và
• sử dụng RDMS thay vì Cassandra.

Không có gì giống như một viên đạn bạc, mọi thứ được xây dựng để giải quyết các vấn đề cụ thể và có những ưu và nhược điểm riêng. Tùy thuộc vào bạn, bạn có vấn đề gì và giải pháp phù hợp nhất cho vấn đề đó là gì.

Tôi sẽ cố gắng trả lời từng câu hỏi của bạn theo thứ tự bạn đã hỏi họ. Vì Cassandra dựa trên họ cơ sở dữ liệu NoQuery, điều quan trọng là bạn hiểu tại sao nên sử dụng cơ sở dữ liệu NoQuery trước khi tôi trả lời câu hỏi của bạn.

Tại sao nên sử dụng NoQuery

Trong trường hợp của RDBMS, việc đưa ra lựa chọn khá dễ dàng vì tất cả các cơ sở dữ liệu như MySQL, Oracle, MS SQL, PostgreQuery trong danh mục này cung cấp gần như cùng một loại giải pháp hướng đến các thuộc tính ACID. Khi nói đến NoQuery, quyết định trở nên khó khăn vì mỗi cơ sở dữ liệu NoQuery cung cấp các giải pháp khác nhau và bạn phải hiểu cái nào phù hợp nhất cho các yêu cầu ứng dụng / hệ thống của bạn. Ví dụ, MongoDB phù hợp cho các trường hợp sử dụng trong đó hệ thống của bạn yêu cầu lưu trữ tài liệu không có lược đồ. HBase có thể phù hợp với các công cụ tìm kiếm, phân tích dữ liệu nhật ký hoặc bất kỳ nơi nào mà việc quét các bảng không tham gia hai chiều rất lớn là một yêu cầu. Redis được xây dựng để cung cấp tìm kiếm trong bộ nhớ cho các loại cấu trúc dữ liệu như cây, hàng đợi, danh sách được liên kết, v.v. và có thể phù hợp để tạo bảng xếp hạng thời gian thực, loại hệ thống pub-sub. Tương tự, có các cơ sở dữ liệu khác trong danh mục này (Bao gồm cả Cassandra) phù hợp với các báo cáo vấn đề khác nhau. Bây giờ hãy chuyển sang các câu hỏi ban đầu và trả lời từng câu hỏi một.

Khi nào nên sử dụng Cassandra

Là một thành viên của gia đình NoQuery, Cassandra cung cấp giải pháp cho các vấn đề trong đó một trong những yêu cầu của bạn là có một hệ thống ghi rất nặng và bạn muốn có một hệ thống báo cáo khá phản hồi trên dữ liệu được lưu trữ đó. Xem xét trường hợp sử dụng phân tích Web nơi lưu trữ dữ liệu nhật ký cho từng yêu cầu và bạn muốn xây dựng một nền tảng phân tích xung quanh nó để đếm số lần truy cập mỗi giờ, theo trình duyệt, theo IP, v.v. theo cách thức thời gian thực. Bạn có thể tham khảo điều này bài đăng trên blog để hiểu thêm về các trường hợp sử dụng mà Cassandra phù hợp.

Khi nào nên sử dụng RDMS thay vì Cassandra

Cassandra dựa trên cơ sở dữ liệu NoQuery và không cung cấp ACID và các thuộc tính dữ liệu quan hệ. Nếu bạn có yêu cầu cao đối với các thuộc tính ACID (ví dụ: Dữ liệu tài chính), Cassandra sẽ không phù hợp trong trường hợp đó. Rõ ràng, bạn có thể giải quyết vấn đề đó, tuy nhiên cuối cùng bạn sẽ viết rất nhiều mã ứng dụng để mô phỏng các thuộc tính ACID và sẽ mất thời gian để tiếp thị xấu. Ngoài ra việc quản lý loại hệ thống đó với Cassandra sẽ rất phức tạp và tẻ nhạt đối với bạn.

Khi nào không sử dụng Cassandra

Tôi không nghĩ rằng nó cần phải được trả lời nếu lời giải thích trên có ý nghĩa.

Khi đánh giá các hệ thống dữ liệu phân tán, bạn phải xem xét định lý CAP - bạn có thể chọn hai trong số các yếu tố sau: tính nhất quán, tính sẵn có và dung sai phân vùng.

Cassandra là một hệ thống có khả năng chịu phân vùng có sẵn, hỗ trợ tính nhất quán cuối cùng. Để biết thêm thông tin, xem bài đăng trên blog này tôi đã viết: Hướng dẫn trực quan về hệ thống NoQuery .

Cassandra là câu trả lời cho một vấn đề cụ thể: Bạn làm gì khi bạn có quá nhiều dữ liệu không phù hợp trên một máy chủ? Làm thế nào để bạn lưu trữ tất cả dữ liệu của bạn trên nhiều máy chủ và không phá vỡ tài khoản ngân hàng của bạn và không làm cho các nhà phát triển của bạn mất trí? Facebook nhận được 4 Terabyte dữ liệu nén mới MERYI NGÀY. Và con số này rất có thể sẽ tăng hơn hai lần trong vòng một năm.

Nếu bạn không có nhiều dữ liệu này hoặc nếu bạn có hàng triệu đồng để trả cho cài đặt cụm Oracle / DB2 dành cho doanh nghiệp và các chuyên gia cần thiết để thiết lập và duy trì nó, thì bạn vẫn ổn với cơ sở dữ liệu SQL.

Tuy nhiên, Facebook không còn sử dụng cassandra và giờ đây, MySQL gần như chỉ chuyển phân vùng lên trong ngăn xếp ứng dụng để có hiệu suất nhanh hơn và kiểm soát tốt hơn.

Ý tưởng chung của NoQuery là bạn nên sử dụng bất kỳ kho lưu trữ dữ liệu nào phù hợp nhất cho ứng dụng của bạn. Nếu bạn có một bảng dữ liệu tài chính, hãy sử dụng SQL. Nếu bạn có các đối tượng sẽ yêu cầu các truy vấn phức tạp / chậm để ánh xạ tới một lược đồ quan hệ, hãy sử dụng một đối tượng hoặc kho lưu trữ khóa / giá trị.

Tất nhiên chỉ là về bất kỳ vấn đề nào trong thế giới thực mà bạn gặp phải là một nơi nào đó ở giữa hai thái cực đó và không có giải pháp nào là hoàn hảo. Bạn cần xem xét khả năng của từng cửa hàng và hậu quả của việc sử dụng hết cửa hàng này, điều này sẽ rất cụ thể đối với vấn đề bạn đang cố gắng giải quyết.

Bên cạnh những câu trả lời được đưa ra ở trên về khi nào nên sử dụng và khi nào không sử dụng Cassandra, nếu bạn quyết định sử dụng Cassandra, bạn có thể muốn xem xét việc không sử dụng chính Cassandra, nhưng là một trong nhiều anh em họ của nó.

Một số câu trả lời ở trên đã chỉ ra các hệ thống "NoQuery" khác nhau có chung nhiều thuộc tính với Cassandra, với một số khác biệt nhỏ hoặc lớn và có thể tốt hơn chính Cassandra cho các nhu cầu cụ thể của bạn.

Ngoài ra, gần đây (vài năm sau khi câu hỏi này ban đầu được hỏi), một bản sao Cassandra có tên Scylla (xem https://en.wikipedia.org/wiki/Scylla_(database) ) đã được phát hành. Scylla là một triển khai lại Cassandra trong mã nguồn mở trong C ++, tuyên bố có thông lượng cao hơn và độ trễ thấp hơn đáng kể so với Java Cassandra ban đầu, trong khi hầu hết tương thích với nó (về tính năng, API và định dạng tệp). Vì vậy, nếu bạn đang xem xét Cassandra, bạn cũng có thể muốn xem xét Scylla.

Nói chuyện với ai đó khi đang triển khai Cassandra, nó không xử lý tốt nhiều-nhiều. Họ đang làm một công việc hack để làm thử nghiệm ban đầu của họ. Tôi đã nói chuyện với một chuyên gia tư vấn của Cassandra về vấn đề này và anh ta nói rằng anh ta sẽ không đề xuất nếu bạn gặp vấn đề này.

Bạn nên tự hỏi mình những câu hỏi sau:

1. (Âm lượng, Vận tốc) Bạn sẽ viết và đọc TẤN thông tin, rất nhiều thông tin mà không một máy tính nào có thể xử lý việc ghi.
2. (Toàn cầu) Bạn sẽ cần khả năng viết và đọc này trên toàn thế giới để việc viết ở một nơi trên thế giới có thể truy cập được ở một nơi khác trên thế giới?
3. (Độ tin cậy) Bạn có cần cơ sở dữ liệu này luôn hoạt động và không bao giờ ngừng hoạt động bất kể Cloud, quốc gia nào, cho dù đó là VM, Container hay Bare metal?
4. (Khả năng chia tỷ lệ) Bạn có cần cơ sở dữ liệu này để có thể tiếp tục phát triển dễ dàng và mở rộng quy mô tuyến tính không
5. (Tính nhất quán) Bạn có cần tính nhất quán TUNABLE trong đó một số ghi có thể xảy ra không đồng bộ khi những người khác cần được chứng nhận không?
6. (Kỹ năng) Bạn có sẵn sàng làm những gì cần thiết để học công nghệ này và mô hình hóa dữ liệu đi kèm với việc tạo cơ sở dữ liệu phân tán toàn cầu có thể nhanh chóng cho mọi người, ở mọi nơi không?

Nếu đối với bất kỳ câu hỏi nào bạn nghĩ "có thể" hoặc "không", bạn nên sử dụng một cái gì đó khác. Nếu bạn có "hell yes" như một câu trả lời cho tất cả chúng, thì bạn nên sử dụng Cassandra.

Sử dụng RDBMS khi bạn có thể làm mọi thứ trên một hộp. Nó có thể dễ dàng hơn hầu hết và bất cứ ai cũng có thể làm việc với nó.

Truy vấn đơn nặng so với tải truy vấn ánh sáng gazillion là một điểm khác cần xem xét, ngoài các câu trả lời khác ở đây. Thật khó để tự động tối ưu hóa một truy vấn trong DB kiểu NoSql. Tôi đã sử dụng MongoDB và gặp vấn đề về hiệu năng khi cố gắng tính toán một truy vấn phức tạp. Tôi đã không sử dụng Cassandra nhưng tôi hy vọng nó có cùng một vấn đề.

Mặt khác, nếu tải của bạn được dự kiến ​​là rất nhiều truy vấn nhỏ và bạn muốn có thể dễ dàng mở rộng quy mô, bạn có thể tận dụng tính nhất quán cuối cùng được cung cấp bởi hầu hết các DB NoSql. Lưu ý rằng tính nhất quán cuối cùng không thực sự là một tính năng của mô hình dữ liệu không liên quan, nhưng việc thực hiện và thiết lập trong hệ thống dựa trên NoSql sẽ dễ dàng hơn nhiều.

Đối với một truy vấn đơn, rất nặng, bất kỳ công cụ RDBMS hiện đại nào cũng có thể thực hiện công việc song song các phần của truy vấn và tận dụng tối đa CPU và bộ nhớ mà bạn ném vào nó (trên một máy). Cơ sở dữ liệu NoSql không có đủ thông tin về cấu trúc dữ liệu để có thể đưa ra các giả định cho phép thực hiện song song thông minh thực sự một truy vấn lớn. Chúng cho phép bạn dễ dàng mở rộng thêm nhiều máy chủ (hoặc lõi) nhưng một khi truy vấn đạt đến mức độ phức tạp, về cơ bản bạn buộc phải phân tách nó theo cách thủ công thành các phần mà công cụ NoSql biết cách xử lý thông minh.

Theo kinh nghiệm của tôi với MongoDB, cuối cùng vì sự phức tạp của truy vấn, Mongo không thể làm gì nhiều để tối ưu hóa nó và chạy các phần của nó trên nhiều dữ liệu. Mongo song song nhiều truy vấn nhưng không tốt lắm trong việc tối ưu hóa một truy vấn duy nhất.

Chúng ta hãy đọc một số trường hợp thực tế:

http://planetcassandra.org/apache-cassandra-use-case/

Trong bài viết này: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

Họ đã giải thích lý do tại sao họ không chọn MySql là vì quá trình đồng bộ hóa db quá chậm.

(Cũng do cam kết 2 cụm từ, FK, PK)

Cassandra dựa trên giấy Amazon Dynamo

Đặc trưng:

Ổn định

Tính sẵn sàng cao

Sao lưu hoạt động tốt

Đọc và viết tốt hơn HBase, (bản sao BigTable trong java).

wiki http://en.wikipedia.org/wiki/Apache_Cassandra

Kết luận của họ là:

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

Tính đến năm 2018,

Tôi sẽ khuyên bạn nên sử dụng ScyllaDB để thay thế cassandra cổ điển, nếu bạn cần hỗ trợ trở lại.

Plugin kv Postgres cũng nhanh hơn cassandra. Làm thế nào sẽ không có khả năng mở rộng đa trường hợp.

Tôi sẽ tập trung ở đây vào một số khía cạnh quan trọng có thể giúp bạn quyết định xem bạn có thực sự cần Cassandra hay không. Danh sách này không đầy đủ, chỉ là một số điểm mà tôi có trong đầu

• Đừng coi Cassandra là lựa chọn đầu tiên khi bạn có yêu cầu nghiêm ngặt về mối quan hệ (trên toàn bộ dữ liệu của bạn).

• Cassandra theo mặc định là hệ thống AP (của CAP). Nhưng, nó hỗ trợ tính nhất quán có thể điều chỉnh được, có nghĩa là nó cũng có thể được cấu hình để hỗ trợ như CP. Vì vậy, đừng bỏ qua nó chỉ vì bạn đọc ở đâu đó rằng đó là AP và bạn đang tìm kiếm các hệ thống CP. Cassandra được gọi chính xác hơn là phù hợp với điều chỉnh, có nghĩa là nó cho phép bạn dễ dàng quyết định mức độ nhất quán mà bạn yêu cầu, cân bằng với mức độ sẵn có.

• Đừng sử dụng Cassandra nếu quy mô của bạn không nhiều hoặc nếu bạn có thể đối phó với DB không được phân phối.

• Hãy suy nghĩ kỹ hơn nếu nhóm của bạn nghĩ rằng tất cả các vấn đề của bạn sẽ được giải quyết nếu bạn sử dụng các DB phân tán như Cassandra. Để bắt đầu với các DB này rất đơn giản vì nó có nhiều mặc định nhưng tối ưu hóa và thành thạo nó để giải quyết một vấn đề cụ thể sẽ đòi hỏi một nỗ lực kỹ thuật tốt (nếu không phải là rất nhiều).

• Cassandra được định hướng theo cột nhưng đồng thời mỗi hàng cũng có một khóa duy nhất. Vì vậy, có thể hữu ích khi nghĩ về nó như một cửa hàng được định hướng theo hàng. Bạn thậm chí có thể sử dụng nó như một cửa hàng tài liệu.

• Cassandra không buộc bạn phải xác định trước các trường. Vì vậy, nếu bạn đang ở chế độ khởi động hoặc các tính năng của bạn đang phát triển (như nhanh nhẹn) - Cassandra nắm lấy nó. Vì vậy, tốt hơn, đầu tiên hãy nghĩ về các truy vấn và sau đó nghĩ về dữ liệu để trả lời chúng.

• Cassandra được tối ưu hóa cho thông lượng thực sự cao khi viết. Nếu trường hợp sử dụng của bạn nặng về đọc (như bộ đệm) thì Cassandra có thể không phải là một lựa chọn lý tưởng.

Một tình huống khác giúp lựa chọn dễ dàng hơn là khi bạn muốn sử dụng hàm tổng hợp như sum, min, max, etcetera và các truy vấn phức tạp (như trong hệ thống tài chính được đề cập ở trên) thì cơ sở dữ liệu quan hệ có thể thuận tiện hơn cơ sở dữ liệu nosql vì cả hai không thể có trên một cơ sở dữ liệu nosql trừ khi bạn thực sự sử dụng rất nhiều chỉ mục Đảo ngược. Khi bạn sử dụng nosql, bạn sẽ phải thực hiện các hàm tổng hợp trong mã hoặc lưu trữ chúng một cách riêng biệt trong cột của chính nó nhưng điều này làm cho nó khá phức tạp và làm giảm hiệu suất mà bạn đạt được bằng cách sử dụng nosql.

Nếu bạn cần một cơ sở dữ liệu hoàn toàn phù hợp với ngữ nghĩa SQL, Cassandra KHÔNG phải là giải pháp cho bạn. Cassandra hỗ trợ tra cứu khóa-giá trị. Nó không hỗ trợ các truy vấn SQL. Dữ liệu trong Cassandra là "cuối cùng phù hợp". Tra cứu dữ liệu đồng thời có thể không nhất quán, nhưng cuối cùng tra cứu là nhất quán.

Nếu bạn cần ngữ nghĩa nghiêm ngặt và cần hỗ trợ cho các truy vấn SQL, hãy chọn một giải pháp khác như MySQL, PostGres hoặc kết hợp sử dụng Cassandra với Solr.

Cassandra là một lựa chọn tốt nếu:

1. Bạn không yêu cầu các thuộc tính ACID từ DB của bạn.

2. Sẽ có số lượng lớn và rất lớn các bài viết trên DB.

3. Có một yêu cầu để tích hợp với Dữ liệu lớn, Hadoop, Hive và Spark.

4. Cần có sự phân tích dữ liệu và thế hệ báo cáo theo thời gian thực.

5. Có một yêu cầu của cơ chế chịu lỗi ấn tượng.

6. Có một yêu cầu của hệ thống đồng nhất.

7. Có một yêu cầu của rất nhiều tùy chỉnh để điều chỉnh.

Mongodb có các hàm tổng hợp rất mạnh và khung tổng hợp biểu cảm. Nó có nhiều tính năng mà các nhà phát triển đã quen với việc sử dụng từ thế giới cơ sở dữ liệu quan hệ. Đó là cấu trúc dữ liệu / lưu trữ tài liệu cho phép các mô hình dữ liệu phức tạp hơn Cassandra chẳng hạn.

Tất cả điều này đi kèm với sự đánh đổi tất nhiên. Vì vậy, khi bạn chọn cơ sở dữ liệu của mình (NoQuery, NewQuery hoặc RDBMS) hãy xem xét vấn đề nào bạn đang cố gắng giải quyết và theo nhu cầu về khả năng mở rộng của bạn. Không một cơ sở dữ liệu nào làm tất cả.

Theo DataStax, Cassandra không phải là trường hợp sử dụng tốt nhất khi có nhu cầu

1- Thiết bị phần cứng cao cấp. 2- Tuân thủ ACID không quay lại (giao dịch ngân hàng)

• Nó không hỗ trợ quản lý giao dịch hoàn chỉnh trên các bảng.
• Chỉ số phụ không được hỗ trợ.
• Phải dựa vào Tìm kiếm đàn hồi / Solr cho chỉ mục phụ và thành phần đồng bộ hóa tùy chỉnh phải được viết.
• Không phải hệ thống tuân thủ ACID.
• Hỗ trợ truy vấn bị hạn chế.

Apache cassandra là một cơ sở dữ liệu phân tán để quản lý một lượng lớn dữ liệu có cấu trúc trên nhiều máy chủ hàng hóa, trong khi cung cấp dịch vụ có tính sẵn sàng cao và không có điểm thất bại duy nhất.

Kiến trúc hoàn toàn dựa trên định lý nắp, tính khả dụng và dung sai phân vùng, và cuối cùng thú vị nhất quán.

Không sử dụng nó, nếu bạn không lưu trữ khối lượng dữ liệu trên các cụm, đừng sử dụng nếu bạn không lưu trữ dữ liệu chuỗi thời gian, Đừng sử dụng nếu bạn không bảo vệ máy chủ của mình, Đừng sử dụng nếu bạn yêu cầu tính nhất quán cao.