我们正在为bq.py编写包装器,结果集大于100k行时遇到一些问题。在过去,这似乎运行得很好(我们与Google BigQuery Incomplete Query Replies on Odd Attempts有相关问题)。也许我不明白doc page上解释的限制?在
例如:
#!/bin/bash
for i in `seq 99999 100002`;
do
bq query -q --nouse_cache --max_rows 99999999 "SELECT id, FROM [publicdata:samples.wikipedia] LIMIT $i" > $i.txt
j=$(cat $i.txt | wc -l)
echo "Limit $i Returned $j Rows"
done
产量(注意有4行格式):
^{pr2}$在我们的包装器中,我们直接访问API:
while row_count < total_rows:
data = client.apiclient.tabledata().list(maxResults=total_rows - row_count,
pageToken=page_token,
**table_dict).execute()
# If there are more results than will fit on a page,
# you will recieve a token for the next page
page_token = data.get('pageToken', None)
# How many rows are there across all pages?
total_rows = min(total_rows, int(data['totalRows'])) # Changed to use get(data[rows],0)
raw_page = data.get('rows', [])
在这种情况下,我们希望得到一个令牌,但是没有返回。在
抱歉,我花了一点时间才回复你。在
我能够识别出一个存在于服务器端的bug,在Java客户机和python客户机上都会看到这一点。我们计划在下周推出一个解决方案。一旦发生这种情况,你的客户就应该开始正确行事。在
顺便说一句,我不确定您是否已经知道这一点,但是有一个完整的独立python客户机可以用来从python访问API。我认为这可能比作为bq.py公司. 您可以在本页找到指向它的链接: https://developers.google.com/bigquery/client-libraries
我可以用bq命令行重现您看到的行为。那好像是个bug,我看看我能做些什么来修复它。在
关于您所查询的数据,我注意到的一点是只选择id字段,并将行数限制在100000行左右。这将产生大约1百万的数据,因此服务器可能不会对结果进行分页。选择较大数量的数据将强制服务器分页,因为它无法在单个响应中返回所有结果。如果你对100000行的示例.wikipedia你将得到大约50米的回报,这应该足够开始看到一些分页发生。在
您是否看到从python客户机返回的结果也太少了,或者对于没有为您的示例.wikipedia询问?在
相关问题 更多 >
编程相关推荐