Case Study: Realtime Trader Seeks 64-Bit Realtime Database
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
"We need to move phenomenal amounts of data very, very fast," maintains Rebecca Lewis, director of systems at Townsend Analytics, a major online trading operation. Wanting to give Townsend a database to match, Townsend has been beta testing SQL Server 2005, formerly codenamed Yukon, ever since last August. The systems director has noticed big gains across areas ranging from performance to WMI integration, security, and VLDB partioning. Yet Lewis still hasn't seen the 64-bit processing that Microsoft promises to include by the time of RTM early next year.
Townsend uses SQL Server to run RealTick, an Internet-based service for online traders, brokerages, and other financial institutions. Realtick is geared to streaming realtime data about stocks, futures and currencies from exchanges around the world. The Web site also gives subscribers Townsend-calculated statistics about weekly volume, gainers, losers, and 52-week highs and lows, for instance.
"SQL Server is RealTick's only RDBMS. It supports RealTick trading; server application configurations; Web services; customers' access to their trading histories; administration of customers' trading accounts; back office functionality; and our authentication and entitlements infrastructure," according to Lewis.
Latency Is Tough To Take
"Financial markets change so quickly that any latency is difficult to accept," Lewis says. After years of using SQL Server, however, the Chicago-based online trading specialist is still putting up with some data processing delays. "We've noticed some latency with SQL Server 2000 that we're hoping to overcome with SQL Server 2005," she adds.
Lewis credits SQL Server 2005 with some considerable performance gains already. Yet for additional improvement, she's looking to 64-bit processing, along with multithreading capabilities for certain tasks.
"Another large challenge we've faced is incompatibility between Dev Studio and SQL Server 2005," she acknowledges. "Largely, though, our efforts (with SQL 2005) have been more positive than negative so far."
More Pluses Than Minuses
Lewis contends that, in the course of beta testing, Microsoft's already come through with one big item on her wish list: WMI integration.
For instance, DTS now includes a WMI task. "This greatly reduces my need to 'file watch.' Previously, I had to remove applications' monitor directories for necessary files, and then move them to SQL Server. Now, I can use WMI file watching from a DTS package, so all this work gets done from SQL."
Lewis also cites DTS's file system, FTP and message queuing tasks as useful. "Before these were added, we had to code in and around using other applications. It's awesome to have the SQL data co-mingled with non-specific data such as FTP."
Microsoft scores some more points with Lewis for adding other functionality to WMI that might have been considered 'missing' before this release. "The ability to extract data from Web services (simplifies) many types of integration that were formerly complex to configure. Logging and error handling are hugely improved, and are now done dynamically," she illustrates.
Lewis also sees some advantages to Dev Studio, despite the compatibility issues. "We're pleased that we're able to develop DTS packages using .Net," she notes.
Lewis admits, though, that DTS poses a stiff learning curve. "Some of the biggest challenges we've faced have been familiarity-based. DTS, for example, has changed so significantly that you must first take time to learn the new application components," before any possible benefits can be realized.