Elasticsearch vs Cassandra vs Elasticsearch với Cassandra


110

Tôi đang học NoSQL và xem xét các tùy chọn khác nhau cho một trong các yêu cầu của khách hàng của tôi. Tôi đã xem qua nhiều nguồn khác nhau trước khi đưa ra câu hỏi này (một người có ít kiến ​​thức về NoSQL)

  • Tôi cần lưu trữ dữ liệu với tốc độ nhanh hơn và đọc dữ liệu.
  • Hoàn toàn không an toàn và có thể mở rộng dễ dàng.
  • Có thể tìm kiếm thông qua dữ liệu cho Analytics.

Tôi đã kết thúc với một danh sách ngắn gồm: Cassandra and Elasticsearch

Những gì tôi hiểu là Cassandra là một giải pháp lưu trữ NoSQL hoàn hảo cho tôi, vì tôi có thể ghi dữ liệu và đọc dữ liệu bằng cách sử dụng các chỉ mục. Nơi nó không thành công hoặc nó có thể không thành công là trên Analytics. Trong tương lai, nếu tôi muốn lấy dữ liệu từ from_date to to_datehoặc nhiều cách khác để lấy dữ liệu cho phân tích, nếu tôi không thiết kế mô hình Dữ liệu đúng cách hoặc giữ tầm nhìn lâu dài, điều này có thể khá khó khăn trong thế giới luôn thay đổi.

Trong khi Elastic Searchlập chỉ mục tốt nhất (được hỗ trợ bởi Lucene) và có thể tìm kiếm dữ liệu một cách ngẫu nhiên bằng cách ném một số văn bản ngẫu nhiên. Nhưng nó có hoạt động giống nhau ngay cả khi tôi muốn truy xuất dữ liệu from_date to to_date(tôi mong đợi có thể như vậy). Nhưng câu hỏi thực sự là, nó có phải là Công cụ tìm kiếm, hay bộ lưu trữ dữ liệu NoSQL hoàn hảo như Cassandra? Nếu có, tại sao chúng ta vẫn cần Cassandra?

Nếu cả hai đều ở thế giới khác nhau, vui lòng giải thích điều đó! Làm thế nào để chúng ta kết hợp chúng để có được một giải pháp hiệu quả hơn?


2
Bạn cũng nên xem xét DSE Search = Cassandra + solr integration = tốt nhất của cả hai thế giới: một db có thể mở rộng cho bộ nhớ được thúc đẩy bởi sức mạnh tìm kiếm của Solr.
Bereng

1
@Bereng, tôi đoán DSE là thương mại và chúng tôi không chăm sóc phần mềm thương mại.
Reddy

3
Nếu bạn là một công ty khởi nghiệp có doanh thu ròng <2 triệu đô la Mỹ (Mỹ), họ sẽ cho phép bạn sử dụng DSE miễn phí (trong ít nhất một hoặc hai năm).
Aaron

Câu trả lời:


150

Một trong những ứng dụng của chúng tôi sử dụng dữ liệu được lưu trữ trong cả Cassandra và ElasticSearch. Chúng tôi sử dụng Cassandra để truy cập các bản ghi đó bất cứ khi nào có thể và sao chép dữ liệu vào các bảng truy vấn được thiết kế để tuân thủ các yêu cầu cụ thể của phía ứng dụng. Đối với một tìm kiếm tự do hơn mức mà bảng truy vấn của chúng tôi có thể cho phép, ElasticSearch thực hiện chức năng đó một cách độc đáo.

Chúng tôi đã đặt câu hỏi tương tự (về chính mình) ... "Tại sao chúng tôi không lấy mọi thứ từ ElastsicSearch?"

Câu trả lời là ElasticSearch được thiết kế để trở thành một công cụ tìm kiếm chứ không phải một kho lưu trữ dữ liệu liên tục. Đôi khi ElasticSearch không ghi được. Rất khó thực hiện các thay đổi giản đồ trong ElasticSearch nếu không làm hỏng mọi thứ và tải lại. Vì mục đích đó, tôi đã viết các công việc được thiết kế để giữ cho ElasticSearch đồng bộ với cụm Cassandra của chúng tôi. Cũng có một cuộc thảo luận khá gần đây trên Quora về chủ đề này , cũng mang lại những điểm tương tự.

Điều đó đang được nói, ElasticSearch hoạt động tuyệt vời như một công cụ tìm kiếm. Và Cassandra hoạt động tuyệt vời như một kho dữ liệu hiệu suất cao, có thể mở rộng. Nhưng truy vấn dữ liệu khác với tìm kiếm dữ liệu. Đôi khi chúng ta cần cái này hay cái kia, và sự kết hợp của cả hai sẽ hoạt động tốt cho ứng dụng của chúng ta. Nó có thể (hoặc có thể không) hoạt động tốt cho bạn.

