Phân trang kiểu from/size càng lật sâu càng đắt, và Elasticsearch chặn cứng ở from=10000 với một lỗi. Bài này đo thật trên es-lab với 500.000 bản ghi: from/size tăng từ 12ms lên 30ms khi lật sâu rồi báo lỗi ở 10.000, còn search_after nhảy tới bất kỳ vị trí nào (kể cả gần cuối) chỉ 2-14ms và không giới hạn. Khi nào dùng từng cái.
Số shard là quyết định kiến trúc quan trọng nhất của một index Elasticsearch — và khó sửa nhất. Bài này đo thật trên es-lab: nạp 200.000 tài liệu với 1 shard mất 1.310ms, với 3 shard chỉ 674ms (ghi song song). Document được băm rải đều ~66k mỗi shard. Và trung thực về replica: trên single-node nó UNASSIGNED, cluster yellow — vì sao cần nhiều node.
Người dùng gõ sai chính tả và gõ dở chừng — hai bài toán tìm gần đúng, hai giải pháp. Bài này đo thật trên es-lab: fuzzy query với Levenshtein distance cho 'elasticsrch' (thiếu chữ) vẫn ra 'elasticsearch', và edge_ngram cho autocomplete gõ 'ela' ra gợi ý ngay trong 0ms. Kèm đánh đổi: edge_ngram index lớn hơn 5 lần nhưng tìm cực nhanh.
Mười một bài, mười một phép đo thật trong Docker. Bài tổng kết này nối tất cả thành một bảng số liệu và một checklist thực chiến: Elasticsearch giỏi gì (tìm toàn văn nhanh hơn LIKE, aggregation 1 triệu bản ghi trong 28ms, bulk 74k doc/giây), không giỏi gì (transaction, JOIN, đếm chính xác), và những cạm bẫy đo được cần tránh.
Đệ quy ngây thơ tính Fibonacci gọi hàm 3,67 tỉ lần cho fib(45) và mất gần 3 giây — vì nó tính đi tính lại cùng một giá trị. Bài này đo thật trong go-lab: thêm một mảng nhớ (memoization) biến O(2^n) thành O(n), nhanh hơn ~4 triệu lần, và giải được fib(90) trong 667 ns. Kèm so sánh memoization với tabulation và đánh đổi bộ nhớ.
Nhiều database khóa hàng khi đọc để tránh đọc dở dang — PostgreSQL thì không, nhờ MVCC. Bài này đo thật với hai phiên psql đồng thời: khi phiên A UPDATE balance=999 chưa commit, phiên B vẫn đọc được balance=100 (bản cũ) mà không bị chặn. Xem metadata ẩn xmin/xmax/ctid để hiểu vì sao UPDATE tạo phiên bản mới thay vì sửa tại chỗ.