Quản lý dữ liệu truyền trực tuyến từ hệ thống nguồn, như PostgreSQL, MongoDB hoặc DynamoDB, vào hệ thống hạ nguồn để tìm kiếm và phân tích theo thời gian thực là một thách thức đối với nhiều nhóm. Luồng dữ liệu thường liên quan đến công cụ ETL phức tạp cũng như tích hợp tự quản lý để đảm bảo rằng khối lượng ghi lớn, bao gồm cả cập nhật và xóa, không làm tốn CPU hoặc ảnh hưởng đến hiệu suất của ứng dụng cuối.
Đối với một hệ thống như Elaticsearch , các kỹ sư cần có kiến thức chuyên sâu về kiến trúc cơ bản để tiếp thu dữ liệu truyền phát một cách hiệu quả . Elaticsearch được thiết kế để phân tích nhật ký trong đó dữ liệu không thường xuyên thay đổi, đặt ra những thách thức bổ sung khi xử lý dữ liệu giao dịch.
Mặt khác, Rockset là cơ sở dữ liệu gốc trên nền tảng đám mây, loại bỏ nhiều công cụ và chi phí cần thiết để đưa dữ liệu vào hệ thống. Vì Rockset được xây dựng có mục đích để tìm kiếm và phân tích theo thời gian thực nên nó cũng được thiết kế để có khả năng thay đổi ở cấp trường , giảm CPU cần thiết để xử lý các thao tác chèn, cập nhật và xóa.
Trong blog này, chúng tôi sẽ so sánh và đối chiếu cách Elaticsearch và Rockset xử lý việc nhập dữ liệu cũng như cung cấp các kỹ thuật thực tế để sử dụng các hệ thống này cho phân tích thời gian thực.
Mặc dù có nhiều cách để nhập dữ liệu vào Elaticsearch, chúng tôi đề cập đến ba phương pháp phổ biến để tìm kiếm và phân tích theo thời gian thực:
Nhập dữ liệu từ cơ sở dữ liệu quan hệ vào Elaticsearch bằng cách sử dụng plugin đầu vào Logstash JDBC
Nhập dữ liệu từ Kafka vào Elaticsearch bằng Trình kết nối bồn rửa dịch vụ Kafka Elaticsearch
Nhập dữ liệu trực tiếp từ ứng dụng vào Elaticsearch bằng API REST và thư viện máy khách
Nhập dữ liệu từ cơ sở dữ liệu quan hệ vào Elaticsearch bằng cách sử dụng plugin đầu vào Logstash JDBC. Plugin đầu vào Logstash JDBC có thể được sử dụng để tải dữ liệu từ cơ sở dữ liệu quan hệ như PostgreSQL hoặc MySQL sang Elaticsearch để tìm kiếm và phân tích.
Logstash là một quy trình xử lý sự kiện có chức năng nhập và chuyển đổi dữ liệu trước khi gửi đến Elaticsearch. Logstash cung cấp plugin đầu vào JDBC thăm dò cơ sở dữ liệu quan hệ, như PostgreSQL hoặc MySQL, để chèn và cập nhật định kỳ. Để sử dụng dịch vụ này, cơ sở dữ liệu quan hệ của bạn cần cung cấp các bản ghi được đánh dấu thời gian mà Logstash có thể đọc được để xác định những thay đổi nào đã xảy ra.
Phương pháp nhập này hoạt động tốt đối với các phần chèn và cập nhật nhưng cần cân nhắc thêm khi xóa. Đó là vì Logstash không thể xác định nội dung nào đã bị xóa trong cơ sở dữ liệu OLTP của bạn. Người dùng có thể khắc phục hạn chế này bằng cách triển khai xóa mềm, trong đó cờ được áp dụng cho bản ghi đã xóa và được sử dụng để lọc dữ liệu tại thời điểm truy vấn. Hoặc, họ có thể quét định kỳ cơ sở dữ liệu quan hệ của mình để có quyền truy cập vào các bản ghi cập nhật nhất và lập chỉ mục lại dữ liệu trong Elaticsearch.
Nhập dữ liệu từ Kafka vào Elaticsearch bằng Kafka Elasticsearch Sink Connector . Việc sử dụng nền tảng phát trực tuyến sự kiện như Kafka để gửi dữ liệu từ hệ thống nguồn vào Elaticsearch để tìm kiếm và phân tích theo thời gian thực cũng là điều phổ biến.
Confluent và Elastic hợp tác trong việc phát hành Kafka Elasticsearch Service Sink Connector , dành cho các công ty sử dụng cả hai dịch vụ Confluent Kafka và Elasticsearch được quản lý. Trình kết nối yêu cầu cài đặt và quản lý công cụ bổ sung, Kafka Connect.
Bằng cách sử dụng trình kết nối, bạn có thể ánh xạ từng chủ đề trong Kafka tới một loại chỉ mục duy nhất trong Elaticsearch. Nếu kiểu gõ động được sử dụng làm loại chỉ mục thì Elaticsearch sẽ hỗ trợ một số thay đổi lược đồ như thêm trường, xóa trường và thay đổi loại.
Một trong những thách thức nảy sinh khi sử dụng Kafka là cần lập chỉ mục lại dữ liệu trong Elaticsearch khi bạn muốn sửa đổi bộ phân tích, mã thông báo hoặc các trường được lập chỉ mục. Điều này là do ánh xạ không thể thay đổi một khi nó đã được xác định. Để thực hiện lập chỉ mục lại dữ liệu, bạn sẽ cần ghi hai lần vào chỉ mục gốc và chỉ mục mới, di chuyển dữ liệu từ chỉ mục gốc sang chỉ mục mới, sau đó dừng công việc kết nối ban đầu.
Nếu không sử dụng các dịch vụ được quản lý từ Confluent hoặc Elastic, bạn có thể sử dụng plugin Kafka nguồn mở cho Logstash để gửi dữ liệu tới Elasticsearch.
Nhập dữ liệu trực tiếp từ ứng dụng vào Elaticsearch bằng API REST và thư viện ứng dụng khách Elaticsearch cung cấp khả năng sử dụng các thư viện ứng dụng khách được hỗ trợ bao gồm Java, Javascript, Ruby, Go, Python, v.v. để nhập dữ liệu qua API REST trực tiếp từ ứng dụng của bạn. Một trong những thách thức khi sử dụng thư viện máy khách là nó phải được cấu hình để hoạt động với hàng đợi và áp suất ngược trong trường hợp Elaticsearch không thể xử lý tải nạp. Nếu không có hệ thống xếp hàng, có khả năng mất dữ liệu vào Elaticsearch.
Elaticsearch có API cập nhật có thể được sử dụng để xử lý các bản cập nhật và xóa. API cập nhật giúp giảm số lần ngắt kết nối mạng và khả năng xảy ra xung đột phiên bản. API cập nhật truy xuất tài liệu hiện có từ chỉ mục, xử lý thay đổi và sau đó lập chỉ mục lại dữ liệu. Điều đó có nghĩa là Elaticsearch không cung cấp các bản cập nhật hoặc xóa tại chỗ. Vì vậy, toàn bộ tài liệu vẫn phải được lập chỉ mục lại, một hoạt động đòi hỏi nhiều CPU.
Dưới lớp vỏ bọc, dữ liệu Elaticsearch được lưu trữ trong chỉ mục Lucene và chỉ mục đó được chia thành các phân đoạn nhỏ hơn. Mỗi phân đoạn là bất biến nên tài liệu không thể thay đổi. Khi thực hiện cập nhật, tài liệu cũ sẽ được đánh dấu để xóa và tài liệu mới sẽ được hợp nhất để tạo thành một phân đoạn mới. Để sử dụng tài liệu cập nhật, tất cả các máy phân tích cần phải chạy, điều này cũng có thể làm tăng mức sử dụng CPU. Thông thường, những khách hàng có dữ liệu thay đổi liên tục sẽ thấy việc hợp nhất chỉ mục ngốn một lượng đáng kể tổng hóa đơn tính toán Elaticsearch của họ.
Với lượng tài nguyên cần thiết, Elastic khuyên bạn nên giới hạn số lượng cập nhật vào Elaticsearch. Một khách hàng tham khảo của Elaticsearch, Bol.com , đã sử dụng Elaticsearch để tìm kiếm trang web như một phần của nền tảng thương mại điện tử của họ. Bol.com có khoảng 700 nghìn bản cập nhật mỗi ngày cho các dịch vụ của họ, bao gồm các thay đổi về nội dung, giá cả và tính khả dụng. Ban đầu, họ muốn có một giải pháp đồng bộ với mọi thay đổi khi chúng xảy ra. Tuy nhiên, do tác động của các bản cập nhật đối với hiệu suất của hệ thống Elaticsearch, họ đã chọn cho phép độ trễ 15-20 phút. Việc phân nhóm tài liệu vào Elaticsearch đảm bảo hiệu suất truy vấn nhất quán.
Trong Elaticsearch, có thể có những thách thức liên quan đến việc xóa các tài liệu cũ và lấy lại không gian.
Elaticsearch hoàn tất việc hợp nhất phân đoạn trong nền khi có số lượng lớn phân đoạn trong một chỉ mục hoặc có nhiều tài liệu trong một phân đoạn được đánh dấu để xóa. Hợp nhất phân đoạn là khi tài liệu được sao chép từ các phân đoạn hiện có vào một phân đoạn mới được hình thành và các phân đoạn còn lại sẽ bị xóa. Thật không may, Lucene không giỏi trong việc định cỡ các phân đoạn cần hợp nhất, có khả năng tạo ra các phân đoạn không đồng đều ảnh hưởng đến hiệu suất và độ ổn định.
Đó là vì Elaticsearch giả định tất cả tài liệu đều có kích thước đồng đều và đưa ra quyết định hợp nhất dựa trên số lượng tài liệu bị xóa. Khi xử lý các kích thước tài liệu không đồng nhất, như thường thấy trong các ứng dụng có nhiều người thuê, một số phân đoạn sẽ tăng kích thước nhanh hơn các phân đoạn khác, làm chậm hiệu suất của những khách hàng lớn nhất trên ứng dụng. Trong những trường hợp này, biện pháp khắc phục duy nhất là lập chỉ mục lại một lượng lớn dữ liệu.
Elaticsearch sử dụng mô hình sao lưu chính để sao chép. Bản sao chính xử lý thao tác ghi đến và sau đó chuyển tiếp thao tác đó tới các bản sao của nó. Mỗi bản sao nhận được thao tác này và lập chỉ mục lại dữ liệu cục bộ một lần nữa. Điều này có nghĩa là mỗi bản sao sẽ sử dụng các tài nguyên tính toán tốn kém một cách độc lập để lập chỉ mục lại cùng một tài liệu nhiều lần. Nếu có n bản sao, Elastic sẽ tốn n lần CPU để lập chỉ mục cho cùng một tài liệu. Điều này có thể làm trầm trọng thêm lượng dữ liệu cần được lập chỉ mục lại khi xảy ra cập nhật hoặc chèn.
Mặc dù bạn có thể sử dụng API cập nhật trong Elaticsearch nhưng thông thường bạn nên thực hiện các thay đổi thường xuyên theo nhóm bằng cách sử dụng API hàng loạt . Khi sử dụng API hàng loạt, nhóm kỹ thuật thường sẽ cần tạo và quản lý hàng đợi để hợp lý hóa các bản cập nhật vào hệ thống.
Hàng đợi độc lập với Elaticsearch và sẽ cần được định cấu hình và quản lý. Hàng đợi sẽ hợp nhất các phần chèn, cập nhật và xóa vào hệ thống trong một khoảng thời gian cụ thể, chẳng hạn như 15 phút, để hạn chế tác động đến Elaticsearch. Hệ thống xếp hàng cũng sẽ áp dụng bộ điều tiết khi tốc độ chèn cao để đảm bảo tính ổn định của ứng dụng. Mặc dù hàng đợi rất hữu ích cho việc cập nhật nhưng chúng không tốt trong việc xác định khi nào có nhiều thay đổi dữ liệu yêu cầu lập chỉ mục lại toàn bộ dữ liệu. Điều này có thể xảy ra bất cứ lúc nào nếu có nhiều bản cập nhật cho hệ thống. Thông thường, các nhóm chạy Elastic trên quy mô lớn thường có các thành viên vận hành chuyên trách quản lý và điều chỉnh hàng đợi của họ hàng ngày.
Như đã đề cập trong phần trước, khi có nhiều bản cập nhật hoặc bạn cần thay đổi ánh xạ chỉ mục thì việc lập chỉ mục lại dữ liệu sẽ xảy ra. Việc lập chỉ mục lại dễ xảy ra lỗi và có khả năng làm hỏng một cụm. Điều đáng sợ hơn nữa là việc lập chỉ mục lại có thể xảy ra bất cứ lúc nào.
Nếu bạn muốn thay đổi ánh xạ của mình, bạn có nhiều quyền kiểm soát hơn đối với thời gian xảy ra việc lập chỉ mục lại. Elaticsearch có API reindex để tạo chỉ mục mới và API Bí danh để đảm bảo rằng không có thời gian ngừng hoạt động khi tạo chỉ mục mới. Với API bí danh, các truy vấn được định tuyến đến bí danh hoặc chỉ mục cũ khi chỉ mục mới đang được tạo. Khi chỉ mục mới sẵn sàng, API bí danh sẽ chuyển đổi để đọc dữ liệu từ chỉ mục mới.
Với API bí danh, việc giữ chỉ mục mới đồng bộ với dữ liệu mới nhất vẫn còn khó khăn. Đó là vì Elaticsearch chỉ có thể ghi dữ liệu vào một chỉ mục. Vì vậy, bạn sẽ cần định cấu hình đường dẫn dữ liệu ngược dòng để ghi kép vào chỉ mục mới và cũ.
Rockset sử dụng các trình kết nối tích hợp sẵn để giữ cho dữ liệu của bạn đồng bộ với hệ thống nguồn. Các trình kết nối được quản lý của Rockset được điều chỉnh cho từng loại nguồn dữ liệu để dữ liệu có thể được nhập và có thể truy vấn được trong vòng 2 giây. Điều này tránh các quy trình thủ công gây thêm độ trễ hoặc chỉ có thể nhập dữ liệu theo từng lô nhỏ, chẳng hạn cứ 15 phút một lần.
Ở cấp độ cao, Rockset cung cấp các trình kết nối tích hợp với cơ sở dữ liệu OLTP, luồng dữ liệu, hồ dữ liệu và kho dữ liệu. Đây là cách chúng hoạt động:
Trình kết nối tích hợp với cơ sở dữ liệu OLTP Rockset thực hiện quét ban đầu các bảng trong cơ sở dữ liệu OLTP của bạn, sau đó sử dụng các luồng CDC để luôn đồng bộ hóa với dữ liệu mới nhất, với dữ liệu được cung cấp để truy vấn trong vòng 2 giây kể từ khi được tạo bởi hệ thống nguồn.
Trình kết nối tích hợp với luồng dữ liệu Với các luồng dữ liệu như Kafka hoặc Kinesis, Rockset liên tục sử dụng bất kỳ chủ đề mới nào bằng cách sử dụng tích hợp dựa trên kéo mà không cần điều chỉnh trong Kafka hoặc Kinesis.
Trình kết nối tích hợp với Hồ dữ liệu và Kho dữ liệu Rockset liên tục giám sát các bản cập nhật và tiếp thu mọi đối tượng mới từ hồ dữ liệu như nhóm S3. Nhìn chung, chúng tôi nhận thấy rằng các nhóm muốn tham gia các luồng thời gian thực với dữ liệu từ hồ dữ liệu của họ để phân tích theo thời gian thực.
Rockset có kiến trúc phân tán được tối ưu hóa để lập chỉ mục dữ liệu song song một cách hiệu quả trên nhiều máy.
Rockset là cơ sở dữ liệu phân chia tài liệu , do đó, nó ghi toàn bộ tài liệu vào một máy duy nhất, thay vì tách nó ra và gửi các trường khác nhau đến các máy khác nhau. Do đó, việc thêm tài liệu mới để chèn hoặc định vị tài liệu hiện có sẽ nhanh chóng dựa trên khóa chính _id để cập nhật và xóa.
Tương tự như Elaticsearch, Rockset sử dụng các chỉ mục để truy xuất dữ liệu nhanh chóng và hiệu quả khi được truy vấn. Tuy nhiên, không giống như các cơ sở dữ liệu hoặc công cụ tìm kiếm khác, Rockset lập chỉ mục dữ liệu tại thời điểm nhập vào Chỉ mục hội tụ , một chỉ mục kết hợp lưu trữ cột, chỉ mục tìm kiếm và lưu trữ hàng. Chỉ mục hội tụ lưu trữ tất cả các giá trị trong các trường dưới dạng một chuỗi các cặp khóa-giá trị. Trong ví dụ bên dưới, bạn có thể xem một tài liệu và cách nó được lưu trữ trong Rockset.
Dưới vỏ bọc, Rockset sử dụng RocksDB , một kho lưu trữ khóa-giá trị hiệu suất cao giúp biến đổi trở nên tầm thường. RocksDB hỗ trợ ghi và xóa nguyên tử trên các khóa khác nhau. Nếu có bản cập nhật cho trường name
của tài liệu, chính xác 3 khóa cần được cập nhật, mỗi khóa cho một chỉ mục. Chỉ mục cho các trường khác trong tài liệu không bị ảnh hưởng, nghĩa là Rockset có thể xử lý các bản cập nhật một cách hiệu quả thay vì lãng phí chu kỳ cập nhật chỉ mục cho toàn bộ tài liệu mỗi lần.
Các tài liệu và mảng lồng nhau cũng là loại dữ liệu hạng nhất trong Rockset, nghĩa là quy trình cập nhật tương tự cũng áp dụng cho chúng, khiến Rockset rất phù hợp để cập nhật dữ liệu được lưu trữ ở các định dạng hiện đại như JSON và Avro.
Nhóm tại Rockset cũng đã xây dựng một số tiện ích mở rộng tùy chỉnh cho RocksDB để xử lý khả năng ghi cao và đọc nhiều, một mô hình phổ biến trong khối lượng công việc phân tích thời gian thực. Một trong những tiện ích mở rộng đó là tính năng nén từ xa , giới thiệu sự tách biệt rõ ràng giữa tính toán truy vấn và tính toán lập chỉ mục cho Đám mây RocksDB. Điều này cho phép Rockset tránh việc ghi làm ảnh hưởng đến việc đọc. Nhờ những cải tiến này, Rockset có thể mở rộng quy mô ghi theo nhu cầu của khách hàng và cung cấp dữ liệu mới để truy vấn ngay cả khi có đột biến xảy ra trong nền.
Người dùng Rockset có thể sử dụng trường _id mặc định hoặc chỉ định một trường cụ thể làm khóa chính. Trường này cho phép ghi đè một tài liệu hoặc một phần của tài liệu. Sự khác biệt giữa Rockset và Elaticsearch là Rockset có thể cập nhật giá trị của một trường riêng lẻ mà không yêu cầu lập chỉ mục lại toàn bộ tài liệu.
Để cập nhật các tài liệu hiện có trong bộ sưu tập bằng API Rockset, bạn có thể gửi yêu cầu tới điểm cuối Patch Documents. Đối với mỗi tài liệu hiện có mà bạn muốn cập nhật, bạn chỉ cần chỉ định trường _id và danh sách các thao tác vá sẽ được áp dụng cho tài liệu.
API Rockset cũng hiển thị điểm cuối Thêm tài liệu để bạn có thể chèn dữ liệu trực tiếp vào bộ sưu tập từ mã ứng dụng của mình. Để xóa tài liệu hiện có, chỉ cần chỉ định trường _id của tài liệu bạn muốn xóa và gửi yêu cầu tới điểm cuối Xóa tài liệu của Rockset API.
Không giống như Elaticsearch, chỉ có một bản sao trong Rockset thực hiện việc lập chỉ mục và nén bằng cách sử dụng các phép nén từ xa của RocksDB. Điều này làm giảm lượng CPU cần thiết để lập chỉ mục, đặc biệt khi nhiều bản sao đang được sử dụng để đảm bảo độ bền.
Tại thời điểm nhập vào Rockset, bạn có thể sử dụng chuyển đổi nhập vào để chỉ định các chuyển đổi dữ liệu mong muốn để áp dụng trên dữ liệu nguồn thô của mình. Nếu sau này muốn thay đổi chuyển đổi nhập vào, bạn sẽ cần lập chỉ mục lại dữ liệu của mình.
Điều đó nói lên rằng, Rockset cho phépnhập dữ liệu không cần sơ đồ và nhập động các giá trị của mọi trường dữ liệu. Nếu kích thước và hình dạng của dữ liệu hoặc truy vấn thay đổi, Rockset sẽ tiếp tục hoạt động và không yêu cầu lập chỉ mục lại dữ liệu.
Rockset có thể mở rộng tới hàng trăm terabyte dữ liệu mà không cần phải lập chỉ mục lại. Điều này quay trở lại chiến lược sharding của Rockset. Khi điện toán mà khách hàng phân bổ trong Phiên bản ảo của họ tăng lên, một tập hợp con các phân đoạn sẽ được xáo trộn để đạt được mức phân phối tốt hơn trên toàn cụm, cho phép thực hiện truy vấn và lập chỉ mục song song hơn, nhanh hơn. Kết quả là, việc lập chỉ mục lại không cần phải xảy ra trong những trường hợp này.
Elaticsearch được thiết kế để phân tích nhật ký trong đó dữ liệu không được cập nhật, chèn hoặc xóa thường xuyên. Theo thời gian, các nhóm đã mở rộng việc sử dụng Elaticsearch, thường sử dụng Elaticsearch làm kho lưu trữ dữ liệu thứ cấp và công cụ lập chỉ mục để phân tích thời gian thực về dữ liệu giao dịch thay đổi liên tục. Đây có thể là một nỗ lực tốn kém, đặc biệt đối với các nhóm tối ưu hóa việc nhập dữ liệu theo thời gian thực cũng như liên quan đến chi phí quản lý đáng kể.
Mặt khác, Rockset được thiết kế để phân tích thời gian thực và cung cấp dữ liệu mới để truy vấn trong vòng 2 giây kể từ khi dữ liệu được tạo. Để giải quyết trường hợp sử dụng này, Rockset hỗ trợ chèn, cập nhật và xóa tại chỗ, tiết kiệm điện toán và hạn chế sử dụng việc lập chỉ mục lại tài liệu. Rockset cũng nhận ra chi phí quản lý của các trình kết nối và quá trình nhập, đồng thời áp dụng cách tiếp cận nền tảng, kết hợp các trình kết nối thời gian thực vào việc cung cấp đám mây của mình.
Nhìn chung, chúng tôi đã thấy các công ty chuyển từ Elaticsearch sang Rockset để phân tích thời gian thực đã tiết kiệm được 44% chỉ trên hóa đơn điện toán của họ. Tham gia vào làn sóng các nhóm kỹ sư chuyển từ Elaticsearch sang Rockset trong vài ngày. Bắt đầu thử nghiệm miễn phí ngay hôm nay.