Как стать автором
Обновить
62
0.1
Михаил @michael_v89

Программист

Отправить сообщение

Ваша процедура работает быстро, только неправильно. Когда кастомера нет в базе и номер заказа null, кастомер создается, а заказ нет. Процедура возвращает null.
Хороший пример, что логика в процедурах увеличивает вероятность багов. Которые потом кто-то должен исправлять, а компания должна за это платить.
Более того, этот случай подвержен состоянию гонки. Для проверки можно добавить PG_SLEEP() в создание кастомера и отправить 2 запроса одновременно, не создадутся оба заказа, а финальный customer.last_order будет '000002'.

Когда кастомера нет в базе, и номер заказа не null, но его нет в базе, заказ и кастомер не создаются. Процедура возвращает null без какого либо описания ошибки.

Если же кастомер есть в базе, и номер заказа не null, но его нет в базе, то создается новый заказ с указанным номером. Неконсистентное поведение, которое тоже похоже на баг, надо либо в обоих случаях создавать, либо в обоих не создавать.
Более того, этот случай тоже подвержен состоянию гонки. Для проверки можно добавить PG_SLEEP() в создание заказа и отправить 2 запроса с 3 товарами одновременно. Будет создан 1 заказ с указанным номером и 6 товарами. И это уже серьезно, такую систему нельзя допускать в эксплуатацию.

Спасибо за наглядный пример, к чему приводит логика в базе. Даже специалисты с опытом разработки в БД в такой простой задаче не могут написать корректный код. Пусть приложение работает медленнее, зато правильнее.

Также эта процедура почему-то позволяет подменять владельца существующего заказа. То есть может быть заказ "customerA2024/000002", принадлежащий кастомеру "customerB". Уж не знаю, баг это или фича.

У вас код процедуры 46 строк, у меня 43, и при этом у меня много пустых строк для читаемости. Если написать сплошным текстом как у вас, то будет 31 строка. То есть кода меньше на 30%. К тому же у меня нет багов параллельной обработки.

Для проверки производительности я запустил из браузера 100 запросов, по 4 штуки одновременно, в каждом заказе 100 товаров. Как можно было ожидать, приложение оказалось медленнее. Получились такие результаты:

Среднее время работы логики на сервере (ms):
APP: 207
SQL: 14
Среднее время выполнения запроса на клиенте (ms):
APP: 563
SQL: 376

Для одиночных запросов с небольшим количеством товаров получается так:

Среднее время работы логики на сервере (ms):
APP: 70
SQL: 10
Среднее время выполнения запроса на клиенте (ms):
APP: 200
SQL: 140

Процедура на сервере в 10-20 раз быстрее приложения (различие зависит от количества товаров, для 1000 товаров будет еще больше). Но так как надо еще передать результаты работы процедуры потребителю (в данном случае браузеру), то это время тоже стоит учитывать. И для потребителя разница получается всего в 1.5 раза, что не так уж много. Для консольной команды, которая работает на сервере и обрабатывает много заказов, процедура конечно будет значительно быстрее.

Но так как эта процедура неправильно работает при параллельных запросах, в такой статистике нет большого смысла. Если добавлять защиту, время работы процедуры будет другим.

В приложении можно было использовать массовый INSERT, тогда различие было бы меньше, но я не стал.

Код можно найти здесь.

Думаю, этот пример дает достаточно информации, чтобы каждый мог сделать вывод, нужно ли ему в своем проекте делать ускорение работы таким способом, и к чему это может привести.

Это говорит только о чудовищно кривом коде

Видимо вам все-таки проще оставаться в рамках собственных фантазий. Правда для вас слишком неудобна, и вы ее избегаете. Выдумываете всякие условия, в которых ваши утверждения будут верными.

На всякий случай поясню. Код там проще некуда, "прочитать данные, обработать, повторить", меняется только количество запрашиваемых строк в одном запросе и количество потоков.

В среде Hadoop обработку можно вести хоть на миллионе хостах по всей планете

И? В чем изменение-то способа решения задачи "отправить данные в sphinx"?

В упор не вижу здесь ответа на два заданных мной вопроса.

Я сказал, что ваш вопрос содержит фразу, вырванную из контекста, и потому некорректен. Это и есть мой ответ, другого ответа на некорректный с моей точки зрения вопрос я дать не могу.

Код написан.

Я уже сказал, что мне не нужен код вашего реального проекта. Предложение было написать код примера и выложить, чтобы его можно было запустить самому, проверить производительность, и переписать на другом языке. Он не обязательно должен быть такой же, как в реальном проекте.

я массивы и композитные типы использую только для обработки данных, но не для хранения в БД

Если вы хотите обсудить архитектуру, пишите полное законченное приложение. Тогда может до вас дойдет, зачем для этих значений нужен JSON. Да, без него тоже можно сделать. Но толку от этого не будет.

Наконец-то вы написали хотя бы какой-то код, проверю и напишу по результатам позже.

И да, если как в Вашей публикации отказаться от внешних ключей

В базе системы из моей публикации есть внешние ключи.

В двух строках слово "интернет-магазин" повторяется ТРИЖДЫ!

Вот и читайте внимательно, что там написано. Две строки прочитать не можете. Слышу звон, да не знаю где он. Еще можете прочитать в словаре определение слова "контекст".
Да, там слово "интернет-магазин" повторяется трижды. Нет, это не значит, что указанная там система это интернет-магазин.

Вы ну никак не сможете утилизировать на операции выгрузки данных из вообще любой БД - вообще проигнорировали.

Я проигнорировал, потому что вы проигнорировали мое описание соотношения работы сети и процессора. Никакие ваши рассуждения фактов не меняют. У нас эта система работала в 100 потоков, и производительность увеличилась примерно в 100 раз по сравнению с одним потоком, а не в 4. Значит ваши рассуждения где-то неправильные, а выяснять где мне неинтересно.

Параметров оборудования я не знаю, я программист, а не системный администратор, мне их никто не сообщал. Я только подобрал параметры приложения для оптимального использования сети и процессора. Если бы после 4 потоков не было ускорения, я бы оставил 4.

Сначала, Вы вообще не назвали СУБД

Я уже несколько раз сказал почему - потому что конкретное хранилище ничего не меняет. Но потом выяснилось, что вы этого не понимаете, поэтому я сообщил больше деталей.

Можно хранить в Postgres, и все равно для этой задачи надо будет загружать много данных в приложение и обрабатывать параллельно. Нет, встроенный полнотекстовый поиск Postgres не подходит по требованиям. Если вы не можете понять такую простую вещь, и не можете представить, как такое приложение будет работать с Postgres, то вообще нет смысла с вами это обсуждать.

сначала на мои прямо поставленные вопрос ответьте

Я уже ответил в прошлом комментарии. Похоже, вы не способны понять ответ. Ничем не могу тут помочь, хотя я попытался уже несколько раз.

Хотеть не вредно.
Я Вам уже объяснил, почему публиковать этот код не буду.

Ну я же говорю, сплошная демагогия.
Я вас изначально вообще-то и не просил, вы сами ответили на мое предложение написать код. Я сказал "Вот код на PHP, кто хочет может написать на SQL", вы сказали "Может наоборот?", я сказал "Давайте", теперь вы уже и наоборот не хотите. Не хотите писать код, не надо было отвечать.

Не вижу результатов в виде таблицы с сопоставлениями.

Ну так вы же не сказали, в каком виде вам нужен результат. Что просили, то и получили.

Соответственно, я никак не могу проверить результат.

Вот как раз чтобы проверить результат, люди для бенчмарков прикладывают код. Чтобы не выяснять 3 дня, кто что и как проверял. Жаль, что вы этого не понимаете.

Кому нужен интернет-магазин, который не может гарантировать ни сроки, ни даже само исполнение заказа?

Блин, объясняю еще раз для тех кто в танке. Система, которая описана в моей статье, это не интернет-магазин, и заказов там нет. Вообще, в принципе, и не было никогда. Бизнес-область приложения описана фразой "Есть отдельный сервис для поставщиков товаров". Заказы находятся не в сервисе для поставщиков, а в интернет-магазине, это другая система с другим кодом и базой, она в статье не описана.

Не можете или не хотите - так и признайтесь.

Я уже несколько раз сказал, что не хочу. Я хочу получить пример кода, я написал об этом сразу в том комментарии.

Мне не нужен Ваш код. Мне нужны результаты его выполнения

Пфф, пожалуйста. Процедура в базе занимает 10 секунд, параллельная обработка в приложении на 10 потоков 3 секунды. Что дальше?

Я честно говорю, что постановку, подобную приведенной Вами, никакого смысла реализовывать в хранимой процедуре нет

Ну и я об этом же говорю. Нет смысла делать такую логику в хранимых процедурах, это усложнит код и не принесет пользы.

так и контекст обсуждения именно РСУБД

Я вам сказал, что там была MySQL. MySQL это уже не РСУБД?
Также я сказал, что конкретное хранилище в этой задаче не имеет значения. Можете представить любую РСУБД, которую хотите.

Или это уже не "отдельный statement"?

Опять вырываете фразы из контекста? Я сказал "каждый отдельный statement из этих 4". Запрос со всеми этими 4 statement-ами это не один из этих 4 statement-ов.

Вы согласны, что один INSERT без CTE это обычная CRUD операция?

Опять вырываете фразы из контекста? Никак у вас не получается конструктивно обсуждать. Вы думаете, никто не заметит что-ли, и все будут считать вас победителем в споре?

В том же комментарии есть фраза "Реализацию на PHP я уже написал, ссылка на репозиторий есть в статье". То есть я привел код на PHP, показал его всем, и предложил сделать то же самое на SQL.

Вы сказали "А может наоборот?". "Наоборот" это значит, что вы приведете код на SQL, покажете его всем, а я сделаю то же самое на PHP. Я согласился. Раз предложили, то делайте. Или признайте, что вам слабо, и вы поторопились с этим предложением.

Ссылку то Вы не привели

Приводил в другом комментарии, и приводил цитаты много раз. Если вы не следите за дискуссией, то это ваши проблемы.

Вы хотите это опровергнуть?

Нет. Я вам так и сказал, что каждый отдельный statement из этих 4 это обычная CRUD операция. Значит утверждение было о том, что каждый из них надо делать в виде процедуры - отдельная процедура с одним INSERT в некоторую таблицу, отдельная процедура с одним DELETE, и т.д.

И кто из нас не просто игнорирует, а подменяет контекст?

Вы. Я отвечал именно на вашу просьбу, а не на что-то другое. Более того, если вам нужная именно реляционная БД, то я сделал пояснение, что сначала она там была, и "много данных" загружалось из нее в приложение. Вы об этом спрашивали, или опять будете увиливать?

Зачем мне эта демагогия, если вопрос был про СХД и реляционную СУБД?

Демагогию разводите вы. Ваша просьба выглядела так: "А вот тут просьба подробней. Как по первому, так и по второму вопросу. С примерами.". Тут нет ничего про СХД. Я про СХД в том комментарии тоже ничего не говорил, поэтому непонятно, почему вы у меня про это спрашиваете. Сами придумали требование про СХД, сами и отвечайте.

Еще раз, какая СХД использовалась?

Идите в пень со своим приказным тоном.

то больше четырех потоков для загрузки данных использовать на нем не имело никакого смысла.

Ну можете оставаться в своих фантазиях, мне какое дело.

А зачем вы дали бизнес-требования, если разговор был про пример кода?

Нет, пример кода для сравнения вы не сделали.

Вы хотите сказать, что Ваш вопрос не являлся спором?

Мой вопрос не являлся спором с утверждением "начинают приходить такие запросы, что вынужденно приходится для этих (и только для этих!) запросов отказываться от ORM". Он являлся спором с другим утверждением.

Кроме "На фига?" там никаких уточнений, что речь идет исключительно про некоторые проекты, ни слова не было.

Потому что умные люди учитывают контекст исходного комментария, в котором написано "обычные crud операции". Я вам уже указал на то, что ваше понимание слова "обычные" не такое, как у меня. Я не знаю, почему вы ожидаете, что я должен был ориентироваться на ваше понимание, а не на свое.

Или Вы не публикацию тут обсуждаете, а одному Вам известный случай?

Ну ок, расскажу еще и это. На Хабре комментарии организованы в виде дерева. Вопросы к статье появляются на верхнем уровне дерева. Если же кто-то хочет ответить на комментарий первого уровня, он пишет дочерний комментарий на следующем уровне, для этого в комментарии есть кнопка "Ответить". Уровень комментария показывается точками возле заголовка. Я обсуждал тот случай, который задан не в статье, а в комментарии первого уровня - "обычные crud операции". Он известен не только мне, а всем, кто прочитал этот комментарий.

Какое отношение HBase имеет к статье о хранимых процедурах?

Он имеет отношение к вашей просьбе "Приведите примеры, где нужно загрузить много данных из БД в приложение, а потом уже параллелить их обработку". HBase это БД. Раньше вместо HBase была MySQL, только тип хранилища тут принципиально ничего не меняет.

Тут только попытка демагогии с подменой темы (с реляционной SQL СУБД на не реляционную NoSQL). Или Вы не знаете, что такое СХД?

Это пример проекта, который загружает гигабайты данных в приложение, про который вы спрашивали, и данные в нем хранились в HBase на нескольких серверах. Все воркеры там работали нормально без задержек. Это всё, что вам нужно знать, дальше сами думайте.

Чрезмерно упрощенное подобие обычной SCM и описано в Вашей публикации.

Молодец, догадались. Теперь подумайте о том, зачем люди вообще пишут и рассматривают упрощенные подобия чего-то.

На остальное отвечать не буду, с моей точки зрения это какие-то бессмысленные утверждения. Но вы можете продолжать считать, что вы победили в споре, сказав много умных слов.

Ну вот, сами написали "Может вы попробуете", а теперь сливаетесь. Зачем предлагали тогда, если делать не хотите.

А я приводил пример реального проекта.

А зачем вы его приводили, если та ветка была о предложении написать код и сравнить? Опять какой-то оффтоп.

как в измененной Вами постановке

Это не измененная мной постановка. Первый раз фраза про атрибуты встречается не в моем комментарии. Ctrl+F "брали все атрибуты именно с неё"

Вы вообще понимаете разницу

Я понимаю разницу, именно поэтому и написал вопрос. Это вы не понимаете, что вам говорят. Читайте внимательно дискуссию, прежде чем спорить.

начинают приходить такие запросы, что вынужденно приходится для этих (и только для этих!) запросов отказываться от ORM

Да никто с этим не спорил, откуда вы это взяли?)

Просто у Вас еще недостаточно опыта и каким-то чудом Вы на такое никогда не нарывались

Ох, попробую еще один раз объяснить. Я работал в таких проектах. И даже писал логику на хранимых процедурах. Но мой вопрос был не про такие проекты, а про противоположные. Где вообще нет таких действий, где надо отправлять 100 тысяч запросов через ORM. И где даже 40 секунд в кроне раз в сутки не создает проблемы. А вы написали про посторонние вещи, которые с темой маленьких проектов не связаны. О чем я вам уже не раз сказал.

Там, где были терабайты данных, у нас была Apache HBase, потому что MySQL с миллиардами документов плохо справляется, и даже сами разработчики MySQL сказали, что быстрее не получится.

Я и не просил вас выкладывать код реального проекта, читайте внимательно.

Не вижу.

Ctrl+F "select max", первый результат.
Если вступаете в дискуссию, то неплохо бы сначала ознакомиться с контекстом.

На что я резонно ответил, что нужна не агрегатная функция

А я вам резонно ответил, что я и сам это знаю, а разговор был про select max, именно поэтому я и задал вопрос.

Ну приводите свой, который лучше, я ж не против. Это пруф хотя бы потому, что он показывает, что я не сам придумал такое понимание этого термина.

"Обычная" - это уже откровенный субъективизм.

Этот откровенный субъективизм был в исходном утверждении (не моём), поэтому я спрашивал в его контексте.

Но только в Вашем крошечном мирке.

Да, это только в моем крошечном мирке. Я говорю только про него с самого начала. Я уже писал, что миллионы пользователей ERP и миллиарды операций от них меня не интересуют.

Вот и дайте ссылку на СХД

Я написал название в предыдущем комментарии. Читайте внимательно. Ссылки в Гугле сами найдете, чай не маленький.
Потом можете подумать о том, что воркеры работают не мгновенно, и пока один воркер обрабатывает данные, база работает с другим.

Хабр глючит и это не Ваша публикация?

1. Это моя публикация.
2. Проект, в котором я мерил время операции SELECT и про который сказал "у нас вообще нет действий, которые сохраняют несколько десятков строк в одной транзакции" это не тот проект, который указан в этой публикации.
3. JSON в публикации это не история изменений. Заказов и SKU в публикации вообще нет.

1
23 ...

Информация

В рейтинге
3 058-й
Откуда
Россия
Зарегистрирован
Активность