Использование таблицы Big Table против Big Query для данных временных рядов - PullRequest
Новая
       17

Использование таблицы Big Table против Big Query для данных временных рядов

0 голосов
/ 18 сентября 2018

Я хочу завершить работу над «Большой таблицей» и «Большим запросом» для моего сценария использования временных рядов.

Я прошел https://cloud.google.com/bigtable/docs/schema-design-time-series

Это для хранения данных Omniture, которые содержат информациюнапример, ключ посетителя веб-сайта (некоторый длинный ключ), его идентификатор куки-файла (некоторый длинный ключ), веб-хиты данных временных меток для его IP-адреса, cookie

Что можно использовать в качестве ключа строки для большой таблицы?Я не могу использовать метку времени или CookieId в качестве префикса, как я узнал из лучших практик.Но должен иметь идентификатор (предпочтительно алфавит?), А затем суффикс временной серии.Объем данных составляет 500 миллионов, и сегодня в таблице SQL хранятся 52 столбца.Я думаю, что данные могут быть обновлены на основе обработки OLTP.Но позже к таблице будут обращаться данные временных рядов для такой же обработки OLAP.

a) Будет ли большая таблица здесь лучшим вариантом, или я должен использовать большой запрос, так как простой запрос на основе данных временных рядов поможетмне больше?б) При использовании большой таблицы, какой будет лучшим ключ строки, так как временные ряды являются единственным значимым фильтром, который я вижу для моих данных.Я полагаю, что при использовании других полей в таблице, таких как ключ посетителя, идентификаторы cookieid (длинные идентификаторы) в качестве префикса с меткой времени, все равно будет вызывать заполнение всего узла на 1 узел в Bigtable вместо распределения.

Пожалуйста, дайте мне знать,

1 Ответ

0 голосов
/ 19 сентября 2018

(я инженер в Cloud Bigtable Team)

Как вы узнали из наших документов, формат ключа строки - это самое важное решение, которое вы принимаете при использовании Bigtable, поскольку оно определяет, какие шаблоны доступаможет быть выполнено эффективно.Использование visitorKey + cookie в качестве префикса до того, как временная метка звучит для меня так, будто это позволит избежать проблем с горячими точками, поскольку на вашем сайте почти наверняка будет гораздо больше посетителей, чем будет узлов в вашем кластере.Bigtable постоянно обслуживает подобные сценарии использования временных рядов!

Однако вы также исходите из архитектуры SQL, которая не всегда подходит для модели схемы / запросов Bigtable.Итак, вот несколько вопросов, с которых можно начать:

  • Планируете ли вы выполнить много специальных запросов, таких как «ВЫБРАТЬ ИЗ Bigtable WHERE B = x»?Если это так, настоятельно предпочитайте BigQuery.Bigtable не может поддержать этот запрос, не выполнив полное сканирование таблицы.И вообще Bigtable больше ориентирован на потоковую передачу простого подмножества данных, скажем, на задание Dataflow, а не на сложную обработку в самих запросах.
  • Потребуются ли многострочные транзакции OLTP?Опять же, используйте BigQuery, так как Bigtable поддерживает транзакции только в пределах одной строки.
  • Вы транслируете новые события с высоким QPS?Bigtable намного лучше для таких обновлений большого объема.Помните, что первоначальная цель Bigtable заключалась в том, чтобы использовать в качестве приемника произвольного доступа обновления веб-сканера в поисковом индексе Google!
  • Хотите ли вы выполнять какие-либо масштабные сложные преобразования данных?Опять же, Bigtable здесь, вероятно, лучше, так как вы можете быстрее передавать и возвращать данные и позволить настраиваемой бизнес-логике в задании потока данных делать все, что вам угодно.

Вы также можете объединить две услуги, если вам нужна некоторая комбинация этих функций.Например, допустим, что вы постоянно получаете объемные обновления, но хотите иметь возможность выполнять сложные специальные запросы.Если вы работаете с немного задержанной версией данных, имеет смысл записать обновления в Bigtable, затем периодически сканировать таблицу с использованием Dataflow и экспортировать версию последних событий с последующей обработкой в ​​BigQuery.GCP также позволяет BigQuery обслуживать запросы непосредственно из Bigtable в некоторых регионах: https://cloud.google.com/bigquery/external-data-bigtable

...