Thiết kế cơ sở dữ liệu để cho nhiều bên thuê trên điện toán đám mây docx

Thiết kế cơ sở dữ liệu để cho nhiều bên thuê trên
điện toán đám mây
Giới thiệu
Đ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ê.

Hình 1. Hình 1. 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.
Về đầu trang
Trường hợp 1: Chia sẻ bảng
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

Hình 2. Hình 2. Trường hợp 1: Chia sẻ bảng

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.
Về đầu trang
Trường hợp 2: Chia sẻ cơ sở dữ liệu
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

Hình 3 là tổng quan về các tài nguyên được chia sẻ trong trường hợp này.

Hình 3. Hình 3. Trường hợp 2: Chia sẻ 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ê.
Về đầu trang
Trường hợp 3: Chia sẻ cơ sở dữ liệu và sử dụng tên lược đồ khác nhau
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
Hình 4 là tổng quan về các tài nguyên được chia sẻ trong trường hợp này.

Hình 4. Hình 4. Trường hợp 3: Chia sẻ cơ sở dữ liệu và sử dụng tên lược đồ khác nhau

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ê.
Về đầu trang
Trường hợp 4: Chia sẻ cá thể
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
Hình 5 là tổng quan về các tài nguyên được chia sẻ trong trường hợp này.

Hình 5. Hình 5. Trường hợp 4: Chia sẻ cá thể

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.
Về đầu trang

Trường hợp 5: Chia sẻ máy chủ cơ sở dữ liệu
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.

Hình 6. Hình 6. Trường hợp 5: Chia sẻ máy chủ cơ sở dữ liệu

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í.
Về đầu trang
Trường hợp 6: Chia sẻ máy chủ cơ sở dữ liệu với nhiều bản sao của DB2
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.

Hình 7. Hình 7. Trường hợp 6: Chia sẻ máy chủ cơ sở dữ liệu với nhiều bản sao của DB2

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 đủ.
Về đầu trang
Tùy biến trong tầng dữ liệu
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 8 cho thấy một ví
dụ.

Hình 8. Hình 8. Xử lý các tùy chỉnh cho các máy khách riêng biệt của người thuê riêng biệt

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.
Về đầu trang
Tóm tắ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.