Lý thuyết và thực hành sử dụng ClickHouse trong ứng dụng thực tế. Alexander Zaitsev (2018)

Mặc dù thực tế là hiện nay có rất nhiều dữ liệu ở hầu hết mọi nơi nhưng cơ sở dữ liệu phân tích vẫn còn khá kỳ lạ. Họ ít được biết đến và thậm chí còn ít có khả năng sử dụng chúng một cách hiệu quả. Nhiều người tiếp tục “ăn xương rồng” với MySQL hoặc PostgreSQL, được thiết kế cho các tình huống khác, gặp khó khăn với NoSQL hoặc trả quá nhiều tiền cho các giải pháp thương mại. ClickHouse là một công cụ thay đổi cuộc chơi và giảm đáng kể rào cản gia nhập thế giới DBMS phân tích.

Báo cáo được lấy từ BackEnd Conf 2018 và được xuất bản với sự cho phép của diễn giả.

Tôi là ai và tại sao tôi lại nói về ClickHouse? Tôi là Giám đốc Phát triển tại LifeStreet, công ty sử dụng ClickHouse. Tôi cũng là người sáng lập Altinity. Đây là đối tác của Yandex nhằm quảng bá ClickHouse và giúp Yandex đưa ClickHouse thành công hơn. Tôi cũng sẵn sàng chia sẻ kiến ​​thức về ClickHouse.

Và tôi cũng không phải là anh trai của Petya Zaitsev. Tôi thường được hỏi về điều này. Không, chúng tôi không phải là anh em.

“Mọi người đều biết” rằng ClickHouse:

• Rất nhanh,
• Rât thuận tiện,
• Được sử dụng trong Yandex.

Người ta ít biết đến công ty nào và nó được sử dụng như thế nào.

Tôi sẽ cho bạn biết lý do, vị trí và cách sử dụng ClickHouse, ngoài Yandex.

Tôi sẽ cho bạn biết cách giải quyết các vấn đề cụ thể bằng ClickHouse ở các công ty khác nhau, những công cụ ClickHouse nào bạn có thể sử dụng cho nhiệm vụ của mình và cách chúng được sử dụng ở các công ty khác nhau.

Tôi đã chọn ba ví dụ hiển thị ClickHouse từ các khía cạnh khác nhau. Tôi nghĩ nó sẽ rất thú vị.

Câu hỏi đầu tiên là: “Tại sao chúng ta cần ClickHouse?” Có vẻ như câu hỏi này khá rõ ràng nhưng có nhiều hơn một câu trả lời cho nó.

• Câu trả lời đầu tiên là vì lý do hiệu suất. ClickHouse rất nhanh. Phân tích trên ClickHouse cũng rất nhanh. Nó thường có thể được sử dụng khi có thứ gì đó khác đang hoạt động rất chậm hoặc rất kém.
• Câu trả lời thứ hai là chi phí. Và trước hết là chi phí mở rộng quy mô. Ví dụ: Vertica là một cơ sở dữ liệu hoàn toàn xuất sắc. Nó hoạt động rất tốt nếu bạn không có nhiều terabyte dữ liệu. Nhưng khi chúng ta đang nói về hàng trăm terabyte hoặc petabyte, chi phí của giấy phép và hỗ trợ lên tới một số tiền khá đáng kể. Và nó đắt tiền. Và ClickHouse là miễn phí.
• Câu trả lời thứ ba là chi phí vận hành. Đây là một cách tiếp cận hơi khác. RedShift là một chất tương tự tuyệt vời. Với RedShift bạn có thể đưa ra quyết định rất nhanh chóng. Nó sẽ hoạt động tốt, nhưng đồng thời, hàng giờ, hàng ngày và hàng tháng, bạn sẽ phải trả khá nhiều tiền cho Amazon, vì đây là một dịch vụ đắt tiền đáng kể. Google BigQuery cũng vậy. Nếu ai đó đã sử dụng nó thì họ biết rằng bạn có thể chạy một số truy vấn ở đó và đột nhiên nhận được hóa đơn trị giá hàng trăm đô la.

ClickHouse không gặp phải những vấn đề này.

ClickHouse hiện được sử dụng ở đâu? Ngoài Yandex, ClickHouse còn được sử dụng ở nhiều doanh nghiệp và công ty khác nhau.

• Trước hết, đây là phân tích ứng dụng web, tức là đây là trường hợp sử dụng đến từ Yandex.
• Nhiều công ty AdTech sử dụng ClickHouse.
• Nhiều công ty cần phân tích nhật ký hoạt động từ nhiều nguồn khác nhau.
• Một số công ty sử dụng ClickHouse để theo dõi nhật ký bảo mật. Họ tải chúng lên ClickHouse, lập báo cáo và nhận được kết quả mà họ cần.
• Các công ty đang bắt đầu sử dụng nó trong phân tích tài chính, tức là dần dần các doanh nghiệp lớn cũng tiếp cận ClickHouse.
• CloudFlare. Nếu ai theo dõi ClickHouse chắc hẳn đã từng nghe đến tên công ty này. Đây là một trong những người đóng góp đáng kể từ cộng đồng. Và họ cài đặt ClickHouse rất nghiêm túc. Ví dụ: họ đã tạo Kafka Engine cho ClickHouse.
• Các công ty viễn thông đã bắt đầu sử dụng. Một số công ty sử dụng ClickHouse làm bằng chứng về ý tưởng hoặc đã được sản xuất.
• Một công ty sử dụng ClickHouse để giám sát quá trình sản xuất. Họ kiểm tra các vi mạch, viết ra một loạt thông số, có khoảng 2 đặc điểm. Và sau đó họ phân tích xem lô hàng đó tốt hay xấu.
• Phân tích chuỗi khối. Có một công ty của Nga tên là Bloxy.info. Đây là một phân tích của mạng Ethereum. Họ cũng đã làm điều này trên ClickHouse.

Hơn nữa, kích thước không thành vấn đề. Có nhiều công ty sử dụng một máy chủ nhỏ. Và anh ấy cho phép họ giải quyết vấn đề của họ. Và thậm chí nhiều công ty còn sử dụng các cụm lớn gồm nhiều máy chủ hoặc hàng chục máy chủ.

Và nếu bạn nhìn vào hồ sơ, thì:

