Select/where/group by на 100m-200m таблицах?

Question

[vittore]

Ощущение что я упускаю что то с noSql решениями, коментарии приветствуются


Есть табличка с 100-200 миллионов записей, сортированные по времени на которой хочется быстро выполнять запросы вида

select time, field, sum(field2) 
from t inner join t2 on ...
where field3 = x and field  = y 
and time between time1 and time2
group by time, field 
order by time

сейчас все это живет на одном сервере, на sql server и проблема в том что индексы к этой таблице занимают столько же места сколько данные.


Какие noSql решения хорошо подойдут для такой задачи? я пока успел посмотреть только на CoachDb — на вид не взлетит

Answer 1

[shagguboy]

Я к тому что такие задачи решаются гораздо проще просто доп-таблицей (field, sum_cache) и обновлением на основе триггеров или самостоятельно

матвью это называется.

Comments

[vittore]

в sql server это то что CREATE VIEW [myView] WITH SCHEMABINDING…?

Answer 2

[edogs]

Ответ не совсем в тему.
Но поскольку запрос у Вас как бы совсем не noSQL-ный, и индексы занимают много места… возможно есть смысл или тупо округлить время до минут (индексы сразу займут раз в 60 меньше места), или ввести доп. поле с временем округленным до минут (таблица подраздуется, но индексы будут меньше).

Answer 3

[rPman]

Меняется ли sum(field2) для каждого field и как часто? Критично ли скорость его записи?
Если быть более точным, изменяется ли поле field2? или только добавляются и удаляются новые записи?

Я к тому что такие задачи решаются гораздо проще просто доп-таблицей (field, sum_cache) и обновлением на основе триггеров или самостоятельно… кстати на сколько я знаю есть БД поддерживающие кеш-индексы на основе выражений (фактически они и создают поле и наполняют его триггерами)

Comments

[vittore]

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

[rPman]

да почти все — postgresql, oracle,…

Только не уверен по поводу производительности на запрос данных из такого индекса, так как обычно они подразумевают использование индексированных выражений в where, group by и order by.

Если запись только добавление, то как написал выше — новую кеш-таблицу и обновляйте ее индексом — при добавлении записи (set sum_field2+=field2), при удалении соответственно (set sum_field2-=field2).

Answer 4

[shagguboy]

покрывающий кластерный индекс вас спасет.

Comments

[vittore]

А где почитать как его лучше задать?

Answer 5

[shagguboy]

msdn.microsoft.com/en-us/library/dd171921%28v=sql.100%29.aspx

Comments

[vittore]

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

[shagguboy]

можно на Оракл, там матвью посолидней. можно на колоночные СУБД типа Sybase IQ

Answer 6

[shagguboy]

ну или если хотите совсем по взрослому сделайте ОЛАП куб и работайте с ним. В MS SQL ОЛАП идет бесплатно к серверу

Comments

[vittore]

кубы разве дадут большую скорость запросов?

[shagguboy]

вы будете смеяться но их придумали для этого.

[rPman]

А разве функционал кубов не реализуется поверх (с использованием) sql? я имею в виду как эти механизмы могут быть быстрее… тем более данная задача не очень то ложится на куб.

Answer 7

[kuzemchik]

Кубы нужны для многомерных срезов, у них есть собственный кеш, который обновляется sql-запросами. Если field-ов по которым вы группируете много разных — то куб будет полезен.
Если нет, то, мне кажется, вам лучше подойдет Partitioning таблицы.

Comments

[vittore]

нам бы точно подошел партишининг таблиц, проблема только в том что он доступен в Sql Server Enterprise, а это очень дорого, вы не знаете у кого еще есть такой же удобный партишининг?

[kuzemchik]

У нас Postgres, он медленней, чем Sql Server, но зато бесплатный и имеет enterprise фичи.