Таблицы MySQL Merge - большой трафик и большие объемы данных

0

Моя работа в настоящее время использует MySQL (MyISAM) исключительно для всех хранилищ данных. В настоящее время у нас более 300 веб-серверов и около 150 баз данных. К сожалению, я в состоянии написать таблицу структуры для поддержки более 100 миллионов строк за 30 дней. Идея такова:

  • Вставки большого объема (никаких обновлений или удалений и всегда в конце таблицы)
  • 1 строка выбирает
  • Данные старше 30 дней отбрасываются.

Лучшим решением, похоже, является таблица для каждого дня, объединенная в таблицу Merge для выбора. Будут дублированные данные, но SELECT будет вытаскивать только самую последнюю строку на основе метки времени и поля int. Очевидно, что наличие 30 столов не является идеальным, но так же и жизнь.

Есть ли какие-либо внутренние недостатки этого подхода? Есть ли другие способы приблизиться к этому, что мне не хватает (мы застряли в 5.0)? Будет ли блокировка таблиц огромной проблемой при выполнении ALTER TABLE в таблице слияния при создании новой таблицы дней? В настоящее время у нас есть структура вращения таблицы, но если мы пойдем с одной таблицей, которая должна выбрать нужные нам данные из старой таблицы в новую, она будет довольно медленной, когда она приблизится к 100 миллионам строк.

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

Любой ввод будет оценен.

Состав:

CREATE TABLE `merge_test_1` (
   `date_stamp` long NOT NULL,
   `hash` char(32) NOT NULL,
   `p_id` mediumint(8) unsigned NOT NULL,
   `a_id` mediumint(8) unsigned NOT NULL,
   `b_id` mediumint(8) unsigned NOT NULL,
   PRIMARY KEY  (`hash`,`p_id`,`date_stamp`)
 ) ENGINE=MyISAM

Пример запроса

SELECT b_id,a_id FROM merge_test WHERE hash='1' AND p_id=1
ORDER BY date_stamp DESC LIMIT 1
Теги:
database
merge

2 ответа

0
Лучший ответ

Если я получаю ядро ​​этого вопроса, что индексирование будет бесплодным из-за высокообъемных вставок, а поиск на основе MAX (id) не соответствует вашим критериям... "SELECT будет вытаскивать только самую последнюю строку на основе метки времени и поля int.

Пробовали ли вы с помощью представления для этой цели? Кажется правдоподобным для победы.

например.

CREATE TABLE lotsofdata (
id INT UNSIGNED AUTO_INCREMENT,
int_val INT UNSIGNED,
the_timestamp TIMESTAMP,
PRIMARY KEY(id));
--
CREATE VIEW FROM 
SELECT id,int_val,the_timestamp 
FROM lotsofdata
WHERE the_timestamp = MAX(the_timestamp)
AND MAX(int_val)
LIMIT 0,1;

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

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

Я знаю, что вы уже приняли ответ "Представления", и я знаю, что вы упомянули, что все еще застряли в 5.0... но я все же думал, что стоит упомянуть раздел, который из того, что я собираю, решит все ваши проблемы. < ш > Удаление старых данных так же просто, как удаление одной из ваших отдельных таблиц... и бесконечно быстрее, чем выполнение "delete from huge_table where timestamp < x"
и если вы убедитесь, что ваши запросы правильно вырезают разделы, чтение также должно быть быстрым.

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню