如何在数据库中存储大量酒店可用性数据

Question

我目前在数据库中有大约 10.000 家酒店（并且还在不断增加）。目前没有存储可用性数据。我想存储可用性数据 + 价格，以便人们可以搜索一组酒店（例如在纽约）在给定日期 + 持续时间是否可用。

我必须存储的内容：

• 10.000 家酒店（并且还在不断增加）
• 每家酒店 6 种房型
• 最多 365 个出发日（但可能更少，比如 300 个）
• 每种房型有大约 30 个持续时间（从 1 晚到 31 晚）
• 1 到 5 种（但主要是 1-3 种）板型（例如，包括早餐，全包）
• 以上每种组合都有价格

当我为每个组合生成 1 个“行”时，“行”的数量将为 10.000 * 6 * 300 * 30 * 3 = 1.620.000.000 行。作为开始。

写作： 每天将刷新大约 25% 的数据。

阅读： 每天有 20.000 名访问者搜索数据。假设每天有 50.000 个请求，晚上有一个高峰（晚上 8 点到 11 点之间有 20.000 个）。主要搜索 1 种房型。有些人会在 1 家酒店中搜索 2 种房型。最后一个很不错。

其他要求：

• 每种房型都包含附加信息。这将是房间中允许的最大人数以及链接到其他房间信息的“房间标识符”。比如设施、照片、描述。
• 用户应该能够使用分面搜索在数据集中进行过滤

我的具体问题是如何设置数据库的架构。

• 我的第一个想法是在哪里插入每个组合。导致大量记录，添加酒店后增长非常快。去 10 万家酒店将产生 10 倍以上的记录。结构如下：

Hotelcode Roomtypecode Departureday Duration Boardcode Price H1234 R1234 20150701 1 A 35 H1234 R1234 20150701 1 B 45 H1234 R1234 20150701 2 A 65 H1234 R1234 20150701 2 B 80 H1234 R1234 等等等等等等等等 H1234 R1234 20150702 1 A 35 H1234 R1235 20150701 1 A 35 H1234 R1235 等等等等等等等等 H1235 R6554 20150701 1 A 35 H1235 R6554 等等等等等等

• 第二个想法是将多个记录“折叠”为一个。价格相同的情况下可以。例如，具有相同房型/持续时间/入住数据的出发日期。存储出发日期，如“20150701|20150702|etc”。但后来认为应该进行“就像'％20150718％'的搜索。我认为这不会很快。喜欢：

Hotelcode Roomtypecode Departureday Duration Boardcode Price H1234 R1234 20150701|20150702 1 A 35 H1234 R1234 20150701 1 B 45 H1234 R1234 20150701 2 A 65 H1234 R1234 20150701 2 B 80 H1234 R1234 等等等等等等等等 H1234 R1235 20150701 1 A 35 H1234 R1235 等等等等等等等等 H1235 R6554 20150701 1 A 35 H1235 R6554 等等等等等等

“基本”示例是 expedia.com、booking.com 和 orbitz.com 的“酒店”变体。如您所见，它们返回结果的速度非常快，对于“可能未缓存的结果”也是如此。

具体问题是“我应该以什么方式在数据库中构建这些数据”。

我当然明白我选择的数据库类型（mysql、solr、Cassandra、redis）会影响结果。目前我首先想找出需要存储的预期行数/文档数。

更新

根据 Livio Costea 给出的答案，这将是想法 3。与想法 2 的不同之处在于 a) 没有酒店的总住宿价格，但每晚的价格使其能够 b) 将多个持续时间添加到一行。

Hotelcode Roomtypecode Departureday Duration Boardcode Price H1234 R1234 20150701|20150702 1|2 A 35 H1234 R1234 20150701 1|2 B 45 H1234 R1234 20150702 1|2 B 55 H1234 R1234 等等等等等等等等 H1234 R1235 20150701 1 A 35 H1234 R1235 等等等等等等等等 H1235 R6554 20150701 1 A 35 H1235 R6554 等等等等等等

如果不在单个列中添加“持续时间”而仅存储不同的“出发日”，则可以使用更小的数据库。如果出发日表示 1 月 1 日，2 月 2 日和 3 月是可能的。可以解释为可以入住 1 月 + 3 晚。我可以想象，向数据库询问特定房间类型和板代码的 3 晚会比上述“想法 3”慢。紧挨着我在搜索 1 月 1 日至 3 晚（2 月 2 日的价格不同）时获取正确数据集的想法苦苦挣扎。在这种情况下，将有 2 行。一个用于 1 月和 3 月的价格为 X，一个用于 2 月的价格为 Y。然后应即时组合。可能只是存储更多行更有效。

我会将价格存储在与所有其他信息（酒店名称、星级等）不同的数据库中，房间类型键将是匹配项。

Answer 1

是的，有很多行要存储。如果你的价格像你说的那样分散，那么我会选择选项 1，因为行数太多，我会开始考虑分片。酒店代码似乎是一个很好的片键候选者。

但我认为你的价格在同一天并没有那么不同。例如，即使您入住 5 天或 8 天，或者即使您在 7 月 25 日或 7 月 27 日入住，8 月 1 日的价格也可能相同。可能的想法是能够根据入住和逗留时间存储同一日期的不同价格，但在大多数情况下，您的价格很可能是相同的。如果是这样，最好考虑一个结构，其中您有没有任何持续时间的住宿日期的价格，并且只有当您的房价根据持续时间和入住日期发生变化时才会有额外的行。这应该会导致更少的行。

现在对于持久性，如果您想要快速的结果，您需要将 Redis 添加到您的堆栈中，因为数据保存在 ram 中，这意味着它非常快。您可以在 Redis 中使用所有这些模式，但由于它是 NoSQL，如果您尝试为这些数据生成一些报告，您将有很多工作要做。另一种选择是将其添加为额外的持久性，您将只保留您的价格，并且您将始终在那里进行搜索。而且您必须将其与保存所有资料的数据库保持同步：价格以及所有其他酒店和房间信息。该数据库可以是 MongoDB 或 SQL 解决方案。