22 thg 11, 2025·8 phút
Lucene và Hadoop của Doug Cutting: Từ tìm kiếm đến dữ liệu lớn
Cách Lucene và Hadoop của Doug Cutting biến tìm kiếm và xử lý dữ liệu phân tán thành các thành phần mã nguồn mở được các đội dữ liệu hiện đại rộng rãi sử dụng.
Cách Lucene và Hadoop của Doug Cutting biến tìm kiếm và xử lý dữ liệu phân tán thành các thành phần mã nguồn mở được các đội dữ liệu hiện đại rộng rãi sử dụng.
Lucene và Hadoop kể một câu chuyện thực dụng bất ngờ: khi bạn đã biết đánh chỉ mục thông tin để tìm kiếm nhanh, thách thức tiếp theo là xử lý lượng dữ liệu lớn hơn khả năng của một máy. Cùng nhau, chúng giúp biến “tìm kiếm” và “tính toán phân tán” từ những khả năng đắt đỏ, hẹp thành các khối xây dựng hàng ngày mà các đội có thể dùng với phần cứng thông thường.
Bài này là một lịch sử làm việc, không phải phân tích sâu về công thức điểm số hay lý thuyết hệ thống phân tán. Mục tiêu là kết nối các vấn đề người ta từng gặp, những ý tưởng đơn giản mở đường cho tiến bộ, và tại sao các ý tưởng đó vẫn xuất hiện trong công cụ hiện đại.
Apache Lucene giúp các nhà phát triển dễ dàng thêm tìm kiếm chất lượng vào ứng dụng: đánh chỉ mục văn bản, truy vấn nhanh, và lặp lại mà không phải phát minh lại mọi thứ.
Apache Hadoop giải quyết một nỗi đau khác: tổ chức thu thập logs, clickstream và tập dữ liệu quá lớn để nằm gọn trên một máy chủ. Hadoop cung cấp cách lưu trữ dữ liệu trên nhiều máy (HDFS) và chạy các job batch trên đó (MapReduce) mà không phải tự tay xây dựng một hệ thống phân tán từ đầu.
Trước các dự án này, nhiều đội phải chọn: mua hệ thống độc quyền đắt tiền hoặc chấp nhận quy trình chậm và thủ công. Lucene và Hadoop hạ rào cản đó.
Bạn sẽ thấy những vấn đề tồn tại trước Lucene và Hadoop là gì, tại sao công việc của Doug Cutting lại cộng hưởng với người làm, và các ý tưởng được kết nối thế nào — từ đánh chỉ mục tài liệu đến điều phối cụm máy.
Cuối cùng, bạn sẽ hiểu được tác động kéo dài: ngay cả khi stack của bạn dùng Elasticsearch, Spark, lưu trữ đối tượng trên cloud, hoặc dịch vụ quản lý, nhiều khái niệm lõi vẫn lần theo về những gì Lucene và Hadoop làm thành xu hướng.
Doug Cutting là một trong những kỹ sư hiếm hoi có công việc định hình hai công cụ “mặc định” khác nhau cho các đội dữ liệu hiện đại: Apache Lucene cho tìm kiếm, và Apache Hadoop cho xử lý dữ liệu phân tán. Mặc dù cả hai dự án lớn hơn bất kỳ cá nhân nào, các quyết định kỹ thuật ban đầu của Cutting và cam kết của ông với cộng tác mã nguồn mở đã định hướng phát triển.
Chủ đề nhất quán của Cutting là sự dễ tiếp cận. Lucene biến tìm kiếm chất lượng cao thành một thư viện bạn có thể nhúng vào ứng dụng, thay vì một hệ thống chuyên dụng chỉ công ty lớn mới đủ sức xây. Sau này, Hadoop hướng tới khiến lưu trữ và tính toán quy mô lớn khả thi trên cụm máy bình thường, không chỉ phần cứng độc quyền đắt tiền.
Động lực đó quan trọng: không phải là “dữ liệu lớn cho dữ liệu lớn”, mà là thúc đẩy để đưa năng lực mạnh mẽ đến các đội nhỏ hơn với ngân sách hạn chế.
Cả Lucene và Hadoop phát triển dưới Apache Software Foundation, nơi các quyết định được đưa ra công khai và quyền lực được xây dựng qua đóng góp. Mô hình đó khuyến khích luồng cải tiến liên tục: sửa lỗi, tối ưu hiệu năng, tài liệu, và phản hồi thực tế từ công ty và trường đại học.
Đóng góp cá nhân của Cutting mạnh nhất ở giai đoạn đầu: kiến trúc ban đầu, các triển khai đầu tiên, và uy tín để thu hút người đóng góp. Khi mức độ áp dụng mở rộng, cộng đồng (và sau này nhiều công ty) thúc đẩy các bổ sung lớn: tính năng mới, tích hợp, công việc mở rộng quy mô, và công cụ vận hành.
Cách hữu ích để nghĩ: Cutting tạo ra “phiên bản đầu tiên hoạt động” và văn hóa xung quanh; cộng đồng mã nguồn mở biến những ý tưởng đó thành hạ tầng bền vững.
Trước Lucene, tích hợp “tìm kiếm” vào sản phẩm thường có nghĩa là xây một dự án nghiên cứu nhỏ. Nhiều đội phải mua phần mềm độc quyền đắt hoặc ghép nối các giải pháp tự chế khó tinh chỉnh, khó mở rộng và dễ sai.
Tìm kiếm không chỉ là tìm nơi một từ xuất hiện. Nó là về tốc độ, xếp hạng và xử lý văn bản đời thực lộn xộn. Nếu bạn muốn người dùng gõ “running shoes” và nhận được kết quả hữu ích trong mili giây, bạn cần các cấu trúc dữ liệu và thuật toán chuyên biệt — cộng với kỹ thuật cẩn thận để giữ việc đánh chỉ mục, cập nhật và truy vấn ổn định.
Một index giống như mục lục ở cuối sách, nhưng cho tất cả tài liệu của bạn: thay vì quét từng trang, bạn tra một thuật ngữ và nhảy thẳng tới nơi nó xuất hiện. Không có index, tìm kiếm trở nên chậm vì bạn thực chất đọc lại mọi thứ cho mỗi truy vấn.
Relevance là cách bạn quyết định hiển thị cái gì trước. Nếu 10.000 tài liệu khớp “shoes”, relevance trả lời: 10 cái nào nên xuất hiện ở trang đầu? Nó phụ thuộc vào tín hiệu như tần suất thuật ngữ, vị trí xuất hiện (tiêu đề so với thân bài), và độ hiếm của thuật ngữ trong toàn bộ tập hợp.
Khi các trang web và danh mục trực tuyến tăng theo cấp số nhân, “đủ tốt” không còn đủ. Người dùng mong kết quả nhanh, có chịu lỗi chính tả và xếp hạng hợp lý. Công ty không cung cấp được điều đó mất tương tác và doanh thu.
Một thư viện tái sử dụng có nghĩa là đội không phải phát minh lại việc đánh chỉ mục và xếp hạng từ đầu. Nó giảm chi phí xây dựng tìm kiếm tốt, khiến thực hành tốt trở nên chia sẻ được, và cho phép dev tập trung vào nhu cầu riêng của sản phẩm thay vì giải lại cùng một vấn đề lõi.
Lucene khiến “tìm kiếm” cảm giác như một tính năng bạn có thể thêm vào sản phẩm, không phải dự án nghiên cứu phải phát minh lại. Về cốt lõi, đó là một thư viện giúp phần mềm biến văn bản lộn xộn thành thứ bạn có thể tìm nhanh và nhất quán.
Lucene tập trung vào bốn công việc thực dụng:
Lucene phù hợp cho nhu cầu tìm kiếm hàng ngày:
Sức hút của Lucene không phải phép màu — mà là tính thực dụng:
Lucene không chỉ giải một bài toán cho một công ty; nó trở thành lớp nền đáng tin cậy mà nhiều ứng dụng và dịch vụ tìm kiếm xây dựng trên. Nhiều công cụ sau này vay mượn cách Lucene đánh chỉ mục và xếp hạng — hoặc dùng Lucene trực tiếp làm engine bên dưới.
Logs tìm kiếm, clickstream, kho lưu trữ email, dữ liệu cảm biến và trang web đều có một đặc tính: chúng tăng nhanh hơn các server bạn mua năm ngoái. Khi các đội bắt đầu lưu “mọi thứ”, tập dữ liệu không còn vừa vặn trên một máy — không chỉ ở khả năng lưu trữ mà còn ở thời gian để xử lý.
Phản ứng đầu tiên là scale up: nhiều CPU, nhiều RAM, đĩa to hơn. Cách này hiệu quả… cho đến lúc không.
Server cao cấp trở nên rất đắt, và giá tăng không tỉ lệ thuận. Bạn còn đặt cược toàn bộ pipeline vào một máy. Nếu nó hỏng, mọi thứ sập. Ngay cả khi không hỏng, có giới hạn vật lý: ổ đĩa chỉ quay nhanh thế, bộ nhớ có trần, và vài workload đơn giản là không thể hoàn thành kịp khi dữ liệu liên tục nhân đôi.
Scale out đổi cách tiếp cận. Thay vì một máy mạnh, bạn dùng nhiều máy thường và chia công việc.
Mô hình giúp hình dung: ngày chuyển thư viện — một người bê những thùng nặng nhất, nhưng mười người bê thùng nhỏ hơn xong nhanh hơn—và nếu một người mệt, những người còn lại vẫn làm tiếp. Xử lý dữ liệu phân tán áp dụng cùng ý tưởng cho lưu trữ và tính toán.
Dùng nhiều máy giá rẻ đưa ra giả định mới: luôn có gì đó hỏng. Ổ đĩa chết, mạng chập chờn, node khởi động lại.
Vì vậy mục tiêu là hệ thống kỳ vọng thất bại và vẫn chạy — bằng cách lưu nhiều bản sao dữ liệu, theo dõi phần việc đã xong, và tự động chạy lại các phần bị ngắt. Áp lực này — dữ liệu lớn hơn một máy cộng với thực tế lỗi thường xuyên ở quy mô — tạo nền tảng cho cách tiếp cận của Hadoop.
Hadoop dễ hiểu nhất qua hai cam kết đơn giản: lưu trữ dữ liệu rất lớn trên nhiều máy bình thường và xử lý dữ liệu đó song song. Hai cam kết hiện diện trong hai phần lõi: HDFS cho lưu trữ và MapReduce cho xử lý.
HDFS (Hadoop Distributed File System) chia file quá lớn cho một máy thành các block kích thước cố định (tưởng tượng như “miếng ghép”). Các block đó được phân tán trên nhiều máy trong cụm.
Để giữ dữ liệu an toàn khi một máy hỏng, HDFS còn lưu bản sao của mỗi block trên máy khác nhau. Nếu một máy chết, hệ thống vẫn đọc được file từ bản sao khác—không cần bạn đi tìm backup.
Kết quả thực tế: một thư mục trong HDFS cư xử như một folder bình thường, nhưng phía sau được ghép từ nhiều đĩa.
MapReduce là mô hình lập trình cho xử lý batch. Nó có hai giai đoạn tên gọi:
Ví dụ cổ điển là đếm từ trên terabyte log: mapper đếm từ trong phần dữ liệu của nó; reducer cộng tổng cho từng từ.
HDFS + MapReduce khiến chạy job batch lớn — phân tích log, pipeline đánh chỉ mục, tổng hợp clickstream, dọn dẹp dữ liệu — trên tập dữ liệu vượt xa một máy trở nên thực tế. Thay vì mua một máy khổng lồ, đội có thể thêm máy giá rẻ và để Hadoop điều phối lưu trữ, thử lại và thực thi song song.
Lucene và Hadoop có thể trông như hai chương riêng — một về tìm kiếm, một về “dữ liệu lớn”. Nhưng chúng chia sẻ tư duy chung: xây công cụ thực dụng mà đội thực tế có thể chạy, mở rộng và tin cậy, thay vì công bố prototype thông minh rồi bỏ đi.
Lucene tập trung làm vài việc khó thật tốt — đánh chỉ mục, truy vấn, xếp hạng — đóng gói như một thư viện dev có thể nhúng ở đâu cũng được. Lựa chọn đó dạy một bài học: khi một công cụ dễ tích hợp, dễ gỡ lỗi và có tài liệu tốt, nó lan rộng vượt ra ngoài trường hợp sử dụng ban đầu.
Hadoop áp dụng triết lý tương tự cho xử lý phân tán: thay vì yêu cầu phần cứng chuyên biệt, nó nhắm chạy trên máy thường và giải bài toán hàng ngày: lưu trữ và xử lý dữ liệu không còn vừa trên một máy.
Nếu dữ liệu của bạn rất lớn, sao chép nó qua mạng về một máy mạnh là như cố mang mọi cuốn sách trong thư viện đến một cái bàn chỉ để tìm trích dẫn. Cách của Hadoop là đưa công việc tới nơi dữ liệu đang nằm: gửi code nhỏ đến nhiều máy, mỗi máy xử lý lát cắt cục bộ, rồi gom kết quả.
Ý tưởng này phản chiếu đánh chỉ mục: bạn tổ chức dữ liệu nơi nó sống (index) để truy vấn không phải quét mọi thứ nhiều lần.
Cả hai dự án hưởng lợi từ hợp tác mở: người dùng báo lỗi, gửi sửa, chia sẻ kiến thức vận hành. Những yếu tố quyết định khiến chúng lan rộng thường là không hào nhoáng nhưng then chốt — tài liệu rõ ràng, khả năng di chuyển giữa môi trường, và quản trị kiểu Apache khiến công ty yên tâm đầu tư thời gian và nhân lực mà không lo bị khóa nhà cung cấp.
Hadoop không lan tỏa vì các đội muốn “dữ liệu lớn”. Nó lan tỏa vì vài công việc phổ biến trở nên quá đắt và không đáng tin trên máy đơn và cơ sở dữ liệu truyền thống.
Xử lý log là thành công sớm. Web server, app và thiết bị mạng tạo lượng lớn bản ghi append-only. Các đội cần tổng hợp hàng ngày (hoặc hàng giờ): lỗi theo endpoint, phần trăm độ trễ, traffic theo vùng, referrer hàng đầu. Hadoop cho phép họ đẩy log thô vào HDFS và chạy job định kỳ để tóm tắt.
Phân tích clickstream theo sau. Nhóm sản phẩm muốn hiểu hành trình người dùng — họ nhấn gì trước khi chuyển đổi, điểm bỏ cuộc, cohort hành xử ra sao theo thời gian. Dữ liệu này lộn xộn và khối lượng lớn, giá trị thường đến từ tổng hợp lớn hơn lookup đơn lẻ.
ETL trở thành một trường hợp cốt lõi. Dữ liệu tản mác trong DB, file và xuất từ bên thứ ba. Hadoop cung cấp nơi chính để hạ dữ liệu thô, biến đổi ở quy mô và xuất ra kết quả tinh chỉnh cho kho dữ liệu hoặc hệ thống hạ nguồn.
Phần lớn workflow này là batch: bạn thu thập dữ liệu trong một cửa sổ (ví dụ mỗi giờ hoặc mỗi ngày), rồi xử lý như một job có thể mất phút hoặc giờ. Batch tốt khi câu hỏi là về xu hướng và tổng, không phải phản hồi tức thời cho từng người dùng.
Trong thực tế, Hadoop phục vụ báo cáo qua đêm, dashboard định kỳ, và tính toán lại lớn (“chạy lại năm ngoái với logic mới”). Nó không thiết kế cho khám phá tương tác sub-second.
Lợi thế lớn là chi phí xử lý rẻ hơn: scale out với phần cứng commodity thay vì scale up trên một máy đắt. Một lợi ích nữa là độ tin cậy nhờ dư thừa. HDFS lưu nhiều bản sao block, nên lỗi node không đồng nghĩa mất dữ liệu hoặc phải bắt đầu lại từ đầu.
Stack Hadoop ban đầu có thể chậm cho truy vấn tương tác, đặc biệt so với DB thiết kế cho đọc nhanh.
Nó cũng đưa vào độ phức tạp vận hành: quản lý cụm, lập lịch job, định dạng dữ liệu, và gỡ lỗi lỗi trên nhiều máy. Việc áp dụng thường thành công khi đội có workload batch rõ ràng và kỷ luật chuẩn hóa pipeline — thay vì cố ép Hadoop làm mọi thứ.
Lucene và Hadoop giải các vấn đề khác nhau, và chính vì thế chúng hợp nhau.
Lucene là về truy xuất nhanh: nó xây index để bạn tìm văn bản và trường có cấu trúc nhanh chóng (nghĩ “tìm 200 event liên quan nhất cho truy vấn này, ngay lập tức”).
Hadoop là về làm việc với file lớn trên nhiều máy: nó lưu dataset lớn tin cậy trong HDFS và xử lý song song (lịch sử với MapReduce) để biến đổi, tổng hợp và enrich dữ liệu quá lớn cho một server.
Nói ngắn gọn: Hadoop chuẩn bị và crunch dữ liệu; Lucene biến kết quả thành thứ dễ khám phá.
Giả sử bạn có hàng tháng log ứng dụng thô.
Bạn có cả hai lợi thế: xử lý batch quy mô trên dữ liệu thô, và tìm kiếm tương tác để điều tra và báo cáo.
Analytics trả lời “tổng quan đã xảy ra gì?” trong khi tìm kiếm giúp “cho tôi thấy bằng chứng cụ thể.” Hadoop giúp tính toán các dataset phái sinh từ đầu vào khổng lồ; Lucene làm cho các dataset đó có thể tìm và duyệt—biến đống file thành thứ người dùng có thể điều hướng.
Cặp này không bắt buộc. Nếu dữ liệu của bạn vừa vặn trong một DB, hoặc dịch vụ managed đã đáp ứng nhu cầu tìm kiếm và phân tích, nối Hadoop + Lucene có thể thêm gánh nặng vận hành. Dùng kết hợp khi bạn thực sự cần cả hai: xử lý quy mô lớn và khám phá nhanh, linh hoạt.
Hadoop không chỉ cung cấp cách xử lý file lớn; nó khiến nhiều tổ chức nghĩ theo hướng nền tảng dữ liệu dùng chung. Thay vì xây hệ thống riêng cho mỗi dự án phân tích, các đội có thể hạ dữ liệu thô một lần, lưu rẻ và cho nhiều nhóm tái dùng theo thời gian.
Khi HDFS-style storage và xử lý batch trở nên quen thuộc, một mẫu xuất hiện: tập trung dữ liệu, rồi xếp lớp khả năng lên trên. Sự chuyển đổi này khuyến khích tách rõ ràng giữa:
Đây là thay đổi khái niệm nhiều như kỹ thuật. Nó đặt kỳ vọng rằng hạ tầng dữ liệu nên tái sử dụng, có quản trị và truy cập xuyên đội.
Động lực cộng đồng theo sau: người ta muốn cách dễ hơn để truy vấn dữ liệu, nạp nó đáng tin cậy và chạy workflow định kỳ. Ở mức cao, điều đó thúc đẩy sự xuất hiện của:
Khi nhiều công cụ kết nối vào cùng một nền tảng, chuẩn hóa trở thành keo gắn kết. Định dạng file chung và mẫu lưu trữ giúp dữ liệu dễ trao đổi giữa engine và nhóm. Thay vì viết lại pipeline cho mọi công cụ, tổ chức có thể thống nhất vài định dạng và quy ước thư mục — và nền tảng trở nên lớn hơn tổng các phần.
Những năm đỉnh cao của Hadoop định nghĩa bởi job batch lớn: copy data vào HDFS, chạy MapReduce qua đêm, rồi xuất kết quả. Mô hình đó không biến mất, nhưng nó ngừng là mặc định khi kỳ vọng chuyển sang “trả lời ngay” và “cập nhật liên tục”.
Các đội bắt đầu chuyển từ pure batch sang pipeline streaming và gần-thời-gian-thực. Thay vì chờ chạy MapReduce hàng ngày, hệ thống bắt đầu xử lý sự kiện khi chúng đến và cập nhật dashboard hoặc cảnh báo nhanh.
Cùng lúc, engine tính toán mới giúp phân tích tương tác khả thi. Các framework tối ưu cho xử lý trong bộ nhớ và thực thi truy vấn thường vượt trội MapReduce cổ điển cho công việc lặp, phân tích tương tác và truy vấn SQL.
Lưu trữ cũng thay đổi. Nhiều tổ chức chuyển từ “HDFS là trung tâm vũ trụ” sang lưu trữ đối tượng cloud như một lớp dữ liệu chung rẻ hơn, đơn giản hơn. Compute trở nên dễ sinh, bật lên khi cần và tắt khi xong.
Một số thành phần gắn nhãn Hadoop giảm độ phổ biến, nhưng ý tưởng lan rộng khắp nơi: lưu trữ phân tán, đưa tính toán gần dữ liệu, chịu lỗi trên phần cứng commodity, và tư duy “data lake”. Dù công cụ thay đổi, mô hình kiến trúc trở thành bình thường.
Lucene không trải qua cùng chu kỳ lên/xuống vì nó là thư viện lõi nhúng trong các stack tìm kiếm hiện đại. Elasticsearch, Solr và các giải pháp khác vẫn dựa trên Lucene cho đánh chỉ mục, scoring và phân tích truy vấn — các năng lực tiếp tục trung tâm cho tìm kiếm, observability và khám phá sản phẩm.
Hadoop dưới dạng một nền tảng đóng gói ít phổ biến hơn nay, nhưng nền tảng tư duy nó mang tới đã định hình kỹ thuật dữ liệu hiện đại. Lucene tiếp tục cung cấp năng lực cho ứng dụng nặng về tìm kiếm, ngay cả khi nó được gói trong dịch vụ và API mới.
Bạn không cần xây hệ thống “dữ liệu lớn” để hưởng lợi từ các ý tưởng Lucene và Hadoop. Phần hữu ích là biết bạn đang giải quyết vấn đề nào: tìm nhanh (search) hay xử lý nhiều dữ liệu hiệu quả (batch/compute).
Nếu người dùng (hoặc công cụ nội bộ) cần gõ truy vấn và nhận kết quả liên quan nhanh — theo từ khóa, cụm, bộ lọc và xếp hạng — bạn đang ở lãnh vực đánh chỉ mục tìm kiếm. Đó là nơi Lucene tỏa sáng.
Nếu mục tiêu là crunch khối lượng lớn dữ liệu để tạo aggregate, feature, export, báo cáo hoặc transform — thường theo lịch — bạn đang ở lãnh vực xử lý batch. Đây là vấn đề Hadoop chuẩn hóa.
Một heuristic nhanh:
Trước khi chọn công cụ, thử đặt các câu hỏi:
Nếu đang khám phá, việc đối chiếu nhu cầu với các pattern phổ biến và đánh đổi sẽ giúp chọn shortlist rõ ràng hơn; nếu cân nhắc managed vs self-hosted, so sánh trách nhiệm vận hành cùng chi phí trên trang pricing thường hữu ích hơn danh sách tính năng.
Bài học thực tế từ thời Lucene/Hadoop là đội thắng khi biến các “ý tưởng hạ tầng” thành sản phẩm hoạt động nhanh. Nếu bạn đang prototype trình khám phá log nội bộ, ứng dụng tìm kiếm tài liệu, hoặc dashboard phân tích nhỏ, một nền tảng vibe-coding như Koder.ai có thể giúp bạn đến một ứng dụng end-to-end dùng được nhanh hơn: React phía frontend, backend Go với PostgreSQL, và giao diện lặp bằng chat.
Điều đó đặc biệt hữu ích khi bạn còn đang xác thực yêu cầu (trường, bộ lọc, retention và UX). Tính năng như planning mode, snapshots và rollback làm cho thử nghiệm ban đầu ít rủi ro hơn — trước khi bạn cam kết vào những lựa chọn vận hành nặng hơn như chạy cluster hay tuning stack tìm kiếm.
Lucene và Hadoop trở nên phổ biến không phải vì phép màu, mà vì chúng đóng gói các nguyên thủy tái sử dụng — đánh chỉ mục và xử lý phân tán — thành các khối xây dựng mà các đội có thể áp dụng, mở rộng và chia sẻ qua mã nguồn mở.
Lucene là một thư viện tìm kiếm giúp xây dựng một index để bạn có thể truy xuất các tài liệu phù hợp nhanh chóng mà không phải quét toàn bộ nội dung mỗi lần. Nó còn cung cấp những thành phần thực dụng bạn cần trong sản phẩm thực tế: analyzers (cách tách từ), phân tích truy vấn, và tính điểm relevance.
Hadoop giải quyết điểm mà “mua server lớn hơn” không còn hiệu quả. Nó cho phép bạn lưu trữ tập dữ liệu lớn trên nhiều máy và chạy xử lý batch song song trên chúng, đồng thời xử lý lỗi máy bằng cơ chế thử lại và sao chép để đảm bảo độ bền.
Index là một cấu trúc dữ liệu ánh xạ các thuật ngữ (hoặc token) tới những tài liệu/trường mà chúng xuất hiện — tương tự như mục lục ở cuối sách.
Về mặt thực tế: việc đánh chỉ mục là công việc bạn làm một lần trước để truy vấn của người dùng có thể trả kết quả trong mili giây thay vì phải đọc lại mọi thứ.
Relevance là cách một công cụ tìm kiếm quyết định kết quả phù hợp nào nên xuất hiện trước.
Các tín hiệu phổ biến bao gồm:
Nếu bạn xây dựng tìm kiếm sản phẩm, hãy dành thời gian để tinh chỉnh relevance (boost field, analyzer, synonym) thay vì coi đó là chuyện phụ.
HDFS (Hadoop Distributed File System) chia các file lớn thành các block kích thước cố định và phân phối chúng trên một cụm máy. Nó còn sao chép các block đó lên nhiều máy khác nhau để dữ liệu vẫn truy cập được ngay cả khi một node hỏng.
Về mặt vận hành, bạn dùng nó như một hệ thống file, còn Hadoop đảm nhiệm việc đặt chỗ lưu và đảm bảo độ bền ở đằng sau.
MapReduce là một mô hình lập trình batch gồm hai giai đoạn chính:
Dùng khi công việc của bạn mang tính "quét toàn bộ, tính tóm tắt, ghi kết quả"—ví dụ tổng hợp log lớn hoặc chạy backfill.
“Move computation to data” nghĩa là gửi các đoạn code nhỏ tới những máy đã lưu trữ dữ liệu đó, thay vì sao chép toàn bộ dataset qua mạng về một nơi để xử lý.
Cách làm này giảm tắc nghẽn mạng và mở rộng tốt hơn khi dữ liệu tăng—đặc biệt phù hợp cho các workload batch lớn.
Một mô hình phổ biến là:
Sự tách biệt này giữ cho việc xử lý nặng và khám phá tương tác không chen lấn lên nhau.
Các chiến thắng đầu tiên là dữ liệu append-heavy có khối lượng lớn và giá trị thu được từ tổng hợp:
Những workflow này thường là batch: độ trễ vài phút/giờ là chấp nhận được.
Bắt đầu từ yêu cầu, sau đó chọn công cụ đơn giản nhất phù hợp:
Kiểm tra độ trễ, quy mô và tốc độ tăng dữ liệu, mô hình cập nhật, hình dạng truy vấn và năng lực vận hành trước khi quyết định. Nếu bạn cần các so sánh liên quan, đọc các bài trên trang blog; nếu cân nhắc managed vs self-hosted, so sánh trách nhiệm vận hành trên trang pricing thường sáng tỏ hơn là chỉ nhìn tính năng.