Структура таблиц mysql - одна очень большая таблица или отдельные таблицы?

Question

Я работаю над проектом, который по своей природе похож на анализ посетителей сайта. Он будет использоваться сотнями сайтов со средним числом просмотров страниц от 10000 до 100000 каждый в день, поэтому объем данных будет очень большим.

Должен ли я использовать одну таблицу с websiteid или отдельную таблицу для каждого сайта?

Внесение изменений в живой сервис с сотнями веб-сайтов с отдельными таблицами для каждого кажется большой проблемой. С другой стороны, производительность и масштабируемость, вероятно, будут проблемой с такими большими данными. Любые предложения, комментарии или советы приветствуются.

Answer 1

Как насчет одной таблицы , секционированной веб-сайтом FK?

Answer 2

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

Но для начала сделайте все просто и используйте одну таблицу с правильной индексацией. Вы также можете определить, нужны ли вам транзакции или нет. Вы также можете использовать различные механизмы хранения MySQL, такие как MyIsam или NDB (в кластеризации памяти), чтобы повысить производительность. Также кэширование играет очень хорошую роль в разгрузке нагрузки от базы данных. Данные, которые в основном предназначены только для чтения и могут быть легко вычислены, обычно помещаются в кеш, и кеш обслуживает запрос, а не поступает в базу данных, а в базу данных поступают только необходимые запросы.

Answer 3

Если данные единообразны, используйте одну таблицу. Если вам когда-либо нужно выбрать на всех веб-сайтах иметь несколько столов это боль. Однако, если вы напишите достаточно сценариев, вы можете сделать это с несколькими таблицами.

Вы можете использовать механизм хранения MySQL MERGE для выполнения SELECT по всем таблицам (но не ожидайте хорошей производительности и следите за жестким ограничением Windows на количество открытых файлов - в Linux вам, возможно, придется использовать ulimit для повышения предел. В Windows нет способа сделать это.)

Я разбил огромную таблицу на множество (сотни) таблиц и использовал MERGE для выбора. Я сделал это так, чтобы я мог выполнять автономное создание и оптимизацию каждой из небольших таблиц. (Например, ОПТИМИЗАЦИЯ или ИЗМЕНЕНИЕ ТАБЛИЦЫ ... ЗАКАЗАТЬ). Однако производительность SELECT с MERGE заставила меня написать свой собственный механизм хранения. (Описано http://blog.coldlogic.com/categories/coldstore/'>here)

Answer 4

Я бы сказал, используйте дизайн, который наиболее целесообразен, учитывая ваши данные - в данном случае одну большую таблицу.

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

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

Answer 5

Используйте одну таблицу, если у вас нет проблем с производительностью с MySQL.

Никто здесь не может ответить на вопросы производительности, вам просто нужно самостоятельно выполнить тесты производительности, чтобы понять, достаточно ли одной большой таблицы.