When it came time to choose technologies for the implementation of Tapaas, there was really no decision needed. We knew we had to use KDB+ as the core engine to give us the real-time performance and flexibility that we needed in our product.
Tapaas provides streaming as well as historical analytics so we knew we needed query processing and data storage layers that worked well together in both those use cases. Dave and I had plenty of experience with Kdb+ in our previous lives at big bulge bracket firms on workloads far more demanding than what is envisioned for Tapaas. And we are both big fans of the product.
Ever since I started working with KDB+ more than 10 years ago, I found the power and simplicity of KDB+ compelling for both real-time streaming and historical time series applications. For a start, it has brute data handling speed which is essential for delivering true low latency streaming analytics in environments where data volumes seem to grow daily. But perhaps its greatest asset is its query language Q which is tightly woven into its data architecture. Q is based on a functional programming model, which allows even the most complex logic to be expressed succinctly and efficiently directly in the database. There are no data access layers, no adaptor logic, no unnecessary data translations between database semantics and analytics semantics. The data is just readily amenable to be processed by our logic through a comprehensive set of powerful functions. And given the scale of KDB+ applications we have worked with previously, we have no doubts we have a great growth path as Tapaas clients seek to gain more and more insights into their data.
No comment yet, add your voice below!