我正在開發一種網站分析類型的系統，需要在網站上爲每個訪問者記錄引薦網址，着陸頁網址和搜索關鍵字。我想對收集到的數據做的事情是允許最終用戶查詢數據，例如「向我展示所有來自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