问题标签 [non-relational-database]

当用于大规模数据集（google、facebook、linkedin）时，非关系型数据库（例如键值对存储）的好处是显而易见的。您认为中小型应用程序如何从使用非关系数据库中受益？

我将很快开始设计一个 Web 应用程序，虽然我在 SQL 领域有很多经验，但我不知道这样做需要考虑什么，以便在不久的将来迁移到 GAE未来。

或者，我可以从一开始就为 GAE 设计应用程序，那么在这种情况下，我需要考虑哪些差异？换句话说，为 GAE 编写应用程序的 DOs 和 DONTs 是什么，来自过去的关系数据库。

我目前正在使用 MS SQL Server 2008，但我不确定它是否是完成这项特定任务的最佳系统。

我有一个像这样的表：

一个常见的查询是

该表大约有 10 亿行，每天插入 500 万行。

我对 SQL Server 的主要问题是分片或分散数据文件不太容易。此外，导出似乎以每秒 1000 行（约 1MB/秒）的速度最大，这似乎非常慢。

我遇到的另一个问题是，对于 SQL Server，如果我想添加一个新的 LookupCol，日志文件会大幅增长，需要大量很少使用的可用空间。

这个问题有什么明显更好的解决方案吗？

作为一个个人项目，我希望构建一个基本的 DBMS。我已经阅读了 Elmasri 和 Navathe (5ed) 中的相关部分，但可以使用更集中的文本——更实用、更注重细节的内容，并提供真实世界的建议——因为 E&N 的深度如此之深。

问题是我想使用新颖的非关系数据模型。虽然很多 E&N 都很棒——特别是索引实现细节——但更高级的 DBMS 实现只针对关系模型。

如果可以的话，我想推迟一段时间盯着 DBMS 源，直到我有了更好的基础。有任何想法吗？

我正在启动一个将可扩展性视为首要任务之一的 Web 应用程序。这样做有什么好处：cassandra scala lift

与传统的云端 LAMP 对比？由于从我读过的内容来看，请纠正我，云本身是可扩展的

我以前从未见过有人在云上部署 scala。努力学习这个平台值得吗？准备好用于生产了吗？

我正在尝试了解 OLAP 和数据仓库，但我对关系建模和维度建模之间的区别感到困惑。维度建模基本上是关系建模，但允许冗余/非规范化数据吗？

例如，假设我有（产品、城市、# 销售额）的历史销售数据。我理解以下将是一个关系的观点：

虽然以下是更立体的观点：

但似乎这两种观点都将在相同的星型模式中实现：

直到您开始向每个维度添加一些额外的细节，差异才会开始显现。例如，如果您还想跟踪区域，关系数据库往往会有一个单独的区域表，以保持一切正常化：

而维度数据库将允许非规范化以将区域数据保留在城市维度内，以便更轻松地对数据进行切片：

它是否正确？

我目前正在使用mysql。我发现我的架构变得异常复杂。我寻求找到一个适合我需要的新数据库：

假设我正在构建一个新闻聚合器（它从多个网站收集新闻）。然后我运行算法来确定来自不同站点的两条新闻是否实际上指的是同一个主题。我运行这个算法将新闻聚集在一起。关系如下图所示：

然后我会应用一些魔法并确定每个单词的重要性。总结每个单词的所有重要性给了我一篇新闻文章的重要性。总结每篇新闻文章的重要性给了我一个集群的重要性。

请注意，上面的集群还有子组（如按地区划分等）和类别（如体育等），我必须确定其在特定日期本身的重要性。

我过去曾使用视图来执行此操作，但我意识到视图非常缓慢。所以我通常会在实际表中插入并索引它们以获得更好的性能。如您所见，这会导致派生多个表，例如（集群，重要性），（新闻，重要性），（单词，重要性）等，这些表可能会变得非常混乱。

“重要性”指标也会发生变化。更改表、更新数据（我正在使用 TRUNCATE TABLE）然后从 null 插入变得越来越困难。

我目前正在研究像 Mongodb 这样的无模式的东西。我不需要分布式。我非常想要一些相当快的东西（可以被索引）和比传统 RDMBS 更灵活的东西。

新的

应各种人的要求，我将我的使用情况发布到这个数据库（它们不是实际的SQL查询，因为我希望这里的每个人都能理解）

您可能会注意到 TABLE_word 有一个额外的 news_id 列。这是为了对应 TABLE_word_importance 列，因为同一个词在不同的文章中可能有不同的重要性（如果你熟悉 tfidf，基本上是这样的）。

所有“重要性”表现在通过平均其下方所有子实体的重要性来计算每个实体的重要性。这意味着每个集群的重要性取决于其中的所有新闻，每个新闻的重要性取决于其中的所有单词等。

正如你所看到的，我从每一层得到了很多分数，有人告诉我为此目的使用物化视图（postgresql 支持它）。但是，如您所见，这个简单的模式已经包含 8 个表（我的实际数据库包含 26 个类似的废话表，这增加了太多额外的维护层复杂性）。

注意这不是关于全文搜索。

有很多关于反革命 NoSQL 数据库的讨论，例如Cassandra、CouchDB、Hypertable、MongoDB、Project Voldemort、BigTable等等。就我而言，最强大的优点是可扩展性、性能和简单性。

我正在认真考虑建议为我们的下一个项目使用一些非关系数据库。但是，一些团队包含一些 RDBMS 狂热分子，因此在某些情况下，仅仅因为情绪原因，说服硬切换可能是不可能的。此外，当涉及到复杂的数据模型时，我个人仍然相信 RDBMS 及其低级一致性执行机制的强大功能。

现在我的问题来了：我想知道，如果有人可以认真考虑在一个新项目中同时使用 RDBMS和非关系数据库：复杂但不是性能关键的数据模型仍将使用关系模型和数据库来实现，而所有性能关键但简单的模型都将使用非关系数据库来实现。此外，这种软范式转变比硬性转变更容易卖给一些高度情绪化的团队成员。

有人会推荐这种方法吗？或者您更愿意推荐黑色或白色，即关系或非关系方法？非常欢迎所有评论！

PS：知道这样的混淆是否适用于 Spring 和 Hibernate/JPA？

在 EF Codd 于 1970 年发表他的论文“大型共享数据库的数据关系模型”之前，层次结构和网络是数据库的两个突出模型。

他们到底有什么问题没有获胜？

我正在构建一个应用程序，该应用程序需要查询大量写入一次且不再更改的数据。我应该使用 MySQL 还是应该使用 SimpleDB 或 BigTable 之类的东西？（我需要写一次，读很多次）

谢谢你。

编辑：我想使用 Heroku，对我来说大超过 5MB。“千行”占用超过 5MB。这就是为什么我想知道是否应该使用 CouchDB、SimpleDB 或 MongoDB，以免支付 Heroku 收取的 15 美元。克服这个问题的建议？谢谢大家的评论！