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

Question

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

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

Лучшим решением, по-видимому, является объединение таблицы для каждого дня в таблицу слияния для выбора. На самом деле будут дублированные данные, но 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

Answer 1

Я знаю, что вы уже приняли ответ View, и я знаю, что вы упомянули, что вы все еще застряли на 5.0 ... но я все же подумал, что стоит упомянуть о разбиении, которое, насколько я понимаю, решит все ваши проблемы. 1001 * Удаление старых данных так же просто, как удаление одной из ваших отдельных таблиц ... и бесконечно быстрее, чем выполнение операции «удалить из огромной_таблицы, где отметка времени и если вы убедитесь, что ваши запросы правильно сокращают разделы, чтение также должно быть быстрым.

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

Answer 2

Если я получаю суть этого вопроса, то индексирование будет бесплодным из-за большого объема вставок, а поиск по 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;

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