|
2.2, takem (?), 17:40, 24/03/2015 [^] [^^] [^^^] [ответить]
| +8 +/– |
смотря как готовить, но да, быстрее, надежнее и вообще лучшее
| |
2.5, ъ (?), 17:56, 24/03/2015 [^] [^^] [^^^] [ответить]
| +6 +/– |
По совокупности:
- При росте БД у постгреса более предсказуемое управление данными, сноуболинг не происходит из-за особенностей ядра. Как следствие на очень малых объемах постгрес работает так же как и на больших, но это заметно только до 100-200 мб.
- Продуманная безопасность у постгресса и нет необходимости перезагружать боевую БД для получения привилегированного доступа.
- Оптимизатор в ядре разрабатывался научным сообществом (с оглядкой на мировых лидеров - таких как оракл и сайбейс), а не только программистами как у мускуля (на конференции СанДейз они очень извинялись за качество кода и алгоритмы в мускуле - так как у них энтерпрайз план и включается в код только то, что одобрено руководством, а так же фичи не принимаются если это идет в разрез с энтерпрайз планом - что и привило к расколу)
- Гистограммы для таблиц и партицирование на сегодняшний день самое лучше и продуманное у постгреса, что снимает почти всю головную боль с администраторов БД и разработчиков.
- Управление кэшем не пытающимся на себя взять функции ядра ОС, каждый делает только свою часть, но делает это отлично.
- Есть множество примеров где постгрес лучше. Только вот на хостингах он встречается реже и по тому стоит чуть-чуть дороже, что и приводит к меньшему распространению.
| |
|
|
4.9, Аноним (-), 22:44, 24/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
Соглашусь с оратором. Partitioning в постгре отсутствует, в мускуле - достаточно развит и решает поставленные перед ним задачи.
| |
4.10, Аноним аля (?), 07:36, 25/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Range-партиции триггером - страшный стыд.
Не триггером, а совокупностью штатных методов, главный из которых в данном случае - наследование таблиц. Чего в MySQL нет в принципе.
| |
|
5.12, Аноним (-), 16:51, 25/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
IF ( NEW.logdate >= DATE '2006-02-01' AND
NEW.logdate < DATE '2006-03-01' ) THEN
INSERT INTO measurement_y2006m02 VALUES (NEW.*);
Вышеприведенный фрагмент документации - ни разу не штатный метод, а всего лишь кривой костыль. Просто постгря не предоставляет вменяемых средств партиционирования, приходится извращаться. Даже в официальной документации.
| |
|
6.17, Аноним (-), 19:45, 25/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
> IF ( NEW.logdate >= DATE '2006-02-01' AND
> NEW.logdate < DATE
> '2006-03-01' ) THEN
> INSERT INTO measurement_y2006m02 VALUES
> (NEW.*);
> Вышеприведенный фрагмент документации - ни разу не штатный метод, а всего лишь
> кривой костыль. Просто постгря не предоставляет вменяемых средств партиционирования,
> приходится извращаться. Даже в официальной документации.
У постгрес просто нет синтаксиса для управления partitioning, но это не мешает ему там работать.
| |
6.22, asdasd (?), 10:33, 26/03/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
Mysql-дрочеры задолбали своими тупыми комментами и попытками хоть чтото положительное найти в своей недодб. Одно когда используешь его поскольку приходится, другое когда пытаетесь найти эфемерные преимущества изза неумения-нежелания вклбчить моск
> IF ( NEW.logdate >= DATE '2006-02-01' AND
> NEW.logdate < DATE
> '2006-03-01' ) THEN
> INSERT INTO measurement_y2006m02 VALUES
> (NEW.*);
> Вышеприведенный фрагмент документации - ни разу не штатный метод, а всего лишь
> кривой костыль. Просто постгря не предоставляет вменяемых средств партиционирования,
> приходится извращаться. Даже в официальной документации. | |
|
|
4.23, ъ (?), 17:52, 27/03/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Предлагаю обсуждать партиции с теми кому их приходится создавать и поддерживать. В оракле создайте доп. рейндж партицию или расширте набор хеш-партиций - удобно? В мускуле добавте гранулярности партициям или наследуйте другие условия на субпартиции. ТО, что механизм в явном виде использует более длинный синтаксис (только больше набирать на клавиатуре, если не умеете автоматизировать) не повод ругать очень ГИБКУЮ систему.
Експлейн на партицированые данные покажет реальную статистику и использует отдельные гистограммы. Если у вас реально отношение вставок к выборкам разбалансированно возможно стоит трезво оценить решение и использовать nosql + etl к примеру.
| |
|
3.11, Аноним (-), 11:57, 25/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
> партицирование на сегодняшний день самое лучше и продуманное у постгреса,
Ну тут вы погорячились, месье. До Оракла им ещё ой как далеко.
| |
|
4.15, Аноним (-), 19:42, 25/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
>> партицирование на сегодняшний день самое лучше и продуманное у постгреса,
> Ну тут вы погорячились, месье. До Оракла им ещё ой как далеко.
Это не совсем так.
| |
|
|
2.24, XoRe (ok), 01:26, 30/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Подскажите знающие, postgresql быстрее mysql?
Если вам сказать "да, быстрее", вы броситесь его изучать и переписывать сайты с mysql на postgres?
| |
|
1.4, amix (ok), 17:47, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –7 +/– |
Не быстрее не надежнее и не лучше, все зависит только от того как готовить.
| |
1.7, o (?), 18:20, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Да постгрес хорош. И академичен и развивается.
А еще меня попросили, почистить место. Там постгрес статистику с приборов в сушильном цехе хранит. 8 лет назад был запущен, так и работает.
| |
1.18, Аноним (-), 20:05, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> запасной сервер переводится в состояние заморозки БД для бэкапа
Какое ещё «состояние заморозки БД для бекапа»? Что за ерунда написана?
| |
1.19, Аноним (-), 20:08, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции.
с последнего checkpoint скорее всего, а не commit.
| |
|
2.21, Andrey Mitrofanov (?), 10:14, 26/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
>> Изменения накатываются начиная с последней зафиксированной на основном сервере транзакции.
> с последнего checkpoint скорее всего, а не commit.
Нет, коммита. По WAL-логам.
И нет, не с "последней зафиксированной", а с последней _общей точки историй двух серверов.
Слайд#25:
[CODE]Start recovery from the point of divergence, not
some later checkpoint.[/CODE]
[И судя по этому "not ... checkpoint" вплоть до откатывания чекпоинтов, не доехавших до нового мастера.]
| |
|
|