Thành công phi lý
(marginalia.nu)- Marginalia Search, nhờ thay đổi gần đây, đã giảm một nửa yêu cầu RAM và giảm đáng kể gánh nặng vận hành khi trước đây phải tắt công cụ tìm kiếm trong lúc nâng cấp
- Sự cố lộ ra trong quá trình chuyển đổi chỉ mục sau bản phát hành mới nhất; kiến trúc xóa cơ sở dữ liệu URL khi nâng cấp đã dẫn đến việc ngoại tuyến trong thời gian dài
- Kho lưu trữ URL được chuyển từ mô hình tập trung vào bảng và chỉ mục MariaDB khổng lồ sang một cơ sở dữ liệu SQLite duy nhất cùng cấu trúc ID URL 64-bit do tiến trình tạo ra
- Việc tạo chỉ mục đảo được chuyển từ lexicon dùng cho term ID dày đặc và lượng ghi ngẫu nhiên lớn sang cách tạo các preindex nhỏ rồi hợp nhất
- Kiến trúc mới cho phép sao lưu bằng file để có thể khôi phục trong vài giờ ngay cả khi triển khai tệ, đồng thời giúp dễ tái sử dụng kết quả xử lý dữ liệu lớn ít thay đổi như Wikipedia
Điều kiện vận hành công cụ tìm kiếm thay đổi chỉ trong một tuần
- Marginalia Search đã giảm đồng thời nhiều vấn đề dài hạn chỉ bằng một tuần lập trình
- Yêu cầu RAM của công cụ tìm kiếm giảm một nửa
- Không còn cần đưa hệ thống ngoại tuyến trong lúc nâng cấp
- Loại bỏ giới hạn cứng về số tài liệu có thể lập chỉ mục
- Giới hạn mềm về số từ khóa có thể đưa vào corpus tăng gấp 4 lần
- Mục tiêu dài hạn là duy trì khả năng vận hành hệ thống ngay cả trên phần cứng hiệu năng thấp, và thay đổi lần này là một cải thiện lớn hơn cả cải tiến trước đó từng khiến máy phát triển 32GB RAM trở nên khá dư dả
Kiến trúc nâng cấp cũ làm sự cố trầm trọng hơn
- Marginalia Search đã ở trạng thái ngoại tuyến gần một tuần do vấn đề với bản phát hành mới nhất
- Nguyên nhân trực tiếp là chuỗi các vấn đề mở rộng tương đối nhỏ, nhưng quy trình vốn bình thường mất 1 ngày, khi có vấn đề mất 2–3 ngày, đã phải khởi động lại vài lần
- Phần lớn các lần khởi động lại là do thiếu RAM
- Lý do sự cố bộc lộ rõ với người dùng là vì hệ thống phải được đưa ngoại tuyến trong quá trình chuyển đổi chỉ mục
- Trong kiến trúc cũ, cơ sở dữ liệu URL bị xóa trong lúc nâng cấp, và thao tác chèn/cập nhật nhanh các hàng trong bảng gần 1 tỷ dòng trở thành nút thắt
- Tiến trình nạp dữ liệu mới sử dụng nhiều RAM
- Khó chạy đồng thời với dịch vụ lập chỉ mục vốn cũng dùng RAM theo cách tương tự
- Khóa chính là số nguyên 32-bit nên có giới hạn khó vượt quá 2 tỷ
Thiết kế lại cơ sở dữ liệu URL
- Cơ sở dữ liệu URL là một thành phần lâu đời của công cụ tìm kiếm, và các quyết định thiết kế ban đầu đã không còn phù hợp với kiến trúc hệ thống hiện tại
- Ở lõi có hai bảng chỉ được dùng khi nạp chỉ mục mới và chỉ được đọc bằng truy vấn khóa chính
- Bảng URL gán một ID số duy nhất cho mỗi URL
- Bảng PAGE_DATA chứa thông tin như tiêu đề và mô tả của các liên kết đã được lập chỉ mục
- Có thêm một chỉ mục để duy trì tính duy nhất của đường dẫn trong từng domain, nhưng nó rất lớn so với vai trò của nó
- Kiến trúc mới gộp hai bảng thành một cơ sở dữ liệu SQLite một bảng, để tiến trình loader chịu trách nhiệm tạo ID duy nhất, còn danh sách URL không được lập chỉ mục được xử lý bằng bảng riêng
- Cách dùng MariaDB và SQLite cùng nhau không phải lựa chọn theo thông lệ, nhưng hai kho lưu trữ đáp ứng các nhu cầu khác nhau
- Hệ thống cần một thế giới quan bền vững tương đối nhỏ
- Đồng thời phải có thể thay thế trạng thái ở quy mô terabyte theo kiểu plug-and-play
- Các bảng DOCUMENT và DOMAIN có liên hệ lỏng lẻo xuyên qua các cơ sở dữ liệu, nhưng không cần join thực sự
- Trong tình huống thảm họa, các phần quan trọng của bảng DOMAIN có thể được dựng lại từ bảng DOCUMENT
Tạo ID URL 64-bit mà không cần chỉ mục
- Bảng URL cũ dùng ID 32-bit, và trạng thái gần tràn số nguyên là một vấn đề mở rộng đã biết
- Một trong các lý do phải xóa cơ sở dữ liệu URL cũng là để tránh cột ID bị tràn
- Chỉ dùng bộ đếm đơn giản thì không xử lý được URL lặp lại, và cũng cần tránh cách giữ toàn bộ tập URL từng thấy trong bộ nhớ
- Cách mới không để cơ sở dữ liệu cấp phát ID mà tự cấu thành ID 64-bit
- 26 bit thấp dùng làm số thứ tự
- Bit 26–56 dùng làm ID tài liệu
- Các bit cao nhất được dành cho mẹo sắp xếp chỉ mục
- Cách bố trí này cho phép khoảng 67 triệu tài liệu trên mỗi domain
- Lớn gấp khoảng 10 lần Wikipedia tiếng Anh
- Cho phép tối đa 2 tỷ domain
- Gần gấp 100 lần số domain mà Marginalia từng thấy được tham chiếu ở bất kỳ đâu trên web
- Trách nhiệm đảm bảo tính nhất quán dữ liệu chuyển từ cơ sở dữ liệu sang tiến trình tạo dữ liệu, nhưng chi phí cưỡng chế ở phía đó thấp hơn nhiều
Thiết kế lại URL giúp giảm gánh nặng bộ nhớ
- Khi loại bỏ các chỉ mục khổng lồ và bảng lớn trộn lẫn dữ liệu URL nóng/lạnh, máy chủ MariaDB không còn cần 36GB RAM nữa
- Dữ liệu nóng còn lại trong MariaDB tối đa chỉ ở mức vài trăm MB, và có khả năng không cần cấp cho máy chủ quá 2GB RAM
- Dữ liệu SQLite vẫn cần chỉ mục cho khóa chính, nhưng phần chỉ mục thực sự nóng dự kiến dưới 1GB
- Lượng dữ liệu được lập chỉ mục giảm xuống còn quy mô một chữ số
- Đối tượng được lập chỉ mục là một
long64-bit duy nhất - Không có ràng buộc unique bổ sung
- Khi đầu ra của loader trở thành một bó file, việc tạo sao lưu tự động trở nên dễ hơn
- Ngay cả khi xảy ra triển khai tệ, hệ thống có thể khôi phục trong vài giờ thay vì gần một tuần như trước
Nút thắt trong việc tạo chỉ mục đảo
- Loader xuất ra cơ sở dữ liệu URL và journal tập trung vào tài liệu dạng
(document, words[]), còn tìm kiếm cần một chỉ mục đã chuyển vị sang dạng(word, documents[]) - Cách cũ dùng lexicon để ánh xạ chuỗi từ khóa sang term ID dày đặc
- Từ đầu tiên nhận ID 0, từ tiếp theo nhận ID 1
- Chuỗi được ánh xạ thành
longbằng hash 64-bit - Cấu trúc về thực chất là một hashmap mở long-to-int
- Cấu trúc này dễ đầy khi quy mô tăng lên
- Java không cho phép mảng vượt quá 2 tỷ phần tử
- Triển khai đang dùng đã bị chặn ở mức khoảng 1 tỷ phần tử
- Với 1 tỷ entry, nó dùng 12GB RAM
- Dịch vụ index đang vận hành dùng 60GB RAM, phần lớn là bộ nhớ off-heap
- Việc kích thước on-heap vượt 32GB, khiến khó dùng CompressedOOPs, cũng là một vấn đề
Khuếch đại ghi trong thuật toán chỉ mục đảo cũ
- Thuật toán cũ tìm word ID lớn nhất, tạo mảng counts có kích thước tương ứng, rồi tính vị trí tài liệu cho từng từ và ghi dữ liệu tài liệu vào file memory-mapped
- Cách này cần lexicon vì giả định miền của word ID được lấp đầy dày đặc
- Nút thắt lớn hơn là quá trình ghi khoảng 1TB dữ liệu vào file memory-mapped theo thứ tự gần như hoàn toàn ngẫu nhiên
- SSD xử lý truy cập ngẫu nhiên tốt khi đọc, nhưng với các thao tác ghi nhỏ thì phát sinh vấn đề write amplification
- SSD phải xóa và ghi lại cả một page ngay cả khi chỉ cập nhật một byte trên đĩa
- Có cache để gom các lần ghi liền kề, nhưng nó không hiệu quả với ghi ngẫu nhiên ở quy mô terabyte
- Trong lúc ghi 1TB, ổ đĩa rơi vào tình huống phải ghi khoảng 0,5PB
- Từng có biện pháp giảm nhẹ tạm thời là
RandomWriteFunnel- Trước tiên chia các lần ghi vào những bucket file nhỏ
- Sau đó ghi file lớn theo thứ tự
- Tốt hơn cách ban đầu nhưng vẫn rất chậm
Tạo các preindex nhỏ rồi hợp nhất
- Việc tạo chỉ mục đảo mới tạo nhiều chỉ mục nhỏ sao cho toàn bộ dữ liệu vừa trong bộ nhớ, rồi hợp nhất chúng
- Hợp nhất các danh sách đã sắp xếp là thao tác nhanh và cũng phù hợp với ổ cứng cơ học
- Với cách này, không còn cần lexicon
- Có thể dùng trực tiếp hash chuỗi 64-bit làm term ID
- Vấn đề ban đầu là đầu vào đã được nén và cách hợp nhất chỉ mục
- Thay vì đọc nhanh một phần đầu vào nén, tạo nhiều file nhỏ rồi đọc từng file
- Thay vì tạo chỉ mục rồi hợp nhất, hợp nhất dữ liệu trước khi tạo chỉ mục
- Abstraction mới
preindexgồm mảng ID từ, mảng count và mảng dữ liệu tài liệu - Vì đầu vào nhỏ, phần lớn preindex có thể được tạo trong RAM; sau khi commit ra đĩa trong lúc tạo, giai đoạn hợp nhất tiếp theo tạo ra preindex cuối cùng
- Preindex cuối cùng được chuyển thành chỉ mục đảo bằng cách thêm chỉ mục btree tĩnh vào bảng words và từng document block như trước, và quá trình này tương đối nhanh
Thay đổi trong vận hành và tái sử dụng dữ liệu
- Việc loại bỏ lexicon làm giảm yêu cầu RAM, và cách tạo chỉ mục đảo mới nhanh hơn thuật toán cũ
- Lexicon cũ tạo một “phương ngữ” riêng cho mỗi bó dữ liệu đã xử lý
- Cùng một từ có thể nhận một ID trong lần chạy này và một ID khác trong lần chạy khác
- Vì vậy phải xử lý toàn bộ dữ liệu cùng lúc
- Khi từ bỏ lexicon, có thể hợp nhất các bó dữ liệu khác nhau
- Có thể tái sử dụng kết quả xử lý của dữ liệu lớn và hiếm khi thay đổi như Wikipedia, rồi kết hợp với dữ liệu chỉ mục thay đổi thường xuyên hơn
- Thay đổi lần này đã giảm gần như mọi vấn đề mở rộng đã biết và bất tiện trong vận hành, đồng thời tạo điều kiện để xem xét thêm nhiều tác dụng phụ khác
2 bình luận
Marginalia - công cụ tìm kiếm DIY vận hành độc lập
Các ý kiến trên Hacker News
Thật sự rất vui khi thấy những câu chuyện thành công như thế này ở một dự án đi theo hướng hoàn toàn ngược lại với phần còn lại của thế giới
Tôi muốn gọi đó là Engildification, và cần có nhiều thứ như vậy hơn nữa
Tôi cũng thích bài Sleeping At Night, và cùng với bài “Lie Still in Bed” gần đây, nó trông như một lựa chọn cực kỳ đơn giản để khắc phục vấn đề luyện ngủ
Công cụ tìm kiếm Marginalia gần đây đã được tác giả chuyển sang làm toàn thời gian, và theo tôi biết thì quy mô đội ngũ là 1 người, nên nó ở xa nguy cơ enshittification nhất. Trái lại, chính ở quy mô như thế này các viên ngọc mới được tạo ra, và sự sáng tạo, nét độc đáo, tầm nhìn mới tỏa sáng
Bình luận này được tài trợ bởi hội “nghỉ việc bàn giấy và ra làm độc lập”
Anh ấy đã giảm một nửa mức tiêu thụ tài nguyên, làm việc năng suất hơn trước trên màn hình nhỏ hơn, và ngủ say như khúc gỗ vào ban đêm
Liên kết cho những ai quan tâm: https://www.marginalia.nu/log/86-sleep/
Nhân tiện, công cụ tìm kiếm trả phí Kagi mà có lẽ bạn từng thấy trên Hacker News dùng Marginalia làm một trong các nguồn dữ liệu
https://help.kagi.com/kagi/search-details/search-sources.htm...
Nếu dùng lens “non-commercial”, các kết quả như thế này sẽ được ưu tiên cùng với kết quả từ chỉ mục riêng của Kagi và một số nguồn độc lập
Đọc bài này khiến tôi nghĩ rằng có lẽ con người khó tạo ra những thứ xuất sắc nếu không có ràng buộc nhân tạo
Lý do Marginalia hiệu quả một cách phi lý là vì Victor cố ý giới hạn phần cứng chạy và dung lượng bộ nhớ
Nếu chỉ gắn thêm 32GiB thì có lẽ nó sẽ chạy được một thời gian, nhưng thiết kế kém hiệu quả vẫn còn đó, và sau này khi hệ thống đã phức tạp hơn, cùng vấn đề ấy có thể bùng lên và trở nên khó sửa hơn
Nếu giả định này đúng, nó cũng giải thích vì sao phần mềm ngày nay phình to, chậm chạp và nhiều lỗi. Vì từng phần mềm riêng lẻ gần như không chạm tới giới hạn, nên dù từng mảnh có kém hiệu quả, chúng vẫn liên tục vượt trước điểm phát sinh vấn đề nhờ M2 Pro đời mới và kết nối cỡ GiB
Kết luận có thể là việc tự đặt giới hạn cho mình về lâu dài sẽ tốt hơn cho chính mình và cho mọi người
Với nhiều ứng dụng, bỏ ngần ấy thời gian cho những tối ưu nhỏ là không hợp lý. Khi có thể thêm 32GiB RAM cho máy chủ với giá dưới 50 đô la, so với việc dùng hơn 40 giờ của lập trình viên với tối thiểu 20 đô la/giờ, xét theo góc độ kinh doanh thì câu trả lời quá rõ. Hơn nữa, website đã sập suốt một tuần, chỉ riêng điều đó cũng có thể giết chết phần lớn doanh nghiệp
Dân kỹ thuật thích kiểu đào sâu như vậy, muốn vi tối ưu cả những đoạn mã nhỏ nhặt trong nhiều năm, nhưng cạo lông yak vô tận thì không kiếm ra tiền. Nếu mã chỉ chạy trên một số rất ít máy, thường là không đáng. Những tối ưu kiểu này cũng hay kết thúc bằng mã khó bảo trì hơn
Tôi cho rằng sự phình to của phần mềm trong các ứng dụng chạy trên thiết bị người dùng ngày nay phần lớn đến từ sự lệch pha giữa máy của lập trình viên và máy của người dùng. Lập trình viên cần workstation mạnh để làm việc và cũng dùng nó để kiểm thử cơ bản, trong khi người dùng chạy ứng dụng trên thiết bị cách đây 5 năm vốn chỉ ở mức trung cấp hoặc thấp hơn
Nói với quản lý rằng “có thể tiết kiệm 150MB bộ nhớ” thì khó bán, nhưng nói “tiết kiệm 150MB bộ nhớ sẽ giúp hiệu năng ứng dụng với 10% người dùng tăng từ tệ hại lên vừa đủ dùng” thì có thể bán được
Trước đây người ta thật sự làm phần mềm như vậy. Nhờ thế, ngay cả những máy như Pentium 1 cũng có thể chạy tốt một hệ điều hành có hầu hết những gì ta kỳ vọng ngày nay. Ngược lại, bây giờ ngay cả smartphone có tài nguyên theo mọi trục nhiều hơn đúng nghĩa khoảng nghìn lần vẫn bị khựng khi cuộn trang web. Nhóm Word 95 luôn phải đối mặt với giới hạn và các đánh đổi về hiệu năng, và kết quả thì rõ ràng là hoặc chạy được, hoặc không chạy được
Nếu chỉ thêm RAM, họ vẫn sẽ bị kẹt trong một thiết kế kém hơn, và chẳng bao lâu lại phải mua thêm RAM nữa. Điều đáng kinh ngạc của thay đổi lần này không chỉ là giảm mức dùng tài nguyên, mà còn là nhờ RAM dư ra, cache đĩa tăng lên, khiến hệ thống năng lực hơn và nhanh hơn
[1] Ví dụ, cái này chạy trên một Pi duy nhất và vì không cho phép cập nhật nên nhanh hơn nhiều so với Wikipedia đang vận hành: https://encyclopedia.marginalia.nu/article/Hacker_News
Vì thế mà máy tính cũ từng đem lại cảm giác tốt, và game cũ cũng có thể đã tuyệt vời như vậy
Có lẽ nó liên quan đến độ phức tạp của hệ thống mà chúng ta xử lý. Khi các tài nguyên như RAM, không gian vật lý, thức ăn, vật liệu, thời gian, tiền bạc bị giới hạn, ta phải lên kế hoạch dùng chúng thế nào, và buộc phải trở nên thông minh hơn
Khi có tài nguyên gần như vô hạn, ta có thể làm theo cách mình muốn, nhưng lại ít cần bận tâm hơn đến trạng thái cuối cùng. Cứ bắt đầu rồi khi nó chạy thì xem sau
Tôi không hẳn là game thủ, nhưng luôn kinh ngạc trước khả năng của con người khi nhét được từng ấy cảm xúc, phiêu lưu và giờ chơi vào trong cartridge ROM chỉ vài KB/MB. ROM Ocarina Of Time chỉ có kích thước cỡ khoảng 8 tấm ảnh gần đây tôi chụp bằng iPhone
Raspberry Pi 2 có thể xử lý hơn 4 tỷ lệnh Dhrystone mỗi giây, còn Pi 4 thì hơn 10 tỷ mỗi giây
Dĩ nhiên, theo tiêu chuẩn hiện đại, SABRE giữa thập niên 1970 khá cơ bản đối với một hệ thống lõi của hãng hàng không, nhưng về lý thuyết, một Pi 2 duy nhất cũng có thể chạy đồng thời hơn 100 hệ thống giản lược của các hãng hàng không
Các chương trình hiện đại còn rất xa mới được tối ưu. Trừ những trường hợp nặng tính toán toán học, cải thiện 1000 lần hay 10000 lần cũng là có thể
Tôi nghĩ Microsoft gặp vấn đề này khá nặng. Ngay cả laptop 3000 đô la của 5 năm trước cũng trở nên chậm đến khó chấp nhận khi chạy đồng thời một cuộc gọi Teams, vài ứng dụng Office và trình duyệt với 30 tab
Nếu kiểm thử riêng từng thứ thì khi chỉ chạy một ứng dụng sẽ ổn, nhưng người thật không dùng như vậy
Có lẽ lời giải là đặt giới hạn nhân tạo, chẳng hạn giới hạn thời gian chạy trên phần cứng được định nghĩa rõ, và chỉ nâng giới hạn đó sau một quyết định rõ ràng
Tuy vậy, tôi chỉ viết phần mềm nghiệp vụ nơi khía cạnh hiệu năng rốt cuộc thường là “đừng làm mấy chuyện ngớ ngẩn với cơ sở dữ liệu, còn lại thì đừng bận tâm vì khách hàng không trả tiền cho nỗi lo đó”, nên có thể tôi đang nhìn sai hoàn toàn
Mỗi khi marginalia.nu có cập nhật là tôi luôn thấy vui. Đây là một người dùng quý giá trên trang này, mong bạn tiếp tục đăng
Cảm ơn. Tôi đang làm một dự án sở thích về công cụ tìm kiếm, nhưng chẳng hiểu sao cứ tìm các biến thể của “Magnolia”. Với tôi cái tên Marginalia không dễ nhớ. Hiện giờ tôi đang tìm hiểu Searx
Tôi thắc mắc liệu Marginalia có hỗ trợ tìm kiếm bằng bộ lọc thời gian như trong ngày qua, tuần qua không. Nhìn các từ khóa đặc biệt thì có vẻ tham số tìm kiếm chỉ nhận theo năm
year>2005 (beta) tài liệu có vẻ được đăng sau năm 2005
year=2005 (beta) tài liệu có vẻ được đăng trong năm 2005
year<2005 (beta) tài liệu có vẻ được đăng trước năm 2005
Bộ lọc theo năm cũng khá thô, và việc xác định chính xác ngày của hầu hết trang web là rất khó
Tôi tự hỏi câu “mỗi khi SSD cập nhật một byte đơn lẻ ở đâu đó trên đĩa, nó phải xóa và ghi lại toàn bộ trang” có thực sự đúng với SSD không
Với flash thô thì không phải vậy. Nếu ghi đè lên giá trị “trống” toàn bit 1, hoặc chỉ đổi 1 thành 0, thì có thể làm được. Ghi chậm hơn đọc vài bậc độ lớn, nhưng cũng nhanh hơn xóa vài bậc độ lớn, và ngân sách hao mòn chỉ tính việc xóa
Nếu bộ điều khiển SSD không tận dụng điều này thì nghe như tự đá phản lưới nhà. Tuy vậy, nếu bên trong thực sự là cấu trúc log thì cũng có thể không làm được
Trước đây tôi từng viết driver cho nhiều chip flash phổ biến, và tất cả các chip tôi xử lý khi đó đều chỉ dùng I/O theo trang kích thước cố định cho cả đọc lẫn ghi
SSD là một tập hợp các chip, nên tôi đoán từng chip bên trong SSD cũng chỉ hỗ trợ I/O theo trang kích thước cố định
Thông thường bộ điều khiển dùng nhiều kỹ thuật như over-provisioning, buffering, sắp xếp lại lệnh ghi để tránh các mẫu tệ nhất như vậy, nhưng vẫn có giới hạn
Đơn vị nhỏ nhất có thể ghi trên SSD là trang, còn đơn vị nhỏ nhất có thể xóa là block gồm nhiều trang
Vì vậy, dù thao tác ghi chỉ ảnh hưởng đến 1 byte trong một trang, SSD cũng không thể chỉ xóa riêng byte đó. Nhưng điều đó cũng không có nghĩa là nhất thiết phải xóa cả block
SSD có thể thực hiện kiểu thao tác “đọc-sửa-ghi”. Nó đọc toàn bộ trang chứa byte sẽ thay đổi vào bộ đệm cache của SSD, chỉ sửa byte đó trong cache trang, rồi xóa một block trống mới, ghi trang đã sửa từ cache vào block mới, và cập nhật bảng ánh xạ FTL để trỏ tới trang đã cập nhật trong block mới
Vì vậy, dù chỉ thay đổi 1 byte thì trang vẫn phải được ghi lại. Tuy nhiên có thể tránh xóa toàn bộ block cho đến khi nhiều trang trong đó bị sửa
Khi có ghi, trang sẽ di chuyển bên trong thiết bị vật lý. Bản thân ổ đĩa duy trì một bản đồ về địa chỉ nào dùng cho việc gì, tình trạng sức khỏe ra sao, v.v. Nó giống một dạng lưu trữ thưa
Cũng có các lệnh như TRIM, bảo trì định kỳ và garbage collection
Thực tế, khi ghi vào một ổ chưa đầy, nó sẽ tìm trang để chứa dữ liệu, kiểm tra xem ở đó có dữ liệu không, nếu cần thì thực hiện đọc/sửa/ghi, quyết định sẽ ghi dữ liệu ở đâu rồi ghi. Do wear leveling, khả năng cao là nó sẽ không quay lại vị trí ban đầu
Đúng là bộ điều khiển thực hiện các bước phức tạp hơn nhiều vì hiệu năng. Vì vậy một ổ mới còn trống hoạt động tốt hơn trong một thời gian, và cũng có thể thực sự chậm hơn khi là một ổ cũ đã đầy, không còn trang dự phòng
Nói thêm về nguồn, tôi từng là kỹ sư trưởng của một bộ tăng tốc flash ánh xạ bộ nhớ có tính nhất quán cache. Nó cho phép ánh xạ ổ đĩa rất hiệu quả từ user space của Linux, nhưng cuối cùng trong một thời gian chúng tôi cũng phải nhượng bộ mô hình lập trình “dễ” trông như chỉ là một ổ cứng nữa
Điều này làm tôi nhớ rằng sếp của tôi ở Mojeek có lẽ cũng đã đi một con đường rất giống. Bài viết này chạm rất nhiều tới những cuộc trò chuyện trước đây
Mojeek bắt đầu năm 2004, phần lớn khung sườn do một lập trình viên xây dựng, và gần như toàn bộ hệ thống truy hồi thông tin cùng hạ tầng cũng do người đó dựng lên
Những chuyện như ràng buộc tài chính và phần cứng, quyết định ID 32-bit hay 64-bit, sharding, tốc độ cập nhật nghe rất quen thuộc
Tôi cũng nhớ tới “Google dance” của Google ngày xưa. Khi đó kết quả tìm kiếm được cập nhật mỗi tháng một lần, còn bây giờ thì dao động hằng ngày. Tất cả đều là quá trình tiến hóa, và thật tốt khi thấy Marginalia cung cấp một góc nhìn khác về web ngoài Big Tech
Bài này đọc hay
Nhiều người xem tối ưu hóa như một thứ ma thuật đen thâm sâu, nhưng phần lớn thậm chí còn dễ hơn sửa lỗi thông thường. Chỉ cần coi việc dùng tài nguyên quá mức như một lỗi
Tôi nghĩ đa số lỗi dễ tái hiện không cần phép màu để sửa. Nếu có thể chọc vào lỗi, thường ta có thể phân loại nó, và ngay cả những khiếm khuyết thiết kế hiếm gặp, một khi tái hiện được thì phần lớn cũng sớm lộ ra
Phần mềm mà chưa ai soi xét nghiêm túc về hiệu năng giống như phần mềm có hàng trăm lỗi dễ tái hiện nhưng chưa ai debug. Bạn có thể gọt dần từng thứ trong một thời gian khá dài trước khi đụng phải điều khó
Tôi cho rằng thái độ này gần như là di sản từ thời người ta còn điều chỉnh địa chỉ đích của nhánh sao cho nó đến dưới đầu trống đúng lúc CPU cần lệnh. Khi tài nguyên bị giới hạn cực độ, mọi thứ được viết thủ công bằng assembly, và một vị trí bộ nhớ toàn cục có ý nghĩa khác nhau tùy theo giai đoạn của chương trình, thì đã có những người cực kỳ thông minh soi hiệu năng rất kỹ, nên bạn phải tìm ra thứ họ không tìm thấy. Điều đó hiếm xảy ra trong mã hiện đại
Nếu gửi yêu cầu X tới dịch vụ Y làm tái hiện lỗi, ta chỉ cần thu nhỏ dần test case cho đến khi tìm ra thủ phạm
Tối ưu hóa thường là vấn đề kiến trúc. Cũng có trường hợp đang copy dù có thể tái sử dụng buffer, nhưng những thứ như vậy nhanh chóng cạn, và profiler sẽ cho biết thông tin cần thiết
Lợi ích hiệu năng lớn thường đến từ việc thay đổi toàn bộ luồng dữ liệu, loại bỏ những phần đáng kể để mã làm việc cần làm bằng ít bước nhất có thể
Tôi tò mò vì sao lại chọn SQLite chứ không phải kho key-value. Có vẻ chỉ muốn đọc theo ID và không cần các cột khác, nên cơ sở dữ liệu quan hệ trông không cần thiết
SQLite có lợi thế là một file đơn lẻ. Vì vậy có thể làm những việc hay như sao chép hoặc chia sẻ
Tôi thích đây là một ví dụ nữa cho thấy ràng buộc sinh ra đổi mới. Đổi mới thường được tìm thấy từ giới hạn nhiều hơn là từ sự dư dả