【问题标题】:No SQL data store or RDBMS data store for these requirements?没有满足这些要求的 SQL 数据存储或 RDBMS 数据存储?
【发布时间】:2015-08-06 18:26:40
【问题描述】:

我的数据集需要为特定记录集动态添加更多字段,而其他记录不需要这些字段。

HBase/No Sql 系统为我提供了使用动态模式的灵活性。但我也需要以标准化方式存储数据以节省更多磁盘空间。大多数情况下,我对数据存储的操作将是并行写入和基于唯一键的读取。我还需要每天转储整个数据集。写入本质上不是事务性的,数据存储应该能够支持聚合以进行分析。

记录数在 100 万到 1000 万之间,总大小从 500 MB 到 10GB。我们还希望通过使用 SQL 作为查询语言来开放数据以便于查询。

根据这些要求,我发现其中一部分满足无基于 SQL 的系统,而另一些满足基于 SQL 的系统。

有了这些要求,我担心的是,

1.动态架构: 没有基于 SQL 的系统很好地支持动态模式。这并不意味着它不能被基于 SQL 的系统支持。仍然可以将动态数据规范化到另一个表中,并使用唯一标识符从父表中引用该数据,从而减少父表中 Null 条目的数量。

2。基于 SQL 的查询语言: RDBMS 就是为此而生的。但是仍然没有像 hbase 这样的 SQL 系统有 Hive、Phoenix 来解决这个问题。在这种情况下有没有明显的赢家?

3.分析支持: 没有 SQL 系统非常适合基于 OLAP 的操作。 RDBMS 系统非常适合基于 OLTP 的操作。这里的要求是执行更多的 OLAP 操作。 RDBMS 系统中缺少哪些执行 OLAP 操作效率不高?

4.数据大小 如前所述,数据量相对较小,可以装入单台机器。这是基于 RDBMS 的系统,例如 My sql,因为与 No SQL 对应的系统相比易于设置,因此它是赢家?在这种情况下,除了易于设置之外,还有其他原因偏爱 RDBMS 吗?

5.支持存储二进制数据 除了上述这些要求,我们还想在数据存储中存储字节对象。基于 RDBMS 的系统提供 blob 来支持这一点。但是我一次又一次地读到,Blob 对于数据的频繁更改效率不高,清理 Blob 的开销更多,等等。所以在这种情况下,没有像 hbase 这样的基于 SQL 的系统如何处理它比他们的更好SQL 对应?

6.每天一次转储整个数据集 在基于 RDBMS 的系统和基于无 SQL 的系统中,我们都在努力节省更多空间,并且我们不关心转储操作需要额外的几分钟来进行非规范化。在这种情况下,赢家会是什么?

基于当前用例的这些主要因素,我发现在基于 RDBMS 的系统与不基于 SQL 的系统之间选择一个明确的赢家有点困难。你对这些请输入..

谢谢, 斯里拉姆

【问题讨论】:

    标签: rdbms datastore nosql


    【解决方案1】:

    这不是问题。这是一组问题。要回答所有这些问题,我需要写一本书,而我并不打算这样做。因此,我将总结一下我的想法。假设您正在使用 RDBMS,并且您有一个表 foo 可能有一些自定义字段。在不将这些列添加到 foo 的情况下支持它们的 RDBMS 解决方案是创建一个表 foo_custom_fields(id, name) 来保存所有可能的自定义字段并具有 foo_custom_field_values(id, foo_custom_field_id, foo_id, value)。因此,您可以使用 RDBMS 实现与 NoSQL 大致相同的效果。 NoSQL 非常灵活,这是它的优势。这两种情况各有利弊,但我认为:

    如果你需要写 SQL,那么不要使用 NoSQL。

    【讨论】:

    • 我真的很喜欢这个底线...我会再试一个:如果您的数据适合单个 RAM 芯片,不要太担心预先节省空间
    • 感谢 Lajos 提供您的想法。我仍在寻找在两者之间进行选择的实际区别,因为大多数情况下两者都可以解决。如果您有任何特定于这些的链接或要点,请分享。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-09-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-02-28
    • 2019-09-27
    • 1970-01-01
    相关资源
    最近更新 更多