diff --git a/TOC.md b/TOC.md index 4a7a288e6a0ee..b926a2b7e71f6 100644 --- a/TOC.md +++ b/TOC.md @@ -2,13 +2,12 @@ ## Index -+ [Introduction](/introduction/introduction.md) ++ [Introduction](/introduction/StarRocks_intro.md) + Quick Start - + [Concepts](/quick_start/concepts.md) - + [Architecture](/quick_start/architecture.md) - + [Deploy](/quick_start/deploy.md) - + [Data flow and control flow](/quick_start/data_flow_and_control_flow.md) - + [Import and query](/quick_start/import_and_query.md) - + [Test FAQs](/quick_start/test_faq.md) - + [Next Step](/quick_start/next_step.md) - \ No newline at end of file + + [Concepts](/quick_start/Concepts.md) + + [Architecture](/quick_start/Architecture.md) + + [Deploy](/quick_start/Deploy.md) + + [Data flow and control flow](/quick_start/Data_flow_and_control_flow.md) + + [Import and query](/quick_start/Import_and_query.md) + + [Test FAQs](/quick_start/Test_faq.md) + diff --git a/assets/2.5-1.png b/assets/2.5-1.png index 4790eb47faa30..5bfe17d72188f 100644 Binary files a/assets/2.5-1.png and b/assets/2.5-1.png differ diff --git a/introduction/StarRocks_intro.md b/introduction/StarRocks_intro.md new file mode 100644 index 0000000000000..896d41211e4d3 --- /dev/null +++ b/introduction/StarRocks_intro.md @@ -0,0 +1,66 @@ +# Introduction + +## What is StarRocks + +* StarRocks is a high-performance, MySQL-compatible, distributed relational columnar database. It has been tested and modernized by the industry for multiple data analysis scenarios. + +* StarRocks takes advantage of the relational Online Analytical Processing (OLAP) database and distributed storage system. Through architectural upgrades and functional optimization, StarRocks has developed into an enterprise-level product. + +* StarRocks is committed to accommodating multiple data analysis scenarios for enterprise users. It supports multiple data warehouse schemas(flat tables, pre-aggregations, star or snowflake schema), multiple data import methods (batch and streaming) and allows direct access to data from Hive, MySQL and Elasticsearch without importing. + +* StarRocks is compatible with the MySQL protocol. Users can use the MySQL client and common Business Intelligence (BI) tools to connect to StarRocks for data analysis. + +* StarRocks uses a distributed architecture to divide the table horizontally and store it in multiple replications. The clusters are highly scalable and therefore support 1) 10PB-level data analysis, 2) Massively Parallel Processing (MPP), and 3) data replication and elastic fault tolerance. + +* Leveraging a relational model, strong data typing, and a columnar storage engine, StarRocks reduces read-write amplification through encoding and compression techniques. Using vectorized query execution, it fully unleashes the power of parallel computing on multi-core CPUs, therefore significantly improves query performance. + +## Main features + +The architectural design of StarRocks integrates the MPP database and the design ideas of distributed systems, and has the following advantages: + +### Simple architecture + +StarRocks does not rely on any external systems. The simple architecture makes it easy to deploy, maintain and scale out. + +### Native vectorized SQL engine + +StarRocks adopts vectorization technology to make full use of the parallel computing power of CPU, achieving sub-second query returns in multi-dimensional analyses. Administrators only need to focus on the StarRocks system itself, without having to learn and manage other external systems. + +### Query optimization + +StarRocks can optimize complex queries through CBO (Cost Based Optimizer). With a better execution plan, the data analysis efficiency will be greatly improved. + +### Query federation + +StarRocks allows direct access to data from Hive, MySQL and Elasticsearch without importing. + +### Efficiently update + +The updated model of StarRocks can perform upsert/delete operations according to the primary key, and achieve efficient query while concurrent updates. + +### Intelligent materialized view + +StarRocks supports intelligent materialized views. Users can create materialized views and generate pre-aggregated tables to speed up aggregate queries. StarRocks's materialized view automatically runs the aggregation when data is imported, keeping it consistent with the original table. When querying, users do not need to specify a materialized view, StarRocks can automatically select the best-materialized view to satisfy the query. + +### Standard SQL + +StarRocks supports standard SQL syntax, including aggregation, JOIN, sorting, window functions, and custom functions. Users can perform data analysis with standard SQL. In addition, StarRocks is compatible with MySQL protocol. Users can use various existing client tools and BI software to access StarRocks and perform data analysis with a simple drag-and-drop in StarRocks. + +### Unified batch and streaming + +StarRocks supports batch and streaming data import. It supports Kafka, HDFS, and local files as data sources, and ORC, Parquet, and CSV data formats. StarRocks can consume real-time Kafka data in data importing to avoid data loss or duplication. StarRocks can also import data in batches from local or remote (HDFS) data sources. + +### High availability, high scalability + +StarRocks supports multi-replica data storage and multi-instance data deployment. The cluster has the ability of self-healing and elastic recovery. + +StarRocks adopts a distributed architecture which allows its storage capacity and computing power to be scaled horizontally. StarRocks clusters can be expanded to hundreds of nodes to support up to 10PB data storage. + +## Use Case + +StarRocks can meet a variety of analysis needs, including OLAP analysis, customized reports, real-time data analysis, ad hoc data analysis, etc. Specific business scenarios include: + +* OLAP analysis +* Real time data analysis +* High concurrency query +* Unified analysis diff --git a/introduction/introduction.md b/introduction/introduction.md deleted file mode 100644 index f343848fd4527..0000000000000 --- a/introduction/introduction.md +++ /dev/null @@ -1,66 +0,0 @@ -# Introduction - -## What is DorisDB - -* DorisDB is a high-performance, MySQL-compatible, distributed relational columnar database. It has been tested and modernized by the industry for multiple data analysis scenarios. - -* DorisDB takes advantage of the relational Online Analytical Processing (OLAP) database and distributed storage system. Through architectural upgrades and functional optimization, DorisDB has developed into an enterprise-level product. - -* DorisDB is committed to accommodating multiple data analysis scenarios for enterprise users. It supports multiple data warehouse schemas(flat tables, pre-aggregations, star or snowflake schema), multiple data import methods (batch and streaming) and allows direct access to data from Hive, MySQL and Elasticsearch without importing. - -* DorisDB is compatible with the MySQL protocol. Users can use the MySQL client and common Business Intelligence (BI) tools to connect to DorisDB for data analysis. - -* DorisDB uses a distributed architecture to divide the table horizontally and store it in multiple replications. The clusters are highly scalable and therefore support 1) 10PB-level data analysis, 2) Massively Parallel Processing (MPP), and 3) data replication and elastic fault tolerance. - -* Leveraging a relational model, strong data typing, and a columnar storage engine, DorisDB reduces read-write amplification through encoding and compression techniques. Using vectorized query execution, it fully unleashes the power of parallel computing on multi-core CPUs, therefore significantly improves query performance. - -## Main features - -The architectural design of DorisDB integrates the MPP database and the design ideas of distributed systems, and has the following advantages: - -### Simple architecture - -DorisDB does not rely on any external systems. The simple architecture makes it easy to deploy, maintain and scale out. - -### Native vectorized SQL engine - -DorisDB adopts vectorization technology to make full use of the parallel computing power of CPU, achieving sub-second query returns in multi-dimensional analyses. Administrators only need to focus on the DorisDB system itself, without having to learn and manage other external systems. - -### Query optimization - -DorisDB can optimize complex queries through CBO (Cost Based Optimizer). With a better execution plan, the data analysis efficiency will be greatly improved. - -### Query federation - -DorisDB allows direct access to data from Hive, MySQL and Elasticsearch without importing. - -### Efficiently update - -The updated model of DorisDB can perform upsert/delete operations according to the primary key, and achieve efficient query while concurrent updates. - -### Intelligent materialized view - -DorisDB supports intelligent materialized views. Users can create materialized views and generate pre-aggregated tables to speed up aggregate queries. DorisDB's materialized view automatically runs the aggregation when data is imported, keeping it consistent with the original table. When querying, users do not need to specify a materialized view, DorisDB can automatically select the best-materialized view to satisfy the query. - -### Standard SQL - -DorisDB supports standard SQL syntax, including aggregation, JOIN, sorting, window functions, and custom functions. Users can perform data analysis with standard SQL. In addition, DorisDB is compatible with MySQL protocol. Users can use various existing client tools and BI software to access DorisDB and perform data analysis with a simple drag-and-drop in DorisDB. - -### Unified batch and streaming - -DorisDB supports batch and streaming data import. It supports Kafka, HDFS, and local files as data sources, and ORC, Parquet, and CSV data formats. DorisDB can consume real-time Kafka data in data importing to avoid data loss or duplication. DorisDB can also import data in batches from local or remote (HDFS) data sources. - -### High availability, high scalability - -DorisDB supports multi-replica data storage and multi-instance data deployment. The cluster has the ability of self-healing and elastic recovery. - -DorisDB adopts a distributed architecture which allows its storage capacity and computing power to be scaled horizontally. DorisDB clusters can be expanded to hundreds of nodes to support up to 10PB data storage. - -## Use Case - -Dorisdb can meet a variety of analysis needs, including OLAP analysis, customized reports, real-time data analysis, ad hoc data analysis, etc. Specific business scenarios include: - -* OLAP analysis -* Real time data analysis -* High concurrency query -* Unified analysis diff --git a/quick_start/architecture.md b/quick_start/Architecture.md similarity index 93% rename from quick_start/architecture.md rename to quick_start/Architecture.md index c457bf2985d03..8c0afc25bb870 100644 --- a/quick_start/architecture.md +++ b/quick_start/Architecture.md @@ -1,4 +1,4 @@ -# DorisDB System Architecture +# StarRocks System Architecture ## System Architecture Diagram @@ -6,7 +6,7 @@ ## Components -The DorisDB cluster is composed of FE and BE, and can be accessed via MySQL client. +The StarRocks cluster is composed of FE and BE, and can be accessed via MySQL client. ### FE @@ -31,5 +31,4 @@ The DorisDB cluster is composed of FE and BE, and can be accessed via MySQL clie ### Other Components -* Management Platform * Hdfs Broker diff --git a/quick_start/Concepts.md b/quick_start/Concepts.md new file mode 100644 index 0000000000000..ff2614550329e --- /dev/null +++ b/quick_start/Concepts.md @@ -0,0 +1,6 @@ +# Basic Concepts of StarRocks + +* FE: The StarRocks frontend node is responsible for metadata management, management of client connectors, query planning, query scheduling, and so on. +* BE: The StarRocks backend node is responsible for data storage, calculation execution, compaction, replication management, and so on. +* Broker: A transit service that connects external data such as HDFS and object storage, assisting import and export functions. +* Tablet: The logical sharding of a StarRocks table, as well as the basic unit of copy management. Each table is divided into multiple tablets and stored on different BE nodes according to the partitioning and bucketing mechanisms. diff --git a/quick_start/data_flow_and_control_flow.md b/quick_start/Data_flow_and_control_flow.md similarity index 100% rename from quick_start/data_flow_and_control_flow.md rename to quick_start/Data_flow_and_control_flow.md diff --git a/quick_start/deploy.md b/quick_start/Deploy.md similarity index 87% rename from quick_start/deploy.md rename to quick_start/Deploy.md index afeaee3ba7b39..337d0dff03502 100644 --- a/quick_start/deploy.md +++ b/quick_start/Deploy.md @@ -4,12 +4,12 @@ Manual deployment allows users to quickly leverage Doris DB to do operation and ## Get the Binary Package -Please download the latest stable version of the DorisDB binary package. +Please download the latest stable version of the StarRocks binary package. -For example, below is what you get after decompressing the package “dorisdb-1.0.0.tar.gz”: +For example, below is what you get after decompressing the package “starrocks-1.0.0.tar.gz”: ```Plain Text -DorisDB-XX-1.0.0 +StarRocks-XX-1.0.0 ├── be  # BE Catalog @@ -25,7 +25,7 @@ DorisDB-XX-1.0.0 │   ├── lib -│   │   ├── dorisdb_be  # BE executable file +│   │   ├── starrocks_be  # BE executable file │   │   └── meta_tool @@ -45,7 +45,7 @@ DorisDB-XX-1.0.0 │   ├── lib -│   │   ├── dorisdb-fe.jar  # FE jar package +│   │   ├── starrocks-fe.jar  # FE jar package │   │   └── *.jar           # FE dependent jar packages @@ -61,7 +61,7 @@ You need three physical machines that support: * Linux (Centos 7+) * Java 1.8+ -The CPU needs to support AVX2 instruction sets. When running `cat /proc/cpuinfo |grep avx2`, you should get a result output indicating the support. If not, we recommend that you replace the machine. DorisDB uses vectorization technology that requires instruction set support to be effective. +The CPU needs to support AVX2 instruction sets. When running `cat /proc/cpuinfo |grep avx2`, you should get a result output indicating the support. If not, we recommend that you replace the machine. StarRocks uses vectorization technology that requires instruction set support to be effective. You can distribute and decompress the binary package to the deployment path of your target host, and create a user account to manage it. @@ -69,11 +69,11 @@ You can distribute and decompress the binary package to the deployment path of y ### Basic Configuration for FE -The FE configuration file is `DorisDB-XX-1.0.0/fe/conf/fe.conf`. The default configuration is sufficient to start the cluster. +The FE configuration file is `StarRocks-XX-1.0.0/fe/conf/fe.conf`. The default configuration is sufficient to start the cluster. ### FE Single Instance Deployment -cd DorisDB-XX-1.0.0/fe +cd StarRocks-XX-1.0.0/fe Step 1: Customize the configuration file `conf/fe.conf`. @@ -81,7 +81,7 @@ Step 1: Customize the configuration file `conf/fe.conf`. JAVA_OPTS = "-Xmx4096m -XX:+UseMembar -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=7 -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -Xloggc:$DORIS_HOME/log/fe.gc.log" ``` -You can adjust `-Xmx4096m` basd on the FE memory size. Recommend to set the memory size to 16G or above to avoid GC. All DorisDB metadata is stored in the memory. +You can adjust `-Xmx4096m` basd on the FE memory size. Recommend to set the memory size to 16G or above to avoid GC. All StarRocks metadata is stored in the memory. Step 2: Create a metadata directory. @@ -112,8 +112,7 @@ Step 4: Look up the log file (`log/fe.log`) to confirm that the FE has been star ``` * If the FE fails to start, check if the port number is occupied. If so, modify the port number (`http_port`) in the configuration file. -* You can also use the jps command to view the java process and see if DorisDbFe exists. -* When you use a browser to access port 8030 and open DorisDB's WebUI, you should see the username is root and password is blank. +* You can also use the jps command to view the java process and see if StarRocks FE exists. ### Use MySQL Client to Access FE @@ -140,7 +139,7 @@ Name: 172.16.139.24_9010_1594200991015 IP: 172.16.139.24 -HostName: doris-sandbox01 +HostName: starrocks-sandbox01 EditLogPort: 9010 @@ -203,7 +202,7 @@ mysql> ALTER SYSTEM ADD OBSERVER "host:port"; The host is the IP of the machine. If the machine has multiple IPs, select the IP in priority_networks. For example, `priority_networks=192.168.1.0/24` can be set to use the subnet `192.168.1.x` for communication. The port is `edit_log_port`, default to `9010`. -> Note: Due to security considerations, DorisDB's FE and BE can only listen to one IP for communication. If a machine has multiple network cards, DorisDB may not be able to automatically find the correct IP. For example, run the `ifconfig` command to get that `eth0 IP` is `192.168.1.1`, `docker0 : 172.17.0.1`. We can set the word network `192.168.1.0/24` to designate eth0 as the communication IP. Here we use [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation to specify the subnet range where the IP is located, so that it can be used on all BE and FE. `priority_networks` is written in both `fe.conf` and `be.conf`. This attribute indicates which IP to use when the FE or BE is started. The example is as follows: `priority_networks=10.1.3.0/24`. +> Note: Due to security considerations, StarRocks' FE and BE can only listen to one IP for communication. If a machine has multiple network cards, StarRocks may not be able to automatically find the correct IP. For example, run the `ifconfig` command to get that `eth0 IP` is `192.168.1.1`, `docker0 : 172.17.0.1`. We can set the word network `192.168.1.0/24` to designate eth0 as the communication IP. Here we use [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation to specify the subnet range where the IP is located, so that it can be used on all BE and FE. `priority_networks` is written in both `fe.conf` and `be.conf`. This attribute indicates which IP to use when the FE or BE is started. The example is as follows: `priority_networks=10.1.3.0/24`. If an error occurs, delete the FE by using the following command: @@ -237,7 +236,7 @@ Name: 172.26.108.172_9010_1584965098874 IP: 172.26.108.172 -HostName: doris-sandbox01 +HostName: starrocks-sandbox01 ...... @@ -257,7 +256,7 @@ Name: 172.26.108.174_9010_1584965098874 IP: 172.26.108.174 -HostName: doris-sandbox02 +HostName: starrocks-sandbox02 ...... @@ -277,7 +276,7 @@ Name: 172.26.108.175_9010_1584965098874 IP: 172.26.108.175 -HostName: doris-sandbox03 +HostName: starrocks-sandbox03 ...... @@ -300,14 +299,14 @@ Alive is true, indicating the node is successfully added. In the above example, ### Basic Configuration for BE -The BE configuration file is `DorisDB-XX-1.0.0/be/conf/be.conf`. The default configuration is sufficient to start the cluster. +The BE configuration file is `StarRocks-XX-1.0.0/be/conf/be.conf`. The default configuration is sufficient to start the cluster. ### BE Instance Deployment -Users can use the following steps to add BE to the DorisDB cluster. In most cases, at least three BE instances are deployed. The steps for adding each instance are the same. +Users can use the following steps to add BE to the StarRocks cluster. In most cases, at least three BE instances are deployed. The steps for adding each instance are the same. ```shell -cd DorisDB-XX-1.0.0/be +cd StarRocks-XX-1.0.0/be ``` Step 1: Create a data storage directory. @@ -348,7 +347,7 @@ Cluster: default\_cluster IP: 172.16.139.24 -HostName: doris-sandbox01 +HostName: starrocks-sandbox01 HeartbeatPort: 9050 @@ -462,17 +461,17 @@ cumulative_compaction_check_interval_seconds = 2 * **Parallelism** -You can modify the parallelism of DorisDB (similar to clickhouse set max_threads= 8) when executing commands via the client. The parallelism can be set to half the number of the current machine's CPU cores. +You can modify the parallelism of StarRocks (similar to clickhouse set max_threads= 8) when executing commands via the client. The parallelism can be set to half the number of the current machine's CPU cores. ```sql set global parallel_fragment_exec_instance_num = 8; ``` -## Use MySQL Client to Access DorisDB +## Use MySQL Client to Access StarRocks ### Root User Login -Use the MySQL client to connect to `query_port (9030)` of a certain FE instance. DorisDB has a built-in root user, its password is empty by default. +Use the MySQL client to connect to `query_port (9030)` of a certain FE instance. StarRocks has a built-in root user, its password is empty by default. ```shell mysql -h fe_host -P9030 -u root @@ -536,7 +535,7 @@ mysql -h 127.0.0.1 -P9030 -utest -p123456 ### Create Tables -DorisDB supports two ways of creating tables -- bucketing and composite partition. +StarRocks supports two ways of creating tables -- bucketing and composite partition. In a composite partition: @@ -559,7 +558,7 @@ Next, let’s see how to create a table with buckets. * siteid: The type is INT (4 bytes), the default value is 10 * cidy_code: The type is SMALLINT (2 bytes) * username: The type is VARCHAR, the maximum length is 32, and the default value is an empty string -* pv: The type is BIGINT (8 bytes), and the default value is 0. This is an indicator column. DorisDB internally aggregates indicator columns. The aggregation method is sum (SUM). +* pv: The type is BIGINT (8 bytes), and the default value is 0. This is an indicator column. StarRocks internally aggregates indicator columns. The aggregation method is sum (SUM). ```sql mysql > @@ -581,7 +580,7 @@ Then, let’s see how to create a composite partition table. The schema of the t * siteid: The type is INT (4 bytes), the default value is 10 * cidy_code: The type is SMALLINT (2 bytes) * username: The type is VARCHAR, the maximum length is 32, and the default value is an empty string -* pv: The type is BIGINT (8 bytes), the default value is 0. This is an indicator column. DorisDB internally aggregates indicator columns. The aggregation method of this column is sum (SUM). +* pv: The type is BIGINT (8 bytes), the default value is 0. This is an indicator column. StarRocks internally aggregates indicator columns. The aggregation method of this column is sum (SUM). We use the `event_day` as the partition key to create three partitions (p1, p2, p3). diff --git a/quick_start/import_and_query.md b/quick_start/Import_and_query.md similarity index 86% rename from quick_start/import_and_query.md rename to quick_start/Import_and_query.md index 5c89ec0192107..34a84eb782270 100644 --- a/quick_start/import_and_query.md +++ b/quick_start/Import_and_query.md @@ -2,7 +2,7 @@ ## Local File Import -DorisDB provides five ways to import data sources (e.g. HDFS, Kafka, local files, etc.), either asynchronously or synchronously. +StarRocks provides five ways to import data sources (e.g. HDFS, Kafka, local files, etc.), either asynchronously or synchronously. ### Broker Load @@ -12,27 +12,27 @@ Broker Load is used when the source data is in a broker-accessible storage syste ### Spark Load -Spark Load leverages the external Spark resources to pre-process imported data, which improves DorisDB’s performance of importing large data volumes and saves computing resources. +Spark Load leverages the external Spark resources to pre-process imported data, which improves StarRocks’ performance of importing large data volumes and saves computing resources. -Spark Load is suitable for initial migration of large data volumes (up to TB level) to DorisDB, and the source data is in a Spark-accessible storage system (e.g. HDFS). +Spark Load is suitable for initial migration of large data volumes (up to TB level) to StarRocks, and the source data is in a Spark-accessible storage system (e.g. HDFS). ### Stream Load -Stream Load is a synchronous import method. The user sends a request via the HTTP protocol to import a local file or data stream into DorisDB, and waits for the system to return a status indicating the import result. +Stream Load is a synchronous import method. The user sends a request via the HTTP protocol to import a local file or data stream into StarRocks, and waits for the system to return a status indicating the import result. Stream Load is suitable for importing local files, or importing data from a data stream through a program. Data sources include Flink, CSV, etc. ### Routine Load -Routine Load allows to automatically import data from a specified data source. The user submits a routine import job via the MySQL protocol, generating a runloop that reads data from a data source (such as Kafka) and imports it into DorisDB without interruption. +Routine Load allows to automatically import data from a specified data source. The user submits a routine import job via the MySQL protocol, generating a runloop that reads data from a data source (such as Kafka) and imports it into StarRocks without interruption. ### Insert Into -Similar to the `Insert` statement of MySQL, DorisDB supports `INSERT INTO tbl SELECT ... ;` to read data and import it to a table and `INSERT INTO tbl VALUES(...) ;` to insert a single row of data. Data sources includes DataX/DTS, Kettle/Informatic, and DorisDB itself. +Similar to the `Insert` statement of MySQL, StarRocks supports `INSERT INTO tbl SELECT ... ;` to read data and import it to a table and `INSERT INTO tbl VALUES(...) ;` to insert a single row of data. Data sources includes DataX/DTS, Kettle/Informatic, and StarRocks itself. -The overall ecological diagram of DorisDB data import is as follows. +The overall ecological diagram of StarRocks data import is as follows. -![dorisdb_ecology](../assets/2.5-1.png) +![starrocks_ecology](../assets/2.5-1.png) Here is an example of stream load using the HTTP protocol. @@ -206,7 +206,7 @@ CANCEL ALTER TABLE COLUMN FROM table1\G ### Create Roll up -Rollup is a new pre-aggregate acceleration technique used by DorisDB, which can be regarded as a materialized indexing structure built on the base table. By materialized, it means data is stored independently. By indexting, it means rollup can adjust the column order to increase the hit rate of prefix indexes, and also reduce key columns to make data aggregation efficient. +Rollup is a new pre-aggregate acceleration technique used by StarRocks, which can be regarded as a materialized indexing structure built on the base table. By materialized, it means data is stored independently. By indexting, it means rollup can adjust the column order to increase the hit rate of prefix indexes, and also reduce key columns to make data aggregation efficient. The schema of the original table1 is as follows: diff --git a/quick_start/test_faq.md b/quick_start/Test_faq.md similarity index 97% rename from quick_start/test_faq.md rename to quick_start/Test_faq.md index 558ff74f2e463..ef57a42536438 100644 --- a/quick_start/test_faq.md +++ b/quick_start/Test_faq.md @@ -8,7 +8,7 @@ * For BE, we recommend 16 cores with 64GB or more. For FE, we recommend 8 cores with 16GB or more. * HDDs or SSDs can be used. -* CPU must support AVX2 instruction sets, use `cat /proc/cpuinfo |grep avx2` to confirm there is output. If not, we recommend replacing the machine. DorisDB's vectorization engine needs CPU instruction sets to perform a better effect. +* CPU must support AVX2 instruction sets, use `cat /proc/cpuinfo |grep avx2` to confirm there is output. If not, we recommend replacing the machine. StarRocks' vectorization engine needs CPU instruction sets to perform a better effect. * The network needs 10 GB NIC and 10 GB switch. ## Modeling diff --git a/quick_start/concepts.md b/quick_start/concepts.md deleted file mode 100644 index 3704b64f73c9d..0000000000000 --- a/quick_start/concepts.md +++ /dev/null @@ -1,7 +0,0 @@ -# Basic Concepts of DorisDB - -* FE: The DorisDB frontend node is responsible for metadata management, management of client connectors, query planning, query scheduling, and so on. -* BE: The DorisDB backend node is responsible for data storage, calculation execution, compaction, replication management, and so on. -* Broker: A transit service that connects external data such as HDFS and object storage, assisting import and export functions. -* DorisManager: A management tool that helps visualize DorisDB cluster management, online query, fault query, and monitoring alerts. -* Tablet: The logical sharding of a DorisDB table, as well as the basic unit of copy management. Each table is divided into multiple tablets and stored on different BE nodes according to the partitioning and bucketing mechanisms.