[This message was posted by Andy Faibishenko of Lasalle Technology <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/fb2df6e0 - PLEASE DO NOT REPLY BY MAIL.]
Thanks Paul, I posted the same question in the LinkedIn group and got a good number of responses, though it seems like most people wanted to argue whether it was a good design choice or not, whereas I just wanted a survey of how many folks out there actually did logging to a DB. One thing that is not clear to me is why you could not use a shared filesystem/SAN type of design to be able to have the best of both worlds. A flatfile logging mechanism, yet the ability to failover should one of the boxes connected to the filesystem goes down. > > Relational database logging does offer a lot in terms of availability, > failover/redundancy and reporting, but I wouldn't use it as a primary > message store for the reason you mentioned, the performance hit. This > does mean that you have to work out another scheme for persisting > messages in such a way as to provide seamless failover, but this can be > done in many ways that I would expect to be more efficient than using a > relational database. Also, if you're logging to a database and it > becomes inaccessible for some reason, you have no logging. One solution > would be to do a hybrid implementation. For example, you could write > messages immediately to a file or some in-memory cache, then lazily > write them to a database. [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
