[GitHub] [incubator-doris] yangzhg commented on a change in pull request #4479: [Apache][Doris]add query cache docs

[GitBox <gi...@apache.org>]

yangzhg commented on a change in pull request #4479:
URL: https://github.com/apache/incubator-doris/pull/4479#discussion_r504350597



##########
File path: docs/en/administrator-guide/query_cache.md
##########
@@ -0,0 +1,190 @@
+---
+{
+    "title": "QUERY CACHE",
+    "language": "en"
+}
+---
+
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# QUERY CACHE
+
+
+## 一 Demond
+
+Usually, we have cache in the corresponding database layer which is focus on the query content.However the data granularity in the cache is too slow and it would have effect only when  data in the table didn't change.Obviously, it could not reduce the heavy IO load from the CRUD of the business system. So it comes the database caching technology, which could highspeed caching the hot data, improve the response speed of the application and greatly relieve the load of the backend database.
+
+- High concurrency scenarios
+  Doris have a well support for high concurrency while single sever is unable to load too high QPS.
+
+
+
+- Complex Graph Dashboard
+  It is not uncommon to see that,  data of the complex Dashboard and the lage screen applications come from many table together which have tens of queries in a single page.Even though every single query cost only few milliseconds, the total queries would cost seconds.
+  
+
+- Trend Analysis
+  In some scenarios, the queries are in a given date range , the index is shown by date.For example, we want to query the treend of the number of user in the last 7 days.This type of queries has a large amount of data and a wide range of fields, and the queries often takes tens of seconds.
+
+
+- User repeated query
+  If the product does not have an anti-re-flash mechanism, the user accidentally  refreshes the page repeatedly due many reasons, which resulting in submitting a large number of repeated SQL
+
+
+
+In the above four scenarios, we have solutions at the application layer. We put the result of queries in the Redis and  update the cache periodically or the user update the cache manually.However, this solution has the following problems:
+
+
+
+- Inconsistence of data , we are unable to sense the update of data, causing users to often see old data
+
+- Low hit rate, we usually cache the whole result of query.If the data is writed real-time, we would often failed in cache, resulting in low hit rate and overload for the system.
+
+- Extra Cost we introduce external cache components, which will bring system complexity and increase additional costs.
+
+
+
+## 二 Solutions

Review comment:
       don`t mix use 一二三四 in en doc




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@doris.apache.org
For additional commands, e-mail: commits-help@doris.apache.org