 how to love Show
to love god love to play to find love is to love to make love Thiền sư Thích Nhất Hạnh nói: “Thấu hiểu nỗi đau của người khác là món quà to lớn nhất mà bạn có thể trao tặng họ. Thấu hiểu là tên gọi khác của yêu thương. Nếu bạn không thể thấu hiểu, thì bạn chẳng thể yêu thương” “Hành động bất bạo động được sinh ra từ nhận thức về đau khổ, được nuôi dưỡng bởi tình thương, và chính là cách hiệu quả nhất để đối đầu với nghịch cảnh” “Mỗi người chúng ta nên tự hỏi mình: Tôi thật sự muốn gì? Trở thành người thành công số 1? Hay đơn giản là người hạnh phúc? Để thành công, bạn có thể phải hi sinh hạnh phúc của mình. Bạn có thể trở thành nạn nhân của thành công, nhưng bạn không bao giờ là nạn nhân của hạnh phúc” “Ta và Đất Mẹ không phải là hai thực tại riêng biệt. Đất Mẹ chính là ta, ta là đất Mẹ. Đất Mẹ không phải chỉ là môi trường” “Hãy bước đi như thể bạn đang hôn trái đất bằng bàn chân của mình” “Con đã được biểu hiện từ đất mẹ, con sẽ trở về đất mẹ để tiếp tục được biểu hiện hàng triệu lần nữa, để cùng với tăng thân con làm công việc chuyển rác thành hoa, bảo hộ sự sống và xây dựng một tịnh độ ngay trên mặt đất này” “Sinh và diệt chỉ là những hiện tượng mà ta nhìn thấy trên bề mặt. Nếu ta nhìn thật sâu thì không có sinh cũng không có diệt, chỉ có sự tiếp nối không ngừng. Khi ta tiếp xúc được với bản chất không sinh không diệt thì ta không còn lo sợ cái chết” 1. Thơ 2. Văn 3. Nghiên cứu Phê bình 4. Vấn đề hôm nay 5. Thư bạn đọc 6. Tư liệu 7. Văn học Miền Nam 54-75 Chào các bạn, trong chuỗi nghiên cứu của mình về Blockchain, có một bài viết khá thú vị về Database mà mình nghĩ nên chia sẽ ở đây, mong nhận đc nhiều cmt và kip, xin cám ơn. Link bài viết gốc The Lightning DatabaseKhi khởi động một dự án, ở giai đoạn thiết kế tổng thể cấu trúc hệ thống, khâu quyết định công cụ lưu trữ dữ liệu thường bị xem nhẹ và diễn ra cũng rất nhanh gọn. Chúng ta mặc định trong đầu những lựa chọn khá hạn chế xung quanh SQL / NoSQL, và ko nghĩ rằng sự lựa chọn đó đòi hỏi phức tạp hay khó khăn. MySQL, MsSQL, MongoDb, SQL Lite, Redis.. cứ thế mà pick, gần như chỉ dựa trên yếu tố "quen tay". Liệu có một lúc nào đó, khi không có áp lực nào thúc ép, tính hiếu kỳ có gây cảm hứng cho một lập trình viên bình thường suy nghĩ về CSDL (Database) theo cách khác thường? Computer là cỗ máy có nhiều loại bộ nhớ và nơi lưu trữ khác nhau, vậy những MySQL, Redis, Mongodb mà chúng ta vẫn hay sử dụng lưu dữ liệu ở đâu? Trên Disk, trên RAM, hay.. CPU Cache-Mem? 1. Computer Memory & StorageTính hiếu kỳ, đối với lập trình viên có thể ko giúp ích nhiều trong công việc thường nhật, nhưng theo tôi thì nó cần thiết để trở thành lập trình viên ko-bất-tài. Hôm nay tính hiếu kỳ với cụm từ "Single-level Store" thôi thúc tôi tìm hiểu bản chất công nghệ lưu trữ của computer. Computer có những hình thức lưu trữ nào?Đa phần tài liệu nghiên cứu về khoa học máy tính đều cho rằng Computer có 2 vùng lưu trữ chính là Main Memory và Secondary Storage, tiếng Việt: "bộ nhớ" và "kho lưu trữ".
Những chíp vi xử lý mới còn có thêm bộ nhớ đệm (L1-L2-L3 Cache) cũng làm phần việc tương tự như Main Memory tuy nhiên dung lượng của Cache Mem rất nhỏ và ko nằm trong tầm quan sát/kiểm sát của người sử dụng. Ảnh trên là một "bộ nhớ" đời đầu của Computer, còn được nhớ đến với tên gọi Magnetic Drum. Vậy dữ liệu được lưu ở đâu?RAM hay Disk đều có thể trở thành nơi lưu trữ dữ liệu, ltv có toàn quyền lựa chọn địa điểm lưu trữ, định dạng dữ liệu, và cả cách thức lưu trữ. Chọn Ram hay Disk, đều có những ưu điểm, nhược điểm riêng, tốc độ thường đi đôi với rủi ro và chi phí. Vì giá thành quá cao so với Disk Storage và tính chất "Volatile" (Ko có điện, mất hết data) của RAM, nên dữ liệu thường được ưu tiên lưu trên Disk, phần dữ liệu sử dụng thường xuyên hoặc cần thiết để thực thi tiến trình (process) thì lưu trên RAM. Ngay cả trong lĩnh vực database, đa số hệ quản trị dữ liệu (DBMS) cũng chọn Disk làm nơi lưu trữ và dùng RAM để thực thi chương trình, vẫn là lý do Price & Volatile. Cũng có một số DBMS hoạt động hoàn toàn trên RAM và tự tin rằng với hạ tầng thông tin hiện tại, Volatile ko còn là vấn đề nữa mà chỉ tồn tại lý do duy nhất để ko lưu data trên RAM, là Price mà thôi. Tuy nhiên có thể ko phải ai cũng biết, còn có một cách lưu trữ ít nổi tiếng hơn, sử dụng cả RAM lẫn Disk để phục vụ cho công việc đọc/ghi dữ liệu. Cách lưu trữ đó có nguồn gốc từ Virtual Memory và Single-Level Store Concepts, mà sau đây chúng ta sẽ tìm hiểu. 2. Virtual Memory ConceptNhững năm 40-50, chính vì hạn chế về dung lượng Memory, lập trình viên khi đó phải đảm nhiệm một công việc quan trọng: tính toán và lập trình các bước luân chuyển của dữ liệu giữa 2 cấp bộ nhớ là Memory và Storage. Công việc này chủ yếu là chia bộ nhớ ra thành từng blocks (về sau gọi là segments và pages), và tính toán kế hooạch di chuyển những block này giữa 2 cấp bộ nhớ (swap / overlay works). Để tăng hiệu suất sử dụng của bộ nhớ và tận dụng tốt hơn nguồn tài nguyên của computer, các nhà khoa học máy tính đã nỗ lực tìm cách xoá đi ranh giới phân biệt giữa 2 cấp bộ nhớ này, và công nghệ được tạo ra sau cùng là Virtual Memory - phát minh quan trọng bậc nhất trong ngành KHMT. Lý thuyết bộ nhớ ảoNăm 1956, nhà Vật Lý học người Đức Fritz-Rudolf Güntsch, trong luận án tiến sĩ của mình, đã mô tả chiếc máy tính có khả năng tự điều chỉnh vùng nhớ - một cách tự động hoàn toàn. Dựa trên bộ nhớ nhanh nhất thời điểm đó - lõi nhớ của siêu máy tính Whirlwind, ông lên ý tưởng chia bộ nhớ sơ cấp thành 6 blocks, mỗi block có dung lượng 100-words. Bộ nhớ này được sử dụng cùng với vùng tham chiếu địa chỉ (Address Space). Address Space có không gian tối đa là 1000 blocks, mỗi block cũng mang dung lượng 100-words.
Mô hình máy tính Güntsch:
*Concept của Güntsch, dù mang tính cách tân, đột phá nhưng chưa bao giờ được thực hiện, chiếc máy mà ông mô tả chưa bao giờ được xây dựng nên. * 3. Single-Level Store ConceptVậy lý thuyết của Güntsch được hình thành và phát triển như thế nào? Hiện thực hoá Virtual MemoryAtlas được phát triển trong khoảng 1956-1962, là chiếc computer đầu tiên sở hữu bộ nhớ ảo - Virtual Memory. Kiến trúc Virtual Memory của Atlas cũng xoay quanh mô hình Güntsch, gồm 3 thành phần chính:
Chi tiết hơn về kiến trúc Atlas Supervisor và Atlas Hardware bạn có thể tham khảo thêm ở link này. Còn dưới đây là hình mô tả tương tác của MMU với CPU và Memory Những thế hệ computer kế thừa Atlas càng hoàn thiện hơn công nghệ ảo hoá bộ nhớ, đáng kể nhất là Multics và Burroughs. 2 hệ máy này đi kèm với những đột phá đi-trước-thời-đại như Multiprocessing/Multitasking, Dynamic Linking, Hierarchical file system... đã làm tiền đề và nguồn cảm hứng cho toàn bộ hệ điều hành sau này gồm cả Unix, Windows. Hiện thực hoá Single-level StoreVới nền tảng công nghệ của 3 chiếc máy huyền thoại, computer dần trở nên "lỗi lạc" hơn:
Đáng lưu ý nhất, lý thuyết Single-level Store cũng được hoàn thiện trên hệ máy Multics cùng với mô hình Persistent Object & Mapping mà nó giới thiệu. Bộ nhớ ảo của Multics được triển khai bằng cách phân mảnh Memory và Storage. Xem dữ liệu chỉ đơn giản là những mảnh bytes thuần tuý, Operating System có nhiệm vụ phân mảnh, quản lý, tham chiếu, đặc biệt là giúp program đọc/ghi lên những mảnh bytes này. Program lúc này chỉ cần read/write thẳng vào phần bộ nhớ được map trên Virtual Memory. Đó cũng là cách mà memory-mapped files/mmap hoạt động. Video Series Bonus below: dành cho ai có ý muốn hiểu sâu hơn về virtual memory David Black-Scaffer - Virtual Memory 4. The Lightning DatabaseLightning (hay LMDB) với tên gọi đầy đủ: Lightning Memory-Mapped Database - là một CSDL dạng Key-Value được viết bởi Howard Chu tại Symas, ra mắt năm 2011. Lightning có thiết kế kỹ thuật ảnh hưởng lớn từ Berkeley DB cùng nhiều bổ sung quan trọng. Triết lý thứ nhất: Single-Level Store (SLS)Lightning được phát triển dựa trên concept Single-level store của chiếc máy Multics, lưu trữ dữ liệu ở dạng thuần tuý, hoàn toàn bỏ qua Type & Structure của dữ liệu mà hướng đến cấu trúc thông tin thô nhất: những mảnh bytes. Toàn bộ file data của Lightning trên Disk sẽ được map vào Memory bằng mmap(), sau đó hành động read/write được thực thi thẳng vào Mapped-Files ở Virtual Address. API của Lightning còn cho phép truy vấn, cập nhật dữ liệu dạng pointer-based Object, nghe hấp dẫn quá phải ko? Lợi ích chính mà SLS và Mmap mang lại, là khả năng bỏ qua cache, buffer, memcpy. Đây là điểm mấu chốt khiến Lightning có thể sử dụng Memory với mức hiệu quả tối đa, read/write performance nhờ đó mà cải thiện rất rất nhiều. Triết lý thứ hai: Multiversion Concurrency Control (MVCC)Một đặc điểm khác của LMDB là triển khai MVCC, điều này có nghĩa là gì? MVCC là một trong những phương pháp kiểm soát tính đồng thời, điểm đặc biệt nhất của MVCC là Isolation. Tôi ko thể tìm được từ tiếng Việt sát nghĩa cho ngữ cảnh 'Isolation' ở đây, nhưng có thể giải thích đơn giản như khả năng cung cấp góc nhìn độc lập đối với dữ liệu giữa các nguồn truy cập đồng thời (multiple threads or processes). MVCC đảm bảo mỗi thread truy cập vào DB sẽ luôn lấy được một view từ dữ liệu "cập-nhật-nhất" mà ko phải chờ đợi hành động modify nào khác. Sự đảm bảo này được thực hiện bằng kỹ thuật copy-on-write, khi cần thiết phải modify dữ liệu, một phiên bản copy mới của DB sẽ được tạo ra, dành riêng cho việc modify, dữ liệu thực sẽ ko bao giờ bị ghi đè - overwritten. Cũng phải nói thêm là khi nhắc tới chiến thuật copy-on-write hay snapshot isolation, lợi ích lớn nhất nó mang lại là tăng cường độ tin cậy (Reliability) cho DB, dữ liệu nằm trong DB sẽ ko bao giờ bị xung đột hay mất mát. Tất nhiên, đi kèm theo lợi ích đó là cái giá đắt đỏ phải trả đối với tài nguyên máy. Cực kỳ hao tốn và nhanh chóng nuốt sạch dung lượng kho lưu trữ là điều phải cân nhắc. Thậm chí việc dọn rác cũng sẽ tiêu tốn tài nguyên CPU/Memory rất nhiều nữa. Và LMDB quyết định chỉ giữ 2 bản snapshot của DB, ngoại trừ long-live transaction được tác giả Howard Chu khuyên là nên tránh dùng đến. Điểm nổi trội của Lightning?Compact, Reliability, Performance là 3 điểm ăn-tiền của LMDB.
Dưới đây là một vài benchmark được trích từ slide của Howard Chu, có thể các bạn cho rằng như vậy thì ko khách quan, nhưng thật ra kết quả benchmark trên một API khác của Google cũng xác nhận tốc độ của LMDB vượt trội. 5. Next Things n ReferencesCòn rất nhiều thứ để khám phá về LMDB như kiến trúc, API, cách cài đặt, sử dụng... nhưng bài viết đã quá dài, nên tôi phải kết thúc vậy. Bên dưới đây là toàn bộ references mà bài viết sử dụng. https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1369143 https://history-computer.com/ModernComputer/Electronic/Atlas.html https://multicians.org/features.html https://multicians.org/multics-vm.html http://www.chilton-computing.org.uk/acl/technology/atlas/p019.htm https://en.wikipedia.org/wiki/Translation_lookaside_buffer https://www.kernel.org/doc/gorman/ http://www.lmdb.tech/doc/ https://symas.com/lmdb/technical/ https://stackoverflow.com/questions/9414565/understanding-virtual-address-and-virtual-address-space |
