我正在处理一个收集历史定价数据的大型数据库。架构相对简单，不会改变。
类似的东西：
SKU（字符），类型（枚举），价格（双倍），日期时间（日期时间）
问题是这个表现在有超过500,000,000行，大约20gb并且还在增长。运行查询已经有点困难了。一个常见的查询是从特定日期范围获取所有skus，其中包含可能500,000条记录。添加任何复杂性，例如group by，你可以忘记它。
这个数据库主要是写。但我们显然需要处理数据并偶尔运行查询。我知道更好的索引规划可以帮助加快查询速度，但我想知道这是否会受益于像MongoDB这样的noSQL解决方案？我可以期待mysql（可能转向MariaDB）继续为我们工作，即使它的大小超过100-200 GB？或者我应该在事情变得无法解决之前探索替代方案吗？
答案 0 :(得分：4)
NoSQL不是大型数据库的解决方案＆＃34;问题; NoSQL - 特别是文档数据库 - 专为您存储的数据的性质各不相同的场景而设计，因此您不希望事先定义严格的架构和关系。
您拥有的是简单明确的数据。这非常适合关系数据库，但对于那种规模的东西，我建议你看一些商业的东西（即SQL Server或Oracle，具体取决于你的平台）。我在SQL Server中使用的数据库大小约为4 TB，在数百万条记录中有几个表。关系数据库可以轻松容纳您已概述的简单数据。
答案 1 :(得分：3)
你实际上有一个理想的SQL用例，而且非常适合NoSQL。 MySQL开发人员报告人们使用5,000,000,000条记录的数据库。其他一些SQL服务器的可扩展性甚至更高。但是，如果您没有适当的索引支持，则应该无法管理其中的一小部分。
BTW，您的表架构是什么，包括索引？
答案 2 :(得分：0)
您可以切换到mariadb，然后使用蜘蛛引擎。蜘蛛引擎可以跨多个mariadb实例拆分数据，而不会失去对现有实例运行查询的能力。
因此，您可以定义自己的分区规则，然后为每个分区创建一个实例。所以最后你有多个mariadb实例，但你的所有记录都是用蜘蛛引擎在一个表中虚拟起来的。
您的性能提升是因为您在多个实例之间拆分数据，因此减少了每个表或实例的记录数量，当然还有更多的硬件资源。