Lược đồ ít / linh hoạt + Cơ sở dữ liệu ACID?

Tôi đang xem xét viết lại một ứng dụng VB dựa trên tiền đề (được cài đặt cục bộ) (lập hóa đơn + hàng tồn kho) dưới dạng một ứng dụng Clojure dựa trên web cho các khách hàng doanh nghiệp nhỏ. Tôi dự định sẽ được cung cấp dưới dạng ứng dụng SaaS cho khách hàng trong giao dịch tương tự.

Tôi đã xem xét các tùy chọn cơ sở dữ liệu: Lựa chọn của tôi là RDBMS: Postgresql / MySQL. Tôi có thể mở rộng tới 400 người dùng trong năm đầu tiên, thường là 20-40 lượt xem trang / ngày cho mỗi người dùng - chủ yếu cho các giao dịch không phải là chế độ xem tĩnh. Mỗi chế độ xem sẽ liên quan đến tìm nạp dữ liệu và cập nhật dữ liệu. Tuân thủ ACID là cần thiết (hoặc tôi nghĩ vậy). Vì vậy, khối lượng giao dịch không lớn.

Sẽ không có gì phải đắn đo khi chọn một trong hai tùy theo sở thích của tôi, nhưng với yêu cầu này, mà tôi tin là điển hình của ứng dụng SaaS: Schema sẽ thay đổi khi tôi thêm nhiều khách hàng / người dùng và cho mỗi khách hàng thay đổi yêu cầu kinh doanh (tôi sẽ cung cấp một số linh hoạt hạn chế chỉ để bắt đầu). Vì tôi không phải là chuyên gia DB, dựa trên những gì tôi có thể nghĩ và đã đọc, tôi có thể xử lý việc đó theo một số cách:

1. Có một thiết kế lược đồ RDBMS truyền thống trong MySQl / Postgresql với một DB thuê nhiều người thuê. Và thêm đủ các cột "thả nổi tự do" vào mỗi bảng để cho phép thay đổi trong tương lai khi tôi thêm nhiều khách hàng hoặc thay đổi cho một khách hàng hiện tại. Điều này có thể có một nhược điểm của việc truyền bá các thay đổi cho DB mỗi khi một thay đổi nhỏ được thực hiện cho Schema. Tôi nhớ đọc rằng trong các cập nhật lược đồ Postgresql có thể được thực hiện theo thời gian thực mà không cần khóa. Nhưng không chắc chắn, nó đau đớn hay thực tế như thế nào trong trường hợp sử dụng này. Ngoài ra, vì các thay đổi lược đồ cũng có thể giới thiệu các thay đổi SQL mới / nhỏ.
2. Có RDBMS, nhưng thiết kế lược đồ cơ sở dữ liệu một cách linh hoạt: gần với giá trị thực thể-thuộc tính hoặc chỉ là kho lưu trữ khóa-giá trị. (Ngày làm việc, FriendFeed chẳng hạn)
3. Có toàn bộ vật trong bộ nhớ dưới dạng đối tượng và lưu trữ chúng trong tệp nhật ký theo định kỳ. (Ví dụ: edval, lmax)
4. Sử dụng DB NoQuery như MongoDB hoặc Redis. Nhưng dựa trên những gì tôi có thể thu thập, chúng không phù hợp với trường hợp sử dụng này và không tuân thủ ACID hoàn toàn.
5. Sử dụng một số Dbs NewQuery như VoltDb hoặc JustoneDb (dựa trên đám mây) giữ lại hành vi tuân thủ SQL và ACID và là RDBMS "thế hệ mới".
6. Tôi đã xem neo4j (graphdb), nhưng không chắc nó có phù hợp với trường hợp sử dụng này không

Trong trường hợp sử dụng của tôi, hơn cả khả năng mở rộng hoặc tính toán phân tán, tôi đang xem xét một cách tốt hơn để đạt được "Tính linh hoạt trong Lược đồ + ACID + một số Hiệu suất hợp lý". Hầu hết các bài viết tôi có thể tìm thấy trên mạng đều nói về tính linh hoạt trong lược đồ là nguyên nhân dẫn đến hiệu suất (trong trường hợp của NoQuery DB) và khả năng mở rộng trong khi bỏ qua bên ACID / Giao dịch.

Đây có phải là trường hợp "một hoặc hoặc" tính linh hoạt của lược đồ so với ACID 'hoặc có cách nào tốt hơn không?

lựa chọn 1

Có một số lý do cho việc này, mà tôi sẽ giải thích dưới đây. Đầu tiên, đây là cách thực hiện.

• Sử dụng sự lựa chọn của bạn về nền tảng RDBMS tiêu chuẩn.

• Thiết lập lược đồ của bạn với một số trường có thể định cấu hình người dùng và làm cho ứng dụng của bạn tạo điều kiện thuận lợi cho việc cấu hình trên cơ sở cho mỗi bên thuê.

