我没有No-SQL数据库的经验,因为我主要研究SQL数据库。但我认为现在我的设计可能会对我试图完成的事情有所帮助。我想监控某些产品的价格并将其保存在数据库中。一开始,产品数量将受到限制(500),我将每天监测一次价格(每年最多365次)。
最初的想法是让表格price_history
包含id|date|price
这样的列 - 所以一年内我会有365天* 500个产品行数。
使用No-SQL数据库会有什么好处,在哪里(如果我已经正确阅读)我可以使用文档格式(例如JSON样式),哪个会更快地查询单个产品的历史记录?
对于这个数据量,也许SQL没问题但是如果:
那么,在我的范例中阅读有关No-SQL dbs的努力是否值得?
答案 0 :(得分:2)
绝对值得阅读更多有关NoSQL的信息,看它是否适合您的工作量。更多信息是一件好事。
但是,到目前为止,您所描述的问题并未将NoSQL视为解决方案。
您已使用mysql标记了您的问题,因此我认为这是您正在考虑的SQL数据库。绝对可以将列添加到MySQL表中,即使在填充后也是如此。表中的数据越多,所需的时间就越长。但这是可能的。
如果您需要在以这种方式进行重组时继续查询表格,pt-online-schema-change之类的工具可以提供帮助。
听起来像一年的数据对你来说就是365 * 500或182,500行。坦率地说,这是一个非常适度的数据量。 MySQL数据库管理员经常处理更大的数据库。
我目前管理的其中一个数据库中的一个表大约有45亿行,而且它每天增长200万到1000万行。我使用索引和分区的组合来确保查询尽可能地执行。我管理的其他表每个都有超过1亿行数据。
没有数据库,SQL或NoSQL,可以让您无限期地保持增长。任何数据可伸缩性策略都必须包含一些用于归档或汇总旧数据的策略。
我给出的另一条建议是,在SQL和NoSQL之间进行选择或多或少与在规范化SQL和非规范化SQL之间进行选择相同。也就是说,您可以根据DBMS优化对数据运行的查询类型而不是需要存储的数据结构或数量来选择DBMS。
我猜你的数据基本上会被用作数据仓库,而你的查询将会进行汇总计算或计算趋势等等。为此,您可以考虑使用专门的列存储数据库。这仍然是一个SQL数据库,但它以优化OLAP查询的方式存储数据。
面向列的数据库的示例包括: