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

Моя работа в настоящее время использует 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

mysql database merge
person methodin    schedule 27.09.2010    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

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

E.g.

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;

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

person randomx    schedule 27.09.2010
comment
Я должен был заявить, что наша группа администраторов баз данных сильно ограничивает наши возможности, а представления не поддерживаются. Отредактированный пост с примерами структуры и запроса. - person methodin; 28.09.2010

arrow_upward
0
arrow_downward

Я знаю, что вы уже приняли ответ Views, и я знаю, что вы упомянули, что все еще застряли на 5.0 ... но я все же подумал, что стоит упомянуть разбиение на разделы, которое, насколько я понимаю, решит все ваши проблемы.
Отбрасывание удалить старые данные так же просто, как удалить одну из ваших отдельных таблиц... и бесконечно быстрее, чем выполнить "удаление из огромной_таблицы, где отметка времени ‹ x"
, и если вы убедитесь, что ваши запросы правильно обрезают разделы, чтение должно быть быстрым слишком.

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

person Strahd_za    schedule 05.11.2010