【问题标题】:how to manage millions/billions of small values in a "database"如何在“数据库”中管理数百万/数十亿的小值
【发布时间】:2011-03-23 10:22:19
【问题描述】:

我有一个会生成数百万个日期/类型/值条目的应用程序。我们不需要做复杂的查询,例如获取日期A和B之间的X类型每天的平均值。

我确信像 mysql 这样的普通数据库不是处理这类事情的最佳选择,是否有更好的系统来处理这类数据。

编辑:目标是不是说关系数据库无法处理我的问题,而是要知道是否有另一种类型的数据库,如键/值数据库、nosql、面向文档, ... 可以更适应我想做的事情。

【问题讨论】:

  • 为什么你认为“普通”数据库无法处理这个问题?
  • 早期优化是万恶之源。
  • 这听起来很简单,可以测试,你可能会在一两个小时内敲出一个程序来生成测试数据/测试查询。为什么不吸一下看看呢?
  • 几(亿?)百万和几(千?)十亿之间有很大的区别,但我们有几个约 5 亿行的基于时间的事件的 MySQL 表,这不是问题.这主要取决于您的应用程序的要求(数据粒度、您查询的数据集有多大、您如何更新/删除内容、您需要多长的查询响应时间等)
  • 一切都取决于你对最佳的定义。

标签: database database-design data-structures


【解决方案1】:

如果您正在处理这样的简单表格:

CREATE TABLE myTable (
    [DATE] datetime,
    [TYPE] varchar(255),
    [VALUE] varchar(255)
)

可能在TYPE,DATE,VALUE 上创建索引 - 按此顺序 - 将为您描述的查询提供良好的性能。使用解释计划或您正在使用的数据库上的任何等效项来查看性能指标。并且,设置一个计划任务来定期对该索引进行碎片整理 - 频率将取决于插入、删除和更新的频率。

就替代持久性存储(即 NoSQL)而言,您什么也得不到。当您需要无模式存储时,NoSQL 会大放异彩。换句话说,您不知道实体定义的时间。但是根据您的描述,您可以非常清楚地了解要存储的内容,这很适合关系数据库。

现在随着时间的推移进行扩展的可能性包括分区和每个TYPE 记录到一个单独的表中。分区片可以按类型和/或日期来完成。真的取决于您正在处理的查询的性质,例如,如果您通常查询同一年内的值,以及您的数据库在这方面提供什么。

【讨论】:

    【解决方案2】:

    MS SQL Server 和 Oracle 提供Partitioned Tables and Indexes 的概念。

    简而言之:您可以按某个值(即按年和月)对行进行分组。每个组都可以作为具有自己索引的单独表进行访问。因此,您无需访问所有行即可列出、汇总和编辑 2011 年 2 月的销售额。分区表使数据库复杂化,但如果表非常长,它可能会显着提高性能。

    【讨论】:

      【解决方案3】:

      根据您可以选择 MySQL 或 SQL Server 的成本,在这种情况下,您必须清楚您想用数据库实现什么目标,仅用于存储,然后任何 RDBMS 都可以处理。

      【讨论】:

        【解决方案4】:

        您可以将数据作为固定长度的记录存储在文件中。 对打开的文件进行二进制搜索以进行随机访问以找到您的开始和结束记录,然后将您的开始索引和结束索引之间的所有记录的给定条件相加到文件中。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2012-03-29
          • 2021-12-14
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2020-12-06
          相关资源
          最近更新 更多