Реляционные БД: пригодны ли для такого?

Marinavo_0507

CREATE TABLE `ip_traffic` (

  `id` bigint(20) NOT NULL,

  `client` int(11) default NULL,

  `class` smallint(6) default NULL,

  `bytes` bigint(20) default NULL,

  `time` bigint(20) default NULL,

  PRIMARY KEY  (`id`

  KEY `i_time` (`time`,`client`

  KEY `i_class` (`class`,`time`

  KEY `i_client_time` (`client`,`time`

  KEY `i_cct` (`client`,`class`,`time`)

)

Marikun

Вопрос: может ли переход на другую реляционную БД сильно улучшить ситуацию,
если да, то как примерно эта другая СУБД добьётся увеличения скорости:

gopnik1994

Marikun

MySQL, афаик, показывает одну из лучших производительностей на больших базах.

gopnik1994

Marikun

Marinavo_0507

stm7884696

gopnik1994

ava3443

gopnik1994

Marinavo_0507

Hastya

Marikun

Фактически, отдельная база для таких запросов?
Тогда будет проще отказаться от реляционных баз и сделать что-то специализированное,
благо все типы запросов, которые нужно выполнять быстро, известны заранее.

TYU_2008

Marinavo_0507

Marikun

а че это за хранилище такое OLAP вообще?

Где можно это поботать

Marikun

Многие делают. Мне тут недавно рассказывали, что биллинг то ли Билайна, то ли Мегафона использует специализированную базу.

Ivan826

TYU_2008

TYU_2008

Marikun

Мегафон сидит на постгресе

otvertka07

sergey_m

Агрегирование сделать легко, даже в реальном времени если понадобится. Тогда таблицы станут маленькими.
Я собственно так и собираюсь сделать.

SvinkaVJeansah

daru

А смена реляционной бд мало на что повлияет: та же беспорядочность в хранении строк - по сути заложена в спецификации sql.

voronetskaya

тут точно все правильно написано?:
сократить время построения аналитического отчета за счёт увеличения времени

ava3443

daru

teonazoi

ava3443

bastii

voronetskaya

daru

SvinkaVJeansah

А насчёт "беспорядочности в хранении строк" она может и "заложена в спецификации sql", но кроме спецификации есть еще и реализация.

SvinkaVJeansah

Есть простейшая схема подсчёта трафика.
Данные о трафике закладываются примерно в такую таблицу:
code:
CREATE TABLE `ip_traffic` (
`id` bigint(20) NOT NULL,
`client` int(11) default NULL,
`class` smallint(6) default NULL,
`bytes` bigint(20) default NULL,
`time` bigint(20) default NULL,
PRIMARY KEY (`id`
KEY `i_time` (`time`,`client`
KEY `i_class` (`class`,`time`
KEY `i_client_time` (`client`,`time`
KEY `i_cct` (`client`,`class`,`time`)
)
Оно есть, и в целом неплохо работает.
Для каждого типичного вида запросов создано по индексу.
За несколько месяцев накапливается несколько гигабайт данных - в несколько раз больше объёма оперативной памяти на сервере.
Если пытаться складывать в таблицу более детальную информацию, данных будет ещё больше.
Проблема в том, что запросы, которым нужно перелопатить ну скажем несколько сот тысяч строк,
выполняются медленно.
Например, отчёт по месяцам, по трафику конкретного клиента - нужно, используя ключ `i_client_time`,
выбрать данные (их относительно немного, скажем около 1/1000 от всех строк и их немного обработать.
Но это делается несколько минут.
Как я понимаю, это происходит потому, что нужные строки разбросаны по всей таблице,
и нужно много операций чтения с диска, с позиционированием головки для каждой.
Используется MySQL.
Вопрос: может ли переход на другую реляционную БД сильно улучшить ситуацию,
если да, то как примерно эта другая СУБД добьётся увеличения скорости:
нужно ведь хранить данные так, чтобы для каждого индекса строчки хранились примерно в нужном порядке,
IMHO без дублирования тут не обойтись?

 mysql> describe raw;

+--------+------------+------+-----+-------------------+-------+

| Field  | Type       | Null | Key | Default           | Extra |

+--------+------------+------+-----+-------------------+-------+

| id     | bigint(20) |      | PRI | 0                 |       |

| data   | bigint(20) |      |     | 0                 |       |

| stamp  | timestamp  | YES  | PRI | CURRENT_TIMESTAMP |       |

| reload | bigint(20) | YES  |     | NULL              |       |

+--------+------------+------+-----+-------------------+-------+

4 rows in set (0.02 sec)



mysql> describe counters;

+-----------+------------------+------+-----+---------+----------------+

| Field     | Type             | Null | Key | Default | Extra          |

+-----------+------------------+------+-----+---------+----------------+

| id        | bigint(20)       |      | PRI | NULL    | auto_increment |

| name      | char(255)        | YES  |     | NULL    |                |

| alias     | char(255)        | YES  |     | NULL    |                |

| rule      | int(11)          |      |     | 0       |                |

| rule_body | char(255)        |      |     |         |                |

| dir       | enum('in','out') |      |     | in      |                |

+-----------+------------------+------+-----+---------+----------------+

6 rows in set (0.00 sec) 

SvinkaVJeansah

daru

SQL не гарантирует хранение строк в каком-либо определенном порядке, посему завязывать на какие-то тонкости конкретной реализации более-менее серьезный проект не стоит.проект

SvinkaVJeansah

Marinavo_0507

        SELECT FROM_UNIXTIME(time, '%Y/%m') as Month, class, sum(bytes) as B

        FROM ip_traffic

        WHERE client=$client AND time>=UNIX_TIMESTAMP($start_time)

        GROUP BY Month, class

SvinkaVJeansah