Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 Re: СУБД с поддержкой компресии данных и индексов  [new]
hvlad
Member

Откуда:
Сообщений: 11551
vazhnecki
Кстати из бесплатных есть такие ? .. Postgresql вот умеет сжимать данные но не индексы.
Firebird
Но нужно понимать, что у версионников в записи присутствует немаленький заголовок. Сжатие данных в Firebird служит в основном для удаления хвостовых пробелов в строках, сжимается каждая запись сама-по-себе, рекордных показателей тут нет. Бекверсии тоже чаще всего представлены в виде достаточно компактных дельт.
А вот индексы в FB жмутся очень хорошо.
19 май 09, 22:32    [7201040]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
miksoft
Member

Откуда:
Сообщений: 38918
hvlad
miksoft
то вероятность уменьшения IO, имхо, сильно сокращается.
Почему ? И почему вероятность ?

miksoft
А вот потребление CPU может возрасти очень значительно.
Это очень зависит от схемы компрессии. Понятно, что rar и даже менее ресурсоёмкий zip никто не встраивает в СУБД (разве что в очень специальных случаях).
Необходимо также учитывать то, что мощность CPU растёт гораздо быстрее скорости дисковых систем. Может быть SSD что-то изменит, но пока что оно не годится для массового применения.
Насколько я вижу по статистике ваших постов, вы работаете с InterBase и/или Firebird.
Вот на их примере и покажите, плиз, выполнение операции апдейта одной записи в сжатой таблице таким образом, чтобы это дало и практическое сокращение IO для этого апдейта, и неувеличение такового для последующих чтений этой же записи. "Схему компрессии" придумайте/выберите на свой вкус.
19 май 09, 22:40    [7201062]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
miksoft
Member

Откуда:
Сообщений: 38918
hvlad
А вот индексы в FB жмутся очень хорошо.
Жмутся как именно? префиксно или а-ля zip ?
19 май 09, 22:44    [7201071]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
miksoft
Насколько я вижу по статистике ваших постов, вы работаете с InterBase и/или Firebird
Выделенное - неправильно. Правильно: "Вы работаете НАД..." ;)))
19 май 09, 22:45    [7201075]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
miksoft
Member

Откуда:
Сообщений: 38918
Senya_L
miksoft
Насколько я вижу по статистике ваших постов, вы работаете с InterBase и/или Firebird
Выделенное - неправильно. Правильно: "Вы работаете НАД..." ;)))
Прошу простить, был не в курсе.
19 май 09, 22:46    [7201082]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
hvlad
Member

Откуда:
Сообщений: 11551
miksoft
Вот на их примере и покажите, плиз, выполнение операции апдейта одной записи в сжатой таблице таким образом, чтобы это дало и практическое сокращение IO для этого апдейта, и неувеличение такового для последующих чтений этой же записи. "Схему компрессии" придумайте/выберите на свой вкус.
А зачем это мне нужно ?

PS Подумайте ещё раз над моим предыдущим сообщением, нет в Firebird'е никаких "сжатых таблиц".
19 май 09, 23:06    [7201138]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
hvlad
Member

Откуда:
Сообщений: 11551
miksoft
hvlad
А вот индексы в FB жмутся очень хорошо.
Жмутся как именно? префиксно или а-ля zip ?
Префиксная компрессия ключей плюс отбрасывание хвостовых пробелов строк.
19 май 09, 23:10    [7201150]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
miksoft
Member

Откуда:
Сообщений: 38918
hvlad
А зачем это мне нужно ?
Чтобы понять "почему вероятность".
hvlad
PS Подумайте ещё раз над моим предыдущим сообщением, нет в Firebird'е никаких "сжатых таблиц".
А я и не говорил, что они там есть. Я лишь попросил предложить "схему компрессии", которая дала бы вероятность (а лучше - уверенность) сокращения IO на примере Firebird-а.
19 май 09, 23:13    [7201161]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
miksoft
Member

Откуда:
Сообщений: 38918
hvlad
miksoft
hvlad
А вот индексы в FB жмутся очень хорошо.
Жмутся как именно? префиксно или а-ля zip ?
Префиксная компрессия ключей плюс отбрасывание хвостовых пробелов строк.
Тогда это тоже "с некоторой вероятностью".
Уникальное (или близкое к тому) поле в начало индекса и вся компрессия сразу исчезает.
19 май 09, 23:16    [7201168]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
hvlad
Member

Откуда:
Сообщений: 11551
miksoft
hvlad
А зачем это мне нужно ?
Чтобы понять "почему вероятность".
Я совершенно не понимаю, что вы мне хотите сказать

miksoft
hvlad
PS Подумайте ещё раз над моим предыдущим сообщением, нет в Firebird'е никаких "сжатых таблиц".
А я и не говорил, что они там есть. Я лишь попросил предложить "схему компрессии", которая дала бы вероятность (а лучше - уверенность) сокращения IO на примере Firebird-а.
В Firebird'е нет разных схем хранения записей. Соответственно невозможно, не трогая исходников, сравнить IO с и без сжатия записей. Так что всё, что вам остаётся - поверить мне, или привести обоснование (лучше практический пример) того, что сжатие может увеличить IO.
Ещё можно закончить этот разговор, оставшись при своих.
19 май 09, 23:40    [7201240]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
hvlad
Member

Откуда:
Сообщений: 11551
miksoft
hvlad
Префиксная компрессия ключей плюс отбрасывание хвостовых пробелов строк.
Тогда это тоже "с некоторой вероятностью".
Уникальное (или близкое к тому) поле в начало индекса и вся компрессия сразу исчезает.
С чего бы это ? Или спорим о вкусе устриц с тем, кто их ест ?

Берёте свою любимую таблицу и индексы из той СУБД, в которой вы работаете, переносите её в Firebird, снимаете статистику и смотрите на кол-во страниц под данные и индексы, средний р-р записи и ключа индекса, сравниваете с оригиналом.
19 май 09, 23:43    [7201247]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

hvlad wrote:
> Т.е. уменьшить IO за счёт CPU - это сомнительная фича ?

Нет. Но думаю не получится. В общем случае. В каких-то
частностях ещё может быть (типа read-only БД, или ещё
какая-то экзотика).

Posted via ActualForum NNTP Server 1.4

20 май 09, 00:34    [7201348]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

SERG1257 wrote:
> Компрессия эффективна только для всяких DWH приложений с денормализацией
> и большим размером блока (там есть где разгулятся)

Ну, да, вот тут соглашусь. Там ещё хранение по колонкам может помочь
сильно -- в колонах как правило данные сильно повторяются, там
из них словари удобно делать.

Posted via ActualForum NNTP Server 1.4

20 май 09, 00:36    [7201351]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
miksoft
Member

Откуда:
Сообщений: 38918
hvlad
В Firebird'е нет разных схем хранения записей.
Первоначально я просил "придумать" возможную схему компрессии. Если вас так сбивает слово "Firebird", то вычеркните его и замените на "некую асбстрактную СУБД".
hvlad
Так что всё, что вам остаётся - поверить мне, или привести обоснование (лучше практический пример) того, что сжатие может увеличить IO.
Пример:
Допустим, есть сжатый по zip-образномуалгоритму логический блок таблицы. Он размещается целиком в физическом блоке меньшего размера. Происходит апдейт записи в этом блоке. Новые данные (пусть даже той же "несжатой" длины) перестают умещаться в один физический блок и надо писать уже два блока. Причем либо один на прежнем месте, второй на новом, либо оба на новом. Думаю, накладные расходы в обоих случаях можете себе представить.

hvlad
Ещё можно закончить этот разговор, оставшись при своих.
Видимо, так и придется поступить... по крайней мере, на сегодня...
20 май 09, 00:36    [7201352]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

miksoft wrote:

> Жмутся как именно? префиксно или а-ля zip ?

Да префиксно, конечно. как ещё можно сжать индекс ?

Posted via ActualForum NNTP Server 1.4

20 май 09, 00:38    [7201357]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
miksoft
Member

Откуда:
Сообщений: 38918
hvlad
miksoft
hvlad
Префиксная компрессия ключей плюс отбрасывание хвостовых пробелов строк.
Тогда это тоже "с некоторой вероятностью".
Уникальное (или близкое к тому) поле в начало индекса и вся компрессия сразу исчезает.
С чего бы это ?
На всякий случай уточню, что термин "Префиксная компрессия ключей" я понимаю в том виде, в каком он существует в Оракле. Возможно, это не совпадает с Firebird-ным варинатом.
20 май 09, 00:39    [7201359]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
Dimitry Sibiryakov
Member

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

miksoft

Новые данные (пусть даже той же "несжатой" длины) перестают умещаться в
один физический блок и надо писать уже два блока. Причем либо один на
прежнем месте, второй на новом, либо оба на новом. Думаю, накладные
расходы в обоих случаях можете себе представить.

Ок, представляем. Напоминаю, что сравнение идёт со случаем несжатых
данных, в котором придётся писать уже не два, а как минимум три блока
(поскольку ни старые данные, ни новые в один блок не помещаются - это
Ваши условия задачи). Т.е. на Вашем примере компрессия даёт от 33
до 50% экономии времени ввода-вывода.

Posted via ActualForum NNTP Server 1.4

20 май 09, 01:00    [7201389]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
hvlad
Member

Откуда:
Сообщений: 11551
miksoft
hvlad
В Firebird'е нет разных схем хранения записей.
Первоначально я просил "придумать" возможную схему компрессии. Если вас так сбивает слово "Firebird", то вычеркните его и замените на "некую асбстрактную СУБД".
А зачем мне что-то придумывать, когда я точно знаю как это работает в Firebird ? Остальные СУБД меня интересуют только в плане более эффективных реализаций...

miksoft
Пример:
Допустим, есть сжатый по zip-образномуалгоритму логический блок таблицы. Он размещается целиком в физическом блоке меньшего размера. Происходит апдейт записи в этом блоке. Новые данные (пусть даже той же "несжатой" длины) перестают умещаться в один физический блок и надо писать уже два блока. Причем либо один на прежнем месте, второй на новом, либо оба на новом. Думаю, накладные расходы в обоих случаях можете себе представить.
Вы упоминаете zip-образный алгоритм, но не понятно к чему это.

Cжатые записи будут реже выходить за границы физ. страницы при апдейтах, чем несжатые т.к. каждая сжатая запись занимает меньше места. Это нужно доказывать ?
На самом деле в Firebird при апдейте создаётся новая версия записи и дельта между нею и старой версией, так что реальные процессы сложнеео описать в 2-х словах, во всяком случае я не собираюсь это тут делать.

Или вы о хранении записей с фиксированной длиной говорите, как в dbf ? В этом случае смешно даже сравнивать

Я не могу себе представить, почему обе страницы (старую и новую) нужно писать на новом месте. В любом случае это не влияет на кол-во IO writes - в обоих случаях нужно писать 2 страницы.

В том что вы написали я не вижу обоснования - почему сжатие увеличит IO ?

Возможно вы имеете в виду какое-то специфическое сжатие ? Я выше описал, как это происходит в Firebird.

miksoft
hvlad
Ещё можно закончить этот разговор, оставшись при своих.
Видимо, так и придется поступить... по крайней мере, на сегодня...
Не возражаю. И на завтра тоже :)
20 май 09, 01:09    [7201396]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
miksoft
Member

Откуда:
Сообщений: 38918
Dimitry Sibiryakov
Ок, представляем. Напоминаю, что сравнение идёт со случаем несжатых
данных, в котором придётся писать уже не два, а как минимум три блока
(поскольку ни старые данные, ни новые в один блок не помещаются - это
Ваши условия задачи). Т.е. на Вашем примере компрессия даёт от 33
до 50% экономии времени ввода-вывода.
Почему три? Храниться те же записи будут в двух блоках, а записать достаточно будет один блок, тот в котором находится изменяемая запись.
20 май 09, 01:11    [7201399]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
hvlad
Member

