4 ms·

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 wit

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.

fendale 16y ago
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!
- zwischenzug 16y ago
  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.
- adw 16y ago
  If it's financial sector (and it likely is), IBM's DB2 has a large userbase.
  - zwischenzug 16y ago
    Not fast enough (I hear).
    - adw 16y ago
      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...

fendale 16y ago

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!

zwischenzug 16y ago
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.
adw 16y ago
If it's financial sector (and it likely is), IBM's DB2 has a large userbase.
- zwischenzug 16y ago
  Not fast enough (I hear).
  - adw 16y ago
    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...