标签: azure-table-storage

有没有办法从Azure表存储中删除项目而不创建基于时间戳删除的工作程序？我想要一些像Azure缓存服务那样的解决方案,我们可以在其中指定消息的时间跨度.

我对如何在Windows Azure中获取blob的大小感到困惑.

在我的情况下,我首先得到blob引用CloudBlockBlob blob = container.GetBlockBlobReference(foo);(这里foo是blob的名称,我确定blob存在).然后我尝试获得blob大小blob.Property.Length;然而,它总是返回0.我在这个语句中断点并跟踪内部内容blob:uriblob是正确的,我可以推断出blob是否正确地从中获取？虽然所有的字段Properties都是null或0.我无法找到解决方案.是因为我目前在本地模拟应用程序Storage Emulator,部署后会好吗？

谢谢和最诚挚的问候.

通过TableServiceEntity在Azure Table Services中存储数据,您只能使用具有公共get/set的常用基本类型(int,string,datetime等).

你从序列化中得到的通常的魔法都没有处理集合,复杂类型,继承等.

解决这个问题的不同方法可能是

• 连接到WritingEntity和ReadingEntity事件以手动设置属性(包括使用一些序列化方法处理复杂类型到普通字符串属性).
• 与上面类似,但使用额外的"存储类"在YourClass < - > YourClassStorage < - > TableServices之间进行转换
• 使用Lokad.Cloud的FatEntities或Lucifure等框架

我错过了什么吗？在哪种情况下哪种方法最好？

使用Azure存储客户端库2.1,我正在进行表存储异步查询.我创建了这段代码:

public async Task<List<TAzureTableEntity>> GetByPartitionKey(string partitionKey)
{
    var theQuery = _table.CreateQuery<TAzureTableEntity>()
                         .Where(tEnt => tEnt.PartitionKey == partitionKey);
    TableQuerySegment<TAzureTableEntity> querySegment = null;
    var returnList = new List<TAzureTableEntity>();
    while(querySegment == null || querySegment.ContinuationToken != null)
    {
        querySegment = await theQuery.AsTableQuery()
                                     .ExecuteSegmentedAsync(querySegment != null ?
                                         querySegment.ContinuationToken : null);
        returnList.AddRange(querySegment);
    }
    return returnList;
}

假设有大量数据返回,因此会有很多往返表存储的往返.我遇到的问题是我们正在等待一组数据,将其添加到内存列表中,等待更多数据,将其添加到同一列表中,等待更多数据,将其添加到列表中......等等等等.为什么不围绕常规TableQuery包装Task.Factory.StartNew()？像这样:

public async Task<List<TAzureTableEntity>> GetByPartitionKey(string partitionKey)
{
    var returnList = await Task.Factory.StartNew(() =>
                                                 table.CreateQuery<TAzureTableEntity>()
                                                .Where(ent => ent.PartitionKey == partitionKey)
                                                .ToList());
    return returnList;
}

这样做似乎我们不会来回反复播放SynchronizationContext.或者它真的重要吗？

编辑以改写问题

上面提到的两种情况有什么区别？

我最近将Microsoft.WindowsAzure.Storage的nuget包更新为3.0包,其中还包括对WCF数据服务客户端及其依赖项的更新.由于更新,我在查询解决时收到错误:

"客户端和服务之间存在类型不匹配.类型'ShiftDigital.Flow.Data.RouteDiagnostic'不是实体类型,但响应有效负载中的类型表示实体类型.请确保客户端上定义的类型匹配服务的数据模型,或更新客户端上的服务引用."

我什么也没做,只是更新了软件包,我的应用程序和我在LinqPad中设置的测试脚本生成了这个异常.

这是我在更新之前返回的实体的定义

public class RouteDiagnostic : TableEntity
    {
        public long? LeadRecipientRouteId { get; set; }
        public bool Successful { get; set; }
        public int Duration { get; set; }
        public string Request { get; set; }
        public string Response { get; set; }

        public RouteDiagnostic()
            : base()
        {
            this.Timestamp = DateTimeOffset.Now;
            this.PartitionKey = GetPartitionKey(this.Timestamp.Date);
            this.RowKey = Guid.NewGuid().ToString();
        }

        public static string GetPartitionKey(DateTime? keyDateTime = null)
        {
            return string.Format("{0:yyyyyMM}", keyDateTime ?? DateTime.Now);
        }
    }

