Closed gauthamchandra closed 1 year ago
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: gauthamchandra
To complete the pull request process, please assign cxie after the PR has been reviewed.
You can assign the PR to them by writing /assign @cxie
in a comment when ready.
The full list of commands accepted by this bot can be found here.
Welcome @gauthamchandra! It looks like this is your first PR to zilliztech/GPTCache 🎉
Sorry for the failing tests. Turns out that specifying the region_name
for AWS overrides the endpoint_url
field so it ended up trying to connect directly to us-east-2
as part of the tests instead of the local DynamoDB container.
My latest changes should hopefully fix the issue. 🙏🏼
It seems a totally unrelated test is failing. Might be finicky 🤔
@gauthamchandra thanks your patience, and i will fix it in the next pr
Has this been released? can we use dynamodb now as a storage for caching? I can't see in the documentation anywhere?
yes, you can. the usage is like other cache storage, and its params include:
elif name == "dynamo":
from gptcache.manager.scalar_data.dynamo_storage import DynamoStorage
return DynamoStorage(
aws_access_key_id=kwargs.get("aws_access_key_id"),
aws_secret_access_key=kwargs.get("aws_secret_access_key"),
aws_region_name=kwargs.get("region_name"),
aws_profile_name=kwargs.get("aws_profile_name"),
aws_endpoint_url=kwargs.get("endpoint_url"),
@mikeblackk, just want to clarify that it uses boto3
under the hood so not all params (like aws_endpoint_url
, etc.) are required.
As a result, it relies on the standard AWS resolution logic (so if you have ENV vars like AWS_ACCESS_KEY_ID
, then it will be automatically picked up without explicitly specifying). The parameters like aws_endpoint_url
act as overrides so that you have an easier time developing on your local machine where you might be using LocalStack or have multiple AWS profiles.
Let me know if you run into any issues. I am not an expert on Dynamo by any means so there might be issues which need to be fixed 😄
This change allows GPTCache to use DynamoDB as the underlying scalar storage for the cache. Addresses #200
The underlying implementation uses 2 tables:
gptcache_questions
- which holds all questions and session information.gptcache_reports
- which holds the reporting information.Normally, we would do a single table design and rollup
gptcache_reports
into the same table asgptcache_questions
. However, this was not done for one key reason: billing.In the event a lot of analytics data is being created, then table scans for operations like
count()
andget_ids()
would also involve reading these reporting rows before filtering them out, resulting in higher read costs for end users of GPTCache.Preview of what the tables look like:
gpt_cache
tableSecondary Indexes:
gsi_items_by_type:
gsi_questions_by_deletion_status: