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

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. Môi trường ứng dụng nhiều người thuê
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.


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. 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.
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. 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ê.

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. 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ê.
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. 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.


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. 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í.


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. 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 đủ.


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. 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.