Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Для PostgreSQL предложено новое хранилище zheap"	+/–
Сообщение от opennews (??) on 06-Мрт-18, 23:39
Разработчики из компании 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.me/opennews/art.shtml?num=48214
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Для PostgreSQL предложено новое хранилище zheap"	+2 +/–
Сообщение от никто (??) on 06-Мрт-18, 23:39
Это же как у ORALCE c его роллбасл сегментом .... старое они оставят ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Для PostgreSQL предложено новое хранилище zheap"	+1 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 05:39
	> Это же как у 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');
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	12. "Для PostgreSQL предложено новое хранилище zheap"	+6 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 08:55
	Начинается свистопляска аля MySQL.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	27. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от rshadow (ok) on 07-Мрт-18, 14:50
	Дык это с незапамятных времен было. Просто всех устраивает дефолтовый. Я думаю если бы в мускуле innodb был бы изначально по умолчанию, то myisam может и не вспомнил бы никто.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	29. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от angra (ok) on 07-Мрт-18, 16:43
	У myisam полнотекстовый поиск и быстрые insert/update в наиболее частом варианте использования. innodb было как минимум с четвертого мускула, но в те времена единственным его преимуществом были внешние ключи, которые большей части пыхеров были ненужны, так что myisam был предпочтительным вариантом вовсе не из-за использования в качестве дефолта.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	36. "Для PostgreSQL предложено новое хранилище zheap"	+1 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 18:04
	> У myisam полнотекстовый поиск и быстрые insert/update в наиболее частом варианте использования. > innodb было как минимум с четвертого мускула, но в те времена > единственным его преимуществом были внешние ключи, которые большей части пыхеров были > ненужны, так что myisam был предпочтительным вариантом вовсе не из-за использования > в качестве дефолта. Была другая более фундаментальная причина. Пыхеры обычно обилием мозгов не отличаются, вернее -- отличаются их отсутствием. Поэтому понять недостатки myisam не могли в принципе. А чем меньше знаешь, тем лучше пища уваривается.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	46. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от angra (ok) on 07-Мрт-18, 20:21
	Но ты то не такой, ты ведь понял недостатки MyISAM для тех задач. Так поведай о них, блесни интеллектом.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	49. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от YetAnotherOnanym (ok) on 07-Мрт-18, 21:59
	Не знаю, как сейчас, а когда я имел дело с этим <censored>, myisam при записи лочил всю таблицу, тогда как innodb - только одну строку. А нарвался я на это дело, когда словил дикие тормоза после заливки в базу бэкапа - когда бэкап был с "create table", то вопреки настройкам таблицы почему-то создавались в myisam. Пришлось из бэкапа команды создания таблиц убрать, создать их вручную (только тогда она создала их в innodb), и заливать данные в базу с готовыми пустыми таблицами. И это не единственный "подводный камень", на который я напоролся. Вобщем, воспоминания о мускуле у меня только матерные.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	47. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от KonstantinB (ok) on 07-Мрт-18, 20:30
	innodb был как минимум с 3.23,  и его преимуществом было всегда прежде всего то, что: 1) это честный версионник, 2) он написан не Монти сотоварищи, которые в то время слабо себе представляли, что такое ACID, а людьми, которые отлично понимают принципы разработки СУБД.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	53. "Для PostgreSQL предложено новое хранилище zheap"	+1 +/–
	Сообщение от Аноним (??) on 08-Мрт-18, 05:59
	Регулярно вылавливаю последствия сладкой групповушки из MySQL(MyISAM)+PHP(Joomla)+ПыхПыхбибизьяна. Когда таблица логов разрастается до пары млн. строк, сайт начинает дико тупить, мыскль дико шуршит диском, запросам вечный лок. Горчишник в виде перегонки таблиц в InnoDB помогает.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	71. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от XoRe (ok) on 13-Мрт-18, 18:54
	> но в те времена единственным его преимуществом были внешние ключи Не единственным и не главным. Главное преимущество innodb - поддержка транзакций (которой до сих пор нет у MyISAM). Т.е. ничего, серьезнее личного бложика, на MyISAM лучше не делать. А ведь много у кого на mysql завязаны деньги клиентов...
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	48. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от KonstantinB (ok) on 07-Мрт-18, 20:37
	> Начинается свистопляска аля MySQL. В данном случае не вижу в этом ничего плохого. Проблема мыскля не в этом, а в реализации (и, до последнего времени, в дефолтном myisam).
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

3. "Для PostgreSQL предложено новое хранилище zheap"	–1 +/–
Сообщение от Аноним (??) on 07-Мрт-18, 05:37
ураааа, мы победили vacuum, vacuum больше ненужно! Опять...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Для PostgreSQL предложено новое хранилище zheap"	+1 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 05:41
	> ураааа, мы победили 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.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	11. "Для PostgreSQL предложено новое хранилище zheap"	+1 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 08:45
	там ключевое слово - "опять" ;-) > Currently any attempt to vacuum zheap will return error. я щетаю, прекрасно :-) (то есть, по факту, сегодня эта "экономичная" разновидность стораджа растет вообще неограниченно, хотя и медленнее чем невакумленый обычный) ну, ладно, понятно что оно еще толком не родилось, подождем еще годик, вдруг чудо все же произойдет...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	57. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от Аноним (??) on 08-Мрт-18, 15:00
	Плюсую. Однако надо помнить, что по ходу этот zheap добавляет лишние операции записи в оперативном периоде, тогда как vacuum и делается отложено и при ненадобности можно его выключить.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

6. "Для PostgreSQL предложено новое хранилище zheap"	+/–
Сообщение от Это я on 07-Мрт-18, 05:49
На тот случай, если не у всех есть fullflash схд - можно ли указать путь, где создавать/хранить индексы? Чтобы не приходилось их переносить вручную.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от Аноним (??) on 07-Мрт-18, 18:14
	> На тот случай, если не у всех есть fullflash схд - можно > ли указать путь, где создавать/хранить индексы? Чтобы не приходилось их переносить > вручную. При создании индекса можно указать целевое ТП, где данные индекса будут размещены физически.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

10. "Для PostgreSQL предложено новое хранилище zheap"	+/–
Сообщение от Аноним (??) on 07-Мрт-18, 08:38
ZSTD сжатия до сих порт нет, inmemory таблиц до сих пор тоже нет. А обещали...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Для PostgreSQL предложено новое хранилище zheap"	+3 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 18:00
	> ZSTD сжатия до сих порт нет, inmemory таблиц до сих пор тоже > нет. А обещали... Зачем вот это вот inmemory? Вы хоть немного себе представляете как типичная современная СУБД работает, а? Ну вот если честно? Во всех современных СУБД ВСЯ ОБРАБОТКА и так inmemory, и по другому не бывает. Какое ещё inmemory вам нужно? Всякие неофиты крикливые выдумают очередной деревянный велосипед и давай радоваться тому, что уже лет 30-ть как повсеместно просто используется.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

15. "Для PostgreSQL предложено новое хранилище zheap"	–10 +/–
Сообщение от лютый жабист__ on 07-Мрт-18, 10:56
Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не нужно. Никуда и никак. Вместо того, чтобы отломать транзакции, героически борются с их следствиями уже почти 20 лет...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Для PostgreSQL предложено новое хранилище zheap"	+5 +/–
	Сообщение от amonymous on 07-Мрт-18, 10:58
	Строите проекты без consistency? Ну удачи, чо.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	19. "Для PostgreSQL предложено новое хранилище zheap"	–5 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 11:49
	Фактически так жестко нужно наверно лишь в 10% случаев. Упрямые бараны, делают проблему из ничего. Ну пускай дальше землю бодают, есть куча альтернатив...
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	42. "Для PostgreSQL предложено новое хранилище zheap"	+2 +/–
	Сообщение от _ (??) on 07-Мрт-18, 18:27
	>есть куча альтернатив... Это - да! Иди в садовники :)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	22. "Для PostgreSQL предложено новое хранилище zheap"	–3 +/–
	Сообщение от лютый жабист__ on 07-Мрт-18, 13:19
	Выбрал ненужный в 90% случаев  C и отказался от нужного в 90% случаях А Ссзб чо
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	43. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от _ (??) on 07-Мрт-18, 18:28
	Это только у жабистов или-или. У нормальных людей - и то, и другое :-р
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	54. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от лютый жабист__ on 08-Мрт-18, 12:37
	Местные "банкиры локалхоста" отменили теорему cap. Не сомневался
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	60. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от _ (??) on 08-Мрт-18, 17:15
	У нас частый случай, который покрывает 146% приложений, работающих с баблом. А пиписки на заборе ... да хоть монгай рисуй :)
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	20. "Для PostgreSQL предложено новое хранилище zheap"	+17 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 12:00
	>Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не нужно. Никуда и никак. Из серии "Самые тупые фразы в ИТ. Золотое издание" из разряда: * 90% времени отазоустойчивость не нужна * 90% времени бэкап не нужен * 90% проектов хватит одной базы данных на одном сервере у одного провайдера. Думаете, почему только 10% проектов успешны? Да потому что 90% обслуживают кретины.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	23. "Для PostgreSQL предложено новое хранилище zheap"	–2 +/–
	Сообщение от лютый жабист__ on 07-Мрт-18, 13:33
	>из разряда: > * 90% времени отазоустойчивость не нужна Экспедры опеннета считают, постгрес в теореме о САР весь такой распупырчатый сразу всё умеет :) это ваше mvcc и бэкапы делать нормально не даёт, а только мееедленно и печально
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	28. "Для PostgreSQL предложено новое хранилище zheap"	+1 +/–
	Сообщение от rshadow (ok) on 07-Мрт-18, 15:02
	Дык дело не в mvcc. Просто в постгре очень много чего не доделано в плане обслуживания самой БД. Даже вот миграция на новую версию без простоя можно делать только в 10-ке (логическая репликация). По факту для репликаций, бекапов пока только бубнами и сторонними проектами можно пользоваться. Но все же караван идет...
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	33. "Для PostgreSQL предложено новое хранилище zheap"	+1 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 17:54
	Я не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	41. "Для PostgreSQL предложено новое хранилище zheap"	–5 +/–
	Сообщение от лютый жабист__ on 07-Мрт-18, 18:26
	> не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно. Подрастёшь, узнаешь
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	51. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от Кузнец on 07-Мрт-18, 23:22
	>> не знаю ни одной СУБД, где миграция на новую версию ПО файлов данных прежней происходит бесшовно. > Подрастёшь, узнаешь Подрасту я уже вряд ли. Давайте лучше примеры. В Оракле переход с версии на версию редкий гемор. В Сиквеле -- не лучше. В сибасе не лучше. В ДБ2 там полная изотерика. Что ещё предложите?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	55. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от лютый жабист__ on 08-Мрт-18, 12:45
	В орацле вообще всё - жуткий гемор. А то кто ж курсы купит. Тут интересно, Монго инк уже настолько раздухарились, что шлют спамчик про oracle->mongo replacement. Ещё лет 10 и реляционные субд останутся только в банках. А, отвечаю, в монге 3.2-3.4-3.6 процесс бесшовный
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	59. "Для PostgreSQL предложено новое хранилище zheap"	+1 +/–
	Сообщение от Кузнец on 08-Мрт-18, 16:46
	> В орацле вообще всё - жуткий гемор. А то кто ж курсы > купит. > Тут интересно, Монго инк уже настолько раздухарились, что шлют спамчик про oracle->mongo > replacement. > Ещё лет 10 и реляционные субд останутся только в банках. > А, отвечаю, в монге 3.2-3.4-3.6 процесс бесшовный Оракл отлично документирован. Причём его освоение дёшево и доступно. Слон в этом плане за последние годы тоже сильно подтянулся: появилась и внятная документация, и книги, и методики. Оракл же до сих хорош тем, что он, всё же, быстрый. Для честного MVCC очень быстрый. Любая нормальная РСУБД быстрее Монго, если довести её до того же уровня недостоверности данных. Ну, скажем, в Оракле ACID не отключить и не обойти, но в Сиквеле или Слоне это возможно. После этого ваш Монго вообще теряет всякие преимущества: он значительно медленней, менее функциональный, инструментарий для него вообще убог до смешного. Поэтому Монго -- не нужен.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	63. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от лютый жабист__ on 08-Мрт-18, 19:55
	>Причём его освоение дёшево и доступно п1. А на нашей планете все курсы по Оракле от полтинника-сотни, даже самые плешивые на 3 дня. п2. Про сертификацию молчу и сколько зарплаты хочет чувак, на которо слили лимон-другой бабла в п1 >РСУБД быстрее Монго, если довести её до того же уровня недостоверности данных Бред оф сив кэйбл. Это в Постгресе постоянно фиксят баги, которые теряют данные, причём БЕЗ отключения ACID. >инструментарий для него вообще убог до смешного О да, куда же консольке mongo до могучего sqlplus :))))))
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	64. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от Кузнец on 08-Мрт-18, 21:58
	По-моему, курсы по Ораклу совершенно бесполезны. У Оракла отличная публичная бесплатная документация и отличная библиография (разжёвано всё, что только имеет смысл жевать). К тому же, разрабу не нужна сертификация. За 10 лет работы со Слоном ни разу с потерей данных из-за ошибок Слона не сталкивался. Да и не критично это при нормальной схеме резервного копирования. Монго же в разы проигрывает Сиквелу в режиме грязного чтения. Зачем тогда этот Монго?
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	65. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от нах on 09-Мрт-18, 05:33
	курсы-то полезны, просто они не для вас в основном - во всяком случае, все эти "за три дня стать dba" (на деле - сможешь долго и счастливо жить с не слишком большой оракловой базой, если руками никуда там не полезешь) хотя получить некоторое представление о том, как и что принято делать (не что вообще-то можно - на этот вопрос отвечает документация) - полезно, и тем более - разработчику. а денег (если хороший) он и так хочет много (и дважды в месяц подавай, а не один раз заплатил, как за курсы, и навечно просветленный)
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	67. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от лютый жабист__ on 09-Мрт-18, 20:12
	>У Оракла отличная публичная бесплатная документация и отличная библиография Как могут быть отличной документацией талмуды на 100500 страниц про то, что само по себе является мегаусложненным крапом? Я вот понимаю документация объемом в 5 страниц - как поднять replica set в Монго. А потом оно как часы работает несколько лет. >За 10 лет работы со Слоном ни разу с потерей данных из-за ошибок Слона не сталкивался Окей, data loss не data loss пока Кузнец лично не одобрит. Он же сидит, все свои терабайты побитно проверяет минимум раз в день. >Монго же в разы проигрывает Сиквелу в режиме грязного чтения Другие workload-ы кроме чтения не знает (это не вопрос).
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	68. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от Кузнец on 10-Мрт-18, 13:50
	Ну тут уж кому и на горшок сходить самому или шнурки завязать -- мегаусложнённый крап.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	61. "Для PostgreSQL предложено новое хранилище zheap"	+1 +/–
	Сообщение от _ (??) on 08-Мрт-18, 17:23
	>В орацле вообще всё - жуткий гемор. А то кто ж курсы купит. Ну ужос, да. Но не УЖОС-УЖОС же! :)   Ваши жабьи ЕЕ иной раз позаковыристее любого оракала бывают, и ничё :) >Тут интересно, Монго инк уже настолько раздухарились, что шлют спамчик про oracle->mongo replacement. А у меня сосед 75 лет, а говорит что свою бабулю не менее 3 раз в день любит. Вот и монга твоя - ____говорит____ :-)))) >Ещё лет 10 и реляционные субд останутся только в банках. Напомнило про виндовскапец, ага :-) >А, отвечаю, в монге 3.2-3.4-3.6 процесс бесшовный Да и ЮХ с ней, хоть шовный, хоть бесшовный - в монге хранят только то что терять не жалко. Конечно - "процесс бесшовный" :-р
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	34. "Для PostgreSQL предложено новое хранилище zheap"	+2 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 17:57
	> Дык дело не в mvcc. Просто в постгре очень много чего не > доделано в плане обслуживания самой БД. Даже вот миграция на новую > версию без простоя можно делать только в 10-ке (логическая репликация). По > факту для репликаций, бекапов пока только бубнами и сторонними проектами можно > пользоваться. > Но все же караван идет... Но ведь это и близко не так. И репликация, и, тем более, резервное копирование в Слоне никакой проблемы не представляет. Всё, в общем-то, как и у других. Единственно, из общей массы Оракл со своим крайне удобным RMAN-ом выделяется, ну так Оракл и стоит куда дороже, чем любые коммерческие решения резервного копирования для Слона (или, скажем, для Сиквел сервака).
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	45. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от Moomintroll (ok) on 07-Мрт-18, 18:30
	> Оракл со своим крайне удобным RMAN-ом Да ладно! Вы действительно считаете RMAN удобным? Функциональный - соглашусь.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	50. "Для PostgreSQL предложено новое хранилище zheap"	+1 +/–
	Сообщение от Кузнец on 07-Мрт-18, 23:20
	Субъективно, конечно же, но по мне это лучшее решение. Обширная функциональность, хорошая документация, отличные возможности скриптинга, понятная модель.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	39. "Для PostgreSQL предложено новое хранилище zheap"	+1 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 18:09
	>>из разряда: >> * 90% времени отазоустойчивость не нужна > Экспедры опеннета считают, постгрес в теореме о САР весь такой распупырчатый сразу > всё умеет :) это ваше mvcc и бэкапы делать нормально не > даёт, а только мееедленно и печально Чувак, как бэкапы связаны с реализацией mvcc в Слоне? Ты вообще хоть немного понимаешь о чём пишешь?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	37. "Для PostgreSQL предложено новое хранилище zheap"	+3 +/–
	Сообщение от Аноним (??) on 07-Мрт-18, 18:06
	> Самое смешное, что для 90% проектов MVCC не нужно. Ну ваще не > нужно. Никуда и никак. > Вместо того, чтобы отломать транзакции, героически борются с их следствиями уже почти > 20 лет... Зачем тогда СУБД вообще? В файлик пишите всё подряд. К чему эта морока?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	56. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от лютый жабист__ on 08-Мрт-18, 12:47
	> Зачем тогда СУБД вообще? В файлик пишите всё подряд. Изобрёл носкль? Увы, это сделали ещё 10 лет назад. И оно уже лет 5 как вытеснило рсубд
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	58. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от Кузнец on 08-Мрт-18, 16:39
	Понимаете, нет никакого носкуль. Носкуль == имплицитный скуль. Т.е. вы пихаете кучу плоских данных, а затем, чаще всего крайне убогий индийский анализатор, сам за вас лепит кривую, но всю так же рэшэнал-модель. Причём делает это динамически и с непредсказуемой стабильностью результата. Сейчас нет даже на академ. уровне проработанной замены реляционной модели. А если нет модели на академ. уровне, т.е. там, где люди хоть немного отвечают за свои слова репутацией и их заявления хоть кто-то верифицирует, я таким пользоваться не стану. Поэтому пока Носкуль это секта верующих.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	62. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от _ (??) on 08-Мрт-18, 19:06
	>Изобрёл носкль? Увы, это сделали ещё 10 лет назад. Му-ха-ха! До чего же жабщики на всю голову волшебные! :-)))) Это 10 лет назад начали __называть__ NoSQL. Ну куда же хипсторам без хайпа :) А так (тряся сединой на ЖЖ :) помницо в IBM/360 key-value (hashed keys) _уже_ было. И его даже COBOL-щики юзают, не то что жаберы :-) >И оно уже лет 5 как вытеснило рсубд В голове отдельного индивида и не такие майданы могут происходить :) На реальный мир это никак не влияет.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	66. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от люьый жабист__ on 09-Мрт-18, 20:04
	key-value Это не субд.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

