René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Removal of storing historical value of feature in serving storage","articleBody":"**Is your feature request related to a problem? Please describe.**\r\nStoring historical value of feature in serving store consume a lot of storage space. It becomes a real problem for limited storage such as Redis.\r\n\r\n**Describe the solution you'd like**\r\nRemove the storing feature as time series data functionality and only store the latest value of feature (which currently we already have)\r\n\r\n**Impact**\r\n1. Ingestion\r\n   Removal of code which writes feature as time series data in Redis and Bigtable.\r\n2. Serving\r\n   Serving currently has 1 API which can request LAST feature or LIST of feature. \r\n   If the time series data is removed then LIST request will always return empty feature.\r\n   Currently, LAST request ignore time range filter, it has to be changed to respect it to allow filtering stale feature. \r\n3. Client\r\n   Client will have to always use LAST request. (currently it uses LIST when time range filtering is not requested)\r\n\r\n**To be discussed further**\r\n- Should we add new API to serving service which simplify request and response since we know it will always return LAST? Currently the request and response is complex to cater the needs LAST and LIST.\r\n\r\nThoughts?\r\n@tims @zhilingc @woop @baskaranz @mansi @budi ","author":{"url":"https://github.com/pradithya","@type":"Person","name":"pradithya"},"datePublished":"2019-01-10T04:19:36.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":18},"url":"https://github.com/53/feast/issues/53"}