Mở rộng quy mô PostgreSQL: Cách chúng tôi thuần hóa 10 tỷ hồ sơ hàng ngày và hơn 350 TB dữ liệu

Đầu năm nay, chúng tôi đã bắt tay vào dự án lớn nhất của công ty mình nỗ lực dogfood bao giờ. Để xây dựng Thông tin chi tiết , một công cụ cho phép người dùng phân tích hiệu suất truy vấn của họ trong nền tảng Timescale, chúng tôi đã tìm cách thu thập số liệu thống kê truy vấn trên tất cả cơ sở dữ liệu của khách hàng, bao gồm thời gian, CPU, mức sử dụng bộ nhớ và I/O ổ đĩa liên quan đến từng truy vấn. Chúng tôi cần một cơ sở dữ liệu có thể xử lý một lượng lớn dữ liệu, có khả năng phân tích mạnh mẽ (đặc biệt là phân tích theo thời gian) và sẽ không trở thành gánh nặng vận hành.

Đương nhiên, chúng tôi đã chọn Timescale, nền tảng đám mây trưởng thành của chúng tôi với cốt lõi là TimescaleDB. Chúng tôi đã quen làm việc với PostgreSQL và chúng tôi đã xây dựng TimescaleDB để làm cho PostgreSQL nhanh hơn và có khả năng mở rộng cao hơn—còn gì tốt hơn việc sống theo ví dụ của chính chúng tôi?

Cách dễ nhất để mô tả thử nghiệm dogfood này là sử dụng những con số giúp định lượng quy mô của nó. Để xây dựng Thông tin chi tiết, chúng tôi cần thu thập thông tin truy vấn trên nhóm cơ sở dữ liệu sản xuất đang chạy liên tục của mình. Chúng tôi đã nhanh chóng thu thập hơn 1 nghìn tỷ hồ sơ về các truy vấn riêng lẻ (đã được dọn dẹp) trên nền tảng.

Hiện tại, Insights đang được đưa vào sản xuất nên chúng tôi đang tiếp nhận hơn 10 tỷ bản ghi mới mỗi ngày . Tập dữ liệu được cung cấp bởi một dịch vụ Timescale duy nhất tăng khoảng 3 TB mỗi ngày và hiện có tổng dung lượng trên 350 TB , đồng thời dịch vụ cơ sở dữ liệu tương tự cung cấp trang tổng quan thời gian thực cho tất cả khách hàng của chúng tôi.

Bài đăng blog này cung cấp thông tin hậu trường về quá trình xây dựng Thông tin chi tiết. Hoạt động ở quy mô này có nghĩa là phải vượt qua các giới hạn của một dịch vụ Timescale duy nhất và mở rộng không chỉ PostgreSQL mà còn cả sự đồng cảm với nhà phát triển của chúng tôi. Chúng tôi nhận thấy Timescale còn hoàn thành tốt nhiệm vụ nhưng cũng có những lĩnh vực chúng tôi muốn cải thiện!

Mở rộng quy mô PostgreSQL để phân tích các truy vấn trên toàn bộ nhóm của chúng tôi

Chúng tôi vừa ra mắt sản phẩm cuối cùng trong nỗ lực dogfood của mình, Insights, trên nền tảng Timescale. Công cụ quan sát cơ sở dữ liệu này cho phép người dùng hiểu rõ hơn về cách thức hoạt động của các truy vấn của họ. Thông tin chi tiết tương quan với nhiều số liệu khác nhau – bao gồm độ trễ truy vấn, CPU, bộ nhớ và I/O – với các truy vấn thực thi đồng thời, giúp người dùng tìm thấy các truy vấn có hiệu suất thấp có thể gây ra sự cố. Sau khi bạn xác định được các truy vấn có vấn đề, Thông tin chi tiết sẽ cung cấp cho bạn cái nhìn chi tiết hơn về các khía cạnh như bộ đệm dùng chung và tỷ lệ truy cập bộ đệm trong một khoảng thời gian nhất định để giúp bạn tìm ra vấn đề.

