Запрос ЦеныЗапрос Цены
Онлайн ЧатОнлайн Чат
Зона КлиентовЗона Клиентов
КонтактыКонтакты
Скрыть
Live Support
Sales department
Technical Support
Хранилище данных в MySQL

Некоторые базы данных используются для хранения больших объёмов исторической информации (такие как записи данных о звонках, сообщения логов, и т.д.). Эта информация обладает следующими общими признаками:

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

Во время жизни подобных баз данных мы получаем фрагментацию информации (не последовательные свободные блоки, получившиеся в результате удаления старых записей) и проблемы со слишком долгими операциями записи – из-за слишком сильно выросших индексов B-Tree. Во время периодической поддержки информации нам стоит удалить записи из таких таблиц, и у нас произойдёт чрезмерно долгое время блокировки таблиц, если таблица хранится какMyISAM и во всех случаях чрезмерное использование ресурсов процессора и IO, когда проводится команда DELETE
Эти проблемы предотвращают возможность увеличения объёма информации, и мы сейчас опишем, как обойти эти проблемы и как сделать так, чтобы база данных занимала весь ваш жёсткий диск без потери производительности.

Сегментирование таблиц может быть применено для решения этих проблем (начиная с MySQL 5.1 http://dev.mysql.com/doc/refman/5.1/en/partitioning.html).Сегментирование предоставляет возможность разделить информацию на несколько табличных пространств, где раздел автоматически выбирается в зависимости от добавляемой информации.

MySQL поддерживает следующие алгоритмы сегментирования:RANGE, HASH, KEY, LIST (http://dev.mysql.com/doc/refman/5.1/en/partitioning-types.html). В этой статье мы опишем только RANGE сегментирование, основанное на дате, так как оно немного лучше для исторического хранилища данных. Пожалуйста, помните, что MySQL оптимизирован для использования функций o_days() and year() в качестве ключа сегментирования

 

Сегментированные таблицы требуют дополнительных административных задач для управления сегментами (добавление/удаление/разбиение), но улучшение производительности стоит всех проблем, указанных выше:

  • блокируется только один сегмент, вместо всей таблицы в MyISAM
  • не фрагментируется информация – новый/пустой сегмент не содержит старой информации
  • улучшение операций индексирования – уменьшение количества итераций для нахождения ключа вB-Tree индексе

Давайте рассмотрим, например эту таблицу:
CREATE TABLE members (
firstname VARCHAR(25) NOT NULL,
lastname VARCHAR(25) NOT NULL,
username VARCHAR(16) NOT NULL,
email VARCHAR(35),
joined DATE NOT NULL
)
PARTITION BY RANGE( YEAR(joined) ) (
PARTITION p0 VALUES LESS THAN (1960),
PARTITION p1 VALUES LESS THAN (1970),
PARTITION p2 VALUES LESS THAN (1980),
PARTITION p3 VALUES LESS THAN (1990),
PARTITION p4 VALUES LESS THAN MAXVALUE
);

Созданная таблица будет обладать следующими файлами в директории базы данных для: MyISAM:
---
# ls -1 members*
members.frm -описание таблицы
members.par - описание сегментов
members#P#p0.MYD, members#P#p0.MYI - сегмент 0
...
members#P#p4.MYD, members#P#p4.MYI - сегмент 4
---
Для InnoDB (с параметром innodb-file-per-table) будут созданы следующие файлы:
---
members.frm - описание таблицы
members.par - описание сегментов
members#P#p0.ibd, members#P#p1.ibd, members#P#p2.ibd, members#P#p3.ibd, members#P#p4.ibd - пространства таблиц сегментов
---
Из этой файловой структуры легко увидеть, что у каждого сегмента есть своё пространство.

Обратите внимание, что максимальное значение последнего сегмента может быть ограничено указанным значением или не ограничено(MAXVALUE).
Сегментированные таблицы требуют периодической поддержки – создание новых сегментов и удаление ненужных. Если последний ключ сегмента был установлен как в пример на «01 января 2011», это означает, что информация с более новой датой, не включая само 1 января 2011, может быть добавлена в подобный сегмент. Если дата является более старой, чем последний сегмент, добавление информации не случится. ‘MAXVALUE’ может быть указано как последний ключ сегмента – это означает, что у сегментирования нет верхнего ограничения. В любых случаях – периодическая поддержка сегментирования, с сегментами, созданными заранее, является лучшим выходом..

Сегментированные таблицы можно легко изменять:
Если мы хотим добавить сегмент для следующего года в случае, когда последний сегмент обладает значением MAXVALUE, значит, нам необходимо разделить последний сегмент на новые::
---
alter table members reorganize partition p4 into (partition y1999 values less than (2000), partition y2000 values less than (maxvalue));
---
В случае, когда последний сегмент обладает фиксированной датой, новые сегменты могут быть легко добавлены:
---
alter table members add partition (partition y2001 values less than (2002), partition y2002 values less than (2003));
---
Ненужная информация может быть легко удалена, без чрезмерной нагрузки на диск и процессор, так как удаление сегмента является DDL командой. Давайте удалим сегмент, в котором хранятся члены до 1960 года:
---
alter table members drop partition p0;
---
В заключение: использование сегментирования очень помогает в уменьшении нагрузки на процессор и диск во время управления историческими данными. Обычные операции, как запрос или вставка данных также получат от этого преимущество, из-за того, что индексы B-Tree более компактны, а также фрагментация данных снижена. Сегментированная таблица может расти фактически без ограничений.

Запросить цену
Заполните форму и мы свяжемся с Вами в ближайшее время
Вход для клиентов
Система запросов и другие полезные сервисы для наших клиентов
Свяжитесь с нами
Мы с удовольствием ответим на все ваши вопросы