|
|
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Со всем уважением хочу поинтересоваться - как хранится varchar в последних версиях Firebird - выделяется место под максимальную длину или под реальную длину хранимой строки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2018, 05:03 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
как и во всех предыдущих. В памяти - максимальной длины, на диске - реальной (с RLE сжатием всей записи). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2018, 08:13 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Насколько я помню RLE жмет фрагментами в 128 байт, в результате чего пустая (или даже null) строка varchar(32000) займет порядка 500 байт на диске после сжатия, вроде хотели увеличить RLE, но на той тройке что я тестил было еще 128 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 09:33 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
a7exander, это решение было отложено до 4.0, так как 3.0 и так сильно отставал по срокам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 09:35 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Симонов Денисэто решение было отложено до 4.0 Но и в четвёрку патч для LZ-сжатия так и не приняли. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 12:21 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, Наверно потому, что она "и так сильно отстает по срокам".))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 13:25 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovНо и в четвёрку патч для LZ-сжатия так и не приняли. ибо он кривокосячный, а аффтар встал в позу обиженного и исправлять не захотел ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 15:22 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
dimitrкак и во всех предыдущих. В памяти - максимальной длины, на диске - реальной (с RLE сжатием всей записи). Я правильно понимаю, что это и есть причина, чтобы НЕ лупить все поля varchar максимальной длины 8000, рассчитывая, что всё равно сохранится на диске столько, сколько надо, а потому и смысла ограничивать нету? А есть еще какие причины? А то я всё никак понять не мог, зачем мне вообще все эти ограничения. Кое-где налепил даже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 15:26 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
V.Borzov, ограничивать надо здравым смыслом (или требованиями бизнес-логики). Ибо полноразмерные варчары идут еще и в сортировку, например. Где можно запросто получить 10 гигов временных файлов вместо ожидаемых 100МБ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 15:33 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Тьфу, извиняюсь, проглотил половину... Я правильно понимаю, что поля максимальной длины обернутся огромными расходами на используемую сервером память при обращении к этим данным? Это и есть причина, чтобы не лепить все поля varchar максимальной длины, так? Есть еще какие причины? А, ну индексы всякие еще лепить по таким полям не получится. А вот создавать это поле взамен blob-полей, когда размер вряд ли будет больше 8000 символов, но в целом - неизвестно сколько - вполне себе можно, так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 15:35 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
V.BorzovЯ правильно понимаю, что поля максимальной длины обернутся огромными расходами на используемую сервером память при обращении к этим данным? в основном при сортировке. Потому что полные строки пойдут в память сортировки, и если не влезут - то на диск (в файл сортировки). То же самое будет при индексировании такого столбца. http://www.ibase.ru/files/articles/performance/Firebird Optimizer - ORDER vs SORT.pdf со страницы 3. В остальных случаях - не так страшно, потому что сервер такие объемы в памяти не держит, ему это ни к чему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 16:08 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Офтопну малость... Господа разработчики, а вы не думали сжимать при хранении строки UTF8 несколько иначе? Ведь практически любую строку UTF8, содержащую национальные символы UNICODE (не ASCII) в определенном диапазоне, можно сжать почти вдвое, если первый байт, определяющий начало диапазона UNICODE и количество байт на символ, задавать только один раз, используя его как маркер, пока не встретится другой маркер? Согласно правилам кодирования utf8, в старшем байте установленные старшие биты до ближайшего сброшенного бита в сторону младших разрядов определяют количество байт на символ. Для ASCII символов ничего не поменяется и они все будут однобайтными, а для национальных, например, для следующих подряд символов русской кириллицы, можно указать только один старший байт формата 110xxxxx, а все последующие, начинающиеся на 10xxxxxx (в бинарном виде) воспринимать как октеты, предварённые старшим октетом до тех пор, пока не встретится старший байт, отличный от начального. После чего, полученную строку можно прогнать через RLE алгоритм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 16:28 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
rdb_dev, прелесть "тупого" RLE в однопроходном сжатии всей записи. Если мы начинаем гулять по столбцам и сжимать их отдельно, то заметно начинает расти ЦПУ-оверхед на компрессию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 16:37 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
dimitr, а, понятно - у вас RLE жмёт строку записи целиком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 17:17 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
rdb_dev, про альтернативную упаковку был доклад то ли на нашем семинаре в Праге, то ли там же на конференции года два-три назад (если мне не изменяет память). И как-то не срослось. Я помню, что сжатие каких-то символов было до 50%, а других - не очень, я в смысле кодировок. Так что... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 17:19 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
dimitrЕсли мы начинаем гулять по столбцам и сжимать их отдельно, то заметно начинает расти ЦПУ-оверхед на компрессию. всего лишь "гулять по столбцам"... что же будет с LZ-сжатием..... PS. Казалось бы можно бы было - чисто тиритисски - убить обоих овец: 1) хранить все тексты в UTF-8 ( или другом UTF-XX ) 2) все текстовые поля собирать в начало или в конец строки. Переупорядочивать. 3) два половинки строки сжимать по разному: "тупым RLE" и "продвинутым префиксным UTF-ером" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 18:35 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
AriochКазалось быКреститься надо ... Мне вот сильно неочевидно, что разновсяческие оптимизации не станут пессимизациями. Особенно, если приложение регулярно делает update или массовые "вставить-обработать-удалить и по циклу". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 18:39 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Arioch, примерно такие мысли и были. Но это будет ждать следующей мажорной ОДС. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 18:40 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, насколько помню эксперименты Олега в яффиле, эффект от отключенного сжатия был только при апдейтах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 18:41 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovОсобенно, если приложение регулярно делает update еще когда Yaffil появился, Олег в нём сделал на пробу параметр для регулирования "порога" сжатия. Я провел мелкий тест, и выяснил, что при обновлениях база начинает пухнуть в 2 раза сильнее, а скорость обновлений тоже где-то раза в 2 повышается. Но это было почти при царе Горохе, лет 14-15 назад. Сейчас и диски другие, и процессоры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 18:44 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Ну не знаю ... Делать сортировку по фактическому размеру varchar можно и без обновления ODS. Некоторое количество проблем это позволит решить. P.S. Нет, предоставить патч - не готов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 18:45 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
dimitrпримерно такие мысли и были. Помнится, Джим вообще предлагал перейти на кодирование записи вместо сжатия (как у Оракула) и, возможно даже, на самоописывающийся код. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 18:48 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
dimitr, не знаю, как Олег, я подробно не проверял. Но отсутствие сжатия казалось чем-то ужасным, из-за непривычного роста объема. Теоретически, если сжатие менять или отключать, надо будет модифицировать и % оставляемого на страницах места. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 18:49 |
|
||
|
varchar в Firebird
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovОсобенно, если приложение регулярно делает update или массовые "вставить-обработать-удалить и по циклу". Наоборот. В этом смысле уменьшать запись на медленный HDD засчет процессорного времени - вполне разумно. Хотя, конечно, практика - критерий истины. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2018, 19:08 |
|
||
|
|
start [/forum/topic.php?fid=40&msg=39711633&tid=1560964]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
70ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
2ms |
| others: | 15ms |
| total: | 195ms |
| 0 / 0 |