• Yandex: Hơn 500 máy chủ, họ lưu trữ 25 tỷ hồ sơ mỗi ngày ở đó.
• LifeStreet: 60 máy chủ, khoảng 75 tỷ hồ sơ mỗi ngày. Có ít máy chủ hơn và nhiều bản ghi hơn trong Yandex.
• CloudFlare: 36 máy chủ, họ lưu trữ 200 tỷ bản ghi mỗi ngày. Họ thậm chí còn có ít máy chủ hơn và lưu trữ nhiều dữ liệu hơn.
• Bloomberg: 102 máy chủ, khoảng một nghìn tỷ hồ sơ mỗi ngày. Người giữ kỷ lục.

Về mặt địa lý, con số này cũng rất nhiều. Bản đồ này hiển thị bản đồ nhiệt về nơi ClickHouse được sử dụng trên thế giới. Ở đây Nga, Trung Quốc và Mỹ nổi bật rõ ràng. Có rất ít nước châu Âu. Và có thể phân biệt được 4 cụm.

Đây là phép phân tích so sánh, không cần tìm số tuyệt đối. Đây là phân tích về những khách truy cập đọc tài liệu bằng tiếng Anh trên trang web Altinity, vì ở đó không có người nói tiếng Nga. Và Nga, Ukraine, Belarus, tức là bộ phận nói tiếng Nga trong cộng đồng, là những người sử dụng nhiều nhất. Sau đó là Mỹ và Canada. Trung Quốc đang bắt kịp rất nhiều. Gần như không có Trung Quốc ở đó sáu tháng trước; bây giờ Trung Quốc đã vượt qua châu Âu và tiếp tục phát triển. Châu Âu cũ cũng không bị tụt lại phía sau, và kỳ lạ thay, nước dẫn đầu trong việc sử dụng ClickHouse lại là Pháp.

Tại sao tôi lại kể tất cả những điều này? Để chứng tỏ rằng ClickHouse đang trở thành một giải pháp tiêu chuẩn để phân tích dữ liệu lớn và đã được sử dụng ở nhiều nơi. Nếu bạn sử dụng nó, bạn đang đi đúng xu hướng. Nếu chưa sử dụng thì bạn không cần phải sợ rằng mình sẽ bị bỏ lại một mình và không ai giúp đỡ bạn vì nhiều người đã làm điều này rồi.

Đây là những ví dụ về việc sử dụng ClickHouse thực sự ở một số công ty.

• Ví dụ đầu tiên là mạng quảng cáo: di chuyển từ Vertica sang ClickHouse. Và tôi biết một số công ty đã chuyển từ Vertica hoặc đang trong quá trình chuyển đổi.
• Ví dụ thứ hai là lưu trữ giao dịch trên ClickHouse. Đây là một ví dụ được xây dựng trên antipotype. Mọi thứ không cần phải làm trong ClickHouse theo lời khuyên của nhà phát triển đều được thực hiện tại đây. Và đồng thời nó được thực hiện hiệu quả đến mức nó hoạt động. Và nó hoạt động tốt hơn nhiều so với một giải pháp giao dịch thông thường.
• Ví dụ thứ ba là tính toán phân tán trên ClickHouse. Đã có câu hỏi về cách tích hợp ClickHouse vào hệ sinh thái Hadoop. Tôi sẽ đưa ra một ví dụ về cách một công ty đã làm điều gì đó tương tự như vùng chứa thu nhỏ bản đồ trên ClickHouse, giám sát việc bản địa hóa dữ liệu, v.v., để tính toán một nhiệm vụ rất không hề tầm thường.

• LifeStreet là một công ty Công nghệ quảng cáo có tất cả các công nghệ liên quan đến mạng quảng cáo.
• Cô ấy tham gia vào việc tối ưu hóa quảng cáo và đặt giá thầu theo chương trình.
• Rất nhiều dữ liệu: khoảng 10 tỷ sự kiện mỗi ngày. Hơn nữa, có những sự kiện có thể được chia thành nhiều sự kiện phụ.
• Có rất nhiều khách hàng sử dụng dữ liệu này và đây không chỉ là con người mà còn có nhiều thuật toán khác nhau tham gia vào đặt giá thầu theo chương trình.

Công ty đã đi một con đường dài và đầy chông gai. Và tôi đã nói về nó trên HighLoad. Đầu tiên, LifeStreet chuyển từ MySQL (có một thời gian dừng ngắn ở Oracle) sang Vertica. Và bạn có thể tìm thấy một câu chuyện về nó.

Và mọi thứ đều rất tốt, nhưng nhanh chóng trở nên rõ ràng rằng dữ liệu ngày càng tăng và Vertica thì đắt đỏ. Vì vậy, nhiều lựa chọn thay thế khác nhau đã được tìm kiếm. Một số trong số họ được liệt kê ở đây. Và trên thực tế, chúng tôi đã thực hiện bằng chứng về khái niệm hoặc đôi khi kiểm tra hiệu suất của hầu hết tất cả các cơ sở dữ liệu có sẵn trên thị trường từ ngày 13 đến ngày 16 và có chức năng gần như phù hợp. Và tôi cũng đã nói về một số trong số đó trên HighLoad.

Nhiệm vụ trước tiên là di chuyển từ Vertica vì dữ liệu ngày càng tăng. Và chúng đã tăng trưởng theo cấp số nhân trong vài năm. Sau đó họ đi lên kệ, nhưng vẫn vậy. Và dự đoán sự tăng trưởng này, các yêu cầu kinh doanh về khối lượng dữ liệu mà một số loại phân tích cần được thực hiện, rõ ràng là sẽ sớm có cuộc nói chuyện về petabyte. Và việc trả cho petabyte vốn đã rất tốn kém, vì vậy chúng tôi đang tìm kiếm một giải pháp thay thế để đi.

Đi đâu? Và trong một thời gian dài, người ta hoàn toàn không biết phải đi đâu, vì một mặt có cơ sở dữ liệu thương mại, chúng có vẻ hoạt động tốt. Một số hoạt động gần như Vertica, một số tệ hơn. Nhưng tất cả đều đắt tiền, không thể tìm được thứ gì rẻ hơn hoặc tốt hơn.

Mặt khác, có những giải pháp nguồn mở không có nhiều, tức là đối với phân tích, chúng có thể được tính bằng một mặt. Và chúng miễn phí hoặc rẻ tiền, nhưng chúng hoạt động chậm. Và chúng thường thiếu chức năng cần thiết và hữu ích.

Và không có gì có thể kết hợp những điều tốt đẹp có trong cơ sở dữ liệu thương mại và tất cả những thứ miễn phí có trong nguồn mở.

Chẳng có chuyện gì xảy ra cho đến khi Yandex bất ngờ rút ClickHouse ra khỏi chiếc mũ như con thỏ của nhà ảo thuật. Và đây là một quyết định bất ngờ, người ta vẫn đặt câu hỏi: “Tại sao?”, tuy nhiên.

