title: Big table vs Big Query usecase for timeseries data
body: <p>I am looking to finalize on Big table vs Big Query for my usecase of timeseries data.</p>
  
  <p>I had gone through <a href="https://cloud.google.com/bigtable/docs/schema-design-time-series" rel="noreferrer">https://cloud.google.com/bigtable/docs/schema-design-time-series</a></p>
  
  <p>This is for storing an Omniture data which contains information like website visitor key(some Long key), his cookie id(some Long key), timestamp series data web hits for his IP, cookie</p>
  
  <p>What can be used as the rowkey for Big table? I cannot be using timestamp or CookieId as a prefix, as I learn from the best practices. But should have an identifier(preferably alphabet?) and then followed by timeseries suffix. The data has a volume of 500 Million with 52 columns stored in SQL table today. I think the data might be updated based on OLTP processing. But the table would be later queried on timeseries data for like OLAP processing.</p>
  
  <p>a) Would Big table would be a best option here, or should I be using Big Query since just querying later based on timeseries data would help me more?
  b) If using Big table, what would be the best row key, since timeseries is the only meaning filter i see for my data. I believe, using other fields in the table like visitorkey, cookieid ids(Long ids) as prefix with timestamp would still cause entire data to be filling up 1 node in Bigtable, instead of distributing.</p>
  
  <p>Please let me know. </p>