Một cơ sở dữ liệu lớn so với một số người nhỏ hơn

Chúng tôi có một tình huống là chúng tôi có thể (A) triển khai các phiên bản của một ứng dụng trong một cơ sở dữ liệu MySQL bằng cách sử dụng tiền tố bảng hoặc (B) sử dụng các cơ sở dữ liệu MySQL khác nhau cho mỗi phiên bản của ứng dụng, ví dụ:

Thiết lập một":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

Kết quả cuối cùng là một db lớn với nhiều bảng.

Cài đặt "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

Kết quả cuối cùng là nhiều cơ sở dữ liệu với một số bảng.

Tất cả mọi thứ đều bằng nhau (ví dụ: lượng dữ liệu, số lượng phiên bản ứng dụng, v.v.), những ưu và nhược điểm của cách tiếp cận là gì? Điều gì sẽ gây bất lợi cho hiệu suất và bảo trì cơ sở dữ liệu? Ứng dụng này dựa trên PHP 5, chạy trên Apache 2.x và chúng tôi đang chạy MySQL 5.x.

Rất cám ơn cho thời gian và suy nghĩ của bạn!

Tôi đã chạy một hệ thống với phần tốt nhất trong một nghìn cơ sở dữ liệu, trải rộng trên nhiều máy chủ. Chúng đều có cấu trúc giống hệt nhau và được đồng bộ hóa với cơ sở dữ liệu mẫu trên mỗi máy.

Điều này cho phép tôi khả năng di chuyển cơ sở dữ liệu từ db này sang db khác nếu một cơ sở bị quá tải và khi kết hợp máy khách thay đổi, tôi có thể tạo cơ sở dữ liệu mới trên các máy chủ khác nhau để cân bằng tải trên các máy chủ. Đây là lợi thế lớn nhất tôi có được từ hệ thống, trong đó tôi có nhiều khối tin lớn thực hiện đồng thời nhiều truy vấn phức tạp trên các máy chủ riêng biệt.

Điều tuyệt vời ở đây là bạn có thể thêm các máy chủ vào cấu hình ở tốc độ của riêng mình, vì mỗi máy chủ bắt đầu bị quá tải, thêm một máy chủ khác vào hỗn hợp, di chuyển một số dbs qua máy chủ mới và kết thúc tốt đẹp tải cân bằng bộ máy chủ. Một cách thực sự tốt đẹp và đơn giản để thêm quy mô vào hệ thống khi cần thiết!

Lý do tôi thực hiện với cách tiếp cận này thay vì cách tiếp cận cơ sở dữ liệu khổng lồ duy nhất, là kích thước tuyệt đối của cơ sở dữ liệu tiềm năng sẽ được tạo ... mỗi 1000 cơ sở dữ liệu có 200 bảng và nhiều bảng riêng lẻ trong mỗi bảng cơ sở dữ liệu bao gồm hàng trăm triệu hàng dữ liệu!

Một cấu hình cơ sở dữ liệu sẽ yêu cầu một số bảng nhất định (khoảng 8 trong số chúng) để có hàng tỷ hàng dữ liệu và tổng kích thước db sẽ có trên 10Tb. Chúng tôi có thể có nhiều máy chủ với 5Tb dung lượng lưu trữ RAID 10, với nhiều cơ sở dữ liệu trên mỗi máy chủ.

Đó là những gì tôi sẽ làm! Hy vọng nó sẽ giúp bạn đưa ra quyết định ... :)

Là ứng dụng bạn đang xây dựng một ứng dụng SaaS? Nếu vậy, tôi khuyên bạn nên xem xét cách tiếp cận thứ ba - có một DB, với cấu trúc chung cho tất cả các trường hợp ứng dụng có một điểm khác biệt - thêm một cột userid / applicationid trong tất cả các bảng. Điều này sẽ làm giảm đáng kể chi phí phát triển / bảo trì ứng dụng của bạn. Theo kinh nghiệm của tôi, đây là một trong những cách tiếp cận tốt nhất để lưu trữ dữ liệu nhiều người thuê.

Cũng thấy điều này trắng tuyệt vời này của Microsoft về kiến ​​trúc dữ liệu nhiều bên thuê

Nó cũng nêu bật những ưu điểm / nhược điểm trên các phương pháp bạn đã đề cập.

Thiết lập B dễ quản lý hơn

Mỗi người tablenngồi trong một thư mục khác nhau. Điều đó có thể rất có lợi nếu bạn không muốn kiểm tra giới hạn hệ điều hành .

Ví dụ: chủ nhân của tôi lưu trữ MySQL cho một hệ thống CRM của các đại lý xe hơi. Khách hàng có 800 đại lý. Mỗi cơ sở dữ liệu đại lý có 160 bảng. Đó là 128.000 bảng.

• Trong Cài đặt A, tất cả 128.000 bảng sẽ nằm dưới một cơ sở dữ liệu.
• Trong Cài đặt B, mỗi bộ 160 bảng nằm trong thư mục con bên dưới / var / lib / mysql.

Từ quan điểm của HĐH và khả năng xử lý các nút i (hoặc bảng FAT cho Windows), bao gồm số lượng tệp tối đa cho mỗi thư mục:

• Trong Cài đặt A, bạn sẽ lo lắng về 128.000 tệp trong một thư mục. Hệ điều hành của bạn có thể hỗ trợ nhiều tệp trong một thư mục không?
• Trong Cài đặt B, không phải lo lắng như vậy.

Nếu bạn phải sử dụng các cấu trúc bảng bằng cách sử dụng ALTER TABLEhoặc một số DDL khác:

• Trong Thiết lập A, bạn sẽ phải tạo kịch bản DDL cần thiết bằng cách sử dụng PHP (hoặc tập lệnh MySQL chuyên dụng) theo tên bảng cụ thể và các truy vấn tương ứng trước khi truy cập vào nó và thực hiện các thay đổi
• Trong Cài đặt B, Kết nối với cơ sở dữ liệu bên phải, sau đó truy cập vào cùng một bảng được đặt tên mỗi lần. Mô hình truy cập sẽ luôn sạch sẽ:
  • Cơ sở dữ liệu cụ thể
  • Thư mục cụ thể dưới /var/lib/mysql
  • Tên bảng Specfic.

Nếu bạn muốn đặt các cơ sở dữ liệu khác nhau trên các đĩa khác nhau:

• Trong Cài đặt A, các liên kết tượng trưng cho mỗi bảng được chuyển sang một đĩa riêng sẽ chỉ làm trầm trọng thêm vấn đề "số lượng nút trong một thư mục". Đĩa I / O và truy cập bảng tổng thể phức tạp hơn và tăng tải máy chủ tổng thể kể từ khi.frm các tệp được truy cập nhiều lần.
• Trong Cài đặt B, chỉ cần di chuyển toàn bộ thư mục cơ sở dữ liệu vào một giá đỡ dữ liệu riêng biệt. Đĩa I / O có thể được phân phối theo yêu cầu.
• CAVEAT: Rất nản lòng với InnoDB

Nói một cách ẩn dụ, bạn muốn có cái nào hơn?

• một căn hộ khổng lồ với một phòng ngủ, một phòng tắm và một nhà bếp (SetupA)
• nhiều căn hộ, mỗi căn hộ có phòng ngủ, phòng tắm và nhà bếp riêng (SetupB)

Khi nói đến việc sửa chữa bộ tản nhiệt trong căn hộ:

• Với Thiết lập A, mọi người thuê nhà đều có thể bất tiện và phải tham gia vì bạn phải nói chuyện với những người thuê bị ảnh hưởng trước mặt mọi người như đó là việc của mọi người
• Với Cài đặt B, ngoài việc nghe thấy tiếng đập vào tường hoặc trong đường ống, người thuê có thể tiếp tục cuộc sống riêng tư của họ
• Danh sách này và ẩn dụ của nó có thể đi và về

IHMO Mặc dù ngân sách có thể là động lực để quyết định thiết kế / cơ sở hạ tầng, tôi sẽ dễ dàng ủng hộ việc phân tách cơ sở dữ liệu trên mỗi khách hàng.

