Google Bigtable против BigQuery для хранения большого количества событий

Фон

Мы хотели бы хранить наши неизменяемые события в (желательно) управляемом сервисе. Средний размер одного события составляет менее 1 Кб, а у нас от 1 до 5 событий в секунду. Основная причина хранения этих событий - возможность воспроизвести их (возможно, используя сканирование таблиц) после того, как мы создадим будущие службы, которые могут быть заинтересованы в этих событиях. Поскольку мы находимся в облаке Google, мы, очевидно, рассматриваем сервисы Google в качестве первого выбора.

Я подозреваю, что для этого подойдет Bigtable, но согласно калькулятор цен это будет стоить нам более 1400 долларов США в месяц (что для нас большой сделка):

введите описание изображения здесь

Если посмотреть на что-то вроде BigQuery, вы получите цену в 3 доллара в месяц (если я не упускаю что-то важное ):

введите описание изображения здесь

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

Вопросы

Можно ли использовать для этого BigQuery вместо Bigtable, чтобы сократить расходы? Например, в BigQuery есть что-то под названием потоковые вставки, что, на мой взгляд, похоже на то, что мы мог бы использовать. Есть ли что-нибудь, что укусит нас в краткосрочной или долгосрочной перспективе, о чем я мог бы не знать, если бы пошел по этому пути?


google-bigquery google-app-engine google-cloud-bigtable bigtable
person Johan    schedule 23.12.2015    source источник
comment
Вы не упускаете из виду самое необходимое, BQ очень дешевый.   -  person Pentium10    schedule 23.12.2015
comment
BigQuery оптимизирован для длительного хранения и аналитики, BigTable - для интенсивного использования онлайн-приложением.   -  person Igor Artamonov    schedule 23.12.2015
comment
Не уверен, но могут быть ограничения с точки зрения операций. Например, вы можете делать только 1k добавлений в таблицу в день (это был один лимит BQ api, который я достиг некоторое время назад). Хотя я думаю, что потоковый API более щадящий. Возможно, стоит рассмотреть еще одно измерение.   -  person andrewm4894    schedule 24.12.2015

Ответы (6)


arrow_upward
11
arrow_downward

Bigtable отлично подходит для больших (> = 1 ТБ) изменяемых наборов данных. Он имеет низкую задержку под нагрузкой и управляется Google. В вашем случае, я думаю, вы на правильном пути с BigQuery.

person Solomon Duskis    schedule 23.12.2015

arrow_upward
9
arrow_downward

К вашему сведению

Cloud Bigtable не является реляционной базой данных; он не поддерживает SQL-запросы или объединения, а также многострочные транзакции. Кроме того, это не лучшее решение для небольших объемов данных (‹1 ТБ).

Рассмотрим следующие случаи: - Если вам нужна полная поддержка SQL для системы онлайн-обработки транзакций (OLTP), рассмотрите вариант Google Cloud SQL.

Если вам нужны интерактивные запросы в системе онлайн-аналитической обработки (OLAP), рассмотрите Google BigQuery.

Если вам нужно хранить неизменяемые большие двоичные объекты размером более 10 МБ, например большие изображения или фильмы, рассмотрите возможность использования облачного хранилища Google.

Если вам нужно хранить высокоструктурированные объекты или если вам нужна поддержка транзакций ACID и запросов, подобных SQL, рассмотрите возможность использования Cloud Datastore.

person RagSawant_ProjectMango    schedule 17.01.2017

arrow_upward
7
arrow_downward

Общая стоимость зависит от того, как часто вы будете запрашивать данные. Если это резервная копия, и вы не слишком часто воспроизводите события, это будет очень дешево. Однако, если вам нужно воспроизводить его один раз в день, вы слишком легко начнете запускать сканирование 5 долларов за ТБ. Мы также были удивлены дешевизной вставки и хранения, но это не так, потому что Google ожидает, что вы в какой-то момент будете запускать к ним дорогостоящие запросы. Однако вам придется спроектировать несколько вещей. Например. У потоковых вставок AFAIK нет гарантии того, что они будут записаны в таблицу, и вам нужно часто опрашивать хвост списка, чтобы увидеть, действительно ли он был написан. Однако отследить можно эффективно с помощью декоратора таблицы временного диапазона (не платя за сканирование всего набора данных).

