Hãy tìm hiểu một số vấn đề mà các nhà cung cấp phần
mềm như một dịch vụ (SaaS) mới xuất hiện cần phải xem xét khi phát triển các ứng
dụng hoặc sửa đổi những ứng dụng hiện có để chúng có thể cho nhiều bên thuê
trên đám mây. Bài viết này chỉ thảo luận các vấn đề cần xem xét từ góc nhìn cơ
sở dữ liệu, cụ thể là từ góc nhìn DB2 của IBM. Sáu trường hợp hoặc sáu phương
thức được mô tả.
Điện toán đám mây là thị trường mở mà trước đây các doanh nghiệp còn chưa
nhòm ngó đến. Một số công ty phần mềm bây giờ đang nghĩ đến việc cung cấp phần
mềm của họ như là một dịch vụ thay vì phương thức phát triển phần mềm thông
thường và bán chúng cho khách hàng của họ bằng cách sử dụng phương pháp phân
phối điển hình. Để trở thành nhà cung cấp phần mềm như là một dịch vụ (SaaS),
các công ty cần phải tìm được sự cân bằng đúng mức, khi tài nguyên được chia sẻ
giữa nhiều người thuê khác nhau để giảm chi phí, trong khi vẫn đảm bảo rằng
thông tin khách hàng được giữ kín riêng tư với các khách hàng khác. Không có
vấn đề gì nghiêm trọng hơn là việc có thể xem thông tin riêng tư của một bên
thuê từ tài khoản của một bên thuê khác. Ngoài thông tin riêng tư của người
thuê, các nhà cung cấp SaaS phải cung cấp một mức độ tuỳ biến nào đó cho khách
hàng của họ.
Trong một môi trường nhiều người thuê, công ty SaaS có thể giảm chi phí nếu
họ chia sẻ hoặc sử dụng lại nhiều hơn các nguồn tài nguyên của họ. Tuy nhiên,
càng nhiều công ty chia sẻ tài nguyên, thì công ty càng phải đối mặt với nhiều
rủi ro hơn, bởi vì sự cố ngừng một tài nguyên chia sẻ chung có thể nhiều khả
năng ảnh hưởng đến nhiều khách hàng. Các nguồn tài nguyên được chia sẻ nhiều
hơn cũng tăng thêm độ phức tạp cho giải pháp.
Hình 1 đã được sử dụng trong một số bài thuyết trình của IBM để cho thấy
tổng quan của một môi trường ứng dụng nhiều người thuê.
Đối với bài viết này, chúng tôi sẽ chỉ tập trung vào các tầng dữ liệu được
hiển thị ở phía bên phải của hình 1, và chúng tôi sẽ sử dụng phần mềm DB2. Các
tầng khác có thể được xử lý bởi phần mềm IBM khác, chẳng hạn như phần mềm
WebSphere Portlet factory (nhà máy Portlet của WebSphere), WebSphere Portal
Server (Máy chủ Portal của WebSphere), Tivoli® Directory Server (Máy chủ
Directory của Tivoli), Tivoli Directory Integrator (Trình tích hợp Directory
của Tivoli), Tivoli Provisioning Manager (Trình quản lý hậu cần của Tivoli),
Tivoli Monitoring (Giám sát của Tivoli), Tivoli Usage and Accounting Manager
(Trình quản lý sử dụng và kế toán của Tivoli) và v.v..
Tính năng cho nhiều người thuê tại tầng dữ liệu bằng cách sử dụng DB2 có
thể được sử dụng trong các tình huống khác nhau như được thảo luận trong sáu
trường hợp sau đây. Cũng nên nhớ rằng nếu bạn là một công ty nhỏ và muốn giảm
chi phí mua giấy phép, bạn có thể xem xét việc sử dụng phiên bản miễn phí của
DB2: DB2
Express-C. DB2 Express-C không có bất kỳ giới hạn nào về kích thước
cơ sở dữ liệu.
Trong trường hợp này, các tài nguyên sau được chia sẻ:
- Máy chủ cơ sở dữ
liệu
- Cá thể DB2
- Cơ sở dữ liệu
- Một hoặc nhiều
không gian bảng
- Một hoặc nhiều
bảng
Hình 2 là tổng quan về các tài nguyên được chia sẻ trong trường hợp này.
Các bảng inventory (kiểm kê hàng), customer (khách hàng) và order (đơn hàng) có
thông tin từ các khách hàng của nhiều bên thuê khác nhau..
Các lợi thế của trường hợp này là nó cung cấp chi phí thấp nhất, lưu trữ
thấp nhất, số tiền mua giấy phép DB2 tối thiểu và số lượng tối thiểu các cá thể
đám mây cần thiết.
Những bất lợi chính là nếu một bảng hỏng chẳng hạn, nó ảnh hưởng đến tất cả
khách hàng. Ngoài ra, có thể có thêm sự phức tạp của ứng dụng nữa khi luôn phải
cố gắng để xác định cần lấy ra những bản ghi nào trong các truy vấn của bạn để
phục vụ một người thuê đã cho.
Trong trường hợp này, các nguồn tài nguyên sau được chia sẻ:
- Máy chủ cơ sở dữ
liệu
- Cá thể DB2
- Cơ sở dữ liệu
Trong trường hợp này, lợi ích là chia sẻ cơ sở dữ liệu vẫn còn chi phí
tương đối thấp do vẫn còn sử dụng một giấy phép DB2 và một cá thể đám mây. Sự
cô lập dữ liệu là tốt bởi vì sử dụng các tập hợp bảng khác nhau. Tùy biến từ
phối cảnh dữ liệu dễ dàng hơn vì mọi người thuê đều có bộ bảng riêng.
Các điểm bất lợi là phải cần lưu trữ nhiều hơn vì bạn cần tạo ra một tập
hợp các bảng tương tự nhau cho mỗi người thuê. Vì vậy, khi so sánh với trường
hợp 1, bạn sẽ được sử dụng x lần nhiều hơn dung lượng lưu trữ, trong đó x là số
lượng người thuê. Sự phức tạp ứng dụng cũng tăng lên và không được linh hoạt
lắm, vì bây giờ bạn cần tùy chỉnh các ứng dụng của bạn để xử lý tên bảng khác
nhau và có khả năng là cả các cấu trúc bảng khác nhau trong trường hợp có tùy
biến riêng cho người thuê.
Trong trường hợp này, các nguồn tài nguyên sau được chia sẻ:
Theo trường hợp này, lợi ích là chi phí vẫn còn thấp, gần như giống với
trường hợp 2. Bạn vẫn cần một giấy phép DB2 và một cá thể đám mây. Cô lập dữ
liệu là tốt vì sử dụng các tập hợp bảng riêng biệt. So sánh với trường hợp 2,
có ít phức tạp hơn trong các ứng dụng bởi vì có thể sử dụng các câu lệnh SQL
hoàn toàn như nhau. Chuyển hướng truy vấn đến tập hợp các bảng cho trước được
thực hiện bằng cách thay đổi tên lược đồ bằng lệnh SET SCHEMA. Các tuỳ
chỉnh của một bảng đã cho đương nhiên sẽ làm phức tạp thêm ứng dụng của bạn.
Điểm bất lợi, giống như trong trường hợp 2, bạn vẫn phải sử dụng không gian
lưu trữ nhiều hơn bởi vì bạn sẽ tạo ra một tập hợp bảng cho mỗi người thuê.
Trong trường hợp này, các nguồn tài nguyên sau được chia sẻ:
Trong trường hợp này, lợi ích là chi phí vẫn còn thấp, gần như giống như
trong trường hợp 2. Bạn vẫn sẽ cần một giấy phép DB2 và một cá thể đám mây. Cô
lập dữ liệu là rất tốt bởi vì mỗi người thuê có cơ sở dữ liệu riêng của mình,
cơ sở dữ liệu này trong DB2 là một đơn vị độc lập. Mỗi cơ sở dữ liệu có thể
được định cấu hình và được duy trì một cách độc lập, mang lại nhiều linh hoạt
hơn. Sự phức tạp của ứng dụng ít hơn trường hợp 1. Cấu trúc bảng cho hầu hết
các bảng sẽ giống nhau trong tất cả các cơ sở dữ liệu. Nếu một người thuê có
yêu cầu tùy biến, thì có thể thay đổi định nghĩa bảng, nhưng điều này làm cho
các ứng dụng thêm phức tạp.
Điểm bất lợi là bạn sẽ cần lưu trữ nhiều hơn. Mỗi cơ sở dữ liệu DB2 tạo ra
danh mục của riêng mình, mà trong các sản phẩm cơ sở dữ liệu khác được gọi là từ
điển dữ liệu, do đó, sẽ phải tạo ra nhiều bảng, nhiều khung nhìn hơn cũng
như các đối tượng cơ sở dữ liệu khác từ hệ thống. Ngoài ra, trong trường hợp
của DB2, sẽ có giới hạn không quá 256 cơ sở dữ liệu hoạt động trong mỗi cá thể,
do đó, theo kịch bản này, chỉ không quá 256 người thuê có thể làm việc đồng
thời. Một nhược điểm nữa là mức tiêu thụ bộ nhớ của bạn cũng tăng lên, nó có
thể là sự phiền hà về hai mặt:
- Bạn có thể đạt
tới giới hạn bộ nhớ của ấn bản DB2 mà bạn đang sử dụng, và sẽ phải mua một
ấn bản DB2 đắt tiền hơn.
- Bạn có thể đạt
tới giới hạn bộ nhớ trong cá thể điện toán đám mây của bạn, trong trường
hợp này, bạn sẽ cần phải chọn cá thể đám mây đắt tiền hơn.
Trong trường hợp này, chỉ có các tài nguyên máy chủ cơ sở dữ liệu được chia
sẻ. Hình 6 là tổng quan về các tài nguyên được chia sẻ trong trường hợp này.
Trong kịch bản này, mỗi người thuê nhận được cá thể DB2 của riêng họ. Lợi
ích đầu tiên là kiểm soát truy cập tốt. Sự phức tạp của ứng dụng tương tự như
trường hợp 4. Tuy nhiên, người quản trị hệ thống phải định cấu hình các thông
số kết nối một cách thích hợp trong tất cả các cá thể, có nghĩa là phải làm
nhiều công việc hơn. Cấu trúc bảng cho hầu hết các bảng là như nhau, và giống
như trong trường hợp 4, đối với một người thuê nhất định, bạn có thể tùy chỉnh
một số bảng, nhưng phải thay đổi ứng dụng. Một lợi ích khác là mỗi cá thể và cơ
sở dữ liệu có thể được duy trì độc lập. Nếu bạn bỏ đi một cá thể, thì nó chỉ
ảnh hưởng đến một người thuê.
Một lần nữa, liên quan đến các bất lợi, bạn cần lưu trữ nhiều hơn các
trường hợp khác và bạn cũng có thể gặp phải các vấn đề liên quan đến bộ nhớ.
Mặc dù số lượng các cá thể trong DB2 được giới hạn bởi các giới hạn của hệ điều
hành, và mặc dù khởi chạy một cá thể không tiêu thụ nhiều bộ nhớ, nhưng nếu như
nhiều cá thể được khởi chạy, mỗi cá thể có một số cơ sở dữ liệu hoạt động tại
cùng thời điểm thì vẫn có thể gây ra các vấn đề bộ nhớ. Kết quả là, bạn có thể
bị buộc phải thay đổi ấn bản DB2 của mình để mua bạn một ấn bản mới đắt tiền
hơn hoặc thay đổi cá thể đám mây của bạn bằng một cá thể lớn hơn và đắt tiền
hơn. Ngoài những bất lợi này, sự phức tạp về quản trị cũng sẽ tăng lên, điều
này có thể khiến cho các công ty thuê thêm tài nguyên và ảnh hưởng trực tiếp
đến chi phí.
Trong trường hợp này, chỉ có các tài nguyên máy chủ cơ sở dữ liệu được chia
sẻ. Hình 7 là tổng quan của các tài nguyên được chia sẻ trong trường hợp này.
Với mục đích cung cấp phần mềm như một dịch vụ (SaaS), thực sự không có lợi
ích gì khi sử dụng cách tiếp cận này. Có một số nhược điểm:
- Nhiều bản sao của
mã DB2 hơn phải được lưu trữ trong cá thể đám mây của bạn, do vậy chiếm
nhiều không gian.
- Bạn phải cài đặt
và định cấu hình DB2 cho mỗi bản sao đã cài đặt, do đó mất nhiều thời gian
thiết lập quản trị.
- Có nhiều phức tạp
về ứng dụng, và loại môi trường này có thể gây nhầm lẫn cho các nhà phát
triển ví dụ như sẽ kết nối đến cơ sở dữ liệu nào, trong cá thể nào của bản
sao DB2 nào.
- Nó có những vấn
đề về bộ nhớ và tốn nhiều vùng lưu trữ, tương tự như trường hợp 5
Tóm lại, trường hợp này không có lợi ích thực sự, nhưng được bàn thêm trong
bài viết này để cho đầy đủ.
Như đã đề cập, việc tuỳ biến cho người thuê nào đó có thể thêm sự phức tạp
cho ứng dụng và quản lý. Phần này mô tả có thể xử lý tuỳ biến như thế nào bằng
cách sử dụng XML - cụ thể là công nghệ pureXML của DB2, công nghệ này cung cấp
sự linh hoạt hơn.
Hình này cho thấy người thuê có nhiều khách hàng và mỗi khách hàng có hồ sơ
khác nhau. Cột ID của người thuê (TID) ở cả hai bảng được sử dụng để xác định
người thuê. Dòng 1 và 3 trong bảng bên trái thuộc về một người thuê với TID là
1, hàng 2, 4, và 5 thuộc về người thuê khác với TID là 2.
Giả sử người thuê số 2 (TID = 2) có một quy tắc kinh doanh, theo quy tắc
này khách hàng không thể nhập vào thông tin về số điện thoại, do đó lưu trữ
thông tin về số điện thoại sẽ không được áp dụng đối với người thuê này. Tuy
nhiên, trong một môi trường nhiều người thuê với các bảng được chia sẻ (trường
hợp 1), công ty SaaS cần phải xem xét rằng người thuê khác lại muốn bao gồm các
thông tin về số điện thoại. Bằng cách sử dụng cơ sở dữ liệu SQL truyền thống
(bảng bên trái), nhà cung cấp SaaS có thể tạo ra bảng cột cố định, trong đó bao
gồm các cột cho tất cả các trường hợp về số điện thoại có thể có (số điện thoại
di động, số điện thoại nhà). Ngay cả nếu người thuê số 2 không cho phép nhập số
điện thoại trong hồ sơ khách hàng, thì vẫn có cột này. Vì vậy, có rất nhiều
"lỗ hổng" và dữ liệu bị rải rác, thưa thớt, như được đánh dấu bằng
các vòng tròn trong hình 8.
Ngoài ra, giả sử người thuê số 1 (TID = 1) muốn thay đổi yêu cầu của họ,
muốn rằng không chỉ lưu trữ số điện thoại di động và số điện nhà riêng mà còn
cả số điện thoại tại nơi làm việc. Trong tình huống này, bạn có thể phải thay
đổi bảng. Tuy nhiên, nếu bạn làm theo các quy tắc chuẩn hóa trong thiết kế cơ
sở dữ liệu, bạn thực sự cần tạo ra một bảng PHONE (Số điện thoại) riêng biệt.
Sau đó, bạn sẽ phải di chuyển dữ liệu và thay đổi các ứng dụng của bạn để truy
vấn SQL của bạn trỏ đến bảng PHONE mới và dùng phép nối bảng (join). Phương
pháp này không linh hoạt.
Ở bên phải của Hình 8 là phương pháp được đề xuất nhằm xử lý tùy chỉnh.
Bảng trong trường hợp này chỉ có hai cột, cột thứ hai được định nghĩa với kiểu
dữ liệu là XML. Bằng cách sử dụng XML, sẽ có nhiều linh hoạt hơn để xử lý các
thay đổi trong lược đồ cơ sở dữ liệu. Ngoài ra, với công nghệ pureXML của DB2,
hiệu suất được cải thiện rất nhiều. DB2 9.7 cũng cho phép tiến triển lược đồ,
nên các thay đổi trong tương lai với một lược đồ XML có thể được dễ dàng áp
dụng. Ngoài ra, DB2 cho phép nhiều lược đồ XML cho một cột, do đó mỗi người
thuê có thể sử dụng lược đồ XML riêng biệt.
Trong bài viết này, chúng tôi đã nói về những cân nhắc mà các nhà cung cấp
SaaS mới cần phải xem xét khi phát triển các ứng dụng mới hoặc sửa đổi những
ứng dụng hiện có. Bài viết này thảo luận các cân nhắc hoặc các trường hợp chỉ
từ góc độ cơ sở dữ liệu, cụ thể là từ phối cảnh của DB2. Sáu trường hợp hay
phương pháp đã được mô tả. Trong nhiều tình huống trong thế giới công nghệ
thông tin, bạn cần phải tìm sự cân bằng chi phí so với yêu cầu khi lựa chọn một
phương pháp nào đó so với phương pháp khác. Các phương pháp mà bạn chia sẻ
nhiều nhất cho phép sử dụng tốt hơn các nguồn lực và chi phí ít hơn. Tuy nhiên,
nếu không được thiết kế một cách đúng đắn, chúng có thể gây ra rất nhiều rắc
rối bởi vì sự cố của một tài nguyên có thể ảnh hưởng đến nhiều người thuê.
Ngoài ra, khi sử dụng các phương pháp mà bạn chia sẻ tài nguyên ít hơn có thể
làm tăng chi phí của bạn, mặc dù rủi ro cho người thuê khác là ít đi.
Là nhà cung cấp SaaS, bạn có thể phải lựa chọn các phương pháp, nơi bạn
chia sẻ tài nguyên. Nếu bạn có các biện pháp phòng ngừa cần thiết, chẳng hạn
như bằng cách sử dụng DB2 HADR, và các khả năng sẵn sàng cao và kiểm soát dự
phòng khác, bạn có thể làm giảm hoặc ngăn ngừa các vấn đề trong một môi trường
nhiều người thuê. Một vài trong số những kiểm soát khả năng phục hồi dữ liệu
được xây dựng sẵn trong đám mây.
Nguồn IBM
![[IMG]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_tWENO2XgoM8nBPguZekACn9cwXL3Mj1-442XX3F6TYOtB0zykV9ncvmPK7YQJ8ptFpN4B89R_-UDKbH1d_juRMUnKS1WWoQj6Gf8JaRpW7VTcwYUFizBxo=s0-d)
