Почему эти 2 запроса обрабатывают одинаковые ГБ (и, следовательно, стоят)?

Мои тестовые данные состоят из 27 768 767 строк. Моя схема включает столбец «сообщение» строки типа. Длина этих строк варьируется, но обычно составляет пару сотен символов. Также есть столбец user_id типа int. Вот два запроса, которые возвращают 0 строк (предложения where ничего не соответствуют моим данным). Однако, к моему удивлению, они оба сообщают об обработке 4,69 ГБ.

SELECT * FROM logtesting.logs WHERE user_id=1;

Query complete (1.7s elapsed, 4.69 GB processed)

.

SELECT * FROM logtesting.logs WHERE message CONTAINS 'this string never appears';

Query complete (2.1s elapsed, 4.69 GB processed)

Поскольку целые числа хранятся в 8 байтах, я ожидал, что данные, обработанные в первом (user_id) будет примерно 213 МБ (28 миллионов строк * 8 байтов на user_id). Последний (сообщение) запрос сложнее оценить, поскольку строки различаются по длине, но я ожидаю, что он будет в несколько раз больше, чем первый запрос (user_id).

Правильно ли я понимаю, как BigQuery рассчитывает стоимость запросов?


person Ian Rose    schedule 09.07.2015    source источник


Ответы (1)


Независимо от того, что вы делаете, BigQuery нужно будет сканировать все строки в ваших таблицах (хотя и не обязательно все столбцы), поэтому это нормально, поскольку ваша таблица не меняется. Предложение where означает, что данные НЕ ВОЗВРАЩАЮТСЯ. Его еще нужно обработать.

Единственный способ убедиться, что вы снижаете объем обработки, — не выбирать все столбцы. BigQuery основан на столбцах, поэтому, если вам не нужны все ваши атрибуты, не возвращайте их все (это также означает, что они не будут обрабатываться). ЭТО поможет снизить ваши расходы :)

Исторически сложилось так, что «выбрать *» не поддерживался, чтобы люди не узнали об этом на собственном горьком опыте.

person Patrice    schedule 09.07.2015
comment
Вау, это супер странно. Я ожидал, что выбранные столбцы не будут иметь значения, поскольку у меня не было совпадающих строк, но я просто попробовал select user_id вместо select *, и это определенно изменило ситуацию. 424 МБ обработано в первом запросе и 2,17 ГБ — во втором. Возможно, оптимизация чтения требует, чтобы BigQuery извлекал все столбцы, которые ему могут когда-либо понадобиться (как для предложений where, так и для возвращаемых значений) за один раз, поэтому он не может выполнить оптимизацию, которую я предполагал. - person Ian Rose; 09.07.2015
comment
Так как BigQuery осколки, этого и следовало ожидать. Так как он не может знать заранее, что понадобится, а что нет, он просто разбрасывает всю вашу таблицу на шарды, и каждый шард фильтрует результаты. Так как всю вашу таблицу нужно пересылать туда и обратно, вы платите за все это. Вот почему важно изменить выбор, так как это означает, что отправляются только соответствующие столбцы. - person Patrice; 09.07.2015