SQLite là định dạng lưu trữ được Thư viện Quốc hội Hoa Kỳ khuyến nghị

 (sqlite.org)
1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • SQLite được đưa vào danh sách định dạng lưu trữ được Thư viện Quốc hội Hoa Kỳ khuyến nghị cho các bộ dữ liệu
  • Có thể xác nhận cơ sở liên quan trong phần mô tả định dạng SQLite của Thư viện Quốc hội và danh sách định dạng được khuyến nghị cho dữ liệu: https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml#local, https://www.loc.gov/preservation/resources/rfs/data.html
  • Tính đến ngày 29/5/2018, ngoài SQLite thì các định dạng lưu trữ được khuyến nghị cho bộ dữ liệu chỉ có XML, JSON và CSV
  • Các định dạng lưu trữ được Thư viện Quốc hội khuyến nghị là những định dạng mà các chuyên gia bảo tồn cho rằng sẽ tối đa hóa khả năng tồn tại và khả năng truy cập lâu dài của nội dung số
  • Các tiêu chí đánh giá bao gồm tính mở, mức độ chấp nhận, tính minh bạch, khả năng tự mô tả, phụ thuộc bên ngoài, tác động của bằng sáng chế và các cơ chế bảo vệ kỹ thuật như mã hóa

SQLite và các định dạng lưu trữ được LoC khuyến nghị