Đối với phân tích, tôi đã có một số thành công trong việc sử dụng trình kết nối Cassandra Spark, để phục vụ các truy vấn OLAP phức tạp hơn. Hy vọng rằng sẽ giúp.

Chỉnh sửa 20200421

Tôi đã viết một câu trả lời mới hơn cho một câu hỏi tương tự:

ElasticSearch so với ElasticSearch + Cassandra


24
Ai đó có thể giải thích về sự khác biệt giữa truy vấntìm kiếm dữ liệu không?
Dror

21
@dror ví dụ: nếu bạn biết (các) id dữ liệu của mình mà bạn chỉ yêu cầu (cassandra) và nếu bạn không biết (các) id dữ liệu của mình thì bạn tìm kiếm / chúng (tìm kiếm đàn hồi).
arsenik

2
@Gladwell tất cả phụ thuộc vào kích thước dữ liệu của bạn và mức độ phức tạp của các truy vấn của bạn. Về lý thuyết Elastic có thể làm được tất cả. Tuy nhiên, tôi tin tưởng Cassandra sẽ làm tốt hơn việc mở rộng quy mô để hỗ trợ tập dữ liệu lớn (cho các truy vấn) hơn Elastic, đặc biệt nếu bạn đang hỗ trợ đa vùng / DC.
Aaron

1
@Aaron ... mở rộng quy mô để hỗ trợ một tập dữ liệu lớn là những gì cả hai công cụ này làm tốt. Tổ chức của chúng tôi sử dụng tìm kiếm đàn hồi làm cơ sở dữ liệu chính, công cụ cảnh báo, công cụ phân tích và bây giờ xpack hỗ trợ học máy; nó cũng cung cấp số liệu thống kê kinh doanh xung quanh IOT cạnh của chúng tôi.
AnthonyJClink

1
@Dror Đặt câu hỏi thực sự!
Mike Ezzati

32

Cassandra + Lucene là một lựa chọn tuyệt vời. Có nhiều sáng kiến ​​khác nhau cho vấn đề này, ví dụ:


Một điều cần lưu ý, trong 2.1 bây giờ bạn có thể "thả vào" một trình chỉ mục tùy chỉnh ... vì vậy, ví dụ như bạn có thể bắt chước những gì Statio đang làm với nhánh C * của họ nhưng ngoài dòng chính C *. Tôi không biết về bất kỳ nỗ lực rộng rãi nào để làm điều này, nhưng bản thân tôi dự định giảm chỉ số Lucene vào C * theo cách này. Để biết thêm thông tin: issue.apache.org/jira/browse/CASSANDRA-8717
evanv

8

Sau khi tự mình giải quyết vấn đề này, tôi nhận ra rằng cơ sở dữ liệu NoSQL như casandra rất tốt khi bạn muốn đảm bảo rằng bạn đang bảo toàn lược đồ dữ liệu của mình bằng thao tác ghi đáng tin cậy và không muốn lợi dụng các thao tác lập chỉ mục màasticsearch cung cấp. Trong trường hợp bạn muốn lưu giữ một số dữ liệu chỉ mục thì tìm kiếm đàn hồi là tốt trong trường hợp bạn đang tin tưởng vào chương trình của mình và chỉ thực hiện nhiều lần đọc hơn là ghi.

Trường hợp của tôi là phân tích dữ liệu. Vì vậy, tôi đã bảo quản rất nhiều Latices của mình trong tìm kiếm đàn hồi vì sau này tôi muốn xem qua dữ liệu rất nhiều để xem đâu là bước tiếp theo của mình. Tôi đã sử dụng casandra nếu tôi muốn có nhiều thay đổi trong lược đồ dữ liệu trong đường dẫn phân tích của mình.

Ngoài ra, có rất nhiều công cụ đại diện đẹp mắt như kibana mà bạn có thể sử dụng để trình bày dữ liệu của mình với một số đồ họa đẹp. Có thể tôi lười biếng nhưng họ rất đẹp trai và họ đã giúp tôi.


4

Lưu trữ dữ liệu kết hợp giữa Cassandra và ElasticSearch cung cấp cho bạn hầu hết các chức năng. Nó cho phép bạn tra cứu các bảng khóa-giá trị và cũng cho phép bạn tìm kiếm dữ liệu trong các chỉ mục.

Sự kết hợp mang lại cho bạn rất nhiều tính linh hoạt, lý tưởng cho ứng dụng của bạn.


4

Elassandra là giải pháp kết hợp giữa tìm kiếm Cassandra + Elastic, Nó sử dụng tìm kiếm Elastic để lập chỉ mục dữ liệu và Cassandra làm kho lưu trữ dữ liệu, tôi không chắc về hiệu suất nhưng theo bài viết này , hiệu suất của nó là tốt.
Nếu ứng dụng của bạn cần tính năng tìm kiếm thì Elassandra là lựa chọn mã nguồn mở tốt nhất. Tìm kiếm DSE có sẵn nhưng đắt tiền.


