Cơ sở hạ tầng cho DB cao đồng thời, cao

Yêu cầu của tôi là:

• 3000 kết nối
• 70-85% Viết so với Đọc

Hiện tại, chúng tôi đang tối đa hóa một CPU cao, cực lớn với 700 kết nối. Tất cả 8 lõi được tối đa. Chúng tôi nghĩ rằng đó là số lượng kết nối đồng thời vì bộ nhớ là tốt. Việc viết chính nó là rất đơn giản (xác nhận những điều chậm). Để mở rộng quy mô lên 3000, chúng tôi cần đến nhiều máy chủ, các tùy chọn hiện tại:

• MySQL Shending
• Cụm MongoDB
• Cassandra
• Hadoop & MySQL (Bộ nhớ cache Hadoop, kết xuất đơn vào MySQL)
• MongoDB & MySQL (thay vì Hadoop, chúng tôi sử dụng mongo cho bộ đệm)

Để xử lý số lượng kết nối này, một số câu hỏi:

1. MySQL Shending có thể xử lý các kết nối đồng thời không?
2. Bất kỳ bậc thầy duy nhất nào có thể xử lý các kết nối đồng thời này, hoặc một đầu nhiều đầu như Mongo là một lựa chọn tốt hơn?

Tôi xin lỗi nếu tôi không mô tả tốt vấn đề của mình. Hãy đặt câu hỏi.

Nếu bạn đang sử dụng MySQL làm cơ sở dữ liệu chính, bạn có thể muốn xem xét sử dụng Cấu trúc liên kết hình sao thông qua Sao chép MySQL.

Bây giờ, trước khi bạn nói UGHHH, ROFL và OMG với bản sao MySQL, hãy nghe tôi nói.

Cấu trúc liên kết hình sao cho phép bạn ghi vào một máy chủ DB (được gọi là Trình phân phối [DM]) và gửi các lệnh SQL đến một số máy chủ DB. Làm thế nào để bạn thiết lập một cơ sở hạ tầng DB như vậy?

Dưới đây là Mô tả

Bạn có 5 máy chủ DB (máy chủ A, B, C, D, E)

Máy chủ A

• Trong thiết lập bản sao MySQL, nó sẽ là Master
• Đóng vai trò đặc biệt là DM
• Bậc thầy của máy chủ B, C, D, E
• Tất cả các bảng đều sử dụng công cụ lưu trữ BLACKHOLE (/ dev / null)
• Chỉ lưu trữ nhật ký nhị phân
• Máy kim loại trần
• Những lợi ích
  • Viết rất nhanh vì tất cả các bảng trên DM đều sử dụng BLACKHOLE
  • Độ trễ mạng ít là vấn đề vì số lần đọc chiếm 15-30% hoạt động DB
  • Tất cả nô lệ được cập nhật nghiêm ngặt từ DM

Máy chủ B, C, D, E

• Nô lệ của A
• Máy chủ một cơ sở cho các CHỌN nặng
• Máy chủ có thể là ảo hoặc kim loại trần
• Đối với tất cả các máy chủ có bảng người dùng sử dụng công cụ lưu trữ InnoDB
  • Nó có thể phục vụ như một máy chủ DB dự phòng ấm áp
  • Sao lưu không xâm nhập có thể được chạy chống lại nó
• Đối với tất cả các máy chủ có bảng người dùng sử dụng công cụ lưu trữ MyISAM
  • Thiết lập với ý kiến ​​chỉ đọc
  • Các bảng có thể được định dạng lại hàng của chúng để làm tăng số lần đọc

Tôi đã viết bài về điều này trước đây

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

Để giữ bản sao MySQL trong hình dạng hàng đầu

• Sử dụng MySQL 5.5
• Sử dụng nhân rộng bán đồng bộ
• Điều chỉnh InnoDB để thu hút nhiều CPU hơn

MySQL Cluster có thể là một cách tiếp cận khác để shending. Kiểm tra bài ở đây .

Tôi cũng là một fan hâm mộ lớn của Cassandra, nhưng nó phụ thuộc rất nhiều vào mô hình dữ liệu của bạn và các truy vấn bạn muốn thực hiện. Cassandra trong sáng nhanh để viết, bởi vì chúng luôn tuần tự trên đĩa.

