HighLoad++ Moscow 2018, Tòa nhà Quốc hội. Ngày 9 tháng 15, 00:XNUMX
Tóm tắt và trình bày:
Yuri Nasretdinov (VKontakte): báo cáo sẽ nói về trải nghiệm triển khai ClickHouse trong công ty của chúng tôi - tại sao chúng tôi cần nó, lượng dữ liệu chúng tôi lưu trữ, cách chúng tôi viết nó, v.v.
Tài liệu bổ sung:
Yury Nasretdinov: - Chào mọi người! Tên tôi là Yury Nasretdinov, như tôi đã được giới thiệu. Tôi làm việc tại VKontakte. Tôi sẽ nói về cách chúng tôi chèn dữ liệu vào ClickHouse từ nhóm máy chủ của mình (hàng chục nghìn).
Nhật ký là gì và tại sao phải thu thập chúng?
Những gì chúng tôi sẽ cho bạn biết: những gì chúng tôi đã làm, tại sao chúng tôi cần “ClickHouse”, tương ứng, tại sao chúng tôi chọn nó, loại hiệu suất mà bạn có thể đạt được mà không cần định cấu hình bất cứ điều gì đặc biệt. Tôi sẽ cho bạn biết thêm về các bảng đệm, về những vấn đề chúng tôi gặp phải với chúng và về các giải pháp mà chúng tôi đã phát triển từ nguồn mở - KittenHouse và Lighthouse.
Tại sao chúng ta lại cần phải làm bất cứ điều gì (mọi thứ luôn tốt trên VKontakte, phải không?). Chúng tôi muốn thu thập nhật ký gỡ lỗi (và có hàng trăm terabyte dữ liệu ở đó), có thể bằng cách nào đó sẽ thuận tiện hơn khi tính toán số liệu thống kê; và chúng tôi có một đội gồm hàng chục nghìn máy chủ để thực hiện tất cả những việc này.
Tại sao chúng tôi quyết định? Chúng tôi có lẽ đã có giải pháp lưu trữ nhật ký. Ở đây – có một “Backend VK” công khai như vậy. Tôi thực sự khuyên bạn nên đăng ký nó.
Nhật ký là gì? Đây là một công cụ trả về các mảng trống. Các công cụ trong VK được người khác gọi là microservice. Và đây là nhãn dán mặt cười (khá nhiều lượt thích). Làm sao vậy? Vâng, hãy lắng nghe thêm!
Những gì có thể được sử dụng để lưu trữ nhật ký? Không thể không nhắc đến Hadup. Sau đó, ví dụ: Rsyslog (lưu trữ các nhật ký này trong tệp). LSD. Ai biết LSD là gì? Không, không phải LSD này. Lưu trữ các tập tin, tương ứng, quá. Chà, ClickHouse là một lựa chọn kỳ lạ.
Clickhouse và đối thủ: yêu cầu và cơ hội
Chúng ta muốn gì? Chúng tôi muốn đảm bảo rằng chúng tôi không phải lo lắng quá nhiều về hoạt động để nó hoạt động tốt, tốt nhất là với cấu hình tối thiểu. Chúng ta muốn viết thật nhiều và viết thật nhanh. Và chúng tôi muốn giữ nó trong nhiều tháng, nhiều năm, tức là trong một thời gian dài. Chúng tôi có thể muốn hiểu một số vấn đề mà họ đã đến gặp chúng tôi và nói, “Có gì đó không ổn ở đây” và đó là chuyện cách đây 3 tháng), và chúng tôi muốn xem điều gì đã xảy ra 3 tháng trước " Nén dữ liệu – rõ ràng tại sao nó lại là một điểm cộng – bởi vì nó làm giảm dung lượng mà nó chiếm.
Và chúng tôi có một yêu cầu thú vị như vậy: đôi khi chúng tôi viết đầu ra của một số lệnh (ví dụ: nhật ký), nó có thể dài hơn 4 kilobyte khá dễ dàng. Và nếu thứ này hoạt động trên UDP, thì nó không cần phải chi tiêu... nó sẽ không có bất kỳ “chi phí chung” nào cho kết nối và đối với một số lượng lớn máy chủ thì đây sẽ là một điểm cộng.
Hãy xem nguồn mở cung cấp cho chúng ta những gì. Đầu tiên, chúng tôi có Logs Engine - đây là công cụ của chúng tôi; Về nguyên tắc, anh ấy có thể làm được mọi thứ, thậm chí anh ấy có thể viết những dòng dài. Chà, nó không nén dữ liệu một cách minh bạch - chúng ta có thể tự nén các cột lớn nếu muốn... tất nhiên là chúng ta không muốn (nếu có thể). Vấn đề duy nhất là anh ta chỉ có thể cho đi những gì phù hợp với trí nhớ của mình; Để đọc phần còn lại, bạn cần lấy binlog của công cụ này và theo đó, phải mất khá nhiều thời gian.
tùy chọn khác là gì ở đó? Ví dụ: "Hadup". Dễ vận hành... Ai nghĩ rằng Hadup dễ cài đặt? Tất nhiên, không có vấn đề gì với việc ghi âm. Khi đọc, đôi khi có câu hỏi nảy sinh. Về nguyên tắc, tôi có thể nói là không, đặc biệt là đối với nhật ký. Lưu trữ dài hạn - tất nhiên là có, nén dữ liệu - vâng, chuỗi dài - rõ ràng là bạn có thể ghi lại. Nhưng việc ghi âm từ một số lượng lớn máy chủ... Bạn vẫn phải tự mình làm điều gì đó!
Rsyslog. Trên thực tế, chúng tôi đã sử dụng nó như một tùy chọn dự phòng để có thể đọc nó mà không bỏ binlog, nhưng nó không thể viết những dòng dài; về nguyên tắc, nó không thể ghi nhiều hơn 4 kilobyte. Bạn phải tự mình thực hiện việc nén dữ liệu theo cách tương tự. Việc đọc sẽ đến từ các tập tin.
Sau đó là sự phát triển “badushka” của LSD. Về cơ bản giống như “Rsyslog”: nó hỗ trợ các chuỗi dài, nhưng nó không thể hoạt động thông qua UDP và trên thực tế, vì điều này, thật không may, khá nhiều thứ cần phải được viết lại ở đó. LSD cần được thiết kế lại để có thể ghi từ hàng chục nghìn máy chủ.
Và đây! Một lựa chọn thú vị là ElasticSearch. Lam thê nao để noi? Anh ấy đọc rất tốt, tức là anh ấy đọc rất nhanh nhưng lại không giỏi viết. Thứ nhất, nếu nén dữ liệu thì rất yếu. Rất có thể, việc tìm kiếm đầy đủ yêu cầu cấu trúc dữ liệu lớn hơn khối lượng ban đầu. Rất khó để vận hành và các vấn đề thường phát sinh với nó. Và một lần nữa, ghi âm trong Elastic - chúng tôi phải tự làm mọi thứ.
Tất nhiên, ở đây ClickHouse là một lựa chọn lý tưởng. Điều duy nhất là việc ghi từ hàng chục nghìn máy chủ là một vấn đề. Nhưng ít nhất có một vấn đề, chúng ta có thể cố gắng giải quyết nó bằng cách nào đó. Và phần còn lại của báo cáo là về vấn đề này. Bạn có thể mong đợi loại hiệu suất nào từ ClickHouse?
Chúng ta sẽ chèn nó như thế nào? Hợp nhất cây
Ai trong số các bạn chưa từng nghe hoặc biết về “ClickHouse”? Tôi cần phải nói với bạn, phải không? Rất nhanh. Việc chèn vào đó - 1-2 gigabit mỗi giây, tốc độ bùng nổ lên tới 10 gigabit mỗi giây thực sự có thể chịu được cấu hình này - có hai Xeon 6 lõi (nghĩa là thậm chí không mạnh nhất), RAM 256 gigabyte, 20 terabyte trong RAID (không có ai cấu hình, cài đặt mặc định). Alexey Milovidov, nhà phát triển ClickHouse, có lẽ đang ngồi đó khóc vì chúng tôi không định cấu hình bất cứ thứ gì (mọi thứ đều hoạt động như vậy đối với chúng tôi). Theo đó, có thể đạt được tốc độ quét khoảng 6 tỷ dòng mỗi giây nếu dữ liệu được nén tốt. Nếu bạn thích % trên một chuỗi văn bản - 100 triệu dòng mỗi giây, nghĩa là nó có vẻ khá nhanh.
Chúng ta sẽ chèn nó như thế nào? Chà, bạn biết rằng VK sử dụng PHP. Chúng tôi sẽ chèn từ mỗi nhân viên PHP thông qua HTTP vào “ClickHouse”, vào bảng MergeTree cho mỗi bản ghi. Ai thấy có vấn đề với kế hoạch này? Vì lý do nào đó, không phải ai cũng giơ tay. Để tôi nói cho bạn biết.
Thứ nhất, có rất nhiều máy chủ - tương ứng, sẽ có rất nhiều kết nối (xấu). Sau đó, tốt hơn là chèn dữ liệu vào MergeTree không quá một lần mỗi giây. Và ai biết tại sao? Được rồi được rồi. Tôi sẽ kể cho bạn nghe thêm một chút về điều này. Một câu hỏi thú vị khác là chúng tôi không thực hiện phân tích, chúng tôi không cần làm phong phú dữ liệu, không cần máy chủ trung gian, chúng tôi muốn chèn trực tiếp vào “ClickHouse” (tốt nhất là - càng trực tiếp thì càng tốt).
Theo đó, việc chèn được thực hiện như thế nào trong MergeTree? Tại sao tốt hơn là nên chèn vào nó không quá một lần một giây hoặc ít thường xuyên hơn? Thực tế là “ClickHouse” là một cơ sở dữ liệu dạng cột và sắp xếp dữ liệu theo thứ tự tăng dần của khóa chính và khi bạn thực hiện thao tác chèn, một số tệp sẽ được tạo ít nhất bằng số cột mà dữ liệu được sắp xếp theo thứ tự tăng dần của khóa chính (một thư mục riêng được tạo, một tập hợp các tệp trên đĩa cho mỗi lần chèn). Sau đó, lần chèn tiếp theo xuất hiện và trong nền, chúng được kết hợp thành các “phân vùng” lớn hơn. Vì dữ liệu đã được sắp xếp nên có thể “hợp nhất” hai tệp đã được sắp xếp mà không tốn nhiều bộ nhớ.
Tuy nhiên, như bạn có thể đoán, nếu bạn viết 10 tệp cho mỗi lần chèn, thì ClickHouse (hoặc máy chủ của bạn) sẽ nhanh chóng kết thúc, vì vậy bạn nên chèn theo lô lớn. Theo đó, chúng tôi chưa bao giờ đưa kế hoạch đầu tiên vào sản xuất. Chúng tôi đã ngay lập tức tung ra một sản phẩm mà ở đây số 2 có:
Ở đây hãy tưởng tượng rằng có khoảng một nghìn máy chủ mà chúng tôi đã khởi chạy, chỉ có PHP. Và trên mỗi máy chủ đều có đại lý địa phương của chúng tôi, mà chúng tôi gọi là “Kittenhouse”, duy trì một kết nối với “ClickHouse” và chèn dữ liệu cứ sau vài giây. Chèn dữ liệu không phải vào MergeTree mà vào bảng đệm, phục vụ chính xác để tránh chèn trực tiếp vào MergeTree ngay lập tức.
Làm việc với các bảng đệm
Nó là gì? Bảng đệm là một phần bộ nhớ được phân chia (nghĩa là nó có thể được chèn vào đó thường xuyên). Chúng bao gồm một số phần và mỗi phần hoạt động như một bộ đệm độc lập và chúng được xóa độc lập (nếu bạn có nhiều phần trong bộ đệm thì sẽ có nhiều phần chèn mỗi giây). Có thể đọc từ các bảng này - sau đó bạn đọc sự kết hợp giữa nội dung của bộ đệm và bảng cha, nhưng tại thời điểm này việc ghi bị chặn, vì vậy tốt hơn là không nên đọc từ đó. Và các bảng đệm thể hiện QPS rất tốt, tức là lên đến 3 nghìn QPS bạn sẽ không gặp bất kỳ vấn đề gì khi chèn vào. Rõ ràng là nếu máy chủ mất điện thì dữ liệu có thể bị mất vì nó chỉ được lưu trong bộ nhớ.
Đồng thời, lược đồ với bộ đệm làm phức tạp ALTER, vì trước tiên bạn cần loại bỏ bảng đệm cũ với lược đồ cũ (dữ liệu sẽ không biến mất ở bất cứ đâu, vì nó sẽ bị xóa trước khi bảng bị xóa). Sau đó, bạn “thay đổi” bảng bạn cần và tạo lại bảng đệm. Theo đó, mặc dù không có bảng đệm, dữ liệu của bạn sẽ không di chuyển đi đâu cả, nhưng ít nhất bạn có thể có nó trên đĩa cục bộ.
Kittenhouse là gì và nó hoạt động như thế nào?
KittenHouse là gì? Đây là một proxy. Đoán xem ngôn ngữ nào? Tôi đã thu thập các chủ đề cường điệu nhất trong báo cáo của mình - “Clickhouse”, Đi, có thể tôi sẽ nhớ điều gì đó khác. Vâng, cái này được viết bằng Go, vì tôi thực sự không biết cách viết bằng C, tôi không muốn.
Theo đó, nó duy trì kết nối với từng máy chủ và có thể ghi vào bộ nhớ. Ví dụ: nếu chúng tôi ghi nhật ký lỗi vào Clickhouse, thì nếu Clickhouse không có thời gian để chèn dữ liệu (xét cho cùng, nếu ghi quá nhiều), thì chúng tôi sẽ không làm phồng bộ nhớ - chúng tôi chỉ cần loại bỏ phần còn lại. Bởi vì nếu chúng tôi viết ra lỗi vài gigabit mỗi giây thì có lẽ chúng tôi có thể loại bỏ một số lỗi. Kittenhouse có thể làm được điều này. Ngoài ra, nó có thể thực hiện phân phối đáng tin cậy, nghĩa là ghi vào đĩa trên máy cục bộ và mỗi lần (ở đó, cứ sau vài giây), nó sẽ cố gắng phân phối dữ liệu từ tệp này. Và lúc đầu, chúng tôi sử dụng định dạng Giá trị thông thường - không phải định dạng nhị phân nào đó, định dạng văn bản (như trong SQL thông thường).
Nhưng sau đó điều này đã xảy ra. Chúng tôi đã sử dụng phương pháp phân phối đáng tin cậy, viết nhật ký, sau đó quyết định (đó là cụm thử nghiệm có điều kiện)... Nó đã được đưa ra trong vài giờ và được khôi phục, và quá trình chèn bắt đầu từ một nghìn máy chủ - hóa ra Clickhouse vẫn có một “Chủ đề trên kết nối” - theo đó, trong một nghìn kết nối, việc chèn hoạt động sẽ dẫn đến mức tải trung bình trên máy chủ là khoảng một nghìn rưỡi. Điều đáng ngạc nhiên là máy chủ đã chấp nhận yêu cầu nhưng dữ liệu vẫn được chèn sau một thời gian; nhưng máy chủ rất khó phục vụ nó...
Thêm nginx
Một giải pháp như vậy cho mô hình Chủ đề trên mỗi kết nối là nginx. Chúng tôi đã cài đặt nginx trước Clickhouse, đồng thời thiết lập cân bằng cho hai bản sao (tốc độ chèn của chúng tôi tăng lên gấp 2 lần, mặc dù thực tế không phải như vậy) và giới hạn số lượng kết nối đến Clickhouse, ở mức ngược dòng và theo đó, nhiều hơn 50 kết nối, có vẻ như việc chèn vào chẳng ích gì.
Sau đó, chúng tôi nhận ra rằng sơ đồ này thường có nhược điểm vì chúng tôi chỉ có một nginx ở đây. Theo đó, nếu nginx này gặp sự cố, mặc dù có bản sao, chúng tôi sẽ mất dữ liệu hoặc ít nhất là không ghi vào đâu. Đó là lý do tại sao chúng tôi thực hiện cân bằng tải của riêng mình. Chúng tôi cũng nhận ra rằng “Clickhouse” vẫn phù hợp với nhật ký, và “con quỷ” cũng bắt đầu viết nhật ký của mình trong “Clickhouse” - thành thật mà nói, rất tiện lợi. Chúng ta vẫn dùng nó cho những “con quỷ” khác.
Sau đó, chúng tôi phát hiện ra vấn đề thú vị này: nếu bạn sử dụng một phương pháp chèn không chuẩn vào chế độ SQL, nó sẽ buộc một trình phân tích cú pháp SQL dựa trên AST chính thức, khá chậm. Theo đó, chúng tôi đã thêm cài đặt để đảm bảo rằng điều này không bao giờ xảy ra. Chúng tôi đã cân bằng tải, kiểm tra tình trạng để nếu một người chết, chúng tôi vẫn để lại dữ liệu. Hiện tại chúng ta có khá nhiều bảng cần có các cluster Clickhouse khác nhau. Và chúng tôi cũng bắt đầu nghĩ đến những cách sử dụng khác - ví dụ: chúng tôi muốn viết nhật ký từ các mô-đun nginx, nhưng họ không biết cách giao tiếp bằng RPC của chúng tôi. Chà, tôi muốn dạy họ cách gửi ít nhất bằng cách nào đó - ví dụ: nhận các sự kiện trên localhost thông qua UDP và sau đó chuyển tiếp chúng đến Clickhouse.
Một bước nữa là đến giải pháp
Lược đồ cuối cùng bắt đầu trông như thế này (phiên bản thứ tư của lược đồ này): trên mỗi máy chủ phía trước Clickhouse có nginx (trên cùng một máy chủ) và nó chỉ đơn giản ủy quyền các yêu cầu tới localhost với giới hạn số lượng kết nối là 50 miếng. Và kế hoạch này đã hoạt động khá tốt, mọi thứ đều khá tốt với nó.
Chúng tôi sống như vậy được khoảng một tháng. Mọi người đều vui vẻ, họ thêm bảng, họ thêm, họ thêm... Nói chung, hóa ra cách chúng tôi thêm bảng đệm chưa tối ưu lắm (hãy nói như vậy). Chúng tôi thực hiện 16 quân cờ trong mỗi bàn và thời gian chớp nhoáng là vài giây; chúng tôi có 20 bảng và mỗi bảng nhận được 8 lần chèn mỗi giây - và tại thời điểm này, “Clickhouse” bắt đầu... các bản ghi bắt đầu chậm lại. Họ thậm chí còn không thông qua... Nginx theo mặc định có một điều thú vị là nếu các kết nối kết thúc ở thượng nguồn, thì nó chỉ trả về “502” cho tất cả các yêu cầu mới.
Và ở đây chúng tôi có (tôi vừa xem nhật ký trong Clickhouse) khoảng nửa phần trăm yêu cầu không thành công. Theo đó, mức sử dụng đĩa cao, có rất nhiều sự hợp nhất. Ồ, tôi đã làm gì thế này? Đương nhiên, tôi không buồn tìm hiểu chính xác lý do tại sao kết nối và ngược dòng lại kết thúc.
Thay thế nginx bằng proxy ngược
Tôi đã quyết định rằng chúng ta cần tự mình quản lý việc này, chúng ta không cần giao việc đó cho nginx - nginx không biết có những bảng nào trong Clickhouse và tôi đã thay thế nginx bằng một proxy ngược mà tôi cũng đã tự viết.
Anh ta đang làm gì vậy? Nó hoạt động dựa trên thư viện fasthttp “goshnoy”, tức là nhanh, gần như nhanh như nginx. Xin lỗi Igor, nếu bạn có mặt ở đây (lưu ý: Igor Sysoev là lập trình viên người Nga, người đã tạo ra máy chủ web nginx). Nó có thể hiểu đây là loại truy vấn nào - INSERT hoặc SELECT - tương ứng, nó chứa các nhóm kết nối khác nhau cho các loại truy vấn khác nhau.
Theo đó, ngay cả khi chúng tôi không có thời gian để hoàn thành các yêu cầu chèn thì các “lựa chọn” sẽ vượt qua và ngược lại. Và nó nhóm dữ liệu vào các bảng đệm - với một bộ đệm nhỏ: nếu có lỗi, lỗi cú pháp, v.v. - để chúng không ảnh hưởng lớn đến phần còn lại của dữ liệu, vì khi chúng ta chỉ chèn vào bảng đệm, chúng ta sẽ có "bachi" nhỏ và tất cả các lỗi cú pháp chỉ ảnh hưởng đến phần nhỏ này; và ở đây chúng sẽ ảnh hưởng đến một bộ đệm lớn. Nhỏ là 1 megabyte, tức là không nhỏ lắm.
Việc chèn đồng bộ hóa và về cơ bản là thay thế nginx, về cơ bản cũng giống như nginx đã làm trước đây - bạn không cần phải thay đổi “Kittenhouse” cục bộ cho việc này. Và vì nó sử dụng fasthttp nên nó rất nhanh - bạn có thể thực hiện hơn 100 nghìn yêu cầu mỗi giây cho các lần chèn đơn lẻ thông qua proxy ngược. Về mặt lý thuyết, bạn có thể chèn từng dòng một vào proxy ngược của chuồng mèo con, nhưng tất nhiên là chúng tôi không làm điều đó.
Lược đồ bắt đầu trông như thế này: “Kittenhouse”, proxy ngược nhóm nhiều yêu cầu vào các bảng và lần lượt các bảng đệm sẽ chèn chúng vào các bảng chính.
Killer là giải pháp tạm thời, Kitten là vĩnh viễn
Đây là một vấn đề thú vị... Có ai trong số các bạn đã sử dụng fasthttp chưa? Ai đã sử dụng fasthttp với các yêu cầu POST? Có lẽ, điều này thực sự không nên được thực hiện vì theo mặc định, nó đệm nội dung yêu cầu và kích thước bộ đệm của chúng tôi được đặt thành 16 megabyte. Quá trình chèn đã ngừng hoạt động tại một thời điểm nào đó và các khối 16 megabyte bắt đầu đến từ tất cả hàng chục nghìn máy chủ và tất cả chúng đều được lưu vào bộ nhớ đệm trước khi được gửi đến Clickhouse. Theo đó, bộ nhớ cạn kiệt, Out-Of-Memory Killer xuất hiện và tiêu diệt proxy ngược (hay “Clickhouse”, về lý thuyết có thể “ăn” nhiều hơn proxy ngược). Chu kỳ lặp lại chính nó. Không phải là một vấn đề rất dễ chịu. Mặc dù chúng tôi chỉ phát hiện ra điều này sau vài tháng hoạt động.
Những gì tôi đã làm? Một lần nữa, tôi thực sự không muốn hiểu chính xác chuyện gì đã xảy ra. Tôi nghĩ khá rõ ràng là bạn không nên lưu vào bộ nhớ. Tôi không thể vá fasthttp, mặc dù tôi đã cố gắng. Nhưng tôi đã tìm ra cách để làm cho nó không cần phải vá bất cứ thứ gì và tôi đã nghĩ ra phương pháp của riêng mình trong HTTP - tôi gọi nó là KITTEN. Chà, nó hợp lý - “VK”, “Mèo con”... Còn gì nữa không?..
Nếu một yêu cầu đến máy chủ bằng phương thức Kitten thì máy chủ sẽ phản hồi “meo meo” - một cách hợp lý. Nếu anh ta phản hồi điều này, thì người ta coi như anh ta hiểu giao thức này và sau đó tôi chặn kết nối (fasthttp có phương thức như vậy) và kết nối sẽ chuyển sang chế độ "thô". Tại sao tôi cần nó? Tôi muốn kiểm soát cách đọc từ kết nối TCP. TCP có một đặc tính tuyệt vời: nếu không có ai đọc từ phía bên kia thì quá trình ghi sẽ bắt đầu chờ và bộ nhớ không được dành đặc biệt cho việc này.
Và vì vậy, tôi đọc từ khoảng 50 khách hàng cùng một lúc (từ năm mươi vì năm mươi chắc chắn là đủ, ngay cả khi tỷ lệ đến từ một DC khác)... Mức tiêu thụ đã giảm với cách tiếp cận này ít nhất 20 lần, nhưng thành thật mà nói, tôi , Tôi không thể đo chính xác là mấy giờ, vì nó đã vô nghĩa rồi (đã đạt đến mức sai số rồi). Giao thức là nhị phân, nghĩa là nó chứa tên bảng và dữ liệu; không có tiêu đề http nên tôi không sử dụng ổ cắm web (tôi không cần giao tiếp với trình duyệt - tôi đã tạo một giao thức phù hợp với nhu cầu của chúng tôi). Và mọi thứ trở nên tốt đẹp với anh ấy.
Bảng đệm buồn quá
Gần đây chúng tôi gặp một tính năng thú vị khác của bảng đệm. Và vấn đề này đã đau đớn hơn nhiều so với những vấn đề khác. Hãy tưởng tượng tình huống này: bạn đã tích cực sử dụng Clickhouse, bạn có hàng chục máy chủ Clickhouse và bạn có một số yêu cầu mất rất nhiều thời gian để đọc (giả sử là hơn 60 giây); và bạn đến và thực hiện Thay đổi ngay lúc này... Trong khi chờ đợi, "các lựa chọn" bắt đầu trước "Alter" sẽ không được đưa vào bảng này, "Alter" sẽ không bắt đầu - có thể là một số tính năng về cách "Clickhouse" hoạt động trong chỗ này. Có lẽ điều này có thể được sửa chữa? Hay là điều này không thể thực hiện được?
Nhìn chung, rõ ràng trên thực tế đây không phải là một vấn đề quá lớn, nhưng với các bảng đệm thì điều đó càng trở nên nhức nhối hơn. Bởi vì, giả sử, nếu thời gian chờ “Alter” của bạn (và nó có thể hết thời gian trên một máy chủ khác - không phải trên máy của bạn mà trên một bản sao chẳng hạn), thì... Bạn đã xóa bảng đệm, “Alter” của bạn ( hoặc một số máy chủ khác) hết thời gian thì đã xảy ra lỗi “Alter”) - bạn vẫn cần đảm bảo rằng dữ liệu tiếp tục được ghi: bạn tạo lại các bảng đệm (theo sơ đồ tương tự như bảng cha), sau đó Cuối cùng, “Alter” đi qua, kết thúc và bộ đệm của bảng bắt đầu khác về lược đồ so với bảng gốc. Tùy thuộc vào "Alter" là gì, phần chèn có thể không còn đi tới bảng đệm này nữa - điều này thật đáng buồn.
Ngoài ra còn có một dấu hiệu như vậy (có thể ai đó đã để ý) - nó được gọi là query_thread_log trong các phiên bản mới của Clickhouse. Theo mặc định, trong một số phiên bản đã có một. Ở đây chúng tôi đã tích lũy được 840 triệu bản ghi trong vài tháng (100 gigabyte). Điều này là do thực tế là các "chèn" đã được viết ở đó (nhân tiện, có thể bây giờ chúng không được viết). Như tôi đã nói với bạn, “phần chèn” của chúng tôi rất nhỏ - chúng tôi có rất nhiều “phần chèn” vào bảng đệm. Rõ ràng là tính năng này đã bị vô hiệu hóa - tôi chỉ kể cho bạn những gì tôi đã thấy trên máy chủ của chúng tôi. Tại sao? Đây là một lập luận khác chống lại việc sử dụng bảng đệm! Spotty rất buồn.
Ai biết tên anh chàng này là Spotty? Nhân viên VK giơ tay. ĐƯỢC RỒI.
Về kế hoạch của “KitttenHouse”
Các kế hoạch thường không được chia sẻ, phải không? Đột nhiên bạn sẽ không hoàn thành được chúng và trông không được đẹp trong mắt người khác. Nhưng tôi sẽ mạo hiểm! Chúng tôi muốn làm những điều sau: đối với tôi, có vẻ như các bảng đệm vẫn là một cái nạng và chúng tôi cần phải tự mình đệm phần chèn. Nhưng chúng tôi vẫn không muốn đệm nó vào đĩa, vì vậy chúng tôi sẽ đệm phần chèn vào bộ nhớ.
Theo đó, khi một "chèn" được thực hiện, nó sẽ không còn đồng bộ nữa - nó sẽ hoạt động như một bảng đệm, sẽ chèn vào bảng cha (tốt, một ngày nào đó sau đó) và báo cáo qua một kênh riêng mà các phần chèn đã được chuyển và phần nào đã được chuyển qua. không có.
Tại sao tôi không thể rời khỏi phần chèn đồng bộ? Nó thuận tiện hơn nhiều. Thực tế là nếu bạn chèn từ 10 nghìn máy chủ thì mọi thứ đều ổn - bạn sẽ nhận được một ít từ mỗi máy chủ, bạn chèn vào đó mỗi giây một lần, mọi thứ đều ổn. Nhưng tôi muốn sơ đồ này hoạt động, chẳng hạn như từ hai máy, để bạn có thể tải xuống ở tốc độ cao - có thể không tận dụng tối đa Clickhouse, nhưng ghi ít nhất 100 megabyte mỗi giây từ một máy thông qua proxy ngược - sơ đồ này phải mở rộng theo cả số lượng lớn và nhỏ, vì vậy chúng tôi không thể đợi một giây cho mỗi lần chèn, vì vậy nó phải không đồng bộ. Và theo cách tương tự, các xác nhận không đồng bộ sẽ xuất hiện sau khi quá trình chèn hoàn tất. Chúng ta sẽ biết liệu nó có vượt qua hay không.
Điều quan trọng nhất là trong sơ đồ này, chúng tôi biết chắc chắn liệu việc chèn có diễn ra hay không. Hãy tưởng tượng tình huống này: bạn có một bảng đệm, bạn đã viết một cái gì đó vào đó, và sau đó, giả sử, bảng chuyển sang chế độ chỉ đọc và cố gắng xóa bộ đệm. Dữ liệu sẽ đi đâu? Chúng sẽ vẫn còn trong bộ đệm. Nhưng chúng tôi không thể chắc chắn về điều này - điều gì sẽ xảy ra nếu có một số lỗi khác, do đó dữ liệu sẽ không còn trong bộ đệm... (Địa chỉ Alexey Milovidov, Yandex, nhà phát triển ClickHouse) Hay nó sẽ vẫn còn? Luôn luôn? Alexey thuyết phục chúng tôi rằng mọi thứ sẽ ổn thôi. Chúng tôi không có lý do gì để không tin anh ấy. Nhưng tất cả đều giống nhau: nếu chúng ta không sử dụng bảng đệm thì sẽ không có vấn đề gì với chúng. Việc tạo số lượng bảng nhiều gấp đôi cũng bất tiện, mặc dù về nguyên tắc không có vấn đề gì lớn. Đây là kế hoạch.
Hãy nói về việc đọc
Bây giờ hãy nói về việc đọc. Chúng tôi cũng đã viết công cụ của riêng mình ở đây. Có vẻ như, tại sao lại viết nhạc cụ của riêng bạn ở đây?.. Và ai đã sử dụng Tabix? Không hiểu sao lại có ít người giơ tay... Và ai hài lòng với màn trình diễn của Tabix? Chà, chúng tôi không hài lòng với nó và nó không thuận tiện cho việc xem dữ liệu. Nó tốt cho việc phân tích, nhưng chỉ để xem thì rõ ràng nó không được tối ưu hóa. Vì vậy, tôi đã viết giao diện của riêng mình.
Nó rất đơn giản - nó chỉ có thể đọc dữ liệu. Anh ấy không biết thể hiện đồ họa, anh ấy không biết làm gì cả. Nhưng nó có thể hiển thị những gì chúng ta cần: ví dụ: trong bảng có bao nhiêu hàng, nó chiếm bao nhiêu dung lượng (không chia thành các cột), tức là chúng ta cần một giao diện rất cơ bản.
Và nó trông rất giống với Sequel Pro, nhưng chỉ được thực hiện trên Bootstrap của Twitter và phiên bản thứ hai. Bạn hỏi: "Yuri, tại sao lại là phiên bản thứ hai?" Năm nào? 2018? Nói chung, tôi đã làm điều này cách đây khá lâu cho “Muscle” (MySQL) và chỉ thay đổi một vài dòng trong các truy vấn ở đó và nó bắt đầu hoạt động cho “Clickhouse”, điều này đặc biệt cảm ơn! Bởi vì trình phân tích cú pháp rất giống với trình phân tích cú pháp “cơ bắp” và các truy vấn cũng rất giống nhau - rất thuận tiện, đặc biệt là lúc đầu.
Chà, nó có thể lọc các bảng, có thể hiển thị cấu trúc và nội dung của bảng, cho phép bạn sắp xếp, lọc theo cột, hiển thị truy vấn dẫn đến kết quả, các hàng bị ảnh hưởng (kết quả là bao nhiêu), tức là những điều cơ bản để xem dữ liệu. Khá nhanh.
Ngoài ra còn có một biên tập viên. Thành thật mà nói, tôi đã cố gắng đánh cắp toàn bộ trình soạn thảo từ Tabix, nhưng tôi không thể. Nhưng bằng cách nào đó nó hoạt động. Về nguyên tắc thì chỉ vậy thôi.
“Clickhouse” phù hợp với mật độ
Tôi muốn nói với bạn rằng Clickhouse, bất chấp tất cả các vấn đề được mô tả, vẫn rất phù hợp với nhật ký. Quan trọng nhất, nó giải quyết được vấn đề của chúng tôi - nó rất nhanh và cho phép bạn lọc nhật ký theo cột. Về nguyên tắc, các bảng đệm hoạt động không tốt, nhưng thường thì không ai biết tại sao... Có thể bây giờ bạn đã biết rõ hơn mình sẽ gặp vấn đề ở đâu.
TCP? Nói chung, trong VK người ta thường sử dụng UDP. Và khi tôi sử dụng TCP... Tất nhiên, không ai nói với tôi: “Yuri, bạn đang nói về cái gì vậy! Bạn không thể, bạn cần UDP.” Hóa ra TCP không đáng sợ đến thế. Điều duy nhất là, nếu bạn viết hàng chục nghìn hợp chất hoạt động, bạn cần chuẩn bị cẩn thận hơn một chút; nhưng điều đó là có thể và khá dễ dàng.
Tôi đã hứa sẽ đăng “Kittenhouse” và “Lighthouse” trên HighLoad Siberia nếu mọi người đăng ký “phụ trợ VK” công khai của chúng tôi... Và bạn biết đấy, không phải ai cũng đăng ký... Tất nhiên, tôi sẽ không yêu cầu bạn đăng ký kênh của chúng tôi công cộng. Vẫn còn nhiều bạn quá, thậm chí có người sẽ bị xúc phạm nhưng vẫn hãy đăng ký (và ở đây tôi phải làm mắt như mắt mèo). Đó là . Cảm ơn rất nhiều! Github là của chúng tôi . Với Clickhouse mái tóc của bạn sẽ mềm mượt.
Dẫn: - Các bạn, bây giờ là câu hỏi. Ngay sau khi chúng tôi trình bày bằng khen và báo cáo của bạn về VHS.
Yury Nasretdinov (sau đây gọi tắt là YN): – Làm sao bạn có thể ghi lại báo cáo của tôi trên VHS nếu nó vừa kết thúc?
Dẫn: – Bạn cũng không thể xác định đầy đủ “Clickhouse” sẽ hoạt động như thế nào hay không! Các bạn ơi, 5 phút cho câu hỏi!
câu hỏi
Câu hỏi của khán giả (sau đây gọi tắt là Q): - Chào buổi chiều. Cảm ơn bạn rất nhiều vì báo cáo. Tôi có hai câu hỏi. Tôi sẽ bắt đầu với một điều phù phiếm: số chữ cái t trong tên "Kittenhouse" trong sơ đồ (3, 4, 7...) có ảnh hưởng đến sự hài lòng của lũ mèo không?
Vâng: - Số lượng cái gì?
З: – Thư t. Có ba chữ t, đâu đó khoảng ba chữ t.
Vâng: - Tôi chưa sửa nó à? Vâng, tất nhiên là có! Đây là những sản phẩm khác nhau - bấy lâu nay tôi chỉ đang lừa dối bạn thôi. Được rồi, tôi đùa thôi - không thành vấn đề. À, ngay đây! Không, nó giống nhau, tôi đã mắc lỗi đánh máy.
З: - Cảm ơn. Câu hỏi thứ hai là nghiêm túc. Theo như tôi hiểu, trong Clickhouse, các bảng đệm chỉ tồn tại trong bộ nhớ, không được lưu vào đĩa và do đó, không tồn tại lâu dài.
Vâng: - Đúng.
З: – Đồng thời, máy khách của bạn sẽ lưu vào đĩa, điều này ngụ ý một số đảm bảo về việc phân phối các nhật ký tương tự này. Nhưng điều này không hề được đảm bảo tại Clickhouse. Giải thích cách thực hiện việc bảo lãnh, do nguyên nhân gì?.. Dưới đây là chi tiết hơn về cơ chế này
Vâng: – Đúng, về mặt lý thuyết thì không có gì mâu thuẫn ở đây cả, vì khi Clickhouse rơi xuống, bạn thực sự có thể phát hiện ra nó theo hàng triệu cách khác nhau. Nếu Clickhouse gặp sự cố (nếu nó kết thúc không chính xác), nói một cách đại khái, bạn có thể tua lại một chút nhật ký mà bạn đã viết ra và bắt đầu từ thời điểm mọi thứ hoàn toàn ổn. Giả sử bạn tua lại một phút, tức là coi như bạn đã xả hết mọi thứ trong một phút.
З: – Tức là “Kittenhouse” giữ cửa sổ lâu hơn và khi bị ngã có thể nhận ra và tua lại được không?
Vâng: – Nhưng đây là trên lý thuyết. Trong thực tế, chúng tôi không làm điều này và việc phân phối đáng tin cậy là từ XNUMX đến vô tận. Nhưng trung bình một. Chúng tôi hài lòng rằng nếu Clickhouse gặp sự cố vì lý do nào đó hoặc máy chủ “khởi động lại” thì chúng tôi sẽ mất một chút. Trong tất cả các trường hợp khác, sẽ không có gì xảy ra.
З: - Xin chào. Ngay từ đầu, tôi thấy có vẻ như bạn thực sự đã sử dụng UDP ngay từ đầu báo cáo. Bạn có http, tất cả những thứ đó... Và hầu hết các vấn đề mà bạn mô tả, theo tôi hiểu, đều do giải pháp cụ thể này gây ra...
Vâng: – Chúng ta sử dụng TCP để làm gì?
З: - Về cơ bản là có.
Vâng: - Không.
З: – Đó là với fasthttp mà bạn gặp vấn đề, với kết nối thì bạn gặp vấn đề. Nếu bạn vừa mới sử dụng UDP, bạn sẽ tiết kiệm được thời gian cho mình. Chà, sẽ có vấn đề với những tin nhắn dài hay điều gì đó khác...
Vâng: - Với cái gì?
З: – Với những tin nhắn dài, vì nó có thể không phù hợp với MTU, hay cái gì khác... À, có thể có vấn đề của riêng họ. Câu hỏi đặt ra là: tại sao không phải là UDP?
Vâng: – Tôi tin rằng các tác giả phát triển TCP/IP thông minh hơn tôi rất nhiều và biết rõ hơn tôi về cách tuần tự hóa các gói tin (để chúng đi), đồng thời điều chỉnh cửa sổ gửi, không làm mạng quá tải, đưa ra phản hồi về những gì không được đọc, không tính ở phía bên kia... Theo tôi, tất cả những vấn đề này sẽ tồn tại trong UDP, chỉ có điều tôi sẽ phải viết nhiều mã hơn những gì tôi đã viết để tự mình thực hiện điều tương tự và rất có thể kém. Tôi thậm chí còn không thực sự thích viết bằng C, huống hồ là ở đó ...
З: - Thật tiện lợi! Đã gửi ok và đừng chờ đợi gì cả - nó hoàn toàn không đồng bộ. Một thông báo quay lại rằng mọi thứ đều ổn - điều đó có nghĩa là nó đã đến; Nếu nó không đến thì có nghĩa là nó tệ.
Vâng: – Tôi cần cả hai – Tôi cần có thể gửi cả hai với bảo đảm giao hàng và không có bảo đảm giao hàng. Đây là hai kịch bản khác nhau. Tôi cần không làm mất một số nhật ký hoặc không làm mất chúng vì lý do chính đáng.
З: – Tôi sẽ không lãng phí thời gian. Điều này cần phải được thảo luận thêm. Cảm ơn.
Dẫn: – Ai có thắc mắc – giơ tay lên trời!
З: - Xin chào, tôi là Sasha. Ở đâu đó ở giữa báo cáo, có cảm giác rằng, ngoài TCP, có thể sử dụng một giải pháp làm sẵn - một loại Kafka nào đó.
Vâng: – Chà... tôi đã nói với bạn rằng tôi không muốn sử dụng máy chủ trung gian, bởi vì... ở Kafka, hóa ra chúng tôi có mười nghìn máy chủ; trên thực tế, chúng tôi có nhiều hơn - hàng chục nghìn máy chủ. Việc thực hiện Kafka mà không có bất kỳ proxy nào cũng có thể gây khó khăn. Ngoài ra, quan trọng nhất là nó vẫn mang lại “độ trễ”, nó cung cấp thêm các hosting mà bạn cần có. Nhưng tôi không muốn có chúng - tôi muốn...
З: “Nhưng cuối cùng thì mọi chuyện lại diễn ra như vậy.”
Vâng: – Không, không có chủ nhà! Tất cả điều này hoạt động trên máy chủ Clickhouse.
З: - Chà, và “Kittenhouse”, ngược lại - anh ấy sống ở đâu?
Vâng: – Trên máy chủ Clickhouse không ghi gì vào đĩa.
З: - Chúng ta hãy giả sử.
Dẫn: - Bạn có hài lòng không? Chúng tôi có thể trả lương cho bạn không?
З: - Có, bạn có thể. Trên thực tế, có rất nhiều cách để đạt được điều tương tự, và bây giờ - câu trả lời trước đây về chủ đề TCP mâu thuẫn với tình huống này, theo ý kiến của tôi. Tôi có cảm giác như mọi thứ có thể được thực hiện bằng đầu gối của mình trong thời gian ngắn hơn nhiều.
Vâng: – Và cũng là lý do tại sao tôi không muốn sử dụng Kafka, vì có khá nhiều phàn nàn trong cuộc trò chuyện Clickhouse Telegram rằng, chẳng hạn như tin nhắn từ Kafka đã bị mất. Không phải từ chính Kafka, mà từ sự hợp nhất giữa Kafka và Clickhaus; hoặc một cái gì đó không kết nối ở đó. Nói một cách đại khái thì việc viết client cho Kafka là cần thiết. Tôi không nghĩ có thể có giải pháp đơn giản hoặc đáng tin cậy hơn.
З: – Nói cho tôi biết, tại sao bạn không thử xếp hàng hoặc đi một loại xe buýt thông thường nào đó? Vì bạn nói rằng với tính không đồng bộ, bạn có thể tự gửi nhật ký qua hàng đợi và nhận phản hồi không đồng bộ qua hàng đợi?
Vâng: – Hãy đề xuất những hàng đợi nào có thể được sử dụng?
З: – Bất kỳ, thậm chí không có sự đảm bảo rằng chúng theo thứ tự. Một số loại Redis, RMQ...
Vâng: – Tôi có cảm giác rằng Redis rất có thể sẽ không thể thực hiện được số lượng chèn như vậy ngay cả trên một máy chủ (theo nghĩa là một số máy chủ) kéo Clickhouse ra. Tôi không thể chứng minh điều này bằng bất kỳ bằng chứng nào (tôi chưa đánh giá nó), nhưng đối với tôi, có vẻ như Redis không phải là giải pháp tốt nhất ở đây. Về nguyên tắc, hệ thống này có thể được coi là một hàng đợi tin nhắn ngẫu hứng, nhưng chỉ được thiết kế riêng cho “Clickhouse”
Dẫn: -Yuri, cảm ơn bạn rất nhiều. Tôi đề nghị kết thúc các câu hỏi và câu trả lời ở đây và nói xem chúng tôi sẽ giao cuốn sách cho ai trong số những người đã đặt câu hỏi.
Vâng: – Tôi muốn tặng một cuốn sách cho người đầu tiên đặt câu hỏi.
Dẫn: - Tuyệt vời! Tuyệt vời! Tuyệt vời! Cảm ơn rất nhiều!
Một số quảng cáo 🙂
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com