Google Bigtable vs BigQuery для хранения большого количества событий
Фон
Мы хотели бы хранить наши неизменяемые события в (предпочтительно) управляемом сервисе. Средний размер одного события меньше 1 Кб, и мы имеем от 1 до 5 событий в секунду. Основная причина хранения этих событий заключается в том, чтобы иметь возможность воспроизвести их (возможно, с помощью сканирования таблиц), как только мы создадим будущие службы, которые могут быть заинтересованы в этих событиях. Поскольку мы находимся в облаке Google, мы, очевидно, рассматриваем сервисы Google как первый выбор.
Я подозреваю, что Bigtable хорошо подходит для этого, но согласно калькулятору цен это будет стоить нам более 1400 долларов в месяц (что для нас являетсябольшой сделкой):
Глядя на что-то вроде BigQuery выдает цену 3 доллара в месяц (если я не упускаю что-то существенное):
Даже при том, что база данных без схемы была бы лучше для нас, мы были бы в порядке с существенным хранением наших данных. события в виде большого двоичного объекта с некоторыми метаданными.
Вопросы
Можем ли мы использовать BigQuery для этого вместо Bigtable для снижения затрат? Например, BigQuery имеет что-то под названием streaming inserts, которое мне кажется, что мы могли бы использовать. Есть ли что-нибудь, что укусит нас в краткосрочной или долгосрочной перспективе, о чем я мог бы не знать, если бы пошел по этому пути?
5 ответов:
Bigtable отлично подходит для больших (>=1 ТБ) изменяемых наборов данных. Он имеет низкую задержку при загрузке и управляется Google. В вашем случае, я думаю, вы на правильном пути с BigQuery.
FYI
Cloud Bigtable не является реляционной базой данных; она не поддерживает SQL-запросы или соединения, а также многорядные транзакции. Кроме того, это не очень хорошее решение для небольших объемов данных (
Рассмотрим эти случаи: - Если вам нужна полная поддержка SQL для обработки транзакций в режиме онлайн (OLTP) система, рассмотрим Google Cloud SQL.
Если вам нужен интерактивный запрос в онлайн аналитической обработке (OLAP) система, рассмотрим Google BigQuery .
Если необходимо хранить неизменяемые большие двоичные объекты размером более 10 МБ, например большие изображения или фильмы, рассмотримоблачное хранилище Google .
Если вам нужно хранить высокоструктурированные объекты, или если вам требуется поддержка ACID транзакций и SQL-подобных запросов, рассмотрим облако Хранилище данных .
Общая стоимостьсводится к тому, как часто вы будете "запрашивать" данные . Если это резервная копия, и вы не слишком часто воспроизводите события, это будет очень дешево. Однако, если вам нужно воспроизводить его один раз в день, вы начинаете запускать сканирование 5$/TB слишком легко. Мы также были удивлены, насколько дешевыми были вставки и хранение, но это ofc, потому что Google ожидает, что вы будете запускать дорогие запросы в определенный момент времени на них. Однако вам придется разработать несколько вещей. Е. Г. Насколько мне известно потокового вставками у вас нет никаких гарантий того, что они будут записаны в таблицу, и вы должны часто опрашивать в хвосте списка, чтобы увидеть, действительно ли это было написано. Однако с помощью декоратора таблиц временных диапазонов можно эффективно выполнять слежение (не оплачивая сканирование всего набора данных).
Если вы не заботитесь о порядке, вы можете даже перечислить таблицу бесплатно. Тогда не нужно запускать "запрос".
Трудно суммировать лучше, чем это уже сделано Google - https://cloud.google.com/bigtable/docs/
Проверьте Cloud Bigtable и другие параметры хранения разделЯ думаю, что вам нужно выяснить, как вы собираетесь использовать (воспроизводить) свои данные (события), и это может помочь вам в принятии окончательного решения.
Пока BigQuery выглядит лучшим выбором для вас
Эта блок-схема может помочь в выборе между различными предложениями Google cloud storage (отказ от ответственности! скопировал это изображение со страницы Google cloud)
Если ваш usecase-это живая база данных (скажем, бэкэнд веб-сайта), BigTable - это то, что вам нужно (хотя это не на самом деле OLTP система). Если это больше похоже на аналитику данных/ datawarehouse, тоBigQuery - это то, что вам нужно.
Подумайте о OLTP vs 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 marketing утверждает, что его функции являются лучшими в обоих мирах (традиционные СУБД и noSQL)
Стоимостной Аспект
Стоимостной аспект уже хорошо освещен здесь https://stackoverflow.com/a/34845073/6785908
Я знаю, что это очень поздний ответ, но добавление его в любом случае может помочь кому-то еще в будущее.
