Озадаченный максимальным количеством записей таблицы в MySQL

Question

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

Теперь мы ежедневно переносим журнал из tomcat в базу данных (MySQL), теперь он работает хорошо. Однако я обнаружил потенциальную и смертельную проблему!

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

И мы используем hibernate в качестве слоя персистентности, каждая строка в таблице журнала отображается в Java-объекте LogEntry в приложении.

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

Кроме того, номер журнала каждого месяца может не совпадать, крайний пример, как насчет того, чтобы номер журнала (записи в таблице) превышал максимальную емкость таблицы в дБ?

Тогда я подумал установить свойство, чтобы ограничить максимальное количество журналов, которые будут выдвигаться при переходе из спящего режима в журнал в db. Если это так, я понятия не имею, попросить hibernate создать новую таблицу и автоматически выполнять запросы к ней.

Есть идеи?

Обновление до Сэнди:

Я знаю ваше значение, то есть максимальная емкость таблицы определяется ОС, и если я использую разбиение, максимальная возможность может увеличиваться, пока не достигнет максимальной емкости моего диска. Однако даже если я использую раздел, мне кажется, что мне не нужно заботиться о максимальных возможностях таблицы, но если таблица содержит слишком много записей, это приведет к низкой производительности. (Кстати, мы еще не решили удалить старые журналы.) Еще один способ, который я подумал, это создать больше, чем таблицы с одинаковой структурой, но я использую hibernate, все операции вставки и запроса журналов будут проходить через hibernate, и может объект (POJO) сопоставлен с несколькими таблицами?

Answer 1

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

Посмотрите на HibernateОсколки (осколок базы данных - это метод горизонтального разбиения).Хотя этот суперпроект не очень активен и имеет некоторые ограничения (см. Документацию), он стабилен и пригоден для использования (Осколки гибернации были предоставлены Максом Россом от Google, который использует его внутри).

Кроме того, номер журнала каждого месяца может не совпадать, крайний пример, как насчет того, чтобы номер журнала (записи в таблице) превышал максимальную емкость таблицы в дБ?

Мониторинг вашей базы данных / таблиц и ожидание необходимого обслуживания.

Если это так, я не имею ни малейшего понятия, чтобы hibernate создавал новую таблицу и выполнял запросы по всей таблице автоматически.

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

Answer 2

Я думаю, вы должны рассмотреть горизонтальное разбиение.

Горизонтальное разделение

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

Повышенная производительность - при сканировании

операций, знает оптимизатор MySQL какие разделы содержат данные, которые будет удовлетворять конкретный запрос и будет доступ только к тем, которые необходимы разделы во время выполнения запроса. Для Например, таблица миллионов строк может быть разбить на десять разных перегородки в стиле диапазона, так что каждый раздел содержит 100 000 строк . * Если выдается запрос, требующий только данных от одного из разделов и необходима операция сканирования таблицы, только 100 000 строк будут доступны вместо миллиона. Очевидно, это гораздо быстрее для MySQL, чтобы попробовать 100 000 строк, чем один миллион, поэтому запрос завершится гораздо раньше. та же выгода должна быть указана доступ возможен как местный секционированные индексы созданы для секционированные таблицы. Наконец, это можно чередовать разделенную таблицу через разные физические диски по указание другого файла системные / каталогные пути для конкретных перегородки. Это позволяет физический ввод / вывод Разногласия должны быть уменьшены, когда несколько разделы доступны одновременно время.

Оформить заказ этой статьи Повышение производительности базы данных с помощью секционирования

Обновление

Кажется, что горизонтальное разбиение может обрабатывать большие таблицы, но как насчет того, если номер записи превышает максимальный размер таблицы?

На самом деле, максимальный размер таблицы mysql определяется ограничениями операционной системы. Посмотрите на это и определите себя. Альтернативным вариантом является периодическая очистка старых записей журнала, только если они не требуются для анализа. Создайте задачу cron или любую запланированную задачу для удаления.