在 mySQL 中扩展餐厅数据库 [关闭]答案

【问题标题】：Scaling a Restaurant Database in mySQL [closed]在 mySQL 中扩展餐厅数据库 [关闭]
【发布时间】：2018-08-23 19:32:51
【问题描述】：

我正在为一个应用程序设计一个后端，该应用程序将跟踪几家不同的餐厅及其订单历史记录。所以我一直在考虑最有效的方法来做到这一点。我想我想做的就是为任何一家餐厅提供一个通用设计，并在我们添加不同的餐厅时创建一个新的数据库。（如果这样做有什么问题，请告诉我）

我要弄清楚的是，我将如何存储餐厅许多订单的特定订单数据。我在想有一张大表来跟踪所有订单，并为每个订单创建一个单独的迷你表，详细说明订购的内容、价格以及是否应用了任何折扣/优惠券。

我想象一家餐厅在一个月内可以收到数千份订单，因此我最终会拥有数千张带有单独订单的迷你餐桌。我还在考虑为所有订单设置一个完整的表格，并为每个订单附加一个 order_id。但是这样一来，我就会有一个表，每个月最多可以有数万条条目。

哪种方法最有效？当然，这两个实现想法可能都离我们很远，所以我愿意听取任何其他想法或想法！

【问题讨论】：

我不知道SO是否适合这个问题，但是这个one generic design for any restaurant and create a new database等各有优缺点
我想我会从任何关于数据库设计和规范化的好书或教程开始
现在你正处于“我想要一所房子，我有一把锤子”的阶段。您需要了解数据库设计、应用程序设计以及可能的餐厅管理。对于stackoverflow页面上的答案来说，这个话题太宽泛了。
“每月数万个条目” 有些系统每小时处理数万个条目，如果不是一分钟的话。您所说的内容对您来说可能听起来很多，但对于计算机而言，这不算什么。
欣赏建议。对于那些推荐我学习更多设计的人，你有什么具体的资源可以推荐给我吗？我以前上过一门数据库课程，但它很垃圾，我通过搜索学到的东西比我在那堂课上学到的更多。 ://

【解决方案1】：

当您实际上并不需要它时，尽量不要为了性能而牺牲设计。它只会制造不必要的并发症。只需尝试以BCNF 或3NF 等正常形式设计您的实体。然后在您设计好实体之后，一切看起来都不错。

然后有许多性能调优和扩展的解决方案。

第一个是indexing，通过索引，可以节省大量的算力。因为查询没有索引的数据库是O(n)，并且通过索引，您可以使用O(log(n)) 甚至O(1)，这取决于您使用的索引算法。

下一个解决方案是partitioning 表格。可以将其想象为将您的表划分为许多表，但数据库将其抽象化，您只能看到一个表。

前两种解决方案可帮助您在一台机器上调优性能。扩大机器规模可以帮助您获得更好的性能。对此有硬件限制。因此，如果您必须向外扩展，则可以使用复制和sharding。

基本上，replication 可以帮助您扩展读取查询。有一些复制解决方案可以扩展写查询，但它们并不是非常有效，因为它们必须在集群中的所有机器上写一个东西。尽管它们是高可用性的完美解决方案。

因此，如果您达到了写入过多的级别，那么复制将不再有帮助。你可以去分片。分片有很多方面。像分片应该在应用程序级别还是数据库级别进行？以及如何在机器之间划分数据？

就我自己而言，我更喜欢数据库级别的分片（我实际上在生产中使用它）。因为应用程序级别的分片可能会使应用程序服务器代码变得复杂（因为您可能需要服务发现等），如果处理不当，甚至会变得肮脏。此外，这种抽象有助于开发人员将集群视为一个数据库，而不是多个分开的数据库。

用于在分片之间划分数据。有垂直分片和水平分片。

在垂直分片中，您将数据按实体划分，例如一个数据库中的客户、另一个数据库中的订单等。这应该是第一种方法，因为它比水平分片更容易做到。

在水平分片中，您在多个数据库服务器之间划分一个实体。例如，您可以使用公式将行均匀划分，例如 ID 为奇数的行进入实例 A，ID 为偶数的行进入实例 B。

另一种方法是用一些常见的方法来划分它们，比如按餐厅划分订单。

希望对您有所帮助。如果您还有其他问题，我很乐意为您解答。

【讨论】：