Разработчики из компании EnterpriseDB представили (http://amitkapila16.blogspot.ru/2018/03/zheap-storage-engine...) новое хранилище zheap (https://github.com/EnterpriseDB/zheap), которое предложено для включения в состав СУБД PostgreSQL 12. Хранилище zheap разработано для решения проблемы с разрастанием файлов с содержимым БД в результате фрагментации при обновлении содержимого записей и отличается от традиционного хранилища тем, что не требует в процессе эксплуатации периодического выполнения операции VACUUM.
Суть предложенного в zheap формата хранения данных на диске в сохранении в основном хранилище только актуальных данных и выносом старых версий записей в отдельный лог отката изменений. При выполнении операций обновления записей данные в основном хранилище заменяются по месту, без применения схемы copy-on-write. Блоки, освобождающиеся в результате операций удаления или выполнения транзакции, для которых невозможна замена данных по месту, могут оперативно повторно использоваться сразу после высвобождения. Подобные особенности позволяют улучшить контроль за разрастанием хранилища и сделать его более предсказуемым.
Новое хранилище также позволяет добиться увеличения производительности и сократить размер служебных данных. Увеличение производительности достигается благодаря сокращению операций записи, путём исключения перезаписи страниц и выборочного обновления только индексированных столбцов без обновления каждого индекса. Оптимизация размера обеспечивается благодаря сокращению размера блоков (сокращён заголовок и исключено добавочное заполнение для выравнивания блока).
Тестирование производительности показало общее увеличение производительности, сокращение размера хранилища и более эффективное выполнение операций отката изменений. Наибольший выигрыш в производительности (до 45%) достигается в условиях большого числа операций перезаписи, а также когда операция UPDATE приводит к обновлению небольшого числа проиндексированных столбцов. Применение zheap также позволяет избавиться от проседания производительности во время активации процесса autovacuum и сократить число операций записи в WAL-лог. Из недостатков zheap упоминается более ресурсоёмкое выполнение операций удаления и сброса транзакций, а также выполнение обновлений, затрагивающих большую часть проиндексированных столбцов.
URL: http://amitkapila16.blogspot.ru/2018/03/zheap-storage-engine...
Новость: https://www.opennet.ru/opennews/art.shtml?num=48214
Это же как у ORALCE c его роллбасл сегментом .... старое они оставят ?
> Это же как у ORALCE c его роллбасл сегментом .... старое они оставят ?We have provided a storage engine option which you can set when creating a table. For example:
create table t_zheap(c1 int, c2 varchar) with (storage_engine='zheap');
Начинается свистопляска аля MySQL.
Дык это с незапамятных времен было. Просто всех устраивает дефолтовый. Я думаю если бы в мускуле innodb был бы изначально по умолчанию, то myisam может и не вспомнил бы никто.
У myisam полнотекстовый поиск и быстрые insert/update в наиболее частом варианте использования. innodb было как минимум с четвертого мускула, но в те времена единственным его преимуществом были внешние ключи, которые большей части пыхеров были ненужны, так что myisam был предпочтительным вариантом вовсе не из-за использования в качестве дефолта.
> У myisam полнотекстовый поиск и быстрые insert/update в наиболее частом варианте использования.
> innodb было как минимум с четвертого мускула, но в те времена
> единственным его преимуществом были внешние ключи, которые большей части пыхеров были
> ненужны, так что myisam был предпочтительным вариантом вовсе не из-за использования
> в качестве дефолта.Была другая более фундаментальная причина. Пыхеры обычно обилием мозгов не отличаются, вернее -- отличаются их отсутствием. Поэтому понять недостатки myisam не могли в принципе. А чем меньше знаешь, тем лучше пища уваривается.
Но ты то не такой, ты ведь понял недостатки MyISAM для тех задач. Так поведай о них, блесни интеллектом.
Не знаю, как сейчас, а когда я имел дело с этим <censored>, myisam при записи лочил всю таблицу, тогда как innodb - только одну строку. А нарвался я на это дело, когда словил дикие тормоза после заливки в базу бэкапа - когда бэкап был с "create table", то вопреки настройкам таблицы почему-то создавались в myisam. Пришлось из бэкапа команды создания таблиц убрать, создать их вручную (только тогда она создала их в innodb), и заливать данные в базу с готовыми пустыми таблицами.
И это не единственный "подводный камень", на который я напоролся. Вобщем, воспоминания о мускуле у меня только матерные.
innodb был как минимум с 3.23, и его преимуществом было всегда прежде всего то, что:
1) это честный версионник,
2) он написан не Монти сотоварищи, которые в то время слабо себе представляли, что такое ACID, а людьми, которые отлично понимают принципы разработки СУБД.
Регулярно вылавливаю последствия сладкой групповушки из MySQL(MyISAM)+PHP(Joomla)+ПыхПыхбибизьяна. Когда таблица логов разрастается до пары млн. строк, сайт начинает дико тупить, мыскль дико шуршит диском, запросам вечный лок. Горчишник в виде перегонки таблиц в InnoDB помогает.
> но в те времена единственным его преимуществом были внешние ключиНе единственным и не главным.
Главное преимущество innodb - поддержка транзакций (которой до сих пор нет у MyISAM).
Т.е. ничего, серьезнее личного бложика, на MyISAM лучше не делать.
А ведь много у кого на mysql завязаны деньги клиентов...
> Начинается свистопляска аля MySQL.В данном случае не вижу в этом ничего плохого. Проблема мыскля не в этом, а в реализации (и, до последнего времени, в дефолтном myisam).
ураааа, мы победили vacuum, vacuum больше ненужно!
Опять...
> ураааа, мы победили vacuum, vacuum больше ненужно!
> Опять...Ну при наличии undo/rollback - действительно не нужно, нужно только purge
Vacuum/Autovacuum: We think that for delete-marked indexes we might not need vacuum, but we still need it for indexes that doesn't support delete-marking. Here, the idea is that by using undo technology we can change three-pass-vacuum to two-pass-vacuum. Currently any attempt to vacuum zheap will return error.
там ключевое слово - "опять" ;-)> Currently any attempt to vacuum zheap will return error.
я щетаю, прекрасно :-)
(то есть, по факту, сегодня эта "экономичная" разновидность стораджа растет вообще неограниченно, хотя и медленнее чем невакумленый обычный)ну, ладно, понятно что оно еще толком не родилось, подождем еще годик, вдруг чудо все же произойдет...
Плюсую. Однако надо помнить, что по ходу этот zheap добавляет лишние операции записи в оперативном периоде, тогда как vacuum и делается отложено и при ненадобности можно его выключить.
На тот случай, если не у всех есть fullflash схд - можно ли указать путь, где создавать/хранить индексы? Чтобы не приходилось их переносить вручную.
> На тот случай, если не у всех есть fullflash схд - можно
> ли указать путь, где создавать/хранить индексы? Чтобы не приходилось их переносить
> вручную.При создании индекса можно указать целевое ТП, где данные индекса будут размещены физически.
ZSTD сжатия до сих порт нет, inmemory таблиц до сих пор тоже нет. А обещали...
> ZSTD сжатия до сих порт нет, inmemory таблиц до сих пор тоже
> нет. А обещали...Зачем вот это вот inmemory? Вы хоть немного себе представляете как типичная современная СУБД работает, а? Ну вот если честно? Во всех современных СУБД ВСЯ ОБРАБОТКА и так inmemory, и по другому не бывает. Какое ещё inmemory вам нужно? Всякие неофиты крикливые выдумают очередной деревянный велосипед и давай радоваться тому, что уже лет 30-ть как повсеместно просто используется.
Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не нужно. Никуда и никак.Вместо того, чтобы отломать транзакции, героически борются с их следствиями уже почти 20 лет...
Строите проекты без consistency? Ну удачи, чо.
Фактически так жестко нужно наверно лишь в 10% случаев. Упрямые бараны, делают проблему из ничего. Ну пускай дальше землю бодают, есть куча альтернатив...
>есть куча альтернатив...Это - да! Иди в садовники :)
Выбрал ненужный в 90% случаев C и отказался от нужного в 90% случаях АСсзб чо
Это только у жабистов или-или. У нормальных людей - и то, и другое :-р
Местные "банкиры локалхоста" отменили теорему cap. Не сомневался
У нас частый случай, который покрывает 146% приложений, работающих с баблом.
А пиписки на заборе ... да хоть монгай рисуй :)
>Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не нужно. Никуда и никак.Из серии "Самые тупые фразы в ИТ. Золотое издание" из разряда:
* 90% времени отазоустойчивость не нужна
* 90% времени бэкап не нужен
* 90% проектов хватит одной базы данных на одном сервере у одного провайдера.Думаете, почему только 10% проектов успешны? Да потому что 90% обслуживают кретины.
>из разряда:
> * 90% времени отазоустойчивость не нужнаЭкспедры опеннета считают, постгрес в теореме о САР весь такой распупырчатый сразу всё умеет :) это ваше mvcc и бэкапы делать нормально не даёт, а только мееедленно и печально
Дык дело не в mvcc. Просто в постгре очень много чего не доделано в плане обслуживания самой БД. Даже вот миграция на новую версию без простоя можно делать только в 10-ке (логическая репликация). По факту для репликаций, бекапов пока только бубнами и сторонними проектами можно пользоваться.
Но все же караван идет...
Я не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно.
> не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно.Подрастёшь, узнаешь
>> не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно.
> Подрастёшь, узнаешьПодрасту я уже вряд ли. Давайте лучше примеры. В Оракле переход с версии на версию редкий гемор. В Сиквеле -- не лучше. В сибасе не лучше. В ДБ2 там полная изотерика. Что ещё предложите?
В орацле вообще всё - жуткий гемор. А то кто ж курсы купит.Тут интересно, Монго инк уже настолько раздухарились, что шлют спамчик про oracle->mongo replacement.
Ещё лет 10 и реляционные субд останутся только в банках.
А, отвечаю, в монге 3.2-3.4-3.6 процесс бесшовный
> В орацле вообще всё - жуткий гемор. А то кто ж курсы
> купит.
> Тут интересно, Монго инк уже настолько раздухарились, что шлют спамчик про oracle->mongo
> replacement.
> Ещё лет 10 и реляционные субд останутся только в банках.
> А, отвечаю, в монге 3.2-3.4-3.6 процесс бесшовныйОракл отлично документирован. Причём его освоение дёшево и доступно. Слон в этом плане за последние годы тоже сильно подтянулся: появилась и внятная документация, и книги, и методики.
Оракл же до сих хорош тем, что он, всё же, быстрый. Для честного MVCC очень быстрый.
Любая нормальная РСУБД быстрее Монго, если довести её до того же уровня недостоверности данных. Ну, скажем, в Оракле ACID не отключить и не обойти, но в Сиквеле или Слоне это возможно. После этого ваш Монго вообще теряет всякие преимущества: он значительно медленней, менее функциональный, инструментарий для него вообще убог до смешного. Поэтому Монго -- не нужен.
>Причём его освоение дёшево и доступноп1. А на нашей планете все курсы по Оракле от полтинника-сотни, даже самые плешивые на 3 дня.
п2. Про сертификацию молчу и сколько зарплаты хочет чувак, на которо слили лимон-другой бабла в п1>РСУБД быстрее Монго, если довести её до того же уровня недостоверности данных
Бред оф сив кэйбл. Это в Постгресе постоянно фиксят баги, которые теряют данные, причём БЕЗ отключения ACID.
>инструментарий для него вообще убог до смешного
О да, куда же консольке mongo до могучего sqlplus :))))))
По-моему, курсы по Ораклу совершенно бесполезны. У Оракла отличная публичная бесплатная документация и отличная библиография (разжёвано всё, что только имеет смысл жевать). К тому же, разрабу не нужна сертификация.
За 10 лет работы со Слоном ни разу с потерей данных из-за ошибок Слона не сталкивался. Да и не критично это при нормальной схеме резервного копирования.
Монго же в разы проигрывает Сиквелу в режиме грязного чтения. Зачем тогда этот Монго?
курсы-то полезны, просто они не для вас в основном - во всяком случае, все эти "за три дня стать dba" (на деле - сможешь долго и счастливо жить с не слишком большой оракловой базой, если руками никуда там не полезешь)хотя получить некоторое представление о том, как и что принято делать (не что вообще-то можно - на этот вопрос отвечает документация) - полезно, и тем более - разработчику.
а денег (если хороший) он и так хочет много (и дважды в месяц подавай, а не один раз заплатил, как за курсы, и навечно просветленный)
>У Оракла отличная публичная бесплатная документация и отличная библиографияКак могут быть отличной документацией талмуды на 100500 страниц про то, что само по себе является мегаусложненным крапом? Я вот понимаю документация объемом в 5 страниц - как поднять replica set в Монго. А потом оно как часы работает несколько лет.
>За 10 лет работы со Слоном ни разу с потерей данных из-за ошибок Слона не сталкивался
Окей, data loss не data loss пока Кузнец лично не одобрит. Он же сидит, все свои терабайты побитно проверяет минимум раз в день.
>Монго же в разы проигрывает Сиквелу в режиме грязного чтения
Другие workload-ы кроме чтения не знает (это не вопрос).
Ну тут уж кому и на горшок сходить самому или шнурки завязать -- мегаусложнённый крап.
>В орацле вообще всё - жуткий гемор. А то кто ж курсы купит.Ну ужос, да. Но не УЖОС-УЖОС же! :)
Ваши жабьи ЕЕ иной раз позаковыристее любого оракала бывают, и ничё :)
>Тут интересно, Монго инк уже настолько раздухарились, что шлют спамчик про oracle->mongo replacement.А у меня сосед 75 лет, а говорит что свою бабулю не менее 3 раз в день любит.
Вот и монга твоя - ____говорит____ :-))))
>Ещё лет 10 и реляционные субд останутся только в банках.Напомнило про виндовскапец, ага :-)
>А, отвечаю, в монге 3.2-3.4-3.6 процесс бесшовныйДа и ЮХ с ней, хоть шовный, хоть бесшовный - в монге хранят только то что терять не жалко. Конечно - "процесс бесшовный" :-р
> Дык дело не в mvcc. Просто в постгре очень много чего не
> доделано в плане обслуживания самой БД. Даже вот миграция на новую
> версию без простоя можно делать только в 10-ке (логическая репликация). По
> факту для репликаций, бекапов пока только бубнами и сторонними проектами можно
> пользоваться.
> Но все же караван идет...Но ведь это и близко не так. И репликация, и, тем более, резервное копирование в Слоне никакой проблемы не представляет. Всё, в общем-то, как и у других. Единственно, из общей массы Оракл со своим крайне удобным RMAN-ом выделяется, ну так Оракл и стоит куда дороже, чем любые коммерческие решения резервного копирования для Слона (или, скажем, для Сиквел сервака).
> Оракл со своим крайне удобным RMAN-омДа ладно! Вы действительно считаете RMAN удобным?
Функциональный - соглашусь.
Субъективно, конечно же, но по мне это лучшее решение. Обширная функциональность, хорошая документация, отличные возможности скриптинга, понятная модель.
>>из разряда:
>> * 90% времени отазоустойчивость не нужна
> Экспедры опеннета считают, постгрес в теореме о САР весь такой распупырчатый сразу
> всё умеет :) это ваше mvcc и бэкапы делать нормально не
> даёт, а только мееедленно и печальноЧувак, как бэкапы связаны с реализацией mvcc в Слоне? Ты вообще хоть немного понимаешь о чём пишешь?
> Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не
> нужно. Никуда и никак.
> Вместо того, чтобы отломать транзакции, героически борются с их следствиями уже почти
> 20 лет...Зачем тогда СУБД вообще? В файлик пишите всё подряд. К чему эта морока?
> Зачем тогда СУБД вообще? В файлик пишите всё подряд.Изобрёл носкль? Увы, это сделали ещё 10 лет назад. И оно уже лет 5 как вытеснило рсубд
Понимаете, нет никакого носкуль. Носкуль == имплицитный скуль. Т.е. вы пихаете кучу плоских данных, а затем, чаще всего крайне убогий индийский анализатор, сам за вас лепит кривую, но всю так же рэшэнал-модель. Причём делает это динамически и с непредсказуемой стабильностью результата. Сейчас нет даже на академ. уровне проработанной замены реляционной модели. А если нет модели на академ. уровне, т.е. там, где люди хоть немного отвечают за свои слова репутацией и их заявления хоть кто-то верифицирует, я таким пользоваться не стану. Поэтому пока Носкуль это секта верующих.
>Изобрёл носкль? Увы, это сделали ещё 10 лет назад.Му-ха-ха! До чего же жабщики на всю голову волшебные! :-))))
Это 10 лет назад начали __называть__ NoSQL. Ну куда же хипсторам без хайпа :)
А так (тряся сединой на ЖЖ :) помницо в IBM/360 key-value (hashed keys) _уже_ было. И его даже COBOL-щики юзают, не то что жаберы :-)
>И оно уже лет 5 как вытеснило рсубдВ голове отдельного индивида и не такие майданы могут происходить :) На реальный мир это никак не влияет.
key-value Это не субд.
> Суть предложенного в zheap формата хранения данных на диске в сохранении в основном хранилище только актуальных данных и выноса старых версий записей в отдельный лог отката измененийЯ не совсем понял, они этакую VCS в СУБД придумали?
Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё и сегмент отката.
> Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё
> и сегмент отката.)))))
Исторические данные в Слоне традиционно хранились вместе в одной и той же куче отношения. Исторические данные это данные отката. Данные "наката", насколько я понимаю вы так окрестили данные повторного исполнения, хранятся в журнале транзакций. Теперь есть возможность исторические данные хранить в отдельном хипе. Сделали Слона ещё более похожим на Оракл.
>> Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё
>> и сегмент отката.
> )))))
> Исторические данные в Слоне традиционно хранились вместе... вместе с актуальными...
MVCC. Нет, не слышал?
Сделали таки сегменты отката. Не очень нужно, в общем-то.
Нормально настроенные autovacuum удобней, чем возьня с контролем за местом ещё и под сегменты отката.
В Слоне же единственной проблемой реализации MVCC были короткие 32-битные XID-ы. Ну так эту проблему вынос исторических данных в отдельный хип не решает ни в какой мере. Да и проблемой это сложно назвать, если честно. В общем, не знаю: по-моему, Слон 9.2 был и так, в плане концепции, вполне достаточен. Дальше уже пошли куда-то... вширь.
> выноса старых версий записей в отдельный лог отката измененийО да, они сделали UNDO aka ROLLBACK SEGMENT
> исключения перезаписи страниц
И похоже, добавили буферные пулы.
Интересно, почему сие произошло только сейчас? :)
> Интересно, почему сие произошло только сейчас? :)Почему сейчас? Так ентропия легла.
Манагеры ентерпрайсдебе прочитали wikipedia://MVCC и запилили в свой сейлз-буклетик к|/|ллер-фичу "как в оракле".