Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 46 47 48 49 50 51 52 [53] 54 55   вперед  Ctrl
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10586
Arioch,

большего бреда я ещё не читал

Arioch
На уровне ODS организовать глобальное хранение строк.
С хэшированием, reference counting, bells and whistles.

На уровне строк в таблицах хранить не тексты - а ссылки на хранилище.

Ну, примерно как MS Excel сохраняет XLSX-файлы.


Как ты представляешь такую структуру на диске и в памяти с учётом разбиения на страницы, поддержки версий и транзакций?

Arioch
VARCHAR - ограниченная длина, неэффективное хранение коротких строк внутри длинных столбцов, RLE заменить на что-то более эффективное не удалось.


во первых сжимается не VARCHAR, а запись целиком. Во вторых ты пробовал заменить то? Я вот видел как один товарищ экспериментировал со сжатием и ему удалось получить прирост производительности в некоторых случаях на 10-30%

Arioch
При этом Firebird ещё и запрещает преобразовать одно в другое с объяснением "хрен его знает, что при этом получится".


да неужели, видать у меня особая сборка FB раз CAST работает

Arioch
Глобальное хранилище строк бы ...


да щаззз. Может тебе стоило бы подумать, что VARCHAR дополняется до максимальной ширины чтобы использовать буфер фиксированного размера?

Arioch
замедлилась запись строк в таблицу - два cache write вместо одного.


ага прям ровно два? А ничего что строка бесконечной длинны может не вместиться на одну страницу?
16 янв 20, 15:49    [22060754]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
Dimitry Sibiryakov
но там на пути воплощения лежит подводный камень.

интересно, какой именно. ведь если есть опция -use_all_space, можно было бы сделать опцию -use_reserve или типа того. А в остальном - при ресторе можно разные параметры БД менять, да и рестор сам по себе тоже на ходу параметрами БД манипулирует.
16 янв 20, 16:41    [22060823]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

kdv
интересно, какой именно.

Весьма забавный: в SPB для gfix есть байтовый тэг "использовать всё пространство" и к нему
два значения "да, использовать" и "нет, резервировать". А в SPB для gbak есть только тэг
"включить опции" и к нему битовая маска опций, один из битов которой "использовать всё
пространство". Неустановленные биты, естественно, игнорируются.

То есть для решения проблемы надо либо заводить новый тэг для gbak, аналогичный
gfix-овому, либо новый тэг "выключить опции" со значением, противоположным существующему.

Я склоняюсь к первому варианту.

Posted via ActualForum NNTP Server 1.5

16 янв 20, 17:04    [22060861]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 11101
Симонов Денис
с учётом разбиения на страницы


с блобами же как-то справились

Симонов Денис
поддержки версий и транзакций?


А чем они мешают?
Записываем строку, которой ещё не было - дёрнули генератор. Ему пофигу на версии и транзакции.
"Записываем" дубликат, найденный по хэшу и сверенный по составу - дёрнули RefCount
Удаляется версия записи - уменьшается RefCount.

> раз CAST работает

CAST не преобразует столбцы. Мимо.

> Я вот видел как один товарищ экспериментировал со сжатием и ему удалось получить прирост производительности в некоторых случаях на 10-30%

"в некоторых случаях". Т.е. в остальных и до 10% недотянул.
ну и если всё так хорошо, почему не в мейнстриме?

по факту - не удалось. Каким RLE был, таким и остался.

> во первых сжимается не VARCHAR, а запись целиком.

В том числе и поэтому. Не удается сделать единое и хорошее сжатие для сильно разных данных.

Симонов Денис
VARCHAR дополняется до максимальной ширины чтобы использовать буфер фиксированного размера?


И это плохо. Хранятся мусорные ненужные данные (padding) в большом объёме. Возможно в большем, чем полезные данные.

Симонов Денис
А ничего что строка бесконечной длинны может не вместиться на одну страницу?

В этом случае она и в текущей ODS тоже на одну страницу бы не влезла. Т.е. overhead на отдельное хранилище станет ещё меньше. Я описал худший случай.

Не говоря про разницу между записью на HDD последовательных блоков и seek между дорожками.
17 янв 20, 20:11    [22061935]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
Arioch
VARCHAR - ограниченная длина, неэффективное хранение коротких строк внутри длинных столбцов

кстати, а откуда взят этот тезис про "неэффективное хранение коротких строк" в varchar?
17 янв 20, 20:34    [22061953]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1163
В новых версиях FB есть varchar(max)? Если нет, то планируется?
18 янв 20, 19:23    [22062245]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10586
DmSer,

