alex55555s_ustinovЯ надеюсь, "грамотные специалисты" умеют читать?
Они ещё и понимать умеют. Они отлично понимают, что ты тупо передёргиваешь. Либо от непонимания, либо намеренно - с пониманием. Последний случай безнадёжен. Ну а в первом случае ты получаешься идиотом.

Поэтому все твои "сложности с отчётами" либо бот первого (идиотизма), либо от желания нагадить. Оба случая - клинические.

Может, "грамотные специалисты" к своим измышлениям еще и цитаты умеют приводить, которые подкрепляют их утверждения?

alex55555ЗЫ. Для случая "идиот" всё же попробую на пальцах показать - речь шла о времени выполнения запроса (перечитай ветку), и в контексте времени выполнения роль играет именно количество данных, а если к этому количеству прикладывается десяток джойнов, которые уменьшают количество данных раз так в 100 , то такой финт ушами даже ускоряет работу отчёта.

Извините, а вы точно умеете на SQL запросы писать?

Я вам немного расскажу про джойны. На пальцах, чтобы даже “грамотному специалисту” было понятно.
В OLTP системах джойны действительно часто (но не всегда!) приводят к уменьшению количества данных. (Кстати, если умеете читать - рекомендую начать с прочтения статей в википедии, для вашего уровня будет очень полезно. Например, прочтите вот эту статью: https://ru.wikipedia.org/wiki/OLTP)
Но в аналитических запросах джойны обычно приводят к совсем другим результатам.

Рассмотрим очень простой пример, который будет понятен даже “грамотному специалисту”.
Предположим, у нас есть:
- Отгрузки (30000 строк)
- Инвойсы (20000 строк)
- Платежи (10000 строк)
И две вспомогательных таблицы для связей многие ко многим между отгрузками и инвойсами и между инвойсами и платежами.

У каждой отгрузки есть как минимум один инвойс, но бывает и два и три. В среднем - два инвойса на отгрузку.
У каждого инвойса как минимум один платеж, но бывает и 2 оплаты. В среднем - 1,2 оплаты на инвойс.
Каждая оплата относится как минимум к одному инвойсу, но чаще одна оплата относится к 2-3 инвойсам. В среднем - одна оплата на 2 инвойса.

И вот предположим нам надо узнать, какими платежами оплачены каждая из отгрузок.
Делаем четыре (всего четыре, не десять!!!) джойна - соединяем отгрузки с инвойсами, которые выставлены по этим отгрузкам, а инвойсы в свою очередь соединяем с платежами, которые закрывают инвойсы.
И у нас, в результате, будет примерно 30000 * 2 * 1,2 = 72000 строк. Не меньше, а БОЛЬШЕ , чем в каждой из "исходных" таблиц - отгрузок и платежей.

Megabytes_ustinovВсе так, но вы забываете еще об одном минусе, когда OLTP и сложные отчеты "в одном флаконе".

Предположим, у нас есть:
пропущено...

и в какой то не очень счастливый момент запускается 2-3 тяжелых отчета каждый на полчаса - час.
Я подозреваю, что пользователям станет не просто тяжело, а очень тяжело ...
А вы запросы не пробовали оптимизировать или архитектуру?
У нас в олтп системе вполне себе уживаются аналитика и обычная текущая работа. Конечно у разного бизнеса отчётность может отличаться. Может в вашем случае по-другому. У нас просто отчёт, который выполняется больше минуты, это уже медленный. Нагрузку на систему он не дает, так чтобы всем было тяжело. И в целом такие отчёты - это редкость и в 95% случаев они либо не оптимизированы, либо кривая изначальная архитектура данных.
Кривая архитектура данных у подавляющего большинства систем.
И очень часто архитектуру данных править нет и смысла, и возможностей. Ну вот написали так разработчики тиражной системы лет 20 назад.

Сложные отчеты могут считаться долго. И даже "выправление" структуры данных не особо поможет - банально большой объем вычислений.
Да, можно делать отдельные таблички для промежуточных результатов, ночами пересчитывать данные и записывать в эти таблички, попутно чистить данные от косяков и т.д. - но зачем это делать на том же сервере СУБД, что и OLTP система? Чтобы они конфликтовали между собой за ресурсы?
А если вынести на отдельный сервер - это и будет DWH.

Megabytes_ustinovПодобных запросов понадобится сделать пару - тройку десятков за несколько дней, причем заранее никто список, какие запросы будут нужны, сказать не сможет. Смотрятся данные, и по результатам осмысления формируются требования к следующему запросу.
Оптимизировать такие запросы смысла нет - они одноразовые. Готовыми агрегированными данными не воспользуешься - данные в таких разрезах никому раньше не были интересны.
И при этом некоторые из подобных запросов могут очень сильно нагрузить базу. И информации о том, будут тормоза или нет, и если будут, то какие - тоже нет - именно таких запросов к базе никто раньше не делал.

Так dwh - это некая система или просто отдельный сервер? Потому как для таких одноразовых не оптимизированных запросов можно просто копию/реплику бд сделать. Если так, то тогда у нас тоже есть dwh. :) правда именуется резервным сервером и используется только разрабами.
Мое мнение - во многих случаях такого DWH вполне достаточно. Просто отдельный сервер с репликой базы, где выполняются сложные отчеты.
Правда, потом может понадобиться хранить данные в очищенном виде, в более правильной структуре, с расчетом некоторых промежуточных результатов - и постепенно появится "настоящий" DWH.

Ares_ekbs_ustinov,

не понятно к чему этот пример. Если все данные будут лежать в одной таблице, то строк будет меньше?

Смысл в высокой степени нормализации данных в хранилищах такой:

1) Устойчивость схемы данных. При изменении схемы данных OLTP в DWH только добавляются таблицы, но не изменяются и не удаляются - старые данные никак не затрагиваются.

2) Возможность гармонизировать между собой очень разнородные схемы данных OLTP. Те же сведения об организациях, товарах и т.п. могут иметь разную структуру в разных системах. А в DWH можно всё это свести, если использовать 6НФ.

3) Производительность. Важно не только сколько строк, но и сколько столбцов. Если для запроса не нужны абсолютно все столбцы, то объём данных меньше. А если ещё используются колоночное хранение, то совсем зашибись.
Нет, пример не к тому, чтобы хранить все в одной таблице.
Мне самому больше нравится работать с данными в высоких формах нормализации.

Пример к тому, что объемы вычислений в аналитических запросах могут быть очень большими . И такие запросы могут очень негативно сказаться на работе OLTP приложения.

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

А если данных побольше - там количество строк после соединений легко превысит несколько миллиардов. И нагрузка на сервер БД будет очень существенной.

MegabyteЯ вижу необходимость отдельного сервера под хранилище, если надо действительно оперировать большими объёмами данных за одну выгрузку, притом чтобы не мешать текущей работе. И то тут тоже есть варианты оптимизации вроде промежуточных расчетов и агрегаций.
Из моей практики, когда пишешь отчеты для целей анализа - регулярно сталкиваешься с большими объемами. То есть 10-20 отчетов быстрые и легкие, а потом бац - и очередной отчет на пол часа грузит систему...

Варианты оптимизации, разумеется, есть. Но главный вопрос - зачем?
Отдельный сервер для отчетов может быть не особо мощным (и не очень дорогим). Настроить асинхронную реплику базы - пара дней. И после этого можно вообще не беспокоиться о возможном влиянии отчетов на рабочую систему. Отчет в худшем случае положит сервер отчетов, но никак не затронет рабочую систему. С моей точки зрения - овчинка стоит выделки.

alex55555s_ustinovПример к тому, что объемы вычислений в аналитических запросах могут быть очень большими . И такие запросы могут очень негативно сказаться на работе OLTP приложения.
Это один момент.
s_ustinovА если данных побольше - там количество строк после соединений легко превысит несколько миллиардов. И нагрузка на сервер БД будет очень существенной.
А это уже принципиально другой момент. И ты, очевидно, разницы между ними не понимаешь. Вот поэтому тебе и кажется, что улучшить ничего нельзя. Но я тебе по секрету скажу - улучшить можно. То есть в переводе на русский язык "попроще" - ты реально не стоишь тех денег, которые тебе зачем-то платит твой работодатель. Ты тупо не даёшь ему улучшить его систему, заявляя про невозможность улучшения и приводя в качестве аргумента идиотские рассуждения про миллиарды строк.

Миллиарды получаются только тогда, когда пейсатель запросов не понимает, как работает БД. И вот твой пример как раз нам это дело ярко демонстрирует. Ты высосал из пальца эти миллиарды только лишь потому, что не понимаешь, как от них избавиться. Ну и начальству пропихиваешь эти теории, сервера дополнительные, софт дорогой, репликации, обслугу к этому всему, себя в качестве аналитика... В общем куча лишних затрат из-за непонимания того, что реально можно сделать.
Ооооо...
"Грамотный специалист" почитал википедию...

А вот про соединения таблиц, видать, "ниасилил"...

Ты не стесняйся, детально расскажи, как избавиться от миллиардов строк. Я так понимаю, речь идет о секретной технологии "к этому количеству прикладывается десяток джойнов, которые уменьшают количество данных раз так в 100"?

Можешь для примера взять описанную мной задачу - для торговой фирмы посчитать фактическую потребность в оборотных средствах для каждого заказа (покупки или продажи) за несколько лет. Это тот самый пример, который по моим расчетам для компании со средним количеством операций покупок / продаж (сотни тысяч в год) может потребовать обработки миллиардов строк.
Продемонстрируй нам свои глубокие знания "как работает БД". ))

s_ustinovТы не стесняйся, детально расскажи, как избавиться от миллиардов строк. Я так понимаю, речь идет о секретной технологии "к этому количеству прикладывается десяток джойнов, которые уменьшают количество данных раз так в 100"?

Можешь для примера взять описанную мной задачу - для торговой фирмы посчитать фактическую потребность в оборотных средствах для каждого заказа (покупки или продажи) за несколько лет. Это тот самый пример, который по моим расчетам для компании со средним количеством операций покупок / продаж (сотни тысяч в год) может потребовать обработки миллиардов строк.
Продемонстрируй нам свои глубокие знания "как работает БД". ))
Давай я тебе даже чуть подробнее опишу ситуацию, а то есть у меня ощущение, что такой "грамотный специалист" в лучшем случае с парой ларьков работал. )))

Потребность в оборотном капитале - это когда ты заплатил 5 числа поставщику 10000, а 23 числа получил от покупателя 11000. И вот на эти 18 дней (23-5) тебе нужно где то взять 10000. И, разумеется, скорее всего платить за каждый день использования. То есть на эту сделку тебе надо 18 * 10000 = 180000 деньго*дней. Надеюсь, не сильно сложно для "грамотного специалиста" объясняю?
В реальной жизни обычно делают не один платеж поставщику, а много - поставщику, аренда контейнера, перевозка, хранение, растаможка и т.д.

Предположим, ситуация:
Стоит задача найти за пять лет 200 самых лучших отгрузок по показателю:
Маржа / Использованный оборотный капитал
Маржа у нас выручка минус себестоимость. Использованный оборотный капитал - деньго*дни.
Это я специально для "грамотного специалиста" повторяю. )))
2000 отгрузок в день. Считаем, что рабочих дней 300 в год.
Каждая отгрузка - 15 позиций, примерно треть из них из разных партий - 20 партий в отгрузке.
Итого за год - 2000 * 20 * 300 = 12'000'000 (двенадцать миллионов отгрузок разных партий).
За пять лет - 60 миллионов.
20% отгрузок - две оплаты (аванс + оплата).
По каждой партии товара 15 платежей поставщикам (тоже часть с авансовыми платежами).
Итого 60'000'000 * 1,2 * 15 = 1'080'000'000 строк (чуть больше миллиарда).


Расскажи нам всем, "что реально можно сделать", как избавиться от обработки этого миллиарда строк. Продемонстрируй знание "как работает БД".

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

alex55555s_ustinovНапример, другой запрос - вывести покупателя, поставщика, товарную группу, маржу по покупателю в целом (будет дублироваться в нескольких строках) и использованный оборотный капитал.
Вот это, возможно, если схема данных убогая и ты в не не создал нужных вещей, может потребовать fullscan, но для начала я бы хотел, что бы ты продемонстрировал понимание - почему этот случай отличается от случай, когда я говорил про 100-кратное сокращение.
О, уже нашлась причина - "схема данных убогая".
Ну так расскажи нам про хорошую схему данных применительно к этой задаче.
Но внутренний голос мне подсказывает, что и тут что то тебе помешает.
А если бы в танцоры пошел?