标签: azure-cosmosdb

近几年来,微软提供了一个名为"Table Storage"的"NoSQL"密钥/值存储(http://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-表/)

表存储提供高性能,可扩展性(通过分区)和相对较低的成本.Table的主要缺点是只能对Partition和Row键建立索引 - 因此对值进行查询效率非常低.

最近,微软宣布了一项名为"DocumentDB"的新"NoSQL"服务(http://azure.microsoft.com/en-us/documentation/services/documentdb/)

DocumentDB存储JSON对象,而不是存储属性列表(如Tables do).整个对象被索引 - 因此可以基于存储对象的每个属性和任何嵌套属性创建有效的查询.

微软表示,DocumentDB也提供了高性能和可扩展性.

如果是这样 - 为什么有人会使用Table Storage而不是DocumentDB？听起来DocumentDB提供与Tables相同的功能,但具有其他功能,例如索引任何内容的功能.

如果有人能够在DocumentDB和Table Storage之间进行比较,我会很高兴,强调每个人的利弊.

看来在azure站点中的documentdb允许的SQL查询中以及通过documentdb explorer(https://studiodocumentdb.codeplex.com/)不能支持"从c中选择计数(*)" .到目前为止,获得记录计数的唯一方法是从代码(见下文).但是,我们的集合中有足够的文件,现在崩溃了.有没有办法计算集合中有多少文档比我的解决方案更有效？

DocumentClient dc = GetDocumentDbClient();
var databaseCount = dc.CreateDatabaseQuery().ToList();
Database azureDb = dc.CreateDatabaseQuery().Where(d => d.Id == Constants.WEATHER_UPDATES_DB_NAME).ToArray().FirstOrDefault();

var collectionCount = dc.CreateDocumentCollectionQuery(azureDb.SelfLink).ToList();

DocumentCollection update = dc.CreateDocumentCollectionQuery(azureDb.SelfLink).Where(c => c.Id == "WeatherUpdates").ToArray().FirstOrDefault();

var documentCount = dc.CreateDocumentQuery(update.SelfLink, "SELECT * FROM c").ToList();

MessageBox.Show("Databases: " + databaseCount.Count().ToString() + Environment.NewLine
                +"Collections: " + collectionCount.Count().ToString() + Environment.NewLine
                + "Documents: " + documentCount.Count().ToString() + Environment.NewLine, 
                 "Totals", MessageBoxButtons.OKCancel); 

我正在设置我们的第一个Azure Cosmos数据库 - 我将导入第一个集合,即我们的一个SQL Server数据库中的表中的数据.在设置集合时,我无法理解分区键的含义和要求,我在设置此初始集合时必须特别指出.

我在这里阅读了文档:(https://docs.microsoft.com/en-us/azure/cosmos-db/documentdb-partition-data)并且仍然不确定如何继续使用此分区键的命名约定.

有人可以帮我理解我应该如何考虑命名这个分区键吗？请参阅下面的屏幕截图,了解我要填写的字段.

如果它有帮助,我导入的表包含7列,包括唯一的主键,一列非结构化文本,一列URL和该记录的URL的其他几个辅助标识符.不确定是否有任何信息与我如何命名我的分区密钥有关.

编辑:我已根据@Porschiey的请求添加了我正在导入的表格中的几条记录的屏幕截图.

我们LIKE可以在T-SQL中使用关键字来过滤掉记录吗？

在像这样的Azure Documentdb文档中

{
"id": "WakefieldFamily",
"parents": [
    { "familyName": "Wakefield", "givenName": "Robin" },
    { "familyName": "Miller", "givenName": "Ben" }
],
"children": [
    {
        "familyName": "Merriam", 
        "givenName": "Jesse", 
        "gender": "female", 
        "grade": 1,
        "pets": [
            { "givenName": "Goofy" },
            { "givenName": "Shadow" }
        ]
    },
    { 
      "familyName": "Miller", 
      "givenName": "Lisa", 
      "gender": "female", 
      "grade": 8 
    }
],
  "address": { "state": "NY", "county": "Manhattan", "city": "NY" },
  "isRegistered": false
};

如何查询给名字的宠物是"高飞"的孩子？

看起来以下语法无效

Select * from root r
WHERE r.children.pets.givenName="Goofy"

相反,我需要这样做

Select * from root …

我正在尝试查询具有某种类型产品的Art.这是我的艺术模型:

  public string Title { get; set; }
  public string Description { get; set; }
  public List<Product> Products { get; set; }
  public string PaintedLocation { get; set; }

从这里我所做的就是以下LINQ查询:

List<Art> items = DocumentDbHelper.Client.CreateDocumentQuery<Art>(collection.DocumentsLink)
                               .Where(i => i.type == "art")
                               .Where(i => i.Products.Any(p => p.Name == productType))
                               .AsEnumerable()
                               .ToList();

我收到以下错误:

"Method 'Any' is not supported."

我去了代码引用的页面,看看支持什么,但我没有看到它说不支持Any(),所以我可能做错了.任何帮助表示赞赏.

UPDATE

这对我来说真的很奇怪,所以我把它拆开来看看从两个结果中返回的是什么来更好地调试问题:

        List<Art> items = DocumentDbHelper.Client.CreateDocumentQuery<Art>(collection.DocumentsLink)
                               .Where(i => i.Id.Contains("art"))
                               .AsEnumerable()
                               .ToList();

        items = items.Where(i => i.Products.Any(p => p.Name == productType))
                     .AsEnumerable()
                     .ToList();

由于某些原因,这不起作用,因为我将它转换为列表,因此我正在运行查询两次 …

我正在为我的新项目选择数据库技术.我想知道Azure DocumentDB和Azure表存储之间的主要区别是什么？

似乎DocumentDB的主要优点是全文搜索和丰富的查询功能.如果我理解正确,我就不需要单独的搜索引擎库,如Lucene/Elasticsearch.

另一方面,Table Storage便宜得多.

可能影响我决定的其他差异是什么？

我根据@AzureSupport Twitter帐户的指示创建了这篇文章.

今天早上(2017年5月10日),当我管理我的Azure资源时,我再也找不到我的DocumentDB资源了.

但我注意到了这一点:

我想知道它是否只是一个错误,或者当前是否正在重命名DocumentDB.现在我真的不想触摸我的资源.

我找不到Microsoft的那个Cosmos DB的任何其他事件.其他人是否看到同样的事情？

编辑5月11日:好的,这是微软发布的Azure CosmosDB,显然DocumentDB正在成为新数据库系统的某种子集https://docs.microsoft.com/en-us/azure/cosmos-db/introduction

我在DocumentDB上有以下JSON商店.

{
  "id": "4",
  "total": 10.46,
  "tax": 0.55,
  "soldItems": [
    {
      "item": "CHEESE NIPS 004400001300 F 1.97 D",
      "price": 1.97
    },
    {
      "item": "ROOT BEER 10.46",
      "price": 10.46
    }
    ]
}

我从这个查询中得不到任何结果:

SELECT * from c where CONTAINS(c.soldItems.item, "BEER")

检查JSON对象值中的字符串的正确语法是什么？

在Microsoft Build 2017活动中,我遇到了CosmosDB Table API.看起来像Azure Table Storage.

这是否意味着微软最终会停止支持Azure表存储？

现在,文档Db已不复存在.它已被转换为CosmosDB现在.

此外,主要问题Table Storage是备份.哪个已经解决了CosmosDB Table API.

此外,Table API的定价策略是Throughput-basedTable Storage的定价策略Storage-based.

那么Table Storage对大批量应用程序来说仍然是一个不错的选择吗？