Và ngay vào mùa hè năm 2016, chúng tôi bắt đầu tìm hiểu ClickHouse là gì. Và hóa ra đôi khi nó có thể nhanh hơn Vertica. Chúng tôi đã thử nghiệm các kịch bản khác nhau theo các yêu cầu khác nhau. Và nếu truy vấn chỉ sử dụng một bảng, tức là không có bất kỳ phép nối nào, thì ClickHouse nhanh gấp đôi Vertica.

Tôi không quá lười biếng và đã xem thêm các bài kiểm tra Yandex vào ngày hôm trước. Ở đó cũng vậy: ClickHouse nhanh gấp đôi Vertica nên họ thường nói về nó.

Nhưng nếu các truy vấn có chứa các phép nối thì mọi thứ sẽ không rõ ràng lắm. Và ClickHouse có thể chậm gấp đôi Vertica. Và nếu bạn sửa và viết lại yêu cầu một chút thì chúng sẽ gần bằng nhau. Không tệ. Và nó miễn phí.

Và sau khi nhận được kết quả kiểm tra và nhìn nó từ nhiều góc độ khác nhau, LifeStreet đã tìm đến ClickHouse.

Đây là năm thứ 16, tôi nhắc nhở bạn. Nó giống như trò đùa về những con chuột khóc lóc và tự tiêm thuốc nhưng vẫn tiếp tục ăn cây xương rồng. Và điều này đã được thảo luận chi tiết, có một video về điều này, v.v.

Vì vậy, tôi sẽ không nói chi tiết về vấn đề này mà chỉ nói về kết quả và một số điều thú vị mà lúc đó tôi chưa nói đến.

Kết quả là:

• Di chuyển thành công và hệ thống đã được sản xuất được hơn một năm.
• Năng suất và tính linh hoạt đã tăng lên. Từ 10 tỷ hồ sơ mà chúng tôi có đủ khả năng lưu trữ mỗi ngày chỉ trong một khoảng thời gian ngắn, LifeStreet hiện lưu trữ 75 tỷ hồ sơ mỗi ngày và có thể lưu trữ như vậy trong 3 tháng trở lên. Nếu bạn tính ở mức cao nhất thì số sự kiện này được lưu trữ lên tới một triệu sự kiện mỗi giây. Hơn một triệu truy vấn SQL mỗi ngày được gửi tới hệ thống này, chủ yếu là từ nhiều robot khác nhau.
• Mặc dù thực tế là ClickHouse đã bắt đầu sử dụng nhiều máy chủ hơn Vertica, nhưng việc tiết kiệm phần cứng cũng được thực hiện vì Vertica sử dụng đĩa SAS khá đắt tiền. ClickHouse sử dụng SATA. Và tại sao? Bởi vì trong Vertica chèn là đồng bộ. Và việc đồng bộ hóa yêu cầu các ổ đĩa không bị chậm đi nhiều và mạng cũng không bị chậm quá nhiều, tức là một hoạt động khá tốn kém. Và phần chèn trong ClickHouse không đồng bộ. Hơn nữa, bạn luôn có thể ghi mọi thứ cục bộ, không phải trả thêm phí cho việc này, vì vậy dữ liệu có thể được chèn vào ClickHouse nhanh hơn nhiều so với Vertika, ngay cả trên những đĩa không nhanh nhất. Và việc đọc cũng giống như vậy. Đọc trên SATA, nếu chúng ở dạng RAID thì tất cả đều đủ nhanh.
• Không giới hạn theo giấy phép, tức là 3 petabyte dữ liệu trong 60 máy chủ (20 máy chủ là một bản sao) và 6 nghìn tỷ bản ghi về dữ kiện và tổng hợp. Vertica không thể mua được thứ gì như thế này.

Bây giờ tôi đang đi vào nội dung thực tế trong ví dụ này.

• Đầu tiên là một kế hoạch hiệu quả. Rất nhiều phụ thuộc vào chương trình.
• Thứ hai là tạo SQL hiệu quả.

Một truy vấn OLAP điển hình được chọn. Một số cột đi đến nhóm, một số cột đi đến các hàm tổng hợp. Có một nơi có thể được coi là một lát của khối lập phương. Toàn bộ nhóm có thể được coi như một hình chiếu. Và đó là lý do tại sao nó được gọi là phân tích dữ liệu đa biến.

Và thường thì điều này được mô hình hóa dưới dạng sơ đồ ngôi sao, khi có một thực tế trung tâm và các đặc điểm của thực tế này ở các cạnh, dọc theo các tia.

Và từ quan điểm của thiết kế vật lý, cách nó phù hợp trên bàn, họ thường tạo ra một biểu diễn chuẩn hóa. Bạn có thể không chuẩn hóa, nhưng nó tốn kém trên đĩa và không hiệu quả lắm đối với các truy vấn. Do đó, họ thường tạo một chế độ xem chuẩn hóa, tức là một bảng dữ kiện và rất nhiều bảng chiều.

Nhưng điều này không hoạt động tốt trong ClickHouse. Có hai lý do:

• Đầu tiên là do ClickHouse có các kết nối không tốt lắm, tức là có các kết nối nhưng rất tệ. Cho đến nay họ là xấu.
• Thứ hai là các bảng không được cập nhật. Thông thường trong những dấu hiệu xung quanh sơ đồ ngôi sao này, cần phải thay đổi điều gì đó. Ví dụ: tên khách hàng, tên công ty, v.v. Và nó không hoạt động.

Và có một cách thoát khỏi điều này trong ClickHouse. thậm chí hai:

• Đầu tiên là việc sử dụng từ điển. Từ điển bên ngoài là thứ giúp 99% giải quyết được vấn đề với sơ đồ sao, với các bản cập nhật, v.v.
• Thứ hai là việc sử dụng mảng. Mảng cũng giúp loại bỏ các phép nối và các vấn đề về chuẩn hóa.

• Không cần tham gia.
• Có thể cập nhật. Kể từ tháng 2018 năm XNUMX, một cơ hội không có giấy tờ đã xuất hiện (bạn sẽ không tìm thấy điều này trong tài liệu) để cập nhật một phần từ điển, tức là những mục đã thay đổi. Trong thực tế, nó giống như một cái bàn.
• Luôn ở trong bộ nhớ, do đó, việc kết hợp với từ điển sẽ hoạt động nhanh hơn so với khi đó là một bảng nằm trên đĩa và thực tế không phải là nó nằm trong bộ đệm, rất có thể là không.

