Một lúc nào đó trong tương lai xa, việc tự động loại bỏ dữ liệu không cần thiết sẽ là một trong những nhiệm vụ quan trọng của DBMS [1]. Trong khi đó, bản thân chúng ta cần quan tâm đến việc xóa hoặc di chuyển dữ liệu không cần thiết sang các hệ thống lưu trữ ít tốn kém hơn. Giả sử bạn quyết định xóa một vài triệu hàng. Một nhiệm vụ khá đơn giản, đặc biệt nếu điều kiện đã biết và có một chỉ số phù hợp. "DELETE FROM table1 WHERE col1 = :value" - điều gì có thể đơn giản hơn, phải không?
Video:
-
Tôi đã tham gia ủy ban chương trình Highload kể từ năm đầu tiên, tức là từ năm 2007.
-
Và tôi đã làm việc với Postgres từ năm 2005. Sử dụng nó trong nhiều dự án.
-
Nhóm với RuPostges cũng từ năm 2007.
-
Chúng tôi đã tăng lên hơn 2100 người tham gia Meetup. Nó đứng thứ hai trên thế giới sau New York, bị San Francisco vượt qua trong một thời gian dài.
-
Tôi đã sống ở California được vài năm. Tôi giao dịch nhiều hơn với các công ty Mỹ, kể cả những công ty lớn. Họ là những người dùng tích cực của Postgres. Và có tất cả các loại điều thú vị.
là công ty của tôi. Chúng tôi đang kinh doanh tự động hóa các nhiệm vụ giúp loại bỏ sự chậm lại trong quá trình phát triển.
Nếu bạn đang làm gì đó, thì đôi khi có một số loại phích cắm xung quanh Postgres. Giả sử bạn cần đợi quản trị viên thiết lập giá đỡ thử nghiệm cho bạn hoặc bạn cần đợi DBA phản hồi cho bạn. Và chúng tôi tìm thấy những nút thắt như vậy trong quá trình phát triển, thử nghiệm và quản trị và cố gắng loại bỏ chúng với sự trợ giúp của tự động hóa và các phương pháp tiếp cận mới.
Gần đây tôi đã ở VLDB ở Los Angeles. Đây là hội nghị lớn nhất về cơ sở dữ liệu. Và đã có báo cáo rằng trong tương lai DBMS sẽ không chỉ lưu trữ mà còn tự động xóa dữ liệu. Đây là một chủ đề mới.
Ngày càng có nhiều dữ liệu trong thế giới zettabyte - tức là 1 petabyte. Và bây giờ người ta ước tính rằng chúng ta có hơn 000 zettabyte dữ liệu được lưu trữ trên thế giới. Và ngày càng có nhiều người trong số họ.
Và phải làm gì với nó? Rõ ràng là nó cần phải được gỡ bỏ. Đây là một liên kết đến báo cáo thú vị này. Nhưng cho đến nay điều này vẫn chưa được thực hiện trong DBMS.
Những người có thể đếm tiền muốn hai điều. Họ muốn chúng tôi xóa, vì vậy về mặt kỹ thuật, chúng tôi sẽ có thể làm điều đó.
Những gì tôi sẽ kể tiếp theo là một số tình huống trừu tượng bao gồm một loạt các tình huống thực tế, tức là một kiểu tổng hợp những gì đã thực sự xảy ra với tôi và các cơ sở dữ liệu xung quanh nhiều lần, nhiều năm. Cào cào ở khắp mọi nơi và mọi người luôn giẫm lên chúng.
Giả sử chúng ta có một hoặc nhiều cơ sở đang phát triển. Và một số hồ sơ rõ ràng là rác rưởi. Ví dụ: người dùng bắt đầu làm một việc gì đó ở đó nhưng chưa hoàn thành. Và sau một thời gian, chúng tôi biết rằng điều chưa hoàn thành này không còn có thể được lưu trữ. Đó là, chúng tôi muốn dọn dẹp một số thứ rác rưởi để tiết kiệm dung lượng, cải thiện hiệu suất, v.v.
Nói chung, nhiệm vụ là tự động loại bỏ những thứ cụ thể, những dòng cụ thể trong một số bảng.
Và chúng tôi có một yêu cầu như vậy mà chúng ta sẽ nói hôm nay, đó là về việc dọn rác.
Chúng tôi đã nhờ một nhà phát triển có kinh nghiệm làm việc đó. Anh ấy đã nhận yêu cầu này, tự mình kiểm tra nó - mọi thứ đều hoạt động. Đã thử nghiệm trên dàn - mọi thứ đều ổn. Đã triển khai - mọi thứ đều hoạt động. Chúng tôi chạy nó mỗi ngày một lần - mọi thứ đều ổn.
Cơ sở dữ liệu phát triển và phát triển. DELETE hàng ngày bắt đầu hoạt động chậm hơn một chút.
Sau đó, chúng tôi hiểu rằng chúng tôi hiện có một công ty tiếp thị và lưu lượng truy cập sẽ lớn hơn gấp nhiều lần, vì vậy chúng tôi quyết định tạm dừng những việc không cần thiết. Và quên trở về.
Vài tháng sau họ mới nhớ ra. Và nhà phát triển đó đã nghỉ việc hoặc đang bận việc khác, đã hướng dẫn người khác trả lại.
Anh ấy đã kiểm tra trên dev, trên dàn - mọi thứ đều ổn. Đương nhiên, bạn vẫn cần dọn dẹp những gì đã tích lũy. Ông đã kiểm tra mọi thứ hoạt động.
Chuyện gì xảy ra tiếp theo? Sau đó, mọi thứ sụp đổ đối với chúng tôi. Nó rơi xuống để đến một lúc nào đó mọi thứ rơi xuống. Mọi người đều bàng hoàng, không ai hiểu chuyện gì đang xảy ra. Và sau đó hóa ra vấn đề là ở XÓA này.
Đã xảy ra sự cố? Đây là danh sách những gì có thể đã đi sai. Cái nào trong số này là quan trọng nhất?
-
Ví dụ: không có đánh giá nào, tức là chuyên gia DBA đã không xem xét đánh giá đó. Anh ta sẽ ngay lập tức tìm ra vấn đề bằng con mắt kinh nghiệm, và bên cạnh đó, anh ta có quyền truy cập vào prod, nơi tích lũy hàng triệu dòng.
-
Có lẽ họ đã kiểm tra một cái gì đó sai.
-
Có thể phần cứng đã lỗi thời và bạn cần nâng cấp cơ sở này.
-
Hoặc có gì đó không ổn với chính cơ sở dữ liệu và chúng ta cần chuyển từ Postgres sang MySQL.
-
Hoặc có thể có điều gì đó không ổn với hoạt động.
-
Có thể có một số sai lầm trong tổ chức công việc và bạn cần sa thải ai đó và thuê những người giỏi nhất?
Không có kiểm tra DBA. Nếu có một DBA, anh ta sẽ thấy vài triệu dòng này và thậm chí không có bất kỳ thử nghiệm nào cũng sẽ nói: "Họ không làm điều đó." Giả sử nếu mã này nằm trong GitLab, GitHub và sẽ có một quy trình xem xét mã và không có nghĩa là nếu không có sự chấp thuận của DBA, hoạt động này sẽ diễn ra trên prod, thì rõ ràng DBA sẽ nói: “Điều này không thể thực hiện được.”
Và anh ấy sẽ nói rằng bạn sẽ gặp sự cố với đĩa IO và tất cả các quy trình sẽ bị hỏng, có thể có khóa và bạn cũng sẽ chặn autovacuum trong vài phút, vì vậy điều này không tốt.
Sai lầm thứ hai - họ đã kiểm tra sai chỗ. Sau đó, chúng tôi đã thấy rằng rất nhiều dữ liệu rác được tích lũy trên sản phẩm, nhưng nhà phát triển không có dữ liệu tích lũy trong cơ sở dữ liệu này và không ai tạo ra dữ liệu rác này trong quá trình dàn dựng. Theo đó, đã có 1 dòng nhanh chóng được hoàn thành.
Chúng tôi hiểu rằng các bài kiểm tra của chúng tôi còn yếu, tức là quy trình được xây dựng không nắm bắt được vấn đề. Một thử nghiệm DB đầy đủ đã không được thực hiện.
Một thí nghiệm lý tưởng tốt nhất là được thực hiện trên cùng một thiết bị. Không phải lúc nào cũng có thể thực hiện việc này trên cùng một thiết bị, nhưng điều rất quan trọng là nó phải là một bản sao cơ sở dữ liệu có kích thước đầy đủ. Đây là những gì tôi đã giảng trong vài năm nay. Và một năm trước tôi đã nói về điều này, bạn có thể xem tất cả trên YouTube.
Có lẽ thiết bị của chúng tôi là xấu? Nếu bạn nhìn, thì độ trễ đã tăng vọt. Chúng tôi đã thấy rằng việc sử dụng là 100%. Tất nhiên, nếu đây là những ổ NVMe hiện đại thì có lẽ sẽ dễ dàng hơn nhiều đối với chúng tôi. Và có lẽ chúng ta sẽ không nằm xuống từ nó.
Nếu bạn có các đám mây, thì việc nâng cấp sẽ dễ dàng được thực hiện ở đó. Tăng bản sao mới trên phần cứng mới. chuyển mạch. Và tất cả đều tốt. Khá dễ dàng.
Có thể bằng cách nào đó chạm vào các đĩa nhỏ hơn? Và ở đây, chỉ với sự trợ giúp của DBA, chúng tôi đi sâu vào một chủ đề nhất định gọi là điều chỉnh điểm kiểm tra. Hóa ra chúng tôi không có điều chỉnh điểm kiểm tra.
Điểm kiểm tra là gì? Nó có trong bất kỳ DBMS nào. Khi bạn có dữ liệu trong bộ nhớ thay đổi, nó sẽ không được ghi ngay vào đĩa. Thông tin mà dữ liệu đã thay đổi trước tiên được ghi vào nhật ký ghi trước. Và tại một thời điểm nào đó, DBMS quyết định rằng đã đến lúc chuyển các trang thực vào đĩa, để nếu chúng tôi gặp lỗi, chúng tôi có thể thực hiện REDO ít hơn. Nó giống như một món đồ chơi. Nếu chúng tôi bị giết, chúng tôi sẽ bắt đầu trò chơi từ trạm kiểm soát cuối cùng. Và tất cả DBMS thực hiện nó.
Các cài đặt trong Postgres bị tụt lại phía sau. Chúng được thiết kế cho khối lượng dữ liệu và giao dịch từ 10-15 năm tuổi. Và trạm kiểm soát cũng không ngoại lệ.
Đây là thông tin từ báo cáo kiểm tra Postgres của chúng tôi, tức là kiểm tra sức khỏe tự động. Và đây là một số cơ sở dữ liệu vài terabyte. Và có thể thấy rõ rằng gần 90% các trường hợp đều bắt buộc phải checkpoint.
Nó có nghĩa là gì? Có hai cài đặt ở đó. Điểm kiểm tra có thể đến khi hết thời gian chờ, chẳng hạn như sau 10 phút. Hoặc nó có thể đến khi khá nhiều dữ liệu đã được lấp đầy.
Và theo mặc định, max_wal_saze được đặt thành 1 gigabyte. Trên thực tế, điều này thực sự xảy ra trong Postgres sau 300-400 megabyte. Bạn đã thay đổi quá nhiều dữ liệu và điểm kiểm tra của bạn xảy ra.
Và nếu không có ai điều chỉnh nó, và dịch vụ phát triển và công ty kiếm được nhiều tiền, nó có rất nhiều giao dịch, thì điểm kiểm tra sẽ xuất hiện mỗi phút một lần, đôi khi cứ sau 30 giây và đôi khi còn trùng lặp. Điều này là khá xấu.
Và chúng ta cần đảm bảo rằng nó đến ít thường xuyên hơn. Tức là chúng ta có thể tăng max_wal_size. Và nó sẽ đến ít thường xuyên hơn.
Nhưng chúng tôi đã phát triển một phương pháp hoàn chỉnh về cách thực hiện điều đó một cách chính xác hơn, đó là cách đưa ra quyết định về việc chọn cài đặt, rõ ràng dựa trên dữ liệu cụ thể.
Theo đó, chúng tôi đang thực hiện hai loạt thử nghiệm trên cơ sở dữ liệu.
Sê-ri đầu tiên - chúng tôi thay đổi max_wal_size. Và chúng tôi đang thực hiện một ca phẫu thuật quy mô lớn. Đầu tiên, chúng tôi thực hiện trên cài đặt mặc định là 1 gigabyte. Và chúng tôi thực hiện XÓA hàng triệu dòng.
Bạn có thể thấy nó khó khăn như thế nào đối với chúng tôi. Chúng tôi thấy rằng đĩa IO là rất xấu. Chúng tôi xem có bao nhiêu WAL chúng tôi đã tạo, vì điều này rất quan trọng. Hãy xem có bao nhiêu lần trạm kiểm soát đã xảy ra. Và chúng tôi thấy rằng nó không tốt.
Tiếp theo, chúng tôi tăng max_wal_size. Chúng ta lặp lại. Chúng tôi tăng lên, chúng tôi lặp lại. Và rất nhiều lần. Về nguyên tắc, 10 điểm là tốt, trong đó 1, 2, 4, 8 gigabyte. Và chúng tôi xem xét hành vi của một hệ thống cụ thể. Rõ ràng là ở đây thiết bị phải giống như trên sản phẩm. Bạn phải có cùng ổ đĩa, cùng dung lượng bộ nhớ và cùng cài đặt Postgres.
Và theo cách này, chúng tôi sẽ trao đổi hệ thống của mình và chúng tôi biết DBMS sẽ hoạt động như thế nào trong trường hợp XÓA hàng loạt xấu, nó sẽ kiểm tra như thế nào.
Checkpoint trong tiếng Nga là trạm kiểm soát.
Ví dụ: XÓA vài triệu hàng theo chỉ mục, các hàng nằm "rải rác" trên các trang.
Đây là một ví dụ. Đây là một số cơ sở. Và với cài đặt mặc định là 1 gigabyte cho max_wal_size, rõ ràng là các đĩa của chúng tôi sẽ được chuyển đến giá để ghi. Hình ảnh này là một triệu chứng điển hình của một bệnh nhân ốm nặng, tức là anh ta thực sự cảm thấy tồi tệ. Và có một thao tác duy nhất, chỉ có XÓA vài triệu dòng.
Nếu một hoạt động như vậy được cho phép trong prod, thì chúng tôi sẽ chỉ nằm xuống, vì rõ ràng là một lần XÓA sẽ giết chúng tôi trong giá.
Hơn nữa, nơi 16 gigabyte, rõ ràng là răng đã biến mất. Răng đã tốt hơn, tức là chúng ta đang gõ trần nhà, nhưng không đến nỗi tệ. Có một số tự do ở đó. Bên phải là bản ghi. Và số lượng hoạt động - biểu đồ thứ hai. Và rõ ràng là chúng ta đã dễ thở hơn một chút khi có 16 gigabyte.
Và nơi 64 gigabyte có thể được nhìn thấy rằng nó đã trở nên hoàn toàn tốt hơn. Răng đã được phát âm, có nhiều cơ hội hơn để tồn tại trong các hoạt động khác và làm điều gì đó với đĩa.
Tại sao vậy?
Tôi sẽ đi sâu vào chi tiết một chút, nhưng chủ đề này, cách tiến hành điều chỉnh điểm kiểm tra, có thể dẫn đến toàn bộ báo cáo, vì vậy tôi sẽ không tải nhiều, nhưng tôi sẽ phác thảo một chút những khó khăn gặp phải.
Nếu điểm kiểm tra xảy ra quá thường xuyên và chúng tôi cập nhật các hàng của mình không theo trình tự mà tìm chúng theo chỉ mục, điều này tốt vì chúng tôi không xóa toàn bộ bảng, thì có thể xảy ra trường hợp đầu tiên chúng tôi chạm vào trang đầu tiên, sau đó là phần nghìn và sau đó quay lại trang đầu tiên. Và nếu giữa những lần truy cập trang đầu tiên này, điểm kiểm tra đã lưu nó vào đĩa, thì nó sẽ lưu lại trang đó, vì chúng tôi đã làm bẩn nó lần thứ hai.
Và chúng tôi sẽ buộc trạm kiểm soát lưu nó nhiều lần. Làm thế nào sẽ có các hoạt động dự phòng cho anh ta.
Nhưng đó không phải là tất cả. Các trang là 8 kilobyte trong Postgres và 4 kilobyte trong Linux. Và có cài đặt full_page_writes. Nó được kích hoạt theo mặc định. Và điều này là chính xác, bởi vì nếu chúng ta tắt nó đi, thì sẽ có nguy cơ chỉ lưu được một nửa trang nếu nó gặp sự cố.
Hành vi ghi vào WAL của nhật ký chuyển tiếp là khi chúng tôi có một điểm kiểm tra và chúng tôi thay đổi trang lần đầu tiên, toàn bộ trang, tức là tất cả 8 kilobyte, sẽ được đưa vào nhật ký chuyển tiếp, mặc dù chúng tôi chỉ thay đổi dòng nặng 100 byte. Và chúng tôi phải viết ra toàn bộ trang.
Trong những thay đổi tiếp theo, sẽ chỉ có một bộ dữ liệu cụ thể, nhưng lần đầu tiên chúng tôi viết ra mọi thứ.
Và theo đó, nếu điểm kiểm tra lại xảy ra, thì chúng ta phải bắt đầu lại mọi thứ từ đầu và đẩy toàn bộ trang. Với các điểm kiểm tra thường xuyên, khi chúng tôi duyệt qua cùng một trang, full_page_writes = on sẽ nhiều hơn mức có thể, tức là chúng tôi tạo ra nhiều WAL hơn. Nhiều hơn nữa được gửi tới các bản sao, tới kho lưu trữ, tới đĩa.
Và, theo đó, chúng tôi có hai dư thừa.
Nếu chúng tôi tăng max_wal_size, hóa ra là chúng tôi tạo điều kiện dễ dàng hơn cho cả điểm kiểm tra và người viết wal. Và điều đó thật tuyệt.
Hãy đặt vào một terabyte và sống với nó. Có gì xấu về nó? Điều này thật tệ, vì trong trường hợp thất bại, chúng tôi sẽ leo lên hàng giờ, vì trạm kiểm soát đã có từ lâu và nhiều thứ đã thay đổi. Và chúng ta cần phải LÀM LẠI tất cả những điều này. Và thế là chúng tôi thực hiện loạt thí nghiệm thứ hai.
Chúng tôi thực hiện một thao tác và xem khi điểm kiểm tra sắp hoàn thành, chúng tôi cố tình tiêu diệt -9 Postgres.
Và sau đó, chúng tôi khởi động lại nó và xem nó sẽ tăng bao lâu trên thiết bị này, tức là nó sẽ LÀM LẠI bao nhiêu trong tình huống xấu này.
Hai lần tôi sẽ lưu ý rằng tình hình là xấu. Đầu tiên, chúng tôi bị rơi ngay trước khi trạm kiểm soát kết thúc, vì vậy chúng tôi có rất nhiều thứ để mất. Và thứ hai, chúng tôi đã có một hoạt động lớn. Và nếu các điểm kiểm tra hết thời gian chờ, thì rất có thể, ít WAL hơn sẽ được tạo kể từ điểm kiểm tra cuối cùng. Đó là, nó là một kẻ thua cuộc kép.
Chúng tôi đo lường tình huống như vậy đối với các kích thước max_wal_size khác nhau và hiểu rằng nếu max_wal_size là 64 gigabyte, thì trong trường hợp xấu nhất, chúng tôi sẽ tăng gấp đôi trong 10 phút. Và chúng tôi nghĩ liệu nó có phù hợp với chúng tôi hay không. Đây là một câu hỏi kinh doanh. Chúng ta cần đưa bức tranh này cho những người chịu trách nhiệm về các quyết định kinh doanh và hỏi: “Chúng ta có thể nằm xuống nhiều nhất là bao lâu khi gặp sự cố? Chúng ta có thể nằm xuống trong tình huống xấu nhất trong 3-5 phút không? Và bạn đưa ra quyết định.
Và đây là một điểm thú vị. Chúng tôi có một vài báo cáo về Patroni tại hội nghị. Và có thể bạn đang sử dụng nó. Đây là một tự động chuyển đổi dự phòng cho Postgres. GitLab và Data Egret đã nói về điều này.
Và nếu bạn có một bộ chuyển đổi dự phòng tự động xuất hiện sau 30 giây, thì có lẽ chúng ta có thể nằm nghỉ trong 10 phút? Bởi vì chúng tôi sẽ chuyển sang bản sao vào thời điểm này và mọi thứ sẽ ổn. Đây là một điểm tranh luận. Tôi không biết một câu trả lời rõ ràng. Tôi chỉ cảm thấy rằng chủ đề này không chỉ xoay quanh việc khôi phục sự cố.
Nếu chúng ta phục hồi lâu sau một thất bại, thì chúng ta sẽ không thoải mái trong nhiều tình huống khác. Ví dụ, trong các thí nghiệm tương tự, khi chúng ta làm một việc gì đó và đôi khi phải chờ 10 phút.
Tôi vẫn sẽ không đi quá xa, ngay cả khi chúng tôi có tính năng tự động chuyển đổi dự phòng. Theo quy định, các giá trị như 64, 100 gigabyte là giá trị tốt. Đôi khi nó thậm chí còn đáng để chọn ít hơn. Nói chung, đây là một khoa học tinh tế.
Để thực hiện phép lặp, ví dụ: max_wal_size =1, 8, bạn cần lặp lại thao tác hàng loạt nhiều lần. Bạn đã thực hiện nó. Và trên cùng một cơ sở, bạn muốn làm lại nhưng bạn đã xóa mọi thứ. phải làm gì?
Tôi sẽ nói sau về giải pháp của chúng tôi, những gì chúng tôi làm để lặp lại trong những tình huống như vậy. Và đây là cách tiếp cận chính xác nhất.
Nhưng trong trường hợp này, chúng tôi đã may mắn. Nếu, như nó nói ở đây "BEGIN, DELETE, ROLLBACK", thì chúng ta có thể lặp lại DELETE. Đó là, nếu chúng ta tự hủy nó, thì chúng ta có thể lặp lại nó. Và về mặt vật lý, dữ liệu sẽ nằm ở cùng một vị trí với bạn. Bạn thậm chí không nhận được bất kỳ sưng lên. Bạn có thể lặp lại các XÓA như vậy.
XÓA với ROLLBACK này là lý tưởng để điều chỉnh điểm kiểm tra, ngay cả khi bạn không có phòng thí nghiệm cơ sở dữ liệu được triển khai đúng cách.
Chúng tôi đã tạo một tấm có một cột "i". Postgres có các cột tiện ích. Chúng là vô hình trừ khi được yêu cầu cụ thể. Đó là: ctid, xmid, xmax.
Ctid là một địa chỉ vật lý. Trang không, bộ dữ liệu đầu tiên trong trang.
Có thể thấy rằng sau ROOLBACK, bộ dữ liệu vẫn ở cùng một vị trí. Đó là, chúng ta có thể thử lại, nó sẽ hoạt động theo cách tương tự. Đây là điều chính.
Xmax là thời điểm chết của tuple. Nó đã được đóng dấu, nhưng Postgres biết rằng giao dịch đã được khôi phục, vì vậy nó là 0 hay đó là giao dịch được khôi phục không thành vấn đề. Điều này cho thấy rằng có thể lặp lại DELETE và kiểm tra các hoạt động hàng loạt của hành vi hệ thống. Bạn có thể làm phòng thí nghiệm cơ sở dữ liệu cho người nghèo.
Đây là về các lập trình viên. Về DBA cũng vậy, họ luôn mắng các lập trình viên về điều này: “Sao mày làm mấy cái thao tác lâu và khó thế?”. Đây là một chủ đề vuông góc hoàn toàn khác. Đã từng có quản lý, và bây giờ sẽ có sự phát triển.
Rõ ràng, chúng tôi đã không chia thành từng mảnh. Rõ ràng. Không thể không chia XÓA như vậy cho một đống hàng triệu dòng thành nhiều phần. Nó sẽ được thực hiện trong 20 phút, và mọi thứ sẽ nằm xuống. Nhưng thật không may, ngay cả những nhà phát triển có kinh nghiệm cũng mắc lỗi, ngay cả trong các công ty rất lớn.
Tại sao nó quan trọng để phá vỡ?
-
Nếu chúng ta thấy đĩa cứng thì hãy làm chậm nó lại. Và nếu chúng tôi bị hỏng, thì chúng tôi có thể thêm các khoảng dừng, chúng tôi có thể giảm tốc độ điều chỉnh.
-
Và chúng tôi sẽ không chặn người khác trong một thời gian dài. Trong một số trường hợp, điều đó không thành vấn đề, nếu bạn đang xóa rác thực sự mà không có ai xử lý, thì rất có thể bạn sẽ không chặn bất kỳ ai ngoại trừ công việc autovacuum, vì nó sẽ đợi giao dịch hoàn tất. Nhưng nếu bạn xóa thứ gì đó mà người khác có thể yêu cầu, thì họ sẽ bị chặn, sẽ có một số loại phản ứng dây chuyền. Nên tránh các giao dịch dài trên các trang web và ứng dụng di động.
Hay đấy. Tôi thường thấy các nhà phát triển hỏi: "Tôi nên chọn kích thước gói nào?".
Rõ ràng là kích thước gói càng lớn thì chi phí giao dịch càng nhỏ, tức là chi phí bổ sung từ các giao dịch. Nhưng đồng thời, thời gian cho giao dịch này tăng lên.
Tôi có một quy tắc rất đơn giản: lấy càng nhiều càng tốt, nhưng đừng vượt qua các tệp thực thi mỗi giây.
Tại sao một giây? Giải thích rất đơn giản và dễ hiểu cho mọi người, ngay cả những người không có kỹ thuật. Chúng tôi thấy một phản ứng. Hãy lấy 50 mili giây. Nếu một cái gì đó đã thay đổi, thì mắt của chúng ta sẽ phản ứng. Nếu ít hơn, thì khó khăn hơn. Ví dụ: nếu một cái gì đó phản hồi sau 100 mili giây, bạn nhấp chuột và nó trả lời bạn sau 100 mili giây, thì bạn đã cảm thấy độ trễ nhẹ này. Một giây đã được coi là phanh.
Theo đó, nếu chúng tôi chia các hoạt động hàng loạt của mình thành các đợt 10 giây, thì chúng tôi có nguy cơ chặn ai đó. Và nó sẽ hoạt động trong vài giây và mọi người sẽ chú ý đến nó. Vì vậy, tôi không muốn làm nhiều hơn một giây. Nhưng đồng thời, đừng chia nhỏ nó ra, vì chi phí giao dịch sẽ rất đáng chú ý. Đế sẽ cứng hơn và các vấn đề khác có thể phát sinh.
Chúng tôi chọn kích thước của gói. Trong mỗi trường hợp, chúng ta có thể làm điều đó khác nhau. Có thể được tự động hóa. Và chúng tôi tin chắc về hiệu quả của việc xử lý một gói. Đó là, chúng tôi XÓA một gói hoặc CẬP NHẬT.
Nhân tiện, mọi thứ tôi đang nói không chỉ là XÓA. Như bạn đoán, đây là bất kỳ thao tác hàng loạt nào trên dữ liệu.
Và chúng tôi thấy rằng kế hoạch là tuyệt vời. Bạn có thể thấy quét chỉ mục, chỉ quét chỉ mục thậm chí còn tốt hơn. Và chúng tôi có một lượng nhỏ dữ liệu liên quan. Và chưa đầy một giây hoàn thành. Siêu.
Và chúng ta vẫn cần đảm bảo rằng không có sự xuống cấp. Nó xảy ra rằng các gói đầu tiên nhanh chóng hoạt động, và sau đó nó trở nên tồi tệ hơn, tồi tệ hơn và tồi tệ hơn. Quá trình này là như vậy mà bạn cần phải kiểm tra rất nhiều. Đây chính xác là những gì phòng thí nghiệm cơ sở dữ liệu dành cho.
Và chúng tôi vẫn phải chuẩn bị một cái gì đó để nó cho phép chúng tôi tuân theo điều này một cách chính xác trong quá trình sản xuất. Ví dụ: chúng ta có thể viết thời gian vào nhật ký, chúng ta có thể viết chúng ta đang ở đâu và chúng ta đã xóa ai. Và điều này sẽ cho phép chúng tôi hiểu những gì đang xảy ra sau đó. Và trong trường hợp xảy ra sự cố, hãy nhanh chóng tìm ra vấn đề.
Nếu chúng ta cần kiểm tra hiệu quả của các yêu cầu và chúng ta cần lặp lại nhiều lần, thì có một thứ gọi là bot đồng nghiệp. Anh ấy đã sẵn sàng. Nó được hàng chục nhà phát triển sử dụng hàng ngày. Và anh ấy biết cách cung cấp một cơ sở dữ liệu hàng terabyte khổng lồ theo yêu cầu trong 30 giây, bản sao của chính bạn. Và bạn có thể xóa một cái gì đó ở đó và nói ĐẶT LẠI, và xóa nó một lần nữa. Bạn có thể thử nghiệm với nó theo cách này. Tôi nhìn thấy một tương lai cho điều này. Và chúng tôi đã và đang làm điều đó.
Chiến lược phân vùng là gì? Tôi thấy 3 chiến lược phân vùng khác nhau mà các nhà phát triển trên gói đang sử dụng.
Cái đầu tiên rất đơn giản. Chúng tôi có một ID số. Và hãy chia nó thành các khoảng thời gian khác nhau và làm việc với nó. Nhược điểm là rõ ràng. Trong phân đoạn đầu tiên, chúng ta có thể có 100 dòng thực sự là rác, trong 5 dòng thứ hai hoặc hoàn toàn không, hoặc tất cả 1 dòng sẽ trở thành rác. Công việc rất không đồng đều, nhưng rất dễ bị phá vỡ. Họ lấy ID tối đa và đập vỡ nó. Đây là một cách tiếp cận ngây thơ.
Chiến lược thứ hai là một cách tiếp cận cân bằng. Nó được sử dụng trong Gitlab. Họ cầm và quét bàn. Chúng tôi đã tìm thấy ranh giới của các gói ID sao cho mỗi gói có chính xác 10 bản ghi. Và xếp chúng vào hàng đợi. Và sau đó chúng tôi xử lý. Bạn có thể làm điều này trong nhiều chủ đề.
Nhân tiện, trong chiến lược đầu tiên, bạn cũng có thể thực hiện việc này trong một số luồng. Nó không khó.
Nhưng có một cách tiếp cận thú vị và tốt hơn. Đây là chiến lược thứ ba. Và khi có thể, tốt hơn là chọn nó. Chúng tôi làm điều này trên cơ sở một chỉ số đặc biệt. Trong trường hợp này, rất có thể nó sẽ là một chỉ mục theo ID và tình trạng rác của chúng tôi. Chúng tôi sẽ bao gồm ID để nó chỉ quét chỉ mục để chúng tôi không chuyển đến đống.
Nói chung, quét chỉ mục nhanh hơn quét chỉ mục.
Và chúng tôi nhanh chóng tìm thấy ID của mình mà chúng tôi muốn xóa. BATCH_SIZE chúng tôi chọn trước. Và chúng tôi không chỉ lấy chúng, chúng tôi lấy chúng theo một cách đặc biệt và hack chúng ngay lập tức. Nhưng chúng tôi đang khóa để nếu chúng đã bị khóa, chúng tôi sẽ không khóa chúng mà tiếp tục và lấy những cái tiếp theo. Cái này dành cho khóa bỏ qua cập nhật. Siêu tính năng này của Postgres cho phép chúng tôi làm việc trong một số luồng nếu chúng tôi muốn. Có thể trong một luồng. Và ở đây có một CTE - đây là một yêu cầu. Và chúng tôi có một cuộc xóa thực sự đang diễn ra ở tầng thứ hai của CTE này - returning *. Bạn có thể trả lại id, nhưng tốt hơn hết *nếu bạn không có nhiều dữ liệu trên mỗi dòng.
Tại sao chúng ta cần nó? Đây là những gì chúng ta cần phải báo cáo lại. Trên thực tế, chúng tôi đã xóa rất nhiều dòng. Và chúng ta có đường viền bằng ID hoặc bằng created_at như thế này. Bạn có thể làm tối thiểu, tối đa. Một cái gì đó khác có thể được thực hiện. Bạn có thể nhồi nhét rất nhiều ở đây. Và nó rất thuận tiện cho việc giám sát.
Có một lưu ý nữa về chỉ mục. Nếu chúng tôi quyết định rằng chúng tôi cần một chỉ mục đặc biệt cho nhiệm vụ này, thì chúng tôi cần đảm bảo rằng nó không làm hỏng các bản cập nhật chỉ bộ dữ liệu của heap. Đó là, Postgres có số liệu thống kê như vậy. Điều này có thể được nhìn thấy trong pg_stat_user_tables cho bảng của bạn. Bạn có thể xem các bản cập nhật nóng có đang được sử dụng hay không.
Có những tình huống khi chỉ mục mới của bạn có thể cắt bỏ chúng một cách đơn giản. Và bạn có tất cả các bản cập nhật khác đang hoạt động, hãy chậm lại. Không chỉ vì chỉ mục xuất hiện (mỗi chỉ mục cập nhật chậm hơn một chút, nhưng một chút), mà ở đây nó vẫn làm hỏng nó. Và không thể thực hiện tối ưu hóa đặc biệt cho bảng này. Điều này đôi khi xảy ra. Đây là một sự tinh tế mà ít người nhớ. Và cào này là dễ dàng để bước vào. Đôi khi, bạn cần tìm một cách tiếp cận từ phía bên kia và vẫn làm mà không có chỉ mục mới này, hoặc tạo một chỉ mục khác, hoặc theo một cách nào đó, chẳng hạn như bạn có thể sử dụng phương pháp thứ hai.
Nhưng đây là chiến lược tối ưu nhất, cách chia thành nhiều đợt và bắn từng đợt với một yêu cầu, xóa một chút, v.v.
giao dịch dài
Autovacuum bị chặn -
vấn đề chặn -
Sai lầm #5 là một sai lầm lớn. Nikolai từ Okmeter đã nói về việc giám sát Postgres. Thật không may, giám sát Postgres lý tưởng không tồn tại. Một số gần hơn, một số xa hơn. Okmeter đã đủ gần để trở nên hoàn hảo, nhưng vẫn còn thiếu rất nhiều thứ và cần được bổ sung. Bạn cần phải sẵn sàng cho việc này.
Ví dụ, các bộ dữ liệu chết được theo dõi tốt nhất. Nếu bạn có nhiều thứ chết trong bàn, thì có gì đó không ổn. Tốt hơn là nên phản ứng ngay bây giờ, nếu không có thể xảy ra suy thoái, và chúng ta có thể nằm xuống. Nó xảy ra.
Nếu có IO lớn thì rõ ràng điều này là không tốt.
Giao dịch dài quá. Các giao dịch dài không được phép trên OLTP. Và đây là một liên kết đến một đoạn mã cho phép bạn lấy đoạn mã này và đã thực hiện một số theo dõi các giao dịch dài hạn.
Tại sao các giao dịch dài không tốt? Bởi vì tất cả các ổ khóa sẽ chỉ được giải phóng khi kết thúc. Và chúng tôi vít tất cả mọi người. Ngoài ra, chúng tôi chặn autovacuum cho tất cả các bảng. Nó không tốt chút nào. Ngay cả khi bạn đã bật chế độ chờ nóng trên bản sao, nó vẫn rất tệ. Nói chung, không nơi nào tốt hơn để tránh các giao dịch dài.
Nếu chúng ta có nhiều bàn chưa được hút bụi, thì chúng ta cần có cảnh báo. Ở đây một tình huống như vậy là có thể. Chúng ta có thể gián tiếp tác động đến hoạt động của autovacuum. Đây là một đoạn trích từ Avito, mà tôi đã cải thiện một chút. Và nó hóa ra là một công cụ thú vị để xem những gì chúng ta có với autovacuum. Ví dụ, một số bảng đang đợi ở đó và sẽ không đợi đến lượt của họ. Bạn cũng cần đặt nó trong giám sát và có cảnh báo.
Và vấn đề khối. Rừng cây khối. Tôi thích lấy thứ gì đó từ ai đó và cải thiện nó. Ở đây, tôi đã lấy một CTE đệ quy thú vị từ Data Egret cho thấy một rừng cây khóa. Đây là một công cụ chẩn đoán tốt. Và trên cơ sở đó, bạn cũng có thể xây dựng giám sát. Nhưng điều này phải được thực hiện cẩn thận. Bạn cần làm một statement_timeout nhỏ cho mình. Và lock_timeout là mong muốn.
Đôi khi tất cả những lỗi này xảy ra trong tổng số.
Theo tôi, sai lầm chính ở đây là tổ chức. Đó là tổ chức, bởi vì kỹ thuật không kéo. Đây là số 2 - họ đã kiểm tra sai chỗ.
Chúng tôi đã kiểm tra nhầm chỗ vì chúng tôi không có bản sao sản xuất, điều này rất dễ kiểm tra. Nhà phát triển có thể hoàn toàn không có quyền truy cập vào sản xuất.
Và chúng tôi đã kiểm tra không có ở đó. Nếu chúng tôi đã kiểm tra ở đó, chúng tôi sẽ tự mình nhìn thấy nó. Nhà phát triển đã nhìn thấy tất cả ngay cả khi không có DBA nếu anh ta kiểm tra nó trong một môi trường tốt, nơi có cùng một lượng dữ liệu và một vị trí giống hệt nhau. Anh ấy sẽ thấy tất cả sự xuống cấp này và anh ấy sẽ xấu hổ.
Tìm hiểu thêm về autovacuum. Sau khi chúng tôi đã thực hiện một cuộc quét lớn vài triệu dòng, chúng tôi vẫn cần thực hiện REPACK. Điều này đặc biệt quan trọng đối với các chỉ mục. Họ sẽ cảm thấy tồi tệ sau khi chúng tôi dọn dẹp mọi thứ ở đó.
Và nếu bạn muốn quay trở lại công việc dọn dẹp hàng ngày, thì tôi khuyên bạn nên làm việc đó thường xuyên hơn, nhưng nhỏ hơn. Nó có thể là một lần một phút hoặc thậm chí thường xuyên hơn một chút. Và bạn cần theo dõi hai điều: thứ này không có lỗi và nó không bị tụt lại phía sau. Thủ thuật mà tôi đã chỉ ra sẽ giải quyết vấn đề này.
Những gì chúng tôi làm là mã nguồn mở. Nó được đăng trên GitLab. Và chúng tôi tạo ra nó để mọi người có thể kiểm tra ngay cả khi không có DBA. Chúng tôi đang thực hiện một phòng thí nghiệm cơ sở dữ liệu, nghĩa là chúng tôi gọi thành phần cơ sở mà Joe hiện đang làm việc. Và bạn có thể lấy một bản sao của quá trình sản xuất. Bây giờ có một triển khai của Joe cho Slack, bạn có thể nói ở đó: "giải thích yêu cầu này và yêu cầu đó" và ngay lập tức nhận được kết quả cho bản sao cơ sở dữ liệu của bạn. Bạn thậm chí có thể XÓA ở đó và sẽ không ai nhận ra điều đó.
Giả sử bạn có 10 terabyte, chúng tôi tạo phòng thí nghiệm cơ sở dữ liệu cũng có 10 terabyte. Và với cơ sở dữ liệu 10 terabyte đồng thời, 10 nhà phát triển có thể làm việc đồng thời. Mọi người đều có thể làm những gì họ muốn. Có thể xóa, thả, v.v. Thật là viển vông. Chúng ta sẽ nói về điều này vào ngày mai.
Điều này được gọi là dự phòng mỏng. Đây là dự phòng tinh tế. Đây là một loại tưởng tượng giúp loại bỏ đáng kể sự chậm trễ trong quá trình phát triển, trong quá trình thử nghiệm và biến thế giới thành một nơi tốt đẹp hơn về mặt này. Đó là, nó chỉ cho phép bạn tránh các vấn đề với các hoạt động hàng loạt.
Ví dụ: Cơ sở dữ liệu 5 terabyte, nhận một bản sao trong vòng chưa đầy 30 giây. Và nó thậm chí không phụ thuộc vào kích thước, tức là bao nhiêu terabyte không quan trọng.
Hôm nay bạn có thể đến và đào sâu vào các công cụ của chúng tôi. Bạn có thể đăng ký để xem những gì ở đó. Bạn có thể cài đặt bot này. Nó miễn phí. Viết.
câu hỏi
Rất thường xuyên trong các tình huống thực tế, hóa ra dữ liệu cần lưu lại trong bảng ít hơn nhiều so với dữ liệu cần xóa. Đó là, trong tình huống như vậy, việc thực hiện một cách tiếp cận như vậy thường dễ dàng hơn khi tạo một đối tượng mới dễ dàng hơn, chỉ sao chép dữ liệu cần thiết ở đó và chuyển bảng cũ. Rõ ràng là cần có một cách tiếp cận có lập trình vào thời điểm này, trong khi bạn sẽ chuyển đổi. Cách tiếp cận này như thế nào?
Đây là một cách tiếp cận rất tốt và một nhiệm vụ rất tốt. Nó rất giống với những gì pg_repack làm, nó rất giống với những gì bạn phải làm khi tạo ID 4 byte. Nhiều khung đã làm điều này cách đây vài năm và chỉ các tấm đã lớn lên và chúng cần được chuyển đổi thành 8 byte.
Nhiệm vụ này khá khó khăn. Chúng ta làm được rồi. Và bạn phải rất cẩn thận. Có khóa, v.v. Nhưng nó đang được thực hiện. Nghĩa là, cách tiếp cận tiêu chuẩn là sử dụng pg_repack. Bạn khai báo một nhãn như vậy. Và trước khi bạn bắt đầu tải dữ liệu ảnh chụp nhanh vào đó, bạn cũng khai báo một tấm theo dõi tất cả các thay đổi. Có một mẹo mà bạn thậm chí có thể không theo dõi một số thay đổi. Có sự tinh tế. Và sau đó bạn chuyển đổi bằng cách thay đổi cuộn. Sẽ có một khoảng thời gian tạm dừng ngắn khi chúng tôi đóng cửa tất cả mọi người, nhưng nhìn chung việc này đang được thực hiện.
Nếu bạn xem pg_repack trên GitHub, thì ở đó, khi có nhiệm vụ chuyển đổi ID từ int 4 sang int 8, thì đã có ý tưởng sử dụng chính pg_repack. Điều này cũng có thể, tuy hơi hack, nhưng nó cũng sẽ hiệu quả với việc này. Bạn có thể can thiệp vào trình kích hoạt mà pg_repack sử dụng và nói ở đó: "Chúng tôi không cần dữ liệu này", tức là chúng tôi chỉ chuyển những gì chúng tôi cần. Và sau đó anh ấy chỉ cần chuyển đổi và thế là xong.
Với cách tiếp cận này, chúng tôi vẫn nhận được một bản sao thứ hai của bảng, trong đó dữ liệu đã được lập chỉ mục và xếp chồng lên nhau rất đồng đều với các chỉ mục đẹp mắt.
Bloat không có mặt, đó là một cách tiếp cận tốt. Nhưng tôi biết rằng có những nỗ lực để phát triển tự động hóa cho việc này, tức là tạo ra một giải pháp phổ quát. Tôi có thể giúp bạn liên lạc với tự động hóa này. Nó được viết bằng Python, đó là một điều tốt.
Tôi chỉ mới biết một chút về thế giới của MySQL, vì vậy tôi đã đến để lắng nghe. Và chúng tôi sử dụng phương pháp này.
Nhưng đó chỉ là khi chúng ta có 90%. Nếu chúng ta có 5%, thì sẽ không tốt lắm khi sử dụng nó.
Cảm ơn bạn đã báo cáo! Nếu không có tài nguyên để tạo một bản sao hoàn chỉnh của prod, có bất kỳ thuật toán hoặc công thức nào để tính tải hoặc kích thước không?
Câu hỏi hay. Cho đến nay, chúng tôi có thể tìm thấy cơ sở dữ liệu nhiều terabyte. Ngay cả khi phần cứng ở đó không giống nhau, chẳng hạn như ít bộ nhớ hơn, ít bộ xử lý hơn và các đĩa không hoàn toàn giống nhau, nhưng chúng tôi vẫn làm. Nếu hoàn toàn không có nơi nào, thì bạn cần phải suy nghĩ. Hãy để tôi suy nghĩ cho đến ngày mai, bạn đã đến, chúng tôi sẽ nói chuyện, đây là một câu hỏi hay.
Cảm ơn bạn đã báo cáo! Lần đầu tiên bạn bắt đầu về thực tế là có một Postgres tuyệt vời, có những hạn chế như vậy và như vậy, nhưng nó đang phát triển. Và đây là tất cả một cái nạng nói chung. Chẳng phải tất cả điều này mâu thuẫn với sự phát triển của chính Postgres, trong đó một số tùy chọn XÓA sẽ xuất hiện hoặc thứ gì đó khác sẽ giữ ở mức thấp những gì chúng tôi đang cố gắng bôi nhọ bằng một số phương tiện kỳ lạ của chúng tôi ở đây?
Nếu chúng tôi đã nói trong SQL để xóa hoặc cập nhật nhiều bản ghi trong một giao dịch, thì làm thế nào Postgres có thể phân phối nó ở đó? Chúng tôi bị giới hạn về thể chất trong các hoạt động. Chúng tôi sẽ vẫn làm điều đó trong một thời gian dài. Và chúng tôi sẽ khóa tại thời điểm này, v.v.
Thực hiện với các chỉ mục.
Tôi có thể cho rằng việc điều chỉnh điểm kiểm tra tương tự có thể được tự động hóa. Một ngày nào đó nó có thể được. Nhưng sau đó tôi không thực sự hiểu câu hỏi.
Câu hỏi đặt ra là liệu có một véc-tơ phát triển đi chỗ này chỗ kia, và chỗ này của bạn đi song song không? Những thứ kia. Họ vẫn chưa nghĩ về nó sao?
Tôi đã nói về những nguyên tắc có thể được sử dụng bây giờ. Có một bot khác , với điều này, bạn có thể thực hiện điều chỉnh điểm kiểm tra tự động. Liệu một ngày nào đó nó có ở Postgres không? Tôi không biết, nó thậm chí còn chưa được thảo luận. Chúng ta vẫn còn xa điều đó. Nhưng có những nhà khoa học tạo ra những hệ thống mới. Và họ đẩy chúng tôi vào danh mục tự động. Có những phát triển. Ví dụ: bạn có thể xem tính năng tự động điều chỉnh. Nó tự động chọn tham số. Nhưng anh ấy sẽ không thực hiện điều chỉnh điểm kiểm tra cho bạn. Nghĩa là, nó sẽ tăng hiệu suất, bộ đệm shell, v.v.
Và để điều chỉnh điểm kiểm tra, bạn có thể làm điều này: nếu bạn có hàng nghìn cụm và phần cứng khác nhau, các máy ảo khác nhau trên đám mây, bạn có thể sử dụng bot của chúng tôi làm tự động hóa. Và max_wal_size sẽ được chọn tự động theo cài đặt mục tiêu của bạn. Nhưng cho đến nay, điều này thậm chí không gần với cốt lõi, thật không may.
Chào buổi chiều Bạn đã nói về sự nguy hiểm của các giao dịch dài hạn. Bạn nói rằng autovacuum bị chặn trong trường hợp xóa. Làm thế nào khác nó làm hại chúng ta? Bởi vì chúng ta đang nói nhiều hơn về việc giải phóng dung lượng và có thể sử dụng nó. Chúng ta còn thiếu gì nữa?
Autovacuum có lẽ không phải là vấn đề lớn nhất ở đây. Và thực tế là một giao dịch dài có thể khóa các giao dịch khác, khả năng này nguy hiểm hơn. Cô ấy có thể gặp hoặc không. Nếu cô ấy gặp, thì nó có thể rất tệ. Và với autovacuum - đây cũng là một vấn đề. Có hai vấn đề với các giao dịch dài trong OLTP: khóa và tự động hút chân không. Và nếu bạn đã bật phản hồi dự phòng nóng trên bản sao, thì bạn vẫn sẽ nhận được khóa chân không tự động trên bản chính, nó sẽ đến từ bản sao. Nhưng ít nhất sẽ không có ổ khóa. Và sẽ có loks. Chúng ta đang nói về những thay đổi dữ liệu, vì vậy ổ khóa là một điểm quan trọng ở đây. Và nếu tất cả điều này diễn ra trong một thời gian dài, thì ngày càng có nhiều giao dịch bị khóa. Họ có thể ăn cắp của người khác. Và cây lok xuất hiện. Tôi đã cung cấp một liên kết đến đoạn trích. Và vấn đề này trở nên đáng chú ý nhanh hơn so với vấn đề với autovacuum, vấn đề chỉ có thể tích lũy.
Cảm ơn bạn đã báo cáo! Bạn đã bắt đầu báo cáo của mình bằng cách nói rằng bạn đã kiểm tra không chính xác. Chúng tôi tiếp tục ý tưởng của mình rằng chúng tôi cần sử dụng cùng một thiết bị, với cơ sở theo cùng một cách. Giả sử chúng tôi đã cung cấp cho nhà phát triển một cơ sở. Và anh đã làm theo yêu cầu. Và anh ấy có vẻ ổn. Nhưng anh ấy không kiểm tra trực tiếp mà đối với trực tiếp chẳng hạn, chúng tôi có tải 60-70%. Và ngay cả khi chúng tôi sử dụng cách điều chỉnh này, nó cũng không hoạt động tốt lắm.
Có một chuyên gia trong nhóm và sử dụng các chuyên gia DBA có thể dự đoán điều gì sẽ xảy ra với tải nền thực là rất quan trọng. Khi chúng tôi chỉ thực hiện những thay đổi sạch sẽ của mình, chúng tôi sẽ thấy bức tranh. Nhưng một cách tiếp cận nâng cao hơn, khi chúng tôi làm lại điều tương tự, nhưng với tải trọng được mô phỏng trong quá trình sản xuất. Nó khá tuyệt. Cho đến lúc đó, bạn phải lớn lên. Nó giống như một người lớn. Chúng tôi chỉ nhìn vào những gì chúng tôi có và cũng xem liệu chúng tôi có đủ nguồn lực hay không. Đó là một câu hỏi hay.
Khi chúng tôi đang thực hiện chọn rác và chẳng hạn, chúng tôi có một cờ đã xóa
Đây là những gì autovacuum thực hiện tự động trong Postgres.
Ồ, anh ấy có làm không?
Autovacuum là bộ thu gom rác.
Cảm ơn bạn!
Cảm ơn bạn đã báo cáo! Có tùy chọn nào để thiết kế ngay cơ sở dữ liệu với phân vùng theo cách mà tất cả rác sẽ bị bẩn từ bảng chính ở đâu đó sang một bên không?
Tất nhiên là có.
Liệu có thể tự bảo vệ mình nếu chúng ta khóa một cái bàn không nên sử dụng?
Tất nhiên là có. Nhưng nó giống như một câu hỏi con gà và quả trứng. Nếu tất cả chúng ta đều biết điều gì sẽ xảy ra trong tương lai, thì tất nhiên, chúng ta sẽ làm mọi thứ thật tuyệt. Nhưng công việc kinh doanh đang thay đổi, có những cột mới, yêu cầu mới. Và sau đó – rất tiếc, chúng tôi muốn xóa nó. Nhưng tình huống lý tưởng này xảy ra trong cuộc sống, nhưng không phải lúc nào cũng vậy. Nhưng nhìn chung đó là một ý tưởng tốt. Chỉ cần cắt ngắn và đó là nó.
Nguồn: www.habr.com