|
2.97, Аноним (97), 13:14, 20/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Я вот не пойму, почему этих ребят за нарушение тм в суд не пригласили?
У них договорённости какие-то или они на территории США не распространяются?
| |
|
3.138, Andrey Mitrofanov (?), 10:58, 22/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Я вот не пойму, почему этих ребят за нарушение тм в суд
Какое "нарушение"?? Это-то Вы, надеюсь, понимаете хотя до уровня -- объяснить. Прошу.
> не пригласили? | |
|
|
|
2.7, Dmrjan (?), 14:22, 19/10/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Когда движок перепилят, что бы избавится от вакуума?
Зачем его выпиливать. Это крайне нужна вещь. Вакуум конечно можно отключить, но так вы базы загубите.
| |
|
3.17, Аноним (17), 15:44, 19/10/2018 [^] [^^] [^^^] [ответить]
| –3 +/– |
С текущим движком постгри всё так. О том и речь, чтобы сделать наконец нормальный движок как в приличных СУБД.
| |
|
|
|
6.79, Аноним (79), 23:09, 19/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это который ORA-01555; Snapshot too old? Нет, такой движок нам не нужен :-)
| |
|
7.85, Мудила (?), 23:42, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ну ведь это тоже чисто "проблема реализации". Сделайте Сегмент отката пожирнее.
| |
|
|
5.68, Аноним (68), 21:36, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
> А "Нормальные" это какие?
Поколоночные? Типа Apache Kudu? Они точно нормальны к строкам....
| |
|
|
|
|
3.14, Ilya Indigo (ok), 15:11, 19/10/2018 [^] [^^] [^^^] [ответить]
| –3 +/– |
И как только InnoDB без всяких вакуумов справляется, предоставляя транзакционность и прочее нужное?
| |
|
4.18, morruth (?), 15:53, 19/10/2018 [^] [^^] [^^^] [ответить]
| +8 +/– |
вы таки будете смеяться, но вакуум там есть, просто называется по другому
| |
4.20, ajp (?), 15:56, 19/10/2018 [^] [^^] [^^^] [ответить]
| +5 +/– |
И только почему-то в InnoDB нужно периодически запускать optimize.
| |
4.31, Аноним (27), 16:55, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ильюша, аналог "вакуума" есть во всех mvcc-рсубд. Это основа подхода -- сохранять исторические данные для организации многоверсионности. Реализаций существует несколько -- ни одна из них не являет особых преимуществ перед другими.
| |
|
|
6.44, Аноним (27), 17:49, 19/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Хабр читать не буду. Хотите что-то узнать попробуйте осмысленно пересказать мне о чём там, я может и отвечу что-нибудь. Хотя не очень понимаю зачем мне этим культпросветом заниматься.
| |
|
|
8.57, Аноним (27), 18:17, 19/10/2018 [^] [^^] [^^^] [ответить] | +2 +/– | Замечательно, что вы освоили ctrl-c и ctrl-v, но что из этого вы поняли Вы крит... текст свёрнут, показать | |
8.58, Аноним (27), 18:29, 19/10/2018 [^] [^^] [^^^] [ответить] | +/– | Объясню В Оракле записи в Сегмент отката обслуживается на общих основаниях , т... текст свёрнут, показать | |
8.60, Аноним (27), 18:41, 19/10/2018 [^] [^^] [^^^] [ответить] | –1 +/– | У Инно ещё и косяки с синхронизацией Нужно быть отчаянным авантюристом, чтобы И... текст свёрнут, показать | |
|
9.86, Ага (?), 01:20, 20/10/2018 [^] [^^] [^^^] [ответить] | +/– | Достаточно провести нагрузочное тестирование перед вводом в прод ну и не пользов... текст свёрнут, показать | |
|
8.62, Аноним (27), 18:59, 19/10/2018 [^] [^^] [^^^] [ответить] | +/– | Сама по себе концепция кластерного индекса не делает Инно не хуже, не лучше, чем... текст свёрнут, показать | |
|
|
6.46, Аноним (27), 17:53, 19/10/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
ААААааааа.... Чуваки из Убера на полном серьёзе пишут, что транзакционность это ненужное фуфло, потому... что замедляет запись )))))))) Вот новость-то.
| |
|
7.100, Аноним (100), 13:51, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
А ты свои 10 записей пишешь и тебе хватает. Как поработаешь с нагруженными прилржениями, поймешь, что это такое и какая нужна производительность
| |
7.113, Анонимно (?), 15:39, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ты, наверное админ, который про базы только в школе слышал и наверное тебе не рассказали что консистентность можно поддерживать разными способами
| |
|
|
|
|
5.54, Аноним (27), 18:14, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ещё раз. Это общая проблема. Никто её пока как-то сильно лучше других не решил. Статистику нужно обновлять, индексы обновлять, данные отмены где-то и как-то хранить, а потом очищать. У всех одинаковые проблемы.
| |
5.109, Аноним (109), 15:27, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
InnoDB на SSD или при преимущественно рандомных выборках не-range на любом носителе OPTIMIZE TABLE наксер не нужен, поскольку фрагментация роли не играет. Повторное использование страниц при этом есть.
Для write-mostly нагрузок есть TokuDB, у которого реюз также сделан.
У постгри же вакуум в этих случаях также не отменяется, а для write-mostly вообще нет ничего.
| |
|
|
|
2.15, пох (?), 15:14, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
да, я тоже что-то не понял, где в списке новостей - "1. vacuum deprecated и назначен к выпиливанию в 11.1" - сопровождавшее все выпуски, кажется, начиная с 8. Наверное, автор новости просто невнимательно читал оригинал. ;-)
| |
|
3.112, Аноним (109), 15:31, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
В пользу автовакуума, угу, который один ксер тот же вакуум. Как вы с этим кактусом живёте. Ну ладно на хдд фрагментирование допустим таблиц InnoDB требовало аккуратного подхода, но вот на SSD-то оно не актуально уже.
| |
|
4.116, пох (?), 18:45, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
вы свое "фрагментирование" (которое многозадачной системе, вообще-то, изрядно до лампы) с бесконечным разрастанием таблиц и их индексов из-за банального update -то не путайте.
| |
|
|
|
3.33, Аноним (27), 17:18, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
А зачем? Чем "вакуум"-то мешает жить тем, кому он... мешает жить? Чем Сегменты откаты в Оракле удобней? Обычно про вакуум визжат ничего сложней Дельфина никогда не пробовавшие.
| |
|
4.73, пох (?), 22:25, 19/10/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Чем "вакуум"-то мешает жить
тем что жрет ресурсы как не в себя и при этом не работает. И в результате - vacuum full; reindex
> Чем Сегменты откаты в Оракле удобней?
тем что они вне стора и после завершения транзакции просто помечаются как ненужные.
обычно проблема ваккума непонятна "аналитикам", которые никогда в базе ничего не меняют.
| |
|
5.80, Аноним (79), 23:14, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
> тем что жрет ресурсы как не в себя
это настраивается
> и при этом не работает.
у всех работает
> И в результате - vacuum full
vacuum full не нужен
> reindex
тут не спорю, нужен, но маловероятно что отказ от вакуума это исправит, индексы всё равно будут пухнуть из-за поддержки многопоточности, либо придётся сильнее лочиться
| |
5.128, Мудила (?), 14:19, 21/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Т. е. по вашему получается, что обслуживание Сегментов отката даром даётся ))) Ну, оно как-то само там что-то с собой делает. И хватит тут кичится своим невежеством и непрофессионализмом. Если у вас что-то не получается, то слушайте тех, у кого получается, а не хамите, как пэтэушник. "Проблема вакуума" непонятна тем, кто по этой проблеме и пары страниц не удосужился прочитать, но рассказывает тут какой он "практик". Даже не смешно уже.
| |
|
6.150, пох (?), 21:45, 22/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
ну, скажем так - оно во-первых вполне предсказуемое, во вторых, в самом банальном варианте таки даром, да - напоминаю, что постгрез раздувает и стор и индекс на банальном update не-ключевых полей. Без всяких параллельных транзакций и длительных блокировок - просто потому что вот так он у него устроен. В этом он совершенно уникален, кто-то там своего PhD в 95м за эту фичу получил.
> И хватит тут кичится своим невежеством и непрофессионализмом.
переадресую вам этот полезный совет.
> Если у вас что-то не получается, то слушайте тех, у кого получается
мамкиных dba, не понявших даже в чем, собственно, проблема, потому что на их append-only базе такого вообще не бывает? Спасибо, неинтересно мне вас слушать. "пару страниц прочитавших", ага.
"такая же нога, и не болит".
| |
|
|
|
|
2.35, Аноним (27), 17:19, 19/10/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Иван, а что вы знаете о СУБД вообще? Хоть что-нибудь знаете, а? Ну хоть чуть-чуть?
| |
2.43, Аноним (43), 17:49, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Другой вопрос, когда появится поддержка других хранилищь, помимо блочных устройств? Энергонезависимую память уже втыкают в слот оперативной. MySQL уже несколько десятков лет умеет работать с оперативкой.
| |
|
3.51, Аноним (27), 18:07, 19/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
А как понять "умеет работать с оперативкой"? Все современные СУБД "умеют работать с оперативкой", с ней только и работают.
| |
3.78, Аноним (78), 22:44, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
А что, оперативка и NVME вдруг перестали работать как блочные устройства?
| |
|
4.115, Аноним (115), 18:24, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
т.е. вы предлагаете то, что можно адресовать по-байтно, адресовать по-блочно, чтобы только ничего не переделывать?
| |
|
5.118, Мудила (?), 20:16, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
З а ч е м? Объём накладных расходов возрастает в десятки раз. Вы не задумывались почему так распространена постраничная адресация, а? Микроменеджмент всего это хозяйства будет занимать все ресурсы.
| |
|
|
|
|
1.8, Ононимус (?), 14:27, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +9 +/– |
В интерфейс командной строки в дополнение к штатной команде "\q" добавлены более привычные для новичков команды "quit" и "exit".
Джва года ждал!
| |
1.9, Аноним (9), 14:27, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –9 +/– |
>Добавлен новый вид хранимых процедур, позволяющих использовать транзакции
Не поклонник слоника, но вот от этого офигел.
Только добавили? Едрить!
| |
|
|
|
|
|
6.52, Аноним (27), 18:08, 19/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Значит, никогда ни транзактом, ни с пл-, ни с пг-сиквелом дел не имели. И с СУБД вообще. Зачем тогда вам разбираться в этих тонкостях?
| |
|
7.64, абв (?), 19:10, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Зачем тогда вам разбираться в этих тонкостях?
Для развития.
Назад к сути. Где в офф.документации почитать про разницу? Спасибо.
| |
|
8.71, Мудила (?), 22:12, 19/10/2018 [^] [^^] [^^^] [ответить] | +/– | Исторически разница была в том, что функции можно было встраивать в SQL-выражени... текст свёрнут, показать | |
8.72, Мудила (?), 22:19, 19/10/2018 [^] [^^] [^^^] [ответить] | +/– | Ну, я несколько не точно выразился Процедуры тоже можно было в SQL-код встраива... текст свёрнут, показать | |
|
|
|
|
|
3.81, Аноним (79), 23:29, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Это вложенные транзакции
Нет, наоборот, это возможность вызвать процедуру _вне_ транзакции, что бы транзакцией управляла она сама.
| |
|
|
1.23, абв (?), 16:20, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
> Добавлен новый вид хранимых процедур, позволяющих использовать транзакции.
В оригинале:
> SQL stored procedures that support embedded transactions
Что за "embedded transactions"?
Имеется в виду "autonomous transactions" или что-то другое?
| |
|
2.29, Аноним (27), 16:51, 19/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
А зачем он? Я DBeaver-ом пользуюсь. Для всего. И для Слона тоже. Вполне достаточно.
| |
|
3.48, Аномномномнимус (?), 17:57, 19/10/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Оооо!!! Спасибо, похоже это то, что я давно хотел.
А он умеет по SSH и через PHP-прокси в базы данных стучать, как Navicat?
| |
|
4.53, Аноним (27), 18:11, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Не знаю, не пробовал.
А зачем это вот прям уметь? Туннель сторонними средствами можно ведь без проблем сделать, только порты пробросить.
| |
|
5.63, Аномномномнимус (?), 19:02, 19/10/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
Не на всех хостингах можно использовать SSH, а так же вертеть mysql как угодно, а в БД бывает надо поковыряться. И в итоге в худших случаях начинается цирк с "забекапить, скачать, развернуть, поправить, сбекапить, залить обратно, развернуть"
| |
|
4.66, й (?), 21:02, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
navicat, на минуточку, стоит $1300. ну, $300, если вам только постгрес, а другие базы не нужны.
| |
|
3.49, Аномномномнимус (?), 17:58, 19/10/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Какие-то мудовикипедисты выпилили его из wiki, хотя в кэше поиска гугл выдаёт превьюшку, что оно было и на русском
| |
|
|
1.34, Цезий Родонович (?), 17:19, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Дайте UNDO !!!
Кто скажет, есть табличка статусов, 2000 строк, обновляются половина каждые 10 секунд, и читаются постоянно, как запилить что бы оно не умирало?
| |
|
2.36, Аноним (27), 17:23, 19/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Автовакуум поставить очень часто. Вот и всё. И вообще, иногда полезно читать документацию.
| |
|
3.87, Цезий Родонович (?), 10:25, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Так жопа получается, непрерывно работает вакум на одной таблице, а базе еще кроме этого много чем нужно заниматься :)
и мне нужно в одной таблице (большой), часто у 5 % строк менять статусы поле число 0,1,2,3
какого хрена таблица растет ппц как?
и что теперь, вакумы работают непрерывно, а базе данных что делать больше ничего не надо?
| |
|
4.120, Мудила (?), 20:37, 20/10/2018 [^] [^^] [^^^] [ответить] | +/– | Но тут гонка получается Один процесс лепит новые строки, под которые нужны новы... большой текст свёрнут, показать | |
|
|
2.37, Аноним (27), 17:25, 19/10/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Чем undo-то лучше? Вы даже самому себе этого объяснить не сможете. Потому что понятия не имеете, как Сегменты отката в Оракле работают.
| |
|
|
4.42, Аноним (27), 17:46, 19/10/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
И что с того? То, что вы имеете 45-ть лет вождения жигулей на дачу не делает из вас раллийного гонщика. Сами ведь понимаете.
| |
|
|
2.40, Аноним (40), 17:37, 19/10/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я сделал UNDO, но потом случайно запустил, поэтому опять ничего нет...
| |
2.56, пох (?), 18:17, 19/10/2018 [^] [^^] [^^^] [ответить]
| –4 +/– |
> Дайте UNDO
это из той же серии где и vacuum full; reindex;
> как запилить что бы оно не умирало?
никак. Или сменить базу данных на такую, авторы которых не изобретали time travel или хотя бы исправили ошибки молодости.
а с форматом хранилища постгреза ничего сделать уже нельзя, только взорвать к чертям.
| |
|
3.59, Аноним (27), 18:32, 19/10/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ну к чему эту чушь транслировать? Вы же не разбираетесь в вопросе совсем. Автовакуум полностью эту проблему решает сейчас. Vacuum Full совсем про другое. И в Оракле нечто подобное тоже приходится делать. До 10-той версии это было крайне мутурное, к слову, занятие.
| |
|
4.75, пох (?), 22:36, 19/10/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
в том и дело что не решает. Проблему раздувания стора, я имею в виду, при банальных апдейтах (причем вовсе не PK, а вообще неиндексированного поля) и, как следствие - тормозов даже при банальном индексном селекте. Потому что индекс, внезапно, у нас отрос в десятки раз больше чем на самом деле надо.
в орацле приходится делать в других случаях и случаи эти изрядно небанальны, если не сказать извратны. Неудивительно что и делается через задницу.
В innodb вообще не приходится - другая конструкция хранилки.
| |
|
5.83, Мудила (?), 23:38, 19/10/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ну, ё-маё, ну, ребята, читайте доки. Нет там никакого "раздувания стора". Если вы не обновляете статистику в соответствии с развитием модели, то, да, вы получаете снижение адекватности "разборщика" запросов. Это настолько очевидные вещи, что смешно о них тут упоминать.
| |
|
6.99, Аноним (98), 13:32, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Нет там никакого "раздувания стора"
Мамкин dba пытается спорить о вкусе устриц с теми, кто их таки ел?
| |
|
5.121, Мудила (?), 20:42, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Кластерные индексы что в Инно, что Сиквеле всё равно нужно обслуживать. В Оракле же ситуация с индексами очень похожа на Слона. Но, и тут я спорить не буду, Оракл значительно быстрее, но он в совсем другой лиге. В Оракле как раз крайне банальны. Куча и индексы по ней очень быстро расходятся под высокой нагрузкой. Но это всё неизбежно. Другое дело, что Оракле это от версии к версии всё больше делается само.
| |
|
|
3.61, Аноним (27), 18:56, 19/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
А, извините, переоценил. Вам, насколько я понял, сама концепциям мультиверсионности аппетит испортила. Ну так, дерзайте, делайте что-то другое.
| |
|
4.77, пох (?), 22:39, 19/10/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
не сама концепция, а последствия конкретно этой ее реализации. Образца 1995го года. Что сейчас нельзя сделать эффективно работающую - очень сомневаюсь.
> Ну так, дерзайте, делайте что-то другое.
вам миллиона существующих storage egnines мало?
| |
|
|
2.65, Аноним (65), 20:40, 19/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если данные условно временные, можете использовать UNLOGGED таблицы (не генерируют события WAL и при фейлах чистятся).
Для частых обновляющихся действий довольно неплохо подходит.
| |
|
3.88, Цезий Родонович (?), 10:31, 20/10/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Дохрена чего пробовали, но вот НАДО, очень, при том что есть и оракл, на тех же задачах, на гораздо более слабом железе, у него не возникает проблем совсем никаких,
без холиваров, нравится постгрес, для небольших задач где только вставки-запросы, все хорошо, sql возможностями нравится и т.д.
| |
3.90, Цезий Родонович (?), 10:58, 20/10/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Кортежей доступно 2130
«Мертвых» кортежей 206960
Последняя автоочистка 2018-10-20 10:55:03.599286+03
Размер таблицы 114 MB
автовакум работает практически непрерывно, 2000 строк Карл!!!, 114 mb
как победить? такая таблица с таким режимом работы нужна.
| |
|
|
5.93, Цезий Родонович (?), 11:40, 20/10/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я же писал уже задержку сдедал, не чаще чем 30 сек
в цикле от 30% до 100% строк
update po.status set last_send_time=, ....= where id=:id по примари кей
ну очень нужна таблица статусов
| |
|
6.106, Мудила (?), 14:49, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Режим изоляции какой? Как транзакция разграничена? И разграничена ли вообще?
| |
6.114, Forth (ok), 17:48, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Вы транзакцию закрываете? Commit есть?
То что наблюдаете очень похоже на типичный недосмотр, нет коммита в коннекте. Апдейты делаете, а транзакцию не закрываете.
| |
|
|
4.103, Мудила (?), 14:23, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ещё раз, читайте как настраивать автовакуум. Покажите тут действующие настройки.
| |
4.108, Мудила (?), 15:11, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Давайте попробуем разобраться. Версия Слона у вас какая? Что вас конкретно не устраивает? То, что файл пухнет? Сценарий ваш довольно типичен и к такому поведению при адекватных настройках приводить не должен.
| |
|
|
2.127, nox (??), 12:54, 21/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ваша проблема, на самом деле, в дизайне. Добавьте поле last_updated или insert_ts и замените UPDATE на INSERT, а запросы на чтение замените на выборку только самого актуального результата. При INSERT вакуум не работает, а удаление старых записей (и запуск вакуума) можно сделать по крону в периоды наименьшей нагрузки и чтобы удалял все и сразу (плюсом будет еще и то, что все удаляемые строки будут к конце таблицы, так что длинных блокировок не будет)
А по хорошему, постгрес не для этой задачи, возьмите другую БД под именно этот функционал и не делайте себе мозг.
| |
|
|
4.143, nox (??), 16:39, 22/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Это очень плохое и некомпетентное предложение.
Сказал человек с ником "Мудила"
Обоснуйте тогда, что ли
| |
|
5.145, Аноним (27), 17:46, 22/10/2018 [^] [^^] [^^^] [ответить] | +/– | Ставить диагноз, когда потциент слился в неизвестном направлении, даже не распис... большой текст свёрнут, показать | |
|
6.146, Аноним (27), 17:49, 22/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Up: неверное выразился -- периодичность чекпоинтов нужно понижать, т.е. повышать промежутки между ними.
| |
6.148, nox (??), 17:53, 22/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ну так вот и я о том же. Просто топикстартер жаловался, что у него вакуум не устраивает, что он распространяется на всю базу и частый запуск ему мешает или не работает, т.к. блокировки. В этом плане моё решение работает как раз норм, т.к. можно контролировать когда делать delete и соответственно вакуум (просто как идея, я ж хз что у него за данные и за модель)
Но вообще да, Слон спокойно справляется с такими вещами, более того, у меня была таблица с 5 млрд строк и 50к апдейтов в секунду - каждый апдейт 5Мб размером и ничего - всё работало и не жужжало и место особенно сильно не ело
Просто Мудилы и ДБА с яйцами видать не очень умеют доки/код читать - вакуум простая штука, пару дней курения мануалов, на крайняк почитать немного кода - и всё становится ясно - где, что и как работает и за что отвечает
| |
|
7.149, nox (??), 18:02, 22/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
> В этом плане моё решение работает как раз норм, т.к. можно контролировать
> когда делать delete и соответственно вакуум (просто как идея, я ж
> хз что у него за данные и за модель)
Забыл уточнить - у него UPDATE, то есть он часто и много делает UPDATE. Если делать часто INSERT, но редко и много DELETE и сразу после этого вакуум, то файл будет расти, но только в периоды между запусками вакуума
| |
|
8.151, пох (?), 22:04, 22/10/2018 [^] [^^] [^^^] [ответить] | +/– | если мы правильно угадали его проблему что это именно из-за особенностей стора,... текст свёрнут, показать | |
|
|
|
|
|
|
2.129, Мудила (?), 14:30, 21/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ладно, понял, что осмысленно диалога "DBA с двадцатилетним стажем" не выйдет.
Просто накрутите
-- autovacuum_vacuum_cost_limit в десять раз (больше 1000) поставьте;
-- autovacuum_vacuum_cost_delay сделайте в районе 5--10.
Если не помогло, то предварительно всё же стоило убедиться, что проблема именно в недостаточно частой "уборке" файла отношения. Потому что подобное поведение может быть следствием очень длительной транзакции, которая работает по данным, которые вы часто изменяете, а значит -- это ошибка вашей модели и её нужно корректировать. В общем, не тупите и читайте документацию.
| |
|
3.153, Цезий Родонович (?), 09:36, 23/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ну нету там длинных транзакций, нету инсертов, делейтов, много коротких апдейтов, и это НЕ единственная таблица, другим тоже нужны ресурсы процессора, память, вакумы, и т.д.
Вакуум на ней висит практически постоянно, и не успевает, блять 2000 строк уже 260MB, простенький запрос к этой таблице должен выполнятся мгновенно, а он задумывается
| |
|
4.154, Аноним (27), 11:31, 23/10/2018 [^] [^^] [^^^] [ответить] | –1 +/– | Думаю, вы уже знаете, что в Слоне update-ов нет, а есть delete insert Как и все... большой текст свёрнут, показать | |
|
5.157, Цезий Родонович (?), 14:40, 23/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
есть и много процессов, но разные строки, read commited,
в данном конкретном случае, 2-3 процесса, (плюс позанимался, добавил нужных индексов для других таблиц, в целом уменьшилась нагрузка на сервер), сделал
alter table set (autovacuum_vacuum_cost_limit = 1000);
alter table set (autovacuum_vacuum_cost_delay = 5);
теперь автовакум не висит постоянно, остановил все сервисы, сделал VACUUM FULL
через пол дня:
Кортежей доступно 2130
«Мертвых» кортежей 28101
vacuum verbose
найдено удаляемых версий строк: 0, неудаляемых - 30230,
какого хрена?, никто таблицу не блокирует
select * from pg_catalog.pg_locks l where l.relation=23037
пусто
| |
|
6.158, Аноним (27), 15:32, 23/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Блокировки тут не причём.
Зомби-транзакции поищите. Всё же, очень похоже на то, что транзакции не фиксируются или разграничены не так, как вы себе представляете. Поэтому задействованные ими кортежи и не подвергаются уборке.
А vacuum full эти мёртвые кортежи убирает?
Понимаете, если у вас много обновляющих данные процессов в одном отношении, то подобная картинка вполне себе типична. В том, что в результате дофига хранится исторических данных, нет ничего ужасного и необычного. Их будет тем больше, чем больше параллельных процессов, работающих с отношением: им же всем нужно получить состояние кортежей на момент начала каждой из транзакций. Другое дело, что шлака столько не должно оставаться.
| |
6.159, Аноним (27), 16:01, 23/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Вот, скажем, началась у вас транзакция Т1. Она длиться, условно, 10 единиц времени. Через десять единиц времени она фиксируется.
T1 началась во время t1.
T2 началась в t1 + 1.
T3 : t1 + 2
T4 : t1 + 3.
Ну и т.д.
Т2 хочет видеть состояние БД на момент t1 + 1. И, соответственно, те кортежи, которые T1 похерила, но не зафиксировала, вакуум удалять не может -- они нужны T2, T3... И так по цепочке. В результате если у вас много процессов которые производят большое кол-во обновлений по ключу, то исторических "хвост" нужно будет держать весьма значительный.
На этом фоне замена обновление на вставку, а потом явное удаление устаревших событий, не кажется таким уж нелепым решением.
| |
6.160, Аноним (27), 16:05, 23/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
А памяти у нас на серваке много? Значение maintenance_work_mem сколько выставлено? БД в кластере много?
| |
|
7.161, Цезий Родонович (?), 09:10, 26/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Короче, нашел, в этой же базе но, вообще не имеюшее к этой таблице никакого отношения, "чужое" приложение после select-а не делает коммит. но у него свои таблицы и к моей никогда не обращается!!!
| |
|
|
|
4.155, Аноним (27), 11:38, 23/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Не зря вас про уровень изоляции транзакции спрашивали. Если у вас много параллельных запросов на изменение, к тому же все они serializable, то что-то подобное может произойти. Если приложение работает через jdbc-драйвер нужно проверить какой режим изоляции для транзакций выбран.
| |
|
|
2.136, лютый джо__ (?), 07:11, 22/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
>есть табличка статусов, 2000 строк, обновляются половина каждые 10 секунд
Накукуй тут вообще реляционная субд?
Если нужна мегаскорость (ну там сотни тысяч запросов в сек с 1 сервера) любой in-memory KV носкль будет хорошо работать или вообще hashmap какой-нибудь с записью журнала и lazy-persistence.
10 строчек кода.
| |
|
3.147, Аноним (27), 17:52, 22/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Слон с этим тоже работает без проблем. Собственно, как раз это самое lazy persistence и происходит: блоки из буферов практически с файл и не успевают попадать большую часть времени. Там фактический I/O с диском получается вообще мизерный.
| |
|
|
1.91, Andrew (??), 11:20, 20/10/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Переводчика на мыло! Зачем так переводить, что смысл кардинально меняется?
>> Добавлен новый вид хранимых процедур, позволяющих использовать транзакции.
Никакого _нового_ вида хранимых процедур не добавляли. Добавили поддержку управления транзакциями из хранимых процедур, и всё. Английское "SQL procedures"- это любые хранимые процедуры, написанные на любом поддерживаемом языке, кроме динамически загружаемых из внешних модулей процедур, написанных, как правло, на C.
>> Поддержка транзакций в процедурах даёт возможность создавать более продвинутые серверные обработчики, например, для пакетной загрузки данных.
В оригинале было "incremental bulk data loading". Инкрементальной пакетной, а не просто пакетной- разница очень существенна.
>> Для определения хранимых процедур с транзакциями добавлена новая команда CREATE PROCEDURE.
Эм... Вообще-то она не новая, она там с незапамятных времен. В оригинале было всего-лишь "SQL procedures can be created using the CREATE PROCEDURE command". То есть просто напомнили, как их создавать.
| |
|
|
3.123, Andrew (??), 22:34, 20/10/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Мой вариант, простите, чего именно? Я, кажется, не предлагал альтернативных вариантов перевода, а лишь указал на ошибки в оригинальном переводе из новости...
| |
|
|
1.101, Аноним (100), 13:54, 20/10/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
CockroachDB через пару лет отправит на свалку этого динозавра.
Из Postgresql уже песок сыпется
| |
|
2.102, Цезий Родонович (?), 14:16, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
https://opennet.ru/opennews/art.shtml?num=46529
"11.05.2017 11:50 Первый стабильный выпуск отказоустойчивой СУБД CockroachDB "
"Из ограничений CockroachDB отмечается плохая пригодность для решений, требующих очень низкого времени отклика при выполнении операций записи и чтения. CockroachDB также плохо адаптирован для нагруженных систем обработки аналитической информации (OLAP), манипулирующих сразу большими срезами данных, и плохо оптимизирован для выполнения сложных SQL-запросов со слиянием нескольких таблиц "
Вы об этом?
| |
|
3.122, Анонимно (?), 21:14, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Да, то было в первой версии.
Прикинь, база маскируется под PostgreSQL, а ведет себя как распределенная, строго консистентная база данных.
Маскируется она полностью, реализуя протокол PostgreSQL.
Запускаешь 1 бинарник и у тебя база с мониторингом, которой приятно пользоваться.
| |
|
4.132, пох (?), 19:49, 21/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Да, то было в первой версии.
а сейчас что?
> Прикинь, база маскируется под PostgreSQL, а ведет себя как распределенная, строго консистентная база данных.
это, конечно, красиво в плане посмотреть как оно стоит, но ничуть не подразумевает того, что оно работает с той же скоростью и теми же (понятными, хотя бы) проблемами, что и оригинал.
> Маскируется она полностью, реализуя протокол PostgreSQL.
"но зачем?!"
неужели это было проще, чем написать свои коннекторы для c/c++/пехепе/пихон/жабы (на самом деле не "и", а "сперва или, а потом как пойдет", поскольку вряд ли одному проекту нужно больше пары из списка ? Или протокол постгреза оказался чем-то удивительно хорош и приятен?
(вот уж вряд ли)
| |
|
5.152, KonstantinB (ok), 04:46, 23/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Протокол постгреса весьма приятен и хорошо задокументирован. Null terminated-строками только несколько злоупотребляют, но это не страшно.
| |
|
|
|
|
1.111, Аноним (111), 15:31, 20/10/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Что значит "Обеспечена корректная маршрутизация операций"? Оно и раньше работало, вот только транзакции там не работали, это оно или о чём речь?
| |
|