• Bạn cũng không cần tham gia.
• Đây là một đại diện nhỏ gọn từ 1 đến nhiều.
• Và theo ý kiến ​​​​của tôi, mảng được tạo ra cho những người đam mê công nghệ. Đây là các chức năng và công cụ lambda.

Đây không phải là vì lời nói. Đây là một chức năng rất mạnh mẽ cho phép bạn thực hiện nhiều việc rất đơn giản và thanh lịch.

Các ví dụ điển hình giúp giải quyết mảng. Những ví dụ này rất đơn giản và khá rõ ràng:

• Tìm kiếm theo thẻ. Nếu bạn có hashtag ở đó và muốn tìm một số bài đăng bằng hashtag.
• Tìm kiếm theo cặp khóa-giá trị. Ngoài ra còn có một số thuộc tính có ý nghĩa.
• Lưu trữ danh sách các khóa mà bạn cần dịch sang thứ khác.

Tất cả những vấn đề này có thể được giải quyết mà không cần mảng. Các thẻ có thể được đặt trong một số dòng và được chọn bằng cách sử dụng biểu thức chính quy hoặc trong một bảng riêng biệt, nhưng sau đó bạn sẽ phải thực hiện các phép nối.

Nhưng trong ClickHouse, bạn không cần phải làm gì cả, chỉ cần mô tả một chuỗi chuỗi cho hashtag hoặc tạo cấu trúc lồng nhau cho hệ thống khóa-giá trị.

Cấu trúc lồng nhau có thể không phải là tên hay nhất. Đây là hai mảng có phần chung ở tên và một số đặc điểm liên quan.

Và rất dễ dàng để tìm kiếm theo thẻ. Có một chức năng has, để kiểm tra xem mảng có chứa một phần tử hay không. Mọi người, chúng tôi đã tìm thấy tất cả các mục liên quan đến hội nghị của chúng tôi.

Tìm kiếm theo subid phức tạp hơn một chút. Trước tiên chúng ta cần tìm chỉ mục của khóa, sau đó lấy phần tử có chỉ mục này và kiểm tra xem giá trị này có phải là thứ chúng ta cần hay không. Nhưng tuy nhiên rất đơn giản và nhỏ gọn.

Biểu thức chính quy mà bạn muốn viết, nếu bạn lưu trữ tất cả trong một dòng, trước hết, nó sẽ vụng về. Và thứ hai, nó hoạt động lâu hơn nhiều so với hai mảng.

Một vi dụ khac. Bạn có một mảng trong đó bạn lưu trữ ID. Và bạn có thể dịch chúng thành tên. Chức năng arrayMap. Đây là một hàm lambda điển hình. Bạn chuyển biểu thức lambda vào đó. Và cô ấy lấy giá trị tên cho mỗi ID từ từ điển.

Bạn có thể thực hiện tìm kiếm theo cách tương tự. Một hàm vị ngữ được truyền vào để kiểm tra xem các phần tử có khớp với nhau không.

Những điều này giúp đơn giản hóa mạch điện rất nhiều và giải quyết được rất nhiều vấn đề.

Nhưng vấn đề tiếp theo mà chúng tôi gặp phải và tôi muốn đề cập đến là các truy vấn hiệu quả.

• ClickHouse không có công cụ lập kế hoạch truy vấn. Tuyệt đối không.
• Tuy nhiên, những truy vấn phức tạp vẫn cần phải được lên kế hoạch. Trong trường hợp nào?
• Nếu yêu cầu có một số liên kết mà bạn gói trong các phần chọn phụ. Và thứ tự thực hiện chúng rất quan trọng.
• Và thứ hai, nếu yêu cầu được phân phối. Bởi vì trong truy vấn phân tán, chỉ phần chọn phụ trong cùng được thực thi theo cách phân tán và mọi thứ khác sẽ được gửi đến một máy chủ mà bạn đã kết nối và thực thi ở đó. Do đó, nếu bạn có các truy vấn phân tán có nhiều kết nối thì bạn cần phải chọn thứ tự.

Và ngay cả trong những trường hợp đơn giản hơn, đôi khi bạn cũng cần thực hiện công việc của bộ lập lịch và viết lại các truy vấn một chút.

Đây là một ví dụ. Ở phía bên trái là truy vấn hiển thị 5 quốc gia hàng đầu. Và tôi nghĩ nó chạy trong 2,5 giây. Và ở bên phải là yêu cầu tương tự, nhưng được viết lại một chút. Thay vì nhóm theo chuỗi, chúng tôi bắt đầu nhóm theo khóa (int). Và nó nhanh hơn. Và sau đó chúng tôi kết nối một từ điển với kết quả. Thay vì 2,5 giây, yêu cầu mất 1,5 giây. Điều này tốt.

Một ví dụ tương tự với các bộ lọc viết lại. Đây là một yêu cầu dành cho Nga. Nó chạy trong 5 giây. Nếu chúng ta viết lại nó theo cách mà chúng ta lại so sánh không phải một chuỗi mà là các số với một số bộ khóa liên quan đến Nga, thì nó sẽ nhanh hơn nhiều.

Có rất nhiều thủ thuật như vậy. Và chúng cho phép bạn tăng tốc đáng kể các truy vấn mà bạn cho rằng đang chạy nhanh hoặc ngược lại, đang chạy chậm. Chúng có thể được thực hiện nhanh hơn nữa.

• Công việc tối đa ở chế độ phân tán.
• Sắp xếp theo loại tối thiểu, như tôi đã làm theo int.
• Nếu có bất kỳ phép nối hoặc từ điển nào thì tốt hơn nên thực hiện chúng sau cùng, khi bạn đã có dữ liệu ít nhất được nhóm một phần thì thao tác nối hoặc gọi từ điển sẽ được gọi ít lần hơn và sẽ nhanh hơn.
• Thay thế bộ lọc.

Có những kỹ thuật khác, không chỉ những kỹ thuật tôi đã trình diễn. Và tất cả chúng đôi khi cho phép bạn tăng tốc đáng kể việc thực hiện các truy vấn.

Hãy chuyển sang ví dụ tiếp theo. Công ty X của Mỹ. Cô ấy đang làm gì?

Có một nhiệm vụ:

• Liên kết ngoại tuyến các giao dịch quảng cáo.
• Mô phỏng các mô hình ràng buộc khác nhau.

Kịch bản là gì?

Ví dụ: một khách truy cập bình thường truy cập trang web 20 lần một tháng từ các quảng cáo khác nhau hoặc đôi khi anh ta truy cập mà không có bất kỳ quảng cáo nào vì anh ta nhớ đến trang web này. Nhìn vào một số sản phẩm, cho vào giỏ, lấy ra khỏi giỏ. Và cuối cùng, anh ta mua thứ gì đó.

Câu hỏi hợp lý: “Ai sẽ trả tiền cho quảng cáo, nếu cần thiết?” và “Quảng cáo nào, nếu có, đã ảnh hưởng đến anh ấy?” Đó là tại sao anh ta lại mua và làm thế nào để đảm bảo rằng những người tương tự như người này cũng mua?

Để giải quyết vấn đề này, bạn cần kết nối các sự kiện xảy ra trên trang web một cách chính xác, tức là bằng cách nào đó xây dựng được sự kết nối giữa chúng. Sau đó chúng được chuyển đi phân tích cho DWH. Và dựa trên phân tích này, hãy xây dựng mô hình về người sẽ hiển thị quảng cáo gì.

Giao dịch quảng cáo là một tập hợp các sự kiện người dùng có liên quan bắt đầu bằng việc hiển thị quảng cáo, sau đó điều gì đó xảy ra, sau đó có thể là một giao dịch mua hàng và sau đó có thể có các giao dịch mua hàng trong một giao dịch mua hàng. Ví dụ: nếu đây là một ứng dụng di động hoặc một trò chơi di động thì việc cài đặt ứng dụng này thường miễn phí, nhưng nếu thực hiện điều gì khác ở đó thì có thể phải trả tiền. Và một người càng chi tiêu nhiều cho ứng dụng thì nó càng có giá trị. Nhưng để làm được điều này, bạn cần kết nối mọi thứ.

Có nhiều mô hình ràng buộc.

Phổ biến nhất là:

• Tương tác cuối cùng, trong đó tương tác là nhấp chuột hoặc hiển thị.
• Tương tác đầu tiên, tức là điều đầu tiên đưa một người đến trang web.
• Kết hợp tuyến tính - chia đều cho mọi người.
• Sự suy giảm.
• Và như thế.

Và ban đầu mọi chuyện diễn ra như thế nào? Có Runtime và Cassandra. Cassandra được sử dụng làm nơi lưu trữ giao dịch, tức là tất cả các giao dịch liên quan đều được lưu trữ trong đó. Và khi một sự kiện nào đó xảy ra trong Runtime, chẳng hạn như hiển thị một trang hoặc thứ gì đó khác, một yêu cầu sẽ được gửi tới Cassandra xem có người đó hay không. Sau đó, các giao dịch liên quan đến nó đã được nhận. Và việc ràng buộc đã được thực hiện.

Và nếu bạn may mắn khi yêu cầu chứa id giao dịch thì việc này thật dễ dàng. Nhưng thông thường bạn không gặp may mắn. Vì vậy, cần phải tìm giao dịch cuối cùng hoặc giao dịch có lần nhấp cuối cùng, v.v.

Và tất cả đều hoạt động rất tốt cho đến khi liên kết đến lần nhấp cuối cùng. Bởi vì chẳng hạn, có 10 triệu lần nhấp mỗi ngày, 300 triệu mỗi tháng, nếu bạn đặt thời hạn trong một tháng. Và vì trong Cassandra tất cả phải nằm trong bộ nhớ để hoạt động nhanh chóng, vì Thời gian chạy cần phải phản hồi nhanh nên cần khoảng 10-15 máy chủ.

Và khi họ muốn liên kết một giao dịch với màn hình, điều đó ngay lập tức trở nên không mấy thú vị. Và tại sao? Có thể thấy lượng sự kiện cần được lưu trữ gấp 30 lần. Và theo đó, bạn cần số lượng máy chủ nhiều hơn 30 lần. Và hóa ra đây là một loại hình thiên văn. Việc giữ tới 500 máy chủ để thực hiện liên kết, mặc dù thực tế là có ít máy chủ hơn đáng kể trong Thời gian chạy, là một con số sai lầm. Và họ bắt đầu nghĩ xem phải làm gì.

Và chúng tôi đã đến ClickHouse. Làm cách nào để thực hiện việc này trên ClickHouse? Thoạt nhìn, có vẻ như đây là một tập hợp các phản mẫu.

• Giao dịch ngày càng tăng, chúng tôi ngày càng gắn nhiều sự kiện vào đó, tức là nó có thể thay đổi và ClickHouse không hoạt động tốt với các đối tượng có thể thay đổi.
• Khi một khách truy cập đến với chúng tôi, chúng tôi cần truy xuất các giao dịch của anh ấy bằng khóa, theo id lượt truy cập của anh ấy. Đây cũng là một truy vấn điểm; ClickHouse không làm điều đó. Thông thường ClickHouse có những lượt quét lớn, nhưng ở đây chúng ta cần lấy một số bản ghi. Cũng là một phản mẫu.
• Ngoài ra, giao dịch ở dạng json, nhưng họ không muốn viết lại nó nên họ muốn lưu trữ json không có cấu trúc và nếu cần, hãy lấy thứ gì đó ra khỏi nó. Và đây cũng là một phản mẫu.

Tức là một tập hợp các phản mẫu.

Tuy nhiên, chúng tôi đã cố gắng tạo ra một hệ thống hoạt động rất tốt.

Thứ đã qua? ClickHouse xuất hiện, trong đó các bản ghi được chia thành các bản ghi được ném vào. Một dịch vụ được phân bổ đã xuất hiện nhận nhật ký từ ClickHouse. Sau đó, đối với mỗi mục nhập theo id lượt truy cập, tôi nhận được các giao dịch có thể chưa được xử lý và cộng với ảnh chụp nhanh, tức là các giao dịch đã được kết nối, cụ thể là kết quả của công việc trước đó. Tôi đã tạo ra logic từ chúng, chọn giao dịch chính xác và kết nối các sự kiện mới. Đã đăng nhập lại. Nhật ký quay trở lại ClickHouse, tức là đây là một hệ thống có tính chu kỳ liên tục. Và bên cạnh đó tôi đã đến DWH để phân tích ở đó.

Nó không hoạt động tốt ở dạng này. Và để ClickHouse dễ dàng hơn, khi có yêu cầu về id lượt truy cập, họ đã nhóm các yêu cầu này thành các khối 1-000 id lượt truy cập và rút ra tất cả các giao dịch cho 2-000 người. Và sau đó tất cả đã hoạt động.

Nếu nhìn vào bên trong ClickHouse, bạn sẽ thấy chỉ có 3 bảng chính phục vụ tất cả những điều này.

Bảng đầu tiên trong đó nhật ký được tải lên và nhật ký được tải lên hầu như không cần xử lý.

Bảng thứ hai. Thông qua chế độ xem cụ thể hóa, các sự kiện chưa được quy kết, tức là không liên quan, đã được trích xuất từ ​​​​các nhật ký này. Và thông qua chế độ xem cụ thể hóa, các giao dịch được rút ra khỏi nhật ký này để tạo ảnh chụp nhanh. Nghĩa là, một ảnh chụp nhanh đã được tạo với chế độ xem cụ thể hóa đặc biệt, cụ thể là trạng thái tích lũy cuối cùng của giao dịch.

Ở đây văn bản được viết bằng SQL. Tôi muốn bình luận về một số điều quan trọng trong đó.

Điều quan trọng đầu tiên là khả năng ClickHouse trích xuất các cột và trường từ json. Tức là ClickHouse có một số phương pháp để làm việc với json. Họ rất, rất nguyên thủy.

VisitParamExtractInt cho phép bạn trích xuất các thuộc tính từ json, tức là lần truy cập đầu tiên được kích hoạt. Và bằng cách này, bạn có thể lấy id giao dịch hoặc id lượt truy cập. Thời gian này.

Thứ hai, một trường vật chất phức tạp được sử dụng ở đây. Nó có nghĩa là gì? Điều này có nghĩa là bạn không thể chèn nó vào bảng, tức là nó không được chèn vào, nó được tính toán và lưu trữ khi chèn vào. Khi bạn chèn, ClickHouse sẽ thực hiện công việc cho bạn. Và những gì bạn cần sau này được lấy ra từ json.

Trong trường hợp này, chế độ xem cụ thể hóa dành cho chuỗi thô. Và bảng đầu tiên có nhật ký gần như thô được sử dụng. Và nó làm gì? Đầu tiên, nó thay đổi cách sắp xếp, tức là việc sắp xếp hiện được thực hiện theo id lượt truy cập, bởi vì chúng tôi cần nhanh chóng rút ra giao dịch của anh ấy cụ thể cho một người cụ thể.

Điều quan trọng thứ hai là index_grainarity. Nếu bạn đã thấy MergeTree thì giá trị mặc định thường là 8 index_grainarity. Nó là gì? Đây là tham số thưa thớt chỉ mục. Trong ClickHouse, chỉ mục rất thưa thớt; nó không bao giờ lập chỉ mục cho mọi bản ghi. Nó thực hiện điều này cứ sau 192. Và điều này tốt khi bạn cần tính toán nhiều dữ liệu, nhưng sẽ không tốt khi bạn cần tính toán một chút vì có quá nhiều chi phí. Và nếu chúng tôi giảm mức độ chi tiết của chỉ mục thì chúng tôi sẽ giảm chi phí chung. Bạn không thể giảm nó xuống còn một vì có thể không có đủ bộ nhớ. Chỉ mục luôn được lưu trữ trong bộ nhớ.

Và ảnh chụp nhanh sử dụng một số chức năng ClickHouse thú vị khác.

Đầu tiên là AggregatingMergeTree. Và AggregatingMergeTree lưu trữ argMax, tức là đây là trạng thái giao dịch tương ứng với dấu thời gian cuối cùng. Các giao dịch mới luôn được tạo cho khách truy cập này. Và ở trạng thái cuối cùng của giao dịch này, chúng tôi đã thêm một sự kiện và chúng tôi có một trạng thái mới. Nó lại tấn công ClickHouse. Và thông qua argMax trong chế độ xem cụ thể hóa này, chúng ta luôn có thể có được trạng thái hiện tại.

• Ràng buộc được "gỡ kết nối" khỏi Thời gian chạy.
• Lên đến 3 tỷ giao dịch mỗi tháng được lưu trữ và xử lý. Đây là mức độ lớn hơn trong Cassandra, tức là trong một hệ thống giao dịch điển hình.
• Cụm máy chủ ClickHouse 2x5. 5 máy chủ và mỗi máy chủ có một bản sao. Con số này thậm chí còn ít hơn so với trong Cassandra để thực hiện phân bổ dựa trên nhấp chuột, nhưng ở đây chúng tôi dựa trên lần hiển thị. Tức là thay vì tăng số lượng máy chủ lên 30 lần thì chúng lại bị giảm đi.

Và ví dụ cuối cùng là công ty tài chính Y, công ty đã phân tích mối tương quan giữa những thay đổi trong giá cổ phiếu.

Và nhiệm vụ là thế này:

• Có khoảng 5 cổ phiếu.
• Báo giá cứ sau 100 mili giây được biết đến.
• Dữ liệu đã được tích lũy trong hơn 10 năm. Rõ ràng, đối với một số công ty thì nhiều hơn, đối với một số công ty thì ít hơn.
• Tổng cộng có khoảng 100 tỷ hàng.

Và cần phải tính toán mối tương quan của những thay đổi.

Đây là hai cổ phiếu và báo giá của họ. Nếu cái này tăng và cái kia tăng thì đây là mối tương quan dương, tức là cái này tăng và cái kia tăng. Nếu một cái tăng lên, như ở cuối biểu đồ, và cái kia đi xuống, thì đây là mối tương quan nghịch, tức là khi cái này tăng thì cái kia đi xuống.

Bằng cách phân tích những thay đổi lẫn nhau này, người ta có thể đưa ra dự đoán trên thị trường tài chính.

Nhưng nhiệm vụ này rất khó khăn. Điều gì đang được thực hiện cho việc này? Chúng tôi có 100 tỷ bản ghi chứa: thời gian, hàng tồn kho và giá cả. Trước tiên, chúng ta cần tính toán chênh lệch chạy 100 tỷ lần so với thuật toán giá. RunningDifference là một hàm trong ClickHouse tính toán tuần tự sự khác biệt giữa hai dòng.

Và sau đó chúng ta cần tính hệ số tương quan, và hệ số tương quan phải được tính cho từng cặp. Với 5 cổ phiếu, mỗi cặp là 000 triệu. Và con số này là rất nhiều, tức là bạn cần 12,5 lần để tính hàm tương quan này.

Và trong trường hợp ai đó quên, ͞x và ͞y là chiếu tướng. mẫu kỳ vọng. Nghĩa là, bạn không chỉ cần tính căn và tổng mà còn cả các tổng khác trong các tổng này. Rất nhiều phép tính cần được thực hiện 12,5 triệu lần và chúng cũng cần được nhóm theo giờ. Và chúng ta cũng có rất nhiều giờ. Và bạn phải làm điều đó trong 60 giây. Đó là một trò đùa.

Chúng tôi phải làm được điều đó bằng cách nào đó, bởi vì tất cả đều hoạt động rất chậm trước khi ClickHouse xuất hiện.

