Forum OpenACS Q&A: Re: Building a marketplace: NYSE, NASDAQ, CBOT

Collapse
Posted by Jerry Asher on
Basically, we started off with such generic application requirements it looked like we needed an RDBMS system.  But as we dug into it, there were only a half dozen or so transactions in our system, and they were relatively simple (think about two to five select statements, two or three types of update/inserts, and no deletes (no real time deletes)) that we went more for an object model and not at RDBM model.  Queries were things like: Find stock named foo.  Find matching buy/sell order.  Inserts were: insert new stock.  Insert new buy/sell order.  Updates were: modify this order (add seller and quantity to list, add buyer and quantity to list, modify total quantity).  With such a few queries, we hardcoded the queries as C, and built the data structures around them.

We designed this with fixed capacities in place (large capacity, but unchanging without restarting the application.)  Like a reservoir, it has a fixed capacity or else it overflows.  It was required to have a huge capacity, but it was fixed, and knowing that number let us determine how large to create and pre-allocate various tables that an RDBMS would not demand you create or pre-allocate.

We had A, C, I in memory and hard-coded in the code, and the D was to bubble up from the rest of the system we would put in place to meet the required system uptime.  I believe this is analogous to how many OODBM systems can work for you.

In a non real-time basis, as system demand permitted, sweeps through our object model were to stream into a traditional database to permit analysis and reporting and things like that and to clean up memory.