Jamie Grant
[custom_headline type=”left” level=”h2″ looks_like=”h3″]Introduction[/custom_headline]
As the adoption of kdb+ has expanded both within and outside of its traditional domain in finance, the options for interfacing kdb+ with other technologies have also grown. kdb+ has always had an excellent set of external interfaces out of the box – with a native C/C++ interface capable of creating and accessing low level data structures and extending the language itself, to the java and C# interfaces which support the kdb+ IPC wire protocol. code.kx.com now contains many interfaces to other languages contributed by other members of the community, including alternative java and C# interfaces.
Kx recently released an updated version of its windows ODBC driver, implementing ODBC version 3 in order to support the latest visualisation tools such as Tableau.
We decided to investigate one of the commercial ODBC SDKs available, both as a technical exercise and to see if it might fill a niche not covered by the free driver from Kx. The most obvious potential advantage would be support for non windows clients – MacOS desktop usage is on the rise, certainly among developers and data scientists if not large institutions, and unixODBC is commonly used in server side applications where different database technologies need to communicate within an application.
[custom_headline type=”left” level=”h2″ looks_like=”h3″]Features[/custom_headline]
Using an SDK means we don’t have to worry about the details of the ODBC standard, nor do we have to write our own SQL library for kdb+. The headline features we get with the SDK are:
- cross platform support for ODBC client (macOS, linux, windows 32/64)
- SQL parsing engine built in
- ODBC 3.8 support
The SQL parsing engine built in to the SDK allows us to identify aggregations and filters in the SQL query, and pass those down to q as a functional query. Hence no libraries are required on the kdb+ server side – the incoming request is valid q. This may be an advantage to kdb+ applications which include a permissions layer examining requests to check user entitlements.
[custom_headline type=”left” level=”h2″ looks_like=”h3″]Conclusions[/custom_headline]
So why might a kdb+ user look beyond the excellent (and free!) odbc3 driver from Kx?
- a requirement for multi platform client support – Linux, MacOS, 32bit windows
- a userbase more comfortable working in SQL rather than learning q
- an existing kdb+ application which relies on external requests in q , e.g. permissions layer or a transparent gateway
- ongoing support contract covering implementation assistance, bug fixes and feature requests
If any any of the above intrigues you and you’d like to get in touch to discuss licensing, please drop us a note at info@aquaq.co.uk
Share this:
