Fatal编程技术网
  • algorithm/
  • Algorithm 查找两个twitter用户关系的算法

Algorithm 查找两个twitter用户关系的算法

algorithm twitter

Algorithm 查找两个twitter用户关系的算法,algorithm,twitter,relationship,Algorithm,Twitter,Relationship,我有一个凯文·培根式的6度问题。假设我有两个推特用户，我想通过推特上的朋友（我用朋友来表示你跟踪某人和他们跟踪你）和追随者来确定他们之间的关系。我的数据库里有所有的id 例如： 乔尔和萨利 乔尔跟着弗雷德，弗雷德和史蒂夫是朋友，史蒂夫跟着萨利 有多种方法可以到达那里，但我想要最短的 这似乎是一个众所周知的计算机科学问题（最短路径算法） 今天，我有一个名为“影响者”的表，其中存储了我所有的twitter ID，然后我有一个followers表，它是一个自参考表（一边是追随者ID，另一边是朋友ID）

我有一个凯文·培根式的6度问题。假设我有两个推特用户，我想通过推特上的朋友（我用朋友来表示你跟踪某人和他们跟踪你）和追随者来确定他们之间的关系。我的数据库里有所有的id

例如：

乔尔和萨利

乔尔跟着弗雷德，弗雷德和史蒂夫是朋友，史蒂夫跟着萨利

有多种方法可以到达那里，但我想要最短的

这似乎是一个众所周知的计算机科学问题（最短路径算法）

今天，我有一个名为“影响者”的表，其中存储了我所有的twitter ID，然后我有一个followers表，它是一个自参考表（一边是追随者ID，另一边是朋友ID）

这就是图论吗？如果是这样的话，有人能告诉我一些有用的实用程序/库/方法吗。我使用ruby，但可以解析大多数语言。

正如您所说，这是一个众所周知的问题，您可以在中看到

请注意，在您的例子中，所有边的权重都等于1），因此我认为Djikstra的算法对您不是很有用

为了找到最小距离，我建议进行广度优先搜索。问题是推特网络可能连接非常紧密，因此可能会出现组合爆炸（假设每个人都与20个其他人连接—在第一个级别中，您将访问20个配置文件，而在下一个级别中，您将访问400个配置文件，在下一个级别中，您将访问8000个配置文件—如果您没有快速找到Sally，您将很快耗尽内存）

还有一个线性规划公式，我不是100%熟悉。我擅长线性规划，但不擅长最短路径问题，而似乎更注重应用

有一个关于这个问题的在线解决方案，看起来相当完整

我希望这些参考资料能有所帮助。

听起来你需要BFS

在线方法： 我认为它可能很贵，这取决于你想如何使用它。 在最坏的情况下，您将迭代数据库中的所有数据：cost runtime
O（n）
（假设您有一个查找函数，可以在runtime
O（1）
中在图中查找用户）

离线方法 您可以进行离线计划的预计算并将距离存储为查找函数，但它需要一些额外的内存
O（n*n）
，其中n是用户数。查找函数的成本现在仅为
O（1）
或
O（logn）
，具体取决于您如何实现它 （忽略离线运行时，我认为离线运行时将位于
O（n）
到
O（n*n）
）

战略 您希望遵循的策略可能取决于您预期的用户数上限以及用户之间的连接情况。如果用户数很少，则在线方法可能很好，如果用户数为百万，则可能需要离线方法，但这会消耗一些内存

其他注意事项

  • 混合在线和离线方法
  • 使用缓存策略
  • 每当为用户更新新引用时，请更新距离查找功能
更新答案有1700万用户，我们需要离线方式

我会遵循离线版本。你应该避免
O（n*n）
运行时，我认为这是可能的

DB型号

您应该考虑如何对DB建模，因为这将是此实现中最昂贵的部分

可能是这样的： 为每个用户创建一个表（表名可以是userId），并且每个表都有每个用户的条目（记录键是userId）。 这将产生1700万个表，每个表有1700万个条目（这是
O（n*n）
cost）

离线您运行BFS一次，同时跟踪您访问了哪个用户以及您在BFS迭代中处于哪个级别，并保存到数据库的距离。我还没有仔细考虑这一部分，但我认为这一策略是可行的。记住在每个节点上运行BFS，即直到您访问了所有用户。 如果此策略不可行，则您可以从运行时为
O（n*n）
的每个节点运行BFS。这意味着在最坏的情况下运行BFS可能需要一个月的时间，即您的距离数据可能很旧。运行速度取决于您的用户的连接程度

或者，如果可能的话，您可以采用“每当为用户更新新引用时，更新距离查找函数”的方法。这将运行BFS一次，即
O（n）
，即几秒钟。在第一次事件时调用BFS（userId），然后在引用更新时调用BFS

联机您使用userId按表名获取表，并使用另一个userId获取条目以获取距离。

他不会耗尽内存。BFS是O（N）内存智能型的（考虑到在BFS中您标记访问的节点，并且不再将它们排队）。问题是推特用户可能有数百个连接（我相信20是一个极端保守的估计），所以即使是O（N）如果距离和连接数都很高，推特用户有1M的追随者，我们数据库中有几十个用户有成千上万个。也许，在这种情况下，你可以考虑迭代加深深度优先搜索。当你有一百万个用户时，O（n*n）肯定是太多了。