Tất cả các bạn đều đã nghe về việc mở rộng quy mô - kiến trúc của bạn phải có khả năng mở rộng, bạn sẽ có thể mở rộng quy mô để đáp ứng nhu cầu, v.v. Nó có nghĩa là gì khi chúng ta nói về cơ sở dữ liệu? Việc chia tỷ lệ trông như thế nào ở hậu trường? Chủ đề này rất rộng lớn và không có cách nào để bao quát tất cả các khía cạnh. Loạt bài đăng hai blog này là một nỗ lực cung cấp cho bạn cái nhìn sâu sắc về chủ đề khả năng mở rộng cơ sở dữ liệu.
Tại sao chúng tôi mở rộng quy mô?
Trước tiên, chúng ta hãy xem xét khả năng mở rộng là gì. Tóm lại, chúng ta đang nói về khả năng xử lý tải cao hơn của hệ thống cơ sở dữ liệu của bạn. Nó có thể là vấn đề đối phó với những đột biến trong thời gian ngắn trong hoạt động, nó có thể là vấn đề đối phó với khối lượng công việc tăng dần trong môi trường cơ sở dữ liệu của bạn. Có thể có nhiều lý do để xem xét việc mở rộng quy mô. Hầu hết trong số họ đều đi kèm với những thách thức của riêng họ. Chúng ta có thể dành thời gian xem qua các ví dụ về tình huống mà chúng ta có thể muốn mở rộng quy mô.
Tăng mức tiêu thụ tài nguyên
Đây là vấn đề chung chung nhất - tải của bạn đã tăng đến mức các nguồn lực hiện có của bạn không còn đủ khả năng để giải quyết. Nó có thể là bất cứ thứ gì. Tải CPU đã tăng lên và cụm cơ sở dữ liệu của bạn không còn có thể cung cấp dữ liệu với thời gian thực hiện truy vấn hợp lý và ổn định. Việc sử dụng bộ nhớ đã phát triển đến mức cơ sở dữ liệu không còn bị ràng buộc bởi CPU mà trở thành giới hạn I / O và do đó, hiệu suất của các nút cơ sở dữ liệu đã giảm đáng kể. Mạng lưới cũng có thể là một cổ phiếu. Bạn có thể ngạc nhiên khi thấy các giới hạn liên quan đến mạng được gán cho các phiên bản đám mây của bạn. Trên thực tế, đây có thể trở thành giới hạn phổ biến nhất mà bạn phải đối phó vì mạng là mọi thứ trên đám mây - không chỉ dữ liệu được gửi giữa ứng dụng và cơ sở dữ liệu mà còn cả bộ nhớ được gắn qua mạng. Nó cũng có thể là sử dụng đĩa - bạn chỉ sắp hết dung lượng đĩa hoặc, nhiều khả năng hơn, với điều kiện chúng ta có thể có các đĩa khá lớn ngày nay, kích thước cơ sở dữ liệu lớn hơn kích thước "có thể quản lý". Việc bảo trì như thay đổi giản đồ trở thành một thách thức, hiệu suất bị giảm do kích thước dữ liệu, các bản sao lưu mất nhiều thời gian để hoàn thành. Tất cả những trường hợp đó có thể là một trường hợp hợp lệ cho nhu cầu mở rộng quy mô.
Khối lượng công việc tăng đột ngột
Một trường hợp ví dụ khác yêu cầu mở rộng quy mô là khối lượng công việc tăng đột ngột. Vì một số lý do (có thể là nỗ lực tiếp thị, nội dung lan truyền, tình huống khẩn cấp hoặc tương tự) cơ sở hạ tầng của bạn trải qua sự gia tăng đáng kể tải trên cụm cơ sở dữ liệu. Tải CPU quá tải, I / O đĩa làm chậm các truy vấn, v.v. Khá nhiều tài nguyên mà chúng tôi đã đề cập trong phần trước có thể bị quá tải và bắt đầu gây ra sự cố.
Hoạt động theo kế hoạch
Lý do thứ ba mà chúng tôi muốn làm nổi bật là lý do chung chung hơn - một loại hoạt động có kế hoạch. Đó có thể là một hoạt động tiếp thị đã lên kế hoạch mà bạn mong đợi sẽ mang lại nhiều lưu lượng truy cập hơn, Thứ Sáu Đen, thử nghiệm tải hoặc bất cứ điều gì mà bạn biết trước.
Mỗi lý do đó đều có những đặc điểm riêng. Nếu bạn có thể lập kế hoạch trước, bạn có thể chuẩn bị quy trình chi tiết, kiểm tra nó và thực hiện bất cứ khi nào bạn cảm thấy thích. Rất có thể bạn sẽ thích làm điều đó trong khoảng thời gian “lưu lượng truy cập thấp”, miễn là thứ gì đó tương tự tồn tại trong khối lượng công việc của bạn (không nhất thiết phải tồn tại). Mặt khác, tải trọng đột ngột tăng vọt, đặc biệt nếu chúng đủ đáng kể để tác động đến quá trình sản xuất, sẽ tạo ra phản ứng tức thì, cho dù bạn đã chuẩn bị và an toàn đến đâu - nếu dịch vụ của bạn đã bị ảnh hưởng, bạn cũng có thể đi tìm nó thay vì chờ đợi.
Các loại Tỷ lệ Cơ sở dữ liệu
Có hai kiểu chia tỷ lệ chính:dọc và ngang. Cả hai đều có ưu và khuyết điểm, cả hai đều hữu ích trong các tình huống khác nhau. Hãy xem chúng và thảo luận về các trường hợp sử dụng cho cả hai trường hợp.
Chia tỷ lệ dọc
Phương pháp chia tỷ lệ này có lẽ là phương pháp cũ nhất:nếu phần cứng của bạn không đủ mạnh để giải quyết khối lượng công việc, hãy tăng cường nó. Ở đây chúng ta đang nói đơn giản về việc thêm tài nguyên vào các nút hiện có với mục đích làm cho chúng đủ khả năng để giải quyết các nhiệm vụ được giao. Điều này có một số hậu quả mà chúng tôi muốn xem xét.
Ưu điểm của chia tỷ lệ dọc
Điều quan trọng nhất là mọi thứ được giữ nguyên. Bạn đã có ba nút trong một cụm cơ sở dữ liệu, bạn vẫn có ba nút, chỉ là khả năng hơn. Không cần phải thiết kế lại môi trường của bạn, thay đổi cách ứng dụng sẽ truy cập vào cơ sở dữ liệu - mọi thứ vẫn hoàn toàn giống nhau bởi vì, về cấu hình, không có gì thực sự thay đổi.
Một ưu điểm đáng kể khác của chia tỷ lệ dọc là nó có thể rất nhanh, đặc biệt là trong môi trường đám mây. Toàn bộ quá trình là để dừng nút hiện có, thực hiện thay đổi trong phần cứng, khởi động lại nút. Đối với các thiết lập cổ điển, tại chỗ, không có bất kỳ ảo hóa nào, điều này có thể phức tạp - bạn có thể không có sẵn CPU nhanh hơn để hoán đổi, việc nâng cấp đĩa lên lớn hơn hoặc nhanh hơn cũng có thể tốn thời gian, nhưng đối với môi trường đám mây, dù là công khai hay riêng tư, điều này có thể dễ dàng như chạy ba lệnh:dừng phiên bản, nâng cấp phiên bản lên kích thước lớn hơn, bắt đầu phiên bản. IP ảo và khối lượng có thể đính kèm lại giúp dễ dàng di chuyển dữ liệu giữa các phiên bản.
Nhược điểm của chia tỷ lệ dọc
Nhược điểm chính của chia tỷ lệ dọc là đơn giản, nó có giới hạn của nó. Nếu bạn đang chạy trên kích thước phiên bản lớn nhất hiện có, với dung lượng đĩa nhanh nhất, bạn không thể làm gì khác. Nó cũng không phải là dễ dàng để tăng hiệu suất của cụm cơ sở dữ liệu của bạn một cách đáng kể. Nó chủ yếu phụ thuộc vào kích thước phiên bản ban đầu, nhưng nếu bạn đang chạy các nút khá hiệu quả, bạn có thể không đạt được quy mô 10x bằng cách sử dụng tính năng mở rộng theo chiều dọc. Đơn giản là các nút nhanh hơn 10 lần có thể không tồn tại.
Chia tỷ lệ theo chiều ngang
Chia tỷ lệ theo chiều ngang là một điều khác biệt. Thay vì tăng kích thước phiên bản, chúng tôi giữ nguyên ở cùng một mức nhưng chúng tôi mở rộng theo chiều ngang bằng cách thêm nhiều nút hơn. Một lần nữa, có những ưu và nhược điểm của phương pháp này.
Ưu điểm của chia tỷ lệ ngang
Ưu điểm chính của chia tỷ lệ ngang là về mặt lý thuyết, bầu trời là giới hạn. Không có giới hạn cố định nhân tạo của việc mở rộng quy mô, mặc dù các giới hạn tồn tại, chủ yếu là do giao tiếp nội bộ ngày càng lớn hơn và chi phí lớn hơn với mọi nút mới được thêm vào cụm.
Một lợi thế quan trọng khác là bạn có thể mở rộng quy mô cụm mà không cần thời gian ngừng hoạt động. Nếu bạn muốn nâng cấp phần cứng, bạn phải dừng phiên bản, nâng cấp và sau đó bắt đầu lại. Nếu bạn muốn thêm nhiều nút hơn vào cụm, tất cả những gì bạn cần làm là cung cấp các nút đó, cài đặt bất kỳ phần mềm nào bạn cần, bao gồm cả cơ sở dữ liệu và để nó tham gia vào cụm. Theo tùy chọn (tùy thuộc nếu cụm có các phương pháp nội bộ để cung cấp dữ liệu cho các nút mới), bạn có thể phải tự cung cấp dữ liệu cho nó. Tuy nhiên, thông thường, đó là một quy trình tự động.
Nhược điểm của việc chia tỷ lệ ngang
Vấn đề chính mà bạn phải giải quyết là việc thêm ngày càng nhiều nút khiến việc quản lý toàn bộ môi trường trở nên khó khăn. Bạn phải biết những nút nào có sẵn, một danh sách như vậy phải được duy trì và cập nhật với mỗi nút mới được tạo. Bạn có thể cần các giải pháp bên ngoài như dịch vụ thư mục (Consul hoặc Etcd) để theo dõi các nút và trạng thái của chúng. Điều này rõ ràng làm tăng độ phức tạp của toàn bộ môi trường.
Một vấn đề tiềm ẩn khác là quá trình mở rộng quy mô mất thời gian. Việc thêm các nút mới và cung cấp chúng bằng phần mềm và đặc biệt là dữ liệu đòi hỏi thời gian. Bao nhiêu, nó phụ thuộc vào phần cứng (chủ yếu là I / O và thông lượng mạng) và kích thước của dữ liệu. Đối với các thiết lập lớn, đây có thể là một khoảng thời gian đáng kể và đây có thể là yếu tố cản trở các tình huống mà việc mở rộng quy mô phải diễn ra ngay lập tức. Hàng giờ chờ đợi để thêm các nút mới có thể không được chấp nhận nếu cụm cơ sở dữ liệu bị ảnh hưởng đến mức các hoạt động không được thực hiện đúng cách.
Điều kiện tiên quyết về Mở rộng quy mô
Sao chép dữ liệu
Trước khi có thể thực hiện bất kỳ nỗ lực mở rộng quy mô nào, môi trường của bạn phải đáp ứng một số yêu cầu. Đối với người mới bắt đầu, ứng dụng của bạn phải có khả năng tận dụng nhiều hơn một nút. Nếu nó có thể chỉ sử dụng một nút, các tùy chọn của bạn bị giới hạn khá nhiều đối với việc mở rộng quy mô theo chiều dọc. Bạn có thể tăng kích thước của nút như vậy hoặc thêm một số tài nguyên phần cứng vào máy chủ kim loại trần và làm cho nó hoạt động tốt hơn nhưng đó là điều tốt nhất bạn có thể làm:bạn sẽ luôn bị giới hạn bởi sự sẵn có của phần cứng hiệu quả hơn và cuối cùng, bạn sẽ tìm thấy mà không có tùy chọn để mở rộng quy mô hơn nữa.
Mặt khác, nếu bạn có phương tiện để sử dụng nhiều nút cơ sở dữ liệu bằng ứng dụng của mình, bạn có thể hưởng lợi từ việc mở rộng quy mô theo chiều ngang. Hãy dừng lại ở đây và thảo luận điều gì bạn cần để thực sự sử dụng nhiều nút cho hết tiềm năng của chúng.
Đối với người mới bắt đầu, khả năng tách lần đọc khỏi lần ghi. Theo truyền thống, ứng dụng chỉ kết nối với một nút. Nút đó được sử dụng để xử lý tất cả các lần ghi và tất cả các lần đọc được thực thi bởi ứng dụng.
Việc thêm nút thứ hai vào cụm, từ quan điểm chia tỷ lệ, không thay đổi gì . Bạn phải lưu ý rằng, nếu một nút bị lỗi, nút kia sẽ phải xử lý lưu lượng truy cập, do đó, tổng tải trên cả hai nút không được quá cao đối với một nút duy nhất để xử lý.
Với ba nút có sẵn, bạn hoàn toàn có thể sử dụng hai nút. Điều này cho phép chúng tôi mở rộng quy mô một số lưu lượng đọc:nếu một nút có 100% dung lượng (và chúng tôi muốn chạy nhiều nhất ở mức 70%), thì hai nút đại diện cho 200%. Ba nút:300%. Nếu một nút gặp sự cố và nếu chúng tôi đẩy các nút còn lại gần như đến giới hạn, chúng tôi có thể nói rằng chúng tôi có thể làm việc với 170 - 180% công suất của một nút nếu cụm bị suy thoái. Điều đó mang lại cho chúng tôi 60% tải tốt trên mỗi nút nếu cả ba nút đều khả dụng.
Xin lưu ý rằng chúng ta chỉ đang nói về tỷ lệ lần đọc tại thời điểm này . Không có thời điểm nào sao chép có thể cải thiện khả năng viết của bạn. Trong sao chép không đồng bộ, bạn chỉ có một người viết (chính) và đối với sao chép đồng bộ, như Galera, nơi tập dữ liệu được chia sẻ trên tất cả các nút, mọi ghi đang xảy ra trên một nút sẽ phải được thực hiện trên các nút còn lại của cụm.
Trong một cụm Galera ba nút, nếu bạn viết một hàng, trên thực tế, bạn viết ba hàng, một cho mỗi nút. Thêm nhiều nút hoặc bản sao hơn sẽ không tạo ra sự khác biệt. Thay vì viết cùng một hàng trên ba nút, bạn sẽ viết nó trên năm nút. Đây là lý do tại sao việc chia nhỏ các bản ghi của bạn trong một cụm đa chủ, nơi tập dữ liệu được chia sẻ trên tất cả các nút (có các cụm đa chủ nơi dữ liệu được chia nhỏ, ví dụ:MySQL NDB Cluster - ở đây câu chuyện về khả năng mở rộng ghi hoàn toàn khác), không có quá nhiều ý nghĩa. Nó bổ sung thêm chi phí xử lý xung đột ghi tiềm năng trên tất cả các nút trong khi nó không thực sự thay đổi bất kỳ điều gì liên quan đến tổng dung lượng ghi.
Cân bằng tải và phân chia đọc / ghi
Khả năng tách các lần đọc khỏi các lần ghi là điều bắt buộc nếu bạn muốn mở rộng quy mô số lần đọc của mình trong các thiết lập sao chép không đồng bộ. Bạn phải có khả năng gửi lưu lượng ghi tới một nút và sau đó gửi các lần đọc đến tất cả các nút trong cấu trúc liên kết sao chép. Như chúng tôi đã đề cập trước đó, chức năng này cũng khá hữu ích trong các cụm đa chủ vì nó cho phép chúng tôi loại bỏ các xung đột ghi có thể xảy ra nếu bạn cố gắng phân phối các ghi trên nhiều nút trong cụm. Làm thế nào chúng ta có thể thực hiện phân chia đọc / ghi? Có một số phương pháp bạn có thể sử dụng để làm điều đó. Hãy đi sâu vào chủ đề này một chút.
Tách R / W cấp ứng dụng
Tình huống đơn giản nhất, cũng ít thường xuyên nhất:ứng dụng của bạn có thể được định cấu hình nút nào sẽ nhận được ghi và nút nào sẽ nhận được lần đọc. Chức năng này có thể được định cấu hình theo một số cách, đơn giản nhất là danh sách các nút được mã hóa cứng nhưng nó cũng có thể là một cái gì đó dọc theo dòng khoảng không quảng cáo nút động được cập nhật bởi các luồng nền. Vấn đề chính của cách tiếp cận này là toàn bộ logic phải được viết như một phần của ứng dụng. Với danh sách các nút được mã hóa cứng, kịch bản đơn giản nhất sẽ yêu cầu thay đổi mã ứng dụng cho mọi thay đổi trong cấu trúc liên kết sao chép. Mặt khác, các giải pháp nâng cao hơn như triển khai khám phá dịch vụ sẽ phức tạp hơn để duy trì về lâu dài.
R / W tách trong trình kết nối
Một tùy chọn khác sẽ là sử dụng trình kết nối để thực hiện phân tách đọc / ghi. Không phải tất cả họ đều có tùy chọn này, nhưng một số thì có. Một ví dụ sẽ là php-mysqlnd hoặc Connector / J. Cách nó được tích hợp vào ứng dụng, nó có thể khác nhau dựa trên chính trình kết nối. Trong một số trường hợp, cấu hình phải được thực hiện trong ứng dụng, trong một số trường hợp, nó phải được thực hiện trong một tệp cấu hình riêng cho trình kết nối. Ưu điểm của cách tiếp cận này là ngay cả khi bạn phải mở rộng ứng dụng của mình, hầu hết mã mới đã sẵn sàng để sử dụng và được duy trì bởi các nguồn bên ngoài. Nó giúp dễ dàng xử lý thiết lập như vậy hơn và bạn phải viết ít mã hơn (nếu có).
R / W tách trong bộ cân bằng tải
Cuối cùng, một trong những giải pháp tốt nhất:bộ cân bằng tải. Ý tưởng rất đơn giản - chuyển dữ liệu của bạn qua một bộ cân bằng tải có thể phân biệt giữa đọc và ghi và gửi chúng đến một vị trí thích hợp. Đây là một cải tiến lớn từ quan điểm về khả năng sử dụng vì chúng tôi có thể tách việc khám phá cơ sở dữ liệu và định tuyến truy vấn khỏi ứng dụng. Điều duy nhất mà ứng dụng phải làm là gửi lưu lượng cơ sở dữ liệu đến một điểm cuối duy nhất bao gồm tên máy chủ và một cổng. Phần còn lại xảy ra ở chế độ nền. Loadbalancers đang làm việc để định tuyến các truy vấn đến các nút cơ sở dữ liệu phụ trợ. Loadbalancers cũng có thể thực hiện khám phá cấu trúc liên kết sao chép hoặc bạn có thể triển khai khoảng không quảng cáo dịch vụ thích hợp bằng cách sử dụng etcd hoặc consul và cập nhật nó thông qua các công cụ điều phối cơ sở hạ tầng của bạn như Ansible.
Điều này kết thúc phần đầu tiên của blog này. Trong phần thứ hai, chúng ta sẽ thảo luận về những thách thức mà chúng ta đang gặp phải khi mở rộng tầng cơ sở dữ liệu. Chúng ta cũng sẽ thảo luận về một số cách mà chúng ta có thể mở rộng các cụm cơ sở dữ liệu của mình.
