|
|
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисЕМНИП, ты ведь пытался что там с сортировкой сделать. Нет, никогда я ничего такого не пытался, просто как-то предлагал простой хак для использования имеющихся процедур сортировки для HASH GROUP. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 12:02 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
гоните его нахер. это мудозвон пустопорожний. ибо сказано в писании: "один дурак может задать столько вопросов, что и 100 мудрецов не ответят" Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 12:06 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, вот здесь это было. Там про уменьшение размеров сортировочных файлов разговор шёл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 12:54 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Симонов Денисвот здесь это было. Экий ты археолог... В плане "сделать" я там никакой активности не проявлял, только "занести хотелку в трекер". Потом хотелка отсохла. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2014, 14:18 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
А всё-таки. Вот есть у нас таблица T(ID integer, S1 varchar(32000), S2 varchar(32000)). Есть в ней одна запись: insert into T(ID, S1, S2) values(1, 'S1', 'S2'). Вопросы: 1. В чём профит от того, что в БД на эту запись лежат примерно 64000 байт, упакованных RLE? Почему бы не записать всего пару десятков байт, закоденых RLE? 2. В чём профит от того, что при доставании записи из БД нужно будет выделить примерно 64000 байт, потом распаковать в них RLE-блок? Почему бы не выделить пару десятков байт и не распаковать туда столько, сколько там реально данных? Зачем сначала запаковывать, а потом распаковывать пустоту? Ведь при этом перерасходуется память (т.е. в итоге в кэш входит меньше полезных данных) + перерасходуется место на диске (а это лишний ввод-вывод) + впустую тратятся ресурсы процессора на работу с тем, что никогда не будет использоваться. В чём профит такого подхода? Или это нужно Джима спрашивать почему он так заархитектурил тридцать лет назад? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 17:36 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee1. В чём профит от того, что в БД на эту запись лежат примерно 64000 байт, упакованных RLE? Почему бы не записать всего пару десятков байт, закоденых RLE? С какого перепугу ты решил, что в БД лежит 64000 байт? Подикося, слышал об RLE только название... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 17:43 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeА всё-таки. Вот есть у нас таблица T(ID integer, S1 varchar(32000), S2 varchar(32000)). Есть в ней одна запись: insert into T(ID, S1, S2) values(1, 'S1', 'S2'). Вопросы: 1. В чём профит от того, что в БД на эту запись лежат примерно 64000 байт, упакованных RLE? Почему бы не записать всего пару десятков байт, закоденых RLE? 2. В чём профит от того, что при доставании записи из БД нужно будет выделить примерно 64000 байт, потом распаковать в них RLE-блок? Почему бы не выделить пару десятков байт и не распаковать туда столько, сколько там реально данных? 1. Потому что запись пакуется целиком, а не по отдельным полям. Одно "длинное" сжатие тупо быстрее десятка "коротких". 2. Чтобы не переаллокировать буфер каждый раз когда последующая запись окажется длиннее. NickDeeВедь при этом перерасходуется память (т.е. в итоге в кэш входит меньше полезных данных) + перерасходуется место на диске (а это лишний ввод-вывод) кеш тут вообще не причем, в нем лежат страницы со сжатыми данными. А для экономии места можно сжимать чуть хитрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 17:44 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
dimitrА для экономии места можно сжимать чуть хитрее. ты про это CORE-4401 говоришь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 18:07 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, так точно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 18:13 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
dimitr1. Потому что запись пакуется целиком, а не по отдельным полям. Одно "длинное" сжатие тупо быстрее десятка "коротких". Запись пакуется целиком и так и так, она же в памяти непрерывно лежит. Просто я предлагаю не хранить хвостовые пробелы варчаров. dimitr2. Чтобы не переаллокировать буфер каждый раз когда последующая запись окажется длиннее.Вот тесты переаллокации: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. Вот код: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. dimitrNickDeeВедь при этом перерасходуется память (т.е. в итоге в кэш входит меньше полезных данных) + перерасходуется место на диске (а это лишний ввод-вывод) кеш тут вообще не причем, в нем лежат страницы со сжатыми данными. А для экономии места можно сжимать чуть хитрее. Или держать в памяти без хвостовых пробелов и не сжимать лишнего :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 19:19 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeВот тесты переаллокации это сферический конь в вакууме. Реально будет потери времени выполнения процентов 10-20. Ты уверен, что их сэкономишь за счет сжатия "без хвостов"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 20:30 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
dimitrNickDeeВот тесты переаллокации это сферический конь в вакууме. Реально будет потери времени выполнения процентов 10-20. Ты уверен, что их сэкономишь за счет сжатия "без хвостов"? Не только сжатия, но и копирования. Одно дело копировать миллион блоков по 1000 байт, и совсем другое - миллион по 100. Выделить миллион по 100 - это примерно 10 ms. Скопировать 100M - это в несколько раз быстрей чем скопировать 1000M. И даже +10 ms к "скопировать 100M" не будут существенны. Возможно что выделить миллион по 900 + скопировать их будет уже где-то равным по скорости копированию миллиона по 1000. Ещё нужно учесть что realloc нужно будет делать только если запись больше чем размер блока под неё. Т.е. при фетче миллиона записей при максимальном размере записи N (что определяется в метаданных) в memory-buffer вмещающий лишь одну запись, мы получим много меньше чем N реаллоков (т.е. совсем даже не миллион). Итого, нужно реаллоцировать только увеличивая размер буфера под одну запись (не уменьшая если следующая запись меньше), и копировать туда-оттуда только реально используемые байты, без хвоста. И имхо будет профит :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 21:13 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee, твои умозаключения основываются на какой-то абстрактной фигне. Исходники FB открыты возьми да и проведи эксперимент. Если удастся получить приличный выигрыш тогда можно что-о смело утверждать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 21:33 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeнужно реаллоцировать только увеличивая размер буфера под одну запись (не уменьшая если следующая запись меньше), и копировать туда-оттуда только реально используемые байты, без хвоста тебе осталось додумать, как обращаться к полям, расположенным после урезанного варчара. Сейчас у них фиксированное смещение относительно начала записи. Станет плавающее. Менять еще и дескрипторы формата каждый раз когда читаем запись и когда меняем ее апдейтом в NEW-контексте? Уверен, что еще куча интересных вопросов вылезет, если копнуть поглубже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 21:51 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
dimitrNickDeeнужно реаллоцировать только увеличивая размер буфера под одну запись (не уменьшая если следующая запись меньше), и копировать туда-оттуда только реально используемые байты, без хвоста тебе осталось додумать, как обращаться к полям, расположенным после урезанного варчара. Сейчас у них фиксированное смещение относительно начала записи. Фиксированное смещение... Ну а по этому фиксированному смещению что расположено? Прям весь варчар? Если да, то предлагаю вместо этого разместить там четыре байта: первые два байта - длина варчара, вторые два - поинтер на его данные. Так обращение будет быстрым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 22:21 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeТак обращение будет быстрым. И эти четырёхбайтовые описатели будут идти один за другим, т.е. доступ к ним будет индексный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 22:23 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee, вернулись к сжатию кучки маленьких буферов вместо одного большого ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2014, 22:38 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
dimitr, запись у нас расположена непрервыно. Например есть табличка: int1, int2, int3, varchar1(1000), varchar2(1000), varchar3(1000), int4, varchar4(1000) Запись в несжатом виде будет иметь вид: [Header], [int, int, int, int, int, int, int, int], [данные varchar1(5 байт), данные varchar2(10 байт), данные varchar3(20 байт), данные varchar4(3 байта)]. В первых трёх int второго блока лежат значения int1, int2 int3. В четвёртом int второго блока будет лежать "длина varchar1" и смещение по которому лежат данные этого varchar1(например относительно начала второго блока). В пятом int второго блока лежит такая же информация про varchar2. В шестом int второго блока лежит такая же информация про varchar3. В седьмом int второго блока лежит значение int4. В восьмом int второго блока лежит такая информация про varchar4. Все три блока непрерывны внутри и лежат последовательно друг за другом, без разрывов. Таким образом у нас будет один буфер для сжатия и разжатия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2014, 02:31 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee, и чем все это (включая переаллокации буфера записи) лучше, чем просто более эффективно сжимать хвосты? Не со степенью 64, а всегда в три-пять байт, например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2014, 08:56 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
dimitrNickDee, и чем все это (включая переаллокации буфера записи) лучше, чем просто более эффективно сжимать хвосты? Не со степенью 64, а всегда в три-пять байт, например. Эффективность сжатия влияет на размер данных в страничном кэше и в БД. А когда запись распаковывается для работы, например для сортировок, то там перерасход памяти: 16433678 . Есть зависимость скорости создания индекса от объявленной длины поля, при одних и тех же данных (varchar(1) vs varchar(2048)): миллион записей, 1 секунда vs 18 секунд. Засада везде :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2014, 14:38 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDee, объясни две вещи: 1. На фига индекс по длинной предлинной строке 2. На фига сортировать по длинной предлинной строке Другое дело что при сортировке сам резалтсет может получится широким даже при сортировки по небольшому ключу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2014, 14:56 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Симонов Дениспри сортировке сам резалтсет может получится широким даже при сортировки по небольшому ключу.Ога. И dimitr пару лет взад давал возможность потестировать некую спецсборку, где сортируются только ключики, а с итоговыми кортежами идёт их соединение по rdb$db_key. Кому было интересно - тот попробовал, и теперь периодически спамит dimitr'a просьбой втыкнуть это в ФБ-3.х :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2014, 15:01 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
Таблоид, я тоже её пробовал. Но тогда она во многих случаях промахивалась и весьма сильно. Будем надеется ДЕ доведёт оценку стоимости до ума, чтобы оптимизатор выбирал лучший алгоритм сорировки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2014, 15:04 |
|
||
|
Опять про varchar(n)
|
|||
|---|---|---|---|
|
#18+
NickDeeЭффективность сжатия влияет на размер данных в страничном кэше и в БД. и она примерно одинакова в обоих случаях NickDeeА когда запись распаковывается для работы, например для сортировок, то там перерасход памяти это вопрос к сортировщику, обсуждалось уже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2014, 15:32 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38723921&tid=1563372]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
182ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
85ms |
get tp. blocked users: |
2ms |
| others: | 199ms |
| total: | 511ms |

| 0 / 0 |
