Chiến lược kết nối hồ bơi: Tốt, Xấu hay Xấu xí?

Question

Tôi phụ trách phát triển và duy trì một nhóm các ứng dụng web tập trung xung quanh dữ liệu tương tự. Kiến trúc mà tôi quyết định vào thời điểm đó là mỗi ứng dụng sẽ có cơ sở dữ liệu và ứng dụng web-root của riêng chúng. Mỗi ứng dụng duy trì một nhóm kết nối với cơ sở dữ liệu riêng của nó và một cơ sở dữ liệu trung tâm cho dữ liệu được chia sẻ (thông tin đăng nhập, v.v.)

Một đồng nghiệp sẽ không quy mô vì có quá nhiều kết nối khác nhau sẽ không được có thể mở rộng và chúng ta nên tái cấu trúc cơ sở dữ liệu để tất cả các ứng dụng khác nhau sử dụng một cơ sở dữ liệu trung tâm và bất kỳ sửa đổi nào có thể là duy nhất đối với một hệ thống sẽ cần được phản ánh từ cơ sở dữ liệu đó và sau đó sử dụng một pool đơn do Tomcat cung cấp. Ông đã đặt ra rằng có rất nhiều "siêu dữ liệu" mà đi qua lại trên mạng để duy trì một hồ bơi kết nối.

Sự hiểu biết của tôi là điều chỉnh thích hợp chỉ sử dụng nhiều kết nối khi cần thiết trên các hồ khác nhau (ứng dụng âm lượng thấp nhận ít kết nối hơn, ứng dụng có khối lượng cao hơn ...) số lượng pools không vấn đề so với số lượng kết nối hoặc chính thức hơn là chênh lệch về chi phí cần thiết để duy trì 3 hồ chứa 10 kết nối là không đáng kể so với 1 hồ bơi gồm 30 kết nối.

Lý do đằng sau phá vỡ hệ thống thành thiết kế một ứng dụng một cơ sở dữ liệu là có khả năng sẽ có sự khác biệt giữa các ứng dụng và mỗi hệ thống có thể thực hiện sửa đổi trên lược đồ khi cần. Tương tự như vậy, nó loại bỏ khả năng chảy máu dữ liệu hệ thống thông qua các ứng dụng khác.

Rất tiếc, không có lãnh đạo mạnh mẽ trong công ty đưa ra quyết định khó khăn. Mặc dù đồng nghiệp của tôi đang sao lưu những lo lắng của mình chỉ với sự mơ hồ, tôi muốn đảm bảo rằng tôi hiểu các nhánh của nhiều cơ sở dữ liệu/kết nối nhỏ so với một cơ sở dữ liệu/kết nối lớn.

Answer 1

Thiết kế ban đầu của bạn dựa trên nguyên tắc âm thanh. Nếu nó giúp trường hợp của bạn, chiến lược này được gọi là horizontal partitioning or sharding. Nó cung cấp:

1) Khả năng mở rộng lớn hơn - bởi vì mỗi phân đoạn có thể sống trên phần cứng riêng biệt nếu cần thiết.

2) có sẵn Greater - bởi vì sự thất bại của một mảnh duy nhất không ảnh hưởng đến phân đoạn khác

3) hiệu suất Greater - bởi vì các bảng được tìm kiếm có ít hàng hơn và lập chỉ mục do đó nhỏ hơn trong đó sản lượng tìm kiếm nhanh hơn.

Đề xuất của đồng nghiệp của bạn sẽ đưa bạn đến một điểm thiết lập lỗi duy nhất.

Đối với câu hỏi của bạn về 3 hồ bơi kết nối có kích thước 10 và 1 hồ bơi kết nối có kích thước 30, cách tốt nhất để giải quyết cuộc tranh luận đó là với điểm chuẩn. Định cấu hình ứng dụng của bạn theo từng cách, sau đó thực hiện một số kiểm tra căng thẳng với ab (Apache Benchmark) và xem cách nào hoạt động tốt hơn. Tôi nghi ngờ sẽ không có một sự khác biệt đáng kể nhưng làm điểm chuẩn để chứng minh điều đó.

Answer 2

Câu hỏi hay. Tôi không biết cách nào tốt hơn, nhưng bạn đã cân nhắc thiết kế mã theo cách sao cho bạn có thể chuyển từ chiến lược này sang chiến lược khác với số lượng đau nhất có thể? Có thể một số đối tượng proxy cơ sở dữ liệu nhẹ có thể được sử dụng để che dấu quyết định thiết kế này từ mã cấp cao hơn. Chỉ trong trường hợp.

Answer 3

Cơ sở dữ liệu và chi phí khôn ngoan, 1 hồ bơi với 30 kết nối và 3 hồ bơi với 10 kết nối phần lớn là giả định tải trọng là như nhau trong cả hai trường hợp.

Ứng dụng khôn ngoan, sự khác biệt giữa việc có tất cả dữ liệu đi qua một điểm duy nhất (ví dụ: lớp dịch vụ) so với điểm truy cập ứng dụng có thể khá quyết liệt; cả về mặt hiệu suất và dễ thực hiện/bảo trì (xem xét việc phải sử dụng bộ nhớ cache được phân phối, chẳng hạn).

Answer 4

Nếu bạn có một cơ sở dữ liệu duy nhất và hai nhóm kết nối, mỗi kết nối có 5 kết nối, bạn có 10 kết nối với cơ sở dữ liệu. Nếu bạn có 5 hồ bơi kết nối với 2 kết nối mỗi nhóm, bạn có 10 kết nối tới cơ sở dữ liệu. Cuối cùng, bạn có 10 kết nối đến cơ sở dữ liệu. Cơ sở dữ liệu không có ý tưởng rằng hồ bơi của bạn tồn tại, không có nhận thức.

Mọi dữ liệu meta được trao đổi giữa hồ bơi và DB sẽ xảy ra trên mỗi kết nối. Khi kết nối được bắt đầu, khi kết nối bị ngắt, vv Vì vậy, nếu bạn có 10 kết nối, lưu lượng truy cập này sẽ xảy ra 10 lần (tối thiểu, giả sử tất cả chúng đều khỏe mạnh cho cuộc sống của hồ bơi). Điều này sẽ xảy ra cho dù bạn có 1 hồ bơi hoặc 10 hồ bơi.

Đối với "1 DB cho mỗi ứng dụng", nếu bạn không nói chuyện với một cá thể riêng biệt của cơ sở dữ liệu cho từng DB, thì về cơ bản không quan trọng.

Nếu bạn có một máy chủ DB lưu trữ 5 cơ sở dữ liệu và bạn có kết nối tới mỗi cơ sở dữ liệu (ví dụ, 2 kết nối cho mỗi), điều này sẽ tiêu tốn nhiều phí và bộ nhớ hơn cùng một DB lưu trữ một cơ sở dữ liệu. Nhưng chi phí đầu vào đó là không đáng kể, và hoàn toàn không đáng kể trên các máy hiện đại với bộ đệm dữ liệu có kích thước GB. Ngoài một điểm nhất định, tất cả các cơ sở dữ liệu quan tâm là lập bản đồ và sao chép các trang dữ liệu từ đĩa sang RAM và ngược lại.

Nếu bạn có một bảng dự phòng lớn được nhân đôi trên các DB, thì điều đó có thể gây lãng phí.

Cuối cùng, khi tôi sử dụng từ "cơ sở dữ liệu", ý tôi là thực thể logic mà máy chủ sử dụng để kết hợp các bảng. Ví dụ, Oracle thực sự thích có một "cơ sở dữ liệu" trên mỗi máy chủ, được chia nhỏ thành "lược đồ". Postgres có một số DB, mỗi trong số đó có thể có các lược đồ. Nhưng trong mọi trường hợp, tất cả các máy chủ hiện đại đều có ranh giới logic của dữ liệu mà chúng có thể sử dụng. Tôi chỉ sử dụng từ "cơ sở dữ liệu" ở đây. Vì vậy, miễn là bạn đang nhấn một trường hợp duy nhất của máy chủ DB cho tất cả các ứng dụng của bạn, các hồ bơi kết nối et al không thực sự quan trọng trong bức tranh lớn vì máy chủ sẽ chia sẻ tất cả bộ nhớ và tài nguyên trên các khách hàng khi cần thiết.

Answer 5

Vâng, câu hỏi tuyệt vời, nhưng nó không phải dễ dàng để thảo luận về cách sử dụng một vài cơ sở dữ liệu (A) cách tiếp cận hay những cái lớn (B):

1. Nó phụ thuộc vào cơ sở dữ liệu riêng của mình. Oracle, ví dụ: cư xử khác với Sybase ASE liên quan đến chiến lược LOG (và do đó KHÓA). Có thể tốt hơn nếu sử dụng một số cơ sở dữ liệu nhỏ khác nhau để giữ tỷ lệ tranh chấp thấp, nếu có nhiều ghi song song và DB đang sử dụng chiến lược khóa bi quan (Sybase).
2. Nếu không gian bảng của các cơ sở dữ liệu nhỏ không được trải rộng trên nhiều đĩa, tốt hơn nên sử dụng một cơ sở dữ liệu lớn để sử dụng bộ đệm (bộ đệm/bộ đệm) chỉ cho một. Tôi nghĩ điều này hiếm khi xảy ra.
3. Sử dụng (A) là tỷ lệ tốt hơn vì một lý do khác với hiệu suất. Bạn có thể di chuyển dữ liệu điểm nóng trên phần cứng khác (mới hơn/nhanh hơn) khi cần mà không cần chạm vào các cơ sở dữ liệu khác. Trong công ty cũ của tôi phương pháp này luôn rẻ hơn so với biến thể (B) (không có giấy phép mới).

Cá nhân tôi thích (A) vì lý do 3.

Answer 6

Thiết kế, kiến ​​trúc, kế hoạch và ý tưởng tuyệt vời không phù hợp nếu không có ý thức chung hoặc một phép toán đơn giản phía sau. Dưới đây là một phép tính đơn giản về lý do tại sao 10 hồ bơi với 5 kết nối không giống như 1 hồ bơi với 50 kết nối: mỗi hồ bơi được cấu hình với tối thiểu & kết nối mở tối đa, thực tế là nó thường sẽ sử dụng (99% thời gian) 50% số min (2-3 trong trường hợp 5 phút) nếu nó đang sử dụng nhiều hơn rằng hồ bơi này được cấu hình sai vì nó đang mở và đóng các kết nối mọi lúc (tốn kém) ... vì vậy chúng tôi 10 hồ bơi với 5 phút kết nối mỗi = 50 kết nối mở ... có nghĩa là 50 kết nối TCP; 50 kết nối JDBC trên đầu chúng ... (bạn có gỡ rối một kết nối JDBC không? Bạn sẽ ngạc nhiên bao nhiêu dữ liệu meta truyền theo cả hai cách ...) Nếu chúng ta có 1 pool (phục vụ cùng một cơ sở hạ tầng ở trên), chúng ta có thể thiết lập từ 30 đến 30 đơn giản vì nó sẽ có thể cân bằng các tính năng bổ sung hiệu quả hơn ... điều này có nghĩa là 20 kết nối JDBS ít hơn. Tôi không biết về bạn nhưng đối với tôi điều này là rất nhiều ... Các ma quỷ trong chi tiết - 2-3 kết nối mà bạn để lại trong mỗi hồ bơi để đảm bảo rằng nó không mở/đóng tất cả các thời gian. .. Thậm chí không muốn đi vào chi phí quản lý hồ bơi 10 ... (Tôi không muốn duy trì 10 hồ bơi mỗi một bao giờ quá khác nhau mà khác, phải không?) Bây giờ bạn bắt đầu tôi nếu tôi là tôi, tôi sẽ "bọc" DB (nguồn dữ liệu) với một ứng dụng duy nhất (lớp dịch vụ bất cứ ai?) sẽ cung cấp các dịch vụ khác (REST/SOAP/WS/JSON - chọn chất độc của bạn) và các ứng dụng của tôi đã thắng ' t thậm chí biết về JDBC, TCP, v.v. ồ, chờ google có nó - GAE ...