Timeplus Proton Documentation

MetroHash is a collection of high-performance, non-cryptographic hash functions optimized for modern x86-64 microarchitectures.

Key features include:

• Performance: Designed for both bulk hashing and small, variable-length keys.
• Statistical Robustness: Maintains a statistical bias profile similar to the MD5 cryptographic hash.
• Incremental Construction: Supports building hashes from data streams via Update and Finalize.
• Variants: Provides 64-bit, 128-bit, and 128-bit CRC variants.
• Statistical Uniqueness: Functions within the same family (e.g., metrohash64_1 and metrohash64_2) are statistically unique, making them suitable for use together in structures like Bloom filters.

The GitHub Events dataset is a large-scale dataset containing all GitHub events from 2011 to December 6, 2020. It consists of approximately 3.1 billion records.

Storage Requirements:

• Download size: ~75 GB
• Disk space required: Up to 200 GB (when stored in a table using lz4 compression).

For full dataset descriptions, insights, download instructions, and interactive queries, visit the official documentation at https://ghe.clickhouse.tech/.

Timeplus Proton is a high-performance SQL pipeline engine designed for stream processing, analytics, observability, and AI. It serves as a lightweight, C++ based alternative to Apache Flink and ksqlDB.

Key features include:

• Native Source/Sink Support: Connects to Kafka, ClickHouse, MySQL, Postgres, MongoDB, S3/Iceberg, OpenSearch, etc.
• Streaming Capabilities: Supports streaming ingestion, multi-stream JOINs, incremental materialized views, and watermarks.
• Extensibility: Supports User Defined Functions (UDF) in Python and JS.
• Zero Dependencies: No JVM or ZooKeeper required; it is distributed as a single binary (<500MB).

The clickhouse-local program allows you to perform high-speed data processing on local files using the ClickHouse SQL dialect without deploying a full ClickHouse server. It supports most ClickHouse features, formats, and table engines.

By default, it uses a unique temporary data directory. While it supports loading server configurations via --config-file, it is not recommended to load production server configurations into clickhouse-local as it may lead to accidental data damage.

clickhouse-odbc-bridge is an HTTP server that acts as a proxy for ODBC drivers. It is designed to prevent ODBC implementation faults (like segfaults) from crashing the main clickhouse-server process by isolating the ODBC driver execution within this separate process.

While typically used internally by clickhouse-server via the odbc table function or StorageODBC, it can be run as a standalone tool. It accepts queries via HTTP POST requests and returns results in RowBinary format.

HTAP refers to the trend of modern database systems attempting to handle both transactional (OLTP) and analytical (OLAP) workloads equally well within a single system.

Historically, businesses had to operate multiple integrated storage systems to satisfy both needs, which increased maintenance costs. HTAP aims to reduce this complexity by providing a single system that can manage continuous transaction streams while also supporting high-performance analytical reporting.

The MergeTree engine and its derivatives (the *MergeTree family) are designed for high-performance ingestion of very large datasets. Instead of rewriting existing data during every insert, data is written to the table in parts, and background processes apply merging rules to these parts to optimize storage and performance.

Key capabilities include:

• Primary Key Sorting: Data is stored sorted by a primary key, enabling the creation of a sparse index for fast data retrieval.
• Partitioning: If a partitioning key is specified, data can be organized into partitions, allowing for more efficient operations and automatic data pruning during queries.
• Data Replication: The ReplicatedMergeTree variant provides support for data replication across nodes.
• Data Sampling: Supports setting specific data sampling methods at the table level.

A "first significant subdomain" is a non-standard concept used to identify the core part of a domain. By default, if a second-level domain is com, net, org, or co, the first significant subdomain is that second-level domain; otherwise, it is the third-level domain.

Standard Functions

• firstSignificantSubdomain(url): Returns the first significant subdomain.
• cutToFirstSignificantSubdomain(url): Returns the domain part including top-level subdomains up to the first significant subdomain (e.g., news.yandex.com.tr $\rightarrow$ yandex.com.tr).
• cutToFirstSignificantSubdomainWithWWW(url): Same as above, but does not strip the www prefix.
• domainWithoutWWW(url): Returns the domain after removing at most one www. from the beginning.