Тем, что оно существенно снижает потребление ресурсов системы. Весьма существенно.

Таки постгрессовское не слабо помогает.

@alexey_kopytov справедливости для стоит таки заметить, что пгпро только начали пилить своб компрессию, а в мыскле (иннодиби), оно уже хорошо обкатано.

Согласен, вместо LEFT JOIN нужен JOIN

Я в вопрос особо не вникал... но это что, EAV?

Таки постгрессовское не слабо помогает.

Я таки не зря спросил про тестирование. И то, что у Дарафея оно не ломается - совсем лично для меня не показатель.

лучше ты не кури вот это вот, что ты там куришь

Я не курю

Я таки не зря спросил про тестирование. И то, что у Дарафея оно не ломается - совсем лично для меня не показатель.

с 1С тестировали довольно активно, в лицо не взрывается, жмет в 4-5 раз, дает хороший выигрыш по tps за счет более эффективного кэширования в файловом кэше

@alexey_kopytov справедливости для стоит таки заметить, что пгпро только начали пилить своб компрессию, а в мыскле (иннодиби), оно уже хорошо обкатано.

я в курсе, да. и сделать правильно сжатие — это сложная задача. я почитал дизайн сжатия в ПгПро и как-то совсем не впечатлился. оно под серьёзной нагрузкой умрёт

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

Я таки не зря спросил про тестирование. И то, что у Дарафея оно не ломается - совсем лично для меня не показатель.

Я пытался насиловать его по разному. Не с реальной нагрузкой, но весьма извращенно. Развалить не смог. Конечно, это не 100% показатель: кабель из компьютера я не выдирал, а без этого тестирование нельзя считать полным.

я могу сказать, что компрессию в innodb все тоже считали стабильной, пока её не потестировал facebook. по результатам чего заслал тонны патчей в Оракл

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

Гриш, а это, по-моему на некоторых профилях нагрузки и на оригинальном ПГ наблюдается.

Гриш, а это, по-моему на некоторых профилях нагрузки и на оригинальном ПГ наблюдается.

например?

например?

На транкейтах

я в курсе, да. и сделать правильно сжатие — это сложная задача. я почитал дизайн сжатия в ПгПро и как-то совсем не впечатлился. оно под серьёзной нагрузкой умрёт

Не умирает. Единственная проблема дизайна: сборка мусора. Она может зафризить запросы к таблице на сотни миллисекунд. Так что, для "реального времени" и сайтов со строгих коитериев к латенси не подходит.

Я таки не зря спросил про тестирование. И то, что у Дарафея оно не ломается - совсем лично для меня не показатель.

Ну это общая проблема fork-ов PostgreSQL —- пользовательская база меньше (тестируется меньше), разработчики "слабее"... разве нет?

например?

А я сейчас помню все разговоры в курилках?! о_О

Не умирает. Единственная проблема дизайна: сборка мусора. Она может зафризить запросы к таблице на сотни миллисекунд. Так что, для "реального времени" и сайтов со строгих коитериев к латенси не подходит.

скажем так, есть несколько возможных подходов для реализации сжатия. В InnoDB есть целых два: самый наивный (которым никто не пользуется) и самый продвинутый (которым все пользуются). В ПгПро реализовано что-то среднее. То есть, оно не совсем наивное, но достаточно наивно, чтобы вызывать проблемы под нагрузкой

На транкейтах

из-за необходимости обхода всех страниц в буфере?

Не умирает. Единственная проблема дизайна: сборка мусора. Она может зафризить запросы к таблице на сотни миллисекунд. Так что, для "реального времени" и сайтов со строгих коитериев к латенси не подходит.

Ой, ну я тебя умоляю! У меня ручонки не добрались до него, вот оно и не умирает.

из-за необходимости обхода всех страниц в буфере?

Вроде как да

скажем так, есть несколько возможных подходов для реализации сжатия. В InnoDB есть целых два: самый наивный (которым никто не пользуется) и самый продвинутый (которым все пользуются). В ПгПро реализовано что-то среднее. То есть, оно не совсем наивное, но достаточно наивно, чтобы вызывать проблемы под нагрузкой

Зависит от нагрузки. Если есть требование к латенси в любой момент времени, то да. Если 500ms раз в несколько часов - не страшно, то норм.

Зависит от нагрузки. Если есть требование к латенси в любой момент времени, то да. Если 500ms раз в несколько часов - не страшно, то норм.

а откуда взялись вот эти абсолютные величины в latency?

Ой, ну я тебя умоляю! У меня ручонки не добрались до него, вот оно и не умирает.

Согласен, карма и природный талант - опасное сочетание ? (без обид)

Зависит от нагрузки. Если есть требование к латенси в любой момент времени, то да. Если 500ms раз в несколько часов - не страшно, то норм.

Место может кончиться раньше gc же?

а откуда взялись вот эти абсолютные величины в latency?

Попытками его померять, и усилиями по его уменьшению.

Согласен, карма и природный талант - опасное сочетание ? (без обид)

* делая наглую, самодовольную харю морды лиТса Помимо кармы и таланта в наличии имеются: профильная вышка и опыт эксплуатации с 1998 г, когда 95-я, 98-я винды не вот уж падали. ЗЫ. Да, скромность - одна из моих потерянных добродетелей.

В жестком тестировании это максимум 2 секунды раз в несколько минут. Но мне сложно представить прод, генерирующий такой профиль нагрущки.

Место может кончиться раньше gc же?

там есть механизм принудительного gc, если сегмент распух до 2Gb, если я правильно помню

Кстати, а как компрессионный ГЦ с вакуумом уживается...

В жестком тестировании это максимум 2 секунды раз в несколько минут. Но мне сложно представить прод, генерирующий такой профиль нагрущки.

а жесткое тестирование — это pgbench?

Кстати, а как компрессионный ГЦ с вакуумом уживается...

Приходит после него и дочищает

Кстати, а как компрессионный ГЦ с вакуумом уживается...

Они друг другу перпендикулярны.

а жесткое тестирование — это pgbench?

Хоть и да? Эта фича локальна для каждого гигабайта данных в конкретной таблице, и абсолютно пофиг, что генерит апдейты в нее.

ну это несерьёзно. вы же понимаете, что мир реальных нагрузок /немного/ разнообразнее pgbench

и запускать pgbench, получать какие-то цифры, и говорить "так и запишем, latency не более 500ms" — это несколько ненаучный подход

ну это несерьёзно. вы же понимаете, что мир реальных нагрузок /немного/ разнообразнее pgbench

Для данной фичи - по барабану. Хотя если брать в общем, то ты прав.

Еще мы заметили, что индексы на критичных таблицах лучше не жать

да в общем и за latency в 500ms в некоторых компаниях удавятся

и запускать pgbench, получать какие-то цифры, и говорить "так и запишем, latency не более 500ms" — это несколько ненаучный подход

И я сказал: под pgbench максимум две секунды раз несколькл минут. Но такой поток апдейтов - это слишком дофига. В жизни проблемы начнутся раньше в других местах.

Денег на диски не хватает?

Северный лис с дисками, но не это главное. В таблицах логи стааарые их изредко поднимают на посмотреть за лохматый месяц вшивого года. Т.е. считай один запро в неделю. Я запилил для секции за -lt 20140101, на btrfs и вродикак все норм, но есть сомнения.

Блин я даже не сразу понял.

В тех случаях, когда скорость работы базы в основном определяется временем чтения/записи на диск, компрессия можеит существенно ускорить работу - иногда почти пропорционально степени сжатия. Ну и место на диске иногда лишним не бывает. Компрессию данных придумали не в innodb и что там такого продвинутого я не понимаю. Оттестирвано оно у них наверное лучше чем у нас - да Fqacebook-у мы PgPro не продовали:) В качестве альтернативы можно поставить zfs.

В тех случаях, когда скорость работы базы в основном определяется временем чтения/записи на диск, компрессия можеит существенно ускорить работу - иногда почти пропорционально степени сжатия. Ну и место на диске иногда лишним не бывает. Компрессию данных придумали не в innodb и что там такого продвинутого я не понимаю. Оттестирвано оно у них наверное лучше чем у нас - да Fqacebook-у мы PgPro не продовали:) В качестве альтернативы можно поставить zfs.

так себе альтернатива, в файловом кэше страницы будут лежать уже декомпрессированными

В тех случаях, когда скорость работы базы в основном определяется временем чтения/записи на диск, компрессия можеит существенно ускорить работу - иногда почти пропорционально степени сжатия. Ну и место на диске иногда лишним не бывает. Компрессию данных придумали не в innodb и что там такого продвинутого я не понимаю. Оттестирвано оно у них наверное лучше чем у нас - да Fqacebook-у мы PgPro не продовали:) В качестве альтернативы можно поставить zfs.

как будто я где-то говорил, что компрессию придумали в innodb. вот эти передёргивания, они зачем? и нет, компрессия на уровне ФС это не замена встроенной компрессии в СУБД

В тех случаях, когда скорость работы базы в основном определяется временем чтения/записи на диск, компрессия можеит существенно ускорить работу - иногда почти пропорционально степени сжатия. Ну и место на диске иногда лишним не бывает. Компрессию данных придумали не в innodb и что там такого продвинутого я не понимаю. Оттестирвано оно у них наверное лучше чем у нас - да Fqacebook-у мы PgPro не продовали:) В качестве альтернативы можно поставить zfs.

и да, я могу подготовить развёрнутый ответ на вопрос "а что там такого продвинутого?". это плохо в формат чатика умещается, но я попробую. Пользуясь случаем: где найти самое свежее описание компрессии в pgpro и желательно код?

и да, я могу подготовить развёрнутый ответ на вопрос "а что там такого продвинутого?". это плохо в формат чатика умещается, но я попробую. Пользуясь случаем: где найти самое свежее описание компрессии в pgpro и желательно код?

Ну так лучше сразу дать развёрнутый ответ, чем писать "это какой-то детский лепет по сравнению с тем, что в innodb" и потом ещё говорить про передёргивания. А то вылил кучу помоев вместо какой-то полезной информации.

DriveSpace!

и да, я могу подготовить развёрнутый ответ на вопрос "а что там такого продвинутого?". это плохо в формат чатика умещается, но я попробую. Пользуясь случаем: где найти самое свежее описание компрессии в pgpro и желательно код?

Может имеет смысл где-нибудб в блоге, а сюда - ссылку? Я бы почитал...

Ну так лучше сразу дать развёрнутый ответ, чем писать "это какой-то детский лепет по сравнению с тем, что в innodb" и потом ещё говорить про передёргивания. А то вылил кучу помоев вместо какой-то полезной информации.

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

а ответы на мои вопросы про документацию и код будут?

- чем лучше? - чем грузины

Компресия на уровне ОС может достаточно успешно замещать компресию на уровне ДБ. Например её успешно используют в Nutanix. Да, в кэши ОС будут расжатые страниццы (как и в случае кэша СУБД). Это с одной стороны минус (меньше данных влезает в память), с другой стороны плюс - доступ к уже прокэшированным данным не требует дополнительного overhead-а. Основные агрументы в пользу кмпрессии на уровне БД: - не всё надо компрессировать - не всегда можно позволить себе поставить спецтальную FS

всем привет

подскажите, пожалуйста, что-нибудь для комплексного мониторинга постгреса

Компресия на уровне ОС может достаточно успешно замещать компресию на уровне ДБ. Например её успешно используют в Nutanix. Да, в кэши ОС будут расжатые страниццы (как и в случае кэша СУБД). Это с одной стороны минус (меньше данных влезает в память), с другой стороны плюс - доступ к уже прокэшированным данным не требует дополнительного overhead-а. Основные агрументы в пользу кмпрессии на уровне БД: - не всё надо компрессировать - не всегда можно позволить себе поставить спецтальную FS

понятно. ответов на мои вопросы, как я понимаю, не будет. шутите тогда про грузинов дальше

понятно. ответов на мои вопросы, как я понимаю, не будет. шутите тогда про грузинов дальше

на наши вопросы ответов тоже как-то не наблюдается, вот и шутим

а ответы на мои вопросы про документацию и код будут?

Компрессия - часть PgPro EE. Это коммерческий продукт с документацией сурсами и.т.п. Я лично выложить ни то, ни другое не могу. Сcылка на презентацию была выше. С тех пор мы много чего в компрессии улучшили, в основном в отношении GC (огромное спасибо Юре Соколову), но сам принцип остался тем же.

на наши вопросы ответов тоже как-то не наблюдается, вот и шутим

зайка, я же написал, что это требует развёрнутого ответа, который в чатике дать тяжело. пообщал это сделать. попросил дополнительную информацию. в ответ получил натужную шутку про грузинов. дважды!

Компресия на уровне ОС может достаточно успешно замещать компресию на уровне ДБ. Например её успешно используют в Nutanix. Да, в кэши ОС будут расжатые страниццы (как и в случае кэша СУБД). Это с одной стороны минус (меньше данных влезает в память), с другой стороны плюс - доступ к уже прокэшированным данным не требует дополнительного overhead-а. Основные агрументы в пользу кмпрессии на уровне БД: - не всё надо компрессировать - не всегда можно позволить себе поставить спецтальную FS

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

такие дела.

Компрессия - часть PgPro EE. Это коммерческий продукт с документацией сурсами и.т.п. Я лично выложить ни то, ни другое не могу. Сcылка на презентацию была выше. С тех пор мы много чего в компрессии улучшили, в основном в отношении GC (огромное спасибо Юре Соколову), но сам принцип остался тем же.

не понял. то есть, даже документации в открытом доступе нет? как ЭТО тогда вообще можно обсуждать

Я не знаю, может и есть... Я не проверял. Чукча не чатель, чукча - писатель:)

зайка, я же написал, что это требует развёрнутого ответа, который в чатике дать тяжело. пообщал это сделать. попросил дополнительную информацию. в ответ получил натужную шутку про грузинов. дважды!

малыш, ты вроде как несколько раз подряд упоминал, что компрессия в innodb лучше, вот я интересируюсь чем. Не исключаю, что это именно так на самом деле

ух тут жесть в чатике войны за будущее СУБД

не понял. то есть, даже документации в открытом доступе нет? как ЭТО тогда вообще можно обсуждать

А вот это уже странно, ибо, ВНЕЗАПНО! на сайте компании: https://postgrespro.ru/docs/enterprise/10/cfs

малыш, ты вроде как несколько раз подряд упоминал, что компрессия в innodb лучше, вот я интересируюсь чем. Не исключаю, что это именно так на самом деле

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

Ребята, давайте жить дружно. От того, что мы будем друг друго прилюдно оскорблять - никому лучше не станет. Давйте постаемся обсуждать с минимумом эмоций и с максимум объективности.

А вот это уже странно, ибо, ВНЕЗАПНО! на сайте компании: https://postgrespro.ru/docs/enterprise/10/cfs

вот, я же помню, что был сарайчик!

а где тут оскорбления? сплошная любовь. и вас всех я люблю. (и когда-нибудь обязательно найду, шутка!)

Лучше постарайся обйтись без этих "солнышек", "заек" и.т.п.

лучше постарайтесь обойтись без рекомендаций мне. и тогда от меня их тоже не услышите

Почитал по диагонали дизайн в innodb. В innodb дизайн действительно сложный и многослойный. Наверняка, в определенных ситуациях он лучше. Дизайн в постгресс-про - это те самые 20% усилий, что дают 80% профита. И мне сложно назвать такой подход "детским лепетом". Скорее, здоровый консервативный подход: снять сливки, посмотреть на результат.

а где тут оскорбления? сплошная любовь. и вас всех я люблю. (и когда-нибудь обязательно найду, шутка!)

Нас найти не трудно, все контакты на сайте ;)

Почитал по диагонали дизайн в innodb. В innodb дизайн действительно сложный и многослойный. Наверняка, в определенных ситуациях он лучше. Дизайн в постгресс-про - это те самые 20% усилий, что дают 80% профита. И мне сложно назвать такой подход "детским лепетом". Скорее, здоровый консервативный подход: снять сливки, посмотреть на результат.

"детский лепет" — оценочное суждение. я так понимаю, мы в общем говорим об одном и том же, но в разных выражениях. Да, можно простую реализацию называть "20% усилий". можно наивной реализацией. а можно и детским лепетом. оценки такие оценки

Чёта какой-то срачик слабоватый. Надо, однако, по "логической" репликации, этому лютому позорищу всего ПГ сообщества пройтись. Заодно и по тому, что там какие-то кеши какой-то файловой системы...

Нас найти не трудно, все контакты на сайте ;)

ой вей, а вот и мой любимый персонаж. ну, после Миши Тюрина, конечно. как дела?

В тех случаях, когда скорость работы базы в основном определяется временем чтения/записи на диск, компрессия можеит существенно ускорить работу - иногда почти пропорционально степени сжатия. Ну и место на диске иногда лишним не бывает. Компрессию данных придумали не в innodb и что там такого продвинутого я не понимаю. Оттестирвано оно у них наверное лучше чем у нас - да Fqacebook-у мы PgPro не продовали:) В качестве альтернативы можно поставить zfs.

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