Если вас не волнует порядок, вы можете даже разместить столик бесплатно. Тогда не нужно запускать «запрос».

person Manuel Arwed Schmidt    schedule 17.01.2016

arrow_upward
5
arrow_downward

Google Cloud - блок-схема выбора вариантов базы данных GCP

Эта блок-схема может помочь в выборе между различными предложениями облачного хранилища Google (Заявление об отказе от ответственности! Скопировано это изображение со страницы облака Google)

Если ваш вариант использования - это действующая база данных (скажем, серверная часть веб-сайта), BigTable - это то, что вам нужно (все же это не на самом деле OLTP система хотя). Если это больше похоже на аналитику данных / хранилище данных, то вам нужен BigQuery.

Подумайте о OLTP и OLAP; Или, если вы знакомы с Cassandra и Hadoop, BigTable примерно соответствует Cassandra, BigQuery примерно соответствует Hadoop (Согласен, не совсем справедливое сравнение, но вы поняли идею)

https://cloud.google.com/images/storage-options/flowchart.svg

Помните, что Bigtable не является реляционной базой данных, это решение noSQL без каких-либо функций SQL, таких как JOIN и т. Д. Если вам нужна RDBMS OLTP, вам, возможно, придется взглянуть на cloudSQL (mysql / postgres) или гаечный ключ.

Cloud Spanner относительно молод, но эффективен и многообещающ. По крайней мере, маркетинг Google утверждает, что его функции лучше обоих миров (традиционная СУБД и noSQL).

введите здесь описание изображения

Аспект затрат

Аспект затрат уже хорошо освещен здесь https://stackoverflow.com/a/34845073/6785908

Я знаю, что это очень поздний ответ, но все равно добавляю его, если он может помочь кому-то другому в будущем.

person so-random-dude    schedule 23.08.2018

arrow_upward
3
arrow_downward

Трудно резюмировать лучше, чем это уже сделано Google.

Я думаю, вам нужно выяснить, как вы собираетесь использовать (воспроизводить) свои данные (события), и это может помочь вам в принятии окончательного решения.

Пока что BigQuery кажется вам лучшим выбором

person Mikhail Berlyant    schedule 23.12.2015

arrow_upward
1
arrow_downward

Bigtable - это распределенная (работающая на кластерах) база данных для приложений, управляющих большими объемами данных. Он предназначен для массивных неструктурированных данных, масштабируется по горизонтали и состоит из семейств столбцов. Он хранит данные в парах ключ-значение, а не в реляционных или структурированных базах данных.

BigQuery - это приложение хранилища данных. Это означает, что он обеспечивает подключение к нескольким источникам данных или потокам, чтобы их можно было извлекать, преобразовывать и загружать в таблицу bigQuery для дальнейшего анализа. В отличие от Bigtable, он хранит данные в структурированных таблицах и поддерживает запросы SQL.

Случаи применения; Если вы хотите проводить аналитику или бизнес-аналитику, извлекая информацию из собранных данных из различных источников (приложений, исследований, опросов, отзывов, журналов и т. Д.) Вашей организации, вы можете собрать всю эту информацию в одном месте. Скорее всего, это хранилище данных Bigquery.

Если у вас есть приложение, которое собирает большие данные, другими словами массивную информацию (большой объем данных) за раз на более высоких скоростях (высокая скорость) и в неструктурированных несогласованных формах с различными типами данных, такими как аудио, текст, видео, изображения и т. Д. . (Разнообразие и достоверность), то вероятным выбором приложения базы данных для этого приложения будет Bigtable.

person ama    schedule 27.06.2020