☰

postgreSQL 与 Cassandra 与 MongoDB 与 Voldemort 相比？

tag-icon • tag-icon database scalability database-performance sharding
postgreSQL 与 Cassandra 与 MongoDB 与 Voldemort 相比？

选择哪个数据库？有比较吗？

  • 现有：postgresql
  • 问题
    • 水平扩展不易。需要分片等
    • 聚类不能解决数据增长问题
  • 寻找：任何易于水平扩展的数据库
    • Cassandra（Twitter 使用这个吗？）
    • MongoDB（迅速流行起来）
    • 伏地魔
    • 其他？
  • 为什么？
    • 数据呈现滚雪球效应
    • 现有的 postgresql 定期锁定表等以执行清理任务
    • 目前归档数据非常困难
    • 定期与现有档案、真空等过程中的人机交互
    • 需要一种“设置它，忘记它。当数据增长更多时，只需添加另一台服务器”类型的解决方案

答案1

第一个问题：如果不需要 ACID 属性，为什么一开始要使用关系数据库？听起来您正在做某种非事务性工作，因此获取具有事务的 RDMBS 可能对您的环境来说太重了。

第二个问题：您要存储什么类型的数据？听起来您需要一个列存储数据库，而且它适用于某种数据仓库项目。

第三个问题：如果你坚持使用 PostgreSQL（它本身就是一个很好的数据库），它是当前版本吗？较旧的 8.x 之前的版本速度很慢，但是很多从那时起，我们已经进行了大量的工作来进行改进，您提到的一些问题（例如自动清理）现在可以通过“设置并忘记”设置轻松解决。

*  Data growing with snowball effect

最好能提供一些关于此问题的其他信息。为什么它会滚雪球？您可以将其标准化以减少存储吗？

* existing postgresql locks table etc for vaccuum tasks periodically

如果这是个问题，我就能判断出你运行的是旧版本。新版本有针对此问题的每张表控制，你甚至可以完全关闭它。

* Archiving data is tideous currently

这里很难做出任何判断，因为没有太多可利用的东西。档案被转储到什么介质上？涉及多少持续 I/O？您在什么时间范围内操作？有多少数据？它需要是“热”转储还是可以是“冷”转储？

* Human interaction involved in existing archive, vaccuum, ... process periodically

我试图了解“正常”使用情况如何需要手动干预，因为它不应该。真空现在是自动的，并且（如前所述）可以设置为根本不发生，并且大多数备份都是脚本化的（当您可以编写脚本时，您可以安排时间）。那么这是怎么发生的呢？

* Need a 'set it. forget it. just add another server when data grows more.' type of solution

您正在谈论集群服务器安排。

在我看来，这听起来如下：

  1. 您使用的是 RDBMS，并且它的事务特性不适合您的应用程序。
  2. 您的应用程序似乎需要一种主要以读取为主的数据库。听起来您也不需要它具有事务完整性。
  3. 您处理的数据量很可能尚未规范化，也没有尝试对其进行规范化。
  4. 您手动做了太多工作，需要更多自动化。
  5. 您喜欢集群解决方案的想法，可能是“云风格”计算。

除此之外，这里没有足够的信息来确定什么是最佳匹配。

答案2

您可能还会考虑研究 HBase 和 HyperTable；但是，正如 Avery Payne 提到的，您没有向我们提供有关当前应用程序的任何信息，只提供了数据库平台。

需要注意以下几点：

在非 SQL 平台上，连接是手动完成的。它们不会执行外键、聚合等操作。所有这些都是手动的。

现有应用程序不一定易于移植。根据移植成本，垂直扩展 PostgreSQL 服务器（而不是水平扩展）可能更具成本效益。

您无法获得 ACID，并且必须手动管理并发性。根据您的应用程序，这可能是一个问题。您也无法以传统方式执行全局保护规则，这同样是由于缺乏原子性。

答案3

当您需要扩展时，Cassandra 是最好的选择。

我推荐一些案例研究文章http://wiki.apache.org/cassandra/ArticlesAndPresentations

答案4

您可以采取以下措施来解决一些问题：

  • 现有的 postgresql 定期锁定表等以执行清理任务

表没有被锁定，只是执行速度慢。postgresql 这样做是为了防止事务 ID 回绕。您可以通过批量写入多行然后提交来降低频率。您可以使用队列（如 rabbitmq）进行中间写入：application->queue->db。这也会大大提高您的写入性能。

  • 目前归档数据非常困难

如果您的数据太大（几 TB 的数量级），我建议您迁移到云中，因为无法转储。使用 AWS 或 Google Cloud，并使用快照。例如，EBS 快照非常快，可在各大洲复制，解决了备份需求。

如果您所说的归档是指删除数据并移至“存档”，则请使用按日期轮换的表空间。网上有一些实现。

相关内容