这是执行查询的代码

var storageAccount = Microsoft.WindowsAzure.Storage.CloudStorageAccount.Parse("..."); …

我有一些基本的Azure表,我一直在串行查询:

var query = new TableQuery<DynamicTableEntity>()
  .Where(TableQuery.GenerateFilterCondition("PartitionKey",
    QueryComparisons.Equal, myPartitionKey));

foreach (DynamicTableEntity entity in myTable.ExecuteQuery(query)) {
  // Process entity here.
}

为了加快速度,我将其并行化:

Parallel.ForEach(myTable.ExecuteQuery(query), (entity, loopState) => {
  // Process entity here in a thread-safe manner.

  // Edited to add: Details of the loop body below:

  // This is the essence of the fixed loop body:
  lock (myLock) {
    DataRow myRow = myDataTable.NewRow();
    // [Add entity data to myRow.]
    myDataTable.Rows.Add(myRow);
  }

  // Old code (apparently not thread-safe, though NewRow() is supposed to …

我们最近更新了我们的日志记录以使用Azure表存储,由于它在行和分区查询时非常适合于此目的而具有低成本和高性能.

我们正在尝试遵循为Azure表存储设计可扩展分区策略文档中给出的准则.由于我们正在为此表格进行大量插入(并且希望随着我们的扩展而增加数量),我们需要确保不会达到我们的限制,从而导致日志丢失.我们的设计结构如下:

• 我们在每个环境(DEV,TEST,PROD)上都有一个Azure存储帐户.

• 我们每个产品都有一张桌子.

• 我们对Row Key使用TicksReversed + GUID,这样我们就可以在特定时间内以高性能查询结果块.

• 我们最初选择使用Logger对表进行分区,对于我们来说,这是产品的广泛领域,如API,应用程序,性能和缓存.然而,由于分区数量较少,我们担心这导致所谓的"热"分区,其中在给定时间段内在一个分区上执行了许多插入.所以我们改为上下文分区(对我们来说,类名或API资源).

然而,在实践中我们发现这不太理想,因为当我们一目了然地查看我们的日志时,我们希望它们按时间顺序出现.我们最终会得到按上下文分组的结果块,如果我们想按时间排序,我们必须得到所有分区.

我们有一些想法

• 使用时间块(比如1小时)分区键按时间排序(导致热分区1小时)

• 使用一些随机的GUID进行分区键尝试分发日志(我们无法快速查询Context等功能).

由于这是Azure表存储的常见应用程序,因此必须有某种标准过程. 分区用于存储日志的Azure表的最佳做法是什么？

解决方案约束

• 使用便宜的Azure存储(表存储似乎是显而易见的选择)

• 快速,可扩展的写入

• 丢失日志的可能性很小(即,超过Azure表存储中每秒2000个实体的分区写入速率).

• 阅读按日期排序,最近一次.

• 如果可能的话,对可能对查询有用的东西进行分区(例如产品区域).

情况:我已经开始了一项新工作,并被分配了如何处理传感器数据表的任务.它有13亿行传感器数据.数据非常简单:基本上只是传感器ID,日期和该时间点的传感器值(双倍).

目前,数据存储在MSSQL Server数据库的表中.

到今年年底,我预计行数将增加到2-3亿.

我正在寻找一种更好的方式来存储和查询这些数据(按日​​期),因为我们有很多"大数据"产品,而且我没有管理这些大数据集的真实经验,我在这里问对于任何指针.

它不是一家大公司,我们的资源不是无限的;)

关于我们的用例的更多细节:

• 数据以图形绘制,并显示传感器值随时间的变化.
• 我们计划创建一个API,让我们的客户在他们感兴趣的任何时间段内获取传感器数据(...... 2年前的数据与上个月的数据一样重要).

到目前为止,我的研究使我考虑了以下解决方案:

1. 将数据保留在SQL Server中

   但是对表进行分区(它现在没有分区).这将需要企业版的SQL Server,其成本很高.

2. 将数据移动到Azure SQL Server.

   在那里我们将获得更少的资金,但是一旦我们的DB增长到250GB以上,它的成本会更高(并且超过500gb).

3. 使用多个数据库

   我们每个客户可以使用1个DB.几个较小的数据库将比一个巨大的数据库便宜,但我们有很多客户和计划更多,所以我真的不想考虑管理所有这些数据库.

4. Azure存储表

   到目前为止,这是我最喜欢的选项.我们可以按公司/传感器/年/月对数据进行分区,使用行键日期并存储传感器值.

   我还没来得及测试查询性能,但从我看来它应该是好的.但是有一个主要的缺点,那就是每个HTTP请求返回1000个项目的限制.如果我们需要获取一周的所有传感器数据,我们需要进行大量的HTTP请求.我现在不确定这对我们的用例有多大问题.

5. Azure HDInsight(Azure中的Hadoop)

   如上所述,我没有大数据的经验,目前我还没有充分了解Hadoop是否适合我们的情况(在给定的时间跨度内通过API公开传感器数据).我应该更深入地学习,还是我的时间更好地花在追求另一种选择上？

有没有人有类似案例的经验.什么对你有用？请记住,价格很重要,而"简单"的解决方案可能比非常复杂的解决方案更受欢迎,即使复杂的解决方案可以更好地执行几秒钟.

更新1: 回答以下评论中的一些问题.

• 大约有12 000个传感器,可能每15秒报告一次值.这相当于每天约7000万.实际上,并非所有这些传感器都打开了"报告",因此我们每天都没有获得那么多数据,但由于我们自然希望随着更多客户和传感器的扩展,我真的需要一个可以扩展到每天有数百万的传感器值.
• 分区是一个解决方案,并且使用了几个数据库和/或几个表,但我确实是这样,但是如果/当我用尽其他解决方案时,我认为这是一个后备.
• 我已经阅读了更多关于HBase,http://opentsdb.net/和google的https://cloud.google.com/bigtable/的内容,看起来Hadoop至少可以成为一个真正的替代品.

更新2: 今天我体验了azure表存储和HDInsight(HDI).我们在查询"灵活性"方面并不需要太多,因此我认为Azure表存储看起来很有前景.由于我提到的每个请求1000项限制,因此抽出数据有点慢,但在我的测试中,我认为它对我们的用例来说足够快.

我也偶然发现了OpenTSDB,这是我首先尝试HDI的原因.按照Azure教程(https://azure.microsoft.com/en-us/documentation/articles/hdinsight-hbase-tutorial-get-started/),我能够快速存储一百万条记录并测试一些查询.查询比Azure表存储快得多.我甚至可以在一个http请求中删除300 000条记录(虽然耗时30秒).

但它的成本比Azure表存储要多得多,而且我认为我可以优化我的代码以提高Azure表存储的查询性能(更细粒度的分区键和并行运行请求).因此,由于简单,价格和"足够好"的性能,我现在倾向于Azure Table Storage.

我很快就会向外部顾问介绍我的发现,所以我很高兴能够了解他对事物的看法.

我正在研究一种能够保存天气数据的物联网解决方案.关于如何设置后端,我已经搜索了几天了.我将使用Azure IoT Hub来处理通信,但下一步是问题.

我想将遥测存储到数据库中.这是我感到困惑的地方.一些示例说我应该使用Azure BLOB存储或Azure表存储或Azure SQL.

经过几年的数据收集,我想开始创建数据报告.因此存储需要善于处理大数据.

我坚持的下一个问题是将接收D2C并将其存储到数据库的工作者.所有Azure IoT示例都使用控制台应用程序,而有些则使用Azure Stream分析将事件移植到数据库.什么是最佳做法？它需要能够扩展并尝试使用最佳实践.

提前致谢!

虽然azure表的官方网站谈论其他实体的限制,但我从未读过关于列数据大小限制的任何内容.虽然很少有非官方博客谈论最大尺寸为64KB.是这种情况还是对列的大小没有限制,仅受行大小1MB的限制.