database-design - FaceBook搜索:它的技术要求和创新功能有哪些值得关注？

Question

Facebook已经在搜索中融入了一些独特的功能-甚至可能已经获得了某些专利？我所说的功能是由三个不同的要求驱动的：


他们的数据库巨大，而且他们不能随便将它们联接到所需数据上，正如您所希望的那样，通常是在一个拥有少于一百万条记录的单宿主业务应用程序中。
用户的期望值受其他搜索体验（即Google）的影响，因此，通过在要搜索的人的姓名后附加关键字（例如“佛罗里达州奥兰多”或“扶轮社”）（或某些人），可以进行长尾搜索查询其他识别值，例如雇主名称）。
基于我们从应用程序中查找的窗口，数据体系结构似乎很浅（当然，它并不浅）。我的意思是，除了用户配置文件中所谓的“基本信息”（例如性别和当前城市）之外，使配置文件唯一的大部分内容都不会严格分配给逻辑列。


因此，与数据集的大小相关的需求中存在复杂性，但需要向用户交付相关结果，到一个不精通搜索，但是由TheThe提供了他们期望和培训的用户社区谷歌。

考虑到所有这些（我的问题的细化）：

a。）我们应该注意并部署在我们自己的搜索应用程序/引擎中的FaceBook需要哪些搜索功能？必要时，我的意思是受数据集的庞大规模驱动，或者受用户的期望驱动，并且网站需要有机地增长和增加其数据之间的关系，即用户。

b。）哪些搜索功能具有创新性，值得数据和/或搜索架构师关注？

有些是显而易见的，例如对名字使用同义词-将“帐单”查询与“威廉”记录模糊匹配。您可以在Solr中使用同义词列表进行此操作。我将其称为必要的基本功能，当然不是创新的。

其他创新的东西值得我们关注。我可以引起注意的第一个创新示例是，它们的搜索相关性是针对每个用户定制的。如果我输入“ John Smith”，则得到的结果集将不同于其他搜索者（理论上，对我，网络中的人，朋友的朋友等的匹配更好）。在您说这不是创新之前，因为您可以在Google中仅输入“ Pizza”，然后他们会将您的语言环境附加到查询中，从而为您提供相关的结果，请继续。我希望，对这个问题的答案和讨论确实可以构成一些技术要求，并提供想法作为搜索功能。

例如...


您会猜测他们运行常规的批处理过程来对数据进行非规范化吗？ （即批处理作业，以建立就地第一分离度，第二分离度等的链接表）
通过这样的批处理或非规范化，它是否会限制点击数？仅返回逻辑上最接近的“约翰·史密斯”匹配项即可证明这一点。但是，对非通用名称（例如我自己的名字和姓氏）的搜索似乎不受结果限制的影响，并且搜索将遍及全球，完全不在“几度”分离的范围内。
他们是否按年龄增加了相关性评分，从而使与搜索者处于同一年龄段的比赛具有更高的相关性？ （评论：看来他们应该这样做，这至少应该是代际沟通/会议的一个小小的障碍，我不知道这是委婉的）


从技术上讲，在后端，最好是在数据库级别执行非规范化过程，然后为“文档”建立索引吗？ （说明：对于那些联合进行企业搜索的人，“文档”的概念类似于数据库记录，是MOL ... MOL）

或者，是否没有数据库非规范化。取而代之的是，编写搜索索引的过程包括将相关信息和“处于网络中”或相距几度的人员写入每个“文档”中。

确实，有必要对此类信息进行预处理。我自己在实践中没有做过这样精确的事情，在我看来，在数据库级别进行批量非规范化是有利的，原因是搜索服务器擅长超快速地查找信息，而数据库服务器则擅长于获取信息。匹配数据（假设数据扩展到搜索索引中没有的相关列）。

因此，扩展依赖于用户搜索者的搜索相关性的概念时，请注意，它也是用户最近浏览活动的衍生形式。例如，搜索“约翰·史密斯奥兰多”可能永远不会产生“正确的”约翰·史密斯，但是在访问了正确的约翰·史密斯的FaceBook页面（假设您通过电子邮件获得了他的URL）之后，即使没有将约翰·史密斯添加为朋友，下次，对John Smith的后续搜索实际上将在下一次返回该结果。 [我不知道它会过期多长时间，还是完全过期？]

我在这里以Facebook为例，因为它们很大。它们的大小决定了一种经过深思熟虑的体系结构，例如保持其正常形式的结构，以及不能因为不能重复JOIN 1亿个记录表（不能从另一个“叉子”重新加入同一个人表）而导致的结构链接表或derived table可以产生“朋友的朋友”效果）。

相关性调整的实践实际上几乎是一门艺术。数据集，业务规则和用户期望非常独特，以致几乎无法创建多功能评分模板甚至最佳实践。

话虽这么说，通过寻找能够很好地进行搜索的大型网站，有一种技术可以模仿，不是吗？

FaceBook有哪些技术？考虑到它们的大小，他们不能仅通过ORM来获取用户所需的内容（不是对ORM拥护者的猛烈抨击）-这就需要精心计划的规范化，SQL级索引，DE规范化和搜索服务器索引。

谁能建议那里采用哪些技术？为此，任何具有相似搜索（和大数据集）的大型站点也将提供良好的主题建议。

Answer 1

对于数据库，Facebook由于其速度和可靠性而使用MySQL。 MySQL主要用作键值存储，因为数据在大量逻辑实例之间随机分布。这些逻辑实例分布在物理节点上，并且负载均衡是在物理节点级别完成的。
就定制而言，Facebook开发了一种定制分区方案，其中将全局ID分配给所有数据。他们还具有基于每个用户的频繁程度和最新数据的自定义存档方案。大多数数据是随机分布的。


对于收件箱之类的某些部件，它使用“最终一致”的NoSQL数据库，并且在查询它们的群集时，会得到“当时的最佳答案”，不一定是正确的。

从问题的某些部分来看，您似乎正在尝试采取适用于社交媒体的做法并将其更广泛地应用。最终，一致性无法在会计或交易或医学或研究中发挥作用。如果这是房妮姨妈的最新照片，那没人会在乎FB页面是否始终显示最新的猫。您愿意为了这种平庸而牺牲这种准确性。

因为FB做到了，所以将每个第3个正规表单业务应用程序转换成关键值对，这不是我愿意登上的火车。