не конечно (два раза)
18 янв 20, 19:25    [22062249]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 850
DmSer
В новых версиях FB есть varchar(max)? Если нет, то планируется?


А что есть max и зачем?
18 янв 20, 19:42    [22062257]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
я бы всё-таки хотел услышать от Arioch про "неэффективное" хранение varchar.
есть впечатление, что он просто не понимает, о чём говорит.

На всякий случай намекну - упаковка записи RLE не имеет никакого отношения к хранению varchar. Видимо, он перепутал char и varchar.
18 янв 20, 21:23    [22062324]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10586
Arioch
CAST не преобразует столбцы. Мимо.


столбцы и не должны преобразовываться. Найди где это можно и покажи.

Arioch
"в некоторых случаях". Т.е. в остальных и до 10% недотянул.
ну и если всё так хорошо, почему не в мейнстриме?

по факту - не удалось. Каким RLE был, таким и остался.


потому что он не довёл это до состояния когда пул реквест приняли бы.
И не стал пробовать другие предложенные варианты (пробовал только один алгоритм сжатие, не факт что лучший).


Arioch
И это плохо. Хранятся мусорные ненужные данные (padding) в большом объёме. Возможно в большем, чем полезные данные.


ничего и нигде не хранится. Под них просто выделена память. И это благо, потому что её не надо перевыделять многократно.

Arioch
В этом случае она и в текущей ODS тоже на одну страницу бы не влезла. Т.е. overhead на отдельное хранилище станет ещё меньше.


в этом случае оно ничем не лучше BLOB. А самое главное абсолютно бесполезно. Я вот думаю тебе пора свою СУБД собирать со своими "гениальными" идеями. Вот там бы и пробовал хранилище уникальных строк делать )))
18 янв 20, 21:44    [22062342]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1163
Старый плюшевый мишка
DmSer
В новых версиях FB есть varchar(max)? Если нет, то планируется?


А что есть max и зачем?


В ms sqlserver есть такая фича. Можно везде ляпать varchar(max) и не париться над тем, какая длина строки реально необходима.
19 янв 20, 00:13    [22062412]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
DmSer,

ну что вы лепите. Это такой же "безразмерный" varchar, который был в PostgreSQL, только ограничен размером страницы 8к
Microsoft SQL Server 2008 (and above) can store up to 8000 characters as the maximum length of the string using varchar data type. SQL varchar usually holds 1 byte per character and 2 more bytes for the length information.

Разве что в последних версиях PostgreSQL тип text сделали почти нелимитированным
The maximum number of characters for variable unlimited length types (text, varchar) is undefined. There is a limit of size in bytes for all string types: In any case, the longest possible character string that can be stored is about 1 GB.
19 янв 20, 00:27    [22062416]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 850
DmSer
Старый плюшевый мишка
пропущено...


А что есть max и зачем?


В ms sqlserver есть такая фича. Можно везде ляпать varchar(max) и не париться над тем, какая длина строки реально необходима.


Не париться - это, канешна, полезно для сердца. Но вредно для ума. Есть подозрение, что даже Вселенная конечна. А также полагать, что, скажем, maxint в 16-разрядной среде - это не совсем то же самое, что maxint в 64-разрядной. А ведь электроника не не стоит на месте. И, как минимум, домен, созданный в 16-разрядной среде может треснуть в 64-разрядной если программист ну совсем не парится. Это как минимум.
19 янв 20, 00:29    [22062418]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
ёёёёё
Member

Откуда:
Сообщений: 2017
kdv
DmSer,

ну что вы лепите. Это такой же "безразмерный" varchar, который был в PostgreSQL, только ограничен размером страницы 8к
Microsoft SQL Server 2008 (and above) can store up to 8000 characters as the maximum length of the string using varchar data type. SQL varchar usually holds 1 byte per character and 2 more bytes for the length information.
...

Нет.
varchar(max) - это типа "нашего" фаербердовского блоба, который сабтип текст. Может быть длиной до 2Гб, можно с ним в некоторых случаях работать как с текстом, но также много ограничений (например, их нельзя индексировать, как и наши блобы).
19 янв 20, 02:12    [22062427]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

Если что-то выглядит как блоб и ведёт себя как блоб, но на клетке надпись "буйвол" - не
верь глазам своим.

Posted via ActualForum NNTP Server 1.5

19 янв 20, 02:17    [22062430]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
ёёёёё,

ну ок
varchar [ ( n | max ) ] — строковые данные переменного размера. Используйте значение n для определения размера строки в байтах (допускаются значения от 1 до 8000) или используйте max для указания предельного размера столбца вплоть до максимального размера хранилища, что составляет 2^31-1 байт (2 ГБ).
19 янв 20, 03:50    [22062439]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
короче. Можно, конечно, ничего не зная, сочинять фантазии о том, как было бы лучше.
Однако, обычно имеет смысл перед фантазированием посмотреть, как и что реализовано физически "у других".
А потом уже оценивать, насколько это хуже или лучше сделано в ФБ.

Насчет отдельного "хранилища строк" - это, конечно, бред. Потому что оно просто в нынешний ODS не вписывается, да и вообще в хранение толком не вписывается. Чтобы это понять, надо хоть немного разбираться в способах хранения данных в страничных структурах. Ну например подучить, как фрагментируется длинная запись, превышающая размер страницы, по нескольким страницам.
https://firebirdsql.org/manual/fbint-page-5.html#fbint-p5-record-data
(см. поиском слово fragment)

А "доменные структуры" идут лесом.

http://citforum.ru/database/osbd/contents.shtml - для общего образования.

в общем-то,
Arioch
На уровне строк в таблицах хранить не тексты - а ссылки на хранилище.

блоб именно так и хранится. Зачем выдумывать нечто, похожее на блоб - непонятно.
Еще и "счетчик ссылок" типа на одинаковые строки - это вообще ересь, потому что одинаковые строки в реальной жизни стремятся к нулю (тем более, что для этого есть НФ). Словари лучше реализовывать программно, поверх РСУБД.
19 янв 20, 04:00    [22062441]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1163
Dimitry Sibiryakov

Если что-то выглядит как блоб и ведёт себя как блоб, но на клетке надпись "буйвол" - не
верь глазам своим.


Должно быть какое-то отличие, например возврат клиенту в рамках одного запроса. FB так умеет с блобами?
19 янв 20, 08:41    [22062454]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10586
DmSer,

Давай не путать сетевой протокол и тип данных. Если хочется передавать блоб по сети так же как варчары так и скажи, для этого не надо изобретать нового типа. Но тогда товарищи желающие должны рассказать как оно должно выглядеть в АПИ и про другие нюансы
19 янв 20, 10:48    [22062479]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

DmSer
например возврат клиенту в рамках одного запроса. FB так умеет с блобами?

Вопрос в том умеет ли так с varchar(max) MS SQL. Или он таки тоже делает для этого
дополнительные раунд-трипы?

Posted via ActualForum NNTP Server 1.5

19 янв 20, 13:50    [22062516]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10993
Dimitry Sibiryakov
DmSer
например возврат клиенту в рамках одного запроса. FB так умеет с блобами?

Вопрос в том умеет ли так с varchar(max) MS SQL. Или он таки тоже делает для этого
дополнительные раунд-трипы?
Вопрос не правильный. Правильный вопрос - работает ли MSSQL на уровне его сетевого протокола с varchar(max) так же, как с блобами, если реальные строки длинные.

Мы же не можем утверждать, что MSSQL делает доп. раундтрипы при работе с блобами.
Или ты это знаешь точно ?
19 янв 20, 14:45    [22062529]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
ёёёёё
Member

Откуда:
Сообщений: 2017
DmSer,

Данные варчар(макс) живут за пределами записи, для их получения формируется отдельный запрос.
19 янв 20, 14:49    [22062532]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
Arioch,

опоздал на пару дней, но всё-таки
"Инструкция по созданию дампов Firebird на Windows"
http://www.ibase.ru/files/firebird/fb_dumps_win.pdf

эээ. не сюда, ну да ладно, пусть и тут будет, раз сообщение удалить нельзя.

Сообщение было отредактировано: 19 янв 20, 15:01
19 янв 20, 14:59    [22062534]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

hvlad
Или ты это знаешь точно ?

Если бы я это знал точно, оно уже не было бы вопросом.

Posted via ActualForum NNTP Server 1.5

19 янв 20, 15:20    [22062537]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
zigorzn
Member

Откуда:
Сообщений: 20
добрый день.

очень нужно PARTITION BY для таблиц .
планируете добавить в ближайшее время?

(при хранении в одной таблице 2млрд записей и б/р долгий, и почти любой индекс не эффективен)
19 фев 20, 17:08    [22083218]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 46 47 48 49 50 51 52 [53] 54 55   вперед  Ctrl
Все форумы / Firebird, InterBase Ответить