|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
Хочу сказать авторам огромное спасибо за их работу! Некоторые советы напомнили о вещах, о которых забыл, некоторые заставили задуматься о том, о чем вообще не думал или не знал вовсе, некоторые подтвердили правильность собственных наработок, что порадовало, а некоторые советы заставят некоторые мои решения, похоже, пересмотреть. Не знаю, как там у мастеров, хотя их критику здесь тоже очень полезно почитать, но нам, новичкам, такие материалы крайне полезны. Даже если что-то тут окажется и неверным, все равно это полезно. Это очень ценный опыт. Может и высокопарно получилось, но зато от души, поверьте :) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2016, 21:08 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
Да, нормальные советы. Пара-тройка советов не совсем хорошо обьяснена, так скажем (кое где надо было по-развернутее расписать, зачем и когда такое лучше применять), а вообще вполне полезная статья. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2016, 22:09 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
К советам еще можно добавить что-то типа: "Если у вас есть таблица с множеством столбцов, в которой при OLTP нагрузке часто меняются значения только некоторых определенных столбцов в наборе строк этой таблицы, вынесите эти столбцы в отдельную таблицу, связав их 1:1 с мастер таблицей по первичному ключу." ... |
|||
:
Нравится:
Не нравится:
|
|||
24.05.2016, 15:56 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
rdb_dev, из чернового документа много таких вещей повыкидывали, потому что они не совсем однозначны, и относятся к оптимизации+проектированию БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.05.2016, 15:59 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
kdv, мне казалось, данный совет имеет очевидный плюс в версионных СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.05.2016, 16:04 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
rdb_dev, по моему практическому опыту, делить таблицы 1:1, или даже дублировать, бывает полезно независимо от версионности. Кроме того, если посмотреть статистику БД, в таких таблицах обычно размер версии МЕНЬШЕ размера записи. Т.е. есть упаковка, поэтому особого прироста при таком делении "из-за версионности" можно и не получить. p.s. и индексы по неизменяемым при update столбцам тоже не меняются, а не как у некоторых других СУБД. Так что по версионности все же основной совет - не держать транзакции длинными. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.05.2016, 16:10 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
А есть книжки "по оптимальному проектированию с финтами и извращениями" для других СУБД? Можно было бы попробовать что-то полезное вытянуть. К примеру, совет "30. Используйте производные таблицы" - имхо, вполне пригоден не только для FB. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.05.2016, 18:32 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
авторSSD обеспечивает более высокую скорость произвольного ввода-вывода, чем обычные жесткие диски. Работа с БД в основном состоит из большого количества операций чтения-записи в разных местах файла БД, и поэтому SSD дают существенный выигрыш в производительности баз данных ssd в этом тысячелетии я выкинул больше, чем "дятлов" в прошлом...кол-во записи в ячейку ограничено и следит за этим трим, кот. не в каждой системе есть, хотя у самсунга она встроена, начиная с кого-то-там поколения....короче есть сомнения по поводу SSD...хотя я, может, порос мхом, как полагается с южной стороны... ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2016, 17:09 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
SangYong> ssd в этом тысячелетии я выкинул больше, чем "дятлов" в прошлом Гм... Это сколько? 5, 10, 20? Каких брендов, моделей? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2016, 17:21 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
SangYong...ssd в этом тысячелетии я выкинул больше, чем "дятлов" в прошлом... Немудрено. А 100 лет машинные носители информации вообще ничего не "сыпались". Карты имени товарища Германа Холлерита до сих пор читаются. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2016, 08:50 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
SangYongкол-во записи в ячейку ограничено и следит за этим трим, кот. не в каждой системе есть trim уже есть практически везде, а если нет на каком-то десктопе, значит или матплата старая, или надо обновить биос. подсчитать "срок жизни" ssd по перезаписи - тоже не проблема. Например, с ресурсом ячейки в 3000 циклов, и размером диска 120 гиг, на такой диск можно записывать/менять по 12 гиг данных, в течение 8 лет. Или 24 гиг данных, в течение 4х лет. Сейчас вообще стали писать в параметрах, сколько гиг каждый день можно записывать за сколько лет, так что даже вычислять не надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2016, 11:08 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
27. Упорядочите внешние соединения Если в вашем запросе есть несколько групп LEFT OUTER JOIN, старайтесь расположить их так, чтобы вначале были таблицы с меньшим количеством записей, а затем – с большим. Случайно с правый джойном не перепутали? По своему опыту при использовании LEFT JOIN чаще всего сперва идёт ведущая таблица, с которой начинается поиск (самая большая, обычно таблица транзакций, фильтруется по дате/времени), затем к ней подцепляются различные справочники (конечно, если нужен дополнительный фильтр по элементам справочника, то порядок может быть другим). Может я и не совсем прав, но совет 27 - явно спорный. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2018, 18:58 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
DmSerСлучайно с правый джойном не перепутали? вы, вероятно, будете смеяться, но - a left join b и b right join a эквивалентны - сервер внутри превращает b right join a в a left join b. Поэтому никакого right join "унутре сервера" нет. DmSerПо своему опыту при использовании LEFT JOIN чаще всего сперва идёт ведущая таблица речь не о том, как у вас чаще. А о том, что если в запросе более двух left join, то ИХ надо располагать в порядке "от меньших таблиц к большим", тогда запрос может выполниться быстрее. И абсолютно точно у запроса будет другой план. А если располагать "как чаще", то план может оказаться похуже, чем в совете 27. На всякий случай - в нём речь о порядке пар left join, а не о сплошном порядке таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2018, 19:49 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
DmSerМожет я и не совсем прав, но совет 27 - явно спорный. Совет 27 будет корректным при следующих условиях: 1. выполняется совет 35 (Обновляйте статистику индексов) 2. связь таблиц выполняется по индексируемым полям 3. для связи таблиц / поиска задействуется не более одного индекса, наиболее эффективного для данной операции поиска. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2018, 19:52 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
kdvНа всякий случай - в нём речь о порядке пар left join, а не о сплошном порядке таблиц. Видимо, я ступил :) Но не исключено, что не я такой один! ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2018, 19:55 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
речь не о том, как у вас чаще. А о том, что если в запросе более двух left join, то ИХ надо располагать в порядке "от меньших таблиц к большим", тогда запрос может выполниться быстрее. И абсолютно точно у запроса будет другой план. А если располагать "как чаще", то план может оказаться похуже, чем в совете 27. Тогда каким образом влияет размер таблиц в LEFT JOIN. Вот в меня в одном справочнике 1000 записей, в другом 100000. И там и там ключ - ID. Думаю выигрыш будет лишь в том случае, если в дальнейшем в выражении WHERE будет фильтр как по первому справочнику (например, по неиндескированному полю NAME), так и по второму справочнику, и при этом будет быстрее сразу прекращать дальнейшие джойны после неуспешного поиска в мелкой таблицы. А ведь и другая ситуация может быть: в большой таблице (справочнике) поиск выполняется быстро (по индексу), а в мелкой - медленно (нет индекса или индекс "тормозит"). Тогда опять совет 27 - не рулит. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2018, 20:06 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
DmSer, вообще-то ни один из этих советов не стоит использовать в лоб и повсеместно. Тут только как вариант попробовать, не факт что будет лучше, но может. И уж не в коем разе не стоит начинать оптимизировать, если производительность устраивает. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2018, 20:32 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
DmSer, дело в том, что если при inner join оптимизатор может выбрать порядок объединения таблиц, то при left join он вынужден (может быть пока) объединять их в том порядке (парами), как они идут в запросе. И вы когда пишете запрос, не задумыватесь о размере таблиц, а думаете о логике запроса. А когда запрос готов, его план может быть весьма далеким от оптимального. Особенно это касается универсальных систем типа erp. Запросы пишутся с предположением что "в этом виде бизнеса будет вот так и сяк", а на деле перекос по данным между таблицами А и Б у контор 1 и 2 может быть прямо противоположным. При этом план с left join фактически действует как "прибитый вручную план". И т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2018, 20:41 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
Добрый день. В 34 способе написано 34. Не используйте VARCHAR для ключей Не используйте VARCHAR для хранения идентификаторов, если это не необходимо – операции со строками медленнее, чем с числовыми типами. Особенно избегайте идентификаторов типа GUID для ключей Primary/Unique – из-за случайных значений скорость вставки или обновления такого столбца может быть от 3 до 20 раз медленее, чем в случае BIGINT. Т.е. guid медленнее при вставке и обновлении чем bigint, даже если он определен как CHAR(16) CHARACTER SET OCTETS . Или это касается только varchar? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2018, 18:06 |
|
45 способов улучшить производительность Firebird
|
|||
---|---|---|---|
#18+
crazypiggyТ.е. guid медленнее при вставке и обновлении чем bigint между char и vharchar тут разницы никакой нет. Несколько лет назад на семинарах у нас один из докладов был про скорость вставки, в тестах скорость вставки в индексированный столбец varchar(32) раза в 3 медленнее, чем в bigint. char(16) octets все равно по длине в 2 раза больше bigint. Кроме того, в bigint обычно пишут последовательный gen_id, а в guid - рандомное значение, что тоже ухудшает скорость вставки при наличии индекса по такому столбцу. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2018, 18:24 |
|
|
start [/forum/topic.php?fid=40&msg=39242444&tid=1560921]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
129ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 300ms |
total: | 516ms |
0 / 0 |