Analytics tightly integrated with the database
In SAMOA, the analytics are tightly integrated with the database. For instance,
select dbo.ssTsyPriceToYield( 'T 4.5 05/15/2017', '2007-05-15', 99.110793, 1, 0)*100.0 as Yield
Here, the function ssTsyPriceToYield(..) calculates the yield for the bond T 4.5 05/15/2017, using the price 99.110793 that settles on 2007-05-05. In order to make this calculation, the system needs to query several internal tables in the database. For instance, it extracts the maturity, first coupon date, dated date and coupon for the given bond in order to reconstruct the cash flow, and thus being able to calculate the yield (4.612). All this data access happens transparently behind the scenes.
Let’s look at one more example:
select dbo.ssAddTimeSpan('1980-01-01', '-1b (US|WEEKENDS)') AS 'ssAddTimeSpan'
Here, we use the function ssAddTimeSpan(..) to calculate the previous business day (“-1b”) from 1980-01-01, using the calendar for US bonds and the weekends as holidays (“US|WEEKENDS”). Here SAMOA needs to query from the database the list of holidays for the calendar “US”. Again, this data access happens behind the scenes.
These two examples illustrate what I meant by “analytics tightly integrated with the database”. That is, SAMOA queries from the database whatever information is necessary to perform it’s calculations.
SAMOA’s cache
Having analytics that are tightly integrated with the database is very useful because it simplifies the number of parameters of the functions. However, it imposes the need to cache the data in order to avoid repeated (and slow) queries to the database.
SAMOA has an efficient in-memory cache. This means that the first time you call a function like ssTsyPriceToYield(…), the calculation time might be slightly longer as SAMOA loads from the database all the static information for bonds and stores it into the in-memory cache. However, subsequent calls to ssTsyPriceToYield will be very fast as they’ll be using the cache.
Flushing the cache
As you can see, the cache is a crucial factor of SAMOA’s good performance, and it simplifies the number of parameters needed in function calls.
When the cached data actually changes in the database, SAMOA automatically flushes the cache. It is possible to force a flush by using the following function:
EXEC dbo.ssFlushAllCaches
This function is available in all the API’s (Excel, Mathematica, c#, etc).
Distributed cache
SAMOA analytics can be called from a number of clients, including Excel, SeriesQueryBuilder, Mathematica, Powershell, R, etc. Each copy of the library will have its own cache. Furthermore, since SAMOA is a client-server software, there might be more than one machine connected to a given server, each in turn with their own cache. In practical term this is a distributed cache and SAMOA treats it like such.
When the cache needs to be flushed (for instance when the user calls the previously described function ssFlushAllCaches) SAMOA broadcasts a messages to all the components with local cache to make sure all of them clear up.
Some other functions for cache handling
- To see the local cache in the SAMOA Server
select * from dbo.ssListCacheInsideSQL()
- To flush only the cache inside SAMOA Server (without propagating a flush to all the other Local Cache’s)
EXEC dbo.ssFlushCacheInsideSQL
- See the local cache of the SeriesQueryBuilder:
