Большие объемы данных / Microsoft SQL Server

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Большие объемы данных

24 сообщений из 24, страница 1 из 1

Большие объемы данных

#32051565

Тромбола Евгений

Гость

Привет всем. Есть большая проблема !!!

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

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

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

Спасибо за помощь.

...

Рейтинг:

0 / 0

19.09.2002, 11:01:15

| Ответить | Цитировать | Написать

Большие объемы данных

#32051569

dao

Участник

Откуда: Москва

Сообщения: 701

Рейтинг: 0 / 0

А индексы настроены?

...

Рейтинг:

0 / 0

19.09.2002, 11:08:54

| Ответить | Цитировать | Написать

Большие объемы данных

#32051577

ziktuw

Участник

Сообщения: 3 335

Рейтинг: 0 / 0

Можно существенно ускорить, если держать предпосчитанные агрегаты в другой таблице за период, в котором нет изменений ("закрытый период")

...

Рейтинг:

0 / 0

19.09.2002, 11:16:27

| Ответить | Цитировать | Написать

Большие объемы данных

#32051584

dao

Участник

Откуда: Москва

Сообщения: 701

Рейтинг: 0 / 0

И наверное без бизнес-правил по которым работает селект ничего нельзя сказать про оптимизацию - по "голому" sql - нельзя (если всё индексы настроены правильно)

...

Рейтинг:

0 / 0

19.09.2002, 11:26:50

| Ответить | Цитировать | Написать

Большие объемы данных

#32051589

Тромбола Евгений

Гость

Индексы настроены...
Держать данные уже агрегированые нельзя, так как период не закрывается (это статистические данные), и я не знаю за какой период могут выбрать :(

...

Рейтинг:

0 / 0

19.09.2002, 11:31:47

| Ответить | Цитировать | Написать

Большие объемы данных

#32051603

Jimmy

Участник

Откуда: г.Москва

Сообщения: 3 149

Рейтинг: 0 / 0

Если это - статистика, то вероятно допускаются некие отклонения, которые не скрывают выявляемых тенденций. Поэтому, возможно допустимо использование агрегатов, например, недельных. Таким образом, отклонение от заданной даты может быть не более 3 дней.
А при этом объем обрабатываемых данных снизится в 7 раз.

...

Рейтинг:

0 / 0

19.09.2002, 11:44:37

| Ответить | Цитировать | Написать

Большие объемы данных

#32051648

akuz

Участник

Откуда: инос - хуесос

Сообщения: 6 844

Рейтинг: 0 / 0

Надо начать с постановки задачи.

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

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

Как я понял это статистические данные, соответственно, данные "за вчера" не меняются. А почему не использовать OLAP Services?

...

Рейтинг:

0 / 0

19.09.2002, 13:07:39

| Ответить | Цитировать | Написать

Большие объемы данных

#32051672

Алексей Кубенко

Гость

А все же интересно было бы взглянуть на структуру таблицы и индексы, прежде чем что-то обсуждать? И хотелось бы знать 70 млн. данных за какой период и какие в среднем интервалы ограничения по дате при выполнении запросов.

...

Рейтинг:

0 / 0

19.09.2002, 14:10:25

| Ответить | Цитировать | Написать

Большие объемы данных

#32051750

av_2000

Участник

Откуда: Moscow

Сообщения: 22

Рейтинг: 0 / 0

Для этого служит OLAP - сервер

...

Рейтинг:

0 / 0

19.09.2002, 17:15:26

| Ответить | Цитировать | Написать

Большие объемы данных

#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, 11:08:30

| Ответить | Цитировать | Написать

Большие объемы данных

#32051902

akuz

Участник

Откуда: инос - хуесос

Сообщения: 6 844

Рейтинг: 0 / 0

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

20.09.2002, 12:28:30

| Ответить | Цитировать | Написать

Большие объемы данных

#32052178

Тромбола Евгений

Гость

Сформулирую задачу.

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

Условия задает конкретный пользователь (пользователей около 30).

...

Рейтинг:

0 / 0

21.09.2002, 17:25:58

| Ответить | Цитировать | Написать

Большие объемы данных

#32052203

akuz

Участник

Откуда: инос - хуесос

Сообщения: 6 844

Рейтинг: 0 / 0

Создаётся дополнительная таблица <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

22.09.2002, 13:26:30

| Ответить | Цитировать | Написать

Большие объемы данных

#32053774

Igor Pi

Гость

А почему нельзя начать с того, чтобы разбить одну таблицу на филиалы?

...

Рейтинг:

0 / 0

27.09.2002, 16:52:43

| Ответить | Цитировать | Написать

Большие объемы данных

#32053777

Igor Pi

Гость

Если разбить таблицу по филиалам, то (надеюсь!) размер каждой таблицы резко сократится. Вы сможете (надесь!) положить их на разные диски - и по вводу/выводу Вы их развяжете. Купите многопроцессорный сервер - развяжете и по процессорной мощности, что для оперативной работы тоже хорошо. Это уже на 7.0.

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

А, кстати, где Ваша таблица хранится? Не на IDE диске 5400 об/сек.? И сколько ОЗУ на сервере?

...

Рейтинг:

0 / 0

27.09.2002, 16:58:28

| Ответить | Цитировать | Написать

Большие объемы данных

#32053871

Тромбола Евгений

Гость

Разнести тбл. по филиалам, не катит так как до нового года их будет около 100, и если необходимо получить данные по нескольким филиалам одновременно, будет еще хуже из-за объединения этих таблиц.

akuz: спасибо за идею, только я ее чуток изменил.
1. Создается тбл., в которой хранятся агрегированные данные (т.е. каждый день (закрытый период 1 день) хранит суммарные данные за все предыдущие+данные самого себя)
2. Вычисление продаж за любой период сводится к вычислению разницы между начальной датой периода и конечной.

...

Рейтинг:

0 / 0

28.09.2002, 11:59:39

| Ответить | Цитировать | Написать

Большие объемы данных

#32053875

Breakneck

Участник

Откуда: Kiev

Сообщения: 2 457

Рейтинг: 0 / 0

Идея разбиения таблицы по филиалам неплоха. Можно (в свете сказанного Евгением) пойти дальше - разбить таблицы по группам филиалов. Это будет экономичнее. Группировку можно делать как территориальному, так и по организационному признаку, например.
А насчет долгого join нескольких таблиц с филиалами - это зря, как мне кажется. Рано или поздно при увеличении количества данных в одной общей таблице затраты на select превысят затраты на join.
Мне кажется одним из лучших решений все-таки группировка филиалов.

...

Рейтинг:

0 / 0

28.09.2002, 12:18:01

| Ответить | Цитировать | Написать

Большие объемы данных

#32053877

SiDen

Участник

Сообщения: 479

Рейтинг: 0 / 0

Как на счет разбития данных по месяцам?

...

Рейтинг:

0 / 0

28.09.2002, 12:39:36

| Ответить | Цитировать | Написать

Большие объемы данных

#32053883

Breakneck

Участник

Откуда: Kiev

Сообщения: 2 457

Рейтинг: 0 / 0

2 SiDen: разбитие данных по месяцамм случае крайне невыгодно. Если неоходимо будет выбрать данные за все периоды или за год хотя бы, уже получится такой навороченный join, что серверу мало не покажется и скорость выборки будет приближаться к черепашьей...

...

Рейтинг:

0 / 0

28.09.2002, 13:25:24

| Ответить | Цитировать | Написать

Большие объемы данных

#32053884

Breakneck

Участник

Откуда: Kiev

Сообщения: 2 457

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

28.09.2002, 13:27:42

| Ответить | Цитировать | Написать

Большие объемы данных

#32054154

Garya

Участник

Откуда: Москва

Сообщения: 33 740

Рейтинг: 164 / 1

По месяцам можно, если :
1. На каждую таблицу навесить по дате констрейнт check.
2. Скрипт с union генерить динамически на клиенте, а не использовать SP с параметром.
Тогда при select .... where Period beetwen ... обращение будет только в те таблицы, в которых эти периоды на самом деле есть.

...

Рейтинг:

0 / 0

30.09.2002, 17:26:33

| Ответить | Цитировать | Написать

Большие объемы данных

#32054229

andreym999

Участник

Сообщения: 116

Рейтинг: 0 / 0

Предлагаю следующий вариант:
Делается таблица промежуточных результатов.
Ночью запускается скрипт который полностью выполняет все группировки и суммирования
На таблицу вешается триггер который в зависимости от вставляемых данных ( можно написать умный триггер )будет при добавлении или изменении апдейтить таблицу результатов в зависимости от операции.
В результате мы очень быстро строим выборки, быстродействия от такого триггера я думаю не упадет если его ограничить (например в текущем дне не работает и.т.п.)

По ночам опять же запустится скрипт который все подверит и построит новую промежуточную таблицу.

...

Рейтинг:

0 / 0

01.10.2002, 02:22:51

| Ответить | Цитировать | Написать

Большие объемы данных

#32055422

Тромбола Евгений

Гость

Спасибо всем откликнувшимся...
Вариант который я предложил, работает и работает быстро (выбока 1 товара по всем филиалам ~1c, выборка всех товаров по всем филиалам ~7-10c., обе выборки за 6мес.)вне зависимости от размера(длины) периода (проверялось на искуственно увеличенной до 250 млн таблице).
Но хотелесь бы все-таки по подробнее про разнесенные по филиалам тбл., мне какжется что это не даст большого выиграша, в связи с тем что придется делать UNION этих таблиц, это раз, и второе, усложняется формулировка условия выборки, так как для каждого филиала(имеется ввиду таблица) придется создавать свое условие.
Если я не прав, попробуйте мне это объяснить.

...

Рейтинг:

0 / 0

04.10.2002, 11:26:26

| Ответить | Цитировать | Написать

Большие объемы данных

#32055431

dkstranger

Участник

Откуда: Москва

Сообщения: 334

Рейтинг: 0 / 0

Мы решаем проблему очень просто ..

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

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

3. Пользователь обращается к 1, даже не зная,
откуда он получит данные :)

...

Рейтинг:

0 / 0

04.10.2002, 11:43:14

| Ответить | Цитировать | Написать

24 сообщений из 24, страница 1 из 1

Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Большие объемы данных

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=46&msg=32053883&tid=1819857]:	0ms
get settings:	8ms
get forum list:	15ms
check forum access:	3ms
check topic access:	3ms
track hit:	41ms
get topic data:	9ms
get forum data:	2ms
get page messages:	54ms
get tp. blocked users:	1ms
others:	199ms

total:	335ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы