What database implementation would better fit this scen…

You need a persistent and durable storage to trace call activity of an IVR (Interactive Voice
Response) system. Call duration is mostly in the 2-3 minutes timeframe. Each traced call can be
either active or terminated. An external application needs to know each minute the list of currently
active calls. Usually there are a few calls/second, but once per month there is a periodic peak up
to 1000 calls/second for a few hours. The system is open 24/7 and any downtime should be

avoided. Historical data is periodically archived to files. Cost saving is a priority for this project.
What database implementation would better fit this scenario, keeping costs as low as possible?

You need a persistent and durable storage to trace call activity of an IVR (Interactive Voice
Response) system. Call duration is mostly in the 2-3 minutes timeframe. Each traced call can be
either active or terminated. An external application needs to know each minute the list of currently
active calls. Usually there are a few calls/second, but once per month there is a periodic peak up
to 1000 calls/second for a few hours. The system is open 24/7 and any downtime should be

avoided. Historical data is periodically archived to files. Cost saving is a priority for this project.
What database implementation would better fit this scenario, keeping costs as low as possible?

A.
Use DynamoDB with a “Calls” table and a Global Secondary Index on a “State” attribute that can
equal to “active” or “terminated”.
In this way the Global Secondary Index can be used for all items in the table.

B.
Use RDS Multi-AZ with a “CALLS” table and an indexed “STATE” field that can be equal to
“ACTIVE” or ‘TERMINATED”.
In this way the SQL query is optimized by the use of the Index.

C.
Use RDS Multi-AZ with two tables, one for “ACTIVE_CALLS” and one for
“TERMINATED_CALLS”.
In this way the “ACTIVE_CALLS” table is always small and effective to access.

D.
Use DynamoDB with a “Calls” table and a Global Secondary Index on a “IsActive” attribute that is
present for active calls only.
In this way the Global Secondary Index is sparse and more effective.

Explanation:
https://aws.amazon.com/dynamodb/faqs/
Q: Can a global secondary index key be defined on non-unique attributes?
Yes. Unlike the primary key on a table, a GSI index does not require the indexed attributes to be
unique.
Q: Are GSI key attributes required in all items of a DynamoDB table?
No. GSIs are sparse indexes. Unlike the requirement of having a primary key, an item in a
DynamoDB table does not have to contain any of the GSI keys. If a GSI key has both hash and
range elements, and a table item omits either of them, then that item will not be indexed by the
corresponding GSI. In such cases, a GSI can be very useful in efficiently locating items that have
an uncommon attribute.



Leave a Reply 0

Your email address will not be published. Required fields are marked *