关系数据库对于大型电子商务平台是否可行？

Question

我被分配到一个拥有大量数据（数十万种产品、卖家等）的电子商务平台，我一直在尝试选择执行此操作所需的适当工具和方法。

虽然有许多电子商务平台使用关系数据库（WooCommerce、Magento、Presta 等），但我并不完全相信使用关系数据库开发这样的东西是有效的。由于产品构成了数据集的主要部分，并且每个产品都有自己特定的蓝图，除非您为每个产品添加大量元数据、存储重复数据等，否则无法将其映射到单个蓝图。有人可能建议使用 JSON，但我不确定这在查询时是否得到了优化。

所以我想知道，使用两种不同的数据库类型开发这样的项目是个好主意吗？用于目录的非关系型数据库和用于用户数据等数据的关系型数据库？

我不是 NoSQL 方面的专家，我担心它的性能，特别是在搜索和查询商店时。

最大化效率和性能的好方法是什么？我的双手可以自由选择所需的任何技术和堆栈。

Answer 1

这里确实存在三个不同的问题。

问：几十万行的表很大吗？

一般来说，不会。例如，您可以下载Stack Overflow公共数据导出，它有超过一亿行的表。

超大型数据库 (VLDB) 的定义随着时间的推移而发生变化，但您经常会听到人们抱怨每个表超过 10 亿行或单个数据库中超过 1 TB 的数据时出现性能和维护问题。当然，这并不是说您不会更早地听到人们抱怨。

问：使用两种不同的数据库类型开发这样的项目是个好主意吗？

当您刚刚开始时，我建议您关注单个数据库。构建一个具有一个您不太了解的持久层的应用程序已经够困难的了，更不用说两个了。

当您遇到成长的烦恼并且正在考虑额外的持久层时，请从像 Redis 这样的缓存层开始。在那里保存经常访问、很少更改的数据 - 在您的情况下，产品表就是一个很好的例子。产品可能不会每 5-10 分钟更改一次以上，但同时，它们会不断被查询以呈现网页。缓存产品是减少数据库工作负载的快速方法，而无需成为多个数据库平台的专家。

问：开发新应用程序时应该选择哪个数据库？

你最了解的人。

所有关系数据库在处理数十万行范围内的表时都可能表现良好或较差。这更多地取决于如何编写查询，而不是数据库本身的内部结构。