Tôi cũng nghĩ ngay đến điều này. Dạo này có cảm giác như người ta cứ mặc nhiên giả định rằng các dịch vụ hay agent AI đang có kiểu quyền hạn gần như đứng trên pháp luật. Cứ đi tiếp trong trạng thái bị bịt mắt một nửa như thế này liệu có ổn không? Kiểu vậy...
Vấn đề là do thiết lập volume sai khi chạy bằng container, chứ không phải do không thể ghi đồng thời nên mới phát sinh vấn đề. Nếu đọc lại bài viết, bạn sẽ thấy trong đó nói rằng việc không thể ghi đồng thời đã được xử lý đủ bằng busy timeout. Thiết lập volume thì
có thể giải quyết bằng ipc=host.
Cuối cùng thì postgres vẫn cần phải được vận hành, còn sqlite thì chỉ cần phân phối binary của ứng dụng là được ở bất cứ đâu.
Chính vì vô số kinh nghiệm vận hành và những lần thất bại đã tích lũy lại nên sqlite mới bắt đầu trở nên phổ biến, và
việc ghi đồng thời cũng được nêu rõ trong bài là hoàn toàn không phải vấn đề.
Đọc toàn bộ bài blog thì thấy đây vốn là công việc mà PM trước nay vẫn làm. Chỉ là khi thời đại AI đến, cách làm có vẻ đang thay đổi từng chút một. Cảm ơn vì những góc nhìn sâu sắc rất hay.
Việc chuyển sang Linux không phải là thứ ai cũng chỉ thử một hai lần; có lý do khiến nó thất bại, nên không rõ lần này sẽ đi đến đâu.
Trước đây ở Hàn Quốc, chính phủ cũng từng thúc đẩy nền tảng dựa trên Linux vì lý do này.
Dù vậy, ở các doanh nghiệp Hàn Quốc thì chí ít chính phủ vẫn có thể phát huy quyền kiểm soát.
Tuy nhiên, xu hướng lại đang nghiêng về web-based hay SaaS hơn là Linux native; nếu vậy thì rốt cuộc có thể lại dẫn tới sự phụ thuộc ở một lĩnh vực khác.
Dù có vấn đề về độ phức tạp hạ tầng đến đâu đi nữa, thì với những nơi cần rất nhiều ghi đồng thời như sàn thương mại điện tử, chẳng phải ngay từ đầu không dùng sqlite sẽ là lựa chọn tốt hơn sao?
Thậm chí nếu được cấu hình bằng Docker thì độ phức tạp hạ tầng của việc dùng postgresql cũng đâu tăng lên quá nhiều.
Mình có cảm giác là vì làm bằng rails nên hệ sinh thái đã được định hình theo hướng dùng sqlite, rồi từ đó bị dẫn dắt đến kết luận rằng nó là lựa chọn tốt.
Đã xảy ra lỗi nghiêm trọng như bỏ sót đơn hàng, và ngay cả khi có những vấn đề về ghi đồng thời như với pg, thì với một hệ thống như shopping mall nơi nhu cầu ghi đồng thời rất lớn, chẳng phải ngay từ đầu không dùng sqlite sẽ là lựa chọn tốt hơn sao?
Mình cũng nghĩ là vì được làm bằng rails nên hệ sinh thái đã đóng khung theo hướng dùng sqlite, rồi bị dẫn dắt đến suy nghĩ rằng như vậy là tốt.
Đã phát sinh lỗi nghiêm trọng như bỏ sót đơn hàng, và cách giải quyết tận gốc chuyện này là dùng một cơ sở dữ liệu hỗ trợ ghi đồng thời như pg.
Vì về mặt kỹ thuật thích sqlite nên vẫn cố chấp nói sẽ tiếp tục dùng nó, với mình nghe như một phát ngôn làm giảm độ tin cậy của họ với tư cách kỹ sư.
Nó cho mình cảm giác như phiên bản ngược lại của kiểu phát triển driven by CV: dựng k8s khi không cần thiết, cấu hình HPA với replica = 1, rồi biến một monolith đang chạy tốt thành MSA.
Dù đây không phải là ý tưởng quá mới ở thời điểm hiện tại, nhưng có vẻ đây là một cách hay vì có thể thực hiện mà không phá vỡ interface signature hay workflow.
Thật tiếc là trong công ty đã có khá nhiều đội AX được lập ra rồi, nên có lẽ phải chú ý đặc biệt đến phần cuối cùng và ứng phó dần dần.
Tôi cũng nghĩ ngay đến điều này. Dạo này có cảm giác như người ta cứ mặc nhiên giả định rằng các dịch vụ hay agent AI đang có kiểu quyền hạn gần như đứng trên pháp luật. Cứ đi tiếp trong trạng thái bị bịt mắt một nửa như thế này liệu có ổn không? Kiểu vậy...
Thực ra chỉ cần chỉnh vài thiết lập là được, nhưng rốt cuộc vẫn cần có kinh nghiệm thôi, hì hì. Dù sao thì tôi khá thích những bài viết như thế này.
Vấn đề là do thiết lập volume sai khi chạy bằng container, chứ không phải do không thể ghi đồng thời nên mới phát sinh vấn đề. Nếu đọc lại bài viết, bạn sẽ thấy trong đó nói rằng việc không thể ghi đồng thời đã được xử lý đủ bằng
busy timeout. Thiết lập volume thìcó thể giải quyết bằng
ipc=host.Cuối cùng thì
postgresvẫn cần phải được vận hành, cònsqlitethì chỉ cần phân phối binary của ứng dụng là được ở bất cứ đâu.Chính vì vô số kinh nghiệm vận hành và những lần thất bại đã tích lũy lại nên
sqlitemới bắt đầu trở nên phổ biến, vàviệc ghi đồng thời cũng được nêu rõ trong bài là hoàn toàn không phải vấn đề.
Hy vọng họ sẽ không thất bại như thành phố Munich. https://zdnet.co.kr/view/?no=20170213100421
Cảm ơn bạn.
Dù cách làm trong khâu lập kế hoạch hay thiết kế vẫn luôn thay đổi, nhưng có cảm giác tốc độ đang ngày càng nhanh hơn.
Đọc toàn bộ bài blog thì thấy đây vốn là công việc mà PM trước nay vẫn làm. Chỉ là khi thời đại AI đến, cách làm có vẻ đang thay đổi từng chút một. Cảm ơn vì những góc nhìn sâu sắc rất hay.
Việc chuyển sang Linux không phải là thứ ai cũng chỉ thử một hai lần; có lý do khiến nó thất bại, nên không rõ lần này sẽ đi đến đâu.
Trước đây ở Hàn Quốc, chính phủ cũng từng thúc đẩy nền tảng dựa trên Linux vì lý do này.
Dù vậy, ở các doanh nghiệp Hàn Quốc thì chí ít chính phủ vẫn có thể phát huy quyền kiểm soát.
Tuy nhiên, xu hướng lại đang nghiêng về web-based hay SaaS hơn là Linux native; nếu vậy thì rốt cuộc có thể lại dẫn tới sự phụ thuộc ở một lĩnh vực khác.
Skills là kiếm thuật, còn MCP là thanh kiếm.. Mục đích sử dụng khác nhau và cả hai đều cần thiết.
Đúng vậy, vì thế càng mong thỉnh thoảng sẽ có những bài viết như thế này được đăng lên.
Dù có vấn đề về độ phức tạp hạ tầng đến đâu đi nữa, thì với những nơi cần rất nhiều ghi đồng thời như sàn thương mại điện tử, chẳng phải ngay từ đầu không dùng sqlite sẽ là lựa chọn tốt hơn sao?
Thậm chí nếu được cấu hình bằng Docker thì độ phức tạp hạ tầng của việc dùng postgresql cũng đâu tăng lên quá nhiều.
Mình có cảm giác là vì làm bằng rails nên hệ sinh thái đã được định hình theo hướng dùng sqlite, rồi từ đó bị dẫn dắt đến kết luận rằng nó là lựa chọn tốt.
Đã xảy ra lỗi nghiêm trọng như bỏ sót đơn hàng, và ngay cả khi có những vấn đề về ghi đồng thời như với pg, thì với một hệ thống như shopping mall nơi nhu cầu ghi đồng thời rất lớn, chẳng phải ngay từ đầu không dùng sqlite sẽ là lựa chọn tốt hơn sao?
Mình cũng nghĩ là vì được làm bằng rails nên hệ sinh thái đã đóng khung theo hướng dùng sqlite, rồi bị dẫn dắt đến suy nghĩ rằng như vậy là tốt.
Đã phát sinh lỗi nghiêm trọng như bỏ sót đơn hàng, và cách giải quyết tận gốc chuyện này là dùng một cơ sở dữ liệu hỗ trợ ghi đồng thời như pg.
Vì về mặt kỹ thuật thích sqlite nên vẫn cố chấp nói sẽ tiếp tục dùng nó, với mình nghe như một phát ngôn làm giảm độ tin cậy của họ với tư cách kỹ sư.
Nó cho mình cảm giác như phiên bản ngược lại của kiểu phát triển driven by CV: dựng k8s khi không cần thiết, cấu hình HPA với replica = 1, rồi biến một monolith đang chạy tốt thành MSA.
Nếu nhà nước đã áp dụng thì cũng nên dùng số tiền đó để hỗ trợ phát triển Linux nữa chứ..
Đã là một ngành AI hỗn loạn với đầy rẫy những kẻ truyền đạo giả danh rồi mà
Skills và MCP vốn đảm nhiệm những vai trò khác nhau, nhưng có vẻ chính vì những bài viết như thế này mà mọi người cứ tiếp tục bị nhầm lẫn.
Vì cuối bài phải quảng bá MCP Nest mà.. haha. Có vẻ mấy lập luận mang tính so sánh đang được hưởng ứng khá mạnh.
Chỉ là hai thứ vốn hoàn toàn khác nhau, vậy mà sao những câu chuyện kiểu này cứ liên tục xuất hiện nhỉ
Nếu xem thêm các bài viết liên quan thì có vẻ như toàn bộ châu Âu đang chuyển động theo hướng này.
Trước hết hãy ổn định tính năng kênh đi đã..
Có vẻ như những người hiểu rõ các điểm nghẽn tại hiện trường mới là cốt lõi.
Dù đây không phải là ý tưởng quá mới ở thời điểm hiện tại, nhưng có vẻ đây là một cách hay vì có thể thực hiện mà không phá vỡ interface signature hay workflow.