18. "Для PostgreSQL предложено новое хранилище zheap"	–1 +/–
Сообщение от Аноним (??) on 07-Мрт-18, 11:34
> Суть предложенного в zheap формата хранения данных на диске в сохранении в основном хранилище только актуальных данных и выноса старых версий записей в отдельный лог отката изменений Я не совсем понял, они этакую VCS в СУБД придумали?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от аноним 12 on 07-Мрт-18, 14:15
	Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё и сегмент отката.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	31. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от Аноним (??) on 07-Мрт-18, 16:51
	> Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё > и сегмент отката. ))))) Исторические данные в Слоне традиционно хранились вместе в одной и той же куче отношения. Исторические данные это данные отката. Данные "наката", насколько я понимаю вы так окрестили данные повторного исполнения, хранятся в журнале транзакций. Теперь есть возможность исторические данные хранить в отдельном хипе. Сделали Слона ещё более похожим на Оракл.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	38. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от Аноним (??) on 07-Мрт-18, 18:06
	>> Какие такие «они»? Сегмент наката так и хранится, просто они сделали ещё >> и сегмент отката. > ))))) > Исторические данные в Слоне традиционно хранились вместе ... вместе с актуальными...
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	30. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от Аноним (??) on 07-Мрт-18, 16:47
	MVCC. Нет, не слышал?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

26. "Для PostgreSQL предложено новое хранилище zheap"	+/–
Сообщение от Аноним (??) on 07-Мрт-18, 14:49
Сделали таки сегменты отката. Не очень нужно, в общем-то. Нормально настроенные autovacuum удобней, чем возьня с контролем за местом ещё и под сегменты отката.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

52. "Для PostgreSQL предложено новое хранилище zheap"	+/–
Сообщение от Кузнец on 07-Мрт-18, 23:29
В Слоне же единственной проблемой реализации MVCC были короткие 32-битные XID-ы. Ну так эту проблему вынос исторических данных в отдельный хип не решает ни в какой мере. Да и проблемой это сложно назвать, если честно. В общем, не знаю: по-моему, Слон 9.2 был и так, в плане концепции, вполне достаточен. Дальше уже пошли куда-то... вширь.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

69. "Для PostgreSQL предложено новое хранилище zheap"	–1 +/–
Сообщение от DeadMustdie (??) on 12-Мрт-18, 14:36
> выноса старых версий записей в отдельный лог отката изменений О да, они сделали UNDO aka ROLLBACK SEGMENT > исключения перезаписи страниц И похоже, добавили буферные пулы. Интересно, почему сие произошло только сейчас? :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	70. "Для PostgreSQL предложено новое хранилище zheap"	+/–
	Сообщение от Andrey Mitrofanov on 12-Мрт-18, 16:18
	> Интересно, почему сие произошло только сейчас? :) Почему сейчас? Так ентропия легла. Манагеры ентерпрайсдебе прочитали wikipedia://MVCC и запилили в свой сейлз-буклетик к|/|ллер-фичу "как в оракле".
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема