google-app-engine - bigquery - gcloud bigtable

Google Bigtable vs BigQuery por almacenar gran cantidad de eventos

Question

Fondo

Nos gustaría almacenar nuestros eventos inmutables en un servicio administrado (preferiblemente). El tamaño promedio de un evento es inferior a 1 Kb y tenemos entre 1 y 5 eventos por segundo. La razón principal para almacenar estos eventos es poder reproducirlos (quizás utilizando el escaneo de tablas) una vez que creamos servicios futuros que podrían estar interesados ​​en estos eventos. Como estamos en la nube de Google, obviamente estamos considerando los servicios de Google como primera opción.

Sospecho que Bigtable sería una buena Bigtable para esto, pero según la calculadora de precios nos costará más de 1400 USD al mes (lo que para nosotros es un gran problema):

Mirando algo como BigQuery un precio de 3 USD por mes (si no me falta algo esencial):

A pesar de que una base de datos sin esquema sería más adecuada para nosotros, estaríamos bien con esencialmente almacenar nuestros eventos como un blob con algunos metadatos.

Preguntas

¿Podríamos usar BigQuery para esto en lugar de BigTable para reducir costos? Por ejemplo, BigQuery tiene algo que se llama inserciones de transmisión, lo que para mí me parece algo que podríamos usar. ¿Hay algo que nos morderá a corto o largo plazo y que quizás no sepa si me tomo esta ruta?

Answer 1

Bigtable es ideal para grandes conjuntos de datos mutables (> = 1TB). Tiene baja latencia bajo carga y es administrado por Google. En tu caso, creo que estás en el camino correcto con BigQuery.

Answer 2

El costo general se reduce a la frecuencia con la que "consultará" los datos . Si es una copia de seguridad y no reproduce los eventos con demasiada frecuencia, será muy barato. Sin embargo, si necesita reproducirlo una vez al día, comienza a activar los 5 $ / TB escaneados con demasiada facilidad. También nos sorprendió lo barato que eran las inserciones y el almacenamiento baratos, pero esto es ofc porque Google espera que usted realice consultas costosas en algún momento. Aunque tendrás que diseñar alrededor de algunas cosas. Por ejemplo, las inserciones de transmisión de AFAIK no tienen ninguna garantía de ser escritas en la tabla y usted tiene que sondear con frecuencia en la cola de la lista para ver si realmente fue escrito. Sin embargo, la cola se puede hacer de manera eficiente con el decorador de tablas de rango de tiempo (sin pagar el escaneo de un conjunto de datos completo).

Si no te importa el orden, puedes incluso listar una tabla gratis . No hay necesidad de ejecutar una ''consulta'' entonces.

Answer 3

Es difícil de resumir mejor de lo que ya está hecho por Google: Bigtable
Consulte la sección de opciones de almacenamiento de Cloud Bigtable y otras

Creo que necesita averiguar cómo va a utilizar (reproducir) sus datos (eventos) y esto puede ayudarlo a tomar una decisión final.

Hasta ahora, BigQuery parece ser la mejor opción para ti.

Answer 4

Este diagrama de flujo puede ayudar a decidir entre diferentes ofertas de almacenamiento en la nube de Google (¡Descargo de responsabilidad! Copié esta imagen de la página de la nube de Google)

Si su base de datos es una base de datos en vivo (digamos, backend de un sitio web), BigTable es lo que necesita (aunque en realidad no es un sistema OLTP ). Si se trata más bien de un propósito de análisis de datos / datawarehouse, entonces BigQuery es lo que necesita.

Piense en OLTP vs OLAP; O si está familiarizado con Cassandra y Hadoop, BigTable equivale aproximadamente a Cassandra, BigQuery equivale aproximadamente a Hadoop (de acuerdo, no es una comparación justa, pero entiendes la idea)

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

Tenga en cuenta que Bigtable no es una base de datos relacional, es una solución noSQL sin ninguna función de SQL como JOIN, etc. Si desea un RDBMS OLTP, es posible que deba consultar cloudSQL (mysql / postgres) o spanner .

La llave de la nube es relativamente joven, pero es poderosa y prometedora. Al menos, Google Marketing afirma que sus características son las mejores de ambos mundos (RDBMS tradicional y noSQL)

Aspecto del costo

El aspecto del costo ya está bien cubierto aquí https://.com/a/34845073/6785908

Sé que esta es una respuesta muy tardía, pero agregarla de todos modos en caso de que pueda ayudar a otra persona en el futuro.

Answer 5

Para tu información

Cloud Bigtable no es una base de datos relacional; no admite consultas de SQL o combinaciones, ni admite transacciones de varias filas. Además, no es una buena solución para pequeñas cantidades de datos (<1 TB).

Considere estos casos: - Si necesita soporte completo de SQL para un sistema de procesamiento de transacciones en línea (OLTP), considere Google Cloud SQL .

Si necesita consultas interactivas en un sistema de procesamiento analítico en línea (OLAP), considere Google BigQuery .

Si necesita almacenar blobs inmutables de más de 10 MB, como imágenes o películas grandes, considere Google Cloud Storage .

Si necesita almacenar objetos altamente estructurados, o si necesita soporte para transacciones ACID y consultas similares a SQL, considere Cloud Datastore .