标签: azure-table-storage

我不明白为什么,但客户端库中似乎没有机制可以并行执行Windows Azure表存储的许多查询.我已经创建了一个模板类,可以用来节省大量时间,欢迎您随意使用它.不过,如果你能把它分开,我会很感激,并就如何改进这门课提供反馈.

public class AsyncDataQuery<T> where T: new()
{
    public AsyncDataQuery(bool preserve_order)
    {
        m_preserve_order = preserve_order;
        this.Queries = new List<CloudTableQuery<T>>(1000);
    }

    public void AddQuery(IQueryable<T> query)
    {
        var data_query = (DataServiceQuery<T>)query;
        var uri = data_query.RequestUri; // required

        this.Queries.Add(new CloudTableQuery<T>(data_query));
    }

    /// <summary>
    /// Blocking but still optimized.
    /// </summary>
    public List<T> Execute()
    {
        this.BeginAsync();
        return this.EndAsync();
    }

    public void BeginAsync()
    {
        if (m_preserve_order == true)
        {
            this.Items = new List<T>(Queries.Count);
            for (var i = 0; i < Queries.Count; i++)
            {
                this.Items.Add(new …

我正在编写一个"概念证明"应用程序,以研究在必要的重写整个应用程序期间将定制的ASP.NET电子商务系统转移到Windows Azure的可能性.

我很想看看使用Azure表存储作为SQL Azure的替代方案,因为随着应用程序的进一步成熟,存储的实体可能随着时间的推移而改变其架构(属性),并且我不需要进行无休止的数据库架构更改.此外,我们可以在应用程序代码中构建参考完整性 - 因此考虑Azure表存储的情况非常强.

我目前唯一可以看到的潜在问题是我们做了一些简单的报告 - 即两个日期之间的销售价值,特定产品的销售数量等等.我知道Table Storage不支持聚合类型功能,我相信我们可以通过巧妙地使用分区,多个实体类型来存储相同数据的子集以及可能的预聚合来实现我们想要的目标,但我不是100%确定如何去做.

有没有人知道有关Azure表存储设计原则的任何深入文档,以便我们正确有效地使用Tables,PartitionKeys和实体设计等.

有一些简单的文档,目前的书籍往往不会深入研究这个主题.

仅供参考 - 电子商务网站拥有约25,000名客户,每年约需100,000份订单.

我有一个Windows Azure应用程序,其中TableA的所有读取查询都在一系列rowkeys的单个分区上执行.促进此存储方案的分区键实际上是层次结构中对象的扁平名称,因此分区键的格式为{root}_{child1}_{child2}_{leaf}.我可以理解,通过在表的命名中使用分区键的根维度(将分区键变为{child1}_{child2}_{leaf}),将这个大的TableA划分为多个表可能是有益的.

我想要做的是尽可能快地从尽可能多的连接访问这些数据.如果我能弄清楚这些限制是什么或应该是什么,那也是不可思议的.

关于我提议的更改的更具体问题:

1. 这是否会对可扩展性产生影响,即可以在不显着改善性能的情况下提供同步数据访问请求的数量？在同一时间服务？
2. 这会对平均表现产生影响吗？潜在的表现？

我们即将在内部实施CQRS系统的Read部分,目标是大幅提高我们的读取性能.目前,我们的读取是通过Web服务进行的,该服务针对规范化数据运行Linq-to-SQL查询,涉及SQL Azure数据库的某种程度的反序列化.

我们数据的简化结构是:

• 用户
• 对话(将消息分组到相同的收件人)
• 信息
• 收件人(用户集)

我想将其移动到非规范化状态,以便当用户请求查看从EITHER读取的消息提要时:

Azure表存储中保存的非规范化表示

• UserID作为PartitionKey
• ConversationID作为RowKey
• 易于更改的任何易失性数据存储为实体
• 消息在实体中序列化为JSON
• 所述消息的接收者在实体中序列化为JSON
• 表存储中行的有限大小(960KB)的主要问题
• 此外,对"易失性数据"列的任何查询都会很慢,因为它们不是密钥的一部分

Azure表存储中保存的规范化表示

• 对话详细信息,消息和收件人的不同表
• 存储在"对话"表中的邮件和收件人的分区键.
• 吧吧; 这遵循与上述相同的结构
• 获取最大行大小问题
• 但归一化状态是否会降低非规范化表的性能增益？

要么

SQL Azure中保存的非规范化表示

• UserID和ConversationID作为复合主键保存
• 易于更改的任何易失性数据存储在单独的列中
• 消息在列中序列化为JSON
• 所述消息的收件人在列中序列化为JSON
• 索引的最大灵活性和非规范化数据的结构
• 性能比Table Storage查询慢得多

我要问的是,是否有人在表存储或SQL Azure中实现非规范化结构的经验,您会选择哪种？还是有一种我错过的更好的方法？

我的直觉说表存储中的标准化(至少在某种程度上)数据是可行的方法; 但是我担心它会降低性能,以便进行3次查询以获取用户的所有数据.

Azure计费基于已用空间的大小.现在我需要知道细节.我的存储中每个存储对象的大小是多少(blob容器,单个表)？

编写一个枚举所有blob并计算每个容器的总大小的代码很容易.但桌子怎么样？如何在Azure存储中获取某个表的大小？

在Windows Azure存储中,我们曾经这样做来创建表:

var tableClient = account.CreateCloudTableClient();
tableClient.CreateTableIfNotExist(TableName);

我刚刚下载了最新版本的azure存储库(v2),而我之前的代码不再适用了:

'Microsoft.WindowsAzure.Storage.Table.CloudTableClient'不包含'CreateTableIfNotExist'的定义,并且没有扩展方法'CreateTableIfNotExist'可以找到接受类型'Microsoft.WindowsAzure.Storage.Table.CloudTableClient'的第一个参数.

v2中的优秀代码是什么？

我真的陷入了对Azure表存储的查询过滤器.我可以知道如何查询时间戳吗？当我单独查询分区键1005时,我得到了我不想要的完整表.当我添加带有时间戳的"和"条件时(尝试了很多格式,但它没有返回任何内容.下面的代码片段:

var lowerlimit = DateTime.Today.AddDays(-52).ToString("yyyy-MM-dd");

string dateRangeFilter = TableQuery.CombineFilters(
    TableQuery.GenerateFilterCondition("PartitionKey", QueryComparisons.Equal, "1005"),
    TableOperators.And,
    TableQuery.GenerateFilterCondition("TimeStamp", QueryComparisons.GreaterThanOrEqual, lowerlimit));

我可以在Azure表存储中更新实体的RowKey或PartitionKey属性吗？

我想是或者可能只是PartitionKey但现在我想尝试这样做(尝试更改RowKey或PartitionKey)并得到错误:

The remote server returned an error: (404) Not Found.
Description: An unhandled exception occurred during the execution of the current 
             web request. Please review the stack trace for more information about 
             the error and where it originated in the code.

Exception Details: System.Net.WebException: The remote server returned an error:
                  (404) Not Found.

Source Error:

Line 143:
Line 144:                var updateOperation = TableOperation.Replace(entity);
Line 145:                _table.Execute(updateOperation);
Line 146:            }
Line 147:        }

我的代码更新实体(简短版):

var query = new TableQuery<CalculatorAccessTokenEntity>()
                .Where(TableQuery.GenerateFilterCondition("AccessUrl", …

我们目前使用Redis作为我们Web应用程序的持久缓存,但由于内存和成本有限,我开始考虑Table存储是否可行.

我们存储的数据是相当基本的json数据,带有明确的2部分密钥,我们将其用于表存储中的分区和行密钥,因此我希望这意味着快速查询.

我很欣赏一个在内存中,一个在外面,所以表存储会慢一点但是随着我们的扩展,我相信只有一个CPU提供来自Redis缓存的数据,而对于Table存储,我们不会有这个问题,因为它会是减少到我们运行的Web服务器的数量.

有没有人有这种方式使用表存储的经验或2之间的比较.

我应该补充一点,我们以极简主义的方式使用Redis来获取/设置,仅此而已,我们逐出我们自己的数据,并且当它耗尽空间时将其驱逐到Redis.

我一直试图很好地掌握Azure Table存储一段时间,虽然我一般都了解它是如何工作的但我真的很难动摇我的关系数据库思维.我通常以身作则最好的学习,所以我想知道是否有人可以帮助我.我将概述一个关于如何使用关系数据库解决问题的简单设置,有人可以帮助指导我将其转换为使用Azure表存储吗？

假设我有简单的笔记记录应用程序,它有用户,每个用户可以拥有他们想要的尽可能多的笔记,并且每个笔记可以拥有所需数量的用户(所有者或查看者).如果我要使用关系数据库部署它,我可能会按如下方式部署它:

对于数据库,我会从这样的事情开始:

CREATE TABLE [dbo].[Users](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [Username] [nvarchar](20) NOT NULL)

CREATE TABLE [dbo].[UsersNotes](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [UserID] [int] NOT NULL,
    [NoteID] [int] NOT NULL)

CREATE TABLE [dbo].[Notes](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [NoteData] [nvarchar](max) NULL)        

我将随后的设置之间的关系Users.ID and UsersNotes.UserID,以及Notes.ID and UsersNotes.NoteID与约束来实施参照完整性.

对于应用程序,我会让一个ORM生成一些具有匹配的名称属性的实体,并且我可能会称它为一天:

public class Users
{
    public int ID { get; set; }
    public String Username { get; set; }
}
// and so on and so forth

我意识到这个设计完全依赖于关系数据库,而我正在寻找的是如何动摇这一思路以使用Azure …