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

时间:2015-07-17 18:22:39

标签: database database-design schema database-schema

我目前在数据库中有大约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个房型。最后一个很好。

其他要求:

  • 每种房型都有额外的信息。这将是房间允许的最大人数和连接到其他房间信息的“房间标识符”。像设施,照片,描述。
  • 用户应该能够使用分面搜索来过滤数据集

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

  • 我的第一个想法是在哪里插入每个组合。导致大量记录,在添加酒店时增长相当快。前往100k酒店将获得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           etc                 etc         etc         etc
H1234       R1234           20150702            1           A           35
H1234       R1235           20150701            1           A           35
H1234       R1235           etc                 etc         etc         etc
H1235       R6554           20150701            1           A           35
H1235       R6554           etc                 etc         etc         etc
  • 第二个想法是将多个记录“折叠”为一个。价格相同时可能。例如具有相同房型/持续时间/寄宿数据的出发日期。像“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           etc                 etc         etc         etc
H1234       R1235           20150701            1           A           35
H1234       R1235           etc                 etc         etc         etc
H1235       R6554           20150701            1           A           35
H1235       R6554           etc                 etc         etc         etc

“基本”示例是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           etc                 etc         etc         etc
H1234       R1235           20150701            1           A           35
H1234       R1235           etc                 etc         etc         etc
H1235       R6554           20150701            1           A           35
H1235       R6554           etc                 etc         etc         etc

如果不在单个列中添加“持续时间”,而只是存储不同的“离开时间”,则可以使用更小的数据库。如果离职者​​说1-jan,2-jan和3-jan是可能的。可以理解为1晚和3晚住宿是可能的。我可以想象,要求数据库3晚的特定房型和电路板代码将比上述“想法3”慢。接下来我正在寻找获得正确的数据集的想法,当1-jan有3个不同的价格搜索1个月 - 3个晚上。在这种情况下,将有2行。一个1-jan&价格为X的3-jan和价格为Y的2-jan的3-jan。然后应该在运行中组合。可能只是存储更多行更有效。

我会将价格存储在与所有其他信息(酒店名称,星级等)不同的数据库中,房间类型的密钥将匹配。

1 个答案:

答案 0 :(得分:0)

是的,存储了很多行。如果你的价格和你说的一样零碎,那么我会去选项1,因为有很多行我会开始考虑分片。酒店代码似乎是分片密钥的好选择。

但我认为你的价格在同一天没有那么不同。例如,即使您在7月25日或7月27日办理登机手续,即使您入住5或8天,8月1日的价格也可能相同,依此类推。可能的想法是能够根据入住时间和停留时间在同一日期存储不同的价格,但大多数情况下您的价格可能会相同。如果这样更好地考虑一个结构,其中您有停留日期的价格没有任何持续时间,并且只有当您的费率根据持续时间和签入日期而变化时才有额外的行。这将导致更少的行。

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