Т.е. это был контролируемый процесс против неконтролируемого процесса, который происходит в движке СУБД, когда он решает перенести данные.
Не так. Контролируемый кодом против контролируемого движком. И я сторонник как раз того, чтобы контролировала СУБД.
представьте, вы решили секционировать таблицу по статусам. Как вы будете подчищать данные?
Я не понял, что имеется в виду под термином "подчищать". Но если вы имеете в виду удаление, то я этого делать не буду в принципе. А ещё я вспомню о субсекционировании.
Я бы сказал, что аномалии это следствие плохой декомпозиции
Да в том и дело, что автор вместо исследования предметной области и нормализации модели почему-то пытается идти от данных к схеме. Крайне странное мероприятие.
При явном WHERE прошлые периоды сами обрежутся, на то и partition pruning. Главное, чтобы парсер по тексту мог легко понять, что условие отбора (или какая-то его часть) точно соответствует выражению секционирования.
То есть, по-вашему, таскать из одной таблицы в другую - нормально, а из секции в секцию, которые по сути такие же таблицы (у нас же постгресс) - это уже моветон? Вот совсем не понимаю. Зато понимаю, что, как только потребуется что-то без оглядки на статус, придётся лезть в две отдельные таблицы и объединять полученные субнаборы. То есть от двух таблиц, как по мне, никакого профиту и геморрой на горизонте. Да и хранение одной сущности в нескольких таблицах - это ещё меньший best practices, кмк.
Любая БД является моделью некоего процесса, отображением значений и зависимостей характеристик этого процесса. Зависимости в значения данных, о которых вы ведёте речь, являются следствиями зависимостей внутри процесса, который моделируется. В связи с чем стремление "забыть" об исходнике и придумывать эти зависимости только на основе данных модели - по меньшей мере странно и не очень разумно. Хотя бы потому, что объём данных почти наверняка не покрывает область допустимых значений параметров. Собственно изъяны ака аномалии и есть следствие этой неполноты.
И поневоле возникает вопрос - а нафига оно вообще такое надо? К сожалению, именно на этот вопрос ответа в статье я не вижу.
Во-первых, сервер БД работает с данными более эффективно, чем фреймворк - как-никак, он для этого создан. И к тому же он как раз заточен на выполнение пакетных операций. Итерации для него не очень естественны, хотя и вполне возможны.
Во-вторых, вместо двух валидаций (в клиентском коде и затем на стороне СУБД) вы получаете одну. Оформляете её в хранимую процедуру и выполняете, когда потребуется. Не надо ни воркеров, ни листенеров, ни чего-то ещё - послал запрос на выполнение, передав имя исходного файла, и жди готового результата, просто и плоско, как блин. К тому же если потребуется вносить изменения в код - у вас всего одна точка его хранения и выполнения, не надо прыгать с обновлением клиентов на вашем компьютерном зоопарке.
В третьих, вы можете после валидации и вставки, в том же запросе, удалить вставленные данные из такой промежуточной таблицы, и сразу получить набор записей, которые не прошли валидацию и требуют ручной обработки (ну или могут быть использованы иным путём). Или, если валидация показала критически кривые данные, откатить вообще всё нафиг лёгким движением руки, а не трясти бэкапы.
PostgreSQL умеет импортировать CSV-файлы в таблицу простейшим запросом COPY. Причём для исключения проблем импорта (особенно если исходный файл потенциально ну очень кривой и может организовать проблемы вроде несовпадения типов или там кодировок) можно просто тянуть всю строку в один блоб и потом на стороне же SQL парсить. Кстати, именно по причине возможности таких недостатков исходных данных и не советую использовать врапперы для подключения внешнего CSV как таблицы.
А для снижения вероятности блокировок рабочих таблиц - импорт в блоб, парсинг, валидация и вставка в структурную копию рабочей таблицы, вставка обработанных и валидированных данных в рабочую таблицу. Минимум интерференций с другими процессами.
??? Вот сейчас не понял, причём совсем. И, кмк, потому, что вы меня поняли неправильно.
Валидация в питоновском коде у вас есть по-любому, и по-любому же она построчная. Так что в этом вопросе разницы я не вижу вообще - хоть построчно вставляем, хоть пакетами. А вот уже потом отвалидированные на уровне python-кода строки вы вставляете в таблицу, т.е. пересылаете наконец на SQL-сервер. И именно на этой стадии у вас при пакетной вставке появляется то, что вы называете "хрупкостью". И об альтернативной реализации именно этой стадии я и говорю - с одной стороны, вставка выполняется пусть и построчно, но внутри транзакции, следовательно, фиксация вставленных строк будет пакетная, с другой стороны, не прошедшая для отдельных записей валидация на уровне SQL-схемы (констрейнты и внешние ключи) не приводит к отказу от вставки всего пакета, отказ выполняется только для невалидных с точки зрения схемы БД отдельных записей.
К сожалению, Постгресс, в отличие от некоторых других СУБД, безусловно считает транзакцию проваленной и требующей отката, если в ходе выполнения запросов транзакции возникла ошибка, и не допускает мысли, что ошибка при выполнении одного из запросов может быть штатным течением транзакции. Но это можно пофиксить вложенными транзакциями. В SQL-коде это выглядит пусть и монстрообразно, но оно работоспособно.
create table test (id int, check (id < 10));
begin;
begin;
insert into test values (1); -- запись вставляется
commit;
begin;
insert into test values (11); -- ошибка ограничения
commit; -- субтранзакция откатывается
begin;
insert into test values (5); -- запись вставляется
commit;
commit; -- фиксируется вставка 2 записей
select * from test;
Внешняя транзакция коммиттится, сохраняя в таблицу записи со значениями 1 и 5, несмотря на то, что внутри при добавлении записи со значением 11 возникла ошибка - она маскируется откатом вложенной транзакции.
Такой подход позволяет, с одной стороны, выполнять вставку пусть и по одной записи, но внутри транзакции, что может оказаться быстрее, чем простая построчная вставка, и в то же время решить вопрос с невалидными записями.
Будет ли это быстрее или медленнее, чем простая построчная запись - не скажу, а протестировать не на чем. И уж тем более не скажу, будет ли это быстрее из программного кода. Но подход в принципе имеет право на существование.
PS. Например, в MySQL такой подход сильно ускоряет построчную вставку - но там не требуются вложенные транзакции.
Да бред... вот как постоянно включённый VPN у меня может принести описанные проблемы какому-то (да вообще абстрактному) подростку и аннулировать усилия государства?
Ынженеры, аднака... Наши просто вместо шестерёнчатой поставили бы червячную передачу. При перекрутке в стоп-зону просто червяк улетает, и поворот прекращается.
ЧПУ-станки, насколько я помню, существуют куда как дольше 3D-принтеров. И пластик они режут прекрасно, а детали при правильном выборе материала заготовок получаются гораздо более прочными. Можно даже боёк и гильзу из пластика выточить, прочности хватит, и тогда металла в оружии останется всего ничего - капсюль да сердечник пули. Почему губернатор не предложила начать именно с них? Или ей просто никто не сказал, что на станках с ЧПУ можно изготовить детали оружия?
Шикарно. Вместо того, чтобы сделать нормальный разъём, давайте защищать уже имеющееся говно.
Взяли бы нашу советскую вилку да розетку от электроплиты, что ли - для неё ваши несчастные 10 ампер вообще ни о чём... а для тех, кому такое решение не понравится, можно сослаться на эту... как её... ну которая рассказывала, что мы чипы для дронов из стиральных машин выковыриваем.
Не так. Контролируемый кодом против контролируемого движком. И я сторонник как раз того, чтобы контролировала СУБД.
Я не понял, что имеется в виду под термином "подчищать". Но если вы имеете в виду удаление, то я этого делать не буду в принципе. А ещё я вспомню о субсекционировании.
Да в том и дело, что автор вместо исследования предметной области и нормализации модели почему-то пытается идти от данных к схеме. Крайне странное мероприятие.
При явном WHERE прошлые периоды сами обрежутся, на то и partition pruning. Главное, чтобы парсер по тексту мог легко понять, что условие отбора (или какая-то его часть) точно соответствует выражению секционирования.
То есть, по-вашему, таскать из одной таблицы в другую - нормально, а из секции в секцию, которые по сути такие же таблицы (у нас же постгресс) - это уже моветон? Вот совсем не понимаю. Зато понимаю, что, как только потребуется что-то без оглядки на статус, придётся лезть в две отдельные таблицы и объединять полученные субнаборы. То есть от двух таблиц, как по мне, никакого профиту и геморрой на горизонте. Да и хранение одной сущности в нескольких таблицах - это ещё меньший best practices, кмк.
Любая БД является моделью некоего процесса, отображением значений и зависимостей характеристик этого процесса. Зависимости в значения данных, о которых вы ведёте речь, являются следствиями зависимостей внутри процесса, который моделируется. В связи с чем стремление "забыть" об исходнике и придумывать эти зависимости только на основе данных модели - по меньшей мере странно и не очень разумно. Хотя бы потому, что объём данных почти наверняка не покрывает область допустимых значений параметров. Собственно изъяны ака аномалии и есть следствие этой неполноты.
И поневоле возникает вопрос - а нафига оно вообще такое надо? К сожалению, именно на этот вопрос ответа в статье я не вижу.
Почему не секционирование?
SHOW CREATE TABLE не может показать ЭТУ проблему в принципе.
0.04 ms и 40 миллисекунд не одно и то же, они различаются... на 3 порядка.
Угу... сделайте звук на динамике погромче и расположите его поближе к приёмной антенне часов. По-моему, это можно воспринимать только как курьёз.
На самом деле преимущества-то, наверное, имеются.
Во-первых, сервер БД работает с данными более эффективно, чем фреймворк - как-никак, он для этого создан. И к тому же он как раз заточен на выполнение пакетных операций. Итерации для него не очень естественны, хотя и вполне возможны.
Во-вторых, вместо двух валидаций (в клиентском коде и затем на стороне СУБД) вы получаете одну. Оформляете её в хранимую процедуру и выполняете, когда потребуется. Не надо ни воркеров, ни листенеров, ни чего-то ещё - послал запрос на выполнение, передав имя исходного файла, и жди готового результата, просто и плоско, как блин. К тому же если потребуется вносить изменения в код - у вас всего одна точка его хранения и выполнения, не надо прыгать с обновлением клиентов на вашем компьютерном зоопарке.
В третьих, вы можете после валидации и вставки, в том же запросе, удалить вставленные данные из такой промежуточной таблицы, и сразу получить набор записей, которые не прошли валидацию и требуют ручной обработки (ну или могут быть использованы иным путём). Или, если валидация показала критически кривые данные, откатить вообще всё нафиг лёгким движением руки, а не трясти бэкапы.
PostgreSQL умеет импортировать CSV-файлы в таблицу простейшим запросом COPY. Причём для исключения проблем импорта (особенно если исходный файл потенциально ну очень кривой и может организовать проблемы вроде несовпадения типов или там кодировок) можно просто тянуть всю строку в один блоб и потом на стороне же SQL парсить. Кстати, именно по причине возможности таких недостатков исходных данных и не советую использовать врапперы для подключения внешнего CSV как таблицы.
А для снижения вероятности блокировок рабочих таблиц - импорт в блоб, парсинг, валидация и вставка в структурную копию рабочей таблицы, вставка обработанных и валидированных данных в рабочую таблицу. Минимум интерференций с другими процессами.
??? Вот сейчас не понял, причём совсем. И, кмк, потому, что вы меня поняли неправильно.
Валидация в питоновском коде у вас есть по-любому, и по-любому же она построчная. Так что в этом вопросе разницы я не вижу вообще - хоть построчно вставляем, хоть пакетами. А вот уже потом отвалидированные на уровне python-кода строки вы вставляете в таблицу, т.е. пересылаете наконец на SQL-сервер. И именно на этой стадии у вас при пакетной вставке появляется то, что вы называете "хрупкостью". И об альтернативной реализации именно этой стадии я и говорю - с одной стороны, вставка выполняется пусть и построчно, но внутри транзакции, следовательно, фиксация вставленных строк будет пакетная, с другой стороны, не прошедшая для отдельных записей валидация на уровне SQL-схемы (констрейнты и внешние ключи) не приводит к отказу от вставки всего пакета, отказ выполняется только для невалидных с точки зрения схемы БД отдельных записей.
К сожалению, Постгресс, в отличие от некоторых других СУБД, безусловно считает транзакцию проваленной и требующей отката, если в ходе выполнения запросов транзакции возникла ошибка, и не допускает мысли, что ошибка при выполнении одного из запросов может быть штатным течением транзакции. Но это можно пофиксить вложенными транзакциями. В SQL-коде это выглядит пусть и монстрообразно, но оно работоспособно.
Внешняя транзакция коммиттится, сохраняя в таблицу записи со значениями 1 и 5, несмотря на то, что внутри при добавлении записи со значением 11 возникла ошибка - она маскируется откатом вложенной транзакции.
Такой подход позволяет, с одной стороны, выполнять вставку пусть и по одной записи, но внутри транзакции, что может оказаться быстрее, чем простая построчная вставка, и в то же время решить вопрос с невалидными записями.
Будет ли это быстрее или медленнее, чем простая построчная запись - не скажу, а протестировать не на чем. И уж тем более не скажу, будет ли это быстрее из программного кода. Но подход в принципе имеет право на существование.
PS. Например, в MySQL такой подход сильно ускоряет построчную вставку - но там не требуются вложенные транзакции.
Да бред... вот как постоянно включённый VPN у меня может принести описанные проблемы какому-то (да вообще абстрактному) подростку и аннулировать усилия государства?
Эммм... не понял, у кого ИИ - у мойки или у обуви?
Да ладно, чтобы на такой станции да не найти 5 киловольт на пару миллисекунд?
Ынженеры, аднака... Наши просто вместо шестерёнчатой поставили бы червячную передачу. При перекрутке в стоп-зону просто червяк улетает, и поворот прекращается.
Так говорят же, что порвали всё - трубы, кабели... но скорее всего первыми были снесены именно ограничители. Масса плюс инерция - это страшная сила.
ЧПУ-станки, насколько я помню, существуют куда как дольше 3D-принтеров. И пластик они режут прекрасно, а детали при правильном выборе материала заготовок получаются гораздо более прочными. Можно даже боёк и гильзу из пластика выточить, прочности хватит, и тогда металла в оружии останется всего ничего - капсюль да сердечник пули. Почему губернатор не предложила начать именно с них? Или ей просто никто не сказал, что на станках с ЧПУ можно изготовить детали оружия?
Шикарно. Вместо того, чтобы сделать нормальный разъём, давайте защищать уже имеющееся говно.
Взяли бы нашу советскую вилку да розетку от электроплиты, что ли - для неё ваши несчастные 10 ампер вообще ни о чём... а для тех, кому такое решение не понравится, можно сослаться на эту... как её... ну которая рассказывала, что мы чипы для дронов из стиральных машин выковыриваем.
Во проблема. Ставишь клиент на компьютер, и имеешь всё, что требуется. Смартфон-то тут зачем?