MYSQL и скорость выборки

ммм... ну собственно 10М записей - это более чем по-божески для MySQL. естественно, если это не full text search или поиск по blob-ам, если аккуратно расставлены индексы и таблицу не лочат постоянно какими-то другими запросами.

// wbr

да мне что то кажется что там больше 10М должно быть, поскольку мой вариант за месяц соберёт примерно 14М записей (прикидка), а в netflow analayzer'е однозначно mysql, проверял.

ну дык структуру таблицы в студию

> да мне что то кажется что там больше 10М должно быть, поскольку мой вариант за месяц соберёт примерно 14М записей (прикидка), а в netflow analayzer'е однозначно mysql, проверял.

10-14 - не велика разница. ты лучше покажи что ты делаешь со своими выборками. что там в nfa происходит одному черту известно.

// wbr

> ну дык структуру таблицы в студию

show columns from fbnetflow_2417600704_1;
+---------+---------------------+------+-----+---------+-------+
| Field   | Type                | Null | Key | Default | Extra |
+---------+---------------------+------+-----+---------+-------+
| time    | bigint(20) unsigned | YES  |     | NULL    |       | 
| src     | bigint(20) unsigned | YES  |     | NULL    |       | 
| dst     | bigint(20) unsigned | YES  |     | NULL    |       | 
| nexthop | bigint(20) unsigned | YES  |     | NULL    |       | 
| dpkts   | bigint(20)          | YES  |     | NULL    |       | 
| doctets | bigint(20)          | YES  |     | NULL    |       | 
| input   | int(11)             | YES  |     | NULL    |       | 
| output  | int(11)             | YES  |     | NULL    |       | 
| first   | bigint(20)          | YES  |     | NULL    |       | 
| last    | bigint(20)          | YES  |     | NULL    |       | 
| dstport | int(11)             | YES  |     | NULL    |       | 
| srcport | int(11)             | YES  |     | NULL    |       | 
| prot    | int(11)             | YES  |     | NULL    |       | 
+---------+---------------------+------+-----+---------+-------+
13 rows in set (0.06 sec)

если дело может быть в индексах, то вопрос такой, как в этой таблице можно раскидать индексы?

> 10-14 - не велика разница. ты лучше покажи что ты делаешь со своими выборками. что там в nfa происходит одному черту известно. 

сами потоки агрегируются внутри моей софтины за период в 10 минут, затем пишутся в таблицу, далее просто идёт выборка по дате, с суммирование doctets и dpkts, плюс отдельная выборка может быть по dstport или srcport или по src и dst, могут быть комбинации

и много там таких табличек , в смысле с такими подозрительными названиями? :]

> и много там таких табличек , в смысле с такими подозрительными названиями? :]

Ну тут ничего подозрительного ))))

fbnetflow_2417600704_1:

2417600704 - адрес источника потока

1 - индекс (при заполнении таблицы 500000 строк, создаётся новая таблица с увеличиным на 1 индексом, т.е. в данном случае у новой таблицы будет индекс равный 2)

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

> если дело может быть в индексах, то вопрос такой, как в этой таблице можно раскидать индексы?

расстановка индексов в 1ю по 10ю очередь зависит то того, какие собственно делаются запросы в эту табличку. сами по себе индексы не есть абсолютное добро и спасение от всех болезней.

// wbr

ну в общем и целом, я бы посоветовал топикастеру заглянуть в книжечке "MySQL Developer's Library", 4е издание. там освещены многие вопросы включая организацию базы данных, кто такие индексы и с чем их едят и прочее и прочее. есть в осле.

// wbr

> 1 - индекс (при заполнении таблицы 500000 строк, создаётся новая таблица с увеличиным на 1 индексом, т.е. в данном случае у новой таблицы будет индекс равный 2)

И в чем тогда вопрос? 500000 - вообще не объем.

не, ты лучше show create покажи.

fbnetflow_2417600704_1 | CREATE TABLE `fbnetflow_2417600704_1` (
  `time` bigint(20) unsigned default NULL,
  `src` bigint(20) unsigned default NULL,
  `dst` bigint(20) unsigned default NULL,
  `nexthop` bigint(20) unsigned default NULL,
  `dpkts` bigint(20) default NULL,
  `doctets` bigint(20) default NULL,
  `input` int(11) default NULL,
  `output` int(11) default NULL,
  `first` bigint(20) default NULL,
  `last` bigint(20) default NULL,
  `dstport` int(11) default NULL,
  `srcport` int(11) default NULL,
  `prot` int(11) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1

> И в чем тогда вопрос? 500000 - вообще не объем.

это если выбирать придёться в пределе одной двух таблиц, а если придёться захватить 10 или 20 таких таблиц...

> ..захватить..
...выбирать из...

обычно, белые люди by default добавляют ещё индекс a'la

CREATE TABLE `fbnetflow_2417600704_1` (
    `id` SERIAL,
    `time` bigint(20) unsigned default NULL,
....

угадайте, зачем :)

// wbr

ну здесь похоже из-за грамотного распределения по табличкам вырастает скорость, без индексов с 14к записями такая скорость маловероятна. Ну может там еще кэши какие и прочее

> ну здесь похоже из-за грамотного распределения по табличкам вырастает скорость, без индексов с 14к записями такая скорость маловероятна. Ну может там еще кэши какие и прочее

ммм.. если ты про топикастера, то у него вообще нет индексов. со всеми вытекающими :) если про софтину, на которую он ссылается - там, уверен, есть и индексы и ручное разбиение на партиции и тд и тп. так что работа с миллионами или десятками миллионов записей - это совсем не проблема.

моё же замечание про [обязательное] добавление id - это отнюдь не для ускорения. это скорее, для 'навигации'.

// wbr

> моё же замечание про [обязательное] добавление id - это отнюдь не для ускорения. это скорее, для 'навигации'.

ну уникальное поле должно быть в любом случае

> ну уникальное поле должно быть в любом случае

да это понятно и индексы то же, это пока набросок и просто интересно что ещё можно сделать

> да это понятно и индексы то же, это пока набросок и просто интересно что ещё можно сделать

Сфинкс/мемкэшд, лучше вообще минимизировать работу с СУБД.