Идите в лес со своими отличными предложениями. Ес отлично развивает ветряки и панельки. Доразвивались до того что цена электричества выросла в разы, и блекауты уже не что то теоретическое. И это при том что промышленность Европы летит даже не с горы а с утеса.
Развивать промышленность и тем более нормальную энергосистему на панель УАЗ и веточках не выйдет. Все немножко забывают, Но помимо выработки мощности, есть ещё очень важная характеристика. Частота. Вот её ни панельки ни ветряки не задают. И чтобы ваша крупнее единая энергосеть работала вообще частота должна быть стабильной, а значит большинство мощностей 80-90% должны быть на турбинах которые крутятся. Гидро или в АЭС или в ТЭЦ, Но никаким образом на веточках и аккумуляторах вы не построить энергосеть даже крупного поселка, не говоря про страну с ее промышленностью и огромными территориями.
И главное зачем если стоимость электроэнергии от ветряков и солнечных панелей в разы выше чем от сжигания газа?
Т.е. вот никогда не строили с перепадом, а тут начали? Ну чушь не несите. Вы ни одного дома ни в СССР ни где то ещё не найдете без перепадов. Или стоить он будет столько что не купить.
Создавать статью на основе мыслей одного из первых инфоцыган. Ну такое себе. Про недвижимость вообще сплошной бред в статье. Никто не говорит что вот сейчас ее надо брать. Сейчас как раз не надо. Копите на депозитах. Упадет ставка у вас уже будет первоначальный взнос и надо будет успеть купить пока цены в космос не улетят очередной раз.
Экономить нужно на латовом рафе и Турции, а не на покупке квартиры.
Если речь о gp то какие нафиг индексы? Вообще оптимизация запросов она не про индексы это совсем другой уровень решений. Оптимизация это про потоки данных в запросе и их наиболее быстрое колапсирование и фильтрацию на более ранних этапах. На разделение запроса на более простые и использование временных таблиц и т.д.
Ну и аналитики бывают очень разными. Я бы больше спрашивал как например найти в бд какую то сущность что то про поиск таблиц по колонкам, про поиск по комментариям к таблицам/колонкам. Про какое то логическое мышление. Написать запрос для этого гугл есть он синтаксис подскажет.
А потом вы понимаете, что заменить mssql на pg вы не можете, потому что сервер в разы мощней вы не найдете. И начинаете переходить на greenplum. И проблемы бекапов новеньких 16+ PG начинают казаться смешными и надуманными. И дауншифтинг там может лет на 10, а не на 40 как уже у вашем случае происходит.
Не очень понял как поможет разобрать джоины на более мелкие. Допустим у вас есть активные запросы с разными условиями на Params. И дальнейшей обработки. Ну грубо выбираются данные из Table1 на основании его Params А дальше это все соединяется с Table2-Tabl4. Т.е. как не крути, если Table1 распределена по ключу то даже если для одного запроса мы все оптимизируем, то 100 других будут с перекосами от единиц процентов до нескольких порядков.
Ну таблицы большие. Положим будет Redistribute Motion но таких запросов тысячи и работать одновременно будут десятки. Насколько это вообще оправдано и как это будет аффектить использование памяти?
Я понимаю что База выбирается под конкретную задачу. Но мир чутка изменился. Предположим что задача вот как я описал, и база выбирается Greenplum, потому что. Забываем про стоимость системы и т.д. Насколько производительней будет система если Table1, Table2, Table3 replicated, а Table4 распределена случайно?
Table4(Date, Param1, Param2, ... , ParamN, ID_1) (огромная и секционирована например по Date помесячно) Допустим 400Гб.
При этом все ID не являющиеся serial updatable.
И система должна быcтро делать запросы типа
select *
from Table4 t4
inner join Table1 t1 on t1.ID_1 = t4.ID_1
inner join Table2 t2 on t2.ID_2 = t1.ID_2
inner join Table3 t3 on t3.ID_3 = t1.ID_3
where Date = Дата
and t2.ParamM = ParamM
and t3.ParamK = ParamK;
Вытекает три проблемы
Если распределить все ровненько по serial а Table4 random. То данные круто лежат по всем сегментам. Но вот для джоина нужен броадкаст.
Нет никакой гарантии, что распределение данных по ParamM будет равномерным.
Нет никакой гарантии, что распределение данных в каждой секции Date по ParamM будет равномерным.
А запросы будут всякие разные со всеми возможными условиями по Param из всех таблиц. Вот какие рекомендации могут быть в такой простой но жизненной ситуации? Вот как будет работать броадкаст, он перегонит все данные отосвcюду восюда? Т.е. для каждой секции придут почти по 200Гб данных из Table1,2,3? И памяти такой джоин отожрет на каждой секции сколько?
Или я что-то не понимаю и данная база пригодна исключительно для хранения больших витрин с которых быстро можно поселектить простенький отчет без джоинов или с джоинами по маленьким справочникам?
Идите в лес со своими отличными предложениями. Ес отлично развивает ветряки и панельки. Доразвивались до того что цена электричества выросла в разы, и блекауты уже не что то теоретическое. И это при том что промышленность Европы летит даже не с горы а с утеса.
Развивать промышленность и тем более нормальную энергосистему на панель УАЗ и веточках не выйдет. Все немножко забывают, Но помимо выработки мощности, есть ещё очень важная характеристика. Частота. Вот её ни панельки ни ветряки не задают. И чтобы ваша крупнее единая энергосеть работала вообще частота должна быть стабильной, а значит большинство мощностей 80-90% должны быть на турбинах которые крутятся. Гидро или в АЭС или в ТЭЦ, Но никаким образом на веточках и аккумуляторах вы не построить энергосеть даже крупного поселка, не говоря про страну с ее промышленностью и огромными территориями.
И главное зачем если стоимость электроэнергии от ветряков и солнечных панелей в разы выше чем от сжигания газа?
Т.е. вот никогда не строили с перепадом, а тут начали? Ну чушь не несите. Вы ни одного дома ни в СССР ни где то ещё не найдете без перепадов. Или стоить он будет столько что не купить.
Создавать статью на основе мыслей одного из первых инфоцыган. Ну такое себе. Про недвижимость вообще сплошной бред в статье. Никто не говорит что вот сейчас ее надо брать. Сейчас как раз не надо. Копите на депозитах. Упадет ставка у вас уже будет первоначальный взнос и надо будет успеть купить пока цены в космос не улетят очередной раз.
Экономить нужно на латовом рафе и Турции, а не на покупке квартиры.
Нет, они хранятся логически отсортированными. Физически все как попрет.
Если речь о gp то какие нафиг индексы? Вообще оптимизация запросов она не про индексы это совсем другой уровень решений. Оптимизация это про потоки данных в запросе и их наиболее быстрое колапсирование и фильтрацию на более ранних этапах. На разделение запроса на более простые и использование временных таблиц и т.д.
Ну и аналитики бывают очень разными. Я бы больше спрашивал как например найти в бд какую то сущность что то про поиск таблиц по колонкам, про поиск по комментариям к таблицам/колонкам. Про какое то логическое мышление. Написать запрос для этого гугл есть он синтаксис подскажет.
А потом вы понимаете, что заменить mssql на pg вы не можете, потому что сервер в разы мощней вы не найдете. И начинаете переходить на greenplum. И проблемы бекапов новеньких 16+ PG начинают казаться смешными и надуманными. И дауншифтинг там может лет на 10, а не на 40 как уже у вашем случае происходит.
Ну учитывая что огород знатный речь не о mssql. Там бы все легко решил проект в vs и sqlpackage.
Но огород все равно знатный. Зачем все дропать то?
Нужно называть объекты и файлы одинаково.
Нужно разделить типы объектов по папкам.
В альтере таблиц нужно добавлять проверки на существование или сделать что то по аналогии рефакторлога из SQL проектов.
Дропать и пересоздавать только то что нужно по зависимостям из бд.
Накатывать только те объекты что у вас в релизе. И запускать все только один раз зачем запускать что то несколько раз вообще?
Не очень понял как поможет разобрать джоины на более мелкие. Допустим у вас есть активные запросы с разными условиями на Params. И дальнейшей обработки. Ну грубо выбираются данные из Table1 на основании его Params А дальше это все соединяется с Table2-Tabl4. Т.е. как не крути, если Table1 распределена по ключу то даже если для одного запроса мы все оптимизируем, то 100 других будут с перекосами от единиц процентов до нескольких порядков.
Ну таблицы большие. Положим будет Redistribute Motion но таких запросов тысячи и работать одновременно будут десятки. Насколько это вообще оправдано и как это будет аффектить использование памяти?
Я понимаю что База выбирается под конкретную задачу. Но мир чутка изменился. Предположим что задача вот как я описал, и база выбирается Greenplum, потому что. Забываем про стоимость системы и т.д. Насколько производительней будет система если Table1, Table2, Table3 replicated, а Table4 распределена случайно?
На одной спичке все прекрасно. Вопросы возникают когда спичек больше одной.
Случай 1. У нас 4 таблицы.
Table1 (ID_1 serial, Param1, Param2, ... , ParamN, ID_3, ID_2) Допустим 200Гб
Table2(ID_2 serial, Param1, Param2, ... , ParamN, ID_3) Допустим 200Гб
Table3(ID_3 serial, Param1, Param2, ... , ParamN) Допустим 200Гб
Table4(Date, Param1, Param2, ... , ParamN, ID_1) (огромная и секционирована например по Date помесячно) Допустим 400Гб.
При этом все ID не являющиеся serial updatable.
И система должна быcтро делать запросы типа
select *
from Table4 t4
inner join Table1 t1 on t1.ID_1 = t4.ID_1
inner join Table2 t2 on t2.ID_2 = t1.ID_2
inner join Table3 t3 on t3.ID_3 = t1.ID_3
where Date = Дата
and t2.ParamM = ParamM
and t3.ParamK = ParamK;
Вытекает три проблемы
Если распределить все ровненько по serial а Table4 random. То данные круто лежат по всем сегментам. Но вот для джоина нужен броадкаст.
Нет никакой гарантии, что распределение данных по ParamM будет равномерным.
Нет никакой гарантии, что распределение данных в каждой секции Date по ParamM будет равномерным.
А запросы будут всякие разные со всеми возможными условиями по Param из всех таблиц. Вот какие рекомендации могут быть в такой простой но жизненной ситуации? Вот как будет работать броадкаст, он перегонит все данные отосвcюду восюда? Т.е. для каждой секции придут почти по 200Гб данных из Table1,2,3? И памяти такой джоин отожрет на каждой секции сколько?
Или я что-то не понимаю и данная база пригодна исключительно для хранения больших витрин с которых быстро можно поселектить простенький отчет без джоинов или с джоинами по маленьким справочникам?