Inside the K-DB Experience Day: Performance Showdown with Oracle
The article recounts a hands‑on K‑DB experience event where participants migrated Oracle workloads, benchmarked K‑DB against Oracle using TPMC, explored the K‑RAC cluster feature, and shared detailed observations that highlight K‑DB's compatibility, performance, and stability in a real‑world setting.
On August 30, 2015, Inspur hosted a K‑DB experience day at its Beijing research center, inviting ten community technologists to test the upcoming K‑DB database, which was slated for official release in October.
The event began with an opening speech by Inspur Vice President Hu Leijun, emphasizing the strategic importance of K‑DB for Inspur's K1 servers, especially since Oracle does not support the Unix environment on those machines.
I am K‑DB, a database. I know you are proficient with Oracle. I also know you understand Oracle's internals. But you know little about me. I am 99% compatible with Oracle, and my performance rivals it. Let’s put that to the test.
Participants included experts such as Dr. Zheng Baowei from Enhe and Hong Ye from Harbin Bank, adding credibility to the technical discussions.
The core technical presentation highlighted K‑DB’s K‑RAC feature, a RAC‑like architecture that reportedly supports stable production workloads. A live fault‑injection test demonstrated K‑RAC’s ability to handle node failures and recoveries with minimal TPMC fluctuation.
During the hands‑on session, attendees used the kdMigrator tool to migrate Oracle schemas, data, and stored procedures to K‑DB. Post‑migration, existing front‑end applications ran smoothly, confirming the claimed Oracle compatibility.
The benchmark phase divided participants into two teams (Oracle vs. K‑DB). Using the TPMC benchmark with 100 warehouses and 1,000 concurrent users, the teams tuned their databases and recorded performance metrics.
Initial results showed Oracle at roughly half the performance of K‑DB. After deeper tuning, Oracle’s performance approached that of K‑DB, illustrating that both systems can achieve comparable results when optimally configured.
Observations noted that the K‑DB team employed aggressive tuning—adjusting hidden parameters like _log_simultaneous_copies, huge page settings, and various internal buffers—while the Oracle team used more conventional methods such as adjusting tablespaces and memory parameters.
Overall, the event demonstrated K‑DB’s robust feature set, including parallelism, extensive internal parameters, and stable cluster behavior, positioning it as a viable alternative to Oracle for Inspur’s hardware ecosystem.
Participants concluded that while K‑DB still lags behind Oracle in some advanced features, its core functionality and performance are impressive for a newly released domestic RDBMS, and further openness and tooling would enhance its adoption.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITPUB
Official ITPUB account sharing technical insights, community news, and exciting events.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
