là một hệ thống quản lý cơ sở dữ liệu cột nguồn mở để xử lý truy vấn phân tích trực tuyến (OLAP), được tạo bởi Yandex. Nó được Yandex, CloudFlare, VK.com, Badoo và các dịch vụ khác trên thế giới sử dụng để lưu trữ lượng dữ liệu thực sự lớn (chèn hàng nghìn hàng mỗi giây hoặc hàng petabyte dữ liệu được lưu trữ trên đĩa).
Trong một DBMS “chuỗi” thông thường, ví dụ như MySQL, Postgres, MS SQL Server, dữ liệu được lưu trữ theo thứ tự sau:
Trong trường hợp này, các giá trị liên quan đến một hàng được lưu trữ vật lý ở gần đó. Trong DBMS dạng cột, các giá trị từ các cột khác nhau được lưu trữ riêng biệt và dữ liệu từ một cột được lưu trữ cùng nhau:
Ví dụ về DBMS dạng cột là Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Công ty chuyển phát thư bắt đầu sử dụng Clickhouse vào năm 2018 để báo cáo và rất ấn tượng với tính đơn giản, khả năng mở rộng, hỗ trợ SQL và tốc độ của nó. Tốc độ của DBMS này gần như kỳ diệu.
Đơn giản
Clickhouse được cài đặt trên Ubuntu chỉ bằng một lệnh duy nhất. Nếu biết SQL, bạn có thể bắt đầu sử dụng Clickhouse ngay cho nhu cầu của mình. Tuy nhiên, điều này không có nghĩa là bạn có thể thực hiện “hiển thị tạo bảng” trong MySQL và sao chép-dán SQL trong Clickhouse.
So với MySQL, có những khác biệt quan trọng về kiểu dữ liệu trong định nghĩa lược đồ bảng, vì vậy bạn sẽ vẫn cần một chút thời gian để thay đổi định nghĩa lược đồ bảng và tìm hiểu các công cụ tạo bảng để làm quen.
Clickhouse hoạt động tốt mà không cần bất kỳ phần mềm bổ sung nào, nhưng nếu muốn sử dụng bản sao, bạn sẽ cần cài đặt ZooKeeper. Phân tích hiệu suất truy vấn cho thấy kết quả tuyệt vời - các bảng hệ thống chứa tất cả thông tin và tất cả dữ liệu có thể được truy xuất bằng SQL cũ và nhàm chán.
Năng suất
- so sánh Clickhouse với Vertica và MySQL về cấu hình máy chủ: 5 socket Intel® Xeon® CPU E2650-2 v2.60 @ 128GHz; RAM 5 GiB; md RAID-8 trên 6 ổ cứng SATA 4TB, extXNUMX.
- so sánh Clickhouse với bộ lưu trữ đám mây Amazon RedShift.
- Trích đoạn blog :
Cơ sở dữ liệu ClickHouse có thiết kế rất đơn giản - tất cả các nút trong cụm đều có chức năng giống nhau và chỉ sử dụng ZooKeeper để phối hợp. Chúng tôi đã xây dựng một cụm nhỏ gồm một số nút và thực hiện thử nghiệm, trong đó chúng tôi nhận thấy rằng hệ thống này có hiệu suất khá ấn tượng, tương ứng với những ưu điểm đã nêu trong các tiêu chuẩn phân tích DBMS. Chúng tôi quyết định xem xét kỹ hơn khái niệm đằng sau ClickHouse. Trở ngại đầu tiên cho việc nghiên cứu là thiếu công cụ và cộng đồng ClickHouse nhỏ, vì vậy chúng tôi đã nghiên cứu kỹ thiết kế của DBMS này để hiểu cách thức hoạt động của nó.
ClickHouse không hỗ trợ nhận dữ liệu trực tiếp từ Kafka vì đây chỉ là cơ sở dữ liệu, vì vậy chúng tôi đã viết dịch vụ bộ điều hợp của riêng mình trong Go. Nó đọc các tin nhắn được mã hóa Cap'n Proto từ Kafka, chuyển đổi chúng thành TSV và chèn chúng vào ClickHouse theo đợt thông qua giao diện HTTP. Sau đó chúng tôi đã viết lại dịch vụ này để sử dụng thư viện Go kết hợp với giao diện riêng của ClickHouse nhằm cải thiện hiệu suất. Khi đánh giá hiệu suất nhận gói, chúng tôi phát hiện ra một điều quan trọng - hóa ra đối với ClickHouse, hiệu suất này phụ thuộc rất nhiều vào kích thước của gói, tức là số lượng hàng được chèn đồng thời. Để hiểu lý do tại sao điều này xảy ra, chúng tôi đã xem xét cách ClickHouse lưu trữ dữ liệu.
Công cụ chính, hay đúng hơn là họ công cụ bảng, được ClickHouse sử dụng để lưu trữ dữ liệu là MergeTree. Công cụ này về mặt khái niệm tương tự như thuật toán LSM được sử dụng trong Google BigTable hoặc Apache Cassandra, nhưng tránh việc xây dựng bảng bộ nhớ trung gian và ghi dữ liệu trực tiếp vào đĩa. Điều này mang lại cho nó thông lượng ghi tuyệt vời vì mỗi gói được chèn chỉ được sắp xếp theo khóa chính, được nén và ghi vào đĩa để tạo thành một phân đoạn.
Việc không có bảng bộ nhớ hay bất kỳ khái niệm nào về “mới” của dữ liệu cũng có nghĩa là chúng chỉ có thể được thêm vào, hệ thống không hỗ trợ thay đổi hoặc xóa. Hiện tại, cách duy nhất để xóa dữ liệu là xóa dữ liệu theo tháng dương lịch vì các phân đoạn không bao giờ vượt quá ranh giới tháng. Nhóm ClickHouse đang tích cực làm việc để tùy chỉnh tính năng này. Mặt khác, nó làm cho việc ghi và hợp nhất các phân đoạn không bị tranh chấp, do đó thông lượng nhận sẽ tăng tỷ lệ tuyến tính với số lần chèn đồng thời cho đến khi xảy ra bão hòa I/O hoặc lõi.
Tuy nhiên, điều này cũng có nghĩa là hệ thống không phù hợp với các gói nhỏ, vì vậy các dịch vụ và bộ chèn Kafka được sử dụng để đệm. Tiếp theo, ClickHouse ở chế độ nền tiếp tục liên tục thực hiện việc hợp nhất các phân đoạn, nhờ đó nhiều mẩu thông tin nhỏ sẽ được kết hợp và ghi lại nhiều lần hơn, do đó làm tăng cường độ ghi. Tuy nhiên, quá nhiều phần không được kết nối sẽ gây ra hiện tượng điều chỉnh mạnh các phần chèn miễn là quá trình hợp nhất vẫn tiếp tục. Chúng tôi nhận thấy rằng sự thỏa hiệp tốt nhất giữa hiệu suất nhập và nhập theo thời gian thực là nhập một số lượng hạn chế các lần chèn mỗi giây vào bảng.
Chìa khóa cho hiệu suất đọc bảng là lập chỉ mục và vị trí của dữ liệu trên đĩa. Dù quá trình xử lý có nhanh đến đâu, khi động cơ cần quét hàng terabyte dữ liệu từ đĩa và chỉ sử dụng một phần trong đó thì sẽ rất mất thời gian. ClickHouse là một kho lưu trữ dạng cột nên mỗi đoạn chứa một file cho mỗi cột (cột) với các giá trị được sắp xếp cho mỗi hàng. Bằng cách này, toàn bộ các cột bị thiếu trong truy vấn có thể được bỏ qua trước tiên, sau đó nhiều ô có thể được xử lý song song với việc thực thi theo vectơ. Để tránh quét toàn bộ, mỗi phân đoạn có một tệp chỉ mục nhỏ.
Vì tất cả các cột được sắp xếp theo “khóa chính”, tệp chỉ mục chỉ chứa nhãn (hàng đã bắt) của mỗi hàng thứ N để có thể lưu chúng trong bộ nhớ ngay cả đối với các bảng rất lớn. Ví dụ: bạn có thể đặt cài đặt mặc định thành “đánh dấu mỗi hàng thứ 8192”, sau đó lập chỉ mục “ít ỏi” của một bảng có 1 nghìn tỷ. những dòng dễ dàng ghi vào bộ nhớ sẽ chỉ có 122 ký tự.
Phát triển hệ thống
Sự phát triển và cải tiến của Clickhouse có thể được bắt nguồn từ và đảm bảo rằng quá trình “lớn lên” diễn ra với tốc độ ấn tượng.
Phổ biến
Mức độ phổ biến của Clickhouse dường như đang tăng lên theo cấp số nhân, đặc biệt là trong cộng đồng nói tiếng Nga. Hội nghị Tải trọng cao 2018 năm ngoái (Moscow, ngày 8-9 tháng 2018 năm 40) đã cho thấy những con quái vật như vk.com và Badoo sử dụng Clickhouse, trong đó chúng chèn dữ liệu (ví dụ: nhật ký) từ hàng chục nghìn máy chủ cùng một lúc. Trong một video dài XNUMX phút . Chúng tôi sẽ sớm đăng bản ghi lên Habr để dễ dàng làm việc với tài liệu.
Ứng dụng
Sau khi dành thời gian nghiên cứu, tôi nghĩ rằng có những lĩnh vực mà ClickHouse có thể hữu ích hoặc có thể thay thế hoàn toàn các giải pháp truyền thống và phổ biến khác như MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot và Druid. Phần sau đây mô tả chi tiết cách sử dụng ClickHouse để hiện đại hóa hoặc thay thế hoàn toàn DBMS trên.
Mở rộng khả năng của MySQL và PostgreSQL
Gần đây, chúng tôi đã thay thế một phần MySQL bằng ClickHouse cho nền tảng bản tin của mình . Vấn đề là MySQL, do thiết kế kém, đã ghi lại mọi email được gửi và mọi liên kết trong email đó bằng hàm băm base64, tạo ra một bảng MySQL khổng lồ (email_stats). Sau khi chỉ gửi 10 triệu email cho các thuê bao dịch vụ, bảng này đã chiếm 150 GB dung lượng tệp và MySQL bắt đầu “ngu ngốc” với các truy vấn đơn giản. Để khắc phục sự cố không gian tệp, chúng tôi đã sử dụng thành công tính năng nén bảng InnoDB, giúp giảm hệ số 4. Tuy nhiên, vẫn không có ý nghĩa gì nếu lưu trữ hơn 20-30 triệu email trong MySQL chỉ vì mục đích đọc lịch sử, vì bất kỳ truy vấn đơn giản nào vì lý do nào đó cần phải quét toàn bộ sẽ dẫn đến trao đổi và rất nhiều trong số đó /O tải, theo đó chúng tôi thường xuyên nhận được cảnh báo từ Zabbix.
Clickhouse sử dụng hai thuật toán nén giúp giảm khối lượng dữ liệu xuống khoảng , nhưng trong trường hợp cụ thể này, dữ liệu đặc biệt "có thể nén được".
Thay thế ELK
Dựa trên kinh nghiệm của riêng tôi, ngăn xếp ELK (ElasticSearch, Logstash và Kibana, trong trường hợp cụ thể này là ElasticSearch) yêu cầu nhiều tài nguyên để chạy hơn mức cần thiết để lưu trữ nhật ký. ElasticSearch là một công cụ tuyệt vời nếu bạn cần tìm kiếm nhật ký toàn văn bản tốt (điều mà tôi không nghĩ là bạn thực sự cần), nhưng tôi đang tự hỏi tại sao nó lại trở thành công cụ ghi nhật ký tiêu chuẩn trên thực tế. Hiệu suất nạp của nó kết hợp với Logstash đã gây ra cho chúng tôi sự cố ngay cả khi tải khá nhẹ và yêu cầu chúng tôi ngày càng bổ sung thêm RAM và dung lượng ổ đĩa. Là một cơ sở dữ liệu, Clickhouse tốt hơn ElasticSearch vì những lý do sau:
- Hỗ trợ phương ngữ SQL;
- Mức độ nén dữ liệu được lưu trữ tốt nhất;
- Hỗ trợ tìm kiếm biểu thức chính quy Regex thay vì tìm kiếm toàn văn;
- Lập kế hoạch truy vấn được cải thiện và hiệu suất tổng thể cao hơn.
Hiện tại, vấn đề lớn nhất nảy sinh khi so sánh ClickHouse với ELK là thiếu giải pháp tải nhật ký lên cũng như thiếu tài liệu và hướng dẫn về chủ đề này. Hơn nữa, mỗi người dùng có thể định cấu hình ELK bằng hướng dẫn sử dụng Digital Ocean, điều này rất quan trọng để triển khai nhanh chóng các công nghệ đó. Có công cụ cơ sở dữ liệu nhưng chưa có Filebeat cho ClickHouse. Vâng, nó ở đó và một hệ thống làm việc với nhật ký , có một công cụ để nhập dữ liệu tệp nhật ký vào ClickHouse, nhưng tất cả việc này sẽ mất nhiều thời gian hơn. Tuy nhiên, ClickHouse vẫn dẫn đầu nhờ tính đơn giản nên ngay cả những người mới bắt đầu cũng có thể dễ dàng cài đặt và bắt đầu sử dụng đầy đủ chức năng chỉ sau 10 phút.
Thích các giải pháp tối giản hơn, tôi đã thử sử dụng FluentBit, một công cụ gửi nhật ký có rất ít bộ nhớ, cùng với ClickHouse, đồng thời cố gắng tránh sử dụng Kafka. Tuy nhiên, những điểm không tương thích nhỏ cần được giải quyết, chẳng hạn như trước khi điều này có thể được thực hiện mà không cần lớp proxy chuyển đổi dữ liệu từ FluentBit sang ClickHouse.
Thay vào đó, Kibana có thể được sử dụng làm phụ trợ ClickHouse . Theo những gì tôi hiểu, điều này có thể gây ra vấn đề về hiệu suất khi hiển thị số lượng lớn điểm dữ liệu, đặc biệt là với các phiên bản Grafana cũ hơn. Chúng tôi chưa thử điều này tại Qwintry, nhưng thỉnh thoảng những lời phàn nàn về điều này vẫn xuất hiện trên kênh hỗ trợ ClickHouse trên Telegram.
Thay thế Google Big Query và Amazon RedShift (giải pháp cho các công ty lớn)
Trường hợp sử dụng lý tưởng cho BigQuery là tải 1 TB dữ liệu JSON và chạy các truy vấn phân tích trên đó. Big Query là một sản phẩm tuyệt vời có khả năng mở rộng không thể phủ nhận. Đây là phần mềm phức tạp hơn nhiều so với ClickHouse, chạy trên một cụm nội bộ, nhưng theo quan điểm của khách hàng, nó có nhiều điểm chung với ClickHouse. BigQuery có thể trở nên đắt đỏ một cách nhanh chóng khi bạn bắt đầu trả tiền cho mỗi CHỌN, vì vậy đây là một giải pháp SaaS thực sự với tất cả ưu và nhược điểm.
ClickHouse là lựa chọn tốt nhất khi bạn đang chạy nhiều truy vấn tốn kém về mặt tính toán. Bạn càng chạy nhiều truy vấn SELECT mỗi ngày thì việc thay thế Big Query bằng ClickHouse càng có ý nghĩa vì việc thay thế như vậy có thể giúp bạn tiết kiệm hàng nghìn đô la khi xử lý nhiều terabyte dữ liệu. Điều này không áp dụng cho dữ liệu được lưu trữ, vốn khá rẻ để xử lý trong Big Query.
Trong một bài viết của người đồng sáng lập Altinity Alexander Zaitsev nói về lợi ích của việc di chuyển DBMS như vậy.
Thay thế TimescaleDB
TimescaleDB là một tiện ích mở rộng PostgreSQL giúp tối ưu hóa hoạt động với chuỗi thời gian trong cơ sở dữ liệu thông thường (, ).
Mặc dù ClickHouse không phải là đối thủ nặng ký trong lĩnh vực chuỗi thời gian, nhưng cấu trúc cột và thực thi truy vấn vectơ, nó nhanh hơn nhiều so với TimescaleDB trong hầu hết các trường hợp xử lý truy vấn phân tích. Đồng thời, hiệu suất nhận dữ liệu hàng loạt từ ClickHouse cao hơn khoảng 3 lần và nó cũng sử dụng dung lượng ổ đĩa ít hơn 20 lần, điều này thực sự quan trọng để xử lý khối lượng lớn dữ liệu lịch sử: .
Không giống như ClickHouse, cách duy nhất để tiết kiệm dung lượng ổ đĩa trong TimescaleDB là sử dụng ZFS hoặc các hệ thống tệp tương tự.
Các bản cập nhật sắp tới cho ClickHouse có thể sẽ giới thiệu tính năng nén delta, điều này sẽ khiến nó phù hợp hơn nữa để xử lý và lưu trữ dữ liệu chuỗi thời gian. TimescaleDB có thể là lựa chọn tốt hơn ClickHouse trần trong các trường hợp sau:
- cài đặt nhỏ với rất ít RAM (<3 GB);
- một số lượng lớn các INSERT nhỏ mà bạn không muốn đệm vào các đoạn lớn;
- các yêu cầu về tính nhất quán, đồng nhất và ACID tốt hơn;
- Hỗ trợ PostGIS;
- tham gia với các bảng PostgreSQL hiện có, vì Timescale DB về cơ bản là PostgreSQL.
Cạnh tranh với hệ thống Hadoop và MapReduce
Hadoop và các sản phẩm MapReduce khác có thể thực hiện nhiều phép tính phức tạp nhưng chúng có xu hướng chạy với độ trễ rất lớn. ClickHouse khắc phục sự cố này bằng cách xử lý hàng terabyte dữ liệu và tạo ra kết quả gần như ngay lập tức. Do đó, ClickHouse hiệu quả hơn nhiều trong việc thực hiện nghiên cứu phân tích tương tác nhanh chóng, điều này sẽ được các nhà khoa học dữ liệu quan tâm.
Cạnh tranh với Pinot và Druid
Đối thủ cạnh tranh gần nhất của ClickHouse là các sản phẩm mã nguồn mở có khả năng mở rộng tuyến tính Pinot và Druid. Một công trình xuất sắc so sánh các hệ thống này được công bố trong bài báo Ngày 1 tháng 2018 năm XNUMX
Bài viết này cần cập nhật - nó nói rằng ClickHouse không hỗ trợ các thao tác CẬP NHẬT và XÓA, điều này không hoàn toàn đúng đối với các phiên bản mới nhất.
Chúng tôi không có nhiều kinh nghiệm với các cơ sở dữ liệu này, nhưng tôi không thực sự thích sự phức tạp của cơ sở hạ tầng cần thiết để chạy Druid và Pinot - đó là một loạt các bộ phận chuyển động được bao quanh bởi Java ở mọi phía.
Druid và Pinot là các dự án ươm tạo Apache, tiến trình của dự án này được Apache trình bày chi tiết trên các trang dự án GitHub của mình. Pinot xuất hiện trong lồng ấp vào tháng 2018 năm 8 và Druid chào đời trước đó XNUMX tháng - vào tháng Hai.
Việc thiếu thông tin về cách thức hoạt động của AFS đặt ra một số câu hỏi, và có lẽ là ngu ngốc, đối với tôi. Tôi tự hỏi liệu các tác giả Pinot có nhận thấy rằng Quỹ Apache có thiện cảm hơn với Druid hay không và liệu thái độ này đối với đối thủ cạnh tranh có gây ra cảm giác ghen tị không? Liệu sự phát triển của Druid có chậm lại và sự phát triển của Pinot sẽ tăng tốc nếu những người ủng hộ cái trước đột nhiên quan tâm đến cái sau?
Nhược điểm của ClickHouse
Tính non nớt: Rõ ràng, đây vẫn không phải là một công nghệ nhàm chán, nhưng trong mọi trường hợp, không có điều gì giống như thế này được quan sát thấy trong các DBMS dạng cột khác.
Các phần chèn nhỏ không hoạt động tốt ở tốc độ cao: các phần chèn phải được chia thành các phần lớn hơn vì hiệu suất của các phần chèn nhỏ giảm tỷ lệ thuận với số lượng cột trong mỗi hàng. Đây là cách ClickHouse lưu trữ dữ liệu trên đĩa - mỗi cột đại diện cho 1 file trở lên nên để chèn 1 hàng chứa 100 cột bạn cần mở và ghi ít nhất 100 file. Đây là lý do tại sao việc chèn bộ đệm cần có người trung gian (trừ khi chính máy khách cung cấp bộ đệm) - thường là Kafka hoặc một số loại hệ thống quản lý hàng đợi. Bạn cũng có thể sử dụng công cụ bảng Buffer để sao chép khối dữ liệu lớn vào bảng MergeTree sau này.
Việc nối bảng bị giới hạn bởi RAM của máy chủ, nhưng ít nhất chúng vẫn ở đó! Ví dụ: Druid và Pinot hoàn toàn không có các kết nối như vậy vì chúng khó triển khai trực tiếp trong các hệ thống phân tán không hỗ trợ di chuyển khối dữ liệu lớn giữa các nút.
Những phát hiện
Chúng tôi dự định sử dụng rộng rãi ClickHouse trong Qwintry trong những năm tới vì DBMS này cung cấp sự cân bằng tuyệt vời về hiệu suất, chi phí thấp, khả năng mở rộng và tính đơn giản. Tôi khá chắc chắn rằng nó sẽ bắt đầu lan truyền nhanh chóng khi cộng đồng ClickHouse tìm ra nhiều cách hơn để sử dụng nó trong các cơ sở lắp đặt vừa và nhỏ.
Một số quảng cáo 🙂
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com