Tôi cũng có một sản phẩm SaaS và sử dụng cùng một thiết lập như Dave Rix đã đề cập.

Mỗi khách hàng có cơ sở dữ liệu riêng của họ

Tôi muốn đưa ra một vài gợi ý nữa:

• Bạn nên có một "bộ điều khiển" cơ sở dữ liệu cân bằng tải (master-master), lưu trữ vị trí cơ sở dữ liệu (ip), tên cơ sở dữ liệu và tên khách hàng. Bộ điều khiển này là nơi ứng dụng của bạn biết nơi mỗi cơ sở dữ liệu khách hàng.

• Ứng dụng của bạn có thể ở bất cứ đâu bạn muốn - bạn có thể có cơ sở dữ liệu cho nhiều trung tâm dữ liệu trên toàn cầu.

• Ứng dụng của bạn có thể phát triển nhiều như bạn muốn. Nếu đó là Web SaaS, bạn có thể tạo trang trại máy chủ web cân bằng tải trỏ đến từng cơ sở dữ liệu, theo thời gian khi khách hàng đăng nhập.

• Bạn có thể tạo XEM / Cơ sở dữ liệu tùy chỉnh cho một số khách hàng - mà không ảnh hưởng đến những người khác. Điều đó quan trọng nếu bạn cố gắng cung cấp tùy chỉnh như một phần của doanh nghiệp của bạn.

• Bạn có thể thiết lập hai trang trại web + trang trại cơ sở dữ liệu: một cho "EDGE" và một cho các bản phát hành "ỔN ĐỊNH". Sau đó, bạn sẽ cần phải có một nhóm nhỏ khách hàng sẵn sàng thử nghiệm mọi thứ và xác nhận rằng mọi thứ đều hoạt động như mong đợi (nói cách khác, đảm bảo chất lượng [QA]), trước khi bạn áp dụng cho tất cả khách hàng của mình.

• Bạn nên có một công việc sao lưu tự động trên mỗi cơ sở dữ liệu ít nhất một lần một ngày.

• Bạn nên có một máy chủ khác để nhân rộng. Một máy chủ lưu trữ có thể sao chép nhiều cơ sở dữ liệu (sử dụng các cổng khác nhau cho mỗi máy chủ tại cùng một máy chủ) nếu bạn không đủ khả năng cung cấp cùng một lượng máy chủ lưu trữ "chính" và "nô lệ".

  Ví dụ: 5 máy chủ chính + 1 máy chủ nô lệ với 5 cơ sở dữ liệu chạy trên các cổng khác nhau - chỉ cần có đủ RAM để làm việc đó.

• Bạn nên làm một công cụ "di chuyển" để di chuyển một cơ sở dữ liệu sang một máy chủ khác bất cứ lúc nào bạn muốn.

• Bạn nên di chuyển khách hàng VIP đến máy chủ cơ sở dữ liệu an toàn / khả dụng hơn để giữ cho doanh thu của bạn được bảo vệ. Hãy nhớ rằng, nhiều lần 20% khách hàng đại diện cho 80% doanh thu của bạn. Chăm sóc khách hàng đặc biệt.

• Bạn nên có một trình thu thập "rác" sao lưu, để thực hiện "sao lưu cuối cùng" và xóa cơ sở dữ liệu khi khách hàng rời khỏi công ty của bạn.

• Bạn phải có một hình ảnh cơ sở dữ liệu nơi bạn xuất và sử dụng cho các tài khoản mới.

• Bạn phải có một công cụ vá cơ sở dữ liệu để áp dụng các bản vá mới cho các tài khoản hiện có.

• Giữ các phiên bản của tất cả các bản vá SQL của bạn, sử dụng một công cụ tạo phiên bản như lật đổ hoặc git và tạo số riêng của bạn. xxx-4.3.0.sql - đôi khi việc vá bị lỗi và bạn phải biết cách khôi phục / hoàn thành nhiệm vụ vá.

Vâng, đây là tất cả những gì tôi làm trong công ty của mình với một sản phẩm có khoảng 5k cơ sở dữ liệu với khoảng 600 bảng mỗi cái.