Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Большие объемы данных / 24 сообщений из 24, страница 1 из 1
19.09.2002, 11:01:15
    #32051565
Тромбола Евгений
Тромбола Евгений
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Привет всем. Есть большая проблема !!!

В базе около 70 млн записей (в одной тбл.) и будет расти. По этой таблице необходимо выполнить группировку по 3 полям, по 4 суммировать, 1 поле выступает ввиде ограничения (дата), стандартным (самым простым) запросом данная операция выполняется очень долго.

ВОПРОС: подскажите, если есть, другой вариант.

Принимаются любые варианты.

Спасибо за помощь.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.09.2002, 11:08:54
    #32051569
dao
dao
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
А индексы настроены?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.09.2002, 11:16:27
    #32051577
ziktuw
ziktuw
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Можно существенно ускорить, если держать предпосчитанные агрегаты в другой таблице за период, в котором нет изменений ("закрытый период")
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.09.2002, 11:26:50
    #32051584
dao
dao
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
И наверное без бизнес-правил по которым работает селект ничего нельзя сказать про оптимизацию - по "голому" sql - нельзя (если всё индексы настроены правильно)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.09.2002, 11:31:47
    #32051589
Тромбола Евгений
Тромбола Евгений
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Индексы настроены...
Держать данные уже агрегированые нельзя, так как период не закрывается (это статистические данные), и я не знаю за какой период могут выбрать :(
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.09.2002, 11:44:37
    #32051603
Jimmy
Jimmy
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Если это - статистика, то вероятно допускаются некие отклонения, которые не скрывают выявляемых тенденций. Поэтому, возможно допустимо использование агрегатов, например, недельных. Таким образом, отклонение от заданной даты может быть не более 3 дней.
А при этом объем обрабатываемых данных снизится в 7 раз.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.09.2002, 13:07:39
    #32051648
akuz
akuz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Надо начать с постановки задачи.

Вопрос - зачем вам нужна эта выборка?

Если это еженедельный отчёт - это одно, если это оперативный запрос выполняемый каждые 5 мин. - это совсем другое.

Как я понял это статистические данные, соответственно, данные "за вчера" не меняются. А почему не использовать OLAP Services?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.09.2002, 14:10:25
    #32051672
Алексей Кубенко
Алексей Кубенко
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
А все же интересно было бы взглянуть на структуру таблицы и индексы, прежде чем что-то обсуждать? И хотелось бы знать 70 млн. данных за какой период и какие в среднем интервалы ограничения по дате при выполнении запросов.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.09.2002, 17:15:26
    #32051750
av_2000
av_2000
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Для этого служит OLAP - сервер
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2002, 11:08:30
    #32051862
Тромбола Евгений
Тромбола Евгений
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
1. Это оперативный отчет.
2. Стуктура тбл.
FilID int 4 0 *
ChequeID int 4 0 *
RasfID int 4 0 *
Kolvo numeric 5 0
PriceOUT numeric 5 1
PriceZal numeric 5 1
PriceIN real 4 1
NDS tinyint 1 1
(*-уникальный ключ)

3. Данные не меняются в "закрытом" периоде, устанавливается гл. бух.
4. Данные за 6 мес. по 13 фил., поступают каждый день
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2002, 12:28:30
    #32051902
akuz
akuz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
1. Это оперативный отчет.
Обычно для оперативного учёта интересны лишь данные за последний открытый период. Попробуйте сделать как в стандартном бухгалтерском отчёте "Оборотно-сальдовая ведомость" - сальдо на начало, оборот за период, сальдо на конец.
2. Стуктура тбл.
FilID int 4 0 *
ChequeID int 4 0 *
RasfID int 4 0 *
Kolvo numeric 5 0
PriceOUT numeric 5 1
PriceZal numeric 5 1
PriceIN real 4 1
NDS tinyint 1 1
(*-уникальный ключ)
FilID - филиал?
ChequeID - код операции?
RasfID - ???
Kolvo - кол-во, которое суммируется?
Не вижу поля для выборки даты, видимо в связ. таблице Cheques
3. Данные не меняются в "закрытом" периоде, устанавливается гл. бух.
Значит расчитанные агрегаты т.е. сальдо на начало периода хранить можно.
4. Данные за 6 мес. по 13 фил., поступают каждый день
Ежедневные поступления влияют лишь на оборот за период и конечное сальдо. Начальное же сальдо от этого не меняется.
Если это правильная постановка, подскажу решение, если нет, поправьте.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.09.2002, 17:25:58
    #32052178
Тромбола Евгений
Тромбола Евгений
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Сформулирую задачу.

Необходимо получить вытогр по кассам по определенному филиалу (или нескольким филиалам) за определенный период по конкретному товару (или группе товаров) с конкретным типом (наличка, безнал, дисконт и т.д.).

Условия задает конкретный пользователь (пользователей около 30).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.09.2002, 13:26:30
    #32052203
akuz
akuz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Создаётся дополнительная таблица <results>, в которой при закрытии периода сохраняются результаты суммирования по группирующим полям, где вместо конкретных дат стоит дата закрытия периода (она же - дата подсчёта результатов). Т.е. в вашем случае ключевыми полями будут: филиал, товар, тип операции.
Запрос выглядит примерно так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select top  1  @date_from = close_date from results where close_date <= @date_from order by close_date desc
select sum(r.quantity_sum) + sum(isnull(o.quantity, 0 ))
from results r
  left join operative o on r.group_field1 = o.group_field1
    and r.group_field2 = o.group_field2
    and o.date <= @date_to
    and o.date > @date_from
where r.close_date = @date_from
group by r.group_field1

Т.е. берём вычисленные результаты из таблицы результатов по последней дате закрытия периода, ближайшей к начальной дате условия и складываем с вычисленными значениями из открытого периода.
При таком подходе выборка будет происходить лишь из открытого периода, т.е. не из 70 млн., а всего лишь из 1 млн.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.09.2002, 16:52:43
    #32053774
Igor Pi
Igor Pi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
А почему нельзя начать с того, чтобы разбить одну таблицу на филиалы?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.09.2002, 16:58:28
    #32053777
Igor Pi
Igor Pi
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Если разбить таблицу по филиалам, то (надеюсь!) размер каждой таблицы резко сократится. Вы сможете (надесь!) положить их на разные диски - и по вводу/выводу Вы их развяжете. Купите многопроцессорный сервер - развяжете и по процессорной мощности, что для оперативной работы тоже хорошо. Это уже на 7.0.

А на 2000 можно (теоретически, если Вы - разработчик системы) разнести эти таблицы на разные компьютеры и связать их. Теоретически это еще лучше. Впрочем, Ваш вопрос относится именно к таблице, а не к системе с большой таблицей, так что все в Ваших силах.

А, кстати, где Ваша таблица хранится? Не на IDE диске 5400 об/сек.? И сколько ОЗУ на сервере?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.09.2002, 11:59:39
    #32053871
Тромбола Евгений
Тромбола Евгений
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Разнести тбл. по филиалам, не катит так как до нового года их будет около 100, и если необходимо получить данные по нескольким филиалам одновременно, будет еще хуже из-за объединения этих таблиц.

akuz: спасибо за идею, только я ее чуток изменил.
1. Создается тбл., в которой хранятся агрегированные данные (т.е. каждый день (закрытый период 1 день) хранит суммарные данные за все предыдущие+данные самого себя)
2. Вычисление продаж за любой период сводится к вычислению разницы между начальной датой периода и конечной.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.09.2002, 12:18:01
    #32053875
Breakneck
Breakneck
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Идея разбиения таблицы по филиалам неплоха. Можно (в свете сказанного Евгением) пойти дальше - разбить таблицы по группам филиалов. Это будет экономичнее. Группировку можно делать как территориальному, так и по организационному признаку, например.
А насчет долгого join нескольких таблиц с филиалами - это зря, как мне кажется. Рано или поздно при увеличении количества данных в одной общей таблице затраты на select превысят затраты на join.
Мне кажется одним из лучших решений все-таки группировка филиалов.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.09.2002, 12:39:36
    #32053877
SiDen
SiDen
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Как на счет разбития данных по месяцам?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.09.2002, 13:25:24
    #32053883
Breakneck
Breakneck
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
2 SiDen: разбитие данных по месяцамм случае крайне невыгодно. Если неоходимо будет выбрать данные за все периоды или за год хотя бы, уже получится такой навороченный join, что серверу мало не покажется и скорость выборки будет приближаться к черепашьей...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.09.2002, 13:27:42
    #32053884
Breakneck
Breakneck
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
сорри, глюк. Читать первую фразу как "разбитие данных по месяцам в данном случае..."
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.09.2002, 17:26:33
    #32054154
Garya
GaryaПривилегированный пользователь
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
По месяцам можно, если :
1. На каждую таблицу навесить по дате констрейнт check.
2. Скрипт с union генерить динамически на клиенте, а не использовать SP с параметром.
Тогда при select .... where Period beetwen ... обращение будет только в те таблицы, в которых эти периоды на самом деле есть.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.10.2002, 02:22:51
    #32054229
andreym999
andreym999
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Предлагаю следующий вариант:
Делается таблица промежуточных результатов.
Ночью запускается скрипт который полностью выполняет все группировки и суммирования
На таблицу вешается триггер который в зависимости от вставляемых данных ( можно написать умный триггер )будет при добавлении или изменении апдейтить таблицу результатов в зависимости от операции.
В результате мы очень быстро строим выборки, быстродействия от такого триггера я думаю не упадет если его ограничить (например в текущем дне не работает и.т.п.)

По ночам опять же запустится скрипт который все подверит и построит новую промежуточную таблицу.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.10.2002, 11:26:26
    #32055422
Тромбола Евгений
Тромбола Евгений
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Спасибо всем откликнувшимся...
Вариант который я предложил, работает и работает быстро (выбока 1 товара по всем филиалам ~1c, выборка всех товаров по всем филиалам ~7-10c., обе выборки за 6мес.)вне зависимости от размера(длины) периода (проверялось на искуственно увеличенной до 250 млн таблице).
Но хотелесь бы все-таки по подробнее про разнесенные по филиалам тбл., мне какжется что это не даст большого выиграша, в связи с тем что придется делать UNION этих таблиц, это раз, и второе, усложняется формулировка условия выборки, так как для каждого филиала(имеется ввиду таблица) придется создавать свое условие.
Если я не прав, попробуйте мне это объяснить.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.10.2002, 11:43:14
    #32055431
dkstranger
dkstranger
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие объемы данных
Мы решаем проблему очень просто ..

1. Все чтение данных идет не через select,
а через ХП /можно view/

2. Данные прошедших периодов архивируются
в отдельные таблицы /по прошлым годам -
даже в другие базы и сервера :)/

3. Пользователь обращается к 1, даже не зная,
откуда он получит данные :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Большие объемы данных / 24 сообщений из 24, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 397ms
Закрыть
start [/forum/topic.php?fid=46&mobile=1&tid=1819857]:
 0ms
get settings:
 8ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 45ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 67ms
get tp. blocked users:
 1ms
others: 241ms
total:  397ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]