Архитектура базы данных для миллионов новых строк в день

Question

Мне нужно реализовать специально разработанный сервис веб-аналитики для большого количества веб-сайтов.Ключевыми объектами здесь являются:

• Веб-сайт
• Посетитель

Каждый уникальный посетитель будет иметь одну строку в базе данных с такой информацией, как целевая страница,время суток, ОС, браузер, реферер, IP и т. д.

Мне нужно будет выполнить агрегированные запросы к этой базе данных, такие как «СЧИТЫВАТЬ всех посетителей, которые используют Windows как ОС и пришли с Bing.com»

У меня есть сотни сайтов для отслеживания, и количество посетителей этих сайтов варьируется от нескольких сотен в день до нескольких миллионов в день.В целом, я ожидаю, что эта база данных будет расти примерно на миллион строк в день.

Мои вопросы:

1) Является ли MySQL хорошей базой данных для этой цели?

2) Что может быть хорошей архитектурой?Я думаю о создании новой таблицы для каждого сайта.Или, возможно, начать с одной таблицы, а затем создать новую таблицу (ежедневно), если количество строк в существующей таблице превышает 1 миллион (мое предположение верно).Единственное, что меня беспокоит, так это то, что если таблица становится слишком большой, SQL-запросы могут значительно замедлиться.Итак, какое максимальное количество строк я должен хранить в таблице?Более того, существует ли ограничение на количество таблиц, которые может обрабатывать MySQL.

3) Желательно ли выполнять агрегированные запросы по миллионам строк?Я готов подождать пару секунд, чтобы получить результаты для таких запросов.Является ли это хорошей практикой или есть какой-либо другой способ выполнения агрегированных запросов?

В двух словах: Я пытаюсь разработать крупномасштабную установку типа хранилища данных с интенсивной записью .Если вы знаете о каких-либо опубликованных тематических исследованиях или отчетах, это будет здорово!

Answer 1

Если вы говорите с большими объемами данных, тогда посмотрите на Разделение MySQL . Для этих таблиц разделение по данным / времени определенно повысит производительность. Приличная статья о разбиении здесь .

Посмотрите на создание двух отдельных баз данных: одну для всех необработанных данных для записей с минимальной индексацией; второй для отчетности с использованием агрегированных значений; либо с помощью пакетного процесса для обновления базы данных отчетов из базы данных необработанных данных, либо для репликации используйте репликацию.

EDIT

Если вы хотите быть действительно умным с вашими отчетами агрегации, создайте набор таблиц агрегации («сегодня», «неделя до даты», «месяц до даты», «по годам»). Агрегировать от необработанных данных до «сегодня» либо ежедневно, либо в «реальном времени»; агрегировать от «по дням» к «неделям до даты» по ночам; от "неделя к дате" до "месяц к дате" на еженедельной основе и т. д. При выполнении запросов объедините (UNION) соответствующие таблицы для интересующих вас диапазонов дат.

РЕДАКТИРОВАТЬ # 2

Вместо одной таблицы для каждого клиента, мы работаем с одной схемой базы данных для каждого клиента. В зависимости от размера клиента у нас может быть несколько схем в одном экземпляре базы данных или выделенный экземпляр базы данных для каждого клиента. Мы используем отдельные схемы для сбора необработанных данных и для агрегации / отчетности для каждого клиента. Мы запускаем несколько серверов баз данных, ограничивая каждый сервер одним экземпляром базы данных. Для обеспечения устойчивости базы данных реплицируются на несколько серверов и сбалансированы для повышения производительности.

Answer 2

Некоторые предложения в зависимости от базы данных.

Самым простым рациональным является различие между таблицами с интенсивным чтением и интенсивной записью. Вероятно, это хорошая идея - создать две параллельные схемы - ежедневную / недельную, а также схему истории. Разделение может быть сделано соответствующим образом. Можно придумать пакетное задание для обновления схемы истории данными из дневной / недельной схемы. Снова в схеме истории вы можете создать отдельные таблицы данных для каждого веб-сайта (на основе объема данных).

Если вас интересует только статистика агрегирования в отдельности (что может не быть правдой). Хорошей идеей будет иметь сводные таблицы (ежемесячные, ежедневные), в которых хранится сводная информация, например, общее количество не посещенных посетителей, повторных посетителей и т. Д .; и эти сводные таблицы должны быть обновлены в конце дня. Это позволяет на лету вычислять статистику без ожидания обновления базы данных истории.

Answer 3

Вам определенно следует рассмотреть возможность разделения данных по сайту между базами данных или схемами - это не только значительно упрощает резервное копирование, удаление и т. Д. Отдельного сайта / клиента, но и устраняет большую часть хлопот, связанных с тем, чтобы ни один клиент не мог видеть другие данные клиентов случайно или из-за плохого кодирования и т. д. Это также означает, что легче делать выбор в отношении разбиения разделов, сверх разделов данных на уровне таблиц для времени или клиента и т. д.

Также вы сказали, что объем данных составляет 1 миллион строк в день (это не особенно тяжело и не требует огромных ресурсов для записи / хранения или даже для отчетов (хотя, если вы генерировали 500 отчетов в полночь, вы могли бы logjam). Однако вы также сказали, что некоторые сайты посещают по 1 млн человек в день, поэтому, возможно, вы считаете, что они слишком консервативны?

Наконец, вы не сказали, хотите ли вы в режиме реального времени сообщать о диаграмме / opentracker и т. Д. Или циклически обновляться, например, в Google Analytics - это будет иметь большое значение для вашей модели хранения с первого дня.

M

Answer 4

Вы действительно должны проверить свой путь вперед в симулированной среде, максимально приближенной к реальной среде, с данными «реальной подделки» (правильный формат и длина). Контрольные запросы и варианты табличных структур. Так как вы, кажется, знаете MySQL, начните там. Это не займет у вас много времени, чтобы настроить несколько сценариев, бомбардирующих вашу базу данных запросами. Изучение результатов вашей базы данных с вашим видом данных поможет вам понять, где возникнут узкие места.

Не решение, но, надеюсь, некоторая помощь в пути, удачи:)