Наверное вы пропустили момент, где автор указывал, что при спуске ему стало тоже плохо (дезориентация). Чтобы окончательно потерять сознание могло как раз не хватить сил, которые он бы потратил на подъём. Ради чего ему эти 70 метров? Эльбрус уже давно покорён.
Спасибо, почитал - https://github.com/wal-g/wal-g/blob/master/docs/PostgreSQL.md я так понял, что это восстанавливает весь кластер, а не отдельную БД. Вот чего не понял - про какое облако речь? Хотелось бы внутри своей локальной сети складывать бэкапы.
Ещё одно ограничение pg_dump - нет возможно PITR (восстановление на заданный пользователем момент времени). Может вы планируете в этом направлении дорабатывать утилиту? (Пока алгоритма, кроме "развернуть бэкап-докидать wal- перекинуть восстановленную бд на целевой сервер" Я подсказать не могу.
А ещё пирамидальная сортировка не паралелится и не работает на списках последовательного доступа. По сути - улучшенный пузырьковый алгоритм. Любую "кучу" данных захочется сначала упорядочить или проиндексировать.
Не совсем понимаю, почему минусуют статью - может из-за того, что где-то только с середины становиться понятно, что речь о ПосгресПро. А может за то, что разрабам просто передали запросы, без предложений по оптимизации.
Окей, может за то время, что я отсутствовал на Хабре что-то координально поменялось (если за форк свободного проекта ставят +37 https://habr.com/ru/companies/greenatom/articles/814589/comments/#comment_26829629). Давайте вопрос по сухим цифрам. "Ещё у нас 15–20 тысяч задач в одном проекте, а есть проекты и по 150–200 тысяч задач." ... "В итоге перенесли больше 2 тысяч проектов, более 50 тысяч активных задач и в целом больше 200 тысяч задач, которые не в фазе работы." Итак имеем, что в Jira было минимум 2 тысячи проектов (которые перенесли), причём минимум в одном из проектов было примерно 200 тысяч задач (то есть минимум 229985 задач). После переноса указывается, что есть минимум 250 к задач.
Я правильно понял, что Jira тащила большее количество задач? Можете выложить ТТХ её сервера-приложения и вашего текущего?
Называть в курилке можно хоть "ебалда на веб-морде". Тут почти официальный пост от большой вроде как серъёзной компании. GitLab и GitHub (которые о ужас!! тоже не ЗДЕСЬ произведены) почему-то написаны нормально (видимо потому что интегрированы - то есть забугорному OpenSSL всё же доверяем, когда припрёт))).
Даже не удивляюсь пренебрежительным назанием от топикстартера "Джира" - Jira позволила вам зарабатывать денег просто копируя её функционал. Проявите хотя бы вежливость.
"Во-вторых, они поднимали цены, нарушали работу сервиса и под конец сообщили, что прекратят поддержку российских аккаунтов." Ваша компания не будет поднимать цену на ваше ПО? Ваша компания будет работать с Талибаном?
"В-третьих, у них там есть пара фатальных то ли уязвимостей, то ли ставших известными бекдоров," То есть вы даже не разобрались, в что указано в CVE к Jira?
"которые существенно снижают безопасность без внешних патчей или прикрытия умными файрволами." А ваше ПО такое надёжное, что вы просто так решили " у нас появилась идея окуклиться в своей серверной версии в замкнутом контуре за DMZ" не выставлять его в Интернет?
Из-за @v=n добавляется Compute Scalar в план выполнения (примерно 1% от всей стоимости плана, но на 100000 строк вместо 46 ms выдаёт 156 ms)
DECLARE @v DATETIME2 = SYSDATETIME()
UPDATE table_name
SET n = @v
WHERE n IS NULL;
SELECT @v
GO
Конечно есть вероятность, что после DECLARE будет попадание в следующий такт CPU (поэтому; и конечно GO пропускаются), но в задании точность была не указана) Вы приняты на работу в маленькую мононациональную компанию)))
Спасибо за хорошую статью! Но всё же хотелось бы последовательности от простого к сложному. То есть вы пропустили пункт "как обновлять статистику", но не дошли до темы "как определить, что статистика требует обновления".
Наверное вы пропустили момент, где автор указывал, что при спуске ему стало тоже плохо (дезориентация). Чтобы окончательно потерять сознание могло как раз не хватить сил, которые он бы потратил на подъём. Ради чего ему эти 70 метров? Эльбрус уже давно покорён.
Спасибо, почитал - https://github.com/wal-g/wal-g/blob/master/docs/PostgreSQL.md я так понял, что это восстанавливает весь кластер, а не отдельную БД. Вот чего не понял - про какое облако речь? Хотелось бы внутри своей локальной сети складывать бэкапы.
Ещё одно ограничение pg_dump - нет возможно PITR (восстановление на заданный пользователем момент времени). Может вы планируете в этом направлении дорабатывать утилиту? (Пока алгоритма, кроме "развернуть бэкап-докидать wal- перекинуть восстановленную бд на целевой сервер" Я подсказать не могу.
А ещё пирамидальная сортировка не паралелится и не работает на списках последовательного доступа. По сути - улучшенный пузырьковый алгоритм. Любую "кучу" данных захочется сначала упорядочить или проиндексировать.
И мне два минуса за что-то вкатали((
Инвертированный индекс. Звучит как будто его построили, а потом перестроили. Упорядоченный в порядке убывания индекс. Desc Сухо и по делу
Не совсем понимаю, почему минусуют статью - может из-за того, что где-то только с середины становиться понятно, что речь о ПосгресПро. А может за то, что разрабам просто передали запросы, без предложений по оптимизации.
Жду pgbouncera, а то с HAproxy устал воевать
Мне бы хотелось узнать цифры топик стартера. Я вроде без сарказма написал вопрос.
200 тыщ для Москвы норм для начинающего ИТшника. Это работодатели крутят хвосты, так как им выгоднее поменьше платить за ту же работу.
Сколько из 2 тысяч? 10 побеседовали, 1 выбрали?
Напишите свою фамилию, имя, отчество, год рождения - пришлю вам повестку, так как нужно защищать Родину (война всё же).
Окей, может за то время, что я отсутствовал на Хабре что-то координально поменялось (если за форк свободного проекта ставят +37 https://habr.com/ru/companies/greenatom/articles/814589/comments/#comment_26829629).
Давайте вопрос по сухим цифрам.
"Ещё у нас 15–20 тысяч задач в одном проекте, а есть проекты и по 150–200 тысяч задач."
...
"В итоге перенесли больше 2 тысяч проектов, более 50 тысяч активных задач и в целом больше 200 тысяч задач, которые не в фазе работы."
Итак имеем, что в Jira было минимум 2 тысячи проектов (которые перенесли), причём минимум в одном из проектов было примерно 200 тысяч задач (то есть минимум 229985 задач). После переноса указывается, что есть минимум 250 к задач.
Я правильно понял, что Jira тащила большее количество задач? Можете выложить ТТХ её сервера-приложения и вашего текущего?
Называть в курилке можно хоть "ебалда на веб-морде". Тут почти официальный пост от большой вроде как серъёзной компании. GitLab и GitHub (которые о ужас!! тоже не ЗДЕСЬ произведены) почему-то написаны нормально (видимо потому что интегрированы - то есть забугорному OpenSSL всё же доверяем, когда припрёт))).
Даже не удивляюсь пренебрежительным назанием от топикстартера "Джира" - Jira позволила вам зарабатывать денег просто копируя её функционал. Проявите хотя бы вежливость.
"Во-вторых, они поднимали цены, нарушали работу сервиса и под конец сообщили, что прекратят поддержку российских аккаунтов."
Ваша компания не будет поднимать цену на ваше ПО? Ваша компания будет работать с Талибаном?
"В-третьих, у них там есть пара фатальных то ли уязвимостей, то ли ставших известными бекдоров,"
То есть вы даже не разобрались, в что указано в CVE к Jira?
"которые существенно снижают безопасность без внешних патчей или прикрытия умными файрволами."
А ваше ПО такое надёжное, что вы просто так решили
" у нас появилась идея окуклиться в своей серверной версии в замкнутом контуре за DMZ"
не выставлять его в Интернет?
Так практически любая деятельность, кроме научных изысканий — это некий компилянт (даже не всегда правдоподобный).
Первый пост на Хабре, где я боюсь писать отрицательные коменты…
Из-за @v=n добавляется Compute Scalar в план выполнения (примерно 1% от всей стоимости плана, но на 100000 строк вместо 46 ms выдаёт 156 ms)
Конечно есть вероятность, что после DECLARE будет попадание в следующий такт CPU (поэтому; и конечно GO пропускаются), но в задании точность была не указана) Вы приняты на работу в маленькую мононациональную компанию)))
Спасибо за хорошую статью! Но всё же хотелось бы последовательности от простого к сложному. То есть вы пропустили пункт "как обновлять статистику", но не дошли до темы "как определить, что статистика требует обновления".
Привет из 2020)) Крутой пост!