Tôi tin rằng việc lưu giữ các bản ghi chính trong cơ sở dữ liệu SQL và sao chép chúng vào cơ sở dữ liệu noSQL là một cách tiếp cận rất phổ biến.
ElasticSearch có một trang trạng thái liên tục về khả năng phục hồi của họ . Ngay cả trong phiên bản mới nhất, ElasticSearch có thể làm mất dữ liệu trong một số tình huống . Một thay đổi lớn trong cấu trúc của chỉ mục ElasticSearch (chẳng hạn như thêm bộ phân tích) yêu cầu bạn re-index tất cả các tài liệu. Quá trình này an toàn hơn nếu bạn có một nguồn tài liệu khác. Vào cuối ngày, ElasticSearch không được thiết kế để lưu trữ tài liệu một cách nhất quán - tôi sẽ chỉ chọn sử dụng ElasticSearch làm nơi lưu trữ chính trong các tình huống mà việc mất dữ liệu không thường xuyên không phải là một thảm họa.
Không giống như ElasticSearch, MongoDB được thiết kế để có khả năng phục hồi . Bạn sẽ có thể lưu trữ tài liệu một cách an toàn trong MongoDB. Tôi nhận thấy việc cố gắng thực hiện tìm kiếm toàn văn trong MongoDB có thể hơi khó khăn, ít nhất là so với ElasticSearch. Theo tôi, đối với tìm kiếm văn bản, lợi thế duy nhất mà MongoDB có so với FULLTEXT là nó được phân phối.
Chúng tôi đang chạy ElasticSearch và MySQL ngay bây giờ - và lợi ích vượt trội hơn rất nhiều so với sự phức tạp của cơ sở hạ tầng bổ sung và đối phó với việc sao chép giữa hai loại này. Trước đây chúng tôi đã cố gắng sử dụng giải pháp noSQL làm kho dữ liệu chính, với kết quả thảm hại. Chạy ES kết hợp với MySQL giúp bạn tận dụng tối đa cả hai thế giới - tính nhất quán và an toàn của dữ liệu trong SQL, với khả năng mở rộng, tìm kiếm toàn văn hiệu quả trong ES.