Để thực hiện Thông tin chi tiết, chúng tôi đã phải đội mũ quản trị viên cơ sở dữ liệu của mình 🤠 và giải quyết một số thách thức kỹ thuật để mở rộng quy mô PostgreSQL lên nhiều terabyte dữ liệu. Chúng tôi muốn sử dụng dịch vụ Timescale làm cơ sở dữ liệu trung tâm, được lưu trữ trên nền tảng của chúng tôi mà không có cơ sở hạ tầng “đặc biệt”. Điều này có nghĩa như sau:

• Chúng tôi phải xây dựng một hệ thống có khả năng nhập hàng tỷ bản ghi mỗi ngày vào một dịch vụ Timescale duy nhất. Timescale có thể xử lý tỷ lệ nhập cao và thực hiện điều này thường xuyên cho khách hàng của chúng tôi, nhưng mức quy mô này theo tải truy vấn sản xuất luôn khiến nhiều người phải thắc mắc.

  
  

• Khách hàng của chúng tôi phải có khả năng truy vấn cơ sở dữ liệu này một cách linh hoạt để cung cấp tất cả các phân tích mà Insights cung cấp và chúng tôi không muốn bắt họ phải đợi vài phút để nhận được phản hồi!

  
  

• Chúng tôi cần lưu trữ hàng trăm TB trong một dịch vụ Timescale vì mỗi ngày chúng tôi thêm một số TB. Dữ liệu cũ hơn (tức là cũ hơn một vài tuần) cần có thể truy cập được nhưng không nhất thiết phải truy vấn nhanh.

Cách chúng tôi xây dựng nó: Hỗ trợ phân tích thời gian thực với cơ sở dữ liệu (khổng lồ)

Thu thập và viết nhiều dữ liệu

Từ phía thu thập dữ liệu , chúng tôi đã tận dụng kiến trúc của nền tảng Timescale. Timescale chạy trên Kubernetes (k8s) và chúng tôi có một số cụm k8 chạy ở các khu vực địa lý khác nhau. Các cụm đó có các nút chứa một hoặc nhiều dịch vụ cơ sở dữ liệu khách hàng. Để thu thập các lần thực thi truy vấn cho tất cả các cơ sở dữ liệu đó, chúng tôi sẽ chuyển từ cơ sở dữ liệu đó lên cấp khu vực và sau đó có một người viết khu vực lưu trữ các lô bản ghi trong dịch vụ cơ sở dữ liệu Timescale hỗ trợ Thông tin chi tiết.

Xin thứ lỗi cho sự vội vàng tránh một số chi tiết đẫm máu ở mức độ thấp, nhưng xét theo nghĩa rộng, đây là cách mọi thứ hoạt động: mỗi cơ sở dữ liệu chạy trên toàn bộ nhóm đều được thiết kế để tạo một bản ghi (được làm sạch để đảm bảo quyền riêng tư và bảo mật) sau mỗi truy vấn, bao gồm cả truy vấn và số liệu thống kê mà chúng tôi quan tâm.

Những bản ghi đó được thu thập ở cấp nút, được gắn thẻ để liên kết chúng với dịch vụ cơ sở dữ liệu mà chúng đến từ đó và được phân nhóm để gửi đến người viết trong khu vực. Dịch vụ nhà văn khu vực được nhân rộng khi cần thiết để xử lý tải ở từng khu vực. Mỗi người viết thu thập các lô từ các nút trong mỗi cụm và tạo ra các lô lớn hơn nữa.

Sau đó, các lô lớn đó được ghi bằng cách sử dụng `COPY` vào một bảng tạm thời trước tiên (không ghi nhật ký ghi trước = nhanh). Các mục trong bảng tạm thời đó sau đó được sử dụng để cập nhật các bảng cần thiết (xem bên dưới). Bảng tạm thời cho phép chúng ta sử dụng `COPY` mà không phải lo lắng về các bản sao, được xử lý bằng các thao tác tiếp theo khi trộn các bản ghi từ bảng tạm thời.

Tóm tắt lại:

• Chúng tôi có các cụm k8 ở một số khu vực địa lý. Bên trong các vùng đó là các nút chạy một hoặc nhiều cơ sở dữ liệu khách hàng.
• Số liệu thống kê truy vấn đã được làm sạch từ cơ sở dữ liệu khách hàng được thu thập và phân nhóm (trong khu vực).
• Khi có đủ số lượng sự kiện, chúng sẽ được gửi đến dịch vụ cơ sở dữ liệu Timescale tập trung của chúng tôi.

Hãy phóng to cơ sở dữ liệu đang hỗ trợ Thông tin chi tiết. Chúng tôi đang chạy Thông tin chi tiết trong một dịch vụ Thang thời gian “có sẵn” với bản sao có tính sẵn sàng cao , cũng được sử dụng để chia tỷ lệ đọc (sẽ nói thêm về điều đó sau). Khi nói “có sẵn”, chúng tôi muốn nói rằng chúng tôi đang sử dụng tất cả các tính năng tương tự có sẵn (hoặc sắp có sẵn 😉) cho khách hàng của mình. Không có ma thuật đen đặc biệt nào vì chúng tôi cũng kiểm soát cơ sở hạ tầng.

Thông tin chi tiết hỗ trợ cơ sở dữ liệu có khá nhiều phần nhưng chúng tôi sẽ cố gắng làm nổi bật những phần quan trọng nhất.

Đầu tiên, chúng tôi có hai bảng PostgreSQL thông thường đóng vai trò là “bảng tham chiếu”. Các bảng này chứa siêu dữ liệu cơ sở dữ liệu thông tin và siêu dữ liệu chuỗi truy vấn. Đây là các lược đồ (giả) của họ:

Siêu dữ liệu cơ sở dữ liệu

 Table "insights.cloud_db" Column | Type | Collation | Nullable | Default ---------------+--------------------------+-----------+----------+-------------------------------------- id | bigint | | not null | nextval('cloud_db_id_seq'::regclass) service_id | text | | not null | project_id | text | | not null | created | timestamp with time zone | | not null | now() Indexes: "cloud_db_pkey" PRIMARY KEY, btree (id) "cloud_db_project_id_service_id_key" UNIQUE CONSTRAINT, btree (project_id, service_id)

Siêu dữ liệu truy vấn

 Table "insights.queries" Column | Type | Collation | Nullable | Default ---------------+--------------------------+-----------+----------+-------------------------------------- hash | text | | not null | normalized_query | text | | not null | created | timestamp with time zone | | not null | now() Indexes: "queries_pkey" PRIMARY KEY, btree (hash)

Bất cứ khi nào cơ sở dữ liệu mới bắt đầu có các truy vấn chạy trên đó, cơ sở dữ liệu đó sẽ được thêm vào `insights.cloud_db`. Bất cứ khi nào một truy vấn chuẩn hóa mới được chạy, truy vấn đó sẽ được thêm vào `insights.queries`.

(Truy vấn chuẩn hóa là gì? Đây là truy vấn trong đó tất cả các hằng số đã được thay thế bằng phần giữ chỗ: $1 cho hằng số đầu tiên, $2 cho hằng số thứ hai, v.v., vì vậy chúng ta chỉ nhìn thấy “hình dạng” của truy vấn chứ không phải các giá trị của nó .)

Cho đến thời điểm này, chúng tôi chỉ sử dụng Postgres thông thường không có bí mật Timescale. Nhưng các đối tượng quan trọng khác trong cơ sở dữ liệu là duy nhất của TimescaleDB, giúp mở rộng PostgreSQL lên một cấp độ khác. Đây là nơi điều kỳ diệu xảy ra: siêu bảng và tập hợp liên tục.

• Hypertables là các bảng được phân vùng tự động của Timescale. Chúng tự động phân vùng dữ liệu theo thứ nguyên trong khi dữ liệu được nhập vào, giúp việc mở rộng quy mô bảng PostgreSQL lên quy mô lớn dễ dàng hơn nhiều. Hypertables là các khối xây dựng của Timescale. Chúng tôi đang lưu trữ các số liệu thống kê truy vấn của mình trong một siêu bảng khổng lồ, như chúng ta sẽ thấy sau.

  
  

• Tổng hợp liên tục là phiên bản cải tiến của các chế độ xem cụ thể hóa PostgreSQL của Timescale, cho phép hiện thực hóa gia tăng và tự động , điều này tỏ ra rất hữu ích khi xây dựng Thông tin chi tiết.

