Хранение миллионов URL-адресов в базе данных для быстрого сопоставления с образцом

Question

Я занимаюсь разработкой системы веб-аналитики, которая должна регистрировать URL-адреса, URL-адреса целевой страницы и ключевые слова для поиска для каждого посетителя сайта. Что я хочу сделать с этими собранными данными, так это позволить конечному пользователю запрашивать данные, такие как «Показать мне всех посетителей, пришедших с Bing.com, которые ищут фразу, содержащую« красные туфли »» или «Показать всех посетителей, которые приземлились на URL, который содержал кампанию "twitter = twitter_ad '" и т. д.

Поскольку эта система будет использоваться на многих крупных веб-сайтах, объем данных, которые необходимо регистрировать, будет расти очень быстро. Итак, мой вопрос: а) какова была бы лучшая стратегия для ведения журнала, чтобы масштабирование системы не стало проблемой; б) как использовать эту архитектуру для быстрого запроса произвольных запросов? Существует ли специальный способ хранения URL-адресов, чтобы их можно было быстрее запрашивать?

В дополнение к базе данных MySQL, которую я использую, я изучаю (и открыт для) другие альтернативы, более подходящие для этой задачи.

Answer 1

Для быстрого поиска в хранилище данных я бы предложил создать индекс URL-адресов (или любых других критериев на основе строк), который основан на структуре данных дерева суффиксов. Поиск будет выполняться в O (k), где k - длина URL (что действительно быстро). Хорошее введение в такие деревья вы можете найти здесь .

Когда дело доходит до регистрации, старайтесь не хранить их по одному. Операции ввода-вывода довольно ресурсоемки и в большинстве случаев являются узкими местами таких систем. Попробуйте записать URL-адреса в ваше хранилище данных в пакетном режиме. Например, сохраняйте представленные URL-адреса в памяти и сохраняйте их только по 1000 кусочкам одновременно. Просто не забудьте обновить для какой-либо фоновой или запланированной задачи дерево суффиксов для синхронизации данных.

Answer 2

Хотелось бы, чтобы в mysql был тип данных для URI. Но так как у oracle есть его и mysql теперь является oracle, это может произойти когда-нибудь ...

http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/sql_elements001.htm#i160550

Answer 3

Я столкнулся с этой конкретной проблемой в SQL Server, и для меня было предложено создать таблицу для хранения всех моих уникальных URL / заголовков с уникальным ключом в двух вычисляемых столбцах, содержащих контрольную сумму URL и TITLE. Он занимал примерно десятую часть пространства в качестве эквивалентного ключа в строке URL / Title.и был в 10 раз быстрее прямого индекса.

Я использую SQL-сервер, поэтому оператор был

(checksum([URL],(0)))

и

(checksum([URL],(0)))

Я нашел это для MySql.

Поскольку большая часть трафика приходила со многих одних и тех же веб-сайтов, это позволило мне объединить URL-адреса / заголовки без необходимости выполнять поиск по всей таблице с каждой вставкой, чтобы применить ограничение уникальности. Моя процедура только что возвратила URL / заголовок PK, если он уже существует.

Чтобы связать своих пользователей, используйте таблицу USER_URL с FK PK USER и URL.

Удачи.