BigQuery Retrieval Times Slow

Question

BigQuery быстро обрабатывает большие наборы данных, однако получение больших результатов из BigQuery не является быстрым.

Например, я выполнил запрос, который возвратил 211,136 строк по трем HTTP-запросам, взяв всего более 12 секунд в общей сложности.
Сам запрос был возвращен из кеша, поэтому не было потрачено времени на выполнение запроса. Хост-сервер Amazon m4.xlarge работает в США-Ист (штат Вирджиния).

В производстве я видел, что этот процесс занимает ~ 90 секунд при возврате строк ~ 1Mn. Очевидно, что некоторые из них могут быть связаны с сетевым трафиком ... но это кажется слишком медленным, потому что это единственная причина (эти 211 136 строк были только ~ 1,7 МБ).

Неужели кто-нибудь еще столкнулся с такой медленной скоростью при возвращении результатов и нашел разрешение?

Обновление: повторный тест на виртуальной машине внутри облака Google с очень близкими результатами. Реализация сетевых проблем между Google и AWS.

Answer 1

Одновременные Запросы, использующие TableData.List

Это не большой, но есть разрешение.

Сделайте запрос и установите максимальные строки на 1000. Если нет токена страницы, просто возвращайте результаты.

Если есть токен страницы, не учитывайте результаты * и используйте API TableData.List. Однако вместо того, чтобы просто отправлять один запрос за раз, отправьте запрос на каждые 10 000 записей * в результате. Для этого можно использовать поля «MaxResults» и «StartIndex». (Обратите внимание, что даже эти более мелкие страницы могут быть разбиты на несколько запросов *, поэтому логика подкачки по-прежнему необходима).

Этот параллелизм (и более мелкие страницы) приводит к значительному сокращению времени поиска. Не так хорошо, как BigQ, просто потоковая передача всех результатов, но достаточно, чтобы начать понимать выгоды от использования BigQ.

Потенциальный Pitfals: держать глаз на графе запроса, так как при больших результирующих наборах не может быть 100req/с дросселированием. Также стоит отметить, что нет никаких гарантий заказа, поэтому использование поля StartIndex в качестве псевдо-пейджинга может не всегда возвращать правильные результаты *.

* Все, что связано с одной астерикой, все еще является просвещенной догадкой, но не подтверждено как истинная/лучшая практика.

Answer 2

Наш SLO на этом API составляет 32 секунды, а вызов занимает 12 секунд. 90 секунд звучит слишком долго, это должно быть связано с задержкой хвоста нашей системы.

Я понимаю, что это неловко медленно. Для этого есть несколько причин, и мы работаем над улучшением латентности этого API. К концу первого квартала следующего года мы сможем развернуть изменение, которое сократит время tabledata.list в два раза (путем обновления интерфейса API до нашей новой технологии One Platform). Если у нас будет больше ресурсов, мы также быстрее выполним jobs.getQueryResults.