Jamesbeyond

To list the key functionalities of this new database, I think they represent many trends in the current data world:

Native support for semi-structured data. Elastic scaling of computation resources. Auto synchronization of data from MySQL and Oracle. Tiered storage of hot and cold data. Storage-compute separation. Kubernetes deployment. CCR. High concurrency. Inverted index. Auto fine-tuning. Data lakehousing capabilities. Parallel execution. Efficient data updates. Resource isolation for multi-tenancy.

Yep, Chinese characters are terrifyingly complicated, but the Chinese language is more compact sentence-wise and text-wise. Actually, the Chinese were acutely aware of how inconvenient the heavily-stroked characters are. That's why they invented simplified Chinese.

Quick computation, no duplication, and no data loss, realized by the idempotent writing of Apache Doris and the two-stage commit mechanism of Apache Flink.

It takes quite some fine-tuning to generate a photo that is not creepy (this is so important...) and worth buying.

There are two common log analytic solutions within the industry: inverted index (Elasticsearch) and lightweight index / no index (Grafana Loki). We opt for the first one since the other one is just trading query speed for high throughput and low storage costs, while query speed is the biggest concern for people. Now there is a way to improve on the first option, and achieve two times faster query speed with only one fifth of the storage space.

TLDR: The transition was mainly for partial update of columns, lower storage costs, and lower maintenance costs.

Hi, engineers. PMC (project management committee) member of Apache Doris here. (If you have never heard of Apache Doris, it is an analytic database.) We recently summarize our efforts in improving query concurrency in this writeup: https://dev.to/apachedoris/30000-qps-per-node-how-we-increas... We've been trying to handle both high-throughput and high-concurrency queries on one single platform, and we are kinda proud of what we have achieved, but we also want some input from HN, like do you think 30,000 per node is competitive enough, and most importantly, do you see any room for improvement in these 9 methods?

Row storage, short-circuit, prepared statement, and row cache.