А то я часто от разрабов ПГ слышу: вот, кеш файловой системы - то, кеш файловой системы - сё. И меня немного начинает такой подход нервировать, потому что в Рамблере меня не только плохому научили, но и очень плохому. Например, наглядно показали разницу между чтением из памяти и чтением из тмпфс (прокфс, если быть точным). После того показа, когда разработчик начинает лепетать про кэш ФС, я хочу этого разработчика чем-нибудь стукнуть. Тяжёлым. Чтобы мозгами по мостой раскинул.

Соответственно, когда демон репликации вычитывает WAL, мне это непонятно. А когда ещё и непонятно во что и как преобразовывает - непонятно становится от слова совсем.

Компресия на уровне ОС может достаточно успешно замещать компресию на уровне ДБ. Например её успешно используют в Nutanix. Да, в кэши ОС будут расжатые страниццы (как и в случае кэша СУБД). Это с одной стороны минус (меньше данных влезает в память), с другой стороны плюс - доступ к уже прокэшированным данным не требует дополнительного overhead-а. Основные агрументы в пользу кмпрессии на уровне БД: - не всё надо компрессировать - не всегда можно позволить себе поставить спецтальную FS

Не всё компрессирую. Сделал tablespace слил в него секции с очень старьём. https://www.ixsystems.com/blog/open-zfs-vs-btrfs/ ZFS vs BTRFS - я так понял что всётаки надо на BTRFS уходить.

А то я часто от разрабов ПГ слышу: вот, кеш файловой системы - то, кеш файловой системы - сё. И меня немного начинает такой подход нервировать, потому что в Рамблере меня не только плохому научили, но и очень плохому. Например, наглядно показали разницу между чтением из памяти и чтением из тмпфс (прокфс, если быть точным). После того показа, когда разработчик начинает лепетать про кэш ФС, я хочу этого разработчика чем-нибудь стукнуть. Тяжёлым. Чтобы мозгами по мостой раскинул.

Можете поподробнее?

Что поподробнее?

разговоры в курилке, когда я удивляюсь, что, оказывается, демон репликации вычитывает WAl-ы, а мне говорят, что они - в кеше ФС?

В чём именно существенная разница (или же, что неожиданного) между чтением из памяти и чтением из тмпфс?

Во времени?

Чёта какой-то срачик слабоватый. Надо, однако, по "логической" репликации, этому лютому позорищу всего ПГ сообщества пройтись. Заодно и по тому, что там какие-то кеши какой-то файловой системы...

Вот ещё один "эксперт" по срачу:) Этим Миша занимался весь год или больше в ПгПро. Остутствие знаний компенсируется желанием влезть в любую дискуссию и и там оставить свою кучку. Поэтому, прошу прощения, но на Мишины впросы и реплики я отвечать не буду.

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

Ну по-моему, решать эту проблему отдали СХД-хам.

Неожиданное - я как-то не придавал этому значения. Поэтому от наглядности не слегка был потрясён.

ой вей, а вот и мой любимый персонаж. ну, после Миши Тюрина, конечно. как дела?

Огонь дела. Читаю вот, жду за что зацепится. Пока только за поиски %)

Вот ещё один "эксперт" по срачу:) Этим Миша занимался весь год или больше в ПгПро. Остутствие знаний компенсируется желанием влезть в любую дискуссию и и там оставить свою кучку. Поэтому, прошу прощения, но на Мишины впросы и реплики я отвечать не буду.

Больше полутора.

Неожиданное - я как-то не придавал этому значения. Поэтому от наглядности не слегка был потрясён.

Так расскажите же! ;)

Что рассказать? разница - несколько порядков.

2 или 3. За давностью лет не помню.

Если не больше.

А то я часто от разрабов ПГ слышу: вот, кеш файловой системы - то, кеш файловой системы - сё. И меня немного начинает такой подход нервировать, потому что в Рамблере меня не только плохому научили, но и очень плохому. Например, наглядно показали разницу между чтением из памяти и чтением из тмпфс (прокфс, если быть точным). После того показа, когда разработчик начинает лепетать про кэш ФС, я хочу этого разработчика чем-нибудь стукнуть. Тяжёлым. Чтобы мозгами по мостой раскинул.

Так научили то чему, раскажи уж , аллегории все эти они конечно хороши ,но не постоянно

Что рассказать? разница - несколько порядков.

А можно подробности? Чтение из памяти же тоже разным бывает. Сравнивалось чтение из файла в темпфс и замапленного в память?

Так научили то чему, раскажи уж , аллегории все эти они конечно хороши ,но не постоянно

Тому, что когда логика подразумевает работу с памятью, надо работать с памятью. А не с кешем файловой системы в данном конретном случае.