Откуда:
Сообщений: 11551
miksoft
hvlad
miksoft
Уникальное (или близкое к тому) поле в начало индекса и вся компрессия сразу исчезает.
С чего бы это ?
На всякий случай уточню, что термин "Префиксная компрессия ключей" я понимаю в том виде, в каком он существует в Оракле. Возможно, это не совпадает с Firebird-ным варинатом.
Если хотите, покажите на реальном примере компрессию ключей в индексе Оракла, а я покажу как это будет выглядеть в Firebird.
20 май 09, 01:11    [7201400]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
miksoft
Member

Откуда:
Сообщений: 38918
hvlad
Cжатые записи будут реже выходить за границы физ. страницы при апдейтах
Имхо, в общем случае - неочевидно, сильно зависит от характера данных.
hvlad
Или вы о хранении записей с фиксированной длиной говорите, как в dbf ?
Нет, конечно. Видимо, каждый из нас думает в свой пространстве умолчаний, отличном от такового у других :)

hvlad
Я не могу себе представить, почему обе страницы (старую и новую) нужно писать на новом месте. В любом случае это не влияет на кол-во IO writes - в обоих случаях нужно писать 2 страницы.
Например, потому, что одна многоблочная операция дешевле, чем несколько одноблочных при равном количестве блоков.

hvlad
В том что вы написали я не вижу обоснования - почему сжатие увеличит IO ?
Изначально вопрос вами был поставлен так:
hvlad
miksoft
то вероятность уменьшения IO, имхо, сильно сокращается.
Почему ? И почему вероятность ?
слово "увеличит" не вижу...
20 май 09, 01:23    [7201408]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
Dimitry Sibiryakov
Member

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

miksoft
Почему три?

Потому что я неверно прочитал условия. Для меня "логический блок" это
ровно одна запись, в то время как Вы говорите о большом их количестве.

Влад, я, кажется, понял, что нам пытается miksoft объяснить. Смотри:
происходит update записи данными, которые сжимаются не так хорошо как
предыдущие и при этом на странице уже нет резерва места. Что при
этом произойдёт:

Firebird - сплит страницы, запись двух страниц данных;
Oracle без сжатия - сплита нет, запись двух страниц (данные+лог);
Oracle со сжатием - сплит и запись трёх страниц (две данных+лог);
DBASE (сжатия нет по определению) - сплита нет, запись одной страницы.

Вот только что это доказывает? Что однопользовательский DBASE быстрее
многопользовательских серверов? Так это как бы общеизвестно... Что в
этом (наихудшем) сценарии Oracle проигрывает? Так сейчас прибежит Ё и
скажет, что это фигня и sparse write всё компенсирует. И, собственно,
именно поэтому сжатие в Оракуле опционально и по умолчанию выключено.

Нет, конечно, он может сказать, что DBASE (в своей FoxPro ипостаси)
бывает многопользовательским, но согласно учению eugenkru, для
обеспечения snapshot на нём приходится использовать буферные таблицы,
что увеличивает количество ввода-вывода при чтении в N раз, где N =
числу пользователей.

Posted via ActualForum NNTP Server 1.4

20 май 09, 12:03    [7202880]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
vasilis
vazhnecki
Грамотно это реализовать может только сама СУБД.
Существуют ли такие СУБД ?

Informix Dynamic Server data compression and storage optimization
Save storage resources, reduce I/O, and optimize performance with new IDS features
http://www.ibm.com/developerworks/data/library/techarticle/dm-0904idsoptimization/index.html?ca=drs-&ca=dkw-informix


Смотрел ссылку по Informix'у. Реализовано "словарное" сжатие данных. В зависимости от структуры и данных есть варианты когда экономия очевидна. Кому-то пригодится, а кому-то ни в дугу. Говорить о процентном соотношение "осчастливленных" реально - не на чем. А индексы, между прочим, сами по себе являются средством "сжатия I/O" :). А кто говорит, что "компрессия данных" должна приводить к уменьшению объёма устройств хранения памяти (HDD+RAM+...)? :)
20 май 09, 12:07    [7202908]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
miksoft
Допустим, есть сжатый по zip-образномуалгоритму логический блок таблицы. Он размещается целиком в физическом блоке меньшего размера.


это ужасно. Надеюсь что нет таких СУБД, которые сжимают целиком содержимое "блоков" или страниц.
Давайте лучше рассмотрим разные варианты сжатия, которые имеются, последовательно, от отсутствия сжатия до например того, что мне известно о Firebird.

Итак, если ничего не сжимается:
- записи хранятся полной длины. Например, если есть столбец varchar(1024), то так на диске 1к и хранится, независимо от содержимого.
- ключи хранятся тоже по полной длине, причем даже есть два рядом одинаковых ключа, они так и хранятся - ключ+ссылка на запись.

Теперь, варианты сжатия ключей, последовательно:
1. не хранить концевые пробелы для строк, или записывать кол-во концевых пробелов. Для чисел - убирать "лишние" нули.

2. префиксное сжатие следующего ключа на основании значения предыдущего. Например, есть ключи "Иванов и "Иванова". При сжатии во втором ключе мы напишем "6а"

3. для одинаковых ключей вообще их не хранить, а формировать список номеров записей для конкретного ключа. Например есть
Иванов 50
Иванов 55
вместо этого записать ключ Иванов и к нему 2 ссылки на записи 50 и 55.

в ФБ используются все 3 способа. Описание есть в статье
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert1

реальный пример:
таблица с 2189152 записей integer. Индекс первичного ключа занимает 12.63 мегабайта, средняя длина ключа равна 1 байту. Если ничего не сжимать, и взять размер ключа по минимуму - 4 байта значение (integer) и 8 байт ссылка на запись, то такой теоретический индекс занимал бы 25 мегабайт (с тем же числом ключей). Замечу, что это УНИКАЛЬНЫЙ индекс, где ключи не повторяются. Но зато они упаковываются потому, что числа обычно идут подряд :-)

В этой же таблице индекс по GUID varchar(16), заполненный одним (!) значением занимает 8.38 мегабайт. Тут "упаковка" максимальная, т.к. на самом деле ключ один, и 2 миллиона ссылок на записи. (индекс бесполезный, кстати).

могу еще практические примеры привести, у меня их навалом.

Теперь сжатие записей:
1. у строк не хранить концевые пробелы или записывать кол-во концевых пробелов. То есть запись получается переменной длины.

реальный пример - в таблице из столбцов vchar(32), vchar(32), char(1), vchar(64), vchar(512) при максимально возможном размере записи в 649 байт средний размер записи - 169 байт.
Или, таблица с примерно 20-ю столбцами и макс. размером записи в 868 байт на деле имеет средний размер записи 124 байта.
Понятно что это данные по конкретной БД и конкретным таблицам, но в среднем в IB/FB реальные данные на диске занимают примерно в 3 раза меньше чем посчитанная по размеру полей структура таблицы.

2. тут лучше пусть hvlad допишет :-)

я же добавлю еще ссылку на структуру страниц ФБ:
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert2
20 май 09, 12:18    [7202965]     Ответить | Цитировать Сообщить модератору
 Re: СУБД с поддержкой компресии данных и индексов  [new]
Yo.!
Guest
Dimitry Sibiryakov

Так сейчас прибежит Ё и
скажет, что это фигня и sparse write всё компенсирует. И, собственно,
именно поэтому сжатие в Оракуле опционально и по умолчанию выключено


не угадал, я скажу что конкретно фанатики ФБ могут отключить писанину лога и жить счастливо без него, почти также как они живут на ФБ. раз даже на своих ошибках они не учатся - это будет вполне здравый совет.

Dimitry Sibiryakov
Нет, конечно, он может сказать, что DBASE (в своей FoxPro ипостаси)
бывает многопользовательским, но согласно учению eugenkru, для
обеспечения snapshot на нём приходится использовать буферные таблицы,
что увеличивает количество ввода-вывода при чтении в N раз, где N =
числу пользователей.


чем вызвана сия фантазия ? буферизация у фокспро на клиенте происходит и снепшот там при всем желании ...
20 май 09, 13:46    [7203645]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить