Что-то вы путаете. Правильная классификация такая - есть OLTP, то есть небольшие количественно изменения, и есть пакетные операции, к которым все ваши проводки раз в день и относятся. OLTP из-за небольшого количества изменений вполне красиво ложится на ORM. Массовое же изменение, естественно, логичнее делать более специализированными средствами. Но поскольку вы сами говорили, что массово проводки сохраняются один раз в день, то простым смещением этого счастливого момента на ночь вы решите все проблемы вашего магазина, и при этом возможная неэффективность используемого вами ORM на больших объёмах никого не заденет.
Но это общие принципы. Конкретика будет когда вы проведёте тесты на своей конфигурации со свойственной именно вам нагрузкой.
вижу попытку оптимизировать 0.1% операций с БД ценой затрат на семантический анализ остальных 99.9%
Анализ (чаще всего не семантический) производится всегда. Вопрос лишь в его полноте. Полноту постепенно подтягивают, добавляя те или иные дополнительные варианты. Если вариант достаточно общий, то внезапно становится простым то, что раньше казалось сложным (затратным по времени). На а, например, граф изменений, который вы задали в своём примере, как раз и укладывается в общий подход по работе с такими графами. Вся сложность там - количественная. Нужно сказать оптимизатору, когда и где меняются переменные. Если для вас непривычно под переменными понимать значения в таблицах, то это не значит, что кто-то другой уже давно не использует именно такой подход. И подход этот достаточно дёшев по сравнению с вашими ожиданиями. Скорее всего дешевле даже одной записи на диск, а потому вполне применим.
Докажите
Тысячу ORM пилят десятки тысяч разработчиков. Пяток-другой оптимизаторов в известных БД пилят хорошо если десятка два разработчиков. Десятки тысяч намного больше пары десятков.
переносить нагрузку на клиентов
Оптимизация распределённых вычислений на порядки сложнее, ибо вносятся вероятностные задержки и неопределённое поведение. Поэтому не надо про "всё делать на клиенте". Он не справится.
Я без объяснения причин отказываюсь пользоваться массовой вставкой данных
Я объяснял - это усложнение практически не нужно, поскольку БД справляется. В том небольшом количестве случаев, когда БД не справится - напишем чистый SQL или вообще хранимку.
Оптимизация всегда производится прозрачно для использующей её стороны. Если же оптимизатор меняет результат алгоритма, ожидаемый разработчиком (а только тогда код перестанет работать), то это означает ошибку в коде оптимизатора. То есть с нормальным оптимизатором всё будет работать.
Какой ценой?
Стоимостной анализ придумали сотни лет назад. Автоматизировали десятки лет назад.
А профита никакого, кроме поддержки кривых рук, зачем-то посылающих в БД одинаковые запросы
То же самое можно сказать про SQL - профита никакого, кроме кривых рук, ленящихся писать специфические для каждой БД запросы сразу в машинных кодах.
Вообще, я не понимаю, зачем вы упорствуете и встаёте на пути прогресса? Оптимизаторы есть. Они развиваются. Если вам в их применении кажется что-то сложным, это совсем не значит, что от оптимизаторов нужно отказаться. Ну а конкретно в случае с ORM ваша собственная ссылка выше показывает, что существенной разница между универсальным множественным инсертом и специализированным для конкретной субд очень мала, соответственно, упрощение работы по созданию ORM вполне приемлемо, поскольку БД умеет оптимизировать неидеальное поведение ORM.
Хотя да, если бы все вещи на свете были бы идеальными, то я был бы только рад. Но мир так устроен, что эффективнее оптимизировать на стороне нескольких известных БД, нежели в сотнях (а то и тысячах) ORM.
Когда-нибудь ORM подтянется, но сейчас это просто неактуально. Возражения же скорее показывают нам этакое старческое брюзжание (независящее от возраста), вечное недовольство тем "какая молодёжь нынче пошла", а затем следует ожидать чего-то вроде "вот в наши-то годы...". Примите мир таким, какой он есть. Или улучшите сами. Не получается? Тогда почему вы вините других, а себе разрешаете быть неидеальным? И не оправдывайтесь другой сферой интересов, потому что в итоге все мы - население одного маленького шарика, и если кто-то на шарике отлынивает, находя очень веские оправдания, то почему то же самое не может сделать другой?
Да, такой вариант оптимизатор большинства БД наверняка сочтёт неоптимизируемым и БД выполнит его строго последовательно, по одной записи на каждый инсерт. Но это не значит, что все запросы имеют подобный характер. Я же писал про 99%. Да, вы можете придумать запрос из группы 0.1%, но что это доказывает?
Но, с другой стороны, даже ваш запрос некоторые оптимизаторы могут улучшить. Разработка оптимизаторов такого уровня, разумеется, не для массовых СУБД, а в массовых, возможно, оптимизатор сумеет объединить в один инсерт каждую пару для t2. Принципиально там применим вполне стандартный алгоритм, особенно если оптимизатор знает, что в пределах одной транзакции временную таблицу никто не видит. Ну а дублирующийся селект например даже mysql вообще легко оптимизирует просто запоминая результат, я уж не говорю про оракла или ms sql.
Здесь ответ на те сложности, которые могут показаться неустранимыми, но на самом деле очень просты.
Трассировку не покажу, потому что нужно тратить приличное время. Если нет сложных (для автоматического разбора) триггеров, то трассировка и не нужна - БД сумеет оптимизировать. Примеров в сети много, правда скорее всего не всем вашим критериям они смогут удовлетворить. Но если вам это важно - ничто не мешает провести собственное расследование с важным для вас набором критериев. Принципиально смешанная последовательность, при соблюдении простых условий (присутствующих в 99,9% случаев), ничем не отличается от однородной.
до стандарта 1992 года, в котором конструкция VALUES (...), (...) ... (...) уже была
Не знаю, насчёт была она там или нет, но знаю, что оракл в 12-й версии её не поддерживал, так что ваши пожелания отправляйте им - они виновники.
Во-первых, Во-вторых, В-третьих...
Всё это актуально и для bulk insert, а потому давно решено. Ссылки ищут одним и тем же алгоритмом, независимо от количества ссылок. Триггеры чаще всего отсутствуют, а если присутствуют - простые. Только в каких-то там тысячных долях случаев триггеры есть и сложные, тогда БД всё делает последовательно и без оптимизации, но в 999 из 1000 случаев этого не бывает. Sequence так же без разницы, какой диапазон отдать, это одна операция и никак более ни на что серьёзное не влияет.
Здесь проверка только на стороне сервера. Есть ещё клиент с его батчами. Сервер, как показывает тест, легко справляется с тривиальной оптимизацией. И даже bulk insert не сильно улучшает ситуацию в сравнении с множественным инсертом, там возможно на парсинг время уходит. Остальное осталось за кадром - кто и как реально оптимизирует. Скорее всего, серверу вообще не нужна информация от клиента о наличии батча, поскольку очевидно, что её сервер может собрать сам, тогда вообще весь разговор про "неправильный ORM" окажется полностью некорректным. И это наиболее вероятный вариант, хотя в тесте он не отражён явно, поэтому не 100% уверенности.
И да, перец из статьи по ссылке забыл нам рассказать, какую СУБД он использовал. Или у шарпистов по умолчанию всегда ms sql?
Раз в день этот объём, даже неоптимальным образом исполненный, будет вполне по силам любой СУБД.
ORM следует реализовывать эти особенности СУБД
Выше отвечал - если реализация batch не от группы идиотов, то никаких проблем не будет.
чтобы findById(ID id) позволял искать по списку ID, saveAll(Iterableentities) создавал один DML для каждой таблицы а не кучу маленьких
findById как раз по списку и ищет. saveAll вы можете руками допилить, на то он и враппер. Но повторюсь - маленькие dml наверняка агрегируются, потому что ms sql всё же довольно старая СУБД и было бы удивительно, если они такую тривиальную оптимизацию до сих пор не сделали.
а попытки применения на больших объемах сразу показывают горизонты
Не знаю про 1С, возможно дело в кривом драйвере, отправляющем на сервер запросы без batch-a.
если сразу в библиотеке нет идеологии правильного использования это и любое другое решение ждет
Идеология ORM везде одна. Вопрос только к конкретной реализации. Со стороны БД наверняка возможность есть, а что там одноэсовцы намутили со своей стороны - ну кто-ж этих умников знает? Хотя вы можете провести предложенное выше простой тестирование и сравнить. Правда не удивлюсь, если в 1С забыли вообще выставить наружу возможность включить batch.
писать сто INSERT ... VALUES (...), вместо одного INSERT ... VALUES (...), (...) ... (...) - граничит с идиотизмом )))
Здесь стандартная проблема наибольшего общего деноминатора. ORM должен работать с максимальным количеством БД, поэтому деноминатор в виде относительно древнего стандарта SQL неизбежен. Но с другой стороны batch предназначен именно для ускорения, не смотря на то, что принимает он всё подряд в любой последовательности. То есть ORM базируется на идее эффективного выполнения batch. А уж как конкретно написан этот батч, зависит от реализации библиотек языка, где батч задействован. Но было бы просто глупо сделать в языке батч и не выделять в нём инсерты в одну и ту же таблицу. Зачем тогда вообще он нужен? Вот поэтому выбранный в ORM подход правильный - может кто-то сдуру и сделает дебильный батч, но в среднем по больнице он всё же будет более или менее оптимальный. Так что идиотизма там нет, но есть вполне разумная логика.
А в одном пакете могут быть вообще-то почти любые DML и DDL предложения.
Сортировка по типу (update, insert, delete) и по целевой таблице. Что тут сложного?
А зачем?
В нашем случае - для спортивного интереса. Попадётся мне задача со вставкой большого количества записей - попробую. Потому что так будет ликвидировано сомнение.
Я вот только не пойму, зачем вам в data science нужен ORM? Стоило из-за него вообще что-то начинать, когда он принципиально для другой области?
Плюс миллиард даже вам будет нужен редко, потому что нормальная практика давно уже предполагает агрегирование промежуточных данных, а это уже даже не миллионы, а уже где-то тысячи, ну пусть десятки тысяч. Без агрегирования же вы сначала новую модель придумать должны, и только потом чего-то там ей скормить. То есть опять нечасто.
Не похоже. По одной вижу.
Есть принципиальная возможность, поддерживаемая на уровне языка БД, поэтому я и говорил про оптимизацию на стороне БД. Она тривиальная, вы даже сами о ней знаете, но почему-то предпочитаете возражать. Поступление хоть миллиона инсертов в одну таблицу очень (очень!) легко выявить и обработать.
Вообще, конечно нужен чистый эксперимент. Я чистого не делал, но обычно мои запросы (через ORM) были достаточно производительными для задачи и потому не было нужды дальше оптимизировать. Но если вы принципиально не согласны, то что мешает написать простейший кусок кода в цикле создающий тысячу объектов, а потом скормить эти объекты например hibernate? Для уверенности добавьте внешний цикл шагов на 100, пусть среднее время покажет. Да даже без ORM ведь тривиально - написать инсерт и в цикле его с батчем прогнать, а потом без батча. Тогда будет обоснованное мнение.
средствами SQL обрабатывать миллионы записей - не проблема. А средствами ORM?
Средства ORM служат для ускорения написания кода, а не для ускорения выполнения программы. Но в среднем на стандартных задачах ORM не сильно отстаёт от чистого SQL. На специфических же, разумеется, универсальный инструмент хуже, чем специализированный, тоже давно известная истина.
В плане "обычно" как раз есть много очень простых запросов. Ваш же пример с миллиардами (!!!) записей является редчайшим исключением.
Про объединение в пакете - каждый dml уже содержит требуемые от нас сотни записей, поэтому со стороны бд нет никаких проблем его исполнить с одной записью на диск. В оракле есть insert all, в mysql есть возможность напрямую указывать множественные значения, это всё к тому, что разработчики СУБД уже подумали о таком варианте использования и сделали необходимые синтаксические конструкции, а значит они просто обязаны были подумать и о собственно исполнении этих конструкций. Поэтому два dml по 1000 записей дадут нам две записи на диск (во время транзакции, а во время коммита может ещё много чего писаться, здесь я не спец).
Про "удел ORM" согласен. Но в тексте статьи речь шла о сотнях записей, так что всё опять уместно. Хотя в батчах и тысячи легко пойдут.
По разделению труда между базистами и программистами тоже в принципе согласен, но одно дело, когда на каждого программиста нужно по базисту нанимать, и совсем другое, когда большую часть оптимизаций программисты делают сами, что избавляет нас от раздувания (дорогих) штатов. Так что здесь опять нужно просто внимательно смотреть на проблему - есть экономия или нет. Может ваши миллиарды записей действительно требуют спеца по имеющейся в конторе СУБД ради реально нужных и сложных оптимизаций, но в большинстве случаев привлекать дополнительного базиста нет необходимости просто из-за достаточной грамотности обычных программистов. А вот если там набрали молодёжь и они пишут что-то более или менее сложное без проверки старшими товарищами, то да, быстро возникнет потребность всё это оптимизировать.
Две таблицы отображаются на два набора объектов, для каждого набора отдельно генерируется dml, затем два dml в режиме batch идут в БД. Всё прекрасно ускоряется.
Параллельная обработка примерно так же - ничего страшного там нет, пройтись по списку объектов очень легко. Возможно, вы имели в виде работу нескольких клиентов, но их запросы ни в коем случае нельзя объединять в один, так что с этой стороны опять всё обстоит так, как должно.
Большинство мифов про страшный ORM базируется на непонимании как внутренней механики сабжа, так и на непонимании цели, ради которой вообще что-то пишут в БД, Если же понимание есть, то всё отлично оптимизируется. В крайнем случае, если реально упёрлись в недостатки ORM, то грамотный разработчик легко напишет оптимизированный SQL. Но до ограничений ORM чаще всего далеко. Главное ограничение - молодые разработчики.
Во первых, батч выглядит по другому, примерно так:
Вместо insert into xxx values (1,2,3) будет insert into xxx values (1,2,3), (4,5,6), (7,8,9), ...
То есть БД получит всё необходимое для любых оптимизаций.
Соответственно, во вторых, вместо сотни отдельных актов записи в журнал транзакций будем иметь один акт, включающий все данные. А раз запись на диск одна, то и время сокращается очень существенно, примерно как вы бы и могли ожидать, но почему-то сочли невозможным.
Хотя стоит признать, что умение оптимизировать батчи свойственно не всем СУБД.
СУБД для производительности рекомендуют использовать один крупный dml опрератор insert update delete вместо 10 мелких. Но реализация современных orm нацелена на создание 10 мелких dml вместо одного крупного
Вы сами выше писали про JDBC batch, но потом как-то невнятно от него отказались. А между тем, он как раз и компонует несколько мелких запросов в один большой. Так что с этой стороны в нормальных ORM всё хорошо.
Поверхностный анализ. Хоть и претендует на использование марксизма.
Наличие эксплуатации в мире, где высшей ценностью являются деньги, есть абсолютно неизбежное (и довольно очевидное) следствие. Зачем отмечать наличие этого следствия в случае с фейсбуком? Те, кому тема интересна, и так всё понимают. А кому неинтересна скажут, что здесь пишут какую-то ерунду (потому что она неинтересная). Так зачем?
Ну и про марксизм. Если уровень анализа в данной статье считать достигнутым на сегодня уровнем полезности марксизма, как средства анализа, то из этого следует неутешительный вывод - марксизм не способен на большее, нежели примитивное повторение одного и того же тезиса про эксплуатацию. Есть ли от этого польза?
Куда можно расти. Анализ должен как обобщать, так и находить новое в ранее не до глубин рассмотренных явлениях. Пример обобщения - массовая ситуация с использованием чужих персональных данных устраивает большинство, значит в этом есть закономерность, выражаемая в готовности большинства жертвовать частью себя ради удовольствий, получаемых за отданную жертву. И от такого вывода уже можно развивать теорию. Но марксисты пока ничего подобного не демонстрируют.
Очень хороший пример так называемого отрицания отрицания. Автор пытается превратить свой комментарий к чужой статье в очередную статью, но с явно противоположной направленностью по отношению к первоисточнику. Целью своего комментария автор ставит рассказ "про технический уровень статей". Но вместо восхождения на недосягаемый для профанов уровень, автор занялся эмоциональным указанием на набор мелких некорректностей, допущенных предыдущим автором. Но давайте посмотрим шире - зачем указывать на некорректность детского лепета? Ребёнок по определению знает намного меньше взрослых. Можно, конечно, пытаться разбирать детский лепет по частям и выделять в нём отдельные нескладные для взрослого уха места, но что это даёт всем остальным взрослым? Упражнение по тренировке терпения, разве что.
Развитие движется в цикле от одного взлёта к следующему, базирующемуся на предыдущем. Автор попытался указать на недостатки первого цикла, но при этом сам оказался настолько же далёк от заявленного пожелания про хороший уровень статей, как любой ребёнок бывает далёк от взрослых. Для ребёнка такие рассуждения были бы уместны - так он развивается, отрицая свои собственные глупые мысли, не нашедшие подтверждения в действительности. Но зачем так делает вроде бы взрослый автор? Зачем он опускает уровень статей ниже абсолютного нуля? Скатывается к вопросам вроде "Кто – «мы» ?" в ответ на текст "Мы поговорили об этом с Максимом Горшнениным". Очевидно же, что интервьюер разговаривает с интервьюируемым, значит их минимум двое, значит это множественное число, значит нужно использовать вариант местоимения "мы", а не "я" или "они". Зачем вот так с первых строк статьи демонстрировать падение уровня текстов? Ну и главная претензия - "но ведь кто-то же поставил 57 лайков свежей статье". О да, кто-то их поставил. Но посмотрим, сколько лайков заслужила статья-критика. И мы увидим, что на момент создания данного комментария там уже было более 80-ти(!!!) лайков. За что? Исключительно за выражения авторского "фи" в адрес неудачливого представителя пресс-службы одной из IT-контор. Так как же не пробивать дно в плане технического уровня, когда аудитория демонстрирует любовь исключительно к обсасыванию грязных подробностей из текстов, написанных на самом детском уровне?
Спасибо за ответ с примером. Да, если есть цель задействовать функциональный стиль, тогда предложенные дополнения станут полезными. Правда непонятно, как могла бы выглядеть альтернатива в том же функциональном стиле, но спроектированная по другому. Возможно она была бы проще, хотя это, разумеется, лишь предположение.
С другой стороны, если не стремиться везде писать в функциональном стиле, ваш пример очень коротко мог бы быть записан в привычном императивном стиле, правда с передачей обработчиков при вызове метода, что кто-то может назвать продолжением функционального стиля. Но это все выглядит очень компактно и в реальности передаётся даже не ссылка на функцию, а полноценный объект со всеми свойственными ООП характеристиками. Компактность достигается за счёт стандартного синтаксиса типа this::myMethodName. Суммарное количество строк при такой реализации было бы, скорее всего, немного побольше, чем в приведённом вами примере, но разница состояла бы из одной фигурной скобки на строку, или из пустых строк между методами, что не напрягает психологически, но наоборот, вносит важные разделители, визуально отделяющие соответствующие части логики.
Собственно по вашему примеру - там всего два места ветвления потоков, поэтому вызовов с передачей this::myMethodName будет всего два, что очевидно совсем не захламляет код. Остальное будет очень близко к вами предложенному варианту.
В целом мы обсуждаем очередной вопрос стиля. Если цель состоит именно в обязательности функционального стиля, тогда вероятно вам нужен реактор, но если не нагружать разработчиков обязательностью исключительно стилистических формальностей, то реактор получается не нужным. Хотя я понимаю, что нередко желание писать именно в том стиле, который нравится, намного важнее для большинства разработчиков, нежели вопрос о включении в проект той или иной библиотеки. Для таких случаев, видимо, и должен существовать реактор.
Пока вот такие глупые вопросы будут сидеть в головах у обывателей, никаких достижений веб-3 не покажет. Жрать много и по возможности бесплатно - это тот самый крючок, на который всех поймали в веб-2.0. Жадность вас губит, драгоценные вы наши обыватели. И этим, разумеется, активно пользуются. Да и как не пользоваться, если вместо реальных проблем вроде повсеместного и крайне масштабного сбора персональной информации о каждом, народ занят одним желанием - разбогатеть. Хоть на чём. Лишь бы разбогатеть. На токенах можно? Значит будем богатеть на токенах!
Веб-3.0 нужны понимающие проблему пользователи. А желающим разбогатеть нужен веб-2.0. Когда же веб-3 всё же худо-бедно заживёт, туда безусловно бросятся толпы желающих разбогатеть. Ну и он опять превратится в то, от чего сегодня все стонут. Подчеркну - стонут, но продолжают с упорством жрать этот кактус.
Да. В каждой истории нужно подчеркнуть ту лёгкость разработки, которую вы обещаете. Видимо истории делятся на две группы - по IDE с указанием упрощений в сравнении с другими IDE, и по "мета-фрейморку" (как вы его называете), с указанием, что конкретно он делает за разработчика и что конкретно остаётся делать разработчику.
И есть сомнение, состоящее в том, что вы собрались конкурировать с другими разработчиками IDE, которые пилят свои проекты уже десятки лет и накопили очень большой багаж знаний. Плюс команды разработки у них на пару порядков больше вашей. Даже не знаю, как в таких условиях можно выжить.
Начинать нужно с понимания, которого вы не продемонстрировали. Вы отметили в списке жадность, но до конца пойти отказались, перейдя на проблемы третьестепенной важности, порождаемые корневой причиной. То есть даже люди, считающие себя разбирающимися в хитросплетениях общества, намеренно уходят от правильных ответов, отражающих корень проблемы. Так происходит из-за желания и рыбку съесть и на кое-что не сесть. Люди старательно избегают указаний на те причины, которые их самих заставляют делать лично им выгодные вещи, но наносящие вред другим. Получается, что человек вроде против насилия над собой, но поскольку от насилия над другими получает ту или иную прибыль, он не может сказать прямо о базовой причине, ведь это равносильно признанию, что и сам он такой же, а раз так, то какие могут быть претензии к аналогично действующим индивидам?
Корень зла - желание паразитировать. Оно проявляется во многих формах. Одна из форм - морковка перед носом в виде "я стану богатым". Есть и менее модные формы, которые выглядят как обычный обман, но прикрываются иногда ещё несколькими слоями обмана или самообмана, дабы не признаваться самому себе в собственной беспринципности и циничности. Хотя есть и такие, кто давно признал сделку с дьяволом и уже просто не обращает внимания на какие-то признания - он всё и так отлично о себе знает, просто вырезает сердце у тех, кто не может дать сдачи, потому что, видите ли, ему хочется кушать.
Поэтому первый шаг, который ещё не потерянный для общества человек обязан сделать, это признание самому себе в наличии проблемы внутри самого себя. Ну а далее всё пойдёт гораздо легче, особенно если человеку противна причина, заставляющего и его самого быть подобным тем, кто его нагибает. Хотя прелесть вырезания сердец у не способных к сопротивлению может взять верх. Но вдруг вы ещё не так глубоко пали...
Начали с голубей, а чем закончат? И понятно, исследования обоснуют исключительно заботой о парализованных и прочими радостями. А потом у любого маньяка во власти будет отличный инструмент для отправки необходимости что-то обосновывать в корзину.
Что-то вы путаете. Правильная классификация такая - есть OLTP, то есть небольшие количественно изменения, и есть пакетные операции, к которым все ваши проводки раз в день и относятся. OLTP из-за небольшого количества изменений вполне красиво ложится на ORM. Массовое же изменение, естественно, логичнее делать более специализированными средствами. Но поскольку вы сами говорили, что массово проводки сохраняются один раз в день, то простым смещением этого счастливого момента на ночь вы решите все проблемы вашего магазина, и при этом возможная неэффективность используемого вами ORM на больших объёмах никого не заденет.
Но это общие принципы. Конкретика будет когда вы проведёте тесты на своей конфигурации со свойственной именно вам нагрузкой.
Прогресс в оптимизаторах.
Анализ (чаще всего не семантический) производится всегда. Вопрос лишь в его полноте. Полноту постепенно подтягивают, добавляя те или иные дополнительные варианты. Если вариант достаточно общий, то внезапно становится простым то, что раньше казалось сложным (затратным по времени). На а, например, граф изменений, который вы задали в своём примере, как раз и укладывается в общий подход по работе с такими графами. Вся сложность там - количественная. Нужно сказать оптимизатору, когда и где меняются переменные. Если для вас непривычно под переменными понимать значения в таблицах, то это не значит, что кто-то другой уже давно не использует именно такой подход. И подход этот достаточно дёшев по сравнению с вашими ожиданиями. Скорее всего дешевле даже одной записи на диск, а потому вполне применим.
Тысячу ORM пилят десятки тысяч разработчиков. Пяток-другой оптимизаторов в известных БД пилят хорошо если десятка два разработчиков. Десятки тысяч намного больше пары десятков.
Оптимизация распределённых вычислений на порядки сложнее, ибо вносятся вероятностные задержки и неопределённое поведение. Поэтому не надо про "всё делать на клиенте". Он не справится.
Я объяснял - это усложнение практически не нужно, поскольку БД справляется. В том небольшом количестве случаев, когда БД не справится - напишем чистый SQL или вообще хранимку.
Оптимизация всегда производится прозрачно для использующей её стороны. Если же оптимизатор меняет результат алгоритма, ожидаемый разработчиком (а только тогда код перестанет работать), то это означает ошибку в коде оптимизатора. То есть с нормальным оптимизатором всё будет работать.
Стоимостной анализ придумали сотни лет назад. Автоматизировали десятки лет назад.
То же самое можно сказать про SQL - профита никакого, кроме кривых рук, ленящихся писать специфические для каждой БД запросы сразу в машинных кодах.
Вообще, я не понимаю, зачем вы упорствуете и встаёте на пути прогресса? Оптимизаторы есть. Они развиваются. Если вам в их применении кажется что-то сложным, это совсем не значит, что от оптимизаторов нужно отказаться. Ну а конкретно в случае с ORM ваша собственная ссылка выше показывает, что существенной разница между универсальным множественным инсертом и специализированным для конкретной субд очень мала, соответственно, упрощение работы по созданию ORM вполне приемлемо, поскольку БД умеет оптимизировать неидеальное поведение ORM.
Хотя да, если бы все вещи на свете были бы идеальными, то я был бы только рад. Но мир так устроен, что эффективнее оптимизировать на стороне нескольких известных БД, нежели в сотнях (а то и тысячах) ORM.
Когда-нибудь ORM подтянется, но сейчас это просто неактуально. Возражения же скорее показывают нам этакое старческое брюзжание (независящее от возраста), вечное недовольство тем "какая молодёжь нынче пошла", а затем следует ожидать чего-то вроде "вот в наши-то годы...". Примите мир таким, какой он есть. Или улучшите сами. Не получается? Тогда почему вы вините других, а себе разрешаете быть неидеальным? И не оправдывайтесь другой сферой интересов, потому что в итоге все мы - население одного маленького шарика, и если кто-то на шарике отлынивает, находя очень веские оправдания, то почему то же самое не может сделать другой?
Да, такой вариант оптимизатор большинства БД наверняка сочтёт неоптимизируемым и БД выполнит его строго последовательно, по одной записи на каждый инсерт. Но это не значит, что все запросы имеют подобный характер. Я же писал про 99%. Да, вы можете придумать запрос из группы 0.1%, но что это доказывает?
Но, с другой стороны, даже ваш запрос некоторые оптимизаторы могут улучшить. Разработка оптимизаторов такого уровня, разумеется, не для массовых СУБД, а в массовых, возможно, оптимизатор сумеет объединить в один инсерт каждую пару для t2. Принципиально там применим вполне стандартный алгоритм, особенно если оптимизатор знает, что в пределах одной транзакции временную таблицу никто не видит. Ну а дублирующийся селект например даже mysql вообще легко оптимизирует просто запоминая результат, я уж не говорю про оракла или ms sql.
Здесь ответ на те сложности, которые могут показаться неустранимыми, но на самом деле очень просты.
Трассировку не покажу, потому что нужно тратить приличное время. Если нет сложных (для автоматического разбора) триггеров, то трассировка и не нужна - БД сумеет оптимизировать. Примеров в сети много, правда скорее всего не всем вашим критериям они смогут удовлетворить. Но если вам это важно - ничто не мешает провести собственное расследование с важным для вас набором критериев. Принципиально смешанная последовательность, при соблюдении простых условий (присутствующих в 99,9% случаев), ничем не отличается от однородной.
Не знаю, насчёт была она там или нет, но знаю, что оракл в 12-й версии её не поддерживал, так что ваши пожелания отправляйте им - они виновники.
Всё это актуально и для bulk insert, а потому давно решено. Ссылки ищут одним и тем же алгоритмом, независимо от количества ссылок. Триггеры чаще всего отсутствуют, а если присутствуют - простые. Только в каких-то там тысячных долях случаев триггеры есть и сложные, тогда БД всё делает последовательно и без оптимизации, но в 999 из 1000 случаев этого не бывает. Sequence так же без разницы, какой диапазон отдать, это одна операция и никак более ни на что серьёзное не влияет.
Здесь проверка только на стороне сервера. Есть ещё клиент с его батчами. Сервер, как показывает тест, легко справляется с тривиальной оптимизацией. И даже bulk insert не сильно улучшает ситуацию в сравнении с множественным инсертом, там возможно на парсинг время уходит. Остальное осталось за кадром - кто и как реально оптимизирует. Скорее всего, серверу вообще не нужна информация от клиента о наличии батча, поскольку очевидно, что её сервер может собрать сам, тогда вообще весь разговор про "неправильный ORM" окажется полностью некорректным. И это наиболее вероятный вариант, хотя в тесте он не отражён явно, поэтому не 100% уверенности.
И да, перец из статьи по ссылке забыл нам рассказать, какую СУБД он использовал. Или у шарпистов по умолчанию всегда ms sql?
Раз в день этот объём, даже неоптимальным образом исполненный, будет вполне по силам любой СУБД.
Выше отвечал - если реализация batch не от группы идиотов, то никаких проблем не будет.
findById как раз по списку и ищет. saveAll вы можете руками допилить, на то он и враппер. Но повторюсь - маленькие dml наверняка агрегируются, потому что ms sql всё же довольно старая СУБД и было бы удивительно, если они такую тривиальную оптимизацию до сих пор не сделали.
Не знаю про 1С, возможно дело в кривом драйвере, отправляющем на сервер запросы без batch-a.
Идеология ORM везде одна. Вопрос только к конкретной реализации. Со стороны БД наверняка возможность есть, а что там одноэсовцы намутили со своей стороны - ну кто-ж этих умников знает? Хотя вы можете провести предложенное выше простой тестирование и сравнить. Правда не удивлюсь, если в 1С забыли вообще выставить наружу возможность включить batch.
Здесь стандартная проблема наибольшего общего деноминатора. ORM должен работать с максимальным количеством БД, поэтому деноминатор в виде относительно древнего стандарта SQL неизбежен. Но с другой стороны batch предназначен именно для ускорения, не смотря на то, что принимает он всё подряд в любой последовательности. То есть ORM базируется на идее эффективного выполнения batch. А уж как конкретно написан этот батч, зависит от реализации библиотек языка, где батч задействован. Но было бы просто глупо сделать в языке батч и не выделять в нём инсерты в одну и ту же таблицу. Зачем тогда вообще он нужен? Вот поэтому выбранный в ORM подход правильный - может кто-то сдуру и сделает дебильный батч, но в среднем по больнице он всё же будет более или менее оптимальный. Так что идиотизма там нет, но есть вполне разумная логика.
Сортировка по типу (update, insert, delete) и по целевой таблице. Что тут сложного?
В нашем случае - для спортивного интереса. Попадётся мне задача со вставкой большого количества записей - попробую. Потому что так будет ликвидировано сомнение.
Я вот только не пойму, зачем вам в data science нужен ORM? Стоило из-за него вообще что-то начинать, когда он принципиально для другой области?
Плюс миллиард даже вам будет нужен редко, потому что нормальная практика давно уже предполагает агрегирование промежуточных данных, а это уже даже не миллионы, а уже где-то тысячи, ну пусть десятки тысяч. Без агрегирования же вы сначала новую модель придумать должны, и только потом чего-то там ей скормить. То есть опять нечасто.
Есть принципиальная возможность, поддерживаемая на уровне языка БД, поэтому я и говорил про оптимизацию на стороне БД. Она тривиальная, вы даже сами о ней знаете, но почему-то предпочитаете возражать. Поступление хоть миллиона инсертов в одну таблицу очень (очень!) легко выявить и обработать.
Вообще, конечно нужен чистый эксперимент. Я чистого не делал, но обычно мои запросы (через ORM) были достаточно производительными для задачи и потому не было нужды дальше оптимизировать. Но если вы принципиально не согласны, то что мешает написать простейший кусок кода в цикле создающий тысячу объектов, а потом скормить эти объекты например hibernate? Для уверенности добавьте внешний цикл шагов на 100, пусть среднее время покажет. Да даже без ORM ведь тривиально - написать инсерт и в цикле его с батчем прогнать, а потом без батча. Тогда будет обоснованное мнение.
Средства ORM служат для ускорения написания кода, а не для ускорения выполнения программы. Но в среднем на стандартных задачах ORM не сильно отстаёт от чистого SQL. На специфических же, разумеется, универсальный инструмент хуже, чем специализированный, тоже давно известная истина.
В плане "обычно" как раз есть много очень простых запросов. Ваш же пример с миллиардами (!!!) записей является редчайшим исключением.
Про объединение в пакете - каждый dml уже содержит требуемые от нас сотни записей, поэтому со стороны бд нет никаких проблем его исполнить с одной записью на диск. В оракле есть insert all, в mysql есть возможность напрямую указывать множественные значения, это всё к тому, что разработчики СУБД уже подумали о таком варианте использования и сделали необходимые синтаксические конструкции, а значит они просто обязаны были подумать и о собственно исполнении этих конструкций. Поэтому два dml по 1000 записей дадут нам две записи на диск (во время транзакции, а во время коммита может ещё много чего писаться, здесь я не спец).
Про "удел ORM" согласен. Но в тексте статьи речь шла о сотнях записей, так что всё опять уместно. Хотя в батчах и тысячи легко пойдут.
По разделению труда между базистами и программистами тоже в принципе согласен, но одно дело, когда на каждого программиста нужно по базисту нанимать, и совсем другое, когда большую часть оптимизаций программисты делают сами, что избавляет нас от раздувания (дорогих) штатов. Так что здесь опять нужно просто внимательно смотреть на проблему - есть экономия или нет. Может ваши миллиарды записей действительно требуют спеца по имеющейся в конторе СУБД ради реально нужных и сложных оптимизаций, но в большинстве случаев привлекать дополнительного базиста нет необходимости просто из-за достаточной грамотности обычных программистов. А вот если там набрали молодёжь и они пишут что-то более или менее сложное без проверки старшими товарищами, то да, быстро возникнет потребность всё это оптимизировать.
Две таблицы отображаются на два набора объектов, для каждого набора отдельно генерируется dml, затем два dml в режиме batch идут в БД. Всё прекрасно ускоряется.
Параллельная обработка примерно так же - ничего страшного там нет, пройтись по списку объектов очень легко. Возможно, вы имели в виде работу нескольких клиентов, но их запросы ни в коем случае нельзя объединять в один, так что с этой стороны опять всё обстоит так, как должно.
Большинство мифов про страшный ORM базируется на непонимании как внутренней механики сабжа, так и на непонимании цели, ради которой вообще что-то пишут в БД, Если же понимание есть, то всё отлично оптимизируется. В крайнем случае, если реально упёрлись в недостатки ORM, то грамотный разработчик легко напишет оптимизированный SQL. Но до ограничений ORM чаще всего далеко. Главное ограничение - молодые разработчики.
Во первых, батч выглядит по другому, примерно так:
Вместо insert into xxx values (1,2,3) будет insert into xxx values (1,2,3), (4,5,6), (7,8,9), ...
То есть БД получит всё необходимое для любых оптимизаций.
Соответственно, во вторых, вместо сотни отдельных актов записи в журнал транзакций будем иметь один акт, включающий все данные. А раз запись на диск одна, то и время сокращается очень существенно, примерно как вы бы и могли ожидать, но почему-то сочли невозможным.
Хотя стоит признать, что умение оптимизировать батчи свойственно не всем СУБД.
Вы сами выше писали про JDBC batch, но потом как-то невнятно от него отказались. А между тем, он как раз и компонует несколько мелких запросов в один большой. Так что с этой стороны в нормальных ORM всё хорошо.
Поверхностный анализ. Хоть и претендует на использование марксизма.
Наличие эксплуатации в мире, где высшей ценностью являются деньги, есть абсолютно неизбежное (и довольно очевидное) следствие. Зачем отмечать наличие этого следствия в случае с фейсбуком? Те, кому тема интересна, и так всё понимают. А кому неинтересна скажут, что здесь пишут какую-то ерунду (потому что она неинтересная). Так зачем?
Ну и про марксизм. Если уровень анализа в данной статье считать достигнутым на сегодня уровнем полезности марксизма, как средства анализа, то из этого следует неутешительный вывод - марксизм не способен на большее, нежели примитивное повторение одного и того же тезиса про эксплуатацию. Есть ли от этого польза?
Куда можно расти. Анализ должен как обобщать, так и находить новое в ранее не до глубин рассмотренных явлениях. Пример обобщения - массовая ситуация с использованием чужих персональных данных устраивает большинство, значит в этом есть закономерность, выражаемая в готовности большинства жертвовать частью себя ради удовольствий, получаемых за отданную жертву. И от такого вывода уже можно развивать теорию. Но марксисты пока ничего подобного не демонстрируют.
Очень хороший пример так называемого отрицания отрицания. Автор пытается превратить свой комментарий к чужой статье в очередную статью, но с явно противоположной направленностью по отношению к первоисточнику. Целью своего комментария автор ставит рассказ "про технический уровень статей". Но вместо восхождения на недосягаемый для профанов уровень, автор занялся эмоциональным указанием на набор мелких некорректностей, допущенных предыдущим автором. Но давайте посмотрим шире - зачем указывать на некорректность детского лепета? Ребёнок по определению знает намного меньше взрослых. Можно, конечно, пытаться разбирать детский лепет по частям и выделять в нём отдельные нескладные для взрослого уха места, но что это даёт всем остальным взрослым? Упражнение по тренировке терпения, разве что.
Развитие движется в цикле от одного взлёта к следующему, базирующемуся на предыдущем. Автор попытался указать на недостатки первого цикла, но при этом сам оказался настолько же далёк от заявленного пожелания про хороший уровень статей, как любой ребёнок бывает далёк от взрослых. Для ребёнка такие рассуждения были бы уместны - так он развивается, отрицая свои собственные глупые мысли, не нашедшие подтверждения в действительности. Но зачем так делает вроде бы взрослый автор? Зачем он опускает уровень статей ниже абсолютного нуля? Скатывается к вопросам вроде "Кто – «мы» ?" в ответ на текст "Мы поговорили об этом с Максимом Горшнениным". Очевидно же, что интервьюер разговаривает с интервьюируемым, значит их минимум двое, значит это множественное число, значит нужно использовать вариант местоимения "мы", а не "я" или "они". Зачем вот так с первых строк статьи демонстрировать падение уровня текстов?
Ну и главная претензия - "но ведь кто-то же поставил 57 лайков свежей статье". О да, кто-то их поставил. Но посмотрим, сколько лайков заслужила статья-критика. И мы увидим, что на момент создания данного комментария там уже было более 80-ти(!!!) лайков. За что? Исключительно за выражения авторского "фи" в адрес неудачливого представителя пресс-службы одной из IT-контор. Так как же не пробивать дно в плане технического уровня, когда аудитория демонстрирует любовь исключительно к обсасыванию грязных подробностей из текстов, написанных на самом детском уровне?
Стыдитесь, граждане хабровчане!
Спасибо за ответ с примером. Да, если есть цель задействовать функциональный стиль, тогда предложенные дополнения станут полезными. Правда непонятно, как могла бы выглядеть альтернатива в том же функциональном стиле, но спроектированная по другому. Возможно она была бы проще, хотя это, разумеется, лишь предположение.
С другой стороны, если не стремиться везде писать в функциональном стиле, ваш пример очень коротко мог бы быть записан в привычном императивном стиле, правда с передачей обработчиков при вызове метода, что кто-то может назвать продолжением функционального стиля. Но это все выглядит очень компактно и в реальности передаётся даже не ссылка на функцию, а полноценный объект со всеми свойственными ООП характеристиками. Компактность достигается за счёт стандартного синтаксиса типа this::myMethodName. Суммарное количество строк при такой реализации было бы, скорее всего, немного побольше, чем в приведённом вами примере, но разница состояла бы из одной фигурной скобки на строку, или из пустых строк между методами, что не напрягает психологически, но наоборот, вносит важные разделители, визуально отделяющие соответствующие части логики.
Собственно по вашему примеру - там всего два места ветвления потоков, поэтому вызовов с передачей this::myMethodName будет всего два, что очевидно совсем не захламляет код. Остальное будет очень близко к вами предложенному варианту.
В целом мы обсуждаем очередной вопрос стиля. Если цель состоит именно в обязательности функционального стиля, тогда вероятно вам нужен реактор, но если не нагружать разработчиков обязательностью исключительно стилистических формальностей, то реактор получается не нужным. Хотя я понимаю, что нередко желание писать именно в том стиле, который нравится, намного важнее для большинства разработчиков, нежели вопрос о включении в проект той или иной библиотеки. Для таких случаев, видимо, и должен существовать реактор.
Пока вот такие глупые вопросы будут сидеть в головах у обывателей, никаких достижений веб-3 не покажет. Жрать много и по возможности бесплатно - это тот самый крючок, на который всех поймали в веб-2.0. Жадность вас губит, драгоценные вы наши обыватели. И этим, разумеется, активно пользуются. Да и как не пользоваться, если вместо реальных проблем вроде повсеместного и крайне масштабного сбора персональной информации о каждом, народ занят одним желанием - разбогатеть. Хоть на чём. Лишь бы разбогатеть. На токенах можно? Значит будем богатеть на токенах!
Веб-3.0 нужны понимающие проблему пользователи. А желающим разбогатеть нужен веб-2.0. Когда же веб-3 всё же худо-бедно заживёт, туда безусловно бросятся толпы желающих разбогатеть. Ну и он опять превратится в то, от чего сегодня все стонут. Подчеркну - стонут, но продолжают с упорством жрать этот кактус.
Да. В каждой истории нужно подчеркнуть ту лёгкость разработки, которую вы обещаете. Видимо истории делятся на две группы - по IDE с указанием упрощений в сравнении с другими IDE, и по "мета-фрейморку" (как вы его называете), с указанием, что конкретно он делает за разработчика и что конкретно остаётся делать разработчику.
И есть сомнение, состоящее в том, что вы собрались конкурировать с другими разработчиками IDE, которые пилят свои проекты уже десятки лет и накопили очень большой багаж знаний. Плюс команды разработки у них на пару порядков больше вашей. Даже не знаю, как в таких условиях можно выжить.
Начинать нужно с понимания, которого вы не продемонстрировали. Вы отметили в списке жадность, но до конца пойти отказались, перейдя на проблемы третьестепенной важности, порождаемые корневой причиной. То есть даже люди, считающие себя разбирающимися в хитросплетениях общества, намеренно уходят от правильных ответов, отражающих корень проблемы. Так происходит из-за желания и рыбку съесть и на кое-что не сесть. Люди старательно избегают указаний на те причины, которые их самих заставляют делать лично им выгодные вещи, но наносящие вред другим. Получается, что человек вроде против насилия над собой, но поскольку от насилия над другими получает ту или иную прибыль, он не может сказать прямо о базовой причине, ведь это равносильно признанию, что и сам он такой же, а раз так, то какие могут быть претензии к аналогично действующим индивидам?
Корень зла - желание паразитировать. Оно проявляется во многих формах. Одна из форм - морковка перед носом в виде "я стану богатым". Есть и менее модные формы, которые выглядят как обычный обман, но прикрываются иногда ещё несколькими слоями обмана или самообмана, дабы не признаваться самому себе в собственной беспринципности и циничности. Хотя есть и такие, кто давно признал сделку с дьяволом и уже просто не обращает внимания на какие-то признания - он всё и так отлично о себе знает, просто вырезает сердце у тех, кто не может дать сдачи, потому что, видите ли, ему хочется кушать.
Поэтому первый шаг, который ещё не потерянный для общества человек обязан сделать, это признание самому себе в наличии проблемы внутри самого себя. Ну а далее всё пойдёт гораздо легче, особенно если человеку противна причина, заставляющего и его самого быть подобным тем, кто его нагибает. Хотя прелесть вырезания сердец у не способных к сопротивлению может взять верх. Но вдруг вы ещё не так глубоко пали...
Начали с голубей, а чем закончат? И понятно, исследования обоснуют исключительно заботой о парализованных и прочими радостями. А потом у любого маньяка во власти будет отличный инструмент для отправки необходимости что-то обосновывать в корзину.