Hacker News new | past | comments | ask | show | jobs | submit login

Sounds HFT to me. Plus functional programming. KDB like?

Quit teasing Out with it. Sounds like fun with lots of real hackability and responsibility built in. Would love to hear more of what you can share.

You mention a SQL db - have you guys put something together of your own or are you using a pre-rolled db?




We tried FP but it didn't take with the more average dev in our number.

It is fun, can be a lot of pressure, and the sheer quantity of issues and the speed with which they must be dispatched means I always have to learn and I often screw up analysis. Humility and the ability to prod people who know stuff and grok what they say quickly is essential.

We use a major DB (not Oracle). Again, think unfashionable, think speedy.

Sorry, don't mean to tease - I just don't want people to be able to track me down.


Well, I can't imagine SQL Server handling your requirements, and I find it unlikely a mission critical system like this will use MySQL or Postgres (primarily because Enterprises like to pay a lot for that 'security' of support), so I'd shoot for Sybase if its not Oracle?

The reason I ask is because I am a pretty highly skilled Oracle guy, and some of the numbers I have seen around financial systems just seem so fast and big volume transactions per second. Maybe I could get Oracle to do them, but then the zero downtime scares me somewhat as until very recently, keeping Oracle up all the time, even through application upgrades is fairly tricky!


Actually, the db we use had similar problems. Schema changes require at least _some_ downtime, if only to lock the tables. The trouble is less the number of transactions than the linkage between each transaction and other transactions' liabilities in the system. In effect, serious DB's are in effect in-memory updates (some of our bigger customers run with no logical log write to disk on commit (really!)) running on 128-core Sun boxes (principal and failover). You can get through a lot of tps and the saving on dev cost and maintenance through this monolithic simplicity is great.


If it's financial sector (and it likely is), IBM's DB2 has a large userbase.


Not fast enough (I hear).


Makes sense. Thinking about it, most of the DB2 usage I've heard of is behind ATM and core accounting systems in retail banking rather than trading applications/low-latency...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: