Вместо этого лучше бы бенчмарки показали. Пиздеть -- не мешки ворочать

Безусловно в оракл много вспомогательных инструментов для администрирования, есть Enterprise manager - админка для чайников, но я бы никогда не навал администрирование оракла простым

Ясен пень, местами там быстрее. Но блять. На сколько?

Восновном субъектиные (не технические) показатели указаны

Дак именно. Где квадрат гартнера -- сравнивают кислое с длинным

@kelvich, Read-only tx speed is the same as in standalone postgres. в clock-si читающий ждет комитающуюся транзакцию, если читает то что она поменяла

как у вас?

Восновном субъектиные (не технические) показатели указаны

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

он сертефицирован кстати уже)

Пруф

Ну может разве чейто форк. Типа постгреспрошный

Они не указывают, что почти все перечисленные фишки только в Enterprise версии оракла

Да. И сравнили бы цену кстати.

господи, как вас просто раззадорить

В стандарте оракл от постгрес недалеко ушел

господи, как вас просто раззадорить

Аш трисёт

Забавное чтиво, ага...

да не было цели раззадорить. Документ этот говорит об одном - заметили, переживают.

А что, у них рашка такой большой рынок сбыта ?

нет. помоему не более 1%

Ну а чо тогда. Импортозаместят постгресом и всё.

Вот еще пдфки какието выдумывать

DBaaS говорят нет

А как же амазоновский RDS? )

А как же амазоновский редшифт ещё спроси

Вот проблема как дизайнить схему: У меня есть таблица фоток с id и album_id, обе колонки идентифицируют уникальное фото, однако никаких прямых запросов по ним не производится. Что тут правильней делать: CREATE PRIMARY KEY (id, album_id) или ADD CONSTRAINT photo UNIQUE (id, album_id)?

Обе идентифицируют или идентифицирует пара колонок?

пара колонок идентифицирует

тк есть дубликаты и той и другой по отдельности

Обьеденить ид и альбум_ид через подчеркивание например

Обьеденить ид и альбум_ид через подчеркивание например

Избыточность данных

Все запросы к таблице идут по индексу с другой колонки from_id, и мне нужно лишь запретить писать дубликаты (id и album_uid в одном row) в таблицу. Семантически верно звучит PRIMARY KEY, но мне кажется что pkey несет больше оверхеда чем просто unique constraint, тк последний наверное можно упростить каким-нибудь блум фильтром например

Избыточность данных

И что ?

Вот проблема как дизайнить схему: У меня есть таблица фоток с id и album_id, обе колонки идентифицируют уникальное фото, однако никаких прямых запросов по ним не производится. Что тут правильней делать: CREATE PRIMARY KEY (id, album_id) или ADD CONSTRAINT photo UNIQUE (id, album_id)?

Мне нравится первый вариант. Сформулировать не могу, но я бы сделал так

Тогда констрейнт имхо

Обьеденить ид и альбум_ид через подчеркивание например

не не вариант, потом когда-нибудь буду их по отдельности индексировать

не бояться и использовать составные pkey

+1

хотя пишут что технически, PRIMARY KEY это просто комбинация UNIQUE и NOT NULL

+1

А Имхо другое ))

не бояться и использовать составные pkey

да вот спасибо, так и сделаю

А они могут быть нулами ?

А они могут быть нулами ?

неа

теперь у меня есть здоровая таблица где PRIMARY KEY (id), а нужно сделать его (id, album_id). Можно как-нибудь сделать его композитным, не дропая pkey на id?

В том же Oracle, наличие pkey упрощает некоторые операции... в postgres не могу сказать приносит ли какаие-то +, но и - не вижу

теперь у меня есть здоровая таблица где PRIMARY KEY (id), а нужно сделать его (id, album_id). Можно как-нибудь сделать его композитным, не дропая pkey на id?

А чтт помешает ?

В том же Oracle, наличие pkey упрощает некоторые операции... в postgres не могу сказать приносит ли какаие-то +, но и - не вижу

да тот же foreign key легко сделать когда есть pkey

А сорри :)

теперь у меня есть здоровая таблица где PRIMARY KEY (id), а нужно сделать его (id, album_id). Можно как-нибудь сделать его композитным, не дропая pkey на id?

дропни в транзакции

вообще, заворачивай миграции в транзакции :)

а лучше найди любимую тулу для миграций и используй

ну мне не страшно если таблица локнется на запись

@kelvich, Read-only tx speed is the same as in standalone postgres. в clock-si читающий ждет комитающуюся транзакцию, если читает то что она поменяла

Так же, тут мой косяк в презе. Автотесты настроены на read-only и update-only нагрузку, соот-но в read-only селекты не ждут никого, так как никто не пишет. При смешанной нагрузке это должно быть заметно, если транзакции короткие, добавлю на слайды.

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

это очень важный нюанс

пушо щас ридерс не ждут врайтеров никак

а тут на миксе будет жопа

ну и например от той же галеры важное отличие

Да, это принципиальная вещь в такой системе, на одной машине можно управлять атомарно видимостью битиком в clog, а если распределенно коммит делать, то появляется in-doubt

еще интересно можно ли будет зашорткатить этот момент, если у нас будет локально чтение и запись на одной ноде

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

ну и например от той же галеры важное отличие

еп, но за это цена в галере — одинаковый лог транзакций везде, там медленнее вставка в него и запись

ну тут за запись тоже надо платить ртт

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

поясни плиз за галеру, не понял твой поинт

ERROR: S client not available

Запустил вот такое вот: BEGIN; ALTER TABLE photos DROP CONSTRAINT photos_pkey; ALTER TABLE photos ADD PRIMARY KEY (id, album_id); COMMIT;

@blkmrkt, maintenance_work_mem

Насколько я понимаю тут отъедает размер - мэйтенс воркмем

точно, она у меня maintenance_work_mem = 8GB

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

только за дистрибутед, но в мм сейчас всё дистрибутед) Это сделано на уровне таплов и clog — если транзакция породившая тапл коммитится, то у неё в clog особый статус и надо ждать. Соот-но если делать шардинг, то такой статус даст только распределенная транзакция, но не локальная, которая от in-progress сразу перейдет к commit/abort

так и подозревал

о, збс

расскажи как дистрибутед дедлок детектор делали

поясни плиз за галеру, не понял твой поинт

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

насколько я знаю они перед коммитом отсылают ченджсет на все ноды и сверяют что оно не конфликтует с инпрогресс транзакциями

потом коммитит

больше ничего не знаю

скрин с какого сервиса?

ну и да, скорость изменения строки - максимум раз в 1 ртт

скрин с какого сервиса?

netdata

расскажи как дистрибутед дедлок детектор делали

Хуку в обычный дедлок детектор вставили — если он не нашел локального дедлока, то рассылает через logical message свой граф зависимости транзакций на соседние ноды. Если дистрибутед дедлок есть, то такой же таймаут истечет на другой ноде и у неё уже будет инфа по куску графа с первой, соот-но можно поискать цикл в общем графе

рассылает же не просто так, а когда таймаутик вышел. или чо как

я просто очень плохо понимаю как у вас всё работает. пушо architecture.md пустая

дд в постгресе — если прождали на локе секунду, то проверяем цикл в графе зависимостей

если нет локального цикла, то кидаем свой кусок графа соседям

я просто очень плохо понимаю как у вас всё работает. пушо architecture.md пустая

соберусь с силами и напишу, много конференций сейчас подряд %)

а как ты понимаешь что секунду ждешь лока в дистрибутед? + не понимаю как вы пишите данные по нодам, 3PC вроде в твоей пдф

какой-то я тупой

надо все нормально написать, но это проще делать ближе к бете, тогда меньше переписывать)

а как ты понимаешь что секунду ждешь лока в дистрибутед? + не понимаю как вы пишите данные по нодам, 3PC вроде в твоей пдф

просто если любого лока постгрес ждет секнду, то он проверяет цикл в графе

https://www.postgresql.org/docs/current/static/runtime-config-locks.html

вот

да это-то понятно

просто если ты на одной ноде поменял A, на второй B. вторая транзакция в обратном порядке

никто никого не ждал получается

и на коммит у тебя сертификация должна идти