Hãy trình bày cách chúng tôi sử dụng các tính năng này để kích hoạt các truy vấn phân tích nhanh về phía người dùng.

Hỗ trợ phân tích thời gian thực (nhanh)

Như chúng tôi đã nói, chúng tôi sử dụng một siêu bảng lớn để lưu trữ thông tin về mọi lần thực hiện truy vấn. Siêu bảng này là bảng chính của chúng tôi, nơi chứa các số liệu thô đã được làm sạch. Nó trông giống như sau và được định cấu hình để sử dụng cột dấu thời gian ( created ) để tự động phân vùng dữ liệu khi dữ liệu được nhập.

 Table "insights.records" Column | Type | Collation | Nullable | Default -----------------------------+--------------------------+-----------+----------+--------- cloud_db_id | bigint | | not null | query_hash | text | | | created | timestamp with time zone | | not null | total_time | bigint | | | rows | bigint | | | ...

Bây giờ, chúng tôi phải cho phép truy vấn nhanh từ phía người dùng—nhưng bảng này rất lớn. Để tăng tốc mọi thứ, chúng tôi chủ yếu dựa vào tổng hợp liên tục (sử dụng tập hợp liên tục có thứ bậc , chinh xac).

Việc tổng hợp liên tục rất có ý nghĩa đối với một sản phẩm cung cấp các phân tích theo thời gian thực, hướng tới người dùng như Thông tin chi tiết. Để cung cấp thông tin hữu ích cho người dùng, chúng tôi cần tổng hợp số liệu: chúng tôi không hiển thị cho người dùng nhật ký của mọi truy vấn họ đã chạy với số liệu thống kê bên cạnh—một số cơ sở dữ liệu đang thực hiện hàng nghìn truy vấn mỗi giây, vì vậy sẽ là một cơn ác mộng khi tìm thấy bất cứ điều gì hữu ích. Thay vào đó, chúng tôi đang phục vụ người dùng tổng hợp.

Vì vậy, chúng tôi cũng có thể tận dụng thực tế là chúng tôi không hiển thị các bản ghi riêng lẻ thô cho người dùng và giữ nguyên kết quả được vật chất hóa để có phản hồi nhanh. Đối với khách hàng, điều này có nghĩa là phải đánh đổi một chút về độ chính xác khi sử dụng Thông tin chi tiết (tức là họ không thể nhận được khoảng thời gian chính xác đến từng giây), nhưng đó là một mức giá rất hợp lý phải trả.

Chúng tôi có thể đã sử dụng các chế độ xem được cụ thể hóa của PostgreSQL, nhưng các chế độ tổng hợp liên tục của Timescale có một số lợi thế đặc biệt hữu ích cho chúng tôi. Chúng tôi làm mới các chế độ xem rất nhiều và các tập hợp tổng hợp liên tục có các chính sách tích hợp để làm mới tự động và chúng làm mới tăng dần.

Chúng tôi làm mới các chế độ xem cứ sau 5 phút, do đó, thay vì tạo lại toàn bộ thông tin được cụ thể hóa cứ sau 5 phút, các tập hợp tổng hợp liên tục sẽ cập nhật dần dần chế độ xem bằng cách theo dõi các thay đổi trong bảng gốc. Ở quy mô mà chúng tôi đang vận hành, chúng tôi không đủ khả năng để quét siêu bảng chính của mình từ trên xuống dưới cứ sau 5 phút, vì vậy chức năng tổng hợp liên tục này là một “mở khóa” cơ bản đối với chúng tôi.

Trong các hoạt động tổng hợp liên tục hỗ trợ Thông tin chi tiết đằng sau hậu trường này, chúng tôi cũng tổng hợp hầu hết các số liệu thống kê thú vị thành một UDDSketch , là một phần trong bộ sưu tập của chúng tôi siêu chức năng trong Thang thời gian. UDDSketch chuyên thu thập các thước đo thống kê gần đúng từ dữ liệu mà nó xử lý. Điều này cho phép chúng tôi trình bày các số liệu cần thiết như trung vị, phân vị thứ 95 (hoặc P95), v.v. cho các số liệu như độ trễ hoặc số hàng.

Tuy nhiên, tại một thời điểm nhất định, cơ sở dữ liệu bắt đầu thực hiện rất nhiều công việc để chèn tất cả các bản ghi thô này và sau đó cụ thể hóa chúng để phục vụ. Chúng tôi đã gặp phải một số hạn chế về số lượng chúng tôi có thể ăn và theo kịp.

Để tăng thêm tốc độ nhập của chúng tôi đến mức cần thiết, chúng tôi đã chuyển quá trình tạo UDDSketch từ cơ sở dữ liệu sang những người viết trong khu vực. Hiện tại, chúng tôi vẫn lưu trữ một số lượng bản ghi dưới dạng bản ghi "thô", nhưng chúng tôi cũng đẩy phần còn lại vào các bản phác thảo được tạo trước mà chúng tôi lưu trữ trong cơ sở dữ liệu:

 Table "insights.sketches" Column | Type | Collation | Nullable | Default -----------------------------+--------------------------+-----------+----------+--------- cloud_db_id | bigint | | not null | query_hash | text | | | created | timestamp with time zone | | not null | total_time_dist | uddsketch | | | rows_dist | uddsketch | | | ...

Phần hay nhất của UDDSketchs là rất dễ dàng liên tục “cuộn” các bản phác thảo để hỗ trợ phạm vi thời gian lớn hơn. Bằng cách sử dụng bản tổng hợp như vậy, các bản phác thảo bao gồm phạm vi thời gian hẹp hơn có thể được tổng hợp thành một bản phác thảo bao gồm phạm vi thời gian rộng, cả khi xây dựng tổng hợp liên tục theo cấp bậc và tại thời điểm truy vấn.

Một công cụ khác mà chúng tôi tận dụng để đảm bảo cả truy vấn và nhập nhanh đều là bản sao đọc. Trong trường hợp của chúng tôi, việc sử dụng bản sao là điều tối quan trọng để có được cả tính sẵn sàng và hiệu suất cao, vì Thông tin chi tiết cung cấp một tính năng chính hướng tới khách hàng cho nền tảng Timescale.

Phiên bản cơ sở dữ liệu chính của chúng tôi khá bận rộn với công việc hàng loạt, ghi dữ liệu, cụ thể hóa các tập hợp liên tục, chạy nén, v.v. (Tìm hiểu thêm về tính năng nén sau một phút.) Để giảm bớt tải, chúng tôi cho phép khách hàng dịch vụ sao chép đọc các yêu cầu từ bảng điều khiển Thông tin chi tiết.

Lưu trữ hàng trăm TB trong một phiên bản Timescale duy nhất

Cuối cùng, chúng tôi cần bố trí hàng trăm TB vào một dịch vụ Timescale một cách thoải mái. Cơ sở dữ liệu Thông tin chi tiết đang mở rộng nhanh chóng: khi chúng tôi bắt đầu, nó có dung lượng ở mức 100 TB và hiện đã lên tới hơn 350 TB (và đang tiếp tục tăng).

Để lưu trữ lượng dữ liệu đó một cách hiệu quả, chúng tôi đã kích hoạt Nén cột của Timescale trong siêu bảng của chúng tôi và trong tất cả các tập hợp liên tục của chúng tôi (vâng, bạn cũng có thể nén các tập hợp liên tục vì về cơ bản chúng là các siêu bảng con!). Chúng tôi cũng đã tăng tốc độ nén của mình—dù sao thì nhóm cũng biết khá nhiều điều về việc tối ưu hóa khả năng nén.

Chúng tôi đang chứng kiến tốc độ nén lên tới 20 lần trên siêu bảng chính của chúng tôi.

Một thắng lợi lớn khác khi quản lý một siêu bảng rất lớn là khả năng biến đổi lược đồ của dữ liệu nén. Chúng tôi đã mô tả lược đồ gần đúng của mình trong phần trước, nhưng như bạn có thể tưởng tượng, chúng tôi thường xuyên thay đổi lược đồ này để thêm nhiều số liệu thống kê, v.v.—thật hữu ích khi có thể thực hiện việc này trực tiếp trong siêu bảng nén.

Chúng tôi cũng là những người sử dụng nhiều cách phân tầng dữ liệu của Timescale. Tính năng này đã được đưa vào quyền truy cập sớm vào đầu năm nay (hãy đợi tin tức GA sớm 🔥) và cho phép chúng tôi giữ hàng trăm TB có thể truy cập được thông qua cơ sở dữ liệu Timescale của chúng tôi. Phân tầng dữ liệu cũng tỏ ra rất hiệu quả: chúng tôi cũng thấy tốc độ nén đáng kinh ngạc ở đây, với 130 TB giảm xuống còn 5 TB có hiệu quả tài nguyên cao.

Mở rộng cơ sở dữ liệu PostgreSQL 350 TB+ bằng cách sử dụng Timescale: Bài học kinh nghiệm

Quá trình xây dựng Thông tin chi tiết đã cho chúng tôi thấy sản phẩm của chúng tôi thực sự có thể đi được bao xa, nhưng điều tuyệt vời nhất là đi được vài dặm bằng đôi giày của khách hàng. Chúng tôi đã học được rất nhiều điều về trải nghiệm của người dùng khi mở rộng quy mô PostgreSQL bằng Timescale và chúng tôi đã thêm một số thứ vào danh sách việc cần làm của mình với tư cách là các kỹ sư đằng sau sản phẩm.

Chúng ta hãy điểm qua tất cả: điều tốt và điều tương tự.

Điểm nổi bật của thang thời gian

• Xin thứ lỗi cho sự thiếu khiêm tốn của chúng tôi, nhưng đôi khi chúng tôi cảm thấy khá tự hào về sản phẩm của mình. Việc nhập hàng chục tỷ bản ghi hàng ngày vào một cơ sở dữ liệu PostgreSQL với hàng trăm TB không có gì đáng chê trách . Chúng tôi đã dành vài tuần để điều chỉnh cơ sở dữ liệu khi nó bắt đầu tăng tốc, nhưng bây giờ nó chỉ hoạt động mà không cần trông trẻ hoặc giám sát liên tục. (Lưu ý rằng điều này khác với việc không được giám sát, nó chắc chắn được giám sát!)

  
  

• Của chúng tôi nhà thám hiểm Chế độ xem đóng vai trò quan trọng trong quá trình này, cung cấp thông tin chuyên sâu có giá trị và cho phép dễ dàng thay đổi cấu hình để tối ưu hóa hiệu suất, chẳng hạn như khi tối ưu hóa kích thước đoạn (phân vùng).

  
  

• Tính năng nén hoạt động rất tốt đối với chúng tôi. Như chúng tôi đã chia sẻ ở phần trước, chúng tôi đã đạt được tốc độ nén ấn tượng (20x!) bằng cách sử dụng tùy chọn `phân đoạn` đơn giản. Đối với chúng tôi, trải nghiệm thiết lập và điều chỉnh chính sách không khó—mặc dù, tất nhiên, chúng tôi đã xây dựng tính năng này…có thể nói rằng chúng tôi có một chút lợi thế. 🙂 Ngoài ra, khả năng thêm liền mạch các cột mới vào dữ liệu nén đã nâng cao hơn nữa tính linh hoạt và khả năng thích ứng của cơ sở dữ liệu của chúng tôi. Chúng tôi đã sử dụng khả năng này mà không gặp bất kỳ trở ngại nào.

  
  

• Việc tổng hợp liên tục đã đơn giản hóa logic trong việc xây dựng các khoảng thời gian khác nhau, hợp lý hóa việc phân tích và xử lý dữ liệu. Chúng tôi đã sử dụng rất nhiều tập hợp liên tục có thứ bậc.

  
  

• Các thuật toán gần đúng có trong siêu hàm của Timecale đã đơn giản hóa việc triển khai của chúng tôi và mở rộng đáng kể phân tích của chúng tôi. Khả năng dễ dàng tổng hợp các bản phác thảo cũng là chìa khóa để hỗ trợ hiệu quả các phạm vi thời gian và mức độ chi tiết của nhóm thời gian khác nhau trong bảng thông tin Thông tin chi tiết dành cho khách hàng của chúng tôi.

  
  

• Bộ lưu trữ ấm “vô hạn” mà cơ sở dữ liệu Timescale có thể tùy ý sử dụng thông qua phân tầng dữ liệu là rất quan trọng để mở rộng quy mô lên 100 TB, với nhiều khoảng trống để phát triển. __ Chính sách phân cấp dữ liệu hiện tại của chúng tôi __lưu giữ ba tuần hồ sơ trong kho lưu trữ nóng.

  
  

Cuối cùng, chúng tôi đã sử dụng khả năng tạo công việc tùy chỉnh để nâng cao khả năng quan sát (như theo dõi lịch sử công việc) và triển khai các chiến lược làm mới thử nghiệm.

Cơ hội cải tiến (chúng tôi đã lưu ý)

Sau khi kể cho bạn nghe tất cả những điều tuyệt vời, đã đến lúc thừa nhận những điều không mấy tuyệt vời. Không có gì là hoàn hảo, kể cả Timescale. Chúng tôi đã phải đối mặt với một số thách thức trong khi triển khai quy trình của mình và chúng tôi không coi đây là những lời phàn nàn:

Khả năng quan sát cơ sở dữ liệu có thể được cải thiện trong nền tảng Timescale, đặc biệt là về các công việc và hiệu suất vật chất hóa tổng hợp liên tục.

TimescaleDB chủ yếu cung cấp các chế độ xem dựa trên ảnh chụp nhanh, khiến việc hiểu hiệu suất và xu hướng theo thời gian trở nên khó khăn. Ví dụ: không có sẵn bảng “lịch sử công việc” sẵn có. Ban đầu, chúng tôi nhận thấy rằng quá trình hiện thực hóa dần dần các tập hợp tổng hợp liên tục của chúng tôi dường như ngày càng mất nhiều thời gian hơn—cuối cùng dẫn đến việc phát hiện ra lỗi—nhưng chúng tôi không có cách nào để xác nhận hoặc định lượng phạm vi.

Như chúng tôi đã lưu ý trước đây, khả năng xác định các công việc tùy chỉnh và chạy chúng trong khung công việc của Timescale đã cho phép chúng tôi tạo ra một phiên bản “đủ tốt” của công việc này. Chúng tôi sẽ liên tục truy vấn các chế độ xem mà chúng tôi muốn theo dõi theo thời gian và chèn bất kỳ thay đổi nào vào siêu bảng. Tính năng này hiện có hiệu quả đối với Thông tin chi tiết, nhưng chúng tôi cũng đang nỗ lực biến một số tính năng này thành các chức năng tích hợp vì chúng tôi cho rằng chúng rất quan trọng khi bạn mở rộng Thang thời gian vượt qua thời điểm mọi thứ đều nhanh chóng mọi lúc .

Việc tổng hợp liên tục có thể khó thực hiện đúng khi dữ liệu cơ bản lớn .

Sử dụng tùy chọn `__ KHÔNG CÓ DỮ LIỆU` khi tạo tập hợp liên tục __là một cứu cánh. Điều quan trọng nữa là bạn phải thận trọng khi đưa ra các khoản bù trừ cho chính sách làm mới, để lượng dữ liệu bạn đang làm mới tăng dần không vô tình tăng quá lớn.

Ngay cả khi bạn làm theo lời khuyên này, bạn vẫn có thể kết thúc với một tổng hợp liên tục mất nhiều thời gian để làm mới hơn lượng dữ liệu bạn đang cố gắng hiện thực hóa, ví dụ: mất 30 phút để hiện thực hóa 15 phút dữ liệu. Điều này xảy ra vì đôi khi tác vụ cơ bản tổng hợp liên tục quá lớn để vừa với bộ nhớ và tràn vào đĩa.

Chúng tôi đã gặp phải sự cố này. Sự cố này càng trở nên trầm trọng hơn do một lỗi riêng lẻ mà chúng tôi tìm thấy (hiện đã được sửa) khiến cho các phần bổ sung được đưa vào kế hoạch truy vấn ngay cả khi cuối cùng chúng không đóng góp dữ liệu nào cho quá trình hiện thực hóa. Việc tìm thấy lỗi này thực chất là một trường hợp của "dogfoodception": chúng tôi đã phát hiện ra vấn đề về hiệu suất này khi sử dụng Thông tin chi tiết khi chúng tôi đang xây dựng nó 🤯. Thông tin về thời gian mà chúng tôi thấy trong Thông tin chi tiết cho thấy có điều gì đó không ổn ở đây và chúng tôi đã phát hiện ra vấn đề bằng cách sử dụng EXPLAIN và xem xét các kế hoạch. Vì vậy, chúng tôi có thể nói với bạn rằng nó hoạt động!

Để thực hiện việc cụ thể hóa nhanh hơn, cuối cùng chúng tôi đã tạo một chính sách làm mới tăng dần tùy chỉnh nhằm giới hạn kích thước của các mức tăng cần làm mới. Chúng tôi đang nỗ lực xem liệu đây có phải là điều chúng tôi có thể khái quát hóa trở lại TimescaleDB một cách chính xác hay không.

Thay đổi là khó khăn ở quy mô .

Khi dữ liệu của bạn đã đạt đến kích thước nhất định, một số thao tác DDL (sửa đổi lược đồ) trong TimescaleDB có thể mất nhiều thời gian hơn mức lý tưởng. Chúng tôi đã trải nghiệm điều này theo một số cách.

Ví dụ, việc thêm các chỉ mục mới vào các siêu bảng lớn sẽ trở thành một bài tập về thời gian. Vì TimescaleDB hiện không hỗ trợ sử dụng `CONCURRENTLY` với `CREATE INDEX`, nên tùy chọn tốt nhất tiếp theo là sử dụng phương thức tích hợp sẵn của nó để tạo chỉ mục từng đoạn một. Trong trường hợp của chúng tôi, chúng tôi phải khởi động nó ngay sau khi một đoạn mới được tạo, vì vậy việc khóa trên đoạn "hoạt động" là tối thiểu. Nghĩa là, việc tạo chỉ mục khi một đoạn mới có nghĩa là nó (gần) trống và do đó, có thể hoàn thành nhanh chóng và không chặn các phần chèn mới.

Một cách khác khó thay đổi là khi cập nhật tổng hợp liên tục để thêm số liệu (cột) mới. Tổng hợp liên tục hiện không hỗ trợ `ALTER`. Vì vậy, khi chúng tôi muốn hiển thị một số liệu mới cho người dùng, chúng tôi sẽ tạo một “phiên bản” hoàn toàn mới của tổng hợp liên tục, tức là đối với “foo” tổng hợp liên tục, chúng tôi sẽ có “foo_v2”, “foo_v3”, v.v. Đây là ít hơn lý tưởng nhưng hiện đang làm việc.

Cuối cùng, việc thay đổi cài đặt nén khá khó khăn trên quy mô lớn. Trên thực tế, điều đó thực sự không thể thực hiện được đối với chúng tôi ngay bây giờ vì nó sẽ yêu cầu giải nén tất cả các phần đã nén, thay đổi cài đặt và sau đó nén lại chúng, điều này không khả thi ở quy mô hiện tại của chúng tôi.

Chúng tôi tiếp tục động não với các đồng nghiệp của mình để có được giải pháp khả thi cho tất cả những vấn đề này. Không chỉ cho chúng tôi mà còn cho tất cả người dùng Timescale.

Gói (lại

Đó là khá nhiều thông tin để đưa tất cả vào một bài viết. Nhưng nếu bạn cần một túi đựng chó để sau này thưởng thức cũng không sao đâu!

Building Insights là một trải nghiệm sâu sắc đối với nhóm của chúng tôi. Chúng tôi đã tận mắt chứng kiến chúng tôi có thể đi được bao xa trên Timescale, đưa nó đến những con số quy mô ấn tượng. Những điểm khó khăn mà chúng tôi gặp phải trong quá trình này đã mang lại cho chúng tôi rất nhiều sự đồng cảm với khách hàng—đó chính là nét đẹp của dogfood.

Năm tới, tôi hy vọng sẽ viết một bài đăng blog khác về cách chúng tôi giám sát nhiều cơ sở dữ liệu hơn ở cấp độ khác và cách chúng tôi tiếp tục cải thiện trải nghiệm làm việc với Timescale trên quy mô lớn.

Gặp bạn sau! 👋