1

Chúng tôi đã phát triển một ứng dụng trong đó chúng tôi sử dụng Elasticsearch và Cassandra. Dữ liệu tương tự đã được lưu trữ vào Cassandra và được lập chỉ mục vào Elasticsearch.

Giao diện người dùng của ứng dụng của chúng tôi có các tính năng như tìm kiếm, tổng hợp, xuất dữ liệu, v.v. Các microservices liên tục nhận được dữ liệu khổng lồ (về các chủ đề của Kafka) và lưu trữ nó vào Cassandra. Khi dữ liệu được lưu trữ vào Cassandra, các dịch vụ sẽ đảm bảo dữ liệu được lập chỉ mục vào Elasticsearch.

Cassandra đã hoạt động như "Nguồn của sự thật" cho Elasticsearch. Trong các trường hợp yêu cầu lập chỉ mục lại chỉ mục ES, chúng tôi đã truy vấn Cassandra và lập chỉ mục lại dữ liệu vào ES.

Giải pháp này đã giúp chúng tôi, vì điều này rất dễ mở rộng quy mô và các tìm kiếm và tổng hợp nhanh hơn nhiều.


0
  • Vìasticsearch được xây dựng dựa trên chỉ mục Lucene và nếu bạn muốn lưu trữ lập chỉ mục trongasticsearch, nó hoạt động tốt nhất so với lập chỉ mục trong chính Cassandra để lấy dữ liệu.
  • Nếu yêu cầu của bạn không liên quan đến truy xuất thời gian thực thì bạn có thể sử dụngasticsearch làm cơ sở dữ liệu NoSQL, có những ý kiến ​​cho rằng ElasticSearch mất khả năng ghi & thay đổi lược đồ là khó, nhưng nếu khối lượng dữ liệu của bạn không quá lớn. Bạn có thể dễ dàng tìm kiếm đàn hồi làm công cụ tìm kiếm có chỉ mục tốt nhất cùng với đàn hồi tìm kiếm dưới dạng cơ sở dữ liệu aNoSQL. Có một số cách mà bạn có thể ngăn chặn nó. Tôi đã làm việc trên các thay đổi lược đồ trongasticsearch, nếu cấu trúc dữ liệu của bạn nhất quán thì nó sẽ tạo ra bất kỳ vấn đề nào.
  • Là người ủng hộ ElasticSearch hoặc SOlr. Tôi đã làm việc trên cả hai công cụ tìm kiếm và tôi có kinh nghiệm rằng cả hai công cụ tìm kiếm đều có thể được sử dụng thành thạo nếu bạn định cấu hình chúng một cách chính xác.
  • Chỉ có khuyết điểm mà tôi có thể nghĩ ra, nếu bạn đang nhắm mục tiêu kết quả thời gian thực và không thể tính toán độ trễ mili giây trong phản hồi của bạn. Sau đó, tốt hơn hết bạn nên nhận sự trợ giúp của các cơ sở dữ liệu NoSQL khác như cassandra hoặc couchbase.
  • Cassandra với solr, hoạt động tốt hơn Cassandra với co giãnSearch.

0

Cassandra rất giỏi trong việc truy xuất dữ liệu bằng ID . Tôi không biết nhiều về hiệu suất chỉ mục thứ cấp, nhưng tôi nghi ngờ nó nhanh như Elasticsearch. Chắc chắn Elasticsearch chiến thắng khi nói đến chức năng tìm kiếm văn bản đầy đủ ( phân tích văn bản , chấm điểm mức độ liên quan , v.v.).

Cassandra cũng thắng về hiệu suất cập nhật . Elasticsearch hỗ trợ các bản cập nhật, nhưng bản cập nhật thực sự là một reindex + soft delete trong một hoạt động nguyên tử.

Cassandra có một mô hình sao chép rất đẹp (nếu bạn cần phải cực kỳ an toàn). Elasticsearch cũng được, tôi không ở trong trại nói rằng ES đặc biệt không đáng tin cậy (đôi khi nó có vấn đề, giống như tất cả các phần mềm).

Elasticsearch cũng có các tổng hợp để phân tích thời gian thực. Và bởi vì tìm kiếm quá nhanh, phân tích trên một tập hợp con dữ liệu cũng sẽ nhanh chóng .

Nếu yêu cầu của bạn được một trong số họ đáp ứng đủ tốt (như ở đây có vẻ như ES sẽ hoạt động tốt), tôi sẽ chỉ sử dụng một trong số đó. Nếu bạn có yêu cầu từ cả hai thế giới, thì bạn có thể:

  • sử dụng một trong số chúng và khắc phục những nhược điểm. Ví dụ: bạn có thể xử lý nhiều bản cập nhật với Elasticsearch, nhưng với nhiều phân đoạn hơn và nhiều phần cứng hơn
  • sử dụng cả hai và đảm bảo chúng được đồng bộ hóa
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.