Lược đồ cơ sở dữ liệu không phải là thứ được viết bằng đá. Nó được thiết kế cho một ứng dụng nhất định, nhưng sau đó các yêu cầu có thể và thường thay đổi. Các mô-đun và chức năng mới được thêm vào ứng dụng, nhiều dữ liệu được thu thập hơn, việc tái cấu trúc mô hình dữ liệu và mã được thực hiện. Do đó cần phải sửa đổi lược đồ cơ sở dữ liệu để thích ứng với những thay đổi này; thêm hoặc sửa đổi các cột, tạo bảng mới hoặc phân vùng các cột lớn. Các truy vấn cũng thay đổi khi các nhà phát triển thêm các cách mới để người dùng tương tác với dữ liệu - các truy vấn mới có thể sử dụng các chỉ mục mới, hiệu quả hơn, vì vậy chúng tôi gấp rút tạo chúng để cung cấp cho ứng dụng hiệu suất cơ sở dữ liệu tốt nhất.
Vì vậy, làm thế nào để chúng ta tiếp cận tốt nhất một sự thay đổi giản đồ? Những công cụ nào hữu ích? Làm thế nào để giảm thiểu tác động đến cơ sở dữ liệu sản xuất? Các vấn đề phổ biến nhất với thiết kế lược đồ là gì? Những công cụ nào có thể giúp bạn luôn cập nhật lược đồ của mình? Trong bài đăng trên blog này, chúng tôi sẽ cung cấp cho bạn tổng quan ngắn gọn về cách thực hiện các thay đổi giản đồ trong MySQL và MariaDB. Xin lưu ý rằng chúng ta sẽ không thảo luận về những thay đổi giản đồ trong ngữ cảnh của Cụm Galera. Chúng ta đã thảo luận về Tổng số đơn hàng bị cô lập, Nâng cấp giản đồ cuộn và các mẹo để giảm thiểu tác động từ RSU trong các bài đăng trên blog trước. Chúng tôi cũng sẽ thảo luận về các mẹo và thủ thuật liên quan đến thiết kế giản đồ và cách ClusterControl có thể giúp bạn luôn cập nhật tất cả các thay đổi về lược đồ.
Các loại thay đổi lược đồ
Những điều đầu tiên trước tiên. Trước khi đi sâu vào chủ đề, chúng ta phải hiểu cách MySQL và MariaDB thực hiện các thay đổi lược đồ. Bạn thấy đấy, một lần thay đổi giản đồ không bằng một lần thay đổi giản đồ khác.
Bạn có thể đã nghe nói về thay đổi trực tuyến, thay đổi tức thì hoặc thay đổi tại chỗ. Tất cả những điều này là kết quả của công việc đang diễn ra nhằm giảm thiểu tác động của các thay đổi lược đồ đối với cơ sở dữ liệu sản xuất. Trước đây, hầu hết tất cả các thay đổi giản đồ đều bị chặn. Nếu bạn thực hiện một thay đổi giản đồ, tất cả các truy vấn sẽ bắt đầu chồng chất, chờ ALTER hoàn thành. Rõ ràng, điều này đặt ra nhiều vấn đề nghiêm trọng cho việc triển khai sản xuất. Chắc chắn, mọi người ngay lập tức bắt đầu tìm kiếm các giải pháp thay thế và chúng ta sẽ thảo luận về chúng sau trong blog này, vì ngay cả ngày nay những giải pháp này vẫn còn phù hợp. Tuy nhiên, công việc bắt đầu cải thiện khả năng của MySQL để chạy DDL (Ngôn ngữ định nghĩa dữ liệu) mà không ảnh hưởng nhiều đến các truy vấn khác.
Thay đổi tức thì
Đôi khi không cần thiết phải chạm vào bất kỳ dữ liệu nào trong vùng bảng, vì tất cả những gì phải thay đổi là siêu dữ liệu. Ví dụ ở đây sẽ giảm một chỉ mục hoặc đổi tên một cột. Các hoạt động như vậy là nhanh chóng và hiệu quả. Thông thường, tác động của chúng bị hạn chế. Tuy nhiên, nó không phải là không có bất kỳ tác động nào. Đôi khi phải mất vài giây để thực hiện thay đổi siêu dữ liệu và thay đổi đó yêu cầu phải có khóa siêu dữ liệu. Khóa này trên cơ sở mỗi bảng và nó có thể chặn các hoạt động khác sẽ được thực hiện trên bảng này. Bạn sẽ thấy đây là mục nhập "Đang chờ khóa siêu dữ liệu bảng" trong danh sách xử lý.
Một ví dụ về sự thay đổi đó có thể là ADD COLUMN tức thì, được giới thiệu trong MariaDB 10.3 và MySQL 8.0. Nó cung cấp khả năng thực hiện thay đổi lược đồ khá phổ biến này mà không có bất kỳ sự chậm trễ nào. Cả MariaDB và Oracle đều quyết định bao gồm mã từ Tencent Game cho phép thêm ngay một cột mới vào bảng. Điều này là trong một số điều kiện cụ thể; cột phải được thêm vào là cột cuối cùng, chỉ mục văn bản đầy đủ không thể tồn tại trong bảng, không thể nén định dạng hàng - bạn có thể tìm thêm thông tin về cách hoạt động của cột thêm tức thì trong tài liệu MariaDB. Đối với MySQL, tài liệu tham khảo chính thức duy nhất có thể được tìm thấy trên blog mysqlserverteam.com, mặc dù có một lỗi để cập nhật tài liệu chính thức.
Thay đổi tại chỗ
Một số thay đổi yêu cầu sửa đổi dữ liệu trong vùng bảng. Những sửa đổi như vậy có thể được thực hiện trên chính dữ liệu và không cần tạo bảng tạm thời với cấu trúc dữ liệu mới. Những thay đổi như vậy, thường (mặc dù không phải luôn luôn) cho phép các truy vấn khác chạm vào bảng được thực thi trong khi thay đổi giản đồ đang chạy. Một ví dụ về thao tác như vậy là thêm một chỉ mục phụ mới vào bảng. Thao tác này sẽ mất một khoảng thời gian để thực hiện nhưng sẽ cho phép thực thi DML.
Tạo lại bảng
Nếu không thể thực hiện thay đổi tại chỗ, InnoDB sẽ tạo một bảng tạm thời với cấu trúc mới mong muốn. Sau đó, nó sẽ sao chép dữ liệu hiện có vào bảng mới. Thao tác này là thao tác tốn kém nhất và có khả năng (mặc dù không phải lúc nào cũng xảy ra) để khóa DML. Kết quả là, sự thay đổi lược đồ như vậy rất khó thực hiện trên một bảng lớn trên một máy chủ độc lập mà không có sự trợ giúp của các công cụ bên ngoài - thông thường bạn không thể để cơ sở dữ liệu của mình bị khóa trong nhiều phút hoặc thậm chí hàng giờ. Ví dụ về thao tác như vậy sẽ là thay đổi kiểu dữ liệu cột, ví dụ như từ INT thành VARCHAR.
Thay đổi và sao chép lược đồ
Ok, vì vậy chúng tôi biết rằng InnoDB cho phép thay đổi lược đồ trực tuyến và nếu chúng ta tham khảo tài liệu MySQL, chúng ta sẽ thấy rằng phần lớn các thay đổi lược đồ (ít nhất là trong số những thay đổi phổ biến nhất) có thể được thực hiện trực tuyến. Lý do đằng sau việc dành hàng giờ phát triển để tạo ra các công cụ thay đổi lược đồ trực tuyến như gh-ost là gì? Chúng tôi có thể chấp nhận rằng pt-online-schema-change là tàn tích của thời cũ, nhưng gh-ost là một phần mềm mới.
Câu trả lời là phức tạp. Có hai vấn đề chính.
Đối với người mới bắt đầu, khi bạn bắt đầu thay đổi giản đồ, bạn không có quyền kiểm soát nó. Bạn có thể hủy bỏ nó nhưng bạn không thể tạm dừng nó. Bạn không thể điều tiết nó. Như bạn có thể tưởng tượng, việc xây dựng lại bảng là một hoạt động tốn kém và ngay cả khi InnoDB cho phép thực thi DML, khối lượng công việc I / O bổ sung từ DDL sẽ ảnh hưởng đến tất cả các truy vấn khác và không có cách nào để hạn chế tác động này đến mức có thể chấp nhận được đối với ứng dụng.
Thứ hai, vấn đề còn nghiêm trọng hơn, là nhân rộng. Nếu bạn thực hiện một hoạt động không chặn, yêu cầu xây dựng lại bảng, thì nó thực sự sẽ không khóa DML nhưng điều này chỉ đúng trên trang cái. Giả sử DDL như vậy mất 30 phút để hoàn thành - Tốc độ ALTER phụ thuộc vào phần cứng nhưng khá phổ biến khi thấy thời gian thực thi như vậy trên các bảng có phạm vi kích thước 20GB. Sau đó, nó được sao chép cho tất cả các nô lệ và, kể từ thời điểm DDL bắt đầu trên các nô lệ đó, quá trình sao chép sẽ đợi nó hoàn thành. Không thành vấn đề nếu bạn sử dụng MySQL hay MariaDB hoặc nếu bạn có bản sao đa luồng. Các nô lệ sẽ bị trễ - chúng sẽ đợi 30 phút đó để DDL hoàn thành trước khi bắt đầu áp dụng các sự kiện binlog còn lại. Như bạn có thể tưởng tượng, 30 phút lag (đôi khi thậm chí 30 giây sẽ không thể chấp nhận được - tất cả phụ thuộc vào ứng dụng) là điều khiến không thể sử dụng những nô lệ đó để mở rộng quy mô. Tất nhiên, có những cách giải quyết - bạn có thể thực hiện các thay đổi lược đồ từ cuối lên đầu của chuỗi sao chép nhưng điều này hạn chế nghiêm trọng các tùy chọn của bạn. Đặc biệt nếu bạn sử dụng sao chép dựa trên hàng, bạn chỉ có thể thực hiện các thay đổi lược đồ tương thích theo cách này. Một vài ví dụ về những hạn chế của việc nhân rộng theo hàng; bạn không thể bỏ bất kỳ cột nào không phải là cột cuối cùng, bạn không thể thêm cột vào một vị trí khác với cột cuối cùng. Bạn cũng không thể thay đổi loại cột (ví dụ:INT -> VARCHAR).
Như bạn có thể thấy, sao chép thêm phức tạp vào cách bạn có thể thực hiện các thay đổi giản đồ. Các hoạt động không chặn trên máy chủ độc lập sẽ bị chặn trong khi thực thi trên nô lệ. Hãy xem xét một số phương pháp bạn có thể sử dụng để giảm thiểu tác động của các thay đổi giản đồ.
Công cụ thay đổi lược đồ trực tuyến
Như chúng tôi đã đề cập trước đó, có các công cụ nhằm thực hiện các thay đổi lược đồ. Các ứng dụng phổ biến nhất là pt-online-schema-change do Percona tạo ra và gh-ost do GitHub tạo ra. Trong một loạt các bài đăng trên blog, chúng tôi đã so sánh chúng và thảo luận về cách gh-ost có thể được sử dụng để thực hiện các thay đổi giản đồ và cách bạn có thể điều chỉnh và định cấu hình lại một quá trình di chuyển đang diễn ra. Ở đây chúng tôi sẽ không đi vào chi tiết, nhưng chúng tôi vẫn muốn đề cập đến một số khía cạnh quan trọng nhất của việc sử dụng các công cụ đó. Đối với người mới bắt đầu, một thay đổi lược đồ được thực thi thông qua pt-osc hoặc gh-ost sẽ xảy ra trên tất cả các nút cơ sở dữ liệu cùng một lúc. Không có bất kỳ sự chậm trễ nào về thời điểm áp dụng thay đổi. Điều này giúp bạn có thể sử dụng các công cụ đó ngay cả đối với các thay đổi giản đồ không tương thích với sao chép dựa trên hàng. Các cơ chế chính xác về cách các công cụ đó theo dõi các thay đổi trên bảng là khác nhau (kích hoạt trong pt-osc so với phân tích cú pháp binlog trong gh-ost) nhưng ý tưởng chính là giống nhau - một bảng mới được tạo với lược đồ mong muốn và dữ liệu hiện có là sao chép từ bảng cũ. Trong khi chờ đợi, DML được theo dõi (theo cách này hay cách khác) và áp dụng cho bảng mới. Khi tất cả dữ liệu được di chuyển, các bảng được đổi tên và bảng mới thay thế bảng cũ. Đây là hoạt động nguyên tử nên nó không hiển thị với ứng dụng. Cả hai công cụ đều có tùy chọn để giảm tải và tạm dừng các hoạt động. Gh-ost có thể dừng tất cả hoạt động, chỉ pt-osc mới có thể dừng quá trình sao chép dữ liệu giữa bảng cũ và bảng mới - các trình kích hoạt sẽ vẫn hoạt động và chúng sẽ tiếp tục sao chép dữ liệu, điều này làm tăng thêm một số chi phí. Do bảng đổi tên, cả hai công cụ đều có một số hạn chế liên quan đến khóa ngoại - không được hỗ trợ bởi gh-ost, được hỗ trợ một phần bởi pt-osc thông qua ALTER thông thường, có thể gây ra độ trễ sao chép (không khả thi nếu bảng con lớn) hoặc do bỏ bảng cũ trước khi đổi tên bảng mới - thật nguy hiểm vì không có cách nào để khôi phục nếu vì lý do nào đó, dữ liệu không được sao chép chính xác vào bảng mới. Các trình kích hoạt cũng rất khó để hỗ trợ.
Chúng không được hỗ trợ trong gh-ost, pt-osc trong MySQL 5.7 và phiên bản mới hơn có hỗ trợ hạn chế cho các bảng có trình kích hoạt hiện có. Các hạn chế quan trọng khác đối với các công cụ thay đổi lược đồ trực tuyến là khóa duy nhất hoặc khóa chính phải tồn tại trong bảng. Nó được sử dụng để xác định các hàng để sao chép giữa các bảng cũ và mới. Những công cụ đó cũng chậm hơn nhiều so với ALTER trực tiếp - một thay đổi mất hàng giờ đồng hồ trong khi chạy ALTER có thể mất vài ngày khi được thực hiện bằng pt-osc hoặc gh-ost.
Mặt khác, như chúng tôi đã đề cập, miễn là các yêu cầu được đáp ứng và các giới hạn không có hiệu lực, bạn có thể chạy tất cả các thay đổi giản đồ bằng cách sử dụng một trong các công cụ. Tất cả sẽ diễn ra cùng lúc trên tất cả các máy chủ, do đó bạn không phải lo lắng về khả năng tương thích. Bạn cũng có một số mức độ kiểm soát đối với cách quá trình được thực thi (ít hơn trong pt-osc, nhiều hơn trong gh-ost).
Bạn có thể giảm tác động của thay đổi giản đồ, bạn có thể tạm dừng chúng và chỉ để chúng chạy dưới sự giám sát, bạn có thể kiểm tra thay đổi trước khi thực hiện nó. Bạn có thể yêu cầu họ theo dõi độ trễ của quá trình sao chép và tạm dừng nếu tác động được phát hiện. Điều này làm cho những công cụ đó trở thành một bổ sung thực sự tuyệt vời cho kho vũ khí của DBA trong khi làm việc với nhân rộng MySQL.
Thay đổi giản đồ cuộn
Thông thường, một DBA sẽ sử dụng một trong các công cụ thay đổi giản đồ trực tuyến. Nhưng như chúng ta đã thảo luận trước đó, trong một số trường hợp, chúng không thể được sử dụng và thay đổi trực tiếp là lựa chọn khả thi duy nhất. Nếu chúng ta đang nói về MySQL độc lập, bạn không có lựa chọn nào khác - nếu thay đổi là không chặn, thì tốt. Nếu không, thì bạn không thể làm gì được. Nhưng sau đó, không có nhiều người chạy MySQL dưới dạng các phiên bản đơn lẻ, phải không? Làm thế nào về nhân rộng? Như chúng ta đã thảo luận trước đó, thay đổi trực tiếp trên máy chủ là không khả thi - hầu hết các trường hợp, nó sẽ gây ra độ trễ trên máy chủ và điều này có thể không được chấp nhận. Tuy nhiên, điều có thể làm là thực hiện thay đổi theo kiểu cuốn chiếu. Bạn có thể bắt đầu với nô lệ và sau khi thay đổi được áp dụng cho tất cả chúng, hãy thăng cấp một trong các nô lệ làm chủ mới, giáng cấp chủ cũ thành nô lệ và thực hiện thay đổi trên đó. Chắc chắn, thay đổi phải tương thích nhưng nói thật, các trường hợp phổ biến nhất mà bạn không thể sử dụng các thay đổi giản đồ trực tuyến là do thiếu khóa chính hoặc khóa duy nhất. Đối với tất cả các trường hợp khác, có một số cách giải quyết, đặc biệt là trong pt-online-schema-change vì gh-ost có nhiều hạn chế khó khăn hơn. Đó là một cách giải quyết mà bạn sẽ gọi là “quá” hoặc “xa lý tưởng”, nhưng nó sẽ thực hiện được công việc nếu bạn không có lựa chọn nào khác để lựa chọn. Điều quan trọng nữa là, hầu hết các hạn chế có thể tránh được nếu bạn theo dõi lược đồ của mình và nắm bắt các vấn đề trước khi bảng phát triển. Ngay cả khi ai đó tạo bảng mà không có khóa chính, thì việc chạy thay đổi trực tiếp mất nửa giây hoặc ít hơn cũng không thành vấn đề vì bảng gần như trống.
Nếu nó phát triển, đây sẽ trở thành một vấn đề nghiêm trọng nhưng DBA phải nắm bắt được loại vấn đề này trước khi họ thực sự bắt đầu tạo ra vấn đề. Chúng tôi sẽ trình bày một số mẹo và thủ thuật về cách đảm bảo bạn sẽ nắm bắt được những vấn đề như vậy đúng lúc. Chúng tôi cũng sẽ chia sẻ các mẹo chung về cách thiết kế lược đồ của bạn.
Mẹo và Thủ thuật
Thiết kế lược đồ
Như chúng tôi đã trình bày trong bài đăng này, các công cụ thay đổi lược đồ trực tuyến khá quan trọng khi làm việc với thiết lập sao chép, do đó, điều khá quan trọng là đảm bảo lược đồ của bạn được thiết kế theo cách mà nó sẽ không giới hạn các tùy chọn của bạn để thực hiện các thay đổi lược đồ. Có ba khía cạnh quan trọng. Đầu tiên, phải tồn tại khóa chính hoặc khóa duy nhất - bạn cần đảm bảo rằng không có bảng nào không có khóa chính trong cơ sở dữ liệu của mình. Bạn nên theo dõi điều này một cách thường xuyên, nếu không nó có thể trở thành một vấn đề nghiêm trọng trong tương lai. Thứ hai, bạn nên xem xét nghiêm túc nếu sử dụng khóa ngoại là một ý kiến hay. Chắc chắn, chúng có công dụng của chúng nhưng chúng cũng thêm chi phí vào cơ sở dữ liệu của bạn và chúng có thể khiến việc sử dụng các công cụ thay đổi lược đồ trực tuyến có vấn đề. Các mối quan hệ có thể được thực thi bởi ứng dụng. Ngay cả khi nó có nghĩa là phải làm việc nhiều hơn, nó vẫn có thể là một ý tưởng tốt hơn là bắt đầu sử dụng khóa ngoại và bị giới hạn nghiêm ngặt đối với những loại thay đổi lược đồ có thể được thực hiện. Thứ ba, yếu tố kích hoạt. Câu chuyện tương tự như với khóa nước ngoài. Chúng là một tính năng tốt cần có, nhưng chúng có thể trở thành gánh nặng. Bạn cần nghiêm túc xem xét nếu lợi ích từ việc sử dụng chúng lớn hơn những hạn chế mà chúng đặt ra.
Thay đổi giản đồ theo dõi
Quản lý thay đổi lược đồ không chỉ là chạy các thay đổi lược đồ. Bạn cũng phải luôn cập nhật cấu trúc lược đồ của mình, đặc biệt nếu bạn không phải là người duy nhất thực hiện các thay đổi.
ClusterControl cung cấp cho người dùng các công cụ để theo dõi một số vấn đề thiết kế lược đồ phổ biến nhất. Nó có thể giúp bạn theo dõi các bảng không có khóa chính:
Như chúng ta đã thảo luận trước đó, việc nắm bắt sớm các bảng như vậy là rất quan trọng vì các khóa chính phải được thêm vào bằng cách sử dụng thay đổi trực tiếp.
ClusterControl cũng có thể giúp bạn theo dõi các chỉ mục trùng lặp. Thông thường, bạn không muốn có nhiều chỉ mục thừa. Trong ví dụ trên, bạn có thể thấy rằng có một chỉ mục trên (k, c) và cũng có một chỉ mục trên (k). Bất kỳ truy vấn nào có thể sử dụng chỉ mục được tạo trên cột ‘k’ cũng có thể sử dụng chỉ mục tổng hợp được tạo trên các cột (k, c). Có những trường hợp có lợi nếu giữ các chỉ mục dư thừa nhưng bạn phải tiếp cận nó theo từng trường hợp. Bắt đầu từ MySQL 8.0, có thể nhanh chóng kiểm tra xem một chỉ mục có thực sự cần thiết hay không. Bạn có thể tạo chỉ mục dư thừa là "ẩn" bằng cách chạy:
ALTER TABLE sbtest.sbtest1 ALTER INDEX k_1 INVISIBLE;Điều này sẽ làm cho MySQL bỏ qua chỉ mục đó và thông qua giám sát, bạn có thể kiểm tra xem có bất kỳ tác động tiêu cực nào đến hiệu suất của cơ sở dữ liệu hay không. Nếu mọi thứ hoạt động như kế hoạch trong một thời gian (vài ngày hoặc thậm chí vài tuần), bạn có thể lập kế hoạch loại bỏ chỉ mục thừa. Trong trường hợp bạn phát hiện có điều gì đó không ổn, bạn luôn có thể bật lại chỉ mục này bằng cách chạy:
ALTER TABLE sbtest.sbtest1 ALTER INDEX k_1 VISIBLE;Các hoạt động đó diễn ra tức thì và chỉ mục luôn ở đó và vẫn được duy trì - chỉ có điều là nó sẽ không được trình tối ưu hóa xem xét. Nhờ tùy chọn này, việc loại bỏ các chỉ mục trong MySQL 8.0 sẽ hoạt động an toàn hơn nhiều. Trong các phiên bản trước, việc thêm lại một chỉ mục bị xóa sai có thể mất hàng giờ nếu không phải là vài ngày trên các bảng lớn.
ClusterControl cũng có thể cho bạn biết về các bảng MyISAM.
Mặc dù MyISAM vẫn có thể có các công dụng của nó, nhưng bạn phải lưu ý rằng nó không phải là một công cụ lưu trữ giao dịch. Do đó, nó có thể dễ dàng tạo ra sự không nhất quán về dữ liệu giữa các nút trong thiết lập sao chép.
Một tính năng rất hữu ích khác của ClusterControl là một trong những báo cáo hoạt động - Báo cáo thay đổi lược đồ.
Trong một thế giới lý tưởng, DBA sẽ xem xét, phê duyệt và thực hiện tất cả các thay đổi của lược đồ. Thật không may, điều này không phải luôn luôn như vậy. Quá trình xem xét như vậy không diễn ra tốt với sự phát triển nhanh. Ngoài ra, tỷ lệ Nhà phát triển trên DBA thường khá cao, điều này cũng có thể trở thành một vấn đề vì DBA sẽ đấu tranh để không trở thành nút cổ chai. Đó là lý do tại sao không có gì lạ khi thấy các thay đổi giản đồ được thực hiện ngoài tầm hiểu biết của DBA. Tuy nhiên, DBA thường là người chịu trách nhiệm về hiệu suất và tính ổn định của cơ sở dữ liệu. Nhờ có Báo cáo thay đổi giản đồ, giờ đây họ có thể theo dõi các thay đổi của giản đồ.
Lúc đầu, một số cấu hình là cần thiết. Trong tệp cấu hình cho một cụm nhất định (/etc/cmon.d/cmon_X.cnf), bạn phải xác định máy chủ ClusterControl nào sẽ theo dõi các thay đổi và lược đồ nào nên được kiểm tra.
schema_change_detection_address=10.0.0.126
schema_change_detection_databases=sbtestSau khi hoàn tất, bạn có thể lập lịch báo cáo để thực hiện một cách thường xuyên. Một ví dụ đầu ra có thể giống như dưới đây:
Như bạn có thể thấy, hai bảng đã thay đổi kể từ lần chạy báo cáo trước. Trong lần đầu tiên, một chỉ mục tổng hợp mới đã được tạo trên các cột (k, c). Trong bảng thứ hai, một cột đã được thêm vào.
Trong lần chạy tiếp theo, chúng tôi nhận được thông tin về bảng mới, được tạo mà không có bất kỳ chỉ mục hoặc khóa chính nào. Sử dụng loại thông tin này, chúng tôi có thể dễ dàng hành động khi cần và giải quyết các vấn đề trước khi chúng thực sự bắt đầu trở thành kẻ chặn.
