我正在设计一家大型旅游市场机构，在那里我有170000家酒店和3000种房型。
我的实体的简单表示形式是：
Hotel:
destination: Paris
rooms:
room_a:
type: single
room_b:
type: double
RoomType:
name: double
paxes(people in room): 2
最基本的搜索操作要求用户提供目的地和所需房间的数量以及每个房间中的 paxes(人)。
在我看来，获取所有提供所需房间的酒店似乎是一个简单的SQL查询，但我担心我的数据大小。
到目前为止，我只使用关系数据库，以前没有使用MongoDB和ElasticSearch等NoSQL数据库的经验，我想知道使用MongoDB或ElasticSearch比使用关系数据库要快多少。我读过 elasticsearch 的典型用例是全文搜索，但我不知道这样的搜索会快多少。
谢谢
非关系选项可能会显著提高搜索速度，这仅仅是因为大型数据集上的联接速度很慢。使用Mongo或Elasticsearch之类的东西，您可以创建一个包含所有相关信息的文档并进行搜索。从关系背景来看，这似乎违反直觉 - 但这个想法是一起访问的信息是一起存储的。
至于 elasticsearch 与 mongo，这里有几件事需要考虑：
- Elasticsearch将更容易过渡到更全面的功能搜索功能。全文搜索特定酒店？边打边搜？建议？"你的意思是"功能？但它也非常擅长结构化过滤，就像你描述的那样。
- Elasticsearch 可能不应该用作您的主要数据源。它不如Mongo或SQL可靠。无论如何，它都不是一个糟糕的产品，但它的分布式性质意味着，如果你超级重视数据的完整性，只需使用弹性进行搜索。
- 这样做的分支是，您必须提前构建索引才能进行搜索。这增加了复杂性，并可能延迟数据的"实时"更新。归根结底，这是搜索如此之快的一部分 - 就像SQL索引一样，您可以通过减慢写入速度来加快读取速度。
虽然使用 Elasticsearch - 或 Mongo 很容易获得一些东西，但我认为 Elasticsearch 的学习曲线有点陡峭。你可以用Elasticsearch做很多事情，这使得筛选起来有点困难。
- 还要了解您的生产计划(如果您要将其投入生产)。Elastic和Mongo的设置都比SQL DB更复杂。 没有许可成本，但用于复制甚至使用托管解决方案的多个盒子可能会变得昂贵。
每个数据库框架都有自己的优点和缺点，但是，根据我的经验，Elasticsearch 之所以好，原因如下：
- 非常容易启动和运行它。
- 通过面向主要云提供商的内置群集发现进行水平扩展。
- 您的数据结构是一个嵌套对象，elasticsearch 索引映射支持这一点。
- 高性能，您可以根据需要调整服务器RAM：磁盘比率。
- 支持各种文本分析器。
- 您可以精细控制文档的哪个部分必须可搜索。
- 可用于主要编程语言的 API。
- 如果你想要更多功能，如监控、警报、安全等，你可以订阅 Elastic 的 x-pack，这很酷。