Друзья всем привет!
Занимаюсь разработкой ПО для анализа и хранения данных от приборов ГЛОНАСС навигации.
Сразу скажу, что с проектированием ДБ я раньше не сталкивался, и в этом деле являюсь абсолютным профаном.
Однако, есть потребность в хранении и оперативном извлечении (по необходимости) большого количества строк.
В сутки приходит порядка 3млн строк, которые нужно хранить в течении 90-366 дней (требование заказчика).

На данный момент база вертится на MSSQL, все валится в одну таблицу, индексы создаются в момент записи строки.
Однако данные которые хранятся более месяца - занимают очень больше время при выборке (что кстати блокирует базу и не дает записывать новые данные в любые таблицы).
Каким образом можно ускорить выборку данных, учитывая что индексация проводится в соответствии с выборочными запросами.
Поможет ли разбитие базы на несколько таблиц вместо одной, (например: каждый день новая таблица, примерным размеров в 3млн записей.. вместо одной таблицы в 300млн) а затем выборка с использованием UNION?
Может быть переехать на другую СУБД, более приспособленную к большим объемам?

PS
Друзья, как я уже говорил выше - я только пытаюсь разобраться в этом деле, и если бы у меня был хороший запас по времени, то я обязательно бы почитал мануалы и ознакомился с горами литературы. Но в связи ограниченностью нашего бренного пребывания на земле - очень прошу обойтись без нравоучений и устроить настоящий обмен опытом, а не "браваду бывалого СУБДшника над неопытным новичком"!

PSS
Поиск на форуме ситуации копирующей мою - к положительным результатам не привели, ссылки на темы (если аналоги есть) приветствуются!

Infernal V. Raven,

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

Бредятина,

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

SERG1257,

К сожалению, переписки на форумах я опыта не шибко имею, поэтому за отсутствие цитирования и другие мелочи - извеняйте)))

СУБД MSSQL 11.0.2100.60 (win2008, x64)
Создание таблицы

CREATE TABLE [dbo].[History] (
[ID] int NOT NULL ,
[AT_NUM] bigint NULL ,
[AT_TIME] int NULL ,
[SV_TIME] int NULL ,
[AT_SPEED] int NULL ,
[AT_VECTOR] int NULL ,
[AT_POSITION] int NULL ,
[AT_ONFINAL] int NULL ,
[AT_ONROUTE] int NULL ,
[ROUTE_ID] int NULL ,
[LASTSTATETIME] int NULL ,
[ONSTATEBY] int NULL ,
[AT_COORD_X] float NULL ,
[AT_COORD_Y] float NULL ,
[AT_ONFIANL_WAS] int NULL ,
[AT_ONROUTE_WAS] int NULL ,
[AT_STOP_ID] int NULL ,
PRIMARY KEY ([ID])
)
GO

Вставляю стандартно командой INSERT, отправляю команды пачками (т.е. по 30-35 за обращение к СУБД) - раз в секунду.

INSERT INTO History(AT_NUM,AT_TIME,SV_TIME,AT_SPEED,AT_VECTOR,AT_POSITION,AT_ONFINAL,AT_ONROUTE,ROUTE_ID,LASTSTATETIME,ONSTATEBY,AT_COORD_X,AT_COORD_Y,AT_ONFINAL_WAS,AT_ONROUTE_WAS,AT_STOP_ID) VALUES(...)

Поля в History заполняются все, за исключением поля AT_STOP_ID - оно по необходимости.

По поводу индексации - её я провел в соответствии с советами утилиты Managment Studio - при стандартных выборках, например:

SELECT * FROM History WHERE (SV_TIME >= Начальное время отчета в UNIX_TIME AND SV_TIME <= Конечное время отчета в UNIX_TIME) AND (AT_COORD_X != 0.0) AND (AT_COORD_Y != 0.0) AND (ROUTE_ID = ИД Маршрута) AND (AT_ONFINAL_WAS = 1) AND (AT_ONFINAL = 0)


Пик запросов SELECT совпадает с пиком запросов INSERT и приходится на время с 7:00 до 23:00 часов дня, после 0:00 запросы SELECT отсутствуют, а INSERT падает раз в 5-8.

По мимо таблицы History, есть ещё несколько таблиц в которых храниться от силы 10-20 тысяч строк... При выборки из таблицы History (особенно за даты в далеком прошлом) - малые таблицы не доступны, да и база в целом не отвечает...

ПЕНСИОНЕРКА,

Обычно запросы SELECT делаются в рамках 1го дня, и редко когда захватывают 2 дня и более.
Отсюда я подумал, что если делить информацию по таблицам опираясь на дни, при запросе нужно будет лопатить не таблицу размером >300млн записей, а всего 3млн.

SERG1257,

по такому типу:
insert () values
...
insert () values
go


Индексы:

CREATE UNIQUE INDEX [ID] ON [dbo].[History]
([ID] ASC)
ON [PRIMARY]
GO

CREATE INDEX [SELECT_FINAL] ON [dbo].[History]
([AT_ONFINAL] ASC, [ROUTE_ID] ASC, [AT_ONFINAL_WAS] ASC, [SV_TIME] ASC, [AT_COORD_X] ASC, [AT_COORD_Y] ASC)
INCLUDE ([ID], [AT_NUM], [AT_TIME], [AT_SPEED], [AT_VECTOR], [AT_POSITION], [AT_ONROUTE], [LASTSTATETIME], [ONSTATEBY], [AT_ONROUTE_WAS], [AT_STOP_ID])
ON [PRIMARY]
GO

CREATE INDEX [SELECT_CAR] ON [dbo].[History]
([AT_NUM] ASC, [ROUTE_ID] ASC, [SV_TIME] ASC, [AT_COORD_X] ASC, [AT_COORD_Y] ASC)
INCLUDE ([ID], [AT_TIME], [AT_SPEED], [AT_VECTOR], [AT_POSITION], [AT_ONFINAL], [AT_ONROUTE], [LASTSTATETIME], [ONSTATEBY], [AT_ONFINAL_WAS], [AT_ONROUTE_WAS], [AT_STOP_ID])
ON [PRIMARY]
GO

CREATE INDEX [SELECT_ROUND] ON [dbo].[History]
([ROUTE_ID] ASC, [SV_TIME] ASC, [AT_COORD_X] ASC, [AT_COORD_Y] ASC)
INCLUDE ([ID], [AT_NUM], [AT_TIME], [AT_SPEED], [AT_VECTOR], [AT_POSITION], [AT_ONFINAL], [AT_ONROUTE], [LASTSTATETIME], [ONSTATEBY], [AT_ONFINAL_WAS], [AT_ONROUTE_WAS], [AT_STOP_ID])
ON [PRIMARY]
GO

В зависимости от запроса - разные поля индексированны.


Сейчас исправлю на:
CREATE UNIQUE INDEX [ID] ON [dbo].[History]
([ID] ASC, [SV_TIME] ASC)
ON [PRIMARY]
GO

1001,

Ну например я если сегодня сделаю выборку за 1 мая, от она будет делаться продолжительное время... >1мин.
В момент обработки выборки другие таблицы не открываются, а если и открываются то с очень большим таймингом!

Dimitry Sibiryakov,

Нене, все запросы индексы уже созданы, просто я их создавал на основании того, что советовал Managment Studio для увеличения производительности запроса

ChA,

По индексу ID - согласен.
А по индексам указанным выше - такие индексы советует анализатор запроса в Mstudio, в этих индексах указанны те данные, которые используются в запросе SELECT. Без такой индексации выборка занимает около 12 минут, а при наличии индексации - 40 секунд (первый раз), а из кеша - моментально...

Мне кажется, если есть способ постоянно держать индексы по всей базе в кеше - то это шанс значительно ускорить работу ДБ!
Останется решить задачу с чисткой базы, т.к. при нынешней скорости на очистку порядка 100млн записей из базы - не хватает ночи...