Форум пользователей MySQL

Не, табличка InnoDB.

Впрочем, тебе разве нужны все несколько тысяч? LIMIT нужно хвостиком сделать.

К сожалению, задача ставится так, что именно все несколько тысяч

Перечитал темы про организацию логов, да и другие некоторые. Хочу поделиться размышлениями.

I. MERGE/VIEW не подходит по следующим причинам:

1. Нужна уникальность ключа (даже нескольких, на самом деле). Я так понимаю, нормальных средств, позволяющих поддерживать уникальность на всем пространстве MERGE, не имеется.

2. С MERGE медленнее чтение по ключу. А чтение тоже периодически случается, причем иногда - по всей таблице (заказчик захотел динамическую статистику за сутки; в основном, конечно, данные добавляются и удаляются кусками, но встречаются и такие запросы, которые приходится делать на всю таблицу)

3. Все-таки в таблицу десятки инсертов в секунду. Несколько раз в минуту бывают и селекты. Как-то страшновато использовать MyISAM в таких условиях имхо.. (хотя лочиться будет только последняя таблица, все же не круто..)

II. Partitioning.

Основной вопрос здесь такой: как влияет paritioning на поиск по остальным ключам (кроме того, по которому разбиение)?
У меня часто задействуются другие ключи. Не будет ли там ситуации, такой же, как в MERGE, когда надо подряд все ключи во всех разделах обыскивать?

III. Еще вот такая идея: а что, если эту всю таблицу загнать в память? (т.е. сделать ей ENGINE = MEMORY)?..
И, например, снять часть ключей?
Насколько поиск по неотсортированной памяти медленнее поиска по отсортированной памяти?

А поглядеть можно на базку как-то?

Милости просим (не хотел эфир просто засорять)
Соответственно, col_key - это siteid, col_data - это refhost.

CREATE TABLE `brevno_ext_sessions` (
  `id` bigint(10) unsigned NOT NULL auto_increment,
  `siteid` int(10) unsigned NOT NULL,
  `uuid` char(36) NOT NULL,
  `DATE` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
  `useragent` varchar(255) NOT NULL,
  `refhost` varchar(255) NOT NULL,
  `refuri` varchar(2048) NOT NULL,
  `GET` varchar(2048) NOT NULL default '',
  PRIMARY KEY  (`id`),
  KEY `uuid` (`uuid`),
  KEY `DATE` (`DATE`),
  KEY `siteid` (`siteid`)
) ENGINE=InnoDB AUTO_INCREMENT=5543800 DEFAULT CHARSET=latin1

Это сессии нескольких тысяч маленьких сайтов за сутки (т.е. записей где-то один-два миллиона; потом будет побольше).

Запрос вида SELECT refhost FROM brevno_ext_sessions WHERE siteid = N как раз и занимает полминуты.

(еще там вторая есть тоже большая, насчет неё уже жаловался:
http://sqlinfo.ru/forum/viewtopic.php?id=1316
так что если будет дежа вю - не удивляйся )

И еще вопрос. У тебя табличка 10кк строк, insertы по 10rps, т.е. всей таблице
2 недели жизни. А что с ней будет через 2 месяца? Или там что-то еще ее
меняет?

Каждую минуту запускается скрипт и удаляет записи так, чтобы оставались только за последние сутки.

Уууу! Много независимых мыслей:

Считай, что это MERGE с возможностью PRUNING. Это очень близко к действительности.

По поводу запроса — я думал, что по site у тебя по крайней мере PK стоит Когда ты
делаешь SELECT siteid FROM brevno_ext_sessions WHERE siteid = 1 — у тебя работает
USING INDEX, более того, ему достаточно посчитать количество строк по индексу.
Когда ты тянешь данные, ему нужно сделать куда больше работы — найти по индексу
PK соответствующий, а по нему уже вытащить данные. Подозреваю, что «короткий»
запрос читает с диска 1-2 страницы последовательно (т.к. сортирован), а «длинный»
хорошо и жестко бегает в поисках этих 1000 страниц данных.

В MEMORY эта хреновина не влезет (см на varchar(2048) несколько раз).

Если uuid — это md5, то binary(16) гораздо лучше, чем char(36).

Подозреваю, что все запросы у тебя все-таки per-site, попробуй покластеризовать по
HASH(siteid) с каким-нибудь невменяемым количеством кусков типа 1000.

А кто вообще придумал хранить независимые данные по тысячам сайтов в одной табличке?

Кстати. Мне тут пришла мысль: всё, что мы тут обсуждали - это, конечно, хорошо, полезно и интересно
Но че-то мы отошли от проблемы. Мне ведь нужно вытащить строковую колонку, которая не в ключе. По-моему, partitioning мне бы тут не помог, т.к. у меня медленная стадия - не поиск по ключу, а выбор данных с диска, который будет так же медленной происходить, как и для обычной таблицы.
(или нет?)

Вчера вечером также подумал, что, возможно, замета PK с id на (site_id, uuid)
(+ выкинуть id + выкинуть ключ по uuid + переписать запросы так, чтобы везде
работал site_id) значительно улучшит работу таблицы. Не смотря на увеличение
размера PK.

Да, это идея хорошая. Учитывая, что я еще и uuid сделал BINARY(4) вместо CHAR(36) (60 символов, латинские буквы и цифры, могут дать 12 млн. комбинаций; учитвая, что сессия живет сутки и проверяется отдельно для каждого siteid, вероятность пересечения ключа получается все равно оч. малая), а PK у меня был не 4 байта, а 8, то ваще намного лучше станет.
Только вот InnoDB все равно неявный PK создает ведь.. Имеет ли смысл удалять при этом явный, если он все равно создастся?

Че-то я затупил... PK - это ж необязательно autoincrement
Теперь все понятно

Честно говоря, не понял, чего ты собираешься добиться, но второй таблице явно не
хватает ключевых полей — sessionkey там должен быть

Я сдуру решил, что эти данные во второй таблице для чего-то нужны (судя по названию —
там хранятся данные сессии). Если их вытаскивать из таблицы не нужно (основываясь на
uid сессии), то никаких проблем, конечно, нету

В любом случае, тут будет какая-то доля эксперимента — будет ли так быстрее, или нет.

Да, очень неприятное ограничение. Но — можно пересобрать сервер с новым значением
Предлагаю 1а и 2 проверить самостоятельно. Я никаких проблем не вижу

Если вопрос разряда «стоит ли перекомпилировать» — нет, не стоит. Попробуй сначала на 1024.
Если будет прирост производительности, но недостаточный — тогда уже пересобирать.

Ресурс на обслуживание == лишние открытые таблицы (i.e. файлхэндлы). Не так много, чтобы было плохо :-)

Открываются все сразу, и закрываются все сразу.