How to move an observability platform onto domestic databases. Field notes on OceanBase (MySQL mode) and Dameng: connection parameters, dialect differences and load-test results.
When government and enterprise organizations migrate to domestic computing, applications and middleware usually change first and the database last — it holds the data, so it carries the highest risk. But the observability platform itself has to move too, and it is an unforgiving workload: it writes enormous volumes of logs and span metadata every day, so write throughput, bulk insert and indexing are all tested hard. Pick the wrong database configuration and the platform itself becomes a bottleneck — which is exactly the thing you bought it to investigate.
The choice of storage protocol makes a huge difference here. Observe's storage layer speaks the MySQL protocol by default, which sharply reduces the cost of adapting it to domestic databases. Below are our field notes on two of them: OceanBase and Dameng. Both were tested on Kunpeng 920 hardware running Kylin V10.
OceanBase's MySQL mode is highly protocol-compatible. After swapping the connection string from MySQL to OceanBase, the platform ran with zero code changes. The only thing to watch is the connection parameters:
db:
host: ob-proxy.example.com
port: 2883 # OceanBase MySQL-protocol port
user: observe
database: observe_meta
params: "useServerPrepStmts=false"The key is useServerPrepStmts=false: earlier OceanBase versions handle server-side prepared statements differently from MySQL, and forcing the text protocol actually gave us more stable bulk-write throughput. On the write side, put logs and spans in separate tablespaces so the two heaviest tables don't contend with each other. If you're on a shared OceanBase cluster, also request a dedicated resource unit for the observability tenant — a heavy observability write pattern can otherwise starve neighboring tenants.
Dameng follows an Oracle style, so you switch the storage layer's SQL dialect to DM mode. Two things need changing in practice. First, pagination: the LIMIT compatibility layer works, but at large data volumes you're better off with the ROWNUM window form — we saw noticeably better execution plans on big tables. Second, auto-increment primary keys use Dameng's IDENTITY column, not MySQL's AUTO_INCREMENT.
CREATE TABLE spans (
id BIGINT IDENTITY(1,1),
trace_id VARCHAR(64) NOT NULL
);For migration we used Dameng's own DTS tool to batch-convert the MySQL DDL, then manually re-checked indexes and default values. Silently dropped defaults are a classic post-migration write-failure cause, and they don't surface until a row actually tries to insert. One more gotcha: Dameng's default character-set handling differs from MySQL on a few edge cases around emoji and rare characters in log messages, so set the charset to UTF-8 explicitly on every column.
On a Kunpeng 920 server, OceanBase (3 replicas) sustained about 60,000 rows/sec on a single table and Dameng about 30,000 rows/sec — both comfortably handle a mid-size observability workload. Three recommendations: write through the bulk interface rather than row-by-row; index the columns you actually query; and partition large tables by month so old partitions can be archived.
One honest observation from the field: in domestic-computing environments the database is rarely the real bottleneck. Disk IO and network are. Spend your budget on SSDs and 10GbE NICs before you chase exotic database tuning — that's where the wins actually are. As a final acceptance step, run the platform's own self-check across log search, tracing and alert rules after the migration, and watch write latency for a full business day before declaring it done.
Three things bit us more than once. First, connection pools tuned for MySQL's defaults can over-commit against OceanBase's proxy layer, so lower maxConnections and raise the per-connection batch size instead. Second, Dameng's planner needs ANALYZE run on the big tables after bulk import, or the first queries against a migrated table will pick terrible execution plans. Third, both databases want the observability data on fast local disks rather than a shared SAN — log writes are bursty and latency-sensitive, and a shared array smooths away the very signal you're trying to capture. None of these are exotic; they're just the usual observability-workload tuning, applied to a domestic database.