该DynamoDB维基百科的文章说，DynamoDB是一个“键-值”的数据库。然而，将其称为“键值”数据库完全忽略了 DynamoDB 的一个极其基本的特性，即排序键：键有两部分（分区键和排序键），并且可以有效地检索到具有相同分区键的项目一起排序通过排序键。
Cassandra 还具有完全相同的 sort-items-inside-a-partition 功能（它称为“集群键”），并且Cassandra 维基百科文章使用术语宽列存储来描述它。然而，虽然这个术语“宽列”比“键值”要好，但它仍然有些不合适，因为它描述了更一般的情况，即一个项目可以有大量不相关的列——不一定是单独的排序列表项目。
所以我的问题是是否有一个更合适的术语可以描述像 DynamoDB 和 Cassandra 这样的数据库的数据模型——像键值存储这样的数据库可以有效地检索单个键的项目，但也可以有效地检索按键或只是其中的一部分（DynamoDB 的排序键或 Cassandra 的集群键）。
一般来说，如果我想确定当多个线程对 DynamoDB 中的同一项目进行并发更新时会发生什么，我应该使用条件更新（即“乐观锁定”）。我知道。但是我想知道是否还有其他情况可以确保对同一项目的并发更新仍然存在。
例如，在 Cassandra 中，对同一项目的不同属性进行并发更新是可以的，并且两个更新最终都可以读取。在 DynamoDB 中也是如此吗？或者是否有可能只有其中一个更新幸存下来？
一个非常相似的问题是，如果我同时将两个不同的值添加到同一项目的集合或列表中会发生什么。我是否保证在我阅读此集合或列表时最终会看到这两个值，或者在某种 DynamoDB“冲突解决”协议期间，其中一个添加项是否可能掩盖另一个？
我看到我的第二个问题的一个版本过去已经在这里问过了DynamoDB 是“设置”值 CDRT 吗？，但答案参考了一个不太清楚的常见问题解答条目，该条目不再存在。作为我的问题的答案，我最希望看到的是 DynamoDB 官方文档，该文档说明了 DynamoDB 在不涉及“条件更新”和“事务”时如何处理并发更新，尤其是上述两个示例中发生的情况。如果没有这样的官方文档，有没有人对这种并发更新有任何实际经验？
传统的 Unix shell 实用程序dirname查找包含给定文件的目录的名称。如果您想在同一目录中查找其他姐妹文件，这非常有用。这里有一些例子：
$ dirname /some/dir/filename
/some/dir
$ dirname dirname/filename
dirname
$ dirname filename
.
新的 C++ std::filesystem 的parent_path()最后一个错误（或者看起来是这样）：
$ dirname /some/dir/filename
/some/dir
$ dirname dirname/filename
dirname
$ dirname filename
.
输出：
parent of filename: ""
返回空字符串而不是“.” 不仅与传统的不同dirname，当在想要在此父级上添加“/...”以创建姐妹文件的名称的代码中使用时也是错误的 - 这会导致错误的“/sister”而不是预期为“./妹妹”。
这是 std::filesystem 中的错误还是故意行为？这种行为的原因是否记录在某处？
DynamoDB的定价页面包含以下文本，解释存储连续备份（又名 PITR - 时间点恢复）的成本：
DynamoDB 根据启用 PITR 的每个 DynamoDB 表（表数据和本地二级索引）的大小收取 PITR 费用。DynamoDB 会在整个月内持续监控启用了 PITR 的表的大小，以确定您的备份费用，并继续向您收取费用，直到您在每个表上禁用 PITR。
这似乎表明，用户根据启用的表的大小（而不是存储的备份的大小）为连续备份付费。这意味着，如果用户不断修改现有数据而不是添加新数据，亚马逊可能需要大量存储空间来存储 35 天的修改量，而用户无需为此付费。这对我来说没有意义 - 我怀疑他们的定价需要与备份的大小相对应，而不是表的大小 - 但这在上面的文本或我在亚马逊网站上找到的任何类似变体中都没有声明。
所以我的问题是 - 亚马逊如何对连续备份存储收费？按表大小，还是按备份大小（即更改量）？这有记录在任何地方吗？
奇怪的是，我在网络上找不到讨论这个问题的任何其他来源。我发现上述文本的许多稍作修改的版本被复制到各种教程中，但它们都没有给出任何回答我的问题的示例。就好像没有人真正关心这个功能在开始使用之前要花多少钱:-)
我以一种方式模拟了我的Cassandra,我有几个具有相同分区键的表--Uuid.
每个表都有它的分区键,其他列表示我想要询问的特定查询的数据.
例如 - 1个表有Uuid和列关于它的状态(此表中没有其他聚类键),表2将包含相同的Uuid(也没有聚类键)但是具有表示此Uuid数据的不同列.
这是正确的建模吗？在表格周围复制相同的分区键是否错误,以便将每个表分组以保存特定用例的相关列？或者它更喜欢只使用1个表并查询它们并在代码中获取特定用例的相关数据？
前天,我使用下面的命令在5节点Cassandra集群中的一个节点上为单个表发出了完整的顺序修复.
nodetool repair -full -seq -tr <keyspace> <table> > <logfile>
现在,发出命令的节点已正确修复,可以从下面的命令中获取
nodetool cfstats -H <keyspace.columnFamily>
然而,对于其他节点,不能说同样的,因为我得到了修复%的随机值,显着更小.
我不确定这里发生了什么,看起来像是为密钥空间修复的唯一节点,列系列是发出修复命令的节点.对此处可能发生的事情或如何正确调查问题的猜测
谢谢 !
我目前正在尝试深入研究Cassandra的数据模型及其与Bigtable的关系,但结果却出现了关于Column Family概念的强烈头痛.
主要是我的问题已被问及已经回答.但是,我对答案不满意:)
首先,我阅读了Bigtable论文,尤其是关于其数据模型,即数据的存储方式.据我所知,Bigtable中的每个表基本上依赖于维度行,列和时间的多维稀疏映射.地图按行排序.列可以使用名称约定系列进行分组:限定符到列族.因此,单行可以包含多个列族(请参阅本文中的示例图).
虽然有人说Cassandra依赖于Bigtable数据模型,但我多次读到,在Cassandra中,列族包含多行,并且在某种程度上与关系数据存储中的表相当.这与Bigtable的方法相反,其中一行可以包含多个列族？什么是第一,列系列或行:)？这些概念是否具有可比性？
我有一个Cassandra集群(2个DC),每个节点有6个节点,RF节点(每个DC中)有4个节点已满,所以我需要很快清理空间.
我试图进行全面修复,但结果是一个坏主意,因为空间开始增加甚至更多,修复最终被绞死.作为最后的解决方案,我正在考虑开始修复,然后清理从最小到最大的特定列.
即
nodetool repair -full foo_keyspace bar_columnfamily
nodetool cleanup foo_keyspace bar_columnfamily
您认为此程序对数据是否安全？
谢谢
我有一个表存储用户拥有的列表产品.该表看起来像这样.
create table my_keyspace.userproducts{
userid,
username,
productid,
productname,
producttype,
Primary Key(userid)
}
所有用户都属于一个组,组中最多可以有1到100个用户
userid|groupid|groupname|
1 |g1 | grp1
2 |g2 | grp2
3 |g3 | grp3
我们有新要求在一个组中显示所有用户的所有产品.
所以我更改了我的用户产品,以便我的分区键现在是groupid并将userid作为我的群集密钥,这样我就可以在一个查询中获得所有结果.
或者我保持我的表设计原样并通过从第二个表中选择组中的所有用户来激发多个选择查询,然后为每个用户触发一个选择查询,在我的代码中合并数据然后将其返回给用户
谢谢.