Vào tháng 4, các kỹ sư của Avito đã tập hợp các cuộc họp trực tuyến với nhà phát triển ClickHouse chính Alexey Milovidov và Kirill Shvakov, một nhà phát triển Golang từ Integros. Chúng tôi đã thảo luận về cách chúng tôi sử dụng hệ thống quản lý cơ sở dữ liệu và những khó khăn mà chúng tôi gặp phải.
Dựa trên cuộc họp, chúng tôi đã biên soạn một bài viết với các câu trả lời của các chuyên gia cho câu hỏi của chúng tôi và khán giả về sao lưu, phân chia lại dữ liệu, từ điển bên ngoài, trình điều khiển Golang và cập nhật các phiên bản ClickHouse. Nó có thể hữu ích cho các nhà phát triển đang tích cực làm việc với Yandex DBMS và quan tâm đến hiện tại cũng như tương lai của nó. Theo mặc định, câu trả lời là của Alexey Milovidov, trừ khi có ghi khác.
Hãy cẩn thận, có rất nhiều văn bản dưới vết cắt. Chúng tôi hy vọng rằng nội dung có câu hỏi sẽ giúp bạn điều hướng.
nội dung
Nếu không muốn đọc văn bản, bạn có thể xem đoạn ghi âm buổi họp mặt . Mã thời gian nằm ở bình luận đầu tiên dưới video.
ClickHouse được cập nhật liên tục, nhưng dữ liệu của chúng tôi thì không. Phải làm gì về nó?
ClickHouse được cập nhật liên tục và dữ liệu của chúng tôi, đã được tối ưu hóa trong quá trình xử lý cuối cùng, không được cập nhật và nằm trong bản sao lưu.
Giả sử chúng tôi gặp sự cố nào đó và dữ liệu bị mất. Chúng tôi đã quyết định khôi phục và hóa ra các phân vùng cũ được lưu trữ trên máy chủ dự phòng rất khác so với phiên bản ClickHouse hiện đang được sử dụng. Phải làm gì trong tình huống như vậy, và có thể không?
Trường hợp bạn khôi phục dữ liệu từ bản sao lưu ở định dạng cũ nhưng không kết nối với phiên bản mới là không thể. Chúng tôi đảm bảo rằng định dạng dữ liệu trong ClickHouse luôn tương thích ngược. Điều này quan trọng hơn nhiều so với khả năng tương thích ngược về chức năng nếu hành vi của một số chức năng hiếm khi được sử dụng đã thay đổi. Phiên bản mới của ClickHouse phải luôn có thể đọc dữ liệu được lưu trữ trên đĩa. Đây là luật.
Các phương pháp tốt nhất hiện nay để sao lưu dữ liệu từ ClickHouse là gì?
Làm cách nào để tạo bản sao lưu, có tính đến việc chúng tôi đã tối ưu hóa các hoạt động cuối cùng, cơ sở dữ liệu khổng lồ hàng terabyte và dữ liệu được cập nhật, chẳng hạn như trong ba ngày qua và sau đó không có thủ tục nào xảy ra với nó?
Chúng ta có thể đưa ra giải pháp của riêng mình và viết vào bash: thu thập các bản sao lưu này theo cách như vậy. Có lẽ không cần phải chống nạng gì cả, và xe đạp đã được phát minh từ lâu rồi?
Hãy bắt đầu với những phương pháp hay nhất. Các đồng nghiệp của tôi luôn khuyên, khi trả lời các câu hỏi về bản sao lưu, hãy nhắc họ về dịch vụ Yandex.Cloud, nơi vấn đề này đã được giải quyết. Vì vậy hãy sử dụng nó nếu có thể.
Không có giải pháp sao lưu hoàn chỉnh, XNUMX% được tích hợp vào ClickHouse. Có một số khoảng trống có thể được sử dụng. Để có được giải pháp hoàn chỉnh, bạn sẽ phải mày mò thủ công một chút hoặc tạo các trình bao bọc dưới dạng tập lệnh.
Tôi sẽ bắt đầu với những giải pháp đơn giản nhất và kết thúc bằng những giải pháp phức tạp nhất, tùy thuộc vào khối lượng dữ liệu và kích thước của cụm. Cụm càng lớn thì giải pháp càng trở nên phức tạp.
Nếu bảng có dữ liệu chỉ chiếm vài gigabyte, việc sao lưu có thể được thực hiện như sau:
- Lưu định nghĩa bảng, tức là siêu dữ liệu - hiển thị tạo bảng.
- Tạo kết xuất bằng ứng dụng khách ClickHouse - chọn * khỏi bàn nộp. Theo mặc định, bạn sẽ nhận được một tệp ở định dạng TabSeparated. Nếu muốn hiệu quả hơn, bạn có thể thực hiện ở định dạng Gốc.
Nếu lượng dữ liệu lớn hơn thì việc sao lưu sẽ tốn nhiều thời gian hơn và nhiều dung lượng hơn. Đây được gọi là bản sao lưu logic; nó không bị ràng buộc với định dạng dữ liệu ClickHouse. Nếu đúng như vậy thì biện pháp cuối cùng là bạn có thể sao lưu và tải nó lên MySQL để khôi phục.
Đối với các trường hợp nâng cao hơn, ClickHouse có khả năng tích hợp sẵn để tạo ảnh chụp nhanh các phân vùng trong hệ thống tệp cục bộ. Tính năng này có sẵn theo yêu cầu thay đổi phân vùng đóng băng bảng. Hoặc đơn giản thay đổi bảng đóng băng - đây là ảnh chụp nhanh của toàn bộ bảng.
Ảnh chụp nhanh sẽ được tạo nhất quán cho một bảng trên một phân đoạn, nghĩa là không thể tạo ảnh chụp nhanh nhất quán cho toàn bộ cụm theo cách này. Nhưng đối với hầu hết các tác vụ thì không có nhu cầu như vậy và chỉ cần thực hiện yêu cầu trên mỗi phân đoạn và có được ảnh chụp nhanh nhất quán là đủ. Nó được tạo dưới dạng liên kết cứng và do đó không chiếm thêm dung lượng. Tiếp theo, bạn sao chép ảnh chụp nhanh này vào máy chủ dự phòng hoặc vào bộ lưu trữ mà bạn sử dụng để sao lưu.
Khôi phục bản sao lưu như vậy là khá dễ dàng. Đầu tiên, tạo bảng bằng cách sử dụng các định nghĩa bảng hiện có. Tiếp theo, sao chép ảnh chụp nhanh đã lưu của các phân vùng vào Directory-Detached cho các bảng này và chạy truy vấn đính kèm phân vùng. Giải pháp này khá phù hợp với khối lượng dữ liệu nghiêm trọng nhất.
Đôi khi bạn cần thứ gì đó thậm chí còn thú vị hơn - trong trường hợp bạn có hàng chục hoặc thậm chí hàng trăm terabyte trên mỗi máy chủ và hàng trăm máy chủ. Có một giải pháp ở đây mà tôi đã học được từ các đồng nghiệp của mình từ Yandex.Metrica. Tôi sẽ không giới thiệu nó cho mọi người - hãy đọc nó và tự quyết định xem nó có phù hợp hay không.
Trước tiên, bạn cần tạo một số máy chủ có kệ đĩa lớn. Tiếp theo, trên các máy chủ này, hãy nâng cấp một số máy chủ ClickHouse và định cấu hình chúng để chúng hoạt động như một bản sao khác cho cùng một phân đoạn. Và sau đó sử dụng hệ thống tệp hoặc một số công cụ trên các máy chủ này cho phép bạn tạo ảnh chụp nhanh. Có hai lựa chọn ở đây. Tùy chọn đầu tiên là ảnh chụp nhanh LVM, tùy chọn thứ hai là ZFS trên Linux.
Sau đó, mỗi ngày bạn cần tạo một ảnh chụp nhanh, nó sẽ nằm và chiếm một khoảng trống. Đương nhiên, nếu dữ liệu thay đổi, dung lượng sẽ tăng theo thời gian. Ảnh chụp nhanh này có thể được lấy ra bất cứ lúc nào và dữ liệu được khôi phục, một giải pháp kỳ lạ như vậy. Ngoài ra, chúng ta cũng cần hạn chế những bản sao này trong config để chúng không cố gắng trở thành người dẫn đầu.
Liệu có thể tổ chức độ trễ có kiểm soát của các bản sao trong trục không?
Năm nay bạn dự định làm trục trong ClickHouse. Liệu có thể tổ chức độ trễ có kiểm soát của các bản sao trong đó không? Chúng tôi muốn sử dụng nó để bảo vệ bản thân khỏi những tình huống tiêu cực với những thay đổi và những thay đổi khác.
Có thể thực hiện một số kiểu khôi phục để thay đổi không? Ví dụ, trong một trục hiện có, hãy nói rằng cho đến thời điểm này bạn áp dụng các thay đổi và từ thời điểm này bạn ngừng áp dụng các thay đổi?
Nếu một lệnh đến cụm của chúng tôi và phá vỡ nó, thì chúng tôi có một bản sao có điều kiện với độ trễ một giờ, nơi chúng tôi có thể nói rằng hãy sử dụng nó vào lúc này, nhưng chúng tôi sẽ không áp dụng các thay đổi cho nó trong mười phút qua?
Đầu tiên, về độ trễ được kiểm soát của bản sao. Có một yêu cầu như vậy từ người dùng và chúng tôi đã tạo một vấn đề trên Github với yêu cầu: “Nếu ai đó cần cái này, hãy thích nó, hãy đặt một trái tim.” Không có ai giao hàng và vấn đề đã bị đóng lại. Tuy nhiên, bạn đã có thể có được cơ hội này bằng cách thiết lập ClickHouse. Đúng, chỉ bắt đầu từ phiên bản 20.3.
ClickHouse liên tục thực hiện việc hợp nhất dữ liệu trong nền. Khi quá trình hợp nhất hoàn tất, một tập hợp dữ liệu nhất định sẽ được thay thế bằng phần lớn hơn. Đồng thời, các phần dữ liệu đã có trước đó vẫn tiếp tục tồn tại trên đĩa trong một thời gian.
Đầu tiên, chúng tiếp tục được lưu trữ miễn là có các truy vấn chọn lọc sử dụng chúng để cung cấp hoạt động không bị chặn. Các truy vấn chọn lọc có thể dễ dàng được đọc từ các đoạn cũ.
Thứ hai, cũng có một ngưỡng thời gian - những phần dữ liệu cũ nằm trên đĩa trong tám phút. Tám phút này có thể được tùy chỉnh và thậm chí biến thành một ngày. Điều này sẽ tiêu tốn dung lượng ổ đĩa: tùy thuộc vào luồng dữ liệu, hóa ra vào ngày cuối cùng, dữ liệu sẽ không chỉ tăng gấp đôi mà còn có thể tăng gấp năm lần. Nhưng nếu có vấn đề nghiêm trọng, bạn có thể dừng máy chủ ClickHouse và sắp xếp mọi thứ.
Bây giờ câu hỏi đặt ra là làm thế nào điều này bảo vệ chống lại những thay đổi. Bạn nên xem xét kỹ hơn ở đây vì trong các phiên bản cũ hơn của ClickHouse, công cụ thay đổi hoạt động theo cách đơn giản là thay đổi trực tiếp các phần. Có một phần dữ liệu với một số tệp và chúng tôi làm như vậy, chẳng hạn: thay đổi cột thả. Sau đó, cột này sẽ bị xóa khỏi tất cả các khối.
Nhưng bắt đầu từ phiên bản 20.3, cơ chế thay đổi đã được thay đổi hoàn toàn và giờ đây các phần dữ liệu luôn không thể thay đổi. Chúng hoàn toàn không thay đổi - các thay đổi hiện hoạt động gần giống như cách hợp nhất. Thay vì thay thế một phần ngay tại chỗ, chúng tôi tạo ra một phần mới. Trong đoạn mới, các tệp không thay đổi sẽ trở thành liên kết cứng và nếu chúng ta xóa một cột, cột đó sẽ bị thiếu trong đoạn mới. Phần cũ sẽ bị xóa theo mặc định sau tám phút và tại đây bạn có thể điều chỉnh các cài đặt được đề cập ở trên.
Điều tương tự cũng áp dụng cho những thay đổi như đột biến. Khi bạn làm thay đổi xóa hoặc thay đổi cập nhật, nó không thay đổi mảnh mà tạo ra một mảnh mới. Và sau đó xóa cái cũ.
Điều gì xảy ra nếu cấu trúc bảng đã thay đổi?
Làm cách nào để khôi phục bản sao lưu được tạo bằng sơ đồ cũ? Và câu hỏi thứ hai là về trường hợp ảnh chụp nhanh và các công cụ hệ thống tệp. Btrfs ở đây có tốt thay vì ZFS trên Linux LVM không?
Nếu bạn làm đính kèm phân vùng phân vùng có cấu trúc khác thì ClickHouse sẽ cho bạn biết rằng điều này là không thể. Đây là giải pháp. Đầu tiên là tạo một bảng tạm thời thuộc loại MergeTree với cấu trúc cũ, đính kèm dữ liệu vào đó bằng cách sử dụng Attach và thực hiện một truy vấn thay đổi. Sau đó, bạn có thể sao chép hoặc chuyển dữ liệu này và đính kèm lại hoặc sử dụng yêu cầu thay đổi phân vùng di chuyển bảng.
Bây giờ câu hỏi thứ hai là liệu Btrfs có thể được sử dụng hay không. Để bắt đầu, nếu bạn có LVM, thì ảnh chụp nhanh LVM là đủ và hệ thống tệp có thể là ext4, điều đó không thành vấn đề. Với Btrts, mọi thứ đều phụ thuộc vào kinh nghiệm sử dụng của bạn. Đây là một hệ thống tệp hoàn thiện, nhưng vẫn còn một số nghi ngờ về cách mọi thứ sẽ diễn ra trong thực tế trong một kịch bản cụ thể. Tôi không khuyên bạn nên sử dụng tính năng này trừ khi bạn có Btrfs đang được sản xuất.
Các phương pháp hay nhất hiện nay về phân chia lại dữ liệu là gì?
Vấn đề chia sẻ lại rất phức tạp và nhiều mặt. Có một số câu trả lời có thể có ở đây. Bạn có thể nhìn từ một phía và nói điều này - ClickHouse không có tính năng chia sẻ lại tích hợp. Nhưng tôi sợ câu trả lời này sẽ không phù hợp với bất cứ ai. Do đó, bạn có thể đi từ phía bên kia và nói rằng ClickHouse có nhiều cách để phân chia lại dữ liệu.
Nếu cụm hết dung lượng hoặc không thể xử lý tải, bạn thêm máy chủ mới. Nhưng những máy chủ này mặc định trống, không có dữ liệu trên đó, không có tải. Bạn cần sắp xếp lại dữ liệu để dữ liệu được trải đều trên cụm mới, lớn hơn.
Cách đầu tiên có thể thực hiện là sao chép một phần phân vùng sang máy chủ mới bằng cách sử dụng yêu cầu thay đổi phân vùng tìm nạp bảng. Ví dụ: bạn có phân vùng theo tháng và bạn lấy tháng đầu tiên của năm 2017 và sao chép nó sang máy chủ mới, sau đó sao chép tháng thứ ba sang một số máy chủ mới khác. Và bạn làm điều này cho đến khi nó trở nên đồng đều hơn hoặc ít hơn.
Việc chuyển giao chỉ có thể được thực hiện đối với những phân vùng không thay đổi trong quá trình ghi. Đối với các phân vùng mới, việc ghi sẽ phải bị tắt vì quá trình truyền của chúng không mang tính nguyên tử. Nếu không, bạn sẽ có những bản sao hoặc khoảng trống trong dữ liệu. Tuy nhiên, phương pháp này rất thực tế và hoạt động khá hiệu quả. Các phân vùng nén làm sẵn được truyền qua mạng, tức là dữ liệu không bị nén hoặc mã hóa lại.
Phương pháp này có một nhược điểm và nó phụ thuộc vào sơ đồ sharding, liệu bạn có cam kết với sơ đồ sharding này hay không, bạn có khóa sharding nào. Trong ví dụ của bạn về trường hợp có số liệu, khóa sharding là hàm băm của đường dẫn. Khi bạn chọn một bảng Phân phối, bảng đó sẽ đi tới tất cả các phân đoạn trong cụm cùng một lúc và lấy dữ liệu từ đó.
Điều này có nghĩa là việc dữ liệu nào nằm trên phân đoạn nào thực sự không quan trọng đối với bạn. Điều chính là dữ liệu dọc theo một đường dẫn sẽ kết thúc trên một phân đoạn, nhưng phân đoạn nào không quan trọng. Trong trường hợp này, việc chuyển các phân vùng tạo sẵn là hoàn hảo, bởi vì với các truy vấn chọn lọc, bạn cũng sẽ nhận được dữ liệu đầy đủ - cho dù trước khi phân chia lại hay sau đó, sơ đồ này không thực sự quan trọng.
Nhưng có những trường hợp phức tạp hơn. Nếu ở cấp logic ứng dụng, bạn dựa vào sơ đồ phân đoạn đặc biệt, thì ứng dụng khách này nằm trên phân đoạn đó và yêu cầu có thể được gửi trực tiếp đến đó chứ không phải đến bảng Phân phối. Hoặc bạn đang sử dụng phiên bản ClickHouse khá mới và đã bật cài đặt tối ưu hóa bỏ qua các phân đoạn không sử dụng. Trong trường hợp này, trong quá trình truy vấn chọn, biểu thức trong phần vị trí sẽ được phân tích và tính toán phân đoạn nào cần được sử dụng theo sơ đồ phân đoạn. Điều này hoạt động với điều kiện là dữ liệu được phân vùng chính xác theo sơ đồ phân chia này. Nếu bạn sắp xếp lại chúng theo cách thủ công, sự tương ứng có thể thay đổi.
Vì vậy, đây là phương pháp số một. Và tôi đang chờ câu trả lời của bạn, liệu phương pháp này có phù hợp hay không, hay hãy tiếp tục.
Vladimir Kolobaev, quản trị viên hệ thống chính tại Avito: Alexey, phương pháp mà bạn đề cập không hiệu quả lắm khi bạn cần dàn tải, kể cả việc đọc. Chúng tôi có thể lấy một phân vùng hàng tháng và có thể đưa tháng trước đó sang một nút khác, nhưng khi có yêu cầu về dữ liệu này, chúng tôi sẽ chỉ tải nó. Nhưng chúng tôi muốn tải toàn bộ cụm, vì nếu không, trong một thời gian, toàn bộ tải đọc sẽ được xử lý bởi hai phân đoạn.
Alexey Milovidov: Câu trả lời ở đây thật kỳ lạ - vâng, nó tệ, nhưng nó có thể hiệu quả. Tôi sẽ giải thích chính xác như thế nào. Bạn nên xem xét kịch bản tải đằng sau dữ liệu của mình. Nếu đây là dữ liệu giám sát thì chúng ta gần như chắc chắn có thể nói rằng phần lớn các yêu cầu là dữ liệu mới.
Bạn đã cài đặt máy chủ mới, di chuyển các phân vùng cũ nhưng cũng thay đổi cách ghi dữ liệu mới. Và dữ liệu mới sẽ được trải rộng khắp cụm. Như vậy, chỉ sau XNUMX phút, các yêu cầu trong XNUMX phút cuối cùng sẽ tải đồng đều trên cụm; sau một ngày, các yêu cầu trong XNUMX giờ sẽ tải đồng đều trên cụm. Và rất tiếc, các yêu cầu của tháng trước sẽ chỉ được chuyển đến một phần của máy chủ cụm.
Nhưng thường thì bạn sẽ không có yêu cầu cụ thể cho tháng 2019 năm 2019. Rất có thể, nếu các yêu cầu được chuyển sang năm 2019, thì chúng sẽ dành cho cả năm XNUMX - trong một khoảng thời gian lớn chứ không phải trong một phạm vi nhỏ nào đó. Và những yêu cầu như vậy cũng sẽ có thể tải cụm đồng đều. Nhưng nói chung, nhận xét của bạn hoàn toàn chính xác rằng đây là một giải pháp đặc biệt không phân bổ dữ liệu hoàn toàn đồng đều.
Tôi có thêm một vài điểm để trả lời câu hỏi. Một trong số đó là về cách thiết kế sơ đồ phân mảnh ban đầu để việc phân chia lại sẽ ít gây khó khăn hơn. Không phải lúc nào cũng khả thi.
Ví dụ: bạn có dữ liệu giám sát. Dữ liệu giám sát đang phát triển vì ba lý do. Đầu tiên là việc tích lũy dữ liệu lịch sử. Thứ hai là tăng trưởng lưu lượng truy cập. Và thứ ba là sự gia tăng số lượng đối tượng phải giám sát. Có những dịch vụ vi mô và số liệu mới cần được lưu lại.
Có thể trong số này, mức tăng lớn nhất có liên quan đến lý do thứ ba - việc tăng cường sử dụng biện pháp giám sát. Và trong trường hợp này, cần xem xét bản chất của tải, các truy vấn chọn chính là gì. Các truy vấn chọn cơ bản rất có thể sẽ dựa trên một số tập hợp con số liệu.
Ví dụ: việc sử dụng CPU trên một số máy chủ của một số dịch vụ. Hóa ra có một tập hợp con khóa nhất định để bạn lấy dữ liệu này. Và bản thân yêu cầu đối với dữ liệu này rất có thể khá đơn giản và được hoàn thành sau hàng chục mili giây. Được sử dụng để giám sát các dịch vụ và bảng điều khiển. Tôi hy vọng tôi hiểu điều này một cách chính xác.
Vladimir Kolobaev: Thực tế là chúng ta thường dựa vào dữ liệu lịch sử vì chúng ta so sánh tình hình hiện tại với tình hình lịch sử trong thời gian thực. Và điều quan trọng là chúng tôi phải có quyền truy cập nhanh vào một lượng lớn dữ liệu và ClickHouse đã làm rất tốt điều này.
Bạn hoàn toàn đúng, chúng tôi xử lý hầu hết các yêu cầu đọc trong ngày qua, giống như bất kỳ hệ thống giám sát nào. Nhưng đồng thời, tải trọng dữ liệu lịch sử cũng khá lớn. Về cơ bản, nó đến từ một hệ thống cảnh báo cứ ba mươi giây một lần và nói với ClickHouse: “Hãy cung cấp cho tôi dữ liệu trong sáu tuần qua. Bây giờ hãy xây dựng cho tôi một số loại đường trung bình động từ chúng và hãy so sánh giá trị hiện tại với giá trị lịch sử.”
Tôi muốn nói rằng đối với những yêu cầu rất gần đây, chúng tôi có một bảng nhỏ khác, trong đó chúng tôi chỉ lưu trữ dữ liệu của hai ngày và các yêu cầu chính sẽ được đưa vào đó. Chúng tôi chỉ gửi các truy vấn lịch sử lớn tới bảng phân đoạn lớn.
Alexey Milovidov: Thật không may, hóa ra nó không phù hợp với trường hợp của bạn, nhưng tôi sẽ mô tả cho bạn về hai sơ đồ phân mảnh xấu và phức tạp không cần sử dụng nhưng lại được sử dụng trong dịch vụ của bạn bè tôi.
Có một cụm chính chứa các sự kiện Yandex.Metrica. Sự kiện là lượt xem trang, số lần nhấp và chuyển đổi. Hầu hết các yêu cầu đều chuyển đến một trang web cụ thể. Bạn mở dịch vụ Yandex.Metrica, bạn có một trang web - avito.ru, đi tới báo cáo và một yêu cầu được đưa ra cho trang web của bạn.
Nhưng có những yêu cầu khác - mang tính phân tích và toàn cầu - được đưa ra bởi các nhà phân tích nội bộ. Để đề phòng, tôi lưu ý rằng các nhà phân tích nội bộ chỉ đưa ra yêu cầu đối với các dịch vụ Yandex. Tuy nhiên, ngay cả các dịch vụ Yandex cũng chiếm một phần đáng kể trong tất cả dữ liệu. Đây là những yêu cầu không dành cho các bộ đếm cụ thể mà để lọc rộng hơn.
Làm cách nào để sắp xếp dữ liệu theo cách mà mọi thứ đều hoạt động hiệu quả cho một bộ đếm và cả các truy vấn toàn cục? Một khó khăn khác là số lượng yêu cầu trong ClickHouse cho cụm Số liệu là vài nghìn mỗi giây. Đồng thời, một máy chủ ClickHouse không thể xử lý các yêu cầu không tầm thường, chẳng hạn như vài nghìn mỗi giây.
Kích thước cụm là khoảng sáu trăm máy chủ. Nếu bạn chỉ đơn giản kéo một bảng Phân phối qua cụm này và gửi hàng nghìn yêu cầu đến đó, điều đó sẽ còn tệ hơn việc gửi chúng đến một máy chủ. Mặt khác, tùy chọn dữ liệu được trải đều và chúng tôi truy cập và yêu cầu từ tất cả các máy chủ sẽ ngay lập tức bị loại bỏ.
Có một lựa chọn hoàn toàn ngược lại. Hãy tưởng tượng nếu chúng ta phân chia dữ liệu trên các trang web và yêu cầu cho một trang web sẽ chuyển đến một phân đoạn. Giờ đây, cụm sẽ có thể xử lý mười nghìn yêu cầu mỗi giây, nhưng trên một phân đoạn, bất kỳ yêu cầu nào cũng sẽ hoạt động quá chậm. Nó sẽ không còn mở rộng quy mô về mặt thông lượng. Đặc biệt nếu đây là trang avito.ru. Tôi sẽ không tiết lộ bí mật nếu nói rằng Avito là một trong những trang được truy cập nhiều nhất trên RuNet. Và việc xử lý nó trên một mảnh sẽ là một điều điên rồ.
Do đó, sơ đồ sharding được thiết kế theo cách tinh vi hơn. Toàn bộ cụm được chia thành một số cụm mà chúng tôi gọi là các lớp. Mỗi cụm chứa từ vài chục đến vài chục mảnh. Tổng cộng có XNUMX cụm như vậy.
Làm thế nào tất cả điều này có quy mô? Số lượng cụm không thay đổi - như cách đây vài năm là XNUMX cụm, đến nay vẫn như vậy. Nhưng trong mỗi phân đoạn đó, chúng tôi tăng dần số lượng phân đoạn khi tích lũy dữ liệu. Và sơ đồ sharding nói chung là như thế này: các cụm này được chia thành các trang web và để hiểu trang web nào nằm trên cụm nào, một cơ sở dữ liệu riêng biệt trong MySQL sẽ được sử dụng. Một trang web - trên một cụm. Và bên trong nó, quá trình phân chia diễn ra theo ID khách truy cập.
Khi ghi lại, chúng tôi chia chúng cho phần còn lại của phép chia ID khách truy cập. Nhưng khi thêm một phân đoạn mới, sơ đồ phân đoạn sẽ thay đổi; chúng tôi tiếp tục chia nhưng với phần còn lại của phép chia cho một số khác. Điều này có nghĩa là một khách truy cập đã được định vị trên một số máy chủ và bạn không thể dựa vào điều này. Điều này được thực hiện chỉ để đảm bảo rằng dữ liệu được nén tốt hơn. Và khi thực hiện yêu cầu, chúng ta đi tới bảng Phân phối, bảng này xem xét cụm và truy cập hàng chục máy chủ. Đây đúng là một kế hoạch ngu ngốc.
Nhưng câu chuyện của tôi sẽ không đầy đủ nếu tôi không nói rằng chúng tôi đã từ bỏ kế hoạch này. Trong sơ đồ mới, chúng tôi đã thay đổi mọi thứ và sao chép tất cả dữ liệu bằng clickhouse-copier.
Trong sơ đồ mới, tất cả các trang web được chia thành hai loại - lớn và nhỏ. Tôi không biết ngưỡng được chọn như thế nào, nhưng kết quả là các trang web lớn được ghi lại trên một cụm, trong đó có 120 phân đoạn với ba bản sao mỗi phân đoạn - tức là 360 máy chủ. Và sơ đồ phân mảnh sao cho mọi yêu cầu đều được chuyển đến tất cả các phân đoạn cùng một lúc. Nếu bây giờ bạn mở bất kỳ trang báo cáo nào về avito.ru trong Yandex.Metrica, yêu cầu sẽ được gửi tới 120 máy chủ. Có rất ít trang web lớn trong RuNet. Và yêu cầu không phải một nghìn mỗi giây mà thậm chí còn ít hơn một trăm. Tất cả điều này được lặng lẽ nhai lại bởi bảng Phân phối, mỗi bảng xử lý với 120 máy chủ.
Và cụm thứ hai dành cho các trang web nhỏ. Đây là sơ đồ phân mảnh dựa trên ID trang web và mỗi yêu cầu sẽ chuyển đến chính xác một phân đoạn.
ClickHouse có tiện ích máy photocopy clickhouse. Bạn có thể kể cho chúng tôi nghe về cô ấy không?
Tôi sẽ nói ngay rằng giải pháp này cồng kềnh hơn và có phần kém hiệu quả hơn. Ưu điểm là nó bôi nhọ dữ liệu hoàn toàn theo mẫu bạn chỉ định. Nhưng nhược điểm của tiện ích là nó không chia sẻ lại được gì cả. Nó sao chép dữ liệu từ lược đồ cụm này sang lược đồ cụm khác.
Điều này có nghĩa là để nó hoạt động, bạn phải có hai cụm. Chúng có thể được đặt trên cùng một máy chủ, tuy nhiên, dữ liệu sẽ không được di chuyển dần dần mà sẽ được sao chép.
Ví dụ, trước đây có bốn máy chủ, bây giờ có tám máy chủ. Bạn tạo một bảng Phân phối mới trên tất cả các máy chủ, các bảng cục bộ mới và khởi chạy clickhouse-copier, chỉ ra trong đó sơ đồ công việc mà nó nên đọc từ đó, chấp nhận sơ đồ phân mảnh mới và chuyển dữ liệu đến đó. Và trên các máy chủ cũ, bạn sẽ cần dung lượng gấp rưỡi so với hiện tại, vì dữ liệu cũ phải được giữ nguyên trên chúng và một nửa dữ liệu cũ sẽ xuất hiện trên chúng. Nếu bạn đã nghĩ trước rằng dữ liệu cần được phân chia lại và có dung lượng trống thì phương pháp này sẽ phù hợp.
Clickhouse-Copier hoạt động bên trong như thế nào? Nó chia tất cả công việc thành một tập hợp các tác vụ để xử lý một phân vùng của một bảng trên một phân đoạn. Tất cả các tác vụ này có thể được thực thi song song và clickhouse-copier có thể chạy trên các máy khác nhau trong nhiều trường hợp, nhưng tác dụng của nó đối với một phân vùng không gì khác hơn là chọn chèn. Dữ liệu được đọc, giải nén, phân vùng lại, sau đó được nén lại, ghi ở đâu đó và sắp xếp lại. Đây là một quyết định khó khăn hơn.
Bạn đã có một thứ thí điểm được gọi là chia sẻ lại. Chuyện gì với cô ấy vậy?
Trở lại năm 2017, bạn đã có một thử nghiệm gọi là phân chia lại. Thậm chí còn có một tùy chọn trong ClickHouse. Theo tôi hiểu thì nó đã không cất cánh. Bạn có thể cho tôi biết tại sao điều này xảy ra? Nó có vẻ rất liên quan.
Toàn bộ vấn đề là nếu cần phải phân chia lại dữ liệu tại chỗ thì cần phải có sự đồng bộ hóa rất phức tạp để thực hiện việc này một cách nguyên tử. Khi chúng tôi bắt đầu xem xét cách thức hoạt động của quá trình đồng bộ hóa này, chúng tôi thấy rõ rằng có những vấn đề cơ bản. Và những vấn đề cơ bản này không chỉ mang tính lý thuyết mà ngay lập tức bắt đầu bộc lộ trong thực tế dưới dạng một điều gì đó có thể giải thích rất đơn giản - không có gì hiệu quả.
Có thể hợp nhất tất cả các phần dữ liệu lại với nhau trước khi chuyển nó sang đĩa chậm không?
Câu hỏi về TTL khi chuyển sang tùy chọn đĩa chậm trong bối cảnh hợp nhất. Có cách nào khác ngoài cron để hợp nhất tất cả các phần thành một trước khi chuyển chúng sang đĩa chậm không?
Câu trả lời cho câu hỏi là bằng cách nào đó có thể tự động dán tất cả các mảnh lại thành một trước khi chuyển chúng - không. Tôi không nghĩ điều này là cần thiết. Bạn không cần phải hợp nhất tất cả các phần thành một mà chỉ cần tin tưởng vào thực tế là chúng sẽ tự động được chuyển sang đĩa chậm.
Chúng tôi có hai tiêu chí cho quy tắc chuyển nhượng. Cái đầu tiên là như nó được lấp đầy. Nếu tầng lưu trữ hiện tại có ít hơn một tỷ lệ phần trăm dung lượng trống nhất định, chúng tôi sẽ chọn một đoạn và chuyển nó sang bộ nhớ chậm hơn. Hay đúng hơn, không phải chậm hơn mà là chậm hơn - khi bạn định cấu hình.
Tiêu chí thứ hai là kích thước. Đó là về việc di chuyển những mảnh lớn. Bạn có thể điều chỉnh ngưỡng theo dung lượng trống trên đĩa nhanh và dữ liệu sẽ được truyền tự động.
Làm cách nào để chuyển sang phiên bản mới của ClickHouse nếu không có cách nào để kiểm tra trước tính tương thích?
Chủ đề này được thảo luận thường xuyên có tính đến các phiên bản khác nhau, và vẫn còn. Mức độ an toàn khi nâng cấp từ phiên bản 19.11 lên 19.16 và, ví dụ: từ 19.16 lên 20.3. Cách tốt nhất để di chuyển sang phiên bản mới mà không thể kiểm tra trước khả năng tương thích trong hộp cát là gì?
Có một số quy tắc “vàng” ở đây. Đầu tiên - . Nó lớn nhưng có những đoạn riêng biệt về những thay đổi không tương thích ngược. Đừng coi những điểm này như một lá cờ đỏ. Đây thường là những điểm không tương thích nhỏ liên quan đến một số chức năng biên mà rất có thể bạn không sử dụng.
Thứ hai, nếu không có cách nào để kiểm tra tính tương thích trong hộp cát và bạn muốn cập nhật ngay trong quá trình sản xuất, thì khuyến nghị là bạn không cần phải thực hiện việc này. Đầu tiên hãy tạo một hộp cát và thử nghiệm. Nếu không có môi trường thử nghiệm thì rất có thể bạn không có một công ty quá lớn, điều đó có nghĩa là bạn có thể sao chép một số dữ liệu vào máy tính xách tay của mình và đảm bảo rằng mọi thứ hoạt động chính xác trên đó. Bạn thậm chí có thể tạo một số bản sao cục bộ trên máy của mình. Hoặc bạn có thể chọn một phiên bản mới ở đâu đó gần đó và tải một số dữ liệu lên đó - nghĩa là tạo một môi trường thử nghiệm ngẫu hứng.
Một quy tắc khác là không cập nhật trong một tuần sau khi phát hành phiên bản do phát hiện lỗi trong quá trình sản xuất và các bản sửa lỗi nhanh sau đó. Cùng tìm hiểu cách đánh số các phiên bản ClickHouse để không bị nhầm lẫn nhé.
Có phiên bản 20.3.4. Con số 20 biểu thị năm sản xuất - 2020. Xét về bên trong có gì thì điều này không quan trọng nên chúng ta sẽ không chú ý đến nó. Tiếp theo - 20.3. Chúng tôi tăng số thứ hai - trong trường hợp này là 3 - mỗi khi chúng tôi phát hành bản phát hành với một số chức năng mới. Nếu chúng ta muốn thêm một số tính năng vào ClickHouse thì chúng ta phải tăng con số này lên. Tức là ở phiên bản 20.4 ClickHouse sẽ hoạt động tốt hơn nữa. Chữ số thứ ba là 20.3.4. Ở đây 4 là số bản phát hành bản vá mà chúng tôi không thêm tính năng mới nhưng đã sửa một số lỗi. Và 4 có nghĩa là chúng tôi đã làm điều đó bốn lần.
Đừng nghĩ rằng đây là một điều gì đó khủng khiếp. Thông thường người dùng có thể cài đặt phiên bản mới nhất và nó sẽ hoạt động mà không gặp vấn đề gì về thời gian hoạt động mỗi năm. Nhưng hãy tưởng tượng rằng trong một số chức năng xử lý ảnh bitmap do các đồng chí Trung Quốc của chúng ta thêm vào, máy chủ gặp sự cố khi truyền đối số không chính xác. Chúng tôi có trách nhiệm phải khắc phục điều này. Chúng tôi sẽ phát hành phiên bản vá lỗi mới và ClickHouse sẽ trở nên ổn định hơn.
Nếu bạn có ClickHouse đang chạy trong sản xuất và một phiên bản mới của ClickHouse xuất hiện với các tính năng bổ sung - ví dụ: 20.4.1 là phiên bản đầu tiên, đừng vội đưa nó vào sản xuất ngay ngày đầu tiên. Tại sao nó lại cần thiết? Nếu bạn chưa sử dụng ClickHouse thì bạn có thể cài đặt nó và rất có thể mọi thứ sẽ ổn. Nhưng nếu ClickHouse đã hoạt động ổn định thì hãy theo dõi các bản vá và cập nhật để xem chúng tôi đang khắc phục những vấn đề gì.
Kirill Shvakov: Tôi muốn nói thêm một chút về môi trường thử nghiệm. Mọi người đều rất sợ môi trường thử nghiệm và vì lý do nào đó họ tin rằng nếu bạn có cụm ClickHouse rất lớn thì môi trường thử nghiệm sẽ nhỏ hơn không ít hoặc ít nhất mười lần. Thực ra nó không hẳn là vậy.
Tôi có thể nói với bạn từ ví dụ của riêng tôi. Tôi có một dự án và có ClickHouse. Môi trường thử nghiệm của chúng tôi chỉ dành cho anh ấy - đây là một máy ảo nhỏ ở Hetzner với giá XNUMX euro, nơi mọi thứ đều được triển khai hoàn toàn. Để làm được điều này, chúng tôi có tính năng tự động hóa hoàn toàn trong Ansible và do đó, về nguyên tắc, không có gì khác biệt khi đi đến đâu - đến máy chủ phần cứng hay chỉ triển khai trong máy ảo.
Những gì có thể được thực hiện? Sẽ rất tuyệt nếu cung cấp một ví dụ trong tài liệu ClickHouse về cách triển khai một cụm nhỏ trong chính ngôi nhà của bạn - trong Docker, trong LXC, có thể tạo một Playbook Ansible, vì những người khác nhau có cách triển khai khác nhau. Điều này sẽ đơn giản hóa rất nhiều. Khi bạn thực hiện và triển khai một cụm trong năm phút, việc cố gắng tìm ra điều gì đó sẽ dễ dàng hơn nhiều. Điều này thuận tiện hơn nhiều vì việc chuyển sang phiên bản sản xuất mà bạn chưa thử nghiệm là một con đường dẫn đến hư không. Đôi khi nó hoạt động và đôi khi không. Và do đó, hy vọng thành công là xấu.
Maxim Kotykov, kỹ sư phụ trợ cấp cao Avito: Tôi sẽ nói thêm một chút về môi trường thử nghiệm từ một loạt vấn đề mà các công ty lớn gặp phải. Chúng tôi có cụm chấp nhận ClickHouse chính thức; về mặt sơ đồ và cài đặt dữ liệu, nó là bản sao chính xác của những gì đang được sản xuất. Cụm này được triển khai trong các vùng chứa khá cũ với nguồn tài nguyên tối thiểu. Chúng tôi viết một tỷ lệ phần trăm nhất định của dữ liệu sản xuất ở đó, may mắn thay là có thể sao chép luồng trong Kafka. Mọi thứ ở đó đều được đồng bộ hóa và mở rộng quy mô - cả về công suất và lưu lượng, và theo lý thuyết, tất cả những thứ khác đều bằng nhau, nó sẽ hoạt động giống như sản xuất về mặt số liệu. Mọi thứ có khả năng gây nổ trước tiên sẽ được lăn lên giá đỡ này và để ở đó trong vài ngày cho đến khi sẵn sàng. Nhưng đương nhiên, giải pháp này đắt tiền, khó khăn và có chi phí hỗ trợ khác XNUMX.
Alexey Milovidov: Tôi sẽ cho bạn biết môi trường thử nghiệm của những người bạn Yandex.Metrica của chúng tôi như thế nào. Một cụm có khoảng 600 máy chủ, cụm khác có 360 máy chủ, còn cụm thứ ba và một số cụm. Môi trường thử nghiệm cho một trong số chúng chỉ đơn giản là hai phân đoạn, mỗi phân đoạn có hai bản sao. Tại sao lại có hai mảnh? Vì vậy, bạn không đơn độc. Và cũng nên có bản sao. Chỉ cần một số tiền tối thiểu nhất định mà bạn có thể đủ khả năng.
Môi trường thử nghiệm này cho phép bạn kiểm tra xem các truy vấn của bạn có hoạt động hay không và có vấn đề gì quan trọng không. Nhưng thường thì các vấn đề có bản chất hoàn toàn khác phát sinh khi mọi thứ vẫn hoạt động nhưng có một số thay đổi nhỏ về tải.
Tôi sẽ cho bạn một ví dụ. Chúng tôi quyết định cài đặt phiên bản ClickHouse mới. Nó đã được đăng trên môi trường thử nghiệm, các thử nghiệm tự động đã được hoàn thành trong chính Yandex.Metrica, so sánh dữ liệu trên phiên bản cũ và phiên bản mới, chạy toàn bộ quy trình. Và tất nhiên, các bài kiểm tra xanh của CI của chúng tôi. Nếu không thì chúng tôi thậm chí đã không đề xuất phiên bản này.
Mọi thứ đều ổn. Chúng tôi đang bắt đầu chuyển sang sản xuất. Tôi nhận được thông báo rằng tải trên biểu đồ đã tăng lên nhiều lần. Chúng tôi đang quay lại phiên bản. Tôi nhìn vào biểu đồ và thấy: tải thực sự đã tăng lên nhiều lần trong quá trình triển khai và giảm trở lại khi chúng được triển khai. Sau đó, chúng tôi bắt đầu quay lại phiên bản. Và tải trọng tăng lên và giảm trở lại theo cách tương tự. Vì vậy, kết luận là thế này: tải đã tăng lên do cách bố trí, không có gì đáng ngạc nhiên.
Khi đó thật khó để thuyết phục đồng nghiệp cài đặt phiên bản mới. Tôi nói: “Không sao đâu, lăn ra đi. Hãy bắt chéo ngón tay của bạn, mọi thứ sẽ hoạt động. Bây giờ tải trên biểu đồ đã tăng lên, nhưng mọi thứ vẫn ổn. Hãy ở yên đó." Nói chung, chúng tôi đã làm điều này và thế là xong - phiên bản đã được phát hành để sản xuất. Nhưng hầu hết mọi cách bố trí đều có vấn đề tương tự.
Truy vấn tiêu diệt được cho là tiêu diệt truy vấn, nhưng thực tế không phải vậy. Tại sao?
Một người dùng, một nhà phân tích nào đó, đã đến gặp tôi và tạo một yêu cầu đưa cụm ClickHouse của tôi vào. Một số nút hoặc toàn bộ cụm, tùy thuộc vào bản sao hoặc phân đoạn mà yêu cầu đã gửi đến. Tôi thấy tất cả tài nguyên CPU trên máy chủ này đều nằm trên kệ, mọi thứ đều có màu đỏ. Đồng thời, ClickHouse tự đáp ứng các yêu cầu. Và tôi viết: “Xin hãy cho tôi xem, danh sách quy trình, yêu cầu nào đã tạo ra sự điên rồ này.”
Tôi tìm thấy yêu cầu này và viết kill cho nó. Và tôi thấy chẳng có gì xảy ra cả. Máy chủ của tôi đang ở trên kệ, ClickHouse sau đó đưa cho tôi một số lệnh, cho thấy rằng máy chủ vẫn hoạt động và mọi thứ đều ổn. Nhưng tất cả các yêu cầu của người dùng đều bị suy giảm, sự xuống cấp bắt đầu bằng các bản ghi trong ClickHouse và truy vấn tiêu diệt của tôi không hoạt động. Tại sao? Tôi nghĩ truy vấn tiêu diệt đáng lẽ phải tiêu diệt truy vấn, nhưng thực tế không phải vậy.
Bây giờ sẽ có một câu trả lời khá lạ lùng. Vấn đề là truy vấn hủy không giết truy vấn.
Truy vấn tiêu diệt sẽ kiểm tra một hộp nhỏ có tên “Tôi muốn tiêu diệt truy vấn này”. Và bản thân yêu cầu sẽ xem xét cờ này khi xử lý từng khối. Nếu nó được đặt, yêu cầu sẽ ngừng hoạt động. Hóa ra không có ai giết yêu cầu, chính anh ta phải kiểm tra mọi thứ và dừng lại. Và điều này sẽ hoạt động trong mọi trường hợp yêu cầu ở trạng thái xử lý khối dữ liệu. Nó sẽ xử lý khối dữ liệu tiếp theo, kiểm tra cờ và dừng lại.
Điều này không hoạt động trong trường hợp yêu cầu bị chặn ở một số thao tác. Đúng, rất có thể đây không phải là trường hợp của bạn, vì theo bạn, nó sử dụng rất nhiều tài nguyên máy chủ. Có thể điều này không hoạt động trong trường hợp sắp xếp bên ngoài và trong một số chi tiết khác. Nhưng nói chung điều này không nên xảy ra, đó là một lỗi. Và điều duy nhất tôi có thể khuyên là cập nhật ClickHouse.
Làm cách nào để tính thời gian phản hồi khi tải đọc?
Có một bảng lưu trữ tổng hợp vật phẩm - nhiều quầy khác nhau. Số lượng dòng là khoảng một trăm triệu. Có thể tin tưởng vào thời gian phản hồi có thể dự đoán được nếu bạn đổ 1K RPS cho 1K vật phẩm không?
Đánh giá theo ngữ cảnh, chúng ta đang nói về tải đọc, bởi vì không có vấn đề gì khi viết - thậm chí có thể chèn một nghìn, thậm chí một trăm nghìn và đôi khi vài triệu hàng.
Yêu cầu đọc rất khác nhau. Trong lựa chọn 1, ClickHouse có thể thực hiện khoảng hàng chục nghìn yêu cầu mỗi giây, do đó, ngay cả những yêu cầu đối với một khóa cũng sẽ yêu cầu một số tài nguyên. Và các truy vấn điểm như vậy sẽ khó khăn hơn so với một số cơ sở dữ liệu khóa-giá trị, vì đối với mỗi lần đọc cần phải đọc một khối dữ liệu theo chỉ mục. Chỉ mục của chúng tôi không đề cập đến từng bản ghi mà là từng phạm vi. Nghĩa là, bạn sẽ phải đọc toàn bộ phạm vi - đây là 8192 dòng theo mặc định. Và bạn sẽ phải giải nén khối dữ liệu nén từ 64 KB xuống còn 1 MB. Thông thường, các truy vấn được nhắm mục tiêu như vậy sẽ mất vài mili giây để hoàn thành. Nhưng đây là lựa chọn đơn giản nhất.
Hãy thử một số phép tính đơn giản. Nếu bạn nhân vài mili giây với một nghìn, bạn sẽ có được vài giây. Có vẻ như không thể đáp ứng được hàng nghìn yêu cầu mỗi giây, nhưng trên thực tế thì điều đó là có thể, bởi vì chúng tôi có một số lõi xử lý. Vì vậy, về nguyên tắc, ClickHouse đôi khi có thể chứa 1000 RPS, nhưng đối với các yêu cầu ngắn, những yêu cầu được nhắm mục tiêu cụ thể.
Nếu bạn cần chia tỷ lệ cụm ClickHouse theo số lượng yêu cầu đơn giản thì tôi khuyên bạn nên làm điều đơn giản nhất - tăng số lượng bản sao và gửi yêu cầu đến một bản sao ngẫu nhiên. Nếu một bản sao chứa năm trăm yêu cầu mỗi giây, điều này hoàn toàn thực tế, thì ba bản sao sẽ xử lý một nghìn rưỡi.
Tất nhiên, đôi khi, bạn có thể định cấu hình ClickHouse để có số lần đọc điểm tối đa. Điều gì là cần thiết cho việc này? Đầu tiên là giảm độ chi tiết của chỉ mục. Trong trường hợp này không nên giảm xuống một mà dựa trên cơ sở số lượng mục trong chỉ mục sẽ là vài triệu hoặc hàng chục triệu trên mỗi máy chủ. Nếu bảng có một trăm triệu hàng thì độ chi tiết có thể được đặt thành 64.
Bạn có thể giảm kích thước của khối nén. Có cài đặt cho việc này kích thước khối nén tối thiểu, kích thước khối nén tối đa. Chúng có thể được giảm bớt, nạp lại dữ liệu và sau đó các truy vấn được nhắm mục tiêu sẽ nhanh hơn. Tuy nhiên, ClickHouse không phải là cơ sở dữ liệu khóa-giá trị. Một số lượng lớn các yêu cầu nhỏ là một phản mẫu tải.
Kirill Shvakov: Tôi sẽ đưa ra lời khuyên trong trường hợp có tài khoản thông thường ở đó. Đây là một tình huống khá chuẩn khi ClickHouse lưu trữ một số loại bộ đếm. Tôi có một người dùng, anh ấy đến từ quốc gia này và quốc gia khác, và một số lĩnh vực thứ ba, và tôi cần tăng dần thứ gì đó. Lấy MySQL, tạo một khóa duy nhất - trong MySQL, đó là khóa trùng lặp và trong PostgreSQL, đó là xung đột - và thêm dấu cộng. Điều này sẽ hoạt động tốt hơn nhiều.
Khi bạn không có nhiều dữ liệu thì việc sử dụng ClickHouse cũng chẳng có ích lợi gì. Có cơ sở dữ liệu thường xuyên và họ làm tốt điều này.
Tôi có thể điều chỉnh gì trong ClickHouse để có nhiều dữ liệu hơn trong bộ đệm?
Hãy tưởng tượng một tình huống - các máy chủ có 256 GB RAM, trong công việc hàng ngày ClickHouse chiếm khoảng 60-80 GB, lúc cao điểm - lên tới 130. Những gì có thể được kích hoạt và điều chỉnh để có nhiều dữ liệu hơn trong bộ đệm và theo đó, có ít chuyến đi vào đĩa hơn?
Thông thường, bộ đệm trang của hệ điều hành thực hiện tốt công việc này. Nếu bạn chỉ mở phần trên cùng, nhìn vào đó được lưu trong bộ nhớ đệm hoặc miễn phí - nó cũng cho biết dung lượng được lưu trong bộ nhớ đệm - khi đó bạn sẽ nhận thấy rằng tất cả bộ nhớ trống được sử dụng cho bộ nhớ đệm. Và khi đọc dữ liệu này, nó sẽ được đọc không phải từ đĩa mà từ RAM. Đồng thời, có thể nói rằng bộ nhớ đệm được sử dụng hiệu quả vì chính dữ liệu nén được lưu vào bộ nhớ đệm.
Tuy nhiên, nếu bạn muốn tăng tốc hơn nữa một số truy vấn đơn giản, bạn có thể kích hoạt bộ đệm trong dữ liệu được giải nén bên trong ClickHouse. Nó được gọi là bộ đệm không nén. Trong tệp cấu hình config.xml, đặt kích thước bộ đệm không nén thành giá trị bạn cần - Tôi khuyên bạn không nên sử dụng quá một nửa RAM trống, vì phần còn lại sẽ nằm trong bộ đệm của trang.
Ngoài ra, có hai cài đặt cấp độ yêu cầu. Cài đặt đầu tiên - sử dụng bộ đệm không nén - bao gồm việc sử dụng nó. Bạn nên kích hoạt nó cho tất cả các yêu cầu, ngoại trừ những yêu cầu nặng, có thể đọc tất cả dữ liệu và xóa bộ đệm. Và cài đặt thứ hai giống như số dòng tối đa để sử dụng bộ đệm. Nó tự động giới hạn các truy vấn lớn để chúng bỏ qua bộ đệm.
Làm cách nào tôi có thể định cấu hình storage_configuration để lưu trữ trong RAM?
Trong tài liệu ClickHouse mới tôi đọc phần liên quan . Mô tả chứa một ví dụ về SSD nhanh.
Tôi tự hỏi làm thế nào điều tương tự có thể được cấu hình với bộ nhớ nóng âm lượng. Và một câu hỏi nữa. Lựa chọn hoạt động như thế nào với tổ chức dữ liệu này, nó sẽ đọc toàn bộ tập hợp hay chỉ một tập hợp trên đĩa và dữ liệu này có được nén trong bộ nhớ không? Và phần prewhere hoạt động như thế nào với tổ chức dữ liệu như vậy?
Cài đặt này ảnh hưởng đến việc lưu trữ các khối dữ liệu và định dạng của chúng không thay đổi theo bất kỳ cách nào.
Chúng ta hãy xem xét kỹ hơn.
Bạn có thể cấu hình lưu trữ dữ liệu trong RAM. Tất cả những gì được cấu hình cho đĩa là đường dẫn của nó. Bạn tạo một phân vùng tmpfs được gắn vào một đường dẫn nào đó trong hệ thống tệp. Bạn chỉ định đường dẫn này làm đường dẫn lưu trữ dữ liệu cho phân vùng nóng nhất, các phần dữ liệu bắt đầu đến và được ghi vào đó, mọi thứ đều ổn.
Nhưng tôi không khuyên bạn nên làm điều này vì độ tin cậy thấp, mặc dù nếu bạn có ít nhất ba bản sao ở các trung tâm dữ liệu khác nhau thì điều đó là có thể. Nếu có điều gì xảy ra, dữ liệu sẽ được khôi phục. Hãy tưởng tượng rằng máy chủ đột nhiên bị tắt và bật lại. Phân vùng đã được gắn lại, nhưng không có gì ở đó. Khi máy chủ ClickHouse khởi động, nó thấy rằng nó không có những phần này, mặc dù theo siêu dữ liệu của ZooKeeper, chúng sẽ ở đó. Anh ấy xem bản sao nào có chúng, yêu cầu và tải chúng xuống. Bằng cách này, dữ liệu sẽ được khôi phục.
Theo nghĩa này, việc lưu trữ dữ liệu trong RAM về cơ bản không khác với việc lưu trữ trên đĩa, vì khi dữ liệu được ghi vào đĩa, trước tiên nó cũng nằm trong bộ đệm trang và được ghi vật lý sau đó. Điều này phụ thuộc vào tùy chọn gắn hệ thống tập tin. Nhưng để đề phòng, tôi sẽ nói rằng ClickHouse không đồng bộ hóa khi chèn.
Trong trường hợp này, dữ liệu trong RAM được lưu trữ ở định dạng giống hệt như trên đĩa. Truy vấn chọn theo cách tương tự sẽ chọn các phần cần đọc, chọn phạm vi dữ liệu cần thiết trong các phần và đọc chúng. Và prewhere hoạt động giống hệt nhau, bất kể dữ liệu nằm trong RAM hay trên đĩa.
Số lượng giá trị duy nhất thấp có hiệu lực là bao nhiêu?
Cardinality thấp được thiết kế khéo léo. Nó biên dịch từ điển dữ liệu, nhưng chúng mang tính cục bộ. Thứ nhất, có những từ điển khác nhau cho mỗi phần và thứ hai, ngay cả trong một phần, chúng có thể khác nhau đối với từng phạm vi. Khi số lượng giá trị duy nhất đạt đến ngưỡng—tôi nghĩ là một triệu—từ điển sẽ được xếp vào giá và một từ điển mới sẽ được tạo.
Câu trả lời nói chung là: đối với từng phạm vi địa phương - chẳng hạn như mỗi ngày - ở đâu đó có tới một triệu giá trị duy nhất. Số lượng thấp có hiệu lực. Sau đó sẽ chỉ có một dự phòng, trong đó nhiều từ điển khác nhau sẽ được sử dụng chứ không chỉ một. Nó sẽ hoạt động gần giống như một cột chuỗi thông thường, có thể kém hiệu quả hơn một chút nhưng sẽ không làm giảm hiệu suất nghiêm trọng.
Các phương pháp hay nhất để tìm kiếm toàn văn bản trong một bảng có năm tỷ hàng là gì?
Có nhiều câu trả lời khác nhau. Đầu tiên phải nói rằng ClickHouse không phải là một công cụ tìm kiếm toàn văn bản. Có những hệ thống đặc biệt cho việc này, ví dụ, и . Tuy nhiên, tôi ngày càng thấy nhiều người nói rằng họ đang chuyển từ Elaticsearch sang ClickHouse.
Lý do tại sao điều này xảy ra? Họ giải thích điều này là do Elaticsearch không còn chịu được tải ở một số khối lượng, bắt đầu bằng việc xây dựng các chỉ mục. Các chỉ mục trở nên quá cồng kềnh và nếu bạn chỉ chuyển dữ liệu sang ClickHouse, thì chúng sẽ được lưu trữ hiệu quả hơn nhiều lần về mặt âm lượng. Đồng thời, các truy vấn tìm kiếm thường không đến mức cần phải tìm một số cụm từ trong toàn bộ khối dữ liệu, có tính đến hình thái học mà là các cụm từ hoàn toàn khác nhau. Ví dụ: tìm một số chuỗi byte trong nhật ký trong vài giờ qua.
Trong trường hợp này, bạn tạo chỉ mục trong ClickHouse, trường đầu tiên sẽ là ngày và giờ. Và giới hạn dữ liệu lớn nhất sẽ dựa trên phạm vi ngày. Theo quy định, trong phạm vi ngày đã chọn, bạn có thể thực hiện tìm kiếm toàn văn bản, thậm chí sử dụng phương pháp vũ phu bằng cách sử dụng lượt thích. Toán tử like trong ClickHouse là toán tử like hiệu quả nhất mà bạn có thể tìm thấy. Nếu bạn tìm thấy một cái gì đó tốt hơn, hãy nói với tôi.
Nhưng vẫn giống như quét toàn bộ. Và quá trình quét toàn bộ có thể bị chậm không chỉ trên CPU mà còn trên đĩa. Nếu đột nhiên bạn có một terabyte dữ liệu mỗi ngày và bạn tìm kiếm một từ trong ngày, thì bạn sẽ phải quét terabyte. Và nó có thể nằm trên các ổ cứng thông thường và cuối cùng chúng sẽ được tải theo cách mà bạn sẽ không thể truy cập máy chủ này thông qua SSH.
Trong trường hợp này, tôi sẵn sàng đưa ra một mẹo nhỏ nữa. Đó là thử nghiệm - nó có thể hoạt động, có thể không. ClickHouse có các chỉ mục toàn văn bản dưới dạng bộ lọc Bát quái Bloom. Các đồng nghiệp của chúng tôi tại Arenadata đã thử các chỉ mục này và chúng thường hoạt động chính xác như dự kiến.
Để sử dụng chúng một cách chính xác, bạn nên hiểu rõ chính xác cách chúng hoạt động: bộ lọc Bloom bát quái là gì và cách chọn kích thước của nó. Tôi có thể nói rằng chúng sẽ giúp ích cho việc truy vấn một số cụm từ hiếm, chuỗi con hiếm khi được tìm thấy trong dữ liệu. Trong trường hợp này, các phạm vi phụ sẽ được chọn theo chỉ mục và sẽ có ít dữ liệu được đọc hơn.
Gần đây, ClickHouse đã bổ sung thêm nhiều chức năng nâng cao hơn nữa cho tìm kiếm toàn văn bản. Trước hết, đây là tìm kiếm một loạt các chuỗi con cùng một lúc trong một lượt, bao gồm các tùy chọn phân biệt chữ hoa chữ thường, không phân biệt chữ hoa chữ thường, có hỗ trợ UTF-8 hoặc chỉ cho ASCII. Chọn một trong những hiệu quả nhất bạn cần.
Tìm kiếm nhiều biểu thức chính quy trong một lượt cũng đã xuất hiện. Bạn không cần phải viết X như một chuỗi con hoặc X như một chuỗi con khác. Bạn viết ngay và mọi thứ được thực hiện hiệu quả nhất có thể.
Thứ ba, hiện nay có một tìm kiếm gần đúng cho các biểu thức chính quy và một tìm kiếm gần đúng cho các chuỗi con. Nếu ai đó viết sai chính tả một từ, từ đó sẽ được tìm kiếm để tìm kết quả phù hợp nhất.
Cách tốt nhất để tổ chức quyền truy cập vào ClickHouse cho số lượng lớn người dùng là gì?
Hãy cho chúng tôi biết cách tốt nhất để tổ chức quyền truy cập cho một lượng lớn người tiêu dùng và nhà phân tích. Làm cách nào để tạo hàng đợi, ưu tiên tối đa các truy vấn đồng thời và bằng công cụ nào?
Nếu cụm đủ lớn thì giải pháp tốt là tăng thêm hai máy chủ, đây sẽ trở thành điểm vào cho các nhà phân tích. Tức là không cho phép các nhà phân tích truy cập vào các phân đoạn cụ thể trong cụm mà chỉ cần tạo hai máy chủ trống, không có dữ liệu và định cấu hình quyền truy cập trên chúng. Trong trường hợp này, cài đặt người dùng cho các yêu cầu được phân phối sẽ được chuyển đến máy chủ từ xa. Nghĩa là, bạn định cấu hình mọi thứ trên hai máy chủ này và các cài đặt có ảnh hưởng đến toàn bộ cụm.
Về nguyên tắc, các máy chủ này không có dữ liệu nhưng dung lượng RAM trên chúng rất quan trọng để thực hiện các yêu cầu. Đĩa cũng có thể được sử dụng cho dữ liệu tạm thời nếu tính năng tổng hợp bên ngoài hoặc sắp xếp bên ngoài được bật.
Điều quan trọng là phải xem xét các cài đặt có liên quan đến tất cả các giới hạn có thể có. Nếu bây giờ tôi truy cập cụm Yandex.Metrica với tư cách là nhà phân tích và đưa ra yêu cầu chọn số lần truy cập, thì ngay lập tức tôi sẽ nhận được một ngoại lệ là tôi không thể thực hiện yêu cầu. Số lượng hàng tối đa mà tôi được phép quét là một trăm tỷ và tổng cộng có năm mươi nghìn tỷ hàng trong một bảng trên cụm. Đây là hạn chế đầu tiên.
Giả sử tôi xóa giới hạn hàng và chạy lại truy vấn. Sau đó tôi sẽ thấy ngoại lệ sau - đã bật cài đặt buộc chỉ số theo ngày. Tôi không thể hoàn thành truy vấn nếu tôi chưa chỉ định phạm vi ngày. Bạn không cần phải dựa vào các nhà phân tích để chỉ định nó một cách thủ công. Một trường hợp điển hình là khi một phạm vi ngày được viết ở nơi có ngày diễn ra sự kiện giữa tuần. Và sau đó, họ chỉ đơn giản là chỉ định một dấu ngoặc ở sai vị trí và thay vào đó, nó lại trở thành hoặc - hoặc URL khớp. Nếu không có giới hạn, nó sẽ thu thập dữ liệu cột URL và lãng phí rất nhiều tài nguyên.
Ngoài ra, ClickHouse có hai cài đặt ưu tiên. Thật không may, chúng rất nguyên thủy. Một cái được gọi đơn giản là ưu tiên. Nếu mức độ ưu tiên ≠ 0 và các yêu cầu có mức độ ưu tiên nào đó đang được thực thi, nhưng một yêu cầu có giá trị ưu tiên nhỏ hơn, nghĩa là mức độ ưu tiên cao hơn, đang được thực thi, thì yêu cầu có giá trị ưu tiên lớn hơn, nghĩa là mức độ ưu tiên thấp hơn , chỉ đơn giản là bị đình chỉ và sẽ không hoạt động trong thời gian này.
Đây là cài đặt rất thô sơ và không phù hợp với trường hợp cụm có tải không đổi. Nhưng nếu bạn có các yêu cầu ngắn, nhiều yêu cầu quan trọng và cụm hầu như không hoạt động thì thiết lập này sẽ phù hợp.
Cài đặt ưu tiên tiếp theo được gọi Ưu tiên luồng hệ điều hành. Nó chỉ đơn giản đặt giá trị Nice cho tất cả các luồng thực thi yêu cầu cho bộ lập lịch Linux. Nó hoạt động bình thường, nhưng nó vẫn hoạt động. Nếu bạn đặt giá trị Nice tối thiểu - đó là giá trị lớn nhất và do đó có mức độ ưu tiên thấp nhất - và đặt -19 cho các yêu cầu có mức độ ưu tiên cao thì CPU sẽ tiêu thụ các yêu cầu có mức độ ưu tiên thấp ít hơn khoảng bốn lần so với các yêu cầu có mức độ ưu tiên cao.
Bạn cũng cần định cấu hình thời gian thực hiện yêu cầu tối đa - chẳng hạn như năm phút. Tốc độ thực hiện truy vấn tối thiểu là điều tuyệt vời nhất. Chế độ cài đặt này đã có từ rất lâu và không những cần phải khẳng định ClickHouse không làm chậm mà còn phải ép buộc.
Hãy tưởng tượng, bạn thiết lập: nếu một số truy vấn xử lý ít hơn một triệu hàng mỗi giây, bạn không thể làm điều đó. Điều này làm ô danh danh tiếng tốt của chúng tôi, cơ sở dữ liệu tốt của chúng tôi. Chúng ta hãy cấm điều này. Thực tế có hai cài đặt. Một người được gọi là tốc độ thực hiện tối thiểu - tính bằng dòng trên giây và giây được gọi là thời gian chờ trước khi kiểm tra tốc độ thực hiện tối thiểu - theo mặc định là mười lăm giây. Nghĩa là, có thể mười lăm giây, sau đó, nếu chậm thì chỉ cần đưa ra một ngoại lệ và hủy bỏ yêu cầu.
Bạn cũng cần phải thiết lập hạn ngạch. ClickHouse có tính năng hạn ngạch tích hợp để tính mức tiêu thụ tài nguyên. Nhưng thật không may, không phải tài nguyên phần cứng như CPU, đĩa, mà là tài nguyên logic - số lượng yêu cầu được xử lý, dòng và byte được đọc. Và bạn có thể định cấu hình, chẳng hạn, tối đa một trăm yêu cầu trong vòng năm phút và một nghìn yêu cầu mỗi giờ.
Tại sao nó lại quan trọng? Bởi vì một số truy vấn phân tích sẽ được thực hiện thủ công trực tiếp từ ứng dụng khách ClickHouse. Và tất cả sẽ tốt đẹp. Nhưng nếu bạn có các nhà phân tích nâng cao trong công ty của mình, họ sẽ viết một kịch bản và có thể có lỗi trong kịch bản. Và lỗi này sẽ khiến yêu cầu được thực hiện trong một vòng lặp vô hạn. Đây là điều chúng ta cần bảo vệ mình khỏi.
Có thể cung cấp kết quả của một truy vấn cho mười khách hàng không?
Chúng tôi có một số người dùng muốn đưa ra những yêu cầu rất lớn vào cùng một thời điểm. Yêu cầu lớn và về nguyên tắc được thực hiện nhanh chóng, nhưng do có nhiều yêu cầu như vậy cùng một lúc nên trở nên rất khó khăn. Có thể thực hiện cùng một yêu cầu đến mười lần liên tiếp, một lần và đưa kết quả cho mười khách hàng không?
Vấn đề là chúng ta không có kết quả cache hoặc cache dữ liệu trung gian. Có một bộ đệm trang của hệ điều hành, điều này sẽ ngăn bạn đọc lại dữ liệu từ đĩa, nhưng thật không may, dữ liệu sẽ vẫn được giải nén, giải tuần tự hóa và xử lý lại.
Tôi muốn tránh điều này bằng cách nào đó, bằng cách lưu vào bộ đệm dữ liệu trung gian hoặc bằng cách sắp xếp các truy vấn tương tự trong một số loại hàng đợi và thêm bộ đệm kết quả. Chúng tôi hiện có một yêu cầu kéo đang trong quá trình phát triển, bổ sung bộ nhớ đệm yêu cầu, nhưng chỉ dành cho các truy vấn phụ trong phần trong và phần tham gia - nghĩa là giải pháp chưa hoàn chỉnh.
Tuy nhiên, chúng ta cũng gặp phải tình trạng như vậy. Một ví dụ đặc biệt kinh điển là các truy vấn được phân trang. Có một báo cáo, nó có nhiều trang và có yêu cầu giới hạn 10. Sau đó, điều tương tự, nhưng giới hạn 10,10. Rồi một trang tiếp theo. Và câu hỏi là, tại sao chúng ta lại đếm tất cả những điều này mỗi lần? Nhưng hiện tại không có biện pháp, cũng không có cách nào tránh né.
Có một giải pháp thay thế được đặt làm sidecar bên cạnh ClickHouse - .
Kirill Shvakov: ClickHouse Proxy có bộ giới hạn tốc độ tích hợp và bộ đệm kết quả tích hợp. Rất nhiều cài đặt đã được thực hiện ở đó vì một vấn đề tương tự đang được giải quyết. Proxy cho phép bạn giới hạn các yêu cầu bằng cách xếp chúng vào hàng đợi và định cấu hình thời gian tồn tại của bộ đệm yêu cầu. Nếu các yêu cầu thực sự giống nhau, Proxy sẽ gửi chúng nhiều lần nhưng sẽ chỉ đến ClickHouse một lần.
Nginx cũng có bộ nhớ đệm trong phiên bản miễn phí và tính năng này cũng sẽ hoạt động. Nginx thậm chí còn có các cài đặt mà nếu các yêu cầu đến cùng lúc, nó sẽ làm chậm các yêu cầu khác cho đến khi hoàn thành. Nhưng trong ClickHouse Proxy, việc thiết lập được thực hiện tốt hơn nhiều. Nó được làm riêng cho ClickHouse, dành riêng cho những yêu cầu này nên phù hợp hơn. Chà, thật dễ dàng để cài đặt.
Còn các hoạt động không đồng bộ và các chế độ xem được cụ thể hóa thì sao?
Có một vấn đề là các hoạt động với công cụ phát lại không đồng bộ - đầu tiên dữ liệu được ghi, sau đó nó bị sập. Nếu một tấm bảng được hiện thực hóa với một số tập hợp nằm dưới dấu hiệu, thì các bản sao sẽ được ghi vào đó. Và nếu không có logic phức tạp thì dữ liệu sẽ bị trùng lặp. Bạn có thể làm gì về nó?
Có một giải pháp rõ ràng - triển khai trình kích hoạt trên một lớp matview nhất định trong quá trình thu gọn không đồng bộ. Có bất kỳ viên đạn bạc hoặc kế hoạch nào để triển khai chức năng tương tự không?
Thật đáng để hiểu cách thức hoạt động của tính năng chống trùng lặp. Những gì tôi sẽ nói với bạn bây giờ không liên quan đến câu hỏi, nhưng chỉ đề phòng trường hợp nó đáng được ghi nhớ.
Khi chèn vào một bảng được sao chép, toàn bộ các khối được chèn sẽ bị trùng lặp. Nếu bạn lắp lại cùng một khối chứa cùng số lượng hàng giống nhau theo cùng một thứ tự thì dữ liệu sẽ bị trùng lặp. Bạn sẽ nhận được phản hồi “Ok” khi chèn, nhưng trên thực tế, một gói dữ liệu sẽ được ghi và nó sẽ không bị trùng lặp.
Điều này là cần thiết cho sự chắc chắn. Nếu bạn nhận được “Ok” trong khi chèn thì dữ liệu của bạn đã được chèn. Nếu bạn nhận được lỗi từ ClickHouse, điều đó có nghĩa là chúng chưa được chèn và bạn cần phải chèn lại. Nhưng nếu kết nối bị đứt trong quá trình chèn thì bạn không biết dữ liệu đã được chèn hay chưa. Tùy chọn duy nhất là lặp lại việc chèn lại. Nếu dữ liệu thực sự đã được chèn vào và bạn chèn lại nó thì sẽ xảy ra hiện tượng trùng lặp khối. Điều này là cần thiết để tránh trùng lặp.
Và điều quan trọng nữa là cách nó hoạt động đối với các chế độ xem cụ thể hóa. Nếu dữ liệu bị trùng lặp khi chèn vào bảng chính thì dữ liệu đó cũng sẽ không được đưa vào chế độ xem cụ thể hóa.
Bây giờ về câu hỏi. Tình huống của bạn phức tạp hơn vì bạn đang ghi lại các bản sao của từng dòng riêng lẻ. Nghĩa là, không phải toàn bộ gói được sao chép mà là các dòng cụ thể và chúng bị thu gọn trong nền. Thật vậy, dữ liệu sẽ thu gọn trong bảng chính, nhưng dữ liệu chưa được thu gọn sẽ chuyển sang chế độ xem cụ thể hóa và trong quá trình hợp nhất sẽ không có gì xảy ra với các chế độ xem cụ thể hóa. Bởi vì chế độ xem cụ thể hóa không gì khác hơn là một trình kích hoạt chèn. Trong các hoạt động khác, không có gì xảy ra thêm với nó.
Và tôi không thể làm cho bạn hạnh phúc ở đây. Bạn chỉ cần tìm kiếm một giải pháp cụ thể cho trường hợp này. Ví dụ: có thể phát lại nó ở chế độ xem cụ thể hóa không và phương pháp loại bỏ trùng lặp có thể hoạt động theo cách tương tự. Nhưng thật không may, không phải lúc nào cũng vậy. Nếu nó được tổng hợp, nó sẽ không hoạt động.
Kirill Shvakov: Ngày trước chúng tôi cũng đã xây dựng nạng. Đã xảy ra sự cố là có số lần hiển thị quảng cáo và có một số dữ liệu mà chúng tôi có thể hiển thị theo thời gian thực - đây chỉ là số lần hiển thị. Chúng hiếm khi bị trùng lặp, nhưng nếu điều này xảy ra, chúng ta sẽ thu gọn chúng sau này. Và có những thứ không thể lặp lại - những cú nhấp chuột và toàn bộ câu chuyện này. Nhưng tôi cũng muốn cho họ xem gần như ngay lập tức.
Các quan điểm cụ thể hóa được thực hiện như thế nào? Có những chế độ xem được ghi trực tiếp - nó được ghi vào dữ liệu thô và được ghi vào chế độ xem. Ở đó, tại một số điểm, dữ liệu không chính xác lắm, nó bị trùng lặp, v.v. Và có phần thứ hai của bảng, nơi chúng trông giống hệt như các khung nhìn cụ thể hóa, nghĩa là chúng hoàn toàn giống nhau về cấu trúc. Thỉnh thoảng chúng tôi tính toán lại dữ liệu, đếm dữ liệu không trùng lặp, ghi vào các bảng đó.
Chúng tôi đã xem qua API - điều này sẽ không hoạt động trong ClickHouse theo cách thủ công. Và API trông như thế này: khi tôi có ngày bổ sung cuối cùng vào bảng, nơi đảm bảo rằng dữ liệu chính xác đã được tính toán và nó đưa ra yêu cầu tới một bảng và tới một bảng khác. Từ một yêu cầu chọn tối đa một khoảng thời gian nhất định và từ yêu cầu kia nhận được những gì chưa được tính toán. Và nó hoạt động, nhưng không chỉ thông qua ClickHouse.
Nếu bạn có một số loại API - dành cho nhà phân tích, dành cho người dùng - thì về nguyên tắc, đây là một tùy chọn. Bạn luôn đếm, luôn đếm. Điều này có thể được thực hiện một lần một ngày hoặc vào một thời điểm khác. Bạn chọn cho mình một phạm vi mà bạn không cần và không quan trọng.
ClickHouse có rất nhiều nhật ký. Làm cách nào tôi có thể xem nhanh mọi thứ xảy ra với máy chủ?
ClickHouse có số lượng rất lớn các log khác nhau và con số này ngày càng tăng lên. Trong các phiên bản mới, một số trong số chúng thậm chí còn được bật theo mặc định, trong các phiên bản cũ hơn, chúng phải được bật khi cập nhật. Tuy nhiên, ngày càng có nhiều người trong số họ. Cuối cùng, tôi muốn xem điều gì đang xảy ra với máy chủ của mình hiện tại, có thể trên một loại bảng điều khiển tóm tắt nào đó.
Bạn có nhóm ClickHouse hoặc nhóm của bạn bè bạn hỗ trợ một số chức năng của trang tổng quan được tạo sẵn để hiển thị các nhật ký này dưới dạng sản phẩm hoàn chỉnh không? Cuối cùng, chỉ cần nhìn vào nhật ký trong ClickHouse là tuyệt vời. Nhưng sẽ rất tuyệt nếu nó được chuẩn bị sẵn dưới dạng bảng điều khiển. Tôi sẽ rất thích thú với điều này.
Có bảng điều khiển, mặc dù chúng không được chuẩn hóa. Trong công ty của chúng tôi, có khoảng 60 nhóm sử dụng ClickHouse và điều kỳ lạ nhất là nhiều người trong số họ có trang tổng quan do họ tự tạo và những trang tổng quan hơi khác một chút. Một số nhóm sử dụng cài đặt Yandex.Cloud nội bộ. Có một số báo cáo làm sẵn, mặc dù không phải tất cả đều cần thiết. Những người khác có cái riêng của họ.
Các đồng nghiệp của tôi ở Metrica có trang tổng quan riêng trên Grafana và tôi có trang tổng quan riêng cho cụm của họ. Tôi đang xem xét những thứ như bộ nhớ đệm cho bộ đệm có chân. Và khó khăn hơn nữa là chúng ta sử dụng các công cụ khác nhau. Tôi đã tạo trang tổng quan của mình bằng một công cụ rất cũ có tên là Graphite-web. Anh ấy hoàn toàn xấu xí. Và mình vẫn dùng cách này, mặc dù Grafana có lẽ sẽ tiện và đẹp hơn.
Điều cơ bản trong bảng điều khiển là như nhau. Đây là các số liệu hệ thống cho cụm: CPU, bộ nhớ, đĩa, mạng. Khác - số lượng yêu cầu đồng thời, số lượng hợp nhất đồng thời, số lượng yêu cầu mỗi giây, số khối tối đa cho phân vùng bảng MergeTree, độ trễ sao chép, kích thước hàng đợi sao chép, số hàng được chèn mỗi giây, số khối được chèn mỗi giây. Đây là tất cả những gì thu được không phải từ nhật ký mà từ số liệu.
Vladimir Kolobaev: Alexey, tôi muốn sửa lại một chút. Có Grafana. Grafana có nguồn dữ liệu là ClickHouse. Tức là tôi có thể gửi yêu cầu trực tiếp từ Grafana tới ClickHouse. ClickHouse có một bảng chứa nhật ký, mọi người đều giống nhau. Do đó, tôi muốn truy cập bảng nhật ký này trong Grafana và xem các yêu cầu mà máy chủ của tôi đưa ra. Sẽ thật tuyệt nếu có một bảng điều khiển như thế này.
Tôi đã tự mình đạp xe. Nhưng tôi có một câu hỏi - nếu tất cả đều được tiêu chuẩn hóa và Grafana được mọi người sử dụng, tại sao Yandex không có trang tổng quan chính thức như vậy?
Kirill Shvakov: Trên thực tế, nguồn dữ liệu truy cập ClickHouse hiện đã hỗ trợ Altinity. Và tôi chỉ muốn đưa ra một vectơ về nơi đào và đẩy ai. Bạn có thể hỏi họ, vì Yandex vẫn sản xuất ClickHouse chứ không phải câu chuyện xung quanh nó. Altinity là công ty chính hiện đang quảng bá ClickHouse. Họ sẽ không bỏ rơi anh ấy mà sẽ ủng hộ anh ấy. Bởi vì, về nguyên tắc, để tải một bảng điều khiển lên trang web Grafana, bạn chỉ cần đăng ký và tải nó lên - không có vấn đề gì đặc biệt.
Alexey Milovidov: Trong năm qua, ClickHouse đã bổ sung nhiều khả năng lập hồ sơ truy vấn. Có số liệu cho từng yêu cầu về việc sử dụng tài nguyên. Và mới đây, chúng tôi đã thêm một trình phân tích truy vấn ở cấp độ thấp hơn nữa để xem vị trí mà truy vấn tiêu tốn mỗi mili giây. Nhưng để sử dụng chức năng này, tôi phải mở ứng dụng khách bảng điều khiển và nhập một yêu cầu mà tôi luôn quên. Tôi đã lưu nó ở đâu đó và cứ quên chính xác ở đâu.
Tôi ước gì có một công cụ vừa nói, đây là những truy vấn nặng nề của bạn, được nhóm theo lớp truy vấn. Tôi nhấn vào một cái và họ nói với tôi rằng đó là lý do tại sao nó nặng. Bây giờ không có giải pháp như vậy. Và thực sự khá kỳ lạ khi mọi người hỏi tôi: “Hãy cho tôi biết, có bảng điều khiển làm sẵn nào cho Grafana không?”, tôi nói: “Hãy truy cập trang web Grafana, có một cộng đồng “Dashboards” và có một bảng điều khiển từ Dimka, có bảng điều khiển từ Kostyan. Tôi không biết nó là gì, bản thân tôi cũng chưa từng sử dụng nó.”
Làm cách nào để tác động đến việc hợp nhất để máy chủ không gặp sự cố với OOM?
Tôi có một bảng, trong bảng chỉ có một phân vùng duy nhất là ReplacingMergeTree. Tôi đã viết dữ liệu vào đó được bốn năm. Tôi cần thực hiện một thay đổi trong đó và xóa một số dữ liệu.
Tôi đã làm điều này và trong quá trình xử lý yêu cầu này, tất cả bộ nhớ trên tất cả các máy chủ trong cụm đã bị sử dụng và tất cả các máy chủ trong cụm đều chuyển sang OOM. Sau đó, tất cả họ cùng nhau đứng dậy, bắt đầu hợp nhất hoạt động tương tự, khối dữ liệu này và lại rơi vào OOM. Sau đó, họ lại đứng dậy và lại rơi xuống. Và chuyện này vẫn chưa dừng lại.
Sau đó hóa ra đây thực sự là một lỗi mà mọi người đã sửa. Điều này rất tuyệt, cảm ơn bạn rất nhiều. Nhưng dư lượng vẫn còn. Và bây giờ, khi tôi nghĩ về việc thực hiện một số kiểu hợp nhất trong bảng, tôi có một câu hỏi - tại sao bằng cách nào đó tôi không thể tác động đến những sự hợp nhất này? Ví dụ: giới hạn chúng theo dung lượng RAM cần thiết hoặc về nguyên tắc, theo dung lượng sẽ xử lý bảng cụ thể này.
Tôi có một bảng tên là “Số liệu”, vui lòng xử lý bảng đó cho tôi theo hai chuỗi. Không cần phải tạo mười hoặc năm lần hợp nhất song song, hãy thực hiện thành hai lần. Tôi nghĩ rằng tôi có đủ bộ nhớ cho hai, nhưng có thể không đủ để xử lý mười. Tại sao nỗi sợ hãi vẫn còn? Bởi vì bảng đang phát triển và một ngày nào đó tôi sẽ phải đối mặt với một tình huống, về nguyên tắc, không còn do lỗi nữa mà do dữ liệu sẽ thay đổi với số lượng lớn đến mức đơn giản là tôi sẽ không có đủ bộ nhớ trên bảng. máy chủ. Và khi đó máy chủ sẽ gặp sự cố OOM khi hợp nhất. Hơn nữa, tôi có thể hủy bỏ đột biến, nhưng Merji không còn ở đó nữa.
Bạn biết đấy, khi merge thì server sẽ không rơi vào tình trạng OOM, vì khi merge thì dung lượng RAM chỉ được sử dụng cho một dải dữ liệu nhỏ. Vì vậy, mọi thứ sẽ ổn bất kể lượng dữ liệu.
Vladimir Kolobaev: Khỏe. Ở đây, thời điểm này là sau khi sửa lỗi, tôi đã tải xuống một phiên bản mới cho chính mình và trên một bảng khác, một bảng nhỏ hơn, nơi có nhiều phân vùng, tôi thực hiện một thao tác tương tự. Và trong quá trình hợp nhất, khoảng 100 GB RAM đã bị đốt cháy trên máy chủ. Tôi đã chiếm 150, ăn 100 và còn lại một cửa sổ 50 GB, vì vậy tôi không rơi vào OOM.
Điều gì hiện đang bảo vệ tôi khỏi rơi vào OOM nếu nó thực sự tiêu tốn 100 GB RAM? Phải làm gì nếu đột nhiên hết RAM khi kết hợp?
Alexey Milovidov: Có một vấn đề là mức tiêu thụ RAM dành riêng cho việc hợp nhất là không bị giới hạn. Và vấn đề thứ hai là nếu một loại hợp nhất nào đó đã được chỉ định thì nó phải được thực thi vì nó được ghi lại trong nhật ký sao chép. Nhật ký sao chép là các hành động cần thiết để đưa bản sao về trạng thái nhất quán. Nếu bạn không thực hiện các thao tác thủ công sẽ khôi phục nhật ký sao chép này, việc hợp nhất sẽ phải được thực hiện bằng cách này hay cách khác.
Tất nhiên, sẽ không thừa nếu có một giới hạn RAM để “đề phòng” bảo vệ khỏi OOM. Nó sẽ không giúp quá trình hợp nhất hoàn tất, nó sẽ bắt đầu lại, đạt đến một ngưỡng nào đó, đưa ra một ngoại lệ và sau đó bắt đầu lại - điều này sẽ không có gì tốt đẹp. Nhưng về nguyên tắc, sẽ rất hữu ích nếu đưa ra hạn chế này.
Trình điều khiển Golang cho ClickHouse sẽ được phát triển như thế nào?
Trình điều khiển Golang do Kirill Shvakov viết, hiện đã được nhóm ClickHouse hỗ trợ chính thức. Anh ta , bây giờ anh ấy đã lớn và có thật.
Một lưu ý nhỏ. Có một kho lưu trữ tuyệt vời và được yêu thích về các dạng trật tự vô hạn thông thường - đây là Vertica. Họ cũng có trình điều khiển python chính thức của riêng mình, được các nhà phát triển Vertica hỗ trợ. Và đã nhiều lần xảy ra trường hợp phiên bản lưu trữ và phiên bản trình điều khiển khác nhau khá nhiều và trình điều khiển tại một thời điểm nào đó đã ngừng hoạt động. Và điểm thứ hai. Đối với tôi, dường như việc hỗ trợ cho trình điều khiển chính thức này được thực hiện bởi hệ thống “núm vú” - bạn viết cho chúng một vấn đề và nó sẽ bị treo vĩnh viễn.
Tôi có hai câu hỏi. Giờ đây, trình điều khiển Golang của Kirill gần như là cách giao tiếp mặc định từ Golang với ClickHouse. Trừ khi ai đó vẫn giao tiếp qua giao diện http vì anh ấy thích như vậy. Sự phát triển của trình điều khiển này sẽ tiến triển như thế nào? Nó có được đồng bộ hóa với bất kỳ thay đổi đột phá nào trong kho lưu trữ không? Và thủ tục xem xét một vấn đề như thế nào?
Kirill Shvakov: Đầu tiên là cách mọi thứ được tổ chức một cách quan liêu. Điểm này chưa được thảo luận nên tôi không có gì để trả lời.
Để trả lời câu hỏi về vấn đề này, chúng ta cần một chút lịch sử của người lái xe. Tôi đã làm việc cho một công ty có rất nhiều dữ liệu. Đó là một công cụ quay vòng quảng cáo với một số lượng lớn các sự kiện cần được lưu trữ ở đâu đó. Và đến một lúc nào đó ClickHouse xuất hiện. Chúng tôi điền dữ liệu vào đó và lúc đầu mọi thứ đều ổn, nhưng sau đó ClickHouse bị lỗi. Vào thời điểm đó, chúng tôi quyết định rằng chúng tôi không cần nó.
Một năm sau, chúng tôi quay lại ý tưởng sử dụng ClickHouse và bằng cách nào đó chúng tôi cần ghi dữ liệu vào đó. Thông điệp giới thiệu là thế này: phần cứng rất yếu, có ít tài nguyên. Nhưng chúng tôi luôn làm việc theo cách này và do đó chúng tôi hướng tới giao thức gốc.
Vì chúng tôi đang làm việc trong Go nên rõ ràng là chúng tôi cần một trình điều khiển Go. Tôi đã làm việc đó gần như toàn thời gian - đó là nhiệm vụ công việc của tôi. Chúng tôi đã đưa nó đến một điểm nhất định và về nguyên tắc không ai cho rằng ai khác ngoài chúng tôi sẽ sử dụng nó. Sau đó, CloudFlare gặp phải vấn đề tương tự và trong một thời gian, chúng tôi đã làm việc với họ rất suôn sẻ vì họ có cùng nhiệm vụ. Hơn nữa, chúng tôi đã thực hiện điều này cả trong ClickHouse và trong trình điều khiển.
Tại một thời điểm nào đó, tôi đơn giản là ngừng làm việc đó vì hoạt động của tôi về ClickHouse và công việc đã thay đổi một chút. Vì vậy các vấn đề không được đóng lại. Theo định kỳ, những người cần thứ gì đó sẽ tự mình cam kết với kho lưu trữ. Sau đó, tôi xem xét yêu cầu kéo và đôi khi tôi thậm chí còn tự mình chỉnh sửa nội dung nào đó, nhưng điều này hiếm khi xảy ra.
Tôi muốn quay lại với tài xế. Vài năm trước, khi toàn bộ điều này bắt đầu, ClickHouse cũng khác và có những khả năng khác. Bây giờ chúng ta đã hiểu cách làm lại driver để nó hoạt động tốt. Nếu điều này xảy ra, thì phiên bản 2 sẽ không tương thích trong mọi trường hợp do nạng tích lũy.
Tôi không biết cách tổ chức vấn đề này. Bản thân tôi không có nhiều thời gian. Nếu một số người lái xe xong, tôi có thể giúp họ và bảo họ phải làm gì. Nhưng sự tham gia tích cực của Yandex vào việc phát triển dự án vẫn chưa được thảo luận.
Alexey Milovidov: Trên thực tế, vẫn chưa có quan liêu về những tài xế này. Điều duy nhất là chúng được gửi đến một tổ chức chính thức, tức là trình điều khiển này được công nhận là giải pháp mặc định chính thức cho Go. Có một số trình điều khiển khác, nhưng chúng đi kèm riêng biệt.
Chúng tôi không có bất kỳ sự phát triển nội bộ nào cho các trình điều khiển này. Câu hỏi đặt ra là liệu chúng ta có thể thuê một cá nhân, không phải cho người lái xe cụ thể này mà cho sự phát triển của tất cả những người lái xe trong cộng đồng, hay chúng ta có thể tìm ai đó từ bên ngoài.
Từ điển bên ngoài không tải sau khi khởi động lại với cài đặt lười_load được bật. Phải làm gì?
Chúng tôi đã bật cài đặt lười_load và sau khi máy chủ được khởi động lại, từ điển sẽ không tự tải. Nó chỉ được nâng lên sau khi người dùng truy cập từ điển này. Và lần đầu vào thì nó báo lỗi. Có thể bằng cách nào đó tự động tải từ điển bằng ClickHouse hay bạn cần luôn tự mình kiểm soát mức độ sẵn sàng của chúng để người dùng không gặp lỗi?
Có lẽ chúng ta sử dụng phiên bản ClickHouse cũ nên từ điển không được tự động tải. Đây có thể là trường hợp?
Thứ nhất, từ điển có thể được tải bằng cách sử dụng truy vấn hệ thống tải lại từ điển. Thứ hai, liên quan đến lỗi - nếu từ điển đã được tải thì các truy vấn sẽ hoạt động dựa trên dữ liệu đã được tải. Nếu từ điển chưa được tải, nó sẽ được tải trực tiếp trong quá trình yêu cầu.
Điều này không thuận tiện lắm cho những từ điển nặng. Ví dụ: bạn cần lấy một triệu hàng từ MySQL. Ai đó thực hiện một lựa chọn đơn giản, nhưng lựa chọn này sẽ đợi hàng triệu hàng giống nhau. Có hai giải pháp ở đây. Đầu tiên là tắt lười_load. Thứ hai, khi máy chủ hoạt động, trước khi tải nó, hãy thực hiện hệ thống tải lại từ điển hoặc chỉ thực hiện một truy vấn sử dụng từ điển. Sau đó từ điển sẽ được tải. Bạn cần kiểm soát tính khả dụng của từ điển khi bật cài đặt lười_load vì ClickHouse không tự động tải chúng.
Câu trả lời cho câu hỏi cuối cùng là phiên bản đã cũ hoặc cần được sửa lỗi.
Phải làm gì với thực tế là hệ thống tải lại từ điển không tải bất kỳ từ điển nào trong số nhiều từ điển nếu ít nhất một trong số chúng gặp lỗi?
Có một câu hỏi khác về việc tải lại từ điển hệ thống. Chúng tôi có hai từ điển - một từ điển chưa được tải, từ điển thứ hai được tải. Trong trường hợp này, Từ điển tải lại hệ thống không tải bất kỳ từ điển nào và bạn phải tải từng từ điển cụ thể theo tên của nó bằng cách sử dụng từ điển tải lại hệ thống. Điều này cũng liên quan đến phiên bản ClickHouse phải không?
Em muôn lam cho anh hạnh phuc. Hành vi này đã thay đổi. Điều này có nghĩa là nếu bạn cập nhật ClickHouse thì nó cũng sẽ thay đổi. Nếu bạn không hài lòng với hành vi hiện tại của mình hệ thống tải lại từ điển, cập nhật và hãy hy vọng nó sẽ thay đổi tốt hơn.
Có cách nào cấu hình chi tiết trong config ClickHouse nhưng không hiển thị khi gặp lỗi không?
Câu hỏi tiếp theo là về các lỗi liên quan đến từ điển, cụ thể là chi tiết. Chúng tôi đã chỉ định chi tiết kết nối trong cấu hình ClickHouse cho từ điển và nếu có lỗi, chúng tôi sẽ nhận được các chi tiết và mật khẩu này trong phản hồi.
Chúng tôi đã giải quyết lỗi này bằng cách thêm chi tiết vào cấu hình trình điều khiển ODBC. Có cách nào cấu hình các chi tiết trong config ClickHouse nhưng không hiển thị các chi tiết này khi gặp lỗi không?
Giải pháp thực sự ở đây là chỉ định các thông tin xác thực này trong odbc.ini và trong ClickHouse chỉ chỉ định Tên nguồn dữ liệu ODBC. Điều này sẽ không xảy ra đối với các nguồn từ điển khác - đối với từ điển có MySQL cũng như các nguồn khác, bạn sẽ không thấy mật khẩu khi nhận được thông báo lỗi. Đối với ODBC, tôi cũng sẽ xem xét - nếu nó tồn tại, bạn chỉ cần xóa nó.
Phần thưởng: hình nền cho Zoom từ các cuộc tụ họp
Bằng cách nhấp vào hình ảnh, hình nền thưởng từ các cuộc tụ họp sẽ mở ra cho những độc giả kiên trì nhất. Chúng tôi dập lửa cùng với các linh vật công nghệ Avito, chúng tôi trao đổi với các đồng nghiệp từ phòng quản trị hệ thống hoặc câu lạc bộ máy tính kiểu cũ, và chúng tôi tiến hành các cuộc họp hàng ngày dưới cầu trên phông nền vẽ bậy.
Nguồn: www.habr.com