Zabbix là một hệ thống giám sát. Giống như bất kỳ hệ thống nào khác, nó phải đối mặt với ba vấn đề chính của tất cả các hệ thống giám sát: thu thập và xử lý dữ liệu, lưu trữ lịch sử và làm sạch dữ liệu.
Các khâu tiếp nhận, xử lý và ghi dữ liệu mất nhiều thời gian. Không nhiều, nhưng đối với một hệ thống lớn, điều này có thể dẫn đến độ trễ lớn. Vấn đề lưu trữ là vấn đề truy cập dữ liệu. Chúng được sử dụng để báo cáo, kiểm tra và kích hoạt. Độ trễ trong truy cập dữ liệu cũng ảnh hưởng đến hiệu suất. Khi cơ sở dữ liệu phát triển, dữ liệu không liên quan phải bị xóa. Loại bỏ là một hoạt động khó khăn và tiêu tốn một số tài nguyên.
Các vấn đề về độ trễ trong quá trình thu thập và lưu trữ trong Zabbix được giải quyết bằng bộ đệm: một số loại bộ đệm, bộ đệm trong cơ sở dữ liệu. Để giải quyết vấn đề thứ ba, bộ nhớ đệm không phù hợp nên Zabbix đã sử dụng TimescaleDB. Anh ấy sẽ kể cho bạn nghe về điều đó Andrey Gushchin - kỹ sư hỗ trợ kỹ thuật . Andrey đã hỗ trợ Zabbix hơn 6 năm và có kinh nghiệm trực tiếp về hiệu suất.
TimescaleDB hoạt động như thế nào, nó có thể mang lại hiệu suất như thế nào so với PostgreSQL thông thường? Zabbix đóng vai trò gì đối với cơ sở dữ liệu TimescaleDB? Làm cách nào để bắt đầu lại từ đầu và cách di chuyển từ PostgreSQL cũng như cấu hình nào có hiệu suất tốt hơn? Về tất cả điều này dưới vết cắt.
Những thách thức về năng suất
Mọi hệ thống giám sát đều phải đối mặt với những thách thức về hiệu suất cụ thể. Tôi sẽ nói về ba trong số đó: thu thập và xử lý dữ liệu, lưu trữ và xóa lịch sử.
Thu thập và xử lý dữ liệu nhanh chóng. Một hệ thống giám sát tốt sẽ nhanh chóng nhận được tất cả dữ liệu và xử lý dữ liệu theo biểu thức kích hoạt - theo tiêu chí của nó. Sau khi xử lý, hệ thống cũng phải nhanh chóng lưu lại những dữ liệu này vào cơ sở dữ liệu để sử dụng sau này.
Lưu trữ lịch sử. Một hệ thống giám sát tốt sẽ lưu trữ lịch sử trong cơ sở dữ liệu và cung cấp khả năng truy cập dễ dàng vào các số liệu. Lịch sử cần được sử dụng trong các báo cáo, đồ thị, trình kích hoạt, ngưỡng và các mục dữ liệu cảnh báo được tính toán.
Xóa lịch sử. Đôi khi sẽ có ngày bạn không cần lưu trữ số liệu. Tại sao bạn cần dữ liệu đã được thu thập cách đây 5 năm, một hoặc hai tháng: một số nút đã bị xóa, một số máy chủ hoặc số liệu không còn cần thiết vì chúng đã lỗi thời và không còn được thu thập nữa. Một hệ thống giám sát tốt nên lưu trữ dữ liệu lịch sử và thỉnh thoảng xóa nó để cơ sở dữ liệu không phát triển.
Dọn dẹp dữ liệu cũ là một vấn đề quan trọng ảnh hưởng lớn đến hiệu suất cơ sở dữ liệu.
Bộ nhớ đệm trong Zabbix
Trong Zabbix, cuộc gọi đầu tiên và thứ hai được giải quyết bằng bộ nhớ đệm. RAM được sử dụng để thu thập và xử lý dữ liệu. Để lưu trữ - lịch sử trong trình kích hoạt, biểu đồ và các phần tử dữ liệu được tính toán. Về phía cơ sở dữ liệu, có một số bộ nhớ đệm dành cho các lựa chọn cơ bản, chẳng hạn như biểu đồ.
Bộ nhớ đệm bên cạnh máy chủ Zabbix là:
- Cấu hìnhCache;
- Giá trịCache;
- Lịch sửCache;
- TrendsCache.
Hãy xem xét chúng chi tiết hơn.
Bộ đệm cấu hình
Đây là bộ đệm chính nơi chúng tôi lưu trữ số liệu, máy chủ, mục dữ liệu, trình kích hoạt - mọi thứ chúng tôi cần cho Quá trình tiền xử lý và thu thập dữ liệu.
Tất cả điều này được lưu trữ trong ConfigurationCache để không tạo ra các truy vấn không cần thiết trong cơ sở dữ liệu. Sau khi máy chủ khởi động, chúng tôi cập nhật bộ đệm này, tạo và cập nhật cấu hình định kỳ.
Thu thập dữ liệu
Sơ đồ khá lớn, nhưng điều chính trong đó là người sưu tầm. Đây là những "người thăm dò" khác nhau - quy trình lắp ráp. Họ chịu trách nhiệm về các loại lắp ráp khác nhau: họ thu thập dữ liệu qua SNMP, IPMI và chuyển tất cả sang PreProcessing.
Các nhà sưu tập được viền màu cam.
Zabbix đã tính toán các mục tổng hợp cần thiết để tổng hợp các lần kiểm tra. Nếu có, chúng tôi sẽ tìm nạp dữ liệu trực tiếp từ ValueCache.
Lịch sử tiền xử lýCache
Tất cả người thu thập đều sử dụng ConfigurationCache để nhận công việc. Sau đó, họ chuyển chúng sang PreProcessing.
PreProcessing sử dụng ConfigurationCache để nhận các bước PreProcessing. Nó xử lý dữ liệu này theo nhiều cách khác nhau.
Sau khi xử lý dữ liệu bằng PreProcessing, chúng ta lưu vào HistoryCache để xử lý. Việc này kết thúc việc thu thập dữ liệu và chúng ta chuyển sang quy trình chính trong Zabbix - đồng bộ hóa lịch sử, vì nó là một kiến trúc nguyên khối.
Lưu ý: Xử lý trước là một thao tác khá khó khăn. Với v 4.2 nó đã được chuyển sang proxy. Nếu bạn có Zabbix rất lớn với số lượng lớn các phần tử dữ liệu và tần suất thu thập thì điều này giúp công việc dễ dàng hơn nhiều.
ValueCache, bộ đệm lịch sử và xu hướng
Trình đồng bộ hóa lịch sử là quy trình chính xử lý nguyên tử từng phần tử dữ liệu, tức là từng giá trị.
Trình đồng bộ hóa lịch sử lấy các giá trị từ HistoryCache và kiểm tra Cấu hình để biết sự hiện diện của trình kích hoạt tính toán. Nếu chúng tồn tại, nó sẽ tính toán.
Trình đồng bộ hóa lịch sử tạo sự kiện, báo cáo để tạo cảnh báo nếu cấu hình yêu cầu và bản ghi. Nếu có trình kích hoạt cho quá trình xử lý tiếp theo thì nó sẽ lưu giá trị này trong ValueCache để không truy cập vào bảng lịch sử. Đây là cách ValueCache chứa đầy dữ liệu cần thiết để tính toán trình kích hoạt và các phần tử được tính toán.
Trình đồng bộ hóa lịch sử ghi tất cả dữ liệu vào cơ sở dữ liệu và ghi vào đĩa. Quá trình xử lý kết thúc ở đây.
Bộ nhớ đệm trong cơ sở dữ liệu
Về phía cơ sở dữ liệu, có nhiều bộ đệm khác nhau khi bạn muốn xem biểu đồ hoặc báo cáo về các sự kiện:
Innodb_buffer_poolvề phía MySQL;shared_buffersvề phía PostgreSQL;effective_cache_sizevề phía Oracle;shared_poolvề phía DB2.
Có nhiều bộ đệm khác, nhưng đây là những bộ đệm chính cho tất cả các cơ sở dữ liệu. Chúng cho phép bạn lưu trữ dữ liệu trong RAM thường cần cho các truy vấn. Họ có công nghệ riêng cho việc này.
Hiệu suất cơ sở dữ liệu là rất quan trọng
Máy chủ Zabbix liên tục thu thập dữ liệu và ghi dữ liệu đó. Khi khởi động lại, nó cũng đọc lịch sử để điền vào ValueCache. Sử dụng tập lệnh và báo cáo API Zabbix, được xây dựng trên giao diện Web. API Zabbix truy cập cơ sở dữ liệu và truy xuất dữ liệu cần thiết cho biểu đồ, báo cáo, danh sách sự kiện và các vấn đề mới nhất.
Để hình dung - grafana. Đây là một giải pháp phổ biến trong số người dùng của chúng tôi. Nó có thể gửi trực tiếp yêu cầu thông qua API Zabbix và tới cơ sở dữ liệu, đồng thời tạo ra sự cạnh tranh nhất định để nhận dữ liệu. Do đó, cần phải điều chỉnh cơ sở dữ liệu tốt hơn và tốt hơn để phù hợp với việc cung cấp kết quả và thử nghiệm nhanh chóng.
Quản gia
Thử thách hiệu suất thứ ba trong Zabbix là xóa lịch sử bằng Housekeeper. Nó tuân theo tất cả các cài đặt - các yếu tố dữ liệu cho biết thời gian lưu trữ động lực của các thay đổi (xu hướng) tính theo ngày.
Chúng tôi tính toán TrendsCache một cách nhanh chóng. Khi dữ liệu đến, chúng tôi tổng hợp dữ liệu trong một giờ và ghi lại vào các bảng để biết động lực thay đổi xu hướng.
Quản gia bắt đầu và xóa thông tin khỏi cơ sở dữ liệu bằng cách sử dụng các lựa chọn thông thường. Điều này không phải lúc nào cũng hiệu quả, như có thể thấy từ biểu đồ hiệu suất của các quy trình nội bộ.
Biểu đồ màu đỏ cho thấy trình đồng bộ hóa Lịch sử liên tục bận. Biểu đồ màu cam ở trên cùng là Housekeeper, đang chạy liên tục. Anh ấy đợi cơ sở dữ liệu xóa tất cả các hàng mà anh ấy đã chỉ định.
Khi nào bạn nên tắt Housekeeper? Ví dụ: có “ID vật phẩm” và bạn cần xóa 5 nghìn hàng cuối cùng trong một thời gian nhất định. Tất nhiên, điều này xảy ra theo chỉ mục. Nhưng thông thường tập dữ liệu rất lớn và cơ sở dữ liệu vẫn đọc từ đĩa và lưu vào bộ đệm. Đây luôn là một hoạt động rất tốn kém đối với cơ sở dữ liệu và tùy thuộc vào kích thước của cơ sở dữ liệu, có thể dẫn đến các vấn đề về hiệu suất.
Quản gia rất dễ bị vô hiệu hóa. Trong giao diện Web có thiết lập ở mục “Quản trị chung” dành cho Housekeeper. Chúng tôi vô hiệu hóa tính năng Quản lý nội bộ đối với lịch sử xu hướng nội bộ và nó không còn quản lý nó nữa.
Quản gia đã bị tắt, biểu đồ được san bằng - vấn đề nào có thể xảy ra trong trường hợp này và điều gì có thể giúp giải quyết thử thách hiệu suất thứ ba?
Phân vùng - phân vùng hoặc phân vùng
Thông thường, việc phân vùng được cấu hình theo một cách khác nhau trên mỗi cơ sở dữ liệu quan hệ mà tôi đã liệt kê. Mỗi người có công nghệ riêng, nhưng nhìn chung chúng giống nhau. Việc tạo một phân vùng mới thường dẫn đến một số vấn đề nhất định.
Thông thường, các phân vùng được cấu hình tùy thuộc vào “thiết lập” - lượng dữ liệu được tạo trong một ngày. Theo quy định, Phân vùng được thực hiện trong một ngày, đây là mức tối thiểu. Đối với xu hướng của lô mới - 1 tháng.
Các giá trị có thể thay đổi nếu “thiết lập” rất lớn. Nếu một “thiết lập” nhỏ lên tới 5 nvps (giá trị mới mỗi giây), thì mức trung bình là từ 000 đến 5, thì mức trung bình là từ 000 đến 25, thì mức lớn là trên 000 nvps. Đây là những bản cài đặt lớn và rất lớn yêu cầu cấu hình cơ sở dữ liệu cẩn thận.
Đối với những cài đặt rất lớn, khoảng thời gian một ngày có thể không phải là tối ưu. Tôi đã thấy các phân vùng MySQL từ 40 GB trở lên mỗi ngày. Đây là một lượng dữ liệu rất lớn có thể gây ra vấn đề và cần phải giảm bớt.
Phân vùng mang lại điều gì?
Bảng phân vùng. Thường đây là những tập tin riêng biệt trên đĩa. Kế hoạch truy vấn chọn một phân vùng tối ưu hơn. Thông thường phân vùng được sử dụng theo phạm vi - điều này cũng đúng với Zabbix. Chúng tôi sử dụng “dấu thời gian” ở đó - thời gian kể từ đầu kỷ nguyên. Đây là những con số bình thường đối với chúng tôi. Bạn đặt đầu và cuối ngày - đây là một phân vùng.
Loại bỏ nhanh chóng - DELETE. Một tệp/bảng phụ được chọn, thay vì lựa chọn các hàng để xóa.
Tăng tốc đáng kể việc truy xuất dữ liệu SELECT - sử dụng một hoặc nhiều phân vùng, thay vì toàn bộ bảng. Nếu bạn truy cập dữ liệu đã cũ hai ngày, nó sẽ được lấy từ cơ sở dữ liệu nhanh hơn vì bạn chỉ cần tải một tệp vào bộ nhớ đệm và trả về chứ không phải một bảng lớn.
Thường thì nhiều cơ sở dữ liệu cũng được tăng tốc INSERT — chèn vào bảng con.
Thang thời gianDB
Đối với phiên bản 4.2, chúng tôi chuyển sự chú ý sang TimescaleDB. Đây là phần mở rộng cho PostgreSQL với giao diện gốc. Tiện ích mở rộng hoạt động hiệu quả với dữ liệu chuỗi thời gian mà không làm mất đi lợi ích của cơ sở dữ liệu quan hệ. TimescaleDB cũng tự động phân vùng.
TimescaleDB có một khái niệm quá khích (hypertable) mà bạn tạo ra. Nó chứa miếng, mảnh nhỏ - phân vùng. Chunk là các đoạn siêu khả năng được quản lý tự động và không ảnh hưởng đến các đoạn khác. Mỗi đoạn có phạm vi thời gian riêng.
TimescaleDB so với PostgreSQL
TimescaleDB hoạt động thực sự hiệu quả. Các nhà sản xuất tiện ích mở rộng tuyên bố rằng họ sử dụng thuật toán xử lý truy vấn chính xác hơn, đặc biệt là inserts . Khi kích thước chèn tập dữ liệu tăng lên, thuật toán sẽ duy trì hiệu suất không đổi.
Sau 200 triệu hàng, PostgreSQL thường bắt đầu giảm đáng kể và giảm hiệu suất xuống 0. TimescaleDB cho phép bạn chèn các “chèn” một cách hiệu quả cho bất kỳ lượng dữ liệu nào.
Cài đặt
Việc cài đặt TimescaleDB khá dễ dàng đối với mọi gói. TRONG mọi thứ đều được mô tả chi tiết - nó phụ thuộc vào các gói PostgreSQL chính thức. TimescaleDB cũng có thể được xây dựng và biên dịch thủ công.
Đối với cơ sở dữ liệu Zabbix, chúng tôi chỉ cần kích hoạt tiện ích mở rộng:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Bạn kích hoạt extension và tạo nó cho cơ sở dữ liệu Zabbix. Bước cuối cùng là tạo một siêu bảng.
Di chuyển các bảng lịch sử sang TimescaleDB
Có một chức năng đặc biệt cho việc này create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
Hàm này có ba tham số. Đầu tiên - bảng trong cơ sở dữ liệu, mà bạn cần tạo một siêu bảng. Thứ hai - trường, theo đó bạn cần tạo chunk_time_interval - khoảng thời gian của các khối phân vùng sẽ được sử dụng. Trong trường hợp của tôi, khoảng thời gian là một ngày - 86.
Tham số thứ ba - migrate_data. Nếu bạn đặt true, thì tất cả dữ liệu hiện tại sẽ được chuyển sang các khối được tạo trước. Tôi đã tự mình sử dụng nó migrate_data. Tôi có khoảng 1 TB, mất hơn một giờ. Thậm chí, trong một số trường hợp, trong quá trình thử nghiệm, tôi đã xóa dữ liệu lịch sử của các loại ký tự không cần thiết để lưu trữ để không chuyển chúng.
Bước cuối cùng - UPDATE: trong db_extension đặt timescaledbđể cơ sở dữ liệu hiểu rằng phần mở rộng này tồn tại. Zabbix kích hoạt nó và sử dụng chính xác cú pháp cũng như các truy vấn tới cơ sở dữ liệu - những tính năng cần thiết cho TimescaleDB.
Cấu hình phần cứng
Tôi đã sử dụng hai máy chủ. Đầu tiên - máy VMware. Nó khá nhỏ: 20 bộ xử lý Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, RAM 16 GB và ổ SSD 200 GB.
Tôi đã cài đặt PostgreSQL 10.8 trên đó với hệ điều hành Debian 10.8-1.pgdg90+1 và hệ thống tệp xfs. Tôi đã định cấu hình mọi thứ ở mức tối thiểu để sử dụng cơ sở dữ liệu cụ thể này, trừ những gì Zabbix sẽ sử dụng.
Trên cùng một máy có máy chủ Zabbix, PostgreSQL và đại lý tải. Tôi có 50 đại lý đang hoạt động đang sử dụng LoadableModuleđể nhanh chóng tạo ra các kết quả khác nhau: số, chuỗi. Tôi đã lấp đầy cơ sở dữ liệu với rất nhiều dữ liệu.
Ban đầu cấu hình chứa 5 mặt hàng dữ liệu trên mỗi máy chủ. Hầu hết mọi phần tử đều chứa một trình kích hoạt để làm cho nó giống với cài đặt thực. Trong một số trường hợp có nhiều hơn một kích hoạt. Đối với một nút mạng có 3-000 kích hoạt.
Khoảng thời gian cập nhật mục dữ liệu - 4-7 giây. Tôi đã tự điều chỉnh tải bằng cách không chỉ sử dụng 50 tác nhân mà còn bổ sung thêm. Ngoài ra, bằng cách sử dụng các phần tử dữ liệu, tôi đã điều chỉnh tải một cách linh hoạt và giảm khoảng thời gian cập nhật xuống còn 4 giây.
PostgreSQL. 35 nvps
Lần chạy đầu tiên của tôi trên phần cứng này là trên PostgreSQL thuần túy - 35 nghìn giá trị mỗi giây. Như bạn có thể thấy, việc chèn dữ liệu chỉ mất một phần giây - mọi thứ đều tốt và nhanh chóng. Điều duy nhất là ổ SSD 200 GB đầy nhanh chóng.
Đây là bảng điều khiển hiệu suất máy chủ Zabbix tiêu chuẩn.
Biểu đồ màu xanh đầu tiên là số lượng giá trị trên giây. Biểu đồ thứ hai bên phải là quá trình tải của quá trình xây dựng. Thứ ba là tải các quy trình xây dựng nội bộ: bộ đồng bộ hóa lịch sử và Quản gia, đã chạy ở đây khá lâu.
Biểu đồ thứ tư hiển thị mức sử dụng HistoryCache. Đây là một loại vùng đệm trước khi chèn vào cơ sở dữ liệu. Biểu đồ thứ năm màu xanh lục hiển thị mức sử dụng ValueCache, tức là có bao nhiêu lần truy cập ValueCache cho trình kích hoạt - đây là vài nghìn giá trị mỗi giây.
PostgreSQL. 50 nvps
Sau đó, tôi tăng tải lên 50 nghìn giá trị mỗi giây trên cùng một phần cứng.
Khi tải từ Housekeeper, việc chèn 10 nghìn giá trị mất 2-3 giây.
Quản gia đã bắt đầu can thiệp vào công việc.
Biểu đồ thứ ba cho thấy, nhìn chung, tải trên bộ bẫy và bộ đồng bộ lịch sử vẫn ở mức 60%. Trong biểu đồ thứ tư, HistoryCache đã bắt đầu được lấp đầy khá tích cực trong quá trình vận hành Housekeeper. Nó đã đầy 20%, tức là khoảng 0,5 GB.
PostgreSQL. 80 nvps
Sau đó tôi tăng tải lên 80 nghìn giá trị mỗi giây. Đây là khoảng 400 nghìn phần tử dữ liệu và 280 nghìn trình kích hoạt.
Chi phí tải của ba mươi bộ đồng bộ lịch sử đã khá cao.
Tôi cũng tăng các thông số khác nhau: bộ đồng bộ hóa lịch sử, bộ nhớ đệm.
Trên phần cứng của tôi, việc tải bộ đồng bộ hóa lịch sử đã tăng lên mức tối đa. HistoryCache nhanh chóng chứa đầy dữ liệu - dữ liệu để xử lý đã tích lũy trong bộ đệm.
Trong suốt thời gian này, tôi đã quan sát cách sử dụng bộ xử lý, RAM và các thông số hệ thống khác và nhận thấy rằng mức sử dụng ổ đĩa ở mức tối đa.
Tôi đã đạt được công dụng khả năng đĩa tối đa trên phần cứng này và trên máy ảo này. Với cường độ như vậy, PostgreSQL bắt đầu xóa dữ liệu khá tích cực và đĩa không còn thời gian để ghi và đọc nữa.
Máy chủ thứ hai
Tôi lấy một máy chủ khác đã có 48 bộ xử lý và 128 GB RAM. Tôi đã điều chỉnh nó - đặt nó thành bộ đồng bộ hóa lịch sử 60 và đạt được hiệu suất chấp nhận được.
Trên thực tế, đây đã là giới hạn về năng suất mà cần phải làm gì đó.
Thang thời gianDB. 80 nvps
Nhiệm vụ chính của tôi là kiểm tra khả năng của TimescaleDB trước tải Zabbix. 80 nghìn giá trị mỗi giây là rất nhiều, tần suất thu thập số liệu (tất nhiên là ngoại trừ Yandex) và một “thiết lập” khá lớn.
Có một điểm sụt giảm trong mọi biểu đồ - đây chính xác là quá trình di chuyển dữ liệu. Sau sự cố ở máy chủ Zabbix, cấu hình tải của trình đồng bộ hóa lịch sử đã thay đổi rất nhiều - nó đã giảm ba lần.
TimescaleDB cho phép bạn chèn dữ liệu nhanh hơn gần 3 lần và sử dụng ít HistoryCache hơn.
Theo đó, bạn sẽ nhận được dữ liệu một cách kịp thời.
Thang thời gianDB. 120 nvps
Sau đó, tôi tăng số lượng phần tử dữ liệu lên 500 nghìn, nhiệm vụ chính là kiểm tra khả năng của TimescaleDB - tôi nhận được giá trị tính toán là 125 nghìn giá trị mỗi giây.
Đây là một “thiết lập” hoạt động có thể hoạt động trong thời gian dài. Nhưng vì đĩa của tôi chỉ có 1,5 TB nên tôi sẽ lấp đầy nó sau vài ngày.
Điều quan trọng nhất là đồng thời các phân vùng TimescaleDB mới được tạo.
Điều này là hoàn toàn không đáng chú ý đối với hiệu suất. Ví dụ, khi các phân vùng được tạo trong MySQL, mọi thứ sẽ khác. Điều này thường xảy ra vào ban đêm vì nó chặn thao tác chèn chung, làm việc với các bảng và có thể khiến dịch vụ xuống cấp. Đây không phải là trường hợp của TimescaleDB.
Để làm ví dụ, tôi sẽ hiển thị một biểu đồ từ nhiều biểu đồ trong cộng đồng. Trong hình, TimescaleDB được bật, nhờ đó tải sử dụng io.weight trên bộ xử lý đã giảm xuống. Việc sử dụng các yếu tố quy trình nội bộ cũng giảm. Hơn nữa, đây là một máy ảo thông thường trên các đĩa pancake thông thường chứ không phải ổ SSD.
Những phát hiện
TimescaleDB là một giải pháp tốt cho việc "thiết lập" nhỏ, ảnh hưởng đến hiệu suất đĩa. Nó sẽ cho phép bạn tiếp tục hoạt động tốt cho đến khi cơ sở dữ liệu được di chuyển sang phần cứng nhanh nhất có thể.
TimescaleDB dễ cấu hình, tăng hiệu suất, hoạt động tốt với Zabbix và có lợi thế hơn PostgreSQL.
Nếu bạn sử dụng PostgreSQL và không có ý định thay đổi nó, tôi khuyên bạn nên sử dụng PostgreSQL với tiện ích mở rộng TimescaleDB kết hợp với Zabbix. Giải pháp này hoạt động hiệu quả ở mức "thiết lập" trung bình.
Khi chúng tôi nói “hiệu suất cao” có nghĩa là chúng tôi . Bạn sẽ không phải chờ đợi lâu để tìm hiểu về các công nghệ và phương pháp thực hành giúp dịch vụ phục vụ hàng triệu người dùng. Danh sách cho ngày 7 và 8 tháng XNUMX, chúng tôi đã tổng hợp rồi, nhưng ở đây có thể đề xuất thêm.
Đăng ký của chúng tôi и , trong đó chúng tôi tiết lộ các tính năng của hội nghị sắp tới và tìm hiểu cách tận dụng tối đa hội nghị đó.
Nguồn: www.habr.com