Một số trường hợp sử dụng để sử dụng Elaticsearch so với truy vấn sql tiêu chuẩn là gì? [đóng cửa]


125

Tôi mới bắt đầu với Elaticsearch và một trong những trường hợp sử dụng chính mà tôi thấy là khả năng mở rộng của nó với các tìm kiếm trên các tập dữ liệu lớn, nhưng bên cạnh đó, khi nào bạn muốn sử dụng nó chỉ bằng cách tạo truy vấn sql với RDBMS truyền thống?


3
Câu hỏi chỉnh sửa để cải thiện chúng (ví dụ: làm rõ, thêm thông tin, v.v.) được khuyến khích . Tuy nhiên, chỉnh sửa Câu hỏi để thay đổi Câu hỏi thành một câu hỏi khác, dẫn đến vô hiệu hóa một hoặc nhiều Câu trả lời, là trái với chính sách đối với Stack Overflow. Chỉnh sửa của bạn ở đây đã làm như vậy. Chính sách là những người dùng khác có đặc quyền chỉnh sửa nên chủ động hoàn nguyên các thay đổi đó, điều mà tôi đã thực hiện ở đây. Nếu câu hỏi mới của bạn thuộc chủ đề, bạn nên đặt câu hỏi mới , có thể có liên kết đến câu hỏi này để biết thêm ngữ cảnh.
Makyen

Hiểu. Vâng, ý định là đúng, chỉ là không thực hiện.
James Drinkard

Câu trả lời:


78

Có hai trường hợp sử dụng Elaticsearch chính:

  1. Tìm kiếm văn bản

Bạn muốn Elaticsearch khi bạn thực hiện nhiều tìm kiếm văn bản, trong đó cơ sở dữ liệu RDBMS truyền thống không hoạt động thực sự tốt (cấu hình kém, hoạt động như một hộp đen, hiệu suất kém). Elaticsearch có khả năng tùy biến cao, có thể mở rộng thông qua các plugin. Bạn có thể xây dựng tìm kiếm mạnh mẽ mà không cần nhiều kiến ​​thức khá nhanh.

  1. Ghi nhật ký và phân tích

Một trường hợp khác là rất nhiều người sử dụng Elaticsearch để lưu trữ nhật ký từ nhiều nguồn khác nhau (để tập trung chúng), vì vậy họ có thể phân tích chúng và hiểu ý nghĩa của nó. Trong trường hợp này, Kibana trở nên tiện dụng. Nó cho phép bạn kết nối với cụm Elaticsearch và tạo trực quan ngay lập tức. Chẳng hạn, Loggly được xây dựng bằng cách sử dụng Elaticsearch và Kibana.

Hãy ghi nhớ rằng bạn sẽ không muốn sử dụng Elaticsearch làm nơi lưu trữ dữ liệu chính của mình. Lý do ở đây: Độ tin cậy của ElasticSearch như một kho dữ liệu chính chống lại các yếu tố như mất ghi, tính khả dụng của dữ liệu

Cập nhật

Tôi cảm thấy như phần thứ hai không còn sắc sảo nữa, đó thực sự là điều mà công ty đàn hồi đã làm rất tốt trong năm qua. Với phong trào DevOps hiện tại, các đường ống CI / CD, tăng số liệu từ nhiều nguồn khác nhau, ELK trở thành lựa chọn không chính xác để giám sát cơ sở hạ tầng, nó không còn là công cụ tìm kiếm văn bản RESTful phân tán. Nó có một bộ sản phẩm tuyệt vời:

  • Logstash (tấn dữ liệu đầu vào)
  • Nhịp đập
    • Filebeat
    • Số liệu
    • Gói
    • Thắng cuộc
  • Kibana
    • Đồ thị
    • Thời gian
  • X-Pack (cao cấp)
    • Cảnh báo
    • Báo cáo
    • Bảo vệ
    • Học máy
    • Số liệu trung tâm dữ liệu chéo

Một hệ sinh thái, được xây dựng bởi cộng đồng, đang phát triển xung quanh ngăn xếp ELK mở rộng các tính năng hiện tại, một vài trong số chúng đáng được đề cập:

  • ElastAlert
  • Bảo vệ tìm kiếm

Tại sao hạn chế Tìm kiếm đàn hồi không được sử dụng làm công cụ truy vấn cho các hệ thống tiêu chuẩn, như pos hoặc erp vì tôi không hiểu các công ty rất nhiều năng lượng được đặt chỉ là chuyển đổi dữ liệu từ sql sang tìm kiếm đàn hồi để phân tích.
pannu

Trong các phiên bản cũ hơn, nó không được khuyến khích, bây giờ tôi không biết.
Evaldas Buinauskas

Bạn nói, vì cấu hình kém, RDBMS hoạt động không thực sự tốt. Điều đó có nghĩa là, với cấu hình tốt, bạn có thể thực hiện cũng như với EleasticSearch, đối với tìm kiếm văn bản (tìm kiếm mờ)?
Huyền thoại

2
@Legends Tôi thực sự có nghĩa là tùy chọn cấu hình kém. Trải nghiệm của riêng tôi bị giới hạn ở Tìm kiếm toàn văn bản MSSQL và số lượng cài đặt trong MSSQL không thể so sánh với Elaticsearch. Tìm kiếm văn bản trong RDBMS là một tính năng, trong khi trong Elaticsearch, đó là bản chất.
Evaldas Buinauskas

Tôi đã tìm kiếm rất nhiều trên web, nhưng tôi không thể tìm thấy bất cứ điều gì cụ thể. Ứng dụng nên có bao nhiêu dữ liệu (chỉ là xấp xỉ) để chúng tôi nghĩ về việc chuyển sang ElasticSerach?, Vì việc duy trì các hệ thống phân tán là phức tạp. Ví dụ, tìm kiếm trong các văn bản bình luận được lập chỉ mục tốt trong mongodb. (Tôi không nói về các tính năng nâng cao của ES, tìm kiếm văn bản thuần túy)
Iván Sánchez

27

Để thêm vào câu trả lời khác, Ghi nhật ký vẫn là trường hợp sử dụng chính cũng như tìm kiếm, nhưng bây giờ số liệu và phân tích đang trở nên quan trọng hơn.

Tôi tin rằng bài đăng này tóm tắt những thay đổi trong thị trường đang thúc đẩy các trường hợp sử dụng mới cho Dữ liệu lớn. Tất cả những gì bạn thực sự cần biết về Cơ sở dữ liệu nguồn mở

Với sự ra đời của Web 2.0, các trang web tĩnh đã trở thành phương tiện truyền thông xã hội năng động và xung quanh chúng ta. Mọi người đang tweet, đăng bài, viết blog, vlogging, chia sẻ hình ảnh, trò chuyện và bình luận. Internet of Things (IoT) đang nổi lên - một mạng lưới các thiết bị được kết nối đang phát triển nhanh chóng thu thập và trao đổi dữ liệu, như cảm biến và thiết bị thông minh. Có một số ví dụ tuyệt vời ở đây.

Nhìn chung, điều này tạo ra một lượng lớn dữ liệu mới mà các doanh nghiệp muốn tiếp thu và sử dụng để luôn đi đầu, để cung cấp các tính năng như đề xuất sản phẩm và trải nghiệm khách hàng tốt hơn. Dữ liệu có thể được phân tích trong tìm kiếm các mẫu cho các ứng dụng như phát hiện gian lận và phân tích hành vi. Phần lớn dữ liệu mới không có cấu trúc, điều đó có nghĩa là nó không thể được lưu trữ gọn gàng trong cơ sở dữ liệu dạng bảng.

Hãy tưởng tượng bạn đang cố gắng thiết kế một cơ sở dữ liệu để chứa dữ liệu về việc mua sắm hàng tạp hóa của bạn - những gì bạn thích, tần suất bạn mua nó, cho dù bạn thích sữa hay kem với cà phê của bạn. Các loại cơ sở dữ liệu mới là cần thiết để lưu trữ dữ liệu mới và chúng cần phải không liên quan và chi phí thấp lý tưởng. Đổ chuông nào? Không liên quan như trong NoQuery và chi phí thấp như trong nguồn mở.

Một trong những Kiến trúc sư Elaticsearch mà tôi đã nói chuyện đã nói rằng 80% dữ liệu mà Elaticsearch làm việc với các công ty là không có cấu trúc, trong khi 20% được cấu trúc. Đó là dữ liệu phi cấu trúc mà các công ty đang xem xét để khám phá các mẫu dữ liệu hiếm hoặc bất thường. Họ cũng đang sử dụng Elaticsearch để theo dõi các mẫu dữ liệu. Ví dụ, một nhà bán lẻ lớn đang thực hiện theo dõi thời gian thực với Elaticsearch để đảm bảo cung cấp đủ tiền tại các cửa hàng để mọi người kiểm tra tiền mặt vào các ngày.

Theo kinh nghiệm của riêng tôi với trường hợp sử dụng tìm kiếm của chúng tôi, chúng tôi không chỉ sử dụng các tìm kiếm mờ mà còn phát triển thành các tìm kiếm tự động hoàn thành và nhanh chóng. Từ những gì tôi đã thấy, một khi bạn bắt đầu làm việc với Elaticsearch, bạn bắt đầu phát triển thành các trường hợp sử dụng khác bổ sung cho những gì bạn đã có. Bây giờ chúng tôi đã thiết lập Elaticsearch như một công cụ tìm kiếm mờ tại công ty của chúng tôi, bây giờ chúng tôi có các nhóm khác đang xem xét phân tích và số liệu để đăng nhập.

Dưới đây là một số tài nguyên bổ sung đi sâu hơn về chủ đề này:

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.