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

Question

Фон

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

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

Глядя на то, как BigQuery оказывает цена 3 USD в месяц (если я не хватает чего-то существенного):

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

Вопросы

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

Answer 1

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

Answer 2

Трудно обобщать лучше, чем это уже сделано Google - https://cloud.google.com/bigtable/docs/
Check Cloud Bigtable и другие варианты хранения раздела

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

До сих пор, BigQuery выглядит как лучший выбор для вас

Answer 3

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

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

Answer 4

FYI

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

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

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

Если вам нужно хранить неизменные сгустки размером более 10 МБ, такие как большие изображений или фильмов, считают Google Cloud Storage.

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