Tiêu chí đánh giá các định dạng lưu trữ được khuyến nghị

  • Các định dạng lưu trữ được khuyến nghị là những định dạng mà các chuyên gia bảo tồn của Thư viện Quốc hội cho rằng sẽ tối đa hóa khả năng tồn tại và khả năng truy cập lâu dài của nội dung số
  • Khi lựa chọn định dạng lưu trữ được khuyến nghị, Thư viện Quốc hội xem xét các tiêu chí sau

  • Tính mở

    • Xem xét mức độ tồn tại của đặc tả đầy đủ và công cụ để kiểm chứng tính toàn vẹn kỹ thuật, cũng như mức độ những người tạo và duy trì nội dung số có thể tiếp cận chúng
    • Tài liệu đầy đủ quan trọng hơn việc được một tổ chức tiêu chuẩn hóa được công nhận phê duyệt

  • Mức độ chấp nhận

    • Xem xét mức độ các nhà tạo lập, nhà phân phối và người dùng chính của tài nguyên thông tin đã sử dụng định dạng đó
    • Bao gồm các trường hợp được dùng làm định dạng gốc, định dạng phân phối tới người dùng cuối và phương tiện trao đổi giữa các hệ thống

  • Tính minh bạch

    • Xem xét mức độ có thể trực tiếp phân tích biểu diễn số bằng các công cụ cơ bản, chẳng hạn như việc con người có thể đọc được bằng trình soạn thảo chỉ văn bản

  • Khả năng tự mô tả

    • Đối tượng số có khả năng tự mô tả bao gồm siêu dữ liệu mô tả cơ bản, siêu dữ liệu kỹ thuật và các siêu dữ liệu quản trị khác

  • Phụ thuộc bên ngoài

    • Xem xét mức độ việc hiển thị hoặc sử dụng phụ thuộc vào phần cứng, hệ điều hành hay phần mềm cụ thể, cũng như độ phức tạp của việc xử lý các phụ thuộc đó trong môi trường công nghệ tương lai

  • Tác động của bằng sáng chế

    • Xem xét mức độ bằng sáng chế cản trở khả năng của các tổ chức bảo tồn trong việc duy trì nội dung ở định dạng đó

  • Cơ chế bảo vệ kỹ thuật

    • Xem xét việc có triển khai các cơ chế như mã hóa làm cản trở việc bảo tồn nội dung trong kho lưu trữ đáng tin cậy hay không

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Hacker News

  • Tôi luôn thấy được truyền cảm hứng từ SQLite. Nhìn chung tôi rất thích nó, nhưng nếu không cần ghi thì đây cũng là một lựa chọn khá quá tay
    Vì vậy, dù không thể vượt qua SQLite, tôi đã tạo ra một định dạng nhẹ hơn nhiều, nhanh hơn và còn hoạt động được trên tệp nén zstd
    Chỉ mục rất nhỏ và cũng có thể chứa dữ liệu nhị phân hoặc văn bản giống như SQLite
    Phần wasm đảm nhiệm việc giải nén, đọc và tìm kiếm chỉ khoảng 38KB nếu không nén, và có lẽ khoảng 16KB với gzip
    So với 1.2MB wasm và glue code của SQLite thì chỉ bằng 3% kích thước, trong khi tìm kiếm và tải còn nhanh hơn nhiều
    Chương trình của tôi không phải dạng cột và cũng không phù hợp để quản lý bảng tính, nhưng lại hợp với từ điển và kho lưu trữ tệp hình ảnh·âm thanh
    Tôi cũng đã port bộ giải mã jbig2 thành mô-đun wasm 17KB, nên có thể đọc các bản quét đen trắng chỉ 8KB mỗi trang mà vẫn còn nhận ra được
    https://github.com/tnelsond/peakslab
    SQLite được thiết kế rất tốt, còn PeakSlab thì cực kỳ đơn giản

    • Bạn nói “1.2MB wasm và glue code của SQLite”, nhưng dạng tiêu chuẩn chưa thu gọn hiện tại trên trunk thực ra là 1.7MB. Tài liệu chiếm gần bằng lượng mã JS nên WASM và JS gần như chia đôi. Tuy nhiên nếu thu gọn thì 1.2MB là đúng
      Nhân tiện, tôi là người bảo trì nó
      Theo trunk hiện tại, các con số là sqlite3.wasm 896745, sqlite3.mjs 816270 (chưa thu gọn, có tài liệu), sqlite3.mjs 431388 (chưa thu gọn, không có tài liệu), sqlite3.mjs 310975 (đã thu gọn)
    • Tôi chưa biết về PeakSlab, nhưng nó thực sự rất hay và mới mẻ. Hiệu năng từ điển cũng có vẻ rất tốt, đáng để đánh dấu lại dùng sau
    • Cái này có vẻ gần với hướng cạnh tranh với Berkeley DB ngày xưa hơn: https://en.wikipedia.org/wiki/Berkeley_DB
      Giờ nhìn lại thì nó cũng không còn là giấy phép BSD nữa, và dù sao thì gần như đã biến mất vì SQLite, nhưng trước đây từng được dùng làm kho key-value cơ bản trên đĩa
    • SQLite bản thân nó cũng khá đơn giản, và tôi thích các nguyên tắc thiết kế của phương ngữ SQL đó
      Kiểu như “right join chỉ là left join theo chiều ngược lại, nên không cần thứ đó”
      Tất nhiên lúc nào cũng có thể có thứ đơn giản hơn hoặc chuyên biệt hơn. Nhiều ứng dụng dùng cơ sở dữ liệu có lẽ chạy rất ổn chỉ với SQLite, còn một số ứng dụng khác thì thậm chí chỉ cần tệp văn bản thay vì DB kiểu SQLite
    • Có lẽ giải pháp chuẩn hơn sẽ là cdb. Chỉ là nó không hỗ trợ dữ liệu nén
      https://cdb.cr.yp.to/ , https://en.wikipedia.org/wiki/Cdb_(software)

  • Tôi lúc nào cũng thích SQLite, nhưng nghe nói có công ty cấm dùng nó
    Lý do là vì nó khiến việc tạo cơ sở dữ liệu cho ứng dụng trở nên quá dễ, đến mức một thành phần cực kỳ cốt lõi của ứng dụng lại trông như một tệp bình thường. Tệp đó có thể mang bất kỳ phần mở rộng nào, và cũng có thể bị chép sang máy chủ khác. Ngay cả khi bên trong có thông tin nhận dạng cá nhân cũng vậy
    Nếu nghĩ tới việc tình huống này nhân lên theo số lượng ứng dụng trong công ty thì có thể thành một mớ hỗn độn khá lớn
    Các nhóm DevOps và DBA thích cơ sở dữ liệu là những hệ thống to, nặng, nhìn vào là biết ngay máy chủ cơ sở dữ liệu. Việc kết nối tới nó cũng phải hiện ra rõ ràng, v.v.
    Dù vậy tôi vẫn rất thích SQLite

    • Vậy thì tôi tự hỏi những công ty đó có cấm cả Excel không. Bảng tính Excel rất hay trở thành cơ sở dữ liệu bóng tối ở những nơi không ngờ tới
    • Với câu chuyện “bất cứ thứ gì cũng có thể trở thành cơ sở dữ liệu mission-critical”, bài này là bắt buộc phải đọc
      https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
    • Nếu là “một tệp có thể mang bất kỳ phần mở rộng nào” thì chỉ cần đọc magic number là được. Đằng nào cũng không nên tin vào phần mở rộng tệp
      Còn chuyện “có thể bị chép sang máy chủ khác” thì bảng tính cũng vậy thôi
      Tôi không phủ nhận rằng truy cập dữ liệu tập trung là điều đáng mong muốn, nhưng lập luận đó có vẻ chưa đủ chặt
    • SQLite còn có cách dùng thú vị thế này: https://sqlite.org/sqlar.html
    • Vì vậy các tệp cấu hình kiểu đó sẽ được đặt trong AppData, thư mục dotfile, hoặc vị trí tương ứng trong ~/Library của MacOS

  • Trước đây tôi từng nghĩ “SQLite là đồ chơi và không thể tin cậy cho dữ liệu thật”, nhưng giờ tôi đã chuyển hẳn sang phe “hãy dùng SQLite cho gần như mọi thứ”
    Nếu bạn có thể điều chỉnh theo mô hình một người ghi, nhiều người đọc thì SQLite rất tuyệt. Chỉ cần dùng đúng cấu hình là không bị mất dữ liệu, và mấy cấu hình đó tìm khoảng 1 phút là ra
    Phần lớn ứng dụng của tôi dạo này chỉ là tổ hợp Go binary + SQLite + tệp service của systemd
    Tôi vẫn chưa từng mất dữ liệu, hiệu năng thì rất tốt và với đa số ứng dụng là quá đủ

    • Một người ghi thực ra không phải vấn đề lớn như người ta hay nói. Ổ NVMe bây giờ rất khủng, với cấu hình WAL được tối ưu thì 5 nghìn lượt ghi mỗi giây là chuyện dễ dàng. Hầu hết ứng dụng còn không dám mơ đến mức đó
      Tôi thậm chí từng đạt 180 nghìn lượt ghi mỗi giây trên một VPS bình thường bằng mô hình batch writer
    • Tôi tò mò không biết bạn có dùng nhiều backend node không. Nếu có thì cũng muốn biết bạn truy cập tệp SQLite từ các node khác nhau bằng cách nào

  • Vì bài có ghi “Tại thời điểm viết bài này (2018-05-29)...” nên đây là tin gần 8 năm trước rồi. Dù vậy tôi không phàn nàn vì đến giờ tôi vẫn chưa biết, nên gần như là cảm ơn vì đã đăng
    Bộ não thiên về toán của tôi vừa chập mạch một lúc nên tưởng là 6 năm

    • Bây giờ là năm 2026 nên là 8 năm trước
    • Tôi đọc mà có cảm giác déjà vu

  • Định dạng lưu trữ được khuyến nghị năm 2026: https://www.loc.gov/preservation/resources/rfs/data.html

    • Khi lưu trữ dữ liệu mà phải tính tới 300~500 năm sau, đồng thời chịu được mọi đổi mới và cả sự lão hóa công nghệ cơ bản, thì thật sự cần tư duy dài hạn
      Không biết vật liệu giấy nào đã tồn tại được lâu nhất nhỉ?
    • Tiêu chí khuyến nghị có vẻ khá lỏng. XLS được xếp là “ưu tiên”

  • Đối với việc bảo tồn dữ liệu khu vực công, SQLite có thể là một trong những lựa chọn tốt nhất
    Đặc tả của nó công khai, được chấp nhận rộng rãi và khả năng cao là sau này vẫn đọc được
    Nó ít phụ thuộc vào hệ điều hành hay dịch vụ cụ thể, và rủi ro bằng sáng chế cũng thấp
    Từ góc độ tính bền vững lâu dài, việc không phụ thuộc vào một công ty hay dịch vụ cụ thể là cực kỳ quan trọng

    • Các nhà lưu trữ cũng thích những định dạng gần với nguyên bản. SQLite cho phép giữ nguyên quan hệ quan hệ mà CSV khó thể hiện được

  • Tôi thích SQLite và vui vì bạn chia sẻ, nhưng có lẽ tiêu đề nên thêm “(2018)” ở cuối
    Trong bài có câu “Tại thời điểm viết bài này (2018-05-29), các định dạng lưu trữ khác được khuyến nghị cho bộ dữ liệu chỉ là XML, JSON, CSV”

    • Để tham khảo thì sau đó danh sách đã được bổ sung thêm khá nhiều định dạng
      Với định dạng ưu tiên, miễn là dữ liệu đầy đủ và giữ được chi tiết cùng độ chính xác, thì các định dạng văn bản độc lập nền tảng được ưu tiên hơn định dạng native hoặc nhị phân. Danh sách này bao gồm cả các tiêu chuẩn thị trường de facto được phát triển tốt và chấp nhận rộng rãi
      Ví dụ như các định dạng dựa trên schema quen thuộc có công cụ kiểm chứng công khai, các định dạng theo dòng như TSV·CSV·fixed-width, và các định dạng mở độc lập nền tảng như .db·.db3·.sqlite·.sqlite3
      Ngoài ra còn có các định dạng độc quyền nhưng là chuẩn de facto trong một số ngành nghề hoặc được nhiều công cụ hỗ trợ, như Excel .xls/.xlsx hay Shapefile
      Mã hóa ký tự được ưu tiên theo thứ tự UTF-8, UTF-16 có BOM, US-ASCII hoặc ISO 8859-1, rồi đến các mã hóa có tên khác
      Với định dạng chấp nhận được, dữ liệu có thể dùng các định dạng không độc quyền, công khai tài liệu, được cộng đồng chuyên môn hoặc cơ quan chính phủ phê chuẩn làm tiêu chuẩn như CDF, HDF, cùng các định dạng dữ liệu văn bản có schema khả dụng
      Với mục đích đóng gói hay truyền tải, ZIP, RAR, tar, 7z không có mã hóa, mật khẩu hay cơ chế bảo vệ khác đều được chấp nhận
      https://www.loc.gov/preservation/resources/rfs/data.html

  • Ngay hôm qua tôi cũng vừa nghĩ là đã lâu chưa thấy bài về SQLite ở đầu HN
    Tôi thực sự rất thích sự đơn giản và tốc độ của SQLite, và đã dùng nó cả trong dự án cá nhân lẫn công việc
    Nhưng trong công việc hằng ngày thì cuối cùng tôi vẫn quay về Excel. Không phải vì tôi thích Excel hơn, mà vì nó quá phổ biến nên khi chia sẻ và khám phá bộ dữ liệu với các bên liên quan ít kỹ thuật hơn hoặc với lãnh đạo, đó là cách ít ma sát nhất

    • Tôi không nghĩ điều này sẽ làm thế giới quan của bạn sụp đổ đâu, nhưng vì nó từng hữu ích với tôi nên có thể cũng giúp được bạn: thử xem Metabase
      Bạn có thể tự host, và nếu chỉ muốn trình bày dữ liệu theo cách dễ tiêu hóa cho các bên liên quan thì nó thực sự rất đơn giản. Tất nhiên nếu đào quá sâu thì bạn có thể hối hận về mọi quyết định trong đời, nhưng tôi cố tự kiềm chế để không đi đến mức đó
      https://www.metabase.com/
    • Điều luôn làm tôi khó chịu về SQLite là nó dựa vào việc phân tích cú pháp văn bản để hoạt động. Tôi không hiểu tại sao truy vấn lại phải viết dưới dạng văn bản, thay vì biểu diễn bằng logic chương trình
      Vì lý do này mà tôi chưa bao giờ dùng cơ sở dữ liệu quan hệ. Tôi ghét nó. Tôi biết nó có thể cho hiệu năng tốt hơn dữ liệu thuần cấu trúc, nhưng tôi ghét SQL và cả chính ý tưởng SQL, và không muốn viết, học hay dùng những hệ thống phụ thuộc vào nó
      Nó cho tôi cảm giác sai lầm kiểu như PHP. Có cách nào làm dịu chuyện này không? Tôi không muốn cứ tiếp tục từ bỏ SQLite chỉ vì SQL, nhưng thực sự không thể chấp nhận nổi. Tôi ghét việc phải tạo chuỗi hay có phân tích cú pháp chuỗi ở bất kỳ đâu trong stack, nó просто khiến tôi thấy sai sai

  • SQLite đa năng đến mức đáng ngạc nhiên. Chỉ vài tuần trước thôi cũng đã có một extension được công bố để triển khai queue liên tiến trình, stream, publish/subscribe trên SQLite
    Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647
    Thông báo thời gian thực là một mảnh ghép lớn còn thiếu khi xây dựng cả ứng dụng trên backend SQLite, và giờ đã có một giải pháp khá ổn

  • Thật vui khi thấy SQLite nhận được mức công nhận ở tầm thể chế như thế này. Nhờ định dạng tệp đơn, việc lưu trữ lưu trữ dạng archive trở nên đơn giản hơn rất nhiều so với dump cơ sở dữ liệu truyền thống