我正在开发一种网站分析类型的系统，需要在网站上为每个访问者记录引荐网址，着陆页网址和搜索关键字。我想对收集到的数据做的事情是允许最终用户查询数据，例如“向我展示所有来自Bing.com的访客搜索包含'红色鞋子'的短语”或“向我显示所有登陆的访客在包含'campaign = twitter_ad'“的URL上，等等。将数百万个网址存储在数据库中以进行快速模式匹配
因为这个系统将被用在很多大网站上，所以需要记录的数据量真的会非常快。所以，我的问题是：a）什么是记录最好的策略，以便缩放系统不会变成一种痛苦; b）如何使用该体系结构快速查询任意请求？是否有一种特殊的方法来存储URL，以便查询它们的速度更快？
除了我使用的MySQL数据库之外，我正在探索（并开放给）更适合于此任务的其他替代方案。
为了快速搜索数据存储，我建议创建基于后缀树数据结构的url（或任何其他基于字符串的条件）的索引。搜索将在O（k）中完成，其中k是url的长度（这非常快）。一个很好的介绍这种树你可以找到here。
说到日志记录，尽量不要一个存储它们。 I/O操作相当耗费资源，并且在大多数情况下是这些系统的瓶颈。尝试批量写入你的数据存储到你的数据存储。例如，将提交的URL保存在内存中，并且一次只能存储1000个块。只记得在某些背景或计划任务上更新后缀树以保持数据同步。
我在SQL Server中遇到了这个确切的问题，对于我来说解决方案是一个表，用于在包含URL和TITLE校验和的两个计算列上存储具有唯一键的所有唯一URLS/TITLES的表。它占用了大约十分之一的空间作为字符串URL/Title的等效键，比直接索引速度快10倍。
我使用SQL服务器，这样的说法是
(checksum([URL],(0)))
和
(checksum([URL],(0)))
我发现this用于MySQL的。
由于大多数流量都来自许多相同的网站，因此它允许我合并url/titles而不必搜索每个插入表的整个表以强制执行唯一约束。我的程序只是返回了一个url /标题PK，如果它已经存在。
要与您的用户绑定，请使用USER_URL表，其中包含USER和URL的PK的FK。
祝你好运。
我希望在URI上有一个mysql数据类型。但由于甲骨文拥有了它，现在的MySQL是甲骨文，这可能有一天会发生......
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/sql_elements001.htm#i160550
感谢您的建议。虽然校验策略可能不适用于我，因为我可能需要进行模式匹配，例如：搜索包含campaign = twitter的所有URL – 2010-06-06 05:32:05