• Từ siêu dữ liệu cho mỗi bên thuê, bạn có thể tạo chế độ xem cho mỗi bên thuê dữ liệu của họ , có các bộ lọc được tích hợp và các cột được đặt tên từ siêu dữ liệu của bạn. Bất kỳ báo cáo nào được cung cấp cũng có thể kế thừa siêu dữ liệu. Nếu họ muốn xóa MI dữ liệu thì hãy cung cấp cho họ trích xuất dữ liệu giao dịch hoặc có thể một số ứng dụng MIS bổ sung trên một máy chủ khác nếu họ sẽ trả tiền cho điều đó.

• Đừng cố gắng cung cấp nhiều tùy chỉnh hơn mức này (nghĩa là không có thay đổi căn bản đối với lược đồ) trừ khi khách hàng sẵn sàng trả tiền cho cá thể riêng của họ và duy trì bản dựng tùy chỉnh.

Những lý do đằng sau điều này là:

• Các hệ thống cơ sở dữ liệu này sẽ xử lý loại khối lượng bạn mô tả trên phần cứng khá bình thường. Bạn thực sự không có loại khối lượng giao dịch xứng đáng với cơ sở dữ liệu NoQuery. Trừ khi bạn có một số lý do kiến ​​trúc khác để muốn một cái, không có nhiều điểm trong việc chảy máu.

• Họ là những công nghệ trưởng thành, được hiểu rõ.

• Quản lý hệ thống, sao lưu / khôi phục, sao chép, báo cáo và khắc phục thảm họa đều được sắp xếp tốt trên các nền tảng RDBMS.

• Bạn có thể nhận các thư viện máy khách bao gồm JDBC cho tất cả các nền tảng RDBMS chính.

• Lượt xem có thể được sử dụng để tùy chỉnh theo người dùng và được tạo từ siêu dữ liệu ứng dụng của bạn.

• Nó thực sự hiệu quả hơn các trường XML hoặc cấu trúc EAV.

Với PostgreSQL, bạn có tùy chọn sử dụng các cơ sở dữ liệu riêng biệt, các lược đồ hoặc chế độ xem riêng biệt để đối phó với nhiều bên thuê.

Sử dụng nhiều cơ sở dữ liệu (trong cùng một máy chủ cơ sở dữ liệu) làm cho việc quản trị trở nên phức tạp hơn vì mỗi cơ sở dữ liệu phải được quản lý riêng lẻ. Do đó, điều này chỉ được khuyến khích nếu an ninh giữa những người thuê nhà là mối quan tâm lớn nhất.

Các lược đồ riêng biệt cung cấp rất nhiều tính linh hoạt và bảo mật nhưng làm cho việc nâng cấp trở nên phức tạp hơn vì chúng phải được áp dụng riêng lẻ và có lẽ chỉ cần thiết nếu người thuê của bạn sử dụng các cấu trúc bảng hoàn toàn khác nhau; điều này là không thể nếu họ đang sử dụng cùng một ứng dụng.

Chế độ xem cho phép người thuê xem các phần khác nhau của cấu trúc bảng chung và cho phép bạn kiểm soát bảng nào, cột nào và hàng nào họ có quyền truy cập. Nhắc nhở duy nhất là ứng dụng của bạn phải đảm bảo nó chỉ sử dụng các khung nhìn đó chứ không phải các bảng cơ sở nếu không có khả năng xảy ra rò rỉ dữ liệu giữa các bên thuê vì lỗi phần mềm.

Bạn không thực sự cần tạo các cột trước các yêu cầu ứng dụng. Các cột có thể được thêm vào các bảng một cách linh hoạt (không có bất kỳ tác động đáng chú ý nào đối với người dùng) và các chế độ xem cũng có thể được cập nhật động. Bạn chỉ cần suy nghĩ về thứ tự thực hiện thay đổi - tức là. thay đổi bảng, sau đó xem mã ứng dụng.

Mối quan tâm tiềm năng duy nhất của bạn là nếu bạn cần thêm một cột mới cần được thêm vào một chỉ mục hiện có hoặc yêu cầu một chỉ mục mới. Đó là khi bảng có thể bị khóa khi sử dụng trong khi chỉ mục đang được xây dựng - nhưng PostgreQuery hỗ trợ khả năng xây dựng các chỉ mục đồng thời mà không khóa bảng. Điều này hoạt động tốt trừ khi chỉ mục mới cần phải là duy nhất và tìm thấy một vi phạm duy nhất.

Bạn có thể không cần cơ sở dữ liệu NoQuery vì chúng loại bỏ lược đồ khỏi cơ sở dữ liệu một cách hiệu quả và yêu cầu ứng dụng quản lý nó thay thế. Có vẻ như khối lượng của bạn không đòi hỏi sự hy sinh đó.