Họ đã cố gắng tính toán điều này trên Hadoop, trên Spark, trên Greenplum. Và tất cả điều này đều rất chậm hoặc tốn kém. Nghĩa là bằng cách nào đó có thể tính toán được nó, nhưng sau đó nó rất tốn kém.

Và rồi ClickHouse đến và mọi thứ trở nên tốt đẹp hơn rất nhiều.

Hãy để tôi nhắc bạn rằng chúng tôi gặp vấn đề với vị trí dữ liệu, vì vậy không thể bản địa hóa các mối tương quan. Chúng ta không thể thêm một số dữ liệu vào máy chủ này, một số vào máy chủ khác và tính toán; chúng ta phải có tất cả dữ liệu ở mọi nơi.

Họ đã làm gì? Ban đầu, dữ liệu được bản địa hóa. Mỗi máy chủ lưu trữ dữ liệu về giá cho một nhóm cổ phiếu cụ thể. Và chúng không giao nhau. Do đó, có thể tính toán logReturn song song và độc lập; tất cả điều này xảy ra song song và phân tán.

Sau đó, chúng tôi quyết định giảm dữ liệu này mà không làm mất đi tính biểu cảm. Giảm việc sử dụng mảng, tức là trong mỗi khoảng thời gian, hãy tạo một mảng cổ phiếu và một mảng giá. Vì vậy nó chiếm ít không gian dữ liệu hơn nhiều. Và chúng thuận tiện hơn để làm việc cùng. Đây là những hoạt động gần như song song, tức là chúng ta đếm một phần song song và sau đó ghi vào máy chủ.

Điều này sau đó có thể được nhân rộng. Chữ “r” có nghĩa là chúng tôi đã sao chép dữ liệu này. Nghĩa là, chúng tôi có cùng một dữ liệu trên cả ba máy chủ - đây là các mảng.

Và sau đó, bằng cách sử dụng một tập lệnh đặc biệt, bạn có thể tạo các gói từ tập hợp 12,5 triệu mối tương quan cần được tính toán này. Tức là 2 nhiệm vụ với 500 cặp tương quan. Và nhiệm vụ này phải được tính toán trên một máy chủ ClickHouse cụ thể. Anh ta có tất cả dữ liệu vì dữ liệu giống nhau và anh ta có thể tính toán nó một cách tuần tự.

Đây là những gì nó trông giống như một lần nữa. Đầu tiên, chúng ta có tất cả dữ liệu theo cấu trúc sau: thời gian, cổ phiếu, giá cả. Sau đó, chúng tôi tính toán logReturn, tức là dữ liệu có cùng cấu trúc, chỉ thay vì giá, chúng tôi có logReturn. Sau đó, chúng được làm lại, tức là chúng tôi có thời gian và nhómArray theo các chương trình khuyến mãi và bảng giá. Nhân rộng. Và sau đó, họ tạo ra một loạt nhiệm vụ và đưa chúng vào ClickHouse để nó có thể đếm chúng. Và nó hoạt động.

Ở giai đoạn thử nghiệm khái niệm, nhiệm vụ là một nhiệm vụ phụ, tức là chúng lấy ít dữ liệu hơn. Và chỉ trên ba máy chủ.

Hai giai đoạn đầu tiên này: tính toán Log_return và gói nó thành mảng, mỗi giai đoạn mất khoảng một giờ.

Và việc tính toán mối tương quan mất khoảng 50 giờ. Nhưng 50 giờ là không đủ, vì trước đây nó đã có tác dụng với họ trong nhiều tuần. Đó là một thành công lớn. Và nếu bạn đếm thì mọi thứ đều được tính 70 lần mỗi giây trên cụm này.

Nhưng điều quan trọng nhất là hệ thống này hầu như không có tắc nghẽn, tức là nó có quy mô gần như tuyến tính. Và họ đã kiểm tra nó. Nó đã được thu nhỏ thành công.

• Kế hoạch đúng là một nửa thành công. Và kế hoạch đúng đắn là sử dụng tất cả các công nghệ ClickHouse cần thiết.
• Summing/AggregatingMergeTrees là các công nghệ cho phép bạn tổng hợp hoặc tính ảnh chụp nhanh trạng thái như một trường hợp đặc biệt. Và điều này đơn giản hóa rất nhiều thứ.
• Chế độ xem cụ thể hóa cho phép bạn vượt qua giới hạn một chỉ mục. Có thể tôi đã không nói điều này rõ ràng, nhưng khi chúng tôi tải nhật ký, các nhật ký thô nằm trong một bảng có một chỉ mục và về thuộc tính, các nhật ký nằm trong bảng, tức là cùng một dữ liệu, chỉ được lọc, nhưng chỉ mục đã được lọc hoàn toàn với người khác. Có vẻ như đó là cùng một dữ liệu nhưng cách sắp xếp khác nhau. Và Chế độ xem cụ thể hóa cho phép bạn, nếu cần, bỏ qua giới hạn ClickHouse này.
• Giảm mức độ chi tiết của chỉ mục cho các truy vấn điểm.
• Và phân phối dữ liệu một cách thông minh, cố gắng bản địa hóa dữ liệu trong máy chủ càng nhiều càng tốt. Và cố gắng đảm bảo rằng các yêu cầu cũng sử dụng bản địa hóa nhiều nhất có thể.

Và để tóm tắt bài phát biểu ngắn này, chúng ta có thể nói rằng ClickHouse hiện đã chiếm lĩnh vững chắc lãnh thổ của cả cơ sở dữ liệu thương mại và cơ sở dữ liệu nguồn mở, tức là đặc biệt dành cho phân tích. Anh ấy hoàn toàn phù hợp với cảnh quan này. Và hơn thế nữa, nó đang dần bắt đầu thay thế những người khác, bởi vì khi có ClickHouse, bạn không cần InfiniDB. Dọc có thể sớm không cần thiết nếu chúng cung cấp hỗ trợ SQL thông thường. Sử dụng nó!

-Cảm ơn vì đã báo cáo! Rất thú vị! Đã có sự so sánh nào với Apache Phoenix chưa?

-Không, tôi chưa từng nghe ai so sánh. Chúng tôi và Yandex cố gắng theo dõi tất cả các so sánh của ClickHouse với các cơ sở dữ liệu khác nhau. Bởi vì nếu đột nhiên có thứ gì đó nhanh hơn ClickHouse, thì Lesha Milovidov không thể ngủ vào ban đêm và bắt đầu tăng tốc nhanh chóng. Tôi chưa bao giờ nghe đến sự so sánh như vậy.

