Gmail sang SQLite

• Công cụ dòng lệnh dựa trên Python giúp chuyển đổi dữ liệu email nhận từ Gmail sang cơ sở dữ liệu SQLite để quản lý và phân tích một cách có hệ thống
• Được phát triển dưới dạng mã nguồn mở nên cả cá nhân lẫn doanh nghiệp đều có thể tự do mở rộng và tùy biến
• So với cách quản lý email thông thường, công cụ này cho phép truy vấn nhanh và phân tích chi tiết theo từ khóa hoặc điều kiện mong muốn
• Việc di chuyển dữ liệu rất đơn giản, đồng thời đặc biệt hiệu quả cho sao lưu và lưu trữ dài hạn khối lượng email lớn
• So với các dự án mã nguồn mở cùng loại, công cụ nổi bật nhờ ít phụ thuộc hơn, cấu hình đơn giản và tiện lợi với các tính năng như đánh chỉ mục tự động

[GN⁺]

Ý kiến trên Hacker News

• Điều tôi thắc mắc là vì sao một số header lại được tách riêng trong schema. Ví dụ, các trường như recipients, subject, sender hoàn toàn có thể được đưa hết vào một mục JSON là headers, nên tôi không hiểu lý do phải tách riêng. Nếu là vì hiệu năng, thì vẫn có thể giữ headers dưới dạng JSON blob và chỉ trích các trường cần thiết ra thành generated column để dùng. Tôi nghĩ làm vậy sẽ tạo ra một mô hình rất mạnh, vì người dùng có thể tự do thêm các generated column có lập chỉ mục cho từng truy vấn cần thiết thông qua ALTER TABLE. Ví dụ, nếu cần truy vấn trạng thái DKIM thì có thể thêm bằng ALTER TABLE và cũng dễ dàng tạo index. Vì có thể mở rộng trường dữ liệu một cách linh hoạt theo ý muốn nên cách này khá có lợi cho nhiều mục đích sử dụng.

  • Thực ra cũng không cần generated column, SQLite có thể tạo index trực tiếp trên biểu thức. Vì vậy, ví dụ có thể tạo index cho subject trực tiếp bằng json_extract, rồi dùng index này trong truy vấn bất cứ khi nào cần. Tôi thấy kiểu chỉ tạo index riêng như vậy rồi dùng qua view còn hữu ích hơn là thay đổi bảng chính bằng ALTER.

  • Chỉ để phục vụ truy vấn dùng một lần mà thêm index thì có vẻ không phải thói quen hay. Thông thường tôi thích chỉ tách riêng những cột chắc chắn sẽ được dùng một cách nhất quán về sau, nhất là với thứ có cấu trúc ổn định như email header. Việc dồn header vào một JSON có thể giúp đổi schema sau này dễ hơn, nhưng rốt cuộc chỉ là chuyển phần vất vả ở lúc ghi sang phía truy vấn đọc, và trong một số trường hợp còn cho phép lỗi âm thầm xảy ra.

  • Tôi cũng hay dùng pattern tương tự trong Postgres. Trước tiên tách những trường chắc chắn cần thiết thành cột riêng, rồi dồn metadata bổ sung vào cột JSON. Sau khoảng 2 tháng thì lại điều chỉnh linh hoạt, như điền lại các trường thực sự cần từ JSON, thay đổi để API vẫn được giữ nguyên, hoặc tạo view. Cách này rất hữu ích để tránh kiểu đau tăng trưởng khi ban đầu ném mọi thứ vô tội vạ vào Mongo hay filesystem rồi sau đó phải hối hận.

  • Họ đặt cột dkim là NOT NULL, vậy nếu email hoàn toàn không có header Dkim-Signature thì sẽ được xử lý thế nào?

• Gần đây tôi đã thử tích hợp Gmail vào ứng dụng của mình. Tôi đã tốn rất nhiều thời gian cho việc này nhưng cuối cùng vẫn từ bỏ hỗ trợ Gmail. Người ta nói Gmail to SQLite chỉ cần xong quy trình xác thực 6 bước là được, nhưng thực tế không phải vậy. Sau khi hoàn thành 6 bước, Google lại báo ứng dụng chưa được publish, rồi khi publish xong thì lại báo vì tôi không phải người dùng Workspace nên không thể dùng ứng dụng nội bộ. Nếu chuyển sang ứng dụng external thì lại bị yêu cầu thêm một quy trình xác minh riêng nữa (đòi domain, địa chỉ, thông tin chi tiết, lý do xin quyền, video giải thích, thời gian chờ duyệt, v.v.). Tôi nghĩ bắt người dùng phổ thông phải đi qua quy trình phức tạp như vậy của Google là quá đáng. Trải nghiệm thực tế khiến tôi rất sửng sốt.

  • Cứ làm theo cách cũ là dùng IMAP với app password là được. Tốt hơn là tránh quy trình phiền phức mà Google yêu cầu.

  • Quy trình để lấy một API key từ Google đúng là phiền toái đến mức khó tin. Tôi thật sự muốn biết tại sao họ lại làm nó rắc rối đến vậy.

• Vài năm trước tôi từng làm một công cụ trực quan hóa email dung lượng lớn như Gmail: https://github.com/terhechte/postsack

  • Cái này thật sự rất hay. Nó giống như công cụ trực quan hóa dung lượng đĩa, nhưng tập trung vào chính khối lượng email. Không biết có tùy chọn hiển thị dung lượng theo người gửi để xem ai đang chiếm nhiều không gian lưu trữ nhất của tôi không. Nhân tiện, chứng chỉ SSL của website đã hết hạn.

  • Trông khá thú vị. Link gmvault trong readme không còn hoạt động nữa, không biết có phải link đúng là https://github.com/gaubert/gmvault không.

  • Trông thực sự rất thú vị. Tôi cũng từng tự DIY một thứ tương tự bằng qdirstat, nhưng trong trường hợp này thì phải sắp theo cấu trúc thư mục email hoặc theo ngày, và khá khó để tái tổ hợp lại theo nhiều tiêu chí khác nhau. Nhân tiện, file cache của qdirstat cực kỳ dễ tạo, nên rất hữu ích khi muốn trực quan hóa dữ liệu kiểu nhiều file như thế này.

• Thật đáng tiếc khi giờ đây ngay cả đăng nhập chỉ bằng app password cũng không còn được nữa, mà phải đi qua quy trình phức tạp như đăng ký OAuth client. Dù email là của tôi, tôi vẫn có cảm giác Google đang tước đi các open standard cho phép tôi tự truy cập nó.

  • Lượng spam tôi nhận ở địa chỉ Gmail miễn phí nhiều áp đảo so với địa chỉ trả phí cho công việc freelance, và spam từ máy chủ Gmail cũng đến tài khoản không phải Gmail của tôi nhiều hơn. Đặc biệt khi thấy email freelance của mình liên tục bị hệ thống mail bên kia đánh dấu là spam, tôi càng ngày càng muốn rời khỏi hệ sinh thái Google. Nhưng tôi vẫn thấy mông lung và áp lực khi nghĩ đến chuyện thoát khỏi các thói quen phụ thuộc vào Google.

  • Tôi không hiểu lắm. Chỉ cần app password là có thể có toàn quyền truy cập IMAP.

  • Tôi muốn biết vì sao app-specific password được xem là open standard còn OAuth thì lại không.

• Thật sự rất hay. Một yêu cầu tính năng mới: tôi muốn có khả năng trích xuất link hủy đăng ký từ nội dung email để có thể dễ dàng hủy đăng ký theo những người gửi thường xuyên xuất hiện.

• Hôm qua tôi cũng đã thử làm y hệt, vì muốn liệt kê số email nhận được theo từng domain. Chất lượng code không cao lắm, nhưng đây: https://github.com/hugoferreira/gmail-sqlite-db

  • Tôi cũng đã thử nhóm theo domain và người gửi giống hệt.

• Tôi không biết là làm được việc này, cảm ơn.

• Hơi gợi nhớ đến Archiveopteryx (máy chủ IMAP dựa trên Postgres): https://github.com/aox/aox Tôi luôn thấy schema của AOX rất đẹp nhưng vẫn chưa có dịp dùng thử tử tế. Chủ yếu tôi muốn dùng nó cho mục đích phân tích hoặc tìm kiếm email.

• Tôi thắc mắc chi phí băng thông ở đây sẽ là bao nhiêu. Chỉ riêng Gmail của tôi đã hơn 40GB, nên tôi muốn biết dùng công cụ này có dẫn tới hóa đơn do lưu lượng truyền dữ liệu hay không. Tất nhiên, nếu lấy Google Takeout xuống (tải toàn bộ email miễn phí) thì chỉ cần parse file là xong, nên cũng dễ giải quyết. Nhưng công cụ này có vẻ sẽ nhanh hơn và dễ bắt đầu hơn nhiều.

• Tôi thấy cái này đáng lẽ nên có tên kiểu "imap to sqlite" hơn. Tôi thắc mắc vì sao lại chỉ giới hạn ở một nhà cung cấp email cụ thể.

  • Lý do là công cụ này được tối ưu riêng cho Gmail. Nó tận dụng OAuth và quyền truy cập API của Google. Cách làm qua IMAP phức tạp hơn nhiều, chậm hơn, và còn vướng giới hạn băng thông của Google.

  • Nhân tiện, trong nhiều năm tôi đã cố backup tài khoản gmail của mình qua imap (thậm chí cả bằng công cụ chuyên cho gmail) nhưng chưa từng thành công một lần nào. Ngay cả công cụ đồng bộ có vẻ hoạt động tốt cũng thường chạy được khoảng một tháng rồi cuối cùng dừng lại vì không lấy được một email nào đó. Có lẽ vì nó đang ở trạng thái cold storage gì đó. Vì vậy tôi nghĩ dùng API riêng của Google có lẽ sẽ tốt hơn. Hiện tại tôi rất hài lòng vì Google Takeout giờ cho phép lấy mbox trực tiếp, backup đầy đủ nhanh chóng mà không gặp vấn đề gì (mất khoảng nửa ngày). Nhược điểm là không có cập nhật tự động liên tục. Nhân tiện, tôi đã chuyển sang dịch vụ mail khác (Infomaniak), và thấy thật may vì trước đó mình đã có sẵn một domain độc lập.