2009-05-29 39 views
5

Tại nơi làm việc, chúng tôi có một số ứng dụng với cơ sở dữ liệu trong máy chủ SQL tập trung. Bất cứ khi nào một ứng dụng cần làm việc với dữ liệu từ một ứng dụng khác, nó chỉ truy vấn nó hoặc cập nhật nó thông qua cơ sở dữ liệu. Tôi tin rằng đây là mẫu "Cơ sở dữ liệu được chia sẻ" như được mô tả trong sách Mẫu tích hợp doanh nghiệp (Hohpe & Woolf).Tái cấu trúc cách xa mô hình Cơ sở dữ liệu được chia sẻ

Các phụ thuộc cơ sở dữ liệu chéo này đang gây ra cho chúng ta nhiều, nhiều vấn đề nhức đầu. Lớn nhất trong số này ngay bây giờ là chúng tôi đang chạy vào các vấn đề hiệu suất trên máy chủ SQL và không thể mở rộng quy mô do các phụ thuộc của cơ sở dữ liệu chéo. Tôi nghĩ rằng những gì chúng ta nên làm là di chuyển ra khỏi mô hình cơ sở dữ liệu được chia sẻ đối với một hệ thống nhắn tin như được mô tả trong cuốn sách EIP. Mỗi ứng dụng sẽ chịu trách nhiệm đối với tất cả dữ liệu của chính nó và các ứng dụng khác muốn truy cập dữ liệu đó sẽ nhận được thông qua dịch vụ (trên xe buýt nhắn tin?).

  • Chúng tôi bắt đầu tái cấu trúc theo hướng mẫu nhắn tin ở đâu?
  • Chúng ta có bắt đầu bằng cách tái cấu trúc một trong các ứng dụng để quản lý cơ sở dữ liệu ứng dụng của riêng mình không?
  • Sau đó, các ứng dụng khác hiện được tích hợp với ứng dụng nào thông qua cơ sở dữ liệu?
  • Đây có phải là cách tốt nhất để tách rời các phụ thuộc cơ sở dữ liệu của chúng ta hay chúng ta nên bắt đầu từ nơi khác?

Trả lời

7

Tôi muốn đề xuất quá trình chuyển đổi 3 pha.

  1. Thêm lớp nhắn tin cho từng ứng dụng của bạn.
  2. Thay đổi tất cả quyền truy cập dữ liệu ứng dụng chéo để sử dụng lớp thông báo mới được tạo.
  3. Quy mô cơ sở dữ liệu (hiện tại độc lập) nếu cần.

Ngoài ra, giả sử bạn có 3 ứng dụng; A, B và C.

Bạn cũng có thể xem đây là 3 hiệu ứng chuyển tiếp riêng biệt:

  • Application Một

    • Thêm Tin nhắn đến A
    • Thay đổi cuộc gọi đến A B & C
  • Ứng dụng B

    • Thêm Tin nhắn đến B
    • Thay đổi cuộc gọi đến B trong một & C
  • Application C

    • Thêm Nhắn tin để C
    • Thay đổi cuộc gọi đến C A & B

Tại thời điểm này trong quá trình kết quả giống như ở cuối giai đoạn 2 và giai đoạn 3 có thể tiếp tục. Sự khác biệt đơn giản là liệu nó có hiệu quả hơn để tập trung vào một loại tái cấu trúc hay tập trung vào một ứng dụng hay không.

1

Nhắn tin chắc chắn có thể là một trong những cách thanh lịch hơn. Tuy nhiên, nó cũng đòi hỏi một chút công việc và sẽ phải thay đổi theo thời gian khi mỗi cơ sở dữ liệu thay đổi. Chúng tôi đã thực hiện cách tiếp cận "dễ dàng hơn" bằng cách đơn giản có mỗi ứng dụng biết cách đăng nhập vào cơ sở dữ liệu khác, và sau đó truy vấn từng cơ sở dữ liệu từ đó. Chúng tôi thấy rằng hầu hết các truy vấn cơ sở dữ liệu chéo khá nhẹ và do đó không tạo ra một cơ sở mã đáng kể trong ứng dụng thứ hai. Có một số bản sao của các truy vấn chọn lọc, nhưng nó đã được ít công việc hơn một hệ thống tin nhắn sẽ có được.

Tất cả phụ thuộc vào mức độ bạn sẽ đẩy và kéo dữ liệu xung quanh. Nếu nó là đáng kể, sau đó nhắn tin là cách tốt nhất để đi. Nếu nó là tối thiểu, sau đó có lẽ một kết nối mới đơn giản với cơ sở dữ liệu khác là một cách để đi.

1

Tôi cũng sẽ xem xét cách các ứng dụng sử dụng cơ sở dữ liệu. Thông thường một cơ sở dữ liệu (cả hai thiết kế & thực hiện) nên rơi vào một trong hai loại khác nhau: giao dịch (OLTP) hoặc báo cáo (OLAP).

Cơ sở dữ liệu giao dịch được thiết kế tốt (và được triển khai) sẽ cung cấp hiệu suất tuyệt vời trong một kịch bản ứng dụng Line-Of-Business điển hình; tương tự như vậy, một cơ sở dữ liệu báo cáo được thiết kế tốt (và được triển khai) sẽ cung cấp hiệu suất tuyệt vời khi truy vấn một lượng lớn dữ liệu phức tạp.

Sự khác biệt quan trọng là sự khác biệt giữa 'thời gian thực' và 'gần thời gian thực'.

Giả sử ứng dụng khác nhau của bạn cần thực hiện cả hai thao tác giao dịch (thời gian thực) và một số báo cáo về dữ liệu hiện tại/cũ hơn; bạn sẽ cần hai kho dữ liệu: một giao dịch được xây dựng chỉ dành riêng cho tốc độ hoạt động để hỗ trợ các hoạt động 'thời gian thực' của các ứng dụng và một dữ liệu khác chứa dữ liệu 'lịch sử' sẽ được xây dựng hoàn toàn để báo cáo.

Bí quyết là tìm ra số lượng dữ liệu bạn cần lưu giữ trong kho lưu trữ dữ liệu giao dịch và khi nào/cách di chuyển nó đến kho dữ liệu báo cáo.

Các vấn đề liên quan