ReSQL.ru
     
powered by simpleCommunicator - 2.0.34     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Наши за рубежом [закрыт для гостей] / LinkedIn
20 сообщений из 120, страница 5 из 5
  5  все
LinkedIn
    #22129092
Фотография OoCc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OoCc
Участник
Leonid Gurevich  07.05.2020, 18:23
22128946
RonibGreat  07.05.2020, 18:10
22128934
Leonid Gurevich,

Это я чего-то напутал... был на одном проекте где большие таблицы надо было шерстить в онлайн, но скорость выборки стала мендленная после вставки нового поля по которому и выбирались данны едля отчета. ТО что навешали новый индекс, но потом перестроили таблицу и при создании новой таблицы даное поле переместили вперед и скорость увеличилась в несколько раз с нескольких часов то десятков минут.
Это я могу понять. Оракл парсит столбцы по порядку. Если столбец в начале очень широкой таблицы, то теоретически доступ к нему будет быстрее, чем к последнему.
Похоже спор идёт об оракле 10. Используйте 11g с column store. И вообще это уже диноазавр как кобол. Оракля просрал клауд революцию и подлежит забвению.
...
Рейтинг: 0 / 0
08.05.2020, 01:07
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129093
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CawaSPb
Участник
witte  07.05.2020, 15:45
22128849
Да собственно мало кто любит добавление столбцов (в DB2, например, явно реорганизацию таблицы после этого проводить нужно иначе она "колом" встаёт).
Не спора ради (или ломания копий вокруг сравнения СУБД), а правды для. Это, скажем так, не совсем верно.
Т.е. да, из реляционных СУБД - да, никто не любит. Но вот DB2 и "колом"...
Спойлер
1. Вы про какую DB2 говорите? Их три (не говоря уж про версии) - для zOs, iSeries и Linux, Unix, and Windows. Ну да, SQL похож, протоколы общения/драйвера - те же, но...
2. Для DB2 for LUW:
https://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0000888.html
=================
The following is the full list of REORG-recommended ALTER statements that cause a version change and place the table into a REORG-pending state: DROP COLUMN ALTER COLUMN SET NOT NULL ALTER COLUMN DROP NOT NULL ALTER COLUMN SET DATA TYPE, except in the following situations: Increasing the length of a VARCHAR or VARGRAPHIC column Decreasing the length of a VARCHAR or VARGRAPHIC column without truncating trailing blanks from existing data, when no indexes exist on the column
=================
ADD COLUMN в этом списке нет.

Добавление колонки на физическом уровне работает так:
- "For all existing rows in the table, the value of the new column is set to its default value. "
- Значение по умолчанию для новой колонки (и, соответственно, для всех существующих записей) записывается в системный каталог и при чтении существующих записей (физически не содержащих добавленной колонки) берётся оттуда.
- При update/insert при необходимости конкретные строки расширяются.

Более того, после REORG-recommended операций (DROP COLUMN, определённые SET DATA TYPE, ...) оно тоже не "колом встаёт", а остаётся доступным только на чтение. Что логично.
И оно даже несколько транзакций (три) с REORG-recommended операциями без промежуточного REORG сделать даст прежде чем насильно зафутболит таблицу в REORG PENDING (внутри тех транзакций количество ALTER TABLE не ограничено).

Ну и да, если где-то необходимый REORG не устраивает, есть другие способы модифицировать структуру (без прерывания доступа) - руками, через игры с подменой таблиц, или посредством ADMIN_MOVE_TABLE().
...
Рейтинг: 0 / 0
08.05.2020, 01:23
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129099
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CawaSPb
Участник
OoCc  08.05.2020, 01:07
22129092
Leonid Gurevich  07.05.2020, 18:23
22128946
пропущено...
Это я могу понять. Оракл парсит столбцы по порядку. Если столбец в начале очень широкой таблицы, то теоретически доступ к нему будет быстрее, чем к последнему.
Похоже спор идёт об оракле 10. Используйте 11g с column store. И вообще это уже диноазавр как кобол. Оракля просрал клауд революцию и подлежит забвению.
А я бы предположил, что co-location вытаскиваемых данных увеличился. Большая степень кластеризации по соответствующей колонке. Меньше физических чтений.

С columnn store должны быть свои прибабахи.
...
Рейтинг: 0 / 0
08.05.2020, 02:22
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129121
Фотография OoCc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OoCc
Участник
CawaSPb  08.05.2020, 02:22
22129099
OoCc  08.05.2020, 01:07
22129092
пропущено...

Похоже спор идёт об оракле 10. Используйте 11g с column store. И вообще это уже диноазавр как кобол. Оракля просрал клауд революцию и подлежит забвению.
А я бы предположил, что co-location вытаскиваемых данных увеличился. Большая степень кластеризации по соответствующей колонке. Меньше физических чтений.

С columnn store должны быть свои прибабахи.
Это сильно зависит от селективности запросов. Понятно что на табличке в сто строчек колумн сторе проиграет.
...
Рейтинг: 0 / 0
08.05.2020, 07:31
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129146
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CawaSPb
Участник
OoCc  08.05.2020, 07:31
22129121
CawaSPb  08.05.2020, 02:22
22129099
пропущено...

А я бы предположил, что co-location вытаскиваемых данных увеличился. Большая степень кластеризации по соответствующей колонке. Меньше физических чтений.

С columnn store должны быть свои прибабахи.
Это сильно зависит от селективности запросов. Понятно что на табличке в сто строчек колумн сторе проиграет.
Да понятно, что много в чём Columnar Storage будет зашибись, так же как много в чём проиграет.
И от селективности и размера таблиц как таковых это не зависит.
Вон, к примеру, на OLTP'шной нагрузке селективность просто таки чумовая, но делать процессинг на Columnar Storage - сумасшедших нет. Э-эээ... или есть? ;)
...
Рейтинг: 0 / 0
08.05.2020, 09:23
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129171
Фотография OoCc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OoCc
Участник
CawaSPb  08.05.2020, 09:23
22129146
OoCc  08.05.2020, 07:31
22129121
пропущено...

Это сильно зависит от селективности запросов. Понятно что на табличке в сто строчек колумн сторе проиграет.
Да понятно, что много в чём Columnar Storage будет зашибись, так же как много в чём проиграет.
И от селективности и размера таблиц как таковых это не зависит.
Вон, к примеру, на OLTP'шной нагрузке селективность просто таки чумовая, но делать процессинг на Columnar Storage - сумасшедших нет. Э-эээ... или есть? ;)
Часто ты вставляешь колонки в OLTP табличку?
...
Рейтинг: 0 / 0
08.05.2020, 10:08
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129317
witte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
witte
Участник
Leonid Gurevich  07.05.2020, 17:59
22128926
witte  07.05.2020, 15:45
22128849
пропущено...

Если речь про Oracle, то это в некоторых случаях имело смысл. Хотя бы потому что могли разъехаться физический и логический порядок столбцов, что может привести к попоболи. Я с таким сталкивался когда Oracle e-Business Suite мигрировал с big endian на little endian. Ну и там всякие chaining rows и т.п. гадости могут вылезать если делать inplace.
Да собственно мало кто любит добавление столбцов (в DB2, например, явно реорганизацию таблицы после этого проводить нужно иначе она "колом" встаёт).
Не понял, о каком "логическом" порядке столбцов идет речь. Говорим о базе данных, а не о приложениях.
То что возвращает словарь (причём не весь). Грубо говоря: таблица хранится как col1, col2, а dba_tab_columns возвращает как col2, col1. Баг проявлялся в таблицах с LOB-ми над которыми проводились операции удаления/добавления столбцов. Обещали закрыть в 12-й версии.
...
Рейтинг: 0 / 0
08.05.2020, 13:22
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129323
witte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
witte
Участник
CawaSPb  08.05.2020, 01:23
22129093
witte  07.05.2020, 15:45
22128849
Да собственно мало кто любит добавление столбцов (в DB2, например, явно реорганизацию таблицы после этого проводить нужно иначе она "колом" встаёт).
Не спора ради (или ломания копий вокруг сравнения СУБД), а правды для. Это, скажем так, не совсем верно.
Т.е. да, из реляционных СУБД - да, никто не любит. Но вот DB2 и "колом"...
Спойлер
1. Вы про какую DB2 говорите? Их три (не говоря уж про версии) - для zOs, iSeries и Linux, Unix, and Windows. Ну да, SQL похож, протоколы общения/драйвера - те же, но...
2. Для DB2 for LUW:
https://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0000888.html
=================
The following is the full list of REORG-recommended ALTER statements that cause a version change and place the table into a REORG-pending state: DROP COLUMN ALTER COLUMN SET NOT NULL ALTER COLUMN DROP NOT NULL ALTER COLUMN SET DATA TYPE, except in the following situations: Increasing the length of a VARCHAR or VARGRAPHIC column Decreasing the length of a VARCHAR or VARGRAPHIC column without truncating trailing blanks from existing data, when no indexes exist on the column
=================
ADD COLUMN в этом списке нет.

Добавление колонки на физическом уровне работает так:
- "For all existing rows in the table, the value of the new column is set to its default value. "
- Значение по умолчанию для новой колонки (и, соответственно, для всех существующих записей) записывается в системный каталог и при чтении существующих записей (физически не содержащих добавленной колонки) берётся оттуда.
- При update/insert при необходимости конкретные строки расширяются.

Более того, после REORG-recommended операций (DROP COLUMN, определённые SET DATA TYPE, ...) оно тоже не "колом встаёт", а остаётся доступным только на чтение. Что логично.
И оно даже несколько транзакций (три) с REORG-recommended операциями без промежуточного REORG сделать даст прежде чем насильно зафутболит таблицу в REORG PENDING (внутри тех транзакций количество ALTER TABLE не ограничено).

Ну и да, если где-то необходимый REORG не устраивает, есть другие способы модифицировать структуру (без прерывания доступа) - руками, через игры с подменой таблиц, или посредством ADMIN_MOVE_TABLE().
Да, ошибся, не добавление а удаление столбца. Я про LUW и классическую построчную таблицу.
...
Рейтинг: 0 / 0
08.05.2020, 13:25
| Ответить | Цитировать | Написать  
LinkedIn
    #22129451
Leonid Gurevich
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Gurevich
Участник
witte  08.05.2020, 13:22
22129317
Leonid Gurevich  07.05.2020, 17:59
22128926
пропущено...
Не понял, о каком "логическом" порядке столбцов идет речь. Говорим о базе данных, а не о приложениях.
То что возвращает словарь (причём не весь). Грубо говоря: таблица хранится как col1, col2, а dba_tab_columns возвращает как col2, col1. Баг проявлялся в таблицах с LOB-ми над которыми проводились операции удаления/добавления столбцов. Обещали закрыть в 12-й версии.
Ну баги, это немного другое.
...
Рейтинг: 0 / 0
08.05.2020, 15:15
| Ответить | Цитировать | Написать  
LinkedIn
    #22129452
Leonid Gurevich
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Gurevich
Участник
OoCc  08.05.2020, 01:07
22129092
Leonid Gurevich  07.05.2020, 18:23
22128946
пропущено...
Это я могу понять. Оракл парсит столбцы по порядку. Если столбец в начале очень широкой таблицы, то теоретически доступ к нему будет быстрее, чем к последнему.
Похоже спор идёт об оракле 10. Используйте 11g с column store. И вообще это уже диноазавр как кобол. Оракля просрал клауд революцию и подлежит забвению.
Насколько я помню колумнар сторе был раньше только в Экзадата. Сейчас это поменялось?
...
Рейтинг: 0 / 0
08.05.2020, 15:17
| Ответить | Цитировать | Написать  
LinkedIn
    #22129472
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CawaSPb
Участник
OoCc  08.05.2020, 10:08
22129171
CawaSPb  08.05.2020, 09:23
22129146
пропущено...

Да понятно, что много в чём Columnar Storage будет зашибись, так же как много в чём проиграет.
И от селективности и размера таблиц как таковых это не зависит.
Вон, к примеру, на OLTP'шной нагрузке селективность просто таки чумовая, но делать процессинг на Columnar Storage - сумасшедших нет. Э-эээ... или есть? ;)
Часто ты вставляешь колонки в OLTP табличку?
Зависит от активности девелоперов на проекте/как быстро функциональность расширяется или от количества ошибок в дизайне.
Бывает что и часто (раз-другой в месяц-два). Для каких-то баз - раз/два в год.

Но речь шла о скорости выборки, которая увеличилась в разы после реорганизации. Скорее всего (не не 100%, конечно) просто изменилась "упаковка" строк в страницы. Раньше были разбросаны по разным, после реорганизации (поди с сортировкой по индексу какому, который и новое поле включал) были собраны вместе. Уменьшилось количество одиночных (не потоковых) физических чтений => увеличилась скорость.

Совет же "используйте Columnar Store и будет вам счастье" - поспешен (собственно мой поинт). Далеко не всегда будет выигрыш по производительности.
...
Рейтинг: 0 / 0
08.05.2020, 15:33
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129493
RonibGreat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RonibGreat
Участник
OoCc  08.05.2020, 01:07
22129092
Оракля просрал клауд революцию и подлежит забвению.
Оracle перешел в разряд "вечных" как и Unix-ы, майнфреймы. По крайней мере, большая часть информации на каждого жителя планеты Земля на сегодня хранится в Оракле. Практически все налоговые и государственные конторы стран используют Оракл. Ораклу уже не надо беспокоится - он завоевал свой рынок и сейчас тихо без напряга покоится на лаврах. И что не говори, а конкурентов пока нет. Майкрософт забил себе десктопы - тоже все гос. конторы банки сидят на Майкрософте. Видел одну контору на Линуксе - мозахисты - долго не прожили через пару лет перешли на Майкрософт, потому как с Линукса и конференцию с клиентом нормально на запустишь, и прочего всякого....
...
Рейтинг: 0 / 0
08.05.2020, 15:50
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129604
base2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
base2
Участник
OoCc  08.05.2020, 01:07
22129092
Оракля просрал клауд революцию и подлежит забвению.
У оракла есть свой клауд и я тоже думал, что они с ним опоздали. Но похоже, что не совсем
https://www.oracle.com/corporate/pressrelease/zoom-selects-oracle-to-support-growth-042820.html
...
Рейтинг: 0 / 0
08.05.2020, 18:52
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129778
Фотография OoCc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OoCc
Участник
CawaSPb  08.05.2020, 15:33
22129472
OoCc  08.05.2020, 10:08
22129171
пропущено...

Часто ты вставляешь колонки в OLTP табличку?
Зависит от активности девелоперов на проекте/как быстро функциональность расширяется или от количества ошибок в дизайне.
Бывает что и часто (раз-другой в месяц-два). Для каких-то баз - раз/два в год.

Но речь шла о скорости выборки, которая увеличилась в разы после реорганизации. Скорее всего (не не 100%, конечно) просто изменилась "упаковка" строк в страницы. Раньше были разбросаны по разным, после реорганизации (поди с сортировкой по индексу какому, который и новое поле включал) были собраны вместе. Уменьшилось количество одиночных (не потоковых) физических чтений => увеличилась скорость.

Совет же "используйте Columnar Store и будет вам счастье" - поспешен (собственно мой поинт). Далеко не всегда будет выигрыш по производительности.
Девелоперы не в счёт. Я говорю о production environment.
Если табличка большая то колумн сторе существенно обгоняет построчное хранилище. Кто сейчас использует хадуп? Никто. Поскольку есть колумн сторе и большие таблички на нём прекрасно работают.
...
Рейтинг: 0 / 0
09.05.2020, 07:26
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129779
Фотография OoCc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OoCc
Участник
base2  08.05.2020, 18:52
22129604
OoCc  08.05.2020, 01:07
22129092
Оракля просрал клауд революцию и подлежит забвению.
У оракла есть свой клауд и я тоже думал, что они с ним опоздали. Но похоже, что не совсем
https://www.oracle.com/corporate/pressrelease/zoom-selects-oracle-to-support-growth-042820.html
Ну если это юзе кейс для оракля клауд то я не сомневаюсь что он уйдёт в забвение.
...
Рейтинг: 0 / 0
09.05.2020, 07:36
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129780
Фотография OoCc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OoCc
Участник
RonibGreat  08.05.2020, 15:50
22129493
OoCc  08.05.2020, 01:07
22129092
Оракля просрал клауд революцию и подлежит забвению.
Оracle перешел в разряд "вечных" как и Unix-ы, майнфреймы. По крайней мере, большая часть информации на каждого жителя планеты Земля на сегодня хранится в Оракле. Практически все налоговые и государственные конторы стран используют Оракл. Ораклу уже не надо беспокоится - он завоевал свой рынок и сейчас тихо без напряга покоится на лаврах. И что не говори, а конкурентов пока нет. Майкрософт забил себе десктопы - тоже все гос. конторы банки сидят на Майкрософте. Видел одну контору на Линуксе - мозахисты - долго не прожили через пару лет перешли на Майкрософт, потому как с Линукса и конференцию с клиентом нормально на запустишь, и прочего всякого....
Я именно об этом и говорил выше. Это напоминает мне историю с коболом, который возможно до сих пор где то используется.
...
Рейтинг: 0 / 0
09.05.2020, 07:37
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22129796
base2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
base2
Участник
OoCc  09.05.2020, 07:36
22129779
base2  08.05.2020, 18:52
22129604
пропущено...

