Из текста не понял: речь о физическом отключении? Как вообще отключение может произойти при наличии спутниковой связи и существования оверлейных сетей?
>Кроме того, по инерции двигатель спереди тоже должен не ломать ноги людям в салоне, а вылетать вперед и крушить препятствие. А он в лучшем случае под салон норовит уйти.
Лобовой удар-то по бамперу приходится, перед двигателем. В этом случае следует говорить об инерции движения салонной клетки относительно двигателя и земли.
А мне, кроме того, показалось, что заголовок не соответствует содержанию. Не увидел в статье ни одного упоминания бизнес-модели, кроме слов «бум стартапов» и ни одного упоминания выхода из зоны комфорта. Чувствую себя обманутым.
Как грубо. Может, лучше все же сообщать авторам о грамматических ошибках в ЛС?
По мне, статья замечательная. Кроме того, описанные в ней практики ведут к повышению качества сервиса ИТ-службы. Рад, что мы постепенно двигаемся от мышления «юзвери тупые» в сторону «наша задача помочь юзерам и облегчить их работу».
Я тоже не специалист в Postgresql, всего лишь энтузиаст с небольшим опытом работы с этой СУБД в личном проекте-печочнице. Мой проект предполагал работу с достаточно крупными таблицами-хранилищами, содержащими порядка 10^8 строк. Я столкнулся с тем, что даже простые селекты с условием на индексированное при помощи кластеризованного btree-индекса поле работали очень медленно. Это при том, что результат селекта предположительно должен был возвращать не более миллиона строк. Понятное дело, сложные запросы, включающие inner join тоже работали медленно.
Анализируя ситуацию, я убедился, что на больших таблицах идет раздувание древовидного индекса, когда его размеры становятся сравнимы с размерами самих данных. Одной из хороших практик в таких ситуациях является дробление таблицы на партиции, когда есть пустая мастер-таблица, задающая структуру данных, и набор наследниц, собственно хранящих информацию. Обычно дробят данные по полю (или комбинации полей), по которым обычно задаются условия запроса.
К примеру, есть таблица, в которую постоянно добавляются данные. Каждая запись промаркирована отметкой времени timestamp. Если предполагается делать запросы, извлекающие данные для конкретного дня, разумно дробить таблицу именно по этому условию. Один день — одна партиция.
В этой схеме зачастую на каждую партицию вешается check constraint, дабы при исполнении запроса отсекать партиции, в которых заведомо нет интересующих данных.
Такое решение сильно снижает общий размер таблицы с индексами, с которой будет работать СУБД во время исполнения одного или пачки похожих запросов. Я предполагаю, что это может положительно повлиять на производительность, т.к. вся таблица, ожидающая присоединения, может быть закеширована в RAM. Поэтому, в частности, я попросил уточнить сайзинг и настройки work_mem и shared_buffers.
Безусловно, в своих предположениях я могу ошибаться, т.к. я достоверно не знаю, что находится у постгреса под капотом. Да и не СУБДист я. Поэтому было бы действительно интересно увидеть в рамках статьи анализ и некие best practices. Но, как я понял из комментариев, у автора не было возможности менять структуру хранения и вообще была иная задача.
Кстати, насколько я помню, наличие индексов в постгрес приводит к замедлению только на маленьких таблицах. Да и то, если планировщик их по какой-то причине использует.
Любопытный способ. Было бы приятно увидеть результаты синтетических тестов SELECT с условиями на примере трех ситуаций:
Простой SELECT из большой таблицы
Тот же SELECT из большой таблицы, разбитой на партиции с грамотно построенными индексами и использованием constraint exclusion
Тот же SELECT, обернутый в COPY по вашей методике.
В рамках статьи ожидал также объяснения, почему этот метод работает. Как в вашем случае строится план запроса? В моем понимании при таком сценарии все равно должен сначала выполняться внутренний селект, результат которого будет отправлен в копи. КМК, ускорение может быть разве что психологическое — в том случае, когда результат вложенного селекта будет отправляться в поток вывода пачками, по мере выполнения запросами.
И еще. Как выглядит ваш postgresql.conf? Размер оперативной памяти ни о чем не говорит в отрыве от размера таблицы и размера work_mem и shared_buffers.
Спасибо за анализ! Добавлю свои пять копеек к остальным комментариям.
>Аналогичным образом, рассчитано, что находясь вблизи Проксимы Центавра данная система передачи данных обеспечит скорость около 70 Мбит/с. Т.е. у человечества появится возможность смотреть в реальном времени видео трансляцию из соседней звездной системы.
Боюсь, что одно утверждение из другого не следует. Да, потоковое видео будет возможно. Но задержку сигнала никто не отменял. Надо же как-то этим 40 фотонам на один бит успеть долететь от Проксимы Центавра до Земли. Так что ни о каком реалтайме, кмк, пока речи и быть не может.
КМК, если рассматривать человеческое тело как тепловую машину, в модели матрицы эта машина имела бы кпд>100%.
Представьте цикл: машины произвели порцию еды, затратив на это энергию E. Человек ее съел, выработал e тепла. Согласно термодинамике, e всегда меньше E.
С чего вы делаете вывод о пологости траектории?
Лобовой удар-то по бамперу приходится, перед двигателем. В этом случае следует говорить об инерции движения салонной клетки относительно двигателя и земли.
Подумать только: звезды — дырки в небесном эфире, через которые параллельные вселенные просвечивают. Потрясающе.
По мне, статья замечательная. Кроме того, описанные в ней практики ведут к повышению качества сервиса ИТ-службы. Рад, что мы постепенно двигаемся от мышления «юзвери тупые» в сторону «наша задача помочь юзерам и облегчить их работу».
Анализируя ситуацию, я убедился, что на больших таблицах идет раздувание древовидного индекса, когда его размеры становятся сравнимы с размерами самих данных. Одной из хороших практик в таких ситуациях является дробление таблицы на партиции, когда есть пустая мастер-таблица, задающая структуру данных, и набор наследниц, собственно хранящих информацию. Обычно дробят данные по полю (или комбинации полей), по которым обычно задаются условия запроса.
К примеру, есть таблица, в которую постоянно добавляются данные. Каждая запись промаркирована отметкой времени timestamp. Если предполагается делать запросы, извлекающие данные для конкретного дня, разумно дробить таблицу именно по этому условию. Один день — одна партиция.
В этой схеме зачастую на каждую партицию вешается check constraint, дабы при исполнении запроса отсекать партиции, в которых заведомо нет интересующих данных.
Такое решение сильно снижает общий размер таблицы с индексами, с которой будет работать СУБД во время исполнения одного или пачки похожих запросов. Я предполагаю, что это может положительно повлиять на производительность, т.к. вся таблица, ожидающая присоединения, может быть закеширована в RAM. Поэтому, в частности, я попросил уточнить сайзинг и настройки work_mem и shared_buffers.
Безусловно, в своих предположениях я могу ошибаться, т.к. я достоверно не знаю, что находится у постгреса под капотом. Да и не СУБДист я. Поэтому было бы действительно интересно увидеть в рамках статьи анализ и некие best practices. Но, как я понял из комментариев, у автора не было возможности менять структуру хранения и вообще была иная задача.
Кстати, насколько я помню, наличие индексов в постгрес приводит к замедлению только на маленьких таблицах. Да и то, если планировщик их по какой-то причине использует.
Простой SELECT из большой таблицы
Тот же SELECT из большой таблицы, разбитой на партиции с грамотно построенными индексами и использованием constraint exclusion
Тот же SELECT, обернутый в COPY по вашей методике.
В рамках статьи ожидал также объяснения, почему этот метод работает. Как в вашем случае строится план запроса? В моем понимании при таком сценарии все равно должен сначала выполняться внутренний селект, результат которого будет отправлен в копи. КМК, ускорение может быть разве что психологическое — в том случае, когда результат вложенного селекта будет отправляться в поток вывода пачками, по мере выполнения запросами.
И еще. Как выглядит ваш postgresql.conf? Размер оперативной памяти ни о чем не говорит в отрыве от размера таблицы и размера work_mem и shared_buffers.
>Аналогичным образом, рассчитано, что находясь вблизи Проксимы Центавра данная система передачи данных обеспечит скорость около 70 Мбит/с. Т.е. у человечества появится возможность смотреть в реальном времени видео трансляцию из соседней звездной системы.
Боюсь, что одно утверждение из другого не следует. Да, потоковое видео будет возможно. Но задержку сигнала никто не отменял. Надо же как-то этим 40 фотонам на один бит успеть долететь от Проксимы Центавра до Земли. Так что ни о каком реалтайме, кмк, пока речи и быть не может.
Представьте цикл: машины произвели порцию еды, затратив на это энергию E. Человек ее съел, выработал e тепла. Согласно термодинамике, e всегда меньше E.