标签: amazon-dynamodb

我对Amazon SimpleDB有一些基本的了解,但根据Amazon DynamoDB描述,它似乎几乎相同:NoSQL Key-value存储服务.

有人可以简单地解释它们之间的主要区别,并告诉在哪些情况下选择一个而不是另一个.

我无法理解Range主键在这里 -

http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.html#WorkingWithTables.primary.key

它是如何工作的？

"散列属性上的无序散列索引和范围属性上的排序范围索引"是什么意思？

我正在试图找出我可以用于未来项目的东西,我们计划在第一年每月存储大约50万条记录,并且可能在接下来的几年中存储更多这是一个垂直应用程序,所以没有必要使用这个数据库,这就是我决定选择noSQL数据存储的原因.

我想到的第一个选择是mongo db,因为它是一个非常成熟的产品,得到了社区的大力支持,但另一方面我们得到了一个全新的产品,提供最佳性能的托管服务,我将开发这个应用但没有维护计划(至少现在),所以我认为这将是一个巨大的优势,因为亚马逊提供了一种弹性的扩展方式.

我主要担心的是查询结构,我还没有看过dynamoDB查询功能,但由于是ak/v数据存储,我觉得这可能比mongo db更受限制.

如果有人有将项目从mongoDB迁移到DynamoDB的经验,那么任何建议都将完全受到赞赏.

我很好奇这两个二级索引和它们之间的差异.很难想象这是怎么回事.而且我认为,这将有助于更多的人而不仅仅是我.

我现在一直在使用MySQL,我很熟悉它的结构和SQL查询等.

目前正在AWS中构建一个新系统,我一直在关注DynamoDB.目前我只知道一点.

一个比另一个好吗？

DynamoDB有什么优势？

什么是从MySQL查询等到这个平面样式DB的过渡？

我正在DynamoDB中编写一个简单的日志记录服务.

我有一个日志表,由user_id哈希和时间戳(Unix epoch int)范围键入.

当服务的用户终止其帐户时,我需要删除表中的所有项目,而不管范围值如何.

这种操作的推荐方法是什么(请记住可能有数百万项要删除)？

据我所知,我的选择是:

答:执行扫描操作,在每个返回的项目上调用删除,直到没有剩余项目

B:执行BatchGet操作,再次对每个项目调用delete,直到没有剩下

这些对我来说都很糟糕,因为它们需要很长时间.

我理想的做法是调用LogTable.DeleteItem(user_id) - 不提供范围,并让它为我删除所有内容.

我来自关系数据库背景,并尝试使用亚马逊的DynamoDB

我有一个表,其中包含一个哈希键"DataID"和一个范围"CreatedAt"以及一系列项目.

我正在尝试获取在特定日期之后创建的所有项目并按日期排序.这在关系数据库中非常简单.

在DynamoDB中,我能找到的最接近的是查询并使用大于filter的范围键.唯一的问题是,为了执行查询,我需要一个破坏目的的哈希键.

那么我做错了什么？我的表架构是错误的,哈希键不应该是唯一的吗？还是有另一种查询方式？

我正在尝试使用DynamoDB javascript shell创建一个简单的表,我得到了这个异常:

    {   
    "message": "The number of attributes in key schema must match the number of attributes defined in attribute definitions.",
    "code": "ValidationException",
    "time": "2015-06-16T10:24:23.319Z",
    "statusCode": 400,
    "retryable": false 
    }

下面是我要创建的表:

    var params = {
        TableName: 'table_name',
        KeySchema: [ 
            { 
                AttributeName: 'hash_key_attribute_name',
                KeyType: 'HASH',
            },

        ],
        AttributeDefinitions: [ 
            {
                AttributeName: 'hash_key_attribute_name',
                AttributeType: 'S', 
            },
            {
                AttributeName: 'attribute_name_1',
                AttributeType: 'S', 
            }
        ],
        ProvisionedThroughput: { 
            ReadCapacityUnits: 1, 
            WriteCapacityUnits: 1, 
        },


    };
    dynamodb.createTable(params, function(err, data) {
        if (err) print(err); 
        else print(data); 
    }); …

这是我的Troposphere生成的JSON的(DynamoDB部分):

"sandbox": {
        "Properties": {
            "AttributeDefinitions": [
                {
                    "AttributeName": "audit_id",
                    "AttributeType": "S"
                },
                {
                    "AttributeName": "status",
                    "AttributeType": "S"
                },
                {
                    "AttributeName": "filename",
                    "AttributeType": "S"
                },
                {
                    "AttributeName": "file_detected_dt",
                    "AttributeType": "S"
                },
                {
                    "AttributeName": "time_taken",
                    "AttributeType": "N"
                },
                {
                    "AttributeName": "number_rows_processed_file",
                    "AttributeType": "N"
                },
                {
                    "AttributeName": "number_rows_created_db",
                    "AttributeType": "N"
                },
                {
                    "AttributeName": "info_messages",
                    "AttributeType": "S"
                }
            ],
            "KeySchema": [
                {
                    "AttributeName": "audit_id",
                    "KeyType": "HASH"
                }
            ],
            "ProvisionedThroughput": {
                "ReadCapacityUnits": {
                    "Ref": "ReadCapacityUnits"
                },
                "WriteCapacityUnits": {
                    "Ref": "WriteCapacityUnits"
                }
            }
        },
        "Type": …

Merkle Trees在几个分布式复制键/值存储中用作反熵机制:

• 发电机
• 了Riak
• 卡桑德拉

毫无疑问,反熵机制是一件好事 - 在生产过程中,瞬间失败就会发生.我只是不确定我理解为什么Merkle Trees是最流行的方法.

• 将完整的Merkle树发送给对等体涉及将本地密钥空间与每个键值的散列一起发送到该对等体,存储在树的最低级别中.

• 区分从同伴发送的Merkle树需要拥有自己的Merkle树.

由于两个对等体必须已经有一个已排序的键/值 - 哈希空间,为什么不进行线性合并以检测差异？

我只是不相信树结构在考虑维护成本时会提供任何节约,而且已经完成线性遍历树叶的事实只是为了在线上序列化表示.

为了解决这个问题,一个稻草人替代方案可能是让节点交换散列摘要数组,这些散列摘要通过模数环位置逐步更新和删除.

我错过了什么？