I appreciate your work and I have a few questions and one suggestion at this point
How frequent trading per instrument per day do you want your backtesting system to simulate ?
I know you only said down to one minute but how fine time stamps have you implemented ?
Have you put in fields for the high and low bid and ask in the one minute period ?
Have you thought about complex event processing in relation to your language? Here is an example http://esper.codehaus.org/
May I suggest that for the source data rather than just main memory you make it (sequential) streaming main memory from disk or memory mapping. Most useful analysis will pull data slower than the sequential speed of modern spinning disks not to mention SSDs and there is not a need to randomly access quote data. Thinking abbiout the design to allow for this will allow your tool to be more general.
One of the initial goals of the aq tool-set is to do back-testing based on eod and 1-min data using aqlang programs that could be very simple or very sophisticated. It is surely not designed to deal with everything. processing tick-data is not in the design so far. Theoretically, aqdb should be able to store huge tick data per symbol.
The format of 1 minutes data is up to the person who uses aqdb. You can define 1 minutes data similar to eod data with time/open/high/low/close/vol or simply as time/price (here you need to normalize/prepare the intraday prices moving to best suite the real price movement of the day).
The tool is targeted to run on a decent PC with minimal 4 GB memory. The requirement for the disk storage depends on how many symbols in the watch list. My experiment so far consumes about 36 GB. The hot active data is in binary format and consumes less than 700MB of EOD data for 8000 symbols up-to dozens of years, and 1GB of 1 minute data for 8000 symbols per month. So, a machine with huge bigger main memory and a good file buffer mechanism (like in Linux) will definitely help a lot to improve the performance.
One of the major design considerations is the speed performance. The core part of the aq tool-set (aqdb and aq program virtual machine) is write in C/C++ and optimized for vector. processing.
Well, I would answer your question in a more generic form: what is the advantage of this yet-another TA project when there are already a lot of TA software and tools available. There are trade-ideas.com (sorry, I really do not know about it), R language for financial, R/xts, q/kdb+, etc. The only reason at the beginning was that I cannot find any software that is flexible, free, fast, easy and command-line based for my need a few years back when I started my experiment. Even now after I reviewed more available tools, I still think my tool can do something specific or doing something in a specific interesting approach.