问题标签 [google-cloud-bigtable]

我正在寻找一个合适的谷歌数据/存储选项，用作将原始 JSON 事件流式传输到的位置。

这些事件是由用户响应非常大的电子邮件广播而生成的，因此吞吐量可能在某一时刻非常低，在短时间内高达每秒约 25,000 个事件。这些事件的 JSON 表示每个可能只有 1kb 左右

我想简单地将这些事件存储为原始和未处理的 JSON 字符串，仅追加，并为插入的每条记录使用单独的顺序数字标识符。我计划使用此标识符作为消费应用程序能够按顺序处理流的一种方式（以类似于 Kafka 消费者通过流跟踪其偏移量的方式） - 这将允许我重播事件流从我选择的角度来看。

我正在利用 Google Cloud Logging 来聚合来自 Compute Engine 节点的事件流，从这里我可以直接流式传输到 BigQuery 表或 Pub/Sub 主题。

BigQuery 似乎不仅能够处理流式插入，但它似乎没有自动递增 id 列的概念，并且还表明它的查询模型最适合聚合查询而不是窄结果集。我查询下一个最高行的要求显然与此背道而驰。

我目前最好的想法是推入 Pub/Sub 并将每个事件写入 Cloud SQL 数据库。这样，如果 Cloud SQL 无法跟上，Pub/Sub 可以缓冲事件。我对自动标识符和可能的日期戳列的渴望使这感觉像是一个“表格”用例，因此我觉得 NoSQL 选项也可能不合适

如果有人有更好的建议，我很想得到一些意见。

在使用 Quickstart 的 Google Cloud Bigtable 中，我尝试创建一个表，然后执行“List”，这会导致下面的错误消息并终止 HBase shell。请指教...谢谢。

I am looking to get data from bigtable into dataflow in an unbounded fashion such that the processing is triggered based on continuos inserts into the table. The document (https://cloud.google.com/bigtable/docs/dataflow-hbase) only talks about bounded read using scans. Does the connector or big table support this model at all?

我遇到了 gRPC C++ 客户端对谷歌云 Bigtable 进行调用的问题。这些调用偶尔会挂起，只有在设置了调用截止日期时才会返回调用。向 gRPC 团队提交了一个问题：https ://github.com/grpc/grpc/issues/6278 ，其中提供了堆栈跟踪和一条 gRPC 跟踪日志。

最常挂起的调用是ReadRows流读取调用。我也见过MutateRow几次通话挂起，但这种情况相当罕见。

gRPC 跟踪显示服务器返回了一些响应，但是该响应似乎不足以让 gRPC 客户端继续。

我确实花了相当多的时间调试代码，到目前为止在客户端没有发现明显的问题，也没有看到内存损坏。这是一个单线程应用程序，一次调用一个，客户端并发不是问题。客户端在谷歌计算引擎盒上运行，因此网络也可能不是问题。gRPC 客户端与 github 存储库主线保持同步。

任何建议，将不胜感激。如果有人有调试想法，那也很棒。到目前为止，使用 valgrind、gdb 将应用程序减少到具有可重复结果的子集并没有帮助，我无法找出问题所在。问题是随机的，偶尔会出现。

2016 年 5 月 17 日 的附加说明 有人建议重试可能有助于解决该问题。不幸的是，重试对我们来说效果不佳，因为我们必须将其转移到应用程序逻辑中。我们可以轻松地重试更新，即MutateRow通话，我们这样做，这些不是流式通话，很容易重试。但是，一旦应用程序开始对数据库查询结果进行迭代，如果失败，重试意味着应用程序需要重新发出查询并重新开始结果的迭代。这是有问题的。总是可以考虑进行更改，使我们的应用程序一次读取整个结果集，然后在应用程序级别的迭代可以在内存中完成。然后可以处理重试。但由于各种原因，例如内存占用和应用程序延迟，这是有问题的。我们希望在数据库查询结果到达后立即处理它们，而不是在所有查询结果都在内存中时处理。当呼叫挂起时，呼叫延迟也会增加超时。所以，

我们有一个 Google Cloud Dataflow 作业，它写入 Bigtable（通过 HBase API）。不幸的是，它失败的原因是：

java.io.IOException: The Application Default Credentials are not available. They are available if running in Google Compute Engine. Otherwise, the environment variable GOOGLE_APPLICATION_CREDENTIALS must be defined pointing to a file defining the credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information. at com.google.bigtable.repackaged.com.google.auth.oauth2.DefaultCredentialsProvider.getDefaultCredentials(DefaultCredentialsProvider.java:74) at com.google.bigtable.repackaged.com.google.auth.oauth2.GoogleCredentials.getApplicationDefault(GoogleCredentials.java:54) at com.google.bigtable.repackaged.com.google.cloud.config.CredentialFactory.getApplicationDefaultCredential(CredentialFactory.java:181) at com.google.bigtable.repackaged.com.google.cloud.config.CredentialFactory.getCredentials(CredentialFactory.java:100) at com.google.bigtable.repackaged.com.google.cloud.grpc.io.CredentialInterceptorCache.getCredentialsInterceptor(CredentialInterceptorCache.java:85) at com.google.bigtable.repackaged.com.google.cloud.grpc.BigtableSession.<init>(BigtableSession.java:257) at org.apache.hadoop.hbase.client.AbstractBigtableConnection.<init>(AbstractBigtableConnection.java:123) at org.apache.hadoop.hbase.client.AbstractBigtableConnection.<init>(AbstractBigtableConnection.java:91) at com.google.cloud.bigtable.hbase1_0.BigtableConnection.<init>(BigtableConnection.java:33) at com.google.cloud.bigtable.dataflow.CloudBigtableConnectionPool$1.<init>(CloudBigtableConnectionPool.java:72) at com.google.cloud.bigtable.dataflow.CloudBigtableConnectionPool.createConnection(CloudBigtableConnectionPool.java:72) at com.google.cloud.bigtable.dataflow.CloudBigtableConnectionPool.getConnection(CloudBigtableConnectionPool.java:64) at com.google.cloud.bigtable.dataflow.CloudBigtableConnectionPool.getConnection(CloudBigtableConnectionPool.java:57) at com.google.cloud.bigtable.dataflow.AbstractCloudBigtableTableDoFn.getConnection(AbstractCloudBigtableTableDoFn.java:96) at com.google.cloud.bigtable.dataflow.CloudBigtableIO$CloudBigtableSingleTableBufferedWriteFn.getBufferedMutator(CloudBigtableIO.java:836) at com.google.cloud.bigtable.dataflow.CloudBigtableIO$CloudBigtableSingleTableBufferedWriteFn.processElement(CloudBigtableIO.java:861)

这没什么意义，因为该作业已经在 Cloud Dataflow 服务/VM 上运行。

Cloud Dataflow 作业 ID：2016-05-13_11_11_57-8485496303848899541

我们正在使用bigtable-hbase-dataflowversion 0.3.0，并且我们想使用 HBase API。

我创建了包含多个子过滤器的复杂过滤器 (FilterList)。无法执行带有该过滤器的查询，因为

我检查了 Cloud Bigtable 的配额和服务限制：

• https://cloud.google.com/bigtable/docs/schema-design#size-limits
• https://cloud.google.com/bigtable/quota

没有定义上述限制的文件。我也检查了BigtableOptionsFactory，但没有看到更改该限制的选项。我怎样才能避免这个限制？

堆栈跟踪：

使用单调递增密钥（如传统时间戳）的危险在 docs 中已经清楚地列出。

在撰写本文时，不太清楚的是在键中使用单调递减模式可能产生的影响，这是在定期检索“首先是最近的记录”时建议的一种方法。

任何人都可以权威地谈论使用减少键与增加键相比的影响，也许是：“可比较的热点”、“减少的热点”或“没有热点但会导致其他不良/灾难性行为”？

PS 当然，我可能没有（也可能永远不会）有足够“大”的数据来建议 Bigtable 作为合适的数据存储选择，但我不清楚为什么 Bigtable 被描述为时间序列数据的“自然契合”，而“最佳实践” “对于可能的读者（即对键使用范围扫描——可能按时间戳聚类）似乎直接对可能的作者的“最佳实践”感到不便（即不要使用时间戳，除非键可以是“de-由提升的字段、盐分片或随机熵聚集”，但也许我遗漏了一些东西……或者这只是“最先进的技术”？

我有一个带有多个表的 Google 云大表部署。有没有办法在权限中创建具有表级粒度的服务帐户？

例如，我有两个作业 A 和 B，这样 1.作业 A 只能读取和写入表 T1（通过服务帐户 Sa）；和 2. 作业 B 获得对表 T2 的读写访问权限，但只有对表 T1 的读取访问权限（通过服务帐户 Sb）。

谢谢。

我正在尝试通过存储在后端的数据库中来跟踪我的 android 应用程序中的用户事件。我正在为我的移动后端使用 Google App Engine。我想弄清楚 Google App Engine 中的 Datastore 是否适合这个。另外，我遇​​到了 NoSQL 的 Bigtable（计费功能）。

在 Google App Engine 中使用 Cloud Datastore 与 Bigtable 的优缺点是什么？

此外，我找不到自动清除数据存储区中的旧数据（即早于特定日期等）的方法（我发现了一些使用 cron-job 的建议）。

我想在 Google Cloud Bigtable（几个 PetaBytes）上存储大量数据以供服务。我计划使用主键访问数据，有时通过键前缀查询。

没有数据更新计划。仅附加到现有表。

我的问题是：由于我不使用我的任何列来过滤/查询/排序我的查询（无论如何这在 Bigtable 中是不可能的）将我的数据存储在单独的列中而不是每行单个 JSON 文档有什么好处？

谢谢！