Nếu bạn định đi nhiều đầu (mà bạn có thể cần nếu bạn thực sự cần kết nối hoạt động 3K) thì có lẽ tôi sẽ nhìn vào Rịa hoặc có thể là Cassandra. Nó thực sự phụ thuộc vào những gì ứng dụng của bạn làm như thế nào là những thứ này sẽ phù hợp như thế nào, nhưng từ những gì bạn đã mô tả tôi nghĩ rằng nó sẽ phù hợp với một cái gì đó như Rịa.

Điều đó nói rằng, một cách tiếp cận phân đoạn có vẻ khá khả thi, nếu bạn có thể tìm ra một cách tốt để phân đoạn dữ liệu và có thể giảm thiểu bất kỳ nhu cầu nào đối với các công cụ phân mảnh chéo. Tôi sẽ tránh xa bất kỳ thứ gì trong vòng / sao / mmm trong mysql và chỉ cần giữ nguyên trạng thái thẳng. Trên thực tế, nếu bạn sẵn sàng sử dụng Postgres, bạn có thể tạo nguyên mẫu khá dễ dàng bằng cách sử dụng các lược đồ trên một cái gì đó như heroku, sau đó phân tách và tách cơ sở dữ liệu khi chúng bắt đầu vượt qua các nút riêng lẻ.

Ồ, và trong khi tôi nghĩ rằng bạn có thể cố gắng mở rộng quy mô như thế này theo chiều dọc (nút đơn xử lý tất cả các liên kết 3K), tôi không nghĩ bạn có thể làm điều đó trong đám mây.

Nếu đó là một tùy chọn cho ứng dụng cụ thể của bạn, có thể bạn có thể sử dụng một số cách không đồng bộ để ghi dữ liệu vào cơ sở dữ liệu của mình (hàng đợi công việc, chèn theo đợt ...) và / hoặc chuyển đi nhiều kết nối máy khách khỏi cơ sở dữ liệu của bạn với một số proxy ở phía trước .

Với shending, bạn thường có thể chia tỷ lệ tốt (2x db-server == 2x kết nối), nhưng nó phụ thuộc nhiều vào bản chất của tập dữ liệu của bạn và cách bạn có thể chia nó thành các phân đoạn.

Cá nhân tôi thích MongoDB vì nó dễ quản trị, khả năng mở rộng, dễ sử dụng chung. Ngoài ra, trừ khi tôi thực sự cần RDBMS, tôi sẽ sử dụng không có SQL.

Như đã nói, hãy chọn DB có ý nghĩa nhất cho ứng dụng của bạn. Nếu bạn cần Giao dịch hoặc không thể thiết kế ứng dụng của mình mà không có Joins (hoặc đơn giản là có ý nghĩa hơn với chúng) thì hãy sử dụng RDBMS (MySQL, PostGres, v.v.)

Trong khi cá nhân tôi thích MongoDB, ý tưởng rằng MySQL không mở rộng quy mô hoặc không thể xử lý tỷ lệ giao dịch cao hoàn toàn sai. Nhóm Kỹ thuật Facebook (và nhóm MySQL trong đó) đi sâu vào chi tiết. Ngoài ra hãy xem blog của nhóm Etsy Ops; họ cũng thích MySQL.

Cuối cùng, tôi sẽ không sử dụng MongoDB cho bộ đệm MySQL; sử dụng Memcached cho điều đó.

Redis cũng là một kho lưu trữ khóa-giá trị trong RAM rất tốt để xử lý các trường hợp sử dụng nhất định. Có một số mục blog trên blog.agoragames.com mô tả một số trường hợp sử dụng.

Bạn cũng nên kiểm tra CouchDB nếu bạn đang nghĩ No-SQL. Chỉ cần lưu ý rằng nó đòi hỏi phải duy trì thường xuyên để giảm mức sử dụng đĩa. (Nó giao dịch tốc độ và sự thuận tiện cho việc sử dụng đĩa ...)

Cuối cùng, kế hoạch năng lực không dễ dự đoán. Bạn cần kiểm tra trong điều kiện thực tế nhất có thể và sẵn sàng khắc phục dựa trên những gì bạn thấy. Đáng buồn thay "Khoa học máy tính" cũng nhiều nghệ thuật như Khoa học.