Sau đây là một đoạn trích từ chương 1 của Hiệu suất cơ sở dữ liệu trên quy mô (một cuốn sách truy cập mở có sẵn miễn phí). Theo đuổi những cuộc phiêu lưu rất hư cấu của Joan với một số thách thức hiệu suất cơ sở dữ liệu quá thực. Bạn sẽ cười. Bạn sẽ khóc. Bạn sẽ tự hỏi làm thế nào chúng tôi đã biến “câu chuyện cheesy” này thành một cuốn sách kỹ thuật sâu sắc. Hiệu suất cơ sở dữ liệu trên quy mô Bị cuốn hút bởi những từ vựng ấn tượng như “hibrid cloud”, “serverless” và “edge first”, Joan đã nhanh chóng gia nhập một công ty mới và bắt đầu bắt kịp với bộ công nghệ của họ. dự án đầu tiên của cô gần đây đã bắt đầu một quá trình chuyển đổi từ việc triển khai hệ thống cơ sở dữ liệu nội bộ của họ, hóa ra không mở rộng theo tốc độ như số lượng khách hàng, sang một trong những giải pháp quản lý cơ sở dữ liệu tiêu chuẩn của ngành. bảo đảm được biết đến trong thế giới SQL. axit Do một vài luật bảo vệ dữ liệu mới có xu hướng xuất hiện hàng năm ngày nay, hội đồng quản trị của công ty đã quyết định rằng họ sẽ duy trì trung tâm dữ liệu của riêng họ, thay vì sử dụng một trong những nhà cung cấp đám mây phổ biến để lưu trữ thông tin nhạy cảm. Ở mức độ rất cao, sản phẩm chính của công ty chỉ bao gồm hai lớp: Frontend, điểm vào cho người dùng, thực sự chạy trong trình duyệt của họ và giao tiếp với phần còn lại của hệ thống để trao đổi và duy trì thông tin. Tất cả mọi thứ, thường được gọi là "backend", nhưng thực sự bao gồm cân bằng tải, xác thực, ủy quyền, nhiều lớp bộ nhớ cache, cơ sở dữ liệu, sao lưu, v.v. Nhiệm vụ giới thiệu đầu tiên của Joan là thực hiện một dịch vụ rất đơn giản để thu thập và tóm tắt các số liệu thống kê khác nhau từ cơ sở dữ liệu, và tích hợp dịch vụ đó với toàn bộ hệ sinh thái, để nó thu thập dữ liệu từ cơ sở dữ liệu trong thời gian thực và cho phép các nhóm DevOps kiểm tra các số liệu thống kê trực tiếp. Để gây ấn tượng với quản lý và đảm bảo rằng việc thuê Joan là quyết định tuyệt đối tốt nhất của họ trong quý này, Joan đã quyết định đưa ra một ứng dụng chứng minh khái niệm vào ngày đầu tiên của mình! Chính sách chưa được nói của công ty là viết phần mềm trong Rust, vì vậy cô đã nắm lấy trình điều khiển đầu tiên cho cơ sở dữ liệu của họ từ một tìm kiếm ngắn gọn crates.io và ngồi xuống hackathon tự tổ chức của mình. Ngày đã trôi qua rất suôn sẻ, với hệ sinh thái tập trung vào công nghệ của Rust cung cấp trải nghiệm phát triển vượt trội.Nhưng sau đó Joan đã chạy thử nghiệm khói đầu tiên của mình trên một hệ thống thực sự.Không tin đã biến thành sự thất vọng và bất lực khi cô nhận ra rằng mỗi yêu cầu thứ ba (trung bình) kết thúc trong một lỗi, mặc dù toàn bộ cụm cơ sở dữ liệu báo cáo là trong một trạng thái lành mạnh, hoạt động. Thật không may, tài xế Joan vội vã chọn cho nền tảng của công việc của mình, mặc dù mã nguồn mở trên chính nó, chỉ là một vòng tròn mỏng so với tiền biên soạn, mã C truyền thống, không có nguồn để tìm thấy. , và cô ấy đã đưa ra một phỏng đoán có kiến thức rằng Trong cơ sở dữ liệu được sử dụng bởi công ty, các phím được hash đến các yêu cầu đường dẫn sau đến các nút thích hợp.Nếu một giá trị hash được tính toán không chính xác, một yêu cầu có thể được chuyển đến nút sai có thể từ chối nó và trả về một lỗi thay vào đó. Tải Wireshark Bug phải nằm trong hash key Không thể xác minh tuyên bố này do thiếu mã nguồn, Joan đã quyết định một con đường đơn giản hơn - từ bỏ trình điều khiển ban đầu được chọn và tái triển khai giải pháp trên một trong những trình điều khiển mã nguồn mở được hỗ trợ chính thức, được hỗ trợ bởi nhà cung cấp cơ sở dữ liệu, với cơ sở người dùng vững chắc và lịch trình phát hành được cập nhật thường xuyên. Diary of Lessons Learned của Joan, Phần I Các bài học ban đầu bao gồm: Chọn một trình điều khiển cẩn thận. nó là cốt lõi của hiệu suất, độ bền và độ tin cậy của mã của bạn. Người lái xe cũng có lỗi, và không thể tránh chúng. Tuy nhiên, có những thực hành tốt để làm theo: Trừ khi có lý do chính đáng, hãy ưu tiên người lái được hỗ trợ chính thức (nếu có); Các trình điều khiển mã nguồn mở có những lợi thế: chúng không chỉ được xác minh bởi cộng đồng, mà còn cho phép kiểm tra sâu về mã của nó, và thậm chí sửa đổi mã trình điều khiển để có được thêm thông tin chi tiết để xử lý lỗi. Tốt hơn là dựa vào các trình điều khiển có lịch trình phát hành được thiết lập tốt vì họ có nhiều khả năng nhận được các bản sửa lỗi (bao gồm cả các lỗ hổng bảo mật) trong một khoảng thời gian hợp lý. 3.Wireshark là một công cụ mã nguồn mở tuyệt vời để giải thích các gói mạng; hãy thử nó nếu bạn muốn nhìn dưới nắp chương trình của bạn. Nhiệm vụ giới thiệu cuối cùng đã được hoàn thành thành công, khiến Joan sẵn sàng nhận nhiệm vụ thực sự đầu tiên của mình. Tuning của Được trang bị với kinh nghiệm thu được khi làm việc với nhiệm vụ giới thiệu, Joan bắt đầu lên kế hoạch cách tiếp cận nhiệm vụ mới của mình: một ứng dụng có hành vi sai trái.Một trong những ứng dụng nổi tiếng gây ra các vấn đề ổn định cho toàn bộ hệ thống, làm gián đoạn các khối lượng công việc khác mỗi khi nó gặp bất kỳ vấn đề nào. Dịch vụ đặc biệt này chịu trách nhiệm tiêm dữ liệu được sao lưu từ hệ thống cổ xưa vào cơ sở dữ liệu mới. Bởi vì công ty không vội vàng, ứng dụng được viết với sự đồng bộ thấp trong tâm trí để có ưu tiên thấp và không can thiệp vào tải công việc của người dùng. Thật không may, một lần mỗi vài ngày một cái gì đó tiếp tục kích hoạt một sự bất thường. Ứng dụng bình thường hòa bình dường như đang cố gắng thực hiện một cuộc tấn công từ chối dịch vụ trên cơ sở dữ liệu của chính nó, lũ lụt nó với các yêu cầu cho đến khi backend bị quá tải đủ để gây ra vấn đề cho các bộ phận khác của hệ sinh thái. Khi Joan quan sát các số liệu được trình bày trong bảng điều khiển Grafana, rõ ràng cho thấy tỷ lệ yêu cầu được tạo ra bởi ứng dụng này bắt đầu tăng vọt vào khoảng thời gian của sự bất thường, cô tự hỏi làm thế nào trên Trái đất khối lượng công việc này có thể cư xử như vậy. Vì sự hợp tác được quảng cáo nặng nề như là một trong những “cơ sở tinh thần và văn hóa” của công ty trong các buổi tham gia với một huấn luyện viên tại chỗ, cô quyết định tốt nhất là thảo luận vấn đề này với đồng nghiệp của mình, Tony. “Nhìn, Tony, tôi không thể lắc đầu xung quanh điều này,” cô giải thích. “Dịch vụ này không gửi bất kỳ yêu cầu mới nào khi 100 người trong số họ đã bay. “Được, cảm ơn Tony, bạn là một người yêu quý – tốt nhất bao giờ!" cô kết luận và quay trở lại để sửa mã. cao su duck Việc quan sát dẫn đến việc phát hiện nguyên nhân gốc rễ khá đơn giản: yêu cầu này không thực sự *trả về* lỗi thời gian vì máy chủ cơ sở dữ liệu không bao giờ gửi lại phản hồi như vậy. yêu cầu này chỉ đơn giản là được trình điều khiển xác định thời gian và bị loại bỏ. Nhưng thực tế duy nhất rằng trình điều khiển không còn chờ câu trả lời cho một yêu cầu cụ thể không có nghĩa là cơ sở dữ liệu đang xử lý nó! Với kiến thức đó, thật dễ dàng để tưởng tượng rằng một khi 100 yêu cầu hết thời gian ở phía khách hàng, ứng dụng có thể sai lầm nghĩ rằng chúng không còn đang được tiến hành, và vui vẻ gửi thêm 100 yêu cầu đến cơ sở dữ liệu, tăng tổng số yêu cầu trong chuyến bay (tức là đồng tiền) lên 200. Nhật ký của Joan về những bài học đã học, phần II Các bài học tiếp tục: Thời gian tạm thời của khách hàng thuận tiện cho các lập trình viên, nhưng họ có thể tương tác kém với thời gian tạm thời của máy chủ. Quy tắc ngón tay cái: làm cho thời gian tạm thời của khách hàng khoảng hai lần so với thời gian tạm thời của máy chủ, trừ khi bạn có một lý do cực kỳ tốt để làm khác. Một số trình điều khiển có thể có thể phát hành cảnh báo nếu họ phát hiện ra rằng thời gian tạm thời của khách hàng là nhỏ hơn so với thời gian tạm thời của máy chủ, hoặc thậm chí sửa đổi thời gian tạm thời của máy chủ để phù hợp, nhưng nói chung tốt nhất là kiểm tra hai lần. Việc kiểm tra nhật ký và bảng điều khiển hữu ích trong việc điều tra các trường hợp như vậy, vì vậy hãy đảm bảo rằng các công cụ quan sát có sẵn cả trong cụm cơ sở dữ liệu và cho tất cả các ứng dụng khách. Với thời gian của khách hàng được sửa đổi đúng cách, ứng dụng bị chìm ít thường xuyên hơn và ở mức độ nhỏ hơn, nhưng nó vẫn không phải là một công dân hoàn hảo trong hệ thống phân tán. Thỉnh thoảng nó chọn một nút cơ sở dữ liệu nạn nhân và tiếp tục làm phiền nó với quá nhiều yêu cầu, trong khi bỏ qua thực tế là bảy nút khác được tải ít hơn đáng kể và có thể giúp xử lý khối lượng công việc cũng vậy. Tại những thời điểm khác, sự đồng thời của nó được báo cáo là chính xác lớn hơn 200% so với mong đợi của cấu hình. Bất cứ khi nào hai sự bất thường hội tụ theo thời gian, nút nghèo không thể xử lý tất cả các yêu cầu mà nó đã bị đánh bom, và phải từ bỏ một phần công bằng của chúng. Một nghiên cứu dài về tài liệu của người lái, may mắn có sẵn trong định dạng và giữ hợp lý cập nhật, giúp Joan giảm bớt những cơn đau đó. mdbook Vấn đề đầu tiên đơn giản là một cấu hình sai lầm của chính sách cân bằng tải không mặc định, cố gắng quá nhiều để chọn nút cơ sở dữ liệu "ít nhất tải" từ tất cả những người có sẵn, dựa trên heuristics và số liệu thống kê đôi khi được cập nhật bởi chính cơ sở dữ liệu. Thật không may, chính sách này cũng là “những nỗ lực tốt nhất”, và dựa trên thực tế là số liệu thống kê đến từ cơ sở dữ liệu luôn luôn hợp pháp – nhưng một nút cơ sở dữ liệu bị căng thẳng có thể trở nên quá tải đến nỗi nó không gửi lại các số liệu thống kê được cập nhật kịp thời! Điều đó dẫn đến trình điều khiển tin sai rằng máy chủ cụ thể này không thực sự bận rộn. Vấn đề thứ hai (lặp đôi tạm thời của đồng tiền tệ) được gây ra bởi một sai lầm khác: một chính sách tái cấu hình đầu cơ quá mức. Sau khi chờ đợi một khoảng thời gian được cấu hình trước mà không nhận được sự công nhận từ cơ sở dữ liệu, các trình điều khiển sẽ tái gửi một yêu cầu để tối đa hóa cơ hội thành công của nó. Cơ chế này rất hữu ích để tăng tỷ lệ thành công của yêu cầu. Tuy nhiên, nếu yêu cầu ban đầu cũng thành công, điều đó có nghĩa là yêu cầu đầu cơ đã được gửi vô ích. Để cân bằng lợi thế và bất lợi, retry đầu tư nên được cấu hình để chỉ tái gửi yêu cầu nếu rất có khả năng là yêu cầu ban đầu đã thất bại. Nếu không, như trong trường hợp của Joan, retry đầu tư có thể hành động quá sớm, tăng gấp đôi số yêu cầu được gửi (và Whew, không có gì mang lại sự vội vàng đồng thời của endorphin và dopamine như một phiên xử lý chất lượng kết thúc với một thành công đáng kinh ngạc (ngoại trừ việc viết một câu chuyện ngọt ngào trong một cuốn sách kỹ thuật sâu sắc, tất nhiên). cái kết Nếu bạn đã đạt được điều này và không thể có đủ các câu chuyện về hiệu suất cơ sở dữ liệu, hãy xem những gì đã xảy ra với Patrick già nghèo trong “ Và nếu bạn đánh giá cao cảm giác hài hước này, hãy xem Piotr . Editor’s note: A Tale of Database Performance Woes: Patrick's Unlucky Green Fedoras (Một câu chuyện về hiệu suất cơ sở dữ liệu: Fedoras xanh không may của Patrick) Sách mới về viết bài viết blog kỹ thuật
