Оракл стоит денег, Постгрес нет. Сертифицированные специалисты стоят денег, постгрессовские тоже стоят но дешевле. Оракл стоит больших денег при масштабировании. Постгресс стоит только за разработку. Вообщем далеко не всем охото платить деньги за достаточно посредственную поддержку оракла.
ну практика показывает что 35 тысяч таблиц (без учета индекса) вполне работоспособно. Но конечно всякости вылазят просто со всех сторон и автовакумов нужно много и планировщик местами тупит, но все таки при нормальном объеме памяти и числе ядер вполне живуче.
Насчет приведенной схемы решения: 2 проблемы: constraint exclusion вещь линейная и при большом числе партиций ( уже на паре десятков заметно) реально планировщик начинает тупить. Спасет конечно Prepared Statement но оно не учитывает значения параметров при планировании и тут уже просто может пострадать эффективность запросов.
Вторая проблема это собственно производительность триггеров: вставка просядет.
А насчет партиционирования из коробки аля Оракл. Он деньгов собственно стоит. Так что в халявной СУБД уровня постгресса врядли будет. Я Вот МПП хочу. в оракле он как самолет стоит.
Знаешь, иногда мне кажется что он прав и зачастую людям нужна супер мегасистема хранения с дикими скоростями записи. А то сроду они пишут пишут пишут, все равно потом никто ничего не читает. Тут главное правильно предложить /dev/null. Вот вы, ботаны, не сможете. А такие как Бабушкин и Попов запросто. И ведь продадут, и ведь потом за техподдержку попросят. А то что если вдруг понадобиться данные таки прочитать так «вы не правильно записали» или «а где файлик волшебный на ftp» или «у вас злобный вирус все удалил».
Отвечу ссылкой: www.mfisoft.ru/products/sorm/sorm2/sormovich, так что подробнее рассказывать не буду.
При использовании предпочтение отдается не свежим версиям, а испытанным ибо очень жесотоки требования 24/7 и работа системы в автономнейшем режиме, ибо она физически не имеет выходов в сеть. А даунтайм затрудним.
Повторюсь: не всегда есть возможность обновить. Иногда даже просто физическая отсутствует. Не говоря про организационную. А реально обусловленной необходимости переходить на 9 нет. Тогда смысл?
например?!
Ну с ходу приходит в голову использование того же fillfactor. Использование возможности hot update.
и всё равно таблица пухнет
Но в первую очередь я бы обратил внимание на max_fsm_pages и вообще fsm (для 9 это должно быть не актуально)
Затем бы посмотрел есть ли шансы у автовакуума проваакумить эту таблицу — возможно вы используете апдейты в длительных транзакциях и он просто не может добраться до страницы (автовакуум (и просто вакуум) не вакуумирует те страницы таблиц, которые используются в активных снапшотах, собственно этим он и отличается от полного вакуума).
Если не помогает значит зря используете СУБД с MVCC. Может стоит использовать «блокировщик» тот же MySQL. Некоторые вон для постгресса пишут типа key-value storage (сейчас не вспомню название, вроде hstore) видимо не понимая, что он просто не предназначен для такого рода задач, а потом будут удивлятся чего он в продакшене пухет.
Не у всех PG для тривиального веб. У некоторых еще несколько сотен баз постгресса кое где объединенные в MPP кластеры с объемом данных под террабайт на каждом сервере (собственно база там правда порядка 10-20%) по всей России. Профиль работы что то типа «самописец» — кольцевой. Кое куда только на оленях и доедешь. плюс требования 24/7 и надежность хранения данных. Так что кое где и 8.1 осталось. На девятку переходить нам в продакшене еще рановато… Подождем 9.3 тем более что никакого функционала важного для нас в 9 пока нет.
«Возможность пересоздавать индекс» и «при перекладывании всегда используется пересоздание индекса» несколько разные понятия.
Ну, значит, начнем поносить:
Во-первых, INSERT никоим образом не раздувает таблицу, а лишь добавляет туда данные, собственно, как и DELETE — он просто не освобождает.
Во-вторых, обратите внимание на ваши индексы после фейковых Update: да да он стал в 2 раза толще ибо теперь там ссылка на старую (удаленную и даже подрезанную) и на новую запись. Собственно и механизм фейкового апдейта как правило на серьезной базе не работет — автовакуум тупо не успеет. В итоге надо последовательно и инкрементально апдейтить записи. лучше идя от физического конца.
В-третих: в pgcompactor не все так тривиально, в том числе из за пухнущего индекса, и он тупо не применим для восьмерок. Ему нужно знать физическое расположение записи в таблице. Иначе можно дров наломать.
Потом автовакуума и вакуума не достаточно для переиспользования места. Информация о «дырках» должна еще где то храниться и если вам «повезло» использовать версии младше 8.4, то не профукайте max_fsm_pages и max_fsm_relations.
Но так же вакуум не является строго необходимым для поиска дырок, есть еще также «минивакуум» который выполняется при доступе к странице например во время SELECT, но там много ограничений. Есть еще магический «HOT UPDATE» начиная с 8.3.
Для понимания откуда растут ноги настоятельно рекомендую презентацию Брюса Момджана «MVCC unmasked» на языке наиболее вероятного противника доступная тут: momjian.us/main/writings/pgsql/mvcc.pdf.
Единственное что не знаю где достать со звуком. В принципе он выступал на последнем Highload и я могу попробовать сделать что то типа статейки если хабравчанам будет интересно. Там рядом так же много других презенташек на тему глубин PostgreSQL.
На последнем pg_days на highload, люди, широко известные в узких кругах, настойчиво хвалили pg_reorg, но с некоторой настороженностью, ибо работает на низком уровне и могут быть потери данных, но правда лишь потенциально.
Сам я в экстренных случаях использую «перекладывалку» — принцип похожий на используемый в pg_reorg, но все исключительно на уровне SQL. При этом я являюсь ярым противником различных утилит/скриптов и прочих «костылей» против блоатинга.
Если ваша база пухнет — надо лечить болезнь, а не заниматься купированием симптомов. Если автовакуум не справляется — надо настраивать его или менять запросы.
что есть максимальная скорость распространения взаимодействий
2.
мы может определить способ проверки является ли какая-то скорость этой самой максимальной
3.
Для скорости света мы получили, что да, является
НО
4.
Если мы получим скорость больше скорости, для которой мы показали, что она максимальная
5.
окажется исходное предположение о наличии максимальной скорости
из 4 не следует что не верен сам постулат о наличии максимальной скорости. Не верно лишь предположение и способ проверки того, что именно скорость света максимальна. А сам постулат верен.
Мы можем предположить что например скорость звука является максимальной, потом проверить на ряде экспериментов и доказать это, а потом новый эксперимент покажет со это совсем не так, но он же не опровергнет (и не докажет) сам факт наличие макс. скорости.
Вы можете объяснить «почему»? Почему не скорость звука или не скорость света в стекле, а именно скорость света в вааукуме? Я понимаю, что сейчас пока не известен носитель быстрее скорости света, но почему исключается принципиальная возможность наличия такового? Какие нибудь супер-волны. Например таже квантовая постоянная, почему она постоянна? может быть возможно сделать «волны квантовой постоянной» и предположить что они будут распространяться быстрее скорости света и модулируя их можно будет передавать информацию быстрее скорости света? Заметьте про монотонность времени я не говорю она именно что не нарушается
Я правильно понимаю, что «экспериментально» означает опять таки, что все наши эксперименты используют электромагнитную среду как средство распространения информации о взаимодействии и отсюда можно сделать вывод что быстрее просто не получится и мы получаем все артефакты с искривлением времени.
Что если завтра появиться способ передать информацию быстрее скорости света (тут вот квантовую телепортацию поминали) то с помощью этого механизма получится синхронизировать часы без необходимости расположить материю в одной точке, и передачи светового лазерного импульса? И часть выводов предыдущих окажется не совсем верна? А передав информацию мы сможем и «передать» материю разрушив объект в одном месте и собрав в другом по полученной информации?
Опять таки «постулируется», т.е. читай «притягивается за уши». Эвклид вон то же постулировал постулировал, а потом пришел Лобачевский и придумал, что Эвклид напостулировал лишнего и у студентов математических специальностей появилась новая куча жестокого матана :)
Много картинок не осилил. :)
Мне тут одному кажется, что есть некое противоречие и подмена понятий? Почему наклон желтых линий это скорость света в вакууме? И границы «светового конуса» по сути отождествляются с границами «информационного конуса».
Что это за такой магический наклон? Почему максимальной скоростью переноса информации является скорость света (электромагнитной волны)? Почему исключается наличие других типов взаимодействий распространяющихся быстрее чем скорость ЭМИ в вакуме? Вот сейчас найдут Бозон Хигса и начнут его делить на части, какие нибудь мегаструны, супербраны и т.п. и окажется что между ними может распространяться информация со скоростью быстрее скорости света.
Я могу ошибаться, но если перейти в мир слепых людей, для которых максимальная скорость распространения информации скорость звука — то будут все теже самые эффекты, а сверхзвуковой полет пули — аналогом парадокса близнецов. И можно будет доказывать что мол это перемещение во времени, нарушение следственно причинных связей и т.д.
Или я не прав и где то глубоко в ткани вселенной зашита эта константа?
эээ врядли. Дело в том что планировщик сам занимается переписыванием запросов, так что зачастую (если конечно запросы эквиваленты) ручное переписывание много не поможет. Другое дело что вы занимаясь таким переписыванием ненароком улучшите/оптимизируете сам запрос.
Лучше бы докомошники партиционирование нормальное впилили или MPP. Или хинты по чилдам: «не чекай 100500 чилдов на constraint exclusion, а сразу топай к таким то» или SQL/MED допиливали быстрее, причем с оптимизацией выполнения запросов для PG-PG связки. Вообщем хочу PostgresXC взрослый и в основном бранче.
А «хинты» и до этого были: «SET enable_seqscan=OFF;» работает в сессии. Можно набор функций по сохранению/включению/выключению допилить и вуаля. Причем профит в том что не указываешь, как именно надо делать, а показываешь чего делать не стоит.
Хотя если честно ни разу не сталкивался еще с тем, что ручное указание плана при правильной статистике дало профит. Всегда это было или криво сконфигуреный автоваакуум/аналайз, или проблемы с индексами, или кривая структура. Планировщик в PG достаточно эффективный.
Именно. Видовые особенности на одном уровне, на уровне особенностей социального поведения на другом.
Эксперименты ставились на грызунах — при избытке пищи, пригодной температуре, и т.п. рождаемость популяции падала, и наоборот при не совсем благоприятных условиях увеличивалась численность.
И очень похоже у людей. Там был пример про рост рождаемости мальчиков перед войной и рост рождаемости девочек после войны.
Но на самом деле выводы конечно неоднозначные. Но такая теория есть.
Ну вообщето это глубоко-глубоко в животных инстинктах. И даже глубже. Саморегуляция популяций, вида: при сложных окружающих условиях популяция начинает размножаться дабы обеспечить выживаемость потомства и сохранение вида за счет увеличения числа особей — тупо «всех съесть не успеют».
При нормальных окружающих условиях численность популяции сокращается дабы уменьшить внутривидовую борьбу за ресурсы. Это характерно для высокоорганизованных животных. Для низкоорганизованных на уровне различных видов.
А для людей это помница два типа демографии — первого (низкая смертность и низкая рождаемость) — развитые страны и второго типа (высокая смертность и высокая рождаемость) — развивающиеся.
Ну не тривиальная задача отодрать userspace от платформы мобильного железа. Ну или наоборот прикрутить. Проходили собственно это при Symbian. Работа с GSM стеком вроде как задача RTOS, их с Application OS подружить это не так и просто. Все эти HTC, Galaxy и прочие андроиды только этим и занимаются. Похоже что Samsung'овцы даже в s3 еще не победили потерю телефона сеткой. Правда в современном мире «звонить» это уже вспомогательная функция телефона, и многие готовы с этим мириться
Насчет приведенной схемы решения: 2 проблемы: constraint exclusion вещь линейная и при большом числе партиций ( уже на паре десятков заметно) реально планировщик начинает тупить. Спасет конечно Prepared Statement но оно не учитывает значения параметров при планировании и тут уже просто может пострадать эффективность запросов.
Вторая проблема это собственно производительность триггеров: вставка просядет.
А насчет партиционирования из коробки аля Оракл. Он деньгов собственно стоит. Так что в халявной СУБД уровня постгресса врядли будет. Я Вот МПП хочу. в оракле он как самолет стоит.
При использовании предпочтение отдается не свежим версиям, а испытанным ибо очень жесотоки требования 24/7 и работа системы в автономнейшем режиме, ибо она физически не имеет выходов в сеть. А даунтайм затрудним.
Повторюсь: не всегда есть возможность обновить. Иногда даже просто физическая отсутствует. Не говоря про организационную. А реально обусловленной необходимости переходить на 9 нет. Тогда смысл?
Ну с ходу приходит в голову использование того же fillfactor. Использование возможности hot update.
Но в первую очередь я бы обратил внимание на max_fsm_pages и вообще fsm (для 9 это должно быть не актуально)
Затем бы посмотрел есть ли шансы у автовакуума проваакумить эту таблицу — возможно вы используете апдейты в длительных транзакциях и он просто не может добраться до страницы (автовакуум (и просто вакуум) не вакуумирует те страницы таблиц, которые используются в активных снапшотах, собственно этим он и отличается от полного вакуума).
Если не помогает значит зря используете СУБД с MVCC. Может стоит использовать «блокировщик» тот же MySQL. Некоторые вон для постгресса пишут типа key-value storage (сейчас не вспомню название, вроде hstore) видимо не понимая, что он просто не предназначен для такого рода задач, а потом будут удивлятся чего он в продакшене пухет.
«Возможность пересоздавать индекс» и «при перекладывании всегда используется пересоздание индекса» несколько разные понятия.
Во-первых, INSERT никоим образом не раздувает таблицу, а лишь добавляет туда данные, собственно, как и DELETE — он просто не освобождает.
Во-вторых, обратите внимание на ваши индексы после фейковых Update: да да он стал в 2 раза толще ибо теперь там ссылка на старую (удаленную и даже подрезанную) и на новую запись. Собственно и механизм фейкового апдейта как правило на серьезной базе не работет — автовакуум тупо не успеет. В итоге надо последовательно и инкрементально апдейтить записи. лучше идя от физического конца.
В-третих: в pgcompactor не все так тривиально, в том числе из за пухнущего индекса, и он тупо не применим для восьмерок. Ему нужно знать физическое расположение записи в таблице. Иначе можно дров наломать.
Потом автовакуума и вакуума не достаточно для переиспользования места. Информация о «дырках» должна еще где то храниться и если вам «повезло» использовать версии младше 8.4, то не профукайте max_fsm_pages и max_fsm_relations.
Но так же вакуум не является строго необходимым для поиска дырок, есть еще также «минивакуум» который выполняется при доступе к странице например во время SELECT, но там много ограничений. Есть еще магический «HOT UPDATE» начиная с 8.3.
Для понимания откуда растут ноги настоятельно рекомендую презентацию Брюса Момджана «MVCC unmasked» на языке наиболее вероятного противника доступная тут: momjian.us/main/writings/pgsql/mvcc.pdf.
Единственное что не знаю где достать со звуком. В принципе он выступал на последнем Highload и я могу попробовать сделать что то типа статейки если хабравчанам будет интересно. Там рядом так же много других презенташек на тему глубин PostgreSQL.
На последнем pg_days на highload, люди, широко известные в узких кругах, настойчиво хвалили pg_reorg, но с некоторой настороженностью, ибо работает на низком уровне и могут быть потери данных, но правда лишь потенциально.
Сам я в экстренных случаях использую «перекладывалку» — принцип похожий на используемый в pg_reorg, но все исключительно на уровне SQL. При этом я являюсь ярым противником различных утилит/скриптов и прочих «костылей» против блоатинга.
Если ваша база пухнет — надо лечить болезнь, а не заниматься купированием симптомов. Если автовакуум не справляется — надо настраивать его или менять запросы.
1.
2.
3.
НО
4.
5.
из 4 не следует что не верен сам постулат о наличии максимальной скорости. Не верно лишь предположение и способ проверки того, что именно скорость света максимальна. А сам постулат верен.
Мы можем предположить что например скорость звука является максимальной, потом проверить на ряде экспериментов и доказать это, а потом новый эксперимент покажет со это совсем не так, но он же не опровергнет (и не докажет) сам факт наличие макс. скорости.
Что если завтра появиться способ передать информацию быстрее скорости света (тут вот квантовую телепортацию поминали) то с помощью этого механизма получится синхронизировать часы без необходимости расположить материю в одной точке, и передачи светового лазерного импульса? И часть выводов предыдущих окажется не совсем верна? А передав информацию мы сможем и «передать» материю разрушив объект в одном месте и собрав в другом по полученной информации?
Мне тут одному кажется, что есть некое противоречие и подмена понятий? Почему наклон желтых линий это скорость света в вакууме? И границы «светового конуса» по сути отождествляются с границами «информационного конуса».
Что это за такой магический наклон? Почему максимальной скоростью переноса информации является скорость света (электромагнитной волны)? Почему исключается наличие других типов взаимодействий распространяющихся быстрее чем скорость ЭМИ в вакуме? Вот сейчас найдут Бозон Хигса и начнут его делить на части, какие нибудь мегаструны, супербраны и т.п. и окажется что между ними может распространяться информация со скоростью быстрее скорости света.
Я могу ошибаться, но если перейти в мир слепых людей, для которых максимальная скорость распространения информации скорость звука — то будут все теже самые эффекты, а сверхзвуковой полет пули — аналогом парадокса близнецов. И можно будет доказывать что мол это перемещение во времени, нарушение следственно причинных связей и т.д.
Или я не прав и где то глубоко в ткани вселенной зашита эта константа?
А «хинты» и до этого были: «SET enable_seqscan=OFF;» работает в сессии. Можно набор функций по сохранению/включению/выключению допилить и вуаля. Причем профит в том что не указываешь, как именно надо делать, а показываешь чего делать не стоит.
Хотя если честно ни разу не сталкивался еще с тем, что ручное указание плана при правильной статистике дало профит. Всегда это было или криво сконфигуреный автоваакуум/аналайз, или проблемы с индексами, или кривая структура. Планировщик в PG достаточно эффективный.
Эксперименты ставились на грызунах — при избытке пищи, пригодной температуре, и т.п. рождаемость популяции падала, и наоборот при не совсем благоприятных условиях увеличивалась численность.
И очень похоже у людей. Там был пример про рост рождаемости мальчиков перед войной и рост рождаемости девочек после войны.
Но на самом деле выводы конечно неоднозначные. Но такая теория есть.
При нормальных окружающих условиях численность популяции сокращается дабы уменьшить внутривидовую борьбу за ресурсы. Это характерно для высокоорганизованных животных. Для низкоорганизованных на уровне различных видов.
А для людей это помница два типа демографии — первого (низкая смертность и низкая рождаемость) — развитые страны и второго типа (высокая смертность и высокая рождаемость) — развивающиеся.