У оракла есть свой клауд и я тоже думал, что они с ним опоздали. Но похоже, что не совсем
https://www.oracle.com/corporate/pressrelease/zoom-selects-oracle-to-support-growth-042820.html
Ну если это юзе кейс для оракля клауд то я не сомневаюсь что он уйдёт в забвение.
В смысле? Что не так с зумом?
...
Рейтинг: 0 / 0
09.05.2020, 09:58
| Ответить | Цитировать | Написать  
LinkedIn
    #22129890
RonibGreat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RonibGreat
Участник
OoCc  09.05.2020, 07:37
22129780
Я именно об этом и говорил выше. Это напоминает мне историю с коболом, который возможно до сих пор где то используется.
Где-то... везде в банках! Ядро банковской системы до сих пор крутится на майнфреймах и коболе. Система была сделана еще в 70ых. И так как банковский бизнес не изменился то и нет смысла чего-нибудь менять. Все новый приблуды в ногу с интернетом прикручиваются поверх кобола и все работает.
...
Рейтинг: 0 / 0
09.05.2020, 16:11
| Ответить | Цитировать | Написать  
LinkedIn
    #22130022
Фотография Pastic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pastic
Участник
OoCc  09.05.2020, 07:26
22129778
CawaSPb  08.05.2020, 15:33
22129472
пропущено...

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

Но речь шла о скорости выборки, которая увеличилась в разы после реорганизации. Скорее всего (не не 100%, конечно) просто изменилась "упаковка" строк в страницы. Раньше были разбросаны по разным, после реорганизации (поди с сортировкой по индексу какому, который и новое поле включал) были собраны вместе. Уменьшилось количество одиночных (не потоковых) физических чтений => увеличилась скорость.

Совет же "используйте Columnar Store и будет вам счастье" - поспешен (собственно мой поинт). Далеко не всегда будет выигрыш по производительности.
Девелоперы не в счёт. Я говорю о production environment.
Если табличка большая то колумн сторе существенно обгоняет построчное хранилище. Кто сейчас использует хадуп? Никто. Поскольку есть колумн сторе и большие таблички на нём прекрасно работают.
Hodoop сейчас те же банки и используют. И есть куча вакансий для спецов по хадупу.
...
Рейтинг: 0 / 0
09.05.2020, 23:39
| Ответить | Цитировать | Написать | Ответы  
LinkedIn
    #22130028
RonibGreat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RonibGreat
Участник
Pastic  09.05.2020, 23:39
22130022
Hodoop сейчас те же банки и используют. И есть куча вакансий для спецов по хадупу.
Hadoop для несерьезных данных. Я был в банке на Hadoope - данные сливаются сотнями гигабайтов в день, но реально пока никто никакой пользы из них не извлекает. Все хадуповские проекты занаяты тем чтобы как-то организовать эти данные потому как стурктура данных меняется у источников данных и в центральных офисах заняты тем чтобы хоть как-то сегодняшние данные прилепить к вчерашним. К примеру, Токийский офис шлет данные о всех биржевых транзакциях банка в центральный офис в Торонто. На следующий день в Японии ввели законодательно, что надо отчитываться в налоговую об типе транзакций с использованием иностранной для Японии валюты - следовательно к структура записи поменялась и добавили новую колонку с данными. Так что Хадуп только для того чтобы поддерживать стартаперов и нестартаперов в Калифорнии, а то все американское айти загнется как индустрия.
...
Рейтинг: 0 / 0
09.05.2020, 23:56
| Ответить | Цитировать | Написать  
20 сообщений из 120, страница 5 из 5
  5  все
Форумы / Наши за рубежом [закрыт для гостей] / LinkedIn
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=7&gotomsg=22129146&tid=1324394]:
 0ms
get settings:
 11ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 62ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 92ms
get tp. blocked users:
 1ms
others: 15ms
total:  217ms
созд. / загр.: 217ms
x
x
Закрыть


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