Sử dụng tệp phẳng so với cơ sở dữ liệu / API làm phương tiện di chuyển giữa giao diện và phụ trợ

Tôi đã có một ứng dụng tạo ra một cuộc thảo luận khá sôi nổi giữa một vài nhà phát triển.

Về cơ bản, nó được chia thành một lớp web và một lớp phụ trợ. Lớp web thu thập thông tin bằng một hình thức web đơn giản, đưa dữ liệu này dưới dạng tài liệu JSON (nghĩa là tệp .json) vào thư mục theo dõi được sử dụng bởi mặt sau. Mặt sau sẽ thăm dò thư mục này cứ sau vài giây, chọn tệp và thực hiện các chức năng của nó.

Bản thân các tệp rất đơn giản (tức là tất cả dữ liệu chuỗi, không lồng nhau) và lớn nhất khoảng 1-2k, với hệ thống dành phần lớn thời gian nhàn rỗi (nhưng bùng nổ tới 100 tin nhắn tại bất kỳ thời điểm nào). Bước xử lý phụ trợ mất khoảng 10 phút cho mỗi tin nhắn.

Đối số xuất hiện khi một nhà phát triển đề xuất rằng sử dụng hệ thống tệp làm lớp nhắn tin là một giải pháp tồi, khi sử dụng một cơ sở dữ liệu quan hệ (MySQL), cơ sở dữ liệu noQuery (Redis) hoặc thậm chí là một lệnh gọi API REST đơn giản.

Cần lưu ý rằng Redis được sử dụng ở nơi khác trong tổ chức để xử lý tin nhắn xếp hàng.

Các đối số tôi đã nghe bị phá vỡ như sau

Có lợi cho các tập tin phẳng:

• Các tệp phẳng đáng tin cậy hơn bất kỳ giải pháp nào khác, vì tệp chỉ được chuyển từ thư mục "xem", sang thư mục "xử lý" sau khi được chọn và cuối cùng đến thư mục "đã hoàn tất" khi hoàn tất. Không có nguy cơ tin nhắn biến mất, ngăn chặn các lỗi ở mức độ rất thấp, điều này sẽ phá vỡ mọi thứ khác.

• Các tập tin phẳng đòi hỏi ít tinh tế kỹ thuật để hiểu - chỉ cần catnó. Không có truy vấn để viết, không có nguy cơ vô tình bật một tin nhắn ra khỏi hàng đợi và nó sẽ biến mất mãi mãi.

• Mã quản lý tệp đơn giản hơn API cơ sở dữ liệu theo quan điểm lập trình, vì đó là một phần của thư viện chuẩn của mọi ngôn ngữ. Điều này làm giảm độ phức tạp chung của cơ sở mã và số lượng mã bên thứ ba phải được đưa vào.

• Các nguyên tắc YAGNI tiểu bang mà các tập tin phẳng chỉ làm việc tốt ngay bây giờ, không có chứng minh nhu cầu thay đổi đến một giải pháp phức tạp hơn, do đó rời khỏi nó.

Có lợi cho cơ sở dữ liệu:

• Dễ dàng mở rộng cơ sở dữ liệu hơn một thư mục chứa đầy các tệp

• Các tệp phẳng có nguy cơ ai đó sao chép tệp "đã hoàn thành" trở lại thư mục "xem". Do tính chất của ứng dụng này (quản lý máy ảo), điều này có thể dẫn đến mất dữ liệu thảm khốc.

• Yêu cầu sự tinh tế kỹ thuật hơn đối với T / S, ứng dụng có nghĩa là các nhân viên ít học ít có khả năng làm hỏng việc gì đó bằng cách chỉ chọc vào mọi thứ.

• Mã kết nối DB, đặc biệt đối với một cái gì đó như Redis, ít nhất là mạnh mẽ như các chức năng quản lý tệp thư viện tiêu chuẩn.

• Mã kết nối DB rõ ràng (nếu không hoạt động) đơn giản hơn từ quan điểm của nhà phát triển, vì mức độ cao hơn so với thao tác tệp.

Từ những gì tôi có thể thấy, cả hai nhà phát triển đều có rất nhiều điểm hợp lệ.

Vì vậy, trong hai người này, nhà phát triển tệp pro hoặc nhà phát triển cơ sở dữ liệu chuyên nghiệp, người nào phù hợp hơn với thực tiễn tốt nhất về kỹ thuật phần mềm, và tại sao?

Chuyển sang một giải pháp liên quan đến cơ sở dữ liệu hoặc các hệ thống xếp hàng được đề cập bởi Ewan sẽ

• tạo sự phụ thuộc vào một hệ thống mới, phức tạp trong cả phụ trợ và giao diện
• giới thiệu sự phức tạp không cần thiết và một loạt các điểm thất bại mới
• tăng chi phí (bao gồm cả chi phí sở hữu)

Di chuyển / đổi tên các tệp trong một ổ đĩa được đảm bảo là nguyên tử trên tất cả các HĐH hiện tại, bất kể những khó khăn của chúng có thể liên quan đến những thứ như khóa tệp / bản ghi. Quản lý quyền ở cấp độ hệ điều hành phải đủ để khóa các phần chưa được xử lý và để ngăn chặn sự thao túng sai lầm vô tình / vô ý của các nhà khai thác được ủy quyền (quản trị viên / nhà phát triển). Do đó, cơ sở dữ liệu không có gì để cung cấp, miễn là hiệu suất của giải pháp hiện tại là hoàn hảo.

Tại công ty chúng tôi, chúng tôi đã sử dụng các giao diện dựa trên tệp tương tự trong nhiều thập kỷ với thành công lớn. Rất nhiều thứ khác đã đến và biến mất, nhưng các giao diện này vẫn tồn tại vì sự đơn giản hoàn toàn, độ tin cậy và khớp nối / phụ thuộc tối thiểu của chúng.

Tôi không nghĩ một trong hai giải pháp đó là một cách thực hành tồi, vì vậy việc trả lời đó là cách thực hành tốt nhất có thể khó khăn.

Tôi không tin hiệu trưởng YAGNI áp dụng ở đây nếu bạn đang xử lý theo quy mô. "Làm việc" là tương đối, nếu bạn có khả năng mất dữ liệu thảm khốc và ít khả năng mở rộng quy mô, tôi sẽ không thực sự xem xét việc đó. Tôi không chắc chắn chính xác quy mô mà bạn đang xử lý, nhưng nếu bạn có một lượng lớn các mục này, thì việc chuyển sang một hệ thống mới sẽ khó khăn hơn. Vì vậy, nếu đây là trường hợp, tôi muốn nói rằng một cơ sở dữ liệu là thực tiễn tốt nhất.

MongoDB hoặc redis (Tôi không có kinh nghiệm với redis, chỉ đọc những điều tốt) nên làm tốt vì dữ liệu của bạn sẽ phù hợp với nó (tài liệu json thường được thay đổi thành tài liệu BSON cho MongoDB). Nó có một lợi thế nữa là giữ được nhiều dữ liệu trong bộ nhớ thay vì tiềm năng đọc / ghi thường xuyên vào đĩa mọi lúc. Nó cũng đảm bảo việc đọc / ghi đồng thời không dẫn đến tham nhũng hoặc chặn.

Nếu hiệu trưởng YAGNI áp dụng ở đây và các tệp không bị nghẽn cổ chai, chúng sẽ mở rộng phạm vi và không có vấn đề nghiêm trọng, tôi sẽ nói rằng việc gắn bó với các tệp là "cách thực hành tốt nhất". Không có lý do để thay đổi bất cứ điều gì nếu không có vấn đề, có thể viết một số bài kiểm tra, nhấn mạnh nó và xem giới hạn và nút thắt của bạn ở đâu.

Tôi không chắc chắn nếu một cơ sở dữ liệu là giải pháp trong bối cảnh này. Nếu bạn đang liên lạc với mọi thứ trên cùng một máy chủ, một số loại IPC có thể được thực hiện, phải không?

Trong khi good ol lưu một tập tin và sao chép nó vào một thư mục đã thực hiện là một yếu tố chính của nhiều lớp truyền thông. với các hệ thống khung chính cũ và tương tự. Những kẻ 'chống đối' có một điểm; trong đó nó có nhiều vấn đề và trường hợp cạnh. Điều này rất khó đối phó nếu bạn cần 100% reliablitiy và xảy ra thường xuyên hơn khi bạn tăng quy mô và tần suất của tệp.

Nếu bạn kiểm soát cả hai mặt của giao dịch, tôi sẽ đề nghị bạn xem xét một số hệ thống xếp hàng đơn giản có sẵn. ZeroMQ, RabbitMQ, MSMQ, v.v. chứ không phải là cơ sở dữ liệu. Nhưng như bạn ngụ ý, nếu nó không bị vỡ ...

Giải pháp cơ sở dữ liệu là đúng. Nó giải quyết rất nhiều sự phụ thuộc vào một điều kiện máy chủ hoặc ranh giới cụ thể.

Cả hai đều là giải pháp tương tự ngoại trừ cơ sở dữ liệu không được lưu trữ trong một máy chủ cụ thể. Điều này được loại bỏ các vấn đề tường lửa / truy cập với hệ thống unix. Chúng tôi đã có trường hợp xóa "vô tình" trên các hệ thống tập tin và không ai có thể đổ lỗi.

Với cơ sở dữ liệu, bạn cũng có thể có vấn đề tương tự nhưng bạn có thể đặt kiểm toán hoặc chỉ chèn logic để loại bỏ xóa.

Ngoài ra trong hệ thống tệp nếu bạn cần đặt ứng dụng vào tên tệp, ví dụ OASIS, thì bạn sẽ cần tạo tệp OASIS.john_doe.system1.20160202. Điều này trở nên tẻ nhạt và có thể được trình bày dễ dàng hơn trong cơ sở dữ liệu. Bạn thậm chí có thể có các trường null trong cơ sở dữ liệu và logic dựa trên đó

Bạn cũng có thể dễ dàng cập nhật cơ sở dữ liệu thay vì toàn bộ thư mục tệp trong trường hợp có bất kỳ bản vá hoặc sửa lỗi nào bạn có thể muốn thực hiện trên các bảng. Tất nhiên bạn có thể làm điều đó trên hệ thống tập tin nhưng cập nhật cơ sở dữ liệu là trực giác hơn.

ví dụ: Bạn muốn chạy lại nhưng với một hệ thống khác với OASIS, hãy nói rằng DESERT và john_doe là doe_smith và ngày từ 20160101 đến 20151231

Dễ dàng tạo các hàng cho DESERT / doe_smith / 20151231 từ bộ ban đầu thay vì tạo các tệp đó bằng tập lệnh shell.

Vì vậy, từ khả năng đọc, điểm mở rộng của giải pháp cơ sở dữ liệu xem là tốt hơn.