• (Alexey Milovidov) Apache Phoenix là một công cụ SQL dựa trên Hbase. Hbase được thiết kế chủ yếu cho kịch bản làm việc loại khóa-giá trị. Ở đó, mỗi dòng có thể có số cột tùy ý với tên tùy ý. Điều này có thể nói về các hệ thống như Hbase và Cassandra. Và chính xác là các truy vấn phân tích nặng sẽ không hoạt động bình thường đối với chúng. Hoặc bạn có thể cho rằng chúng hoạt động tốt nếu bạn chưa có kinh nghiệm với ClickHouse.

• Cảm ơn

  • Chào buổi chiều Tôi đã khá quan tâm đến chủ đề này vì tôi có một hệ thống con phân tích. Nhưng khi nhìn vào ClickHouse, tôi có cảm giác ClickHouse rất phù hợp cho việc phân tích sự kiện, có thể thay đổi được. Và nếu tôi cần phân tích nhiều dữ liệu kinh doanh bằng một loạt các bảng lớn, thì ClickHouse, theo tôi hiểu, không phù hợp lắm với tôi? Đặc biệt nếu họ thay đổi. Điều này có đúng không hoặc có ví dụ nào có thể bác bỏ điều này không?

  • Đúng rồi đó. Và điều này đúng với hầu hết các cơ sở dữ liệu phân tích chuyên ngành. Chúng được điều chỉnh dựa trên thực tế là có một hoặc một số bảng lớn có thể thay đổi và nhiều bảng nhỏ thay đổi chậm. Nghĩa là, ClickHouse không giống Oracle, nơi bạn có thể đặt mọi thứ và xây dựng một số truy vấn rất phức tạp. Để sử dụng ClickHouse hiệu quả, bạn cần xây dựng sơ đồ sao cho hoạt động tốt trong ClickHouse. Nghĩa là, tránh việc chuẩn hóa quá mức, sử dụng từ điển, cố gắng tạo ít kết nối dài hơn. Và nếu sơ đồ được xây dựng theo cách này, thì các vấn đề kinh doanh tương tự có thể được giải quyết trên ClickHouse hiệu quả hơn nhiều so với cơ sở dữ liệu quan hệ truyền thống.

Cảm ơn vì đã báo cáo! Tôi có một câu hỏi về vụ việc tài chính mới nhất. Họ đã có phân tích. Cần phải so sánh cách chúng đi lên và đi xuống. Và tôi hiểu rằng bạn đã xây dựng hệ thống dành riêng cho phân tích này? Giả sử ngày mai, nếu họ cần một số báo cáo khác về dữ liệu này, họ có cần xây dựng lại sơ đồ và tải dữ liệu không? Tức là thực hiện một số loại tiền xử lý để nhận yêu cầu?

Tất nhiên, đây là việc sử dụng ClickHouse cho một nhiệm vụ rất cụ thể. Nó có thể được giải quyết theo cách truyền thống hơn trong Hadoop. Đối với Hadoop đây là một nhiệm vụ lý tưởng. Nhưng trên Hadoop thì rất chậm. Và mục tiêu của tôi là chứng minh rằng ClickHouse có thể giải quyết các vấn đề thường được giải quyết bằng các phương pháp hoàn toàn khác, nhưng đồng thời thực hiện nó hiệu quả hơn nhiều. Điều này được thiết kế riêng cho một nhiệm vụ cụ thể. Rõ ràng là nếu có một vấn đề tương tự, thì nó có thể được giải quyết theo cách tương tự.

Rõ ràng. Bạn nói phải mất 50 giờ để xử lý. Có phải nó bắt đầu ngay từ đầu, khi bạn tải dữ liệu hoặc nhận được kết quả?

Vâng vâng.

OK cảm ơn bạn rất nhiều.

Đây là trên một cụm 3 máy chủ.

Lời chào hỏi! Cảm ơn vì đã báo cáo! Mọi thứ đều rất thú vị. Tôi không hỏi một chút về chức năng mà là về việc sử dụng ClickHouse trên quan điểm ổn định. Tức là bạn có gặp vấn đề gì không và có phải khôi phục chúng không? ClickHouse hoạt động như thế nào? Và đã bao giờ xảy ra trường hợp bản sao của bạn cũng bị hỏng chưa? Ví dụ: chúng tôi gặp sự cố với ClickHouse khi nó vẫn vượt quá giới hạn và bị rơi.

Tất nhiên, không có hệ thống lý tưởng. Và ClickHouse cũng có vấn đề của nó. Nhưng bạn đã nghe nói về việc Yandex.Metrica đã lâu không hoạt động chưa? Chắc là không. Nó đã hoạt động đáng tin cậy kể từ khoảng năm 2012-2013 trên ClickHouse. Tôi có thể nói như vậy về kinh nghiệm của tôi. Chúng tôi chưa bao giờ thất bại hoàn toàn. Một số điều có thể xảy ra một phần nhưng chúng không bao giờ đủ nghiêm trọng để ảnh hưởng nghiêm trọng đến hoạt động kinh doanh. Điều này chưa bao giờ xảy ra trước đây. ClickHouse khá đáng tin cậy và không gặp sự cố ngẫu nhiên. Bạn không cần phải lo lắng về nó. Nó không phải là một điều thô. Điều này đã được chứng minh bởi nhiều công ty.

Xin chào! Bạn nói rằng bạn cần phải suy nghĩ ngay về lược đồ dữ liệu. Nếu điều này xảy ra thì sao? Dữ liệu của tôi đang đổ vào và ra. Sáu tháng trôi qua, tôi hiểu rằng mình không thể sống như thế này, tôi cần tải lại dữ liệu lên và làm gì đó với nó.

Tất nhiên, điều này phụ thuộc vào hệ thống của bạn. Có một số cách để làm điều này gần như không ngừng nghỉ. Ví dụ: bạn có thể tạo Chế độ xem cụ thể hóa trong đó bạn có thể tạo cấu trúc dữ liệu khác nếu nó có thể được ánh xạ duy nhất. Nghĩa là, nếu nó cho phép ánh xạ bằng ClickHouse, tức là trích xuất một số thứ, thay đổi khóa chính, thay đổi phân vùng, thì bạn có thể tạo Chế độ xem cụ thể hóa. Ở đó dữ liệu cũ của bạn sẽ được ghi lại, dữ liệu mới sẽ được ghi tự động. Và sau đó chỉ cần chuyển sang sử dụng Chế độ xem cụ thể hóa, sau đó chuyển bản ghi và hủy bảng cũ. Đây là một cách nói chung không ngừng nghỉ.

Cảm ơn bạn.

Nguồn: www.habr.com