Сообщение Re[59]: В России опять напишут новый объектно-ориентированны от 13.06.2018 11:48
Изменено 13.06.2018 11:50 vdimas
Re[59]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Это так называлась библиотека ORM? ))
S>Не "библиотека ORM", а просто ORM. Object-relational mapper.
Но мы обсуждали либы/фреймворки.
S>Там была адская смесь метаданных в коде приложения, метаданных в таблицах в базе, и метаданных в виде собственно объектной модели.
V>>Что, прям абстрактная от конкретных ваших прикладных типов и прямо на Дельфях?
S>Ядро — было абстрактным. На основе этого ядра писались "наши прикладные типы".
S>100% кода — на дельфях.
V>>А это вообще возможно физически? ))
S>Отож.
Ясно, невозможно.
Всё ручками.
Как и все остальные в те года.
V>>Т.е., твоё поучение должно было трансформироваться из упрёка в незнании IDENTITY в упрёк в незнании о наличии такой хрени как батчей, не?
S>А где я говорил о незнании IDENTITY? Я наглядно вижу ваше непонимание, как правильно готовить батчи для MS SQL.
О! Всё-таки батчи!
Ну т.е. ты уже увидел, что если из твоего батча убрать несколько документов, оставив один, то запрос IDENTITY всё-равно нужен.
И даже если взять предположенный тобой раундтрип на клиента, разбивая вставку master/slave на много операций, то IDENTITY после вставки в master нужен даже в этом сценарии. )) Не прошло и пяти постов, как ты сие заметил. А как дышал, как дышал...
V>>Рисовать такой батч на клиенте и отправлять на сервак в те года — я еще ДО этого высмеял такой сценарий, как совершенно нереальный для тех лет.
S>Ну вот, продолжаете тупить.
Продолжаю настаивать, а не тупить.
Потому что не кластер с ценой транзакций 0.1$ за штуку, а обычный комп, с ценой транзакций примерно 0.00001$ за штуку.
S>Вполне себе реальный сценарий. Именно так всё и работало. Ничего военного — подготовили команду, отправили на сервер.
И залипли на 3-10 секунд.
Я б уволил.
S>Вижу, для вас эта простая идея представляет непредставимую сложность.
Да какая там сложность?
Это ж то самое решение в "лоб", от которого мне всю жизнь приходилось уходить.
И не от хорошей жизни приходилось, замёть, а из-за проживания в реальном мире, а не в мире сферических коней в вакууме.
Помнится, как-то несколько лет назад я уже обращал твоё внимание, что ты за все эти годы не удовлетворил ни одного нефункционального требования в обсуждениях.
Ты даешь некий примитивизм, решение в лоб, которое даст любой студент.
А на вопросы "а как же остальные требования?" у тебя всегда одна и та же отмазка — "оно вам не нужно!", и далее ВСЕГДА следует много бла-бла-бла, объясняющее почему человеку "на самом деле" (С) не нужно то, что он спрашивает. Вот такой всегда с тобой сюрр. ))
V>>Ну вот документы каждый по нескольку сотен строк.
V>>А еще и несколько док-тов за раз.
S>Отож. Вы что, правда думаете, что отправить 50 килобайт данных по сети — это что-то невообразимое?
Я не думаю, я знаю, (бо постоянно наблюдал) что это задержки на ровном месте по состоянию на 20+ лет назад.
Поэтому, в популярных промышленных системах никто так не делал, разумеется, т.е. никто не отправлял многокилобайтные батчи на сервак.
Документ отправлялся на сервак построчно или группами строк (в асинхронном UI, которое как раз стало мегапопулярно именно во второй половине 90-х, с развитием клиент-сервера и трехзвенки).
Просто в Дельфи всего этого не было, разумеется.
Дельфи — это как обратная сторона Луны... там жили и работали инопланетяне.
Там, наверно, даже другие физические законы были. ))
V>>В твоём случае надо ожидать ответ от сервака, прежде чем продолжить редактировать в "синхронном" режиме строчки накладной, отправляя на сервак их обновлённые версии.
S>И в чём проблема? Подождать 3 секунды после нажатия на "Save"?
Это если ты один подключённый к серваку, то 3 секунды.
А так-то и десяток секунд аж бегом.
За этот же десяток секунд уже можно обслужить следующего клиента.
Кароч, от клиентского сценария ты малость далёк, я уже обращал на это твоё внимания.
Достаточно того, что ты всю дорогу делаешь акценты на сложности/важности именно серверной части.
Отнюдь, серверная часть никогда не бывает сложной от слова вообще (там есть лишь сложность поддержки, но это побочные эффекты языка SQL и отдельный разговор, почему SQL так радостно переезжает на клиента + LINQ).
В любом случае, именно информационная сложность БД-части до клиентской никогда не дотягивает.
Даже в полноценной трехзвенке, а не в примазываемом к трехзвенке HTTP-сценарии.
Клиент диктует вообще все сценарии работы с серваком, бо ради него (клиента) всё и затевалось.
V>>Ну, реально, вот прямо отсуюда дай мне ссылку, плиз, именно на мою чушь.
S>Ссылки искать среди тысяч ваших сообщений мне неинтересно. Из того, что осталось в памяти:
S>- что EC2 Амазона были обычными серверами, которые надо было заказывать за три дня, и только в 2009 их перевели на виртуализацию
Во-первых, это было не в этом обсуждении, а в другом.
Я проявил незнание того, как обстояли дела конкретно с AWS.
Зато знал, как обстояли дела с виртуализацией вообще, бо я в ней живу — в среднем несколько часов в день с 2001-го года, бо характер работ такой.
Во-вторых, я, в отличие от, признал за собой невладение некоторой информацией.
В третьих, почему я там упирался?
Если бы ты так же плотно имел дела с виртуализацией, как я все последние более 15 лет, то тебе было бы всё кристально ясно и ты бы мне мог указать на суть моих заблуждений, как я регулярно указываю тебе.
А ларчик там просто открывался — на момент 2006-2008-хх лет вменяемой виртуализации в Linux не было.
Она появилась в сыром виде в 2011-м и в более менее нормальном виде вот недавно — в 2013-м.
До этого была технология qemu, т.е. технология полной эмуляции аппаратуры.
Кто помнит самые первые версии VirtualBox, тот должен понимать, о чём речь.
Сравнивать с уже вышедшим полноценным Hyper-V сей кошмар было нельзя.
Это были разные вселенные.
На "той стороне" технологий был еще такой гипервизор Xen.
Одно но — с ним всё было не просто в те года, нужно было патчить исходники ядра Linux и кучи системных сервисов для работы с ним.
Поэтому, на Xen хорошо ложился лишь на такой сценарий, когда поставщик услуг собирает свою пропатченную сборку с самостоятельно собранным из сырцов ядром, основными сетевыми службами, веб-серваком, скриптовым языком и каким-нить MySQL. Вот такой сценарий был мега-популярен — когда тебе дают уже преднастроенную специально собранную под Xen виртуалку, в которой лишь веб-сервак+скрипт+sql+ftp/sftp и шаг вправо-влево банально недоступен.
Но это ж "не оно", верно?
Произвольный бинарный образ на "этом" не запустишь.
А на чём запустишь (на RHEL под AWS), то вдвойне "не оно".
Почему не оно?
Потому что на тот момент была совсем уж сильная зависимость генерируемого кода от опций компилятора, в которых указывалось поколение целевых процессоров.
Для сравнения, собранная Генту на начало 2000-х у меня работала минимум на 30% быстрее чем RHEL. Генту собиралась по-месту на целевой проц, а не на (упаси хосподи) на 486-й, как тогда собирался RHEL. Почему Генту и вызывала такой интересо тогда.
Но Генту и прочие сборки Линукс, включая собственные (я участвовал одно время в разработке и поддержке одной из сборок), — это всё на Xen не жило от слова никак и ни в коем случае.
А пользовать qemu — это или обман клиентов или жуткая неэффективность, тут на выбор, как сие назвать.
Однако, когда я по твоей ссылке (спасибо, кста) увидел цену "аренды" в пересчёте на одноядерный проц с 1700 MHz тактовой (при том, что у меня на столе уже стоял комп с 3.2 GHz), то всё встало на свои места.
Паззл у меня в голове сошёлся — да, таки qemu.
Какой кошмар. )))
У богатых свои причуды.
S>- что запись в shared memory вызывает какие-то дополнительные "прерывания" по сравнению с записью в обычную private память процесса
Разумеется. Каждая запись в shared memory в Windows вызывает прерывания ОС, чтобы пометить ссотв. страницы памяти как "грязные".
Потому что нет такого понятия "просто shared memory" в Windows, есть технология маппинга файлов в память.
И пометка страниц для последующей обязательной синхронизации с диском — это азы азов сей технологии.
Даже если ты не указал конкретный файл для маппинга, то cистема тебе выделит область в system paging file.
Но суть происходящего не изменится.
RTFM!
S>- что Skype for Business использует проприетарный протокол вместо стандартного SIP/RTP
Это ты указал, что используешь Skype for Business.
S>- что-то там про ресайз страниц в SQL Server
И что там? ))
Ну, т.е., в ЭТОМ обсуждении найти мою "чушь" у тебя не получилось.
Итого, голосновность, так и запишем.
V>>Потому что перечислить твою бесконечную чушь мне вовсе не сложно:
V>>- если ISAM — то речь непременно о файловой базе, индексы непременно хранятся отдельно и без транзакций;
S>о да, тут вам повезло — поймали на разнице терминологий.
Если бы ты не пытался "гнобить", я не "поймал бы", заметь.
Просто совсем уж в глаза бросались, прямо скажем, странности рассуждений в сочетании с агрессивностью.
V>>- важна только стоимость транзакций, а то, что железо при этом будет стоить дороже стоимости всего бизнеса заказчика — не важно; ))
S>Это вы, похоже, не понимаете фундаментальной природы вещей. Не бывает таких бизнесов, стоимость которых меньше их оборота. Я вам даже формулы приводил, как первокласснику. Вы продолжаете тупить, и верить в бизнесы, у которых есть потребность в миллион транзакций в минуту, но при этом зарабатывают они на этих транзакциях столько, что не могут себе позволить $50k на железо.
Тем не менее, обычный современный серверный бокс ценой до 2000 зелени справляется с сотней тыс транзакций в секунду (описанной "сложности" их по твоей ссылке).
Вот и прикинь стоимость транзакции за ~5 лет работы этого сервака.
Она выходит на несколько порядков меньше озвученных тобой цифр.
И кто тут первоклассник?
Разделить два числа уже не в состоянии.
V>>- накладные расходы при передаче в другой процесс можно игнорировать по сравнению с "тут устаревший набор представлений о дисках";
S>Ну, вы же так и не опровергли мои аргументы. В ответ — какой-то бред про "прерывания".
Опроверг, дав тебе для примера современные диски и их скорости.
V>>Кстате, не далее месяца назад я поставил себе похожий девайс от обсуждаемого:
V>>https://www.dns-shop.ru/product/855ee22dac8f3330/250-gb-ssd-m2-nakopitel-samsung-960-evo-mz-v6e250bw/
V>>Выдаёт скорости в точности как указано в спецификации.
V>>вот на этой материнке:
V>>https://ru.gecid.com/mboard/gigabyte_z370p_d3/
S>Ну, почему бы не скачать софтинку и не запустить её? Поделитесь результатами — общественность будет вам благодарна.
Дык, я сходу скачал несколько программ для теста диска и погонял их.
Скриншоты прислать?
S>Интересует random mixed read/write, очередь можете любого размера.
Ага, уже mixed read/write?
А соломки не постелить? ))
А чего же не sequential read для очереди длиной свыше сотни?
Неудобно?
Зато SQL-серваку очень удобно на 99% сценариев.
Ну и, главное замечание, что эти "голые скорости" чтения с диска в любом случае получаются уже выше, чем даже в случае расположения файлов базы на RAM-диске, т.е. узким местом современные SSD-диски уже не являются.
Узкое место — сама СУБД.
Об этом и есть всё это обсуждение, если ты не заметил до сих пор.
S>Здравствуйте, vdimas, Вы писали:
V>>Это так называлась библиотека ORM? ))
S>Не "библиотека ORM", а просто ORM. Object-relational mapper.
Но мы обсуждали либы/фреймворки.
S>Там была адская смесь метаданных в коде приложения, метаданных в таблицах в базе, и метаданных в виде собственно объектной модели.
V>>Что, прям абстрактная от конкретных ваших прикладных типов и прямо на Дельфях?
S>Ядро — было абстрактным. На основе этого ядра писались "наши прикладные типы".
S>100% кода — на дельфях.
V>>А это вообще возможно физически? ))
S>Отож.
Ясно, невозможно.
Всё ручками.
Как и все остальные в те года.
V>>Т.е., твоё поучение должно было трансформироваться из упрёка в незнании IDENTITY в упрёк в незнании о наличии такой хрени как батчей, не?
S>А где я говорил о незнании IDENTITY? Я наглядно вижу ваше непонимание, как правильно готовить батчи для MS SQL.
О! Всё-таки батчи!
Ну т.е. ты уже увидел, что если из твоего батча убрать несколько документов, оставив один, то запрос IDENTITY всё-равно нужен.
И даже если взять предположенный тобой раундтрип на клиента, разбивая вставку master/slave на много операций, то IDENTITY после вставки в master нужен даже в этом сценарии. )) Не прошло и пяти постов, как ты сие заметил. А как дышал, как дышал...
V>>Рисовать такой батч на клиенте и отправлять на сервак в те года — я еще ДО этого высмеял такой сценарий, как совершенно нереальный для тех лет.
S>Ну вот, продолжаете тупить.
Продолжаю настаивать, а не тупить.
Потому что не кластер с ценой транзакций 0.1$ за штуку, а обычный комп, с ценой транзакций примерно 0.00001$ за штуку.
S>Вполне себе реальный сценарий. Именно так всё и работало. Ничего военного — подготовили команду, отправили на сервер.
И залипли на 3-10 секунд.
Я б уволил.
S>Вижу, для вас эта простая идея представляет непредставимую сложность.
Да какая там сложность?
Это ж то самое решение в "лоб", от которого мне всю жизнь приходилось уходить.
И не от хорошей жизни приходилось, замёть, а из-за проживания в реальном мире, а не в мире сферических коней в вакууме.
Помнится, как-то несколько лет назад я уже обращал твоё внимание, что ты за все эти годы не удовлетворил ни одного нефункционального требования в обсуждениях.
Ты даешь некий примитивизм, решение в лоб, которое даст любой студент.
А на вопросы "а как же остальные требования?" у тебя всегда одна и та же отмазка — "оно вам не нужно!", и далее ВСЕГДА следует много бла-бла-бла, объясняющее почему человеку "на самом деле" (С) не нужно то, что он спрашивает. Вот такой всегда с тобой сюрр. ))
V>>Ну вот документы каждый по нескольку сотен строк.
V>>А еще и несколько док-тов за раз.
S>Отож. Вы что, правда думаете, что отправить 50 килобайт данных по сети — это что-то невообразимое?
Я не думаю, я знаю, (бо постоянно наблюдал) что это задержки на ровном месте по состоянию на 20+ лет назад.
Поэтому, в популярных промышленных системах никто так не делал, разумеется, т.е. никто не отправлял многокилобайтные батчи на сервак.
Документ отправлялся на сервак построчно или группами строк (в асинхронном UI, которое как раз стало мегапопулярно именно во второй половине 90-х, с развитием клиент-сервера и трехзвенки).
Просто в Дельфи всего этого не было, разумеется.
Дельфи — это как обратная сторона Луны... там жили и работали инопланетяне.
Там, наверно, даже другие физические законы были. ))
V>>В твоём случае надо ожидать ответ от сервака, прежде чем продолжить редактировать в "синхронном" режиме строчки накладной, отправляя на сервак их обновлённые версии.
S>И в чём проблема? Подождать 3 секунды после нажатия на "Save"?
Это если ты один подключённый к серваку, то 3 секунды.
А так-то и десяток секунд аж бегом.
За этот же десяток секунд уже можно обслужить следующего клиента.
Кароч, от клиентского сценария ты малость далёк, я уже обращал на это твоё внимания.
Достаточно того, что ты всю дорогу делаешь акценты на сложности/важности именно серверной части.
Отнюдь, серверная часть никогда не бывает сложной от слова вообще (там есть лишь сложность поддержки, но это побочные эффекты языка SQL и отдельный разговор, почему SQL так радостно переезжает на клиента + LINQ).
В любом случае, именно информационная сложность БД-части до клиентской никогда не дотягивает.
Даже в полноценной трехзвенке, а не в примазываемом к трехзвенке HTTP-сценарии.
Клиент диктует вообще все сценарии работы с серваком, бо ради него (клиента) всё и затевалось.
V>>Ну, реально, вот прямо отсуюда дай мне ссылку, плиз, именно на мою чушь.
S>Ссылки искать среди тысяч ваших сообщений мне неинтересно. Из того, что осталось в памяти:
S>- что EC2 Амазона были обычными серверами, которые надо было заказывать за три дня, и только в 2009 их перевели на виртуализацию
Во-первых, это было не в этом обсуждении, а в другом.
Я проявил незнание того, как обстояли дела конкретно с AWS.
Зато знал, как обстояли дела с виртуализацией вообще, бо я в ней живу — в среднем несколько часов в день с 2001-го года, бо характер работ такой.
Во-вторых, я, в отличие от, признал за собой невладение некоторой информацией.
В третьих, почему я там упирался?
Если бы ты так же плотно имел дела с виртуализацией, как я все последние более 15 лет, то тебе было бы всё кристально ясно и ты бы мне мог указать на суть моих заблуждений, как я регулярно указываю тебе.
А ларчик там просто открывался — на момент 2006-2008-хх лет вменяемой виртуализации в Linux не было.
Она появилась в сыром виде в 2011-м и в более менее нормальном виде вот недавно — в 2013-м.
До этого была технология qemu, т.е. технология полной эмуляции аппаратуры.
Кто помнит самые первые версии VirtualBox, тот должен понимать, о чём речь.
Сравнивать с уже вышедшим полноценным Hyper-V сей кошмар было нельзя.
Это были разные вселенные.
На "той стороне" технологий был еще такой гипервизор Xen.
Одно но — с ним всё было не просто в те года, нужно было патчить исходники ядра Linux и кучи системных сервисов для работы с ним.
Поэтому, на Xen хорошо ложился лишь на такой сценарий, когда поставщик услуг собирает свою пропатченную сборку с самостоятельно собранным из сырцов ядром, основными сетевыми службами, веб-серваком, скриптовым языком и каким-нить MySQL. Вот такой сценарий был мега-популярен — когда тебе дают уже преднастроенную специально собранную под Xen виртуалку, в которой лишь веб-сервак+скрипт+sql+ftp/sftp и шаг вправо-влево банально недоступен.
Но это ж "не оно", верно?
Произвольный бинарный образ на "этом" не запустишь.
А на чём запустишь (на RHEL под AWS), то вдвойне "не оно".
Почему не оно?
Потому что на тот момент была совсем уж сильная зависимость генерируемого кода от опций компилятора, в которых указывалось поколение целевых процессоров.
Для сравнения, собранная Генту на начало 2000-х у меня работала минимум на 30% быстрее чем RHEL. Генту собиралась по-месту на целевой проц, а не на (упаси хосподи) на 486-й, как тогда собирался RHEL. Почему Генту и вызывала такой интересо тогда.
Но Генту и прочие сборки Линукс, включая собственные (я участвовал одно время в разработке и поддержке одной из сборок), — это всё на Xen не жило от слова никак и ни в коем случае.
А пользовать qemu — это или обман клиентов или жуткая неэффективность, тут на выбор, как сие назвать.
Однако, когда я по твоей ссылке (спасибо, кста) увидел цену "аренды" в пересчёте на одноядерный проц с 1700 MHz тактовой (при том, что у меня на столе уже стоял комп с 3.2 GHz), то всё встало на свои места.
Паззл у меня в голове сошёлся — да, таки qemu.
Какой кошмар. )))
У богатых свои причуды.
S>- что запись в shared memory вызывает какие-то дополнительные "прерывания" по сравнению с записью в обычную private память процесса
Разумеется. Каждая запись в shared memory в Windows вызывает прерывания ОС, чтобы пометить ссотв. страницы памяти как "грязные".
Потому что нет такого понятия "просто shared memory" в Windows, есть технология маппинга файлов в память.
И пометка страниц для последующей обязательной синхронизации с диском — это азы азов сей технологии.
Даже если ты не указал конкретный файл для маппинга, то cистема тебе выделит область в system paging file.
Но суть происходящего не изменится.
RTFM!
S>- что Skype for Business использует проприетарный протокол вместо стандартного SIP/RTP
Это ты указал, что используешь Skype for Business.
S>- что-то там про ресайз страниц в SQL Server
И что там? ))
Ну, т.е., в ЭТОМ обсуждении найти мою "чушь" у тебя не получилось.
Итого, голосновность, так и запишем.
V>>Потому что перечислить твою бесконечную чушь мне вовсе не сложно:
V>>- если ISAM — то речь непременно о файловой базе, индексы непременно хранятся отдельно и без транзакций;
S>о да, тут вам повезло — поймали на разнице терминологий.
Если бы ты не пытался "гнобить", я не "поймал бы", заметь.
Просто совсем уж в глаза бросались, прямо скажем, странности рассуждений в сочетании с агрессивностью.
V>>- важна только стоимость транзакций, а то, что железо при этом будет стоить дороже стоимости всего бизнеса заказчика — не важно; ))
S>Это вы, похоже, не понимаете фундаментальной природы вещей. Не бывает таких бизнесов, стоимость которых меньше их оборота. Я вам даже формулы приводил, как первокласснику. Вы продолжаете тупить, и верить в бизнесы, у которых есть потребность в миллион транзакций в минуту, но при этом зарабатывают они на этих транзакциях столько, что не могут себе позволить $50k на железо.
Тем не менее, обычный современный серверный бокс ценой до 2000 зелени справляется с сотней тыс транзакций в секунду (описанной "сложности" их по твоей ссылке).
Вот и прикинь стоимость транзакции за ~5 лет работы этого сервака.
Она выходит на несколько порядков меньше озвученных тобой цифр.
И кто тут первоклассник?
Разделить два числа уже не в состоянии.
V>>- накладные расходы при передаче в другой процесс можно игнорировать по сравнению с "тут устаревший набор представлений о дисках";
S>Ну, вы же так и не опровергли мои аргументы. В ответ — какой-то бред про "прерывания".
Опроверг, дав тебе для примера современные диски и их скорости.
V>>Кстате, не далее месяца назад я поставил себе похожий девайс от обсуждаемого:
V>>https://www.dns-shop.ru/product/855ee22dac8f3330/250-gb-ssd-m2-nakopitel-samsung-960-evo-mz-v6e250bw/
V>>Выдаёт скорости в точности как указано в спецификации.
V>>вот на этой материнке:
V>>https://ru.gecid.com/mboard/gigabyte_z370p_d3/
S>Ну, почему бы не скачать софтинку и не запустить её? Поделитесь результатами — общественность будет вам благодарна.
Дык, я сходу скачал несколько программ для теста диска и погонял их.
Скриншоты прислать?
S>Интересует random mixed read/write, очередь можете любого размера.
Ага, уже mixed read/write?
А соломки не постелить? ))
А чего же не sequential read для очереди длиной свыше сотни?
Неудобно?
Зато SQL-серваку очень удобно на 99% сценариев.
Ну и, главное замечание, что эти "голые скорости" чтения с диска в любом случае получаются уже выше, чем даже в случае расположения файлов базы на RAM-диске, т.е. узким местом современные SSD-диски уже не являются.
Узкое место — сама СУБД.
Об этом и есть всё это обсуждение, если ты не заметил до сих пор.
Re[59]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Это так называлась библиотека ORM? ))
S>Не "библиотека ORM", а просто ORM. Object-relational mapper.
Но мы обсуждали либы/фреймворки.
S>Там была адская смесь метаданных в коде приложения, метаданных в таблицах в базе, и метаданных в виде собственно объектной модели.
V>>Что, прям абстрактная от конкретных ваших прикладных типов и прямо на Дельфях?
S>Ядро — было абстрактным. На основе этого ядра писались "наши прикладные типы".
S>100% кода — на дельфях.
V>>А это вообще возможно физически? ))
S>Отож.
Ясно, невозможно.
Всё ручками.
Как и все остальные в те года.
V>>Т.е., твоё поучение должно было трансформироваться из упрёка в незнании IDENTITY в упрёк в незнании о наличии такой хрени как батчей, не?
S>А где я говорил о незнании IDENTITY? Я наглядно вижу ваше непонимание, как правильно готовить батчи для MS SQL.
О! Всё-таки батчи!
Ну т.е. ты уже увидел, что если из твоего батча убрать несколько документов, оставив один, то запрос IDENTITY всё-равно нужен.
И даже если взять предположенный тобой раундтрип на клиента, разбивая вставку master/slave на много операций, то IDENTITY после вставки в master нужен даже в этом сценарии. )) Не прошло и пяти постов, как ты сие заметил. А как дышал, как дышал...
V>>Рисовать такой батч на клиенте и отправлять на сервак в те года — я еще ДО этого высмеял такой сценарий, как совершенно нереальный для тех лет.
S>Ну вот, продолжаете тупить.
Продолжаю настаивать, а не тупить.
Потому что не кластер с ценой транзакций 0.1$ за штуку, а обычный комп, с ценой транзакций примерно 0.00001$ за штуку.
S>Вполне себе реальный сценарий. Именно так всё и работало. Ничего военного — подготовили команду, отправили на сервер.
И залипли на 3-10 секунд.
Я б уволил.
S>Вижу, для вас эта простая идея представляет непредставимую сложность.
Да какая там сложность?
Это ж то самое решение в "лоб", от которого мне всю жизнь приходилось уходить.
И не от хорошей жизни приходилось, заметь, а из-за проживания в реальном мире, а не в мире сферических коней в вакууме.
Помнится, как-то несколько лет назад я уже обращал твоё внимание, что ты за все эти годы не удовлетворил ни одного нефункционального требования в обсуждениях.
Ты даешь некий примитивизм, решение в лоб, которое даст любой студент.
А на вопросы "а как же остальные требования?" у тебя всегда одна и та же отмазка — "оно вам не нужно!", и далее ВСЕГДА следует много бла-бла-бла, объясняющее почему человеку "на самом деле" (С) не нужно то, что он спрашивает. Вот такой всегда с тобой сюрр. ))
V>>Ну вот документы каждый по нескольку сотен строк.
V>>А еще и несколько док-тов за раз.
S>Отож. Вы что, правда думаете, что отправить 50 килобайт данных по сети — это что-то невообразимое?
Я не думаю, я знаю, (бо постоянно наблюдал) что это задержки на ровном месте по состоянию на 20+ лет назад.
Поэтому, в популярных промышленных системах никто так не делал, разумеется, т.е. никто не отправлял многокилобайтные батчи на сервак.
Документ отправлялся на сервак построчно или группами строк (в асинхронном UI, которое как раз стало мегапопулярно именно во второй половине 90-х, с развитием клиент-сервера и трехзвенки).
Просто в Дельфи всего этого не было, разумеется.
Дельфи — это как обратная сторона Луны... там жили и работали инопланетяне.
Там, наверно, даже другие физические законы были. ))
V>>В твоём случае надо ожидать ответ от сервака, прежде чем продолжить редактировать в "синхронном" режиме строчки накладной, отправляя на сервак их обновлённые версии.
S>И в чём проблема? Подождать 3 секунды после нажатия на "Save"?
Это если ты один подключённый к серваку, то 3 секунды.
А так-то и десяток секунд аж бегом.
За этот же десяток секунд уже можно обслужить следующего клиента.
Кароч, от клиентского сценария ты малость далёк, я уже обращал на это твоё внимания.
Достаточно того, что ты всю дорогу делаешь акценты на сложности/важности именно серверной части.
Отнюдь, серверная часть никогда не бывает сложной от слова вообще (там есть лишь сложность поддержки, но это побочные эффекты языка SQL и отдельный разговор, почему SQL так радостно переезжает на клиента + LINQ).
В любом случае, именно информационная сложность БД-части до клиентской никогда не дотягивает.
Даже в полноценной трехзвенке, а не в примазываемом к трехзвенке HTTP-сценарии.
Клиент диктует вообще все сценарии работы с серваком, бо ради него (клиента) всё и затевалось.
V>>Ну, реально, вот прямо отсуюда дай мне ссылку, плиз, именно на мою чушь.
S>Ссылки искать среди тысяч ваших сообщений мне неинтересно. Из того, что осталось в памяти:
S>- что EC2 Амазона были обычными серверами, которые надо было заказывать за три дня, и только в 2009 их перевели на виртуализацию
Во-первых, это было не в этом обсуждении, а в другом.
Я проявил незнание того, как обстояли дела конкретно с AWS.
Зато знал, как обстояли дела с виртуализацией вообще, бо я в ней живу — в среднем несколько часов в день с 2001-го года, бо характер работ такой.
Во-вторых, я, в отличие от, признал за собой невладение некоторой информацией.
В третьих, почему я там упирался?
Если бы ты так же плотно имел дела с виртуализацией, как я все последние более 15 лет, то тебе было бы всё кристально ясно и ты бы мне мог указать на суть моих заблуждений, как я регулярно указываю тебе.
А ларчик там просто открывался — на момент 2006-2008-хх лет вменяемой виртуализации в Linux не было.
Она появилась в сыром виде в 2011-м и в более менее нормальном виде вот недавно — в 2013-м.
До этого была технология qemu, т.е. технология полной эмуляции аппаратуры.
Кто помнит самые первые версии VirtualBox, тот должен понимать, о чём речь.
Сравнивать с уже вышедшим полноценным Hyper-V сей кошмар было нельзя.
Это были разные вселенные.
На "той стороне" технологий был еще такой гипервизор Xen.
Одно но — с ним всё было не просто в те года, нужно было патчить исходники ядра Linux и кучи системных сервисов для работы с ним.
Поэтому, на Xen хорошо ложился лишь на такой сценарий, когда поставщик услуг собирает свою пропатченную сборку с самостоятельно собранным из сырцов ядром, основными сетевыми службами, веб-серваком, скриптовым языком и каким-нить MySQL. Вот такой сценарий был мега-популярен — когда тебе дают уже преднастроенную специально собранную под Xen виртуалку, в которой лишь веб-сервак+скрипт+sql+ftp/sftp и шаг вправо-влево банально недоступен.
Но это ж "не оно", верно?
Произвольный бинарный образ на "этом" не запустишь.
А на чём запустишь (на RHEL под AWS), то вдвойне "не оно".
Почему не оно?
Потому что на тот момент была совсем уж сильная зависимость генерируемого кода от опций компилятора, в которых указывалось поколение целевых процессоров.
Для сравнения, собранная Генту на начало 2000-х у меня работала минимум на 30% быстрее чем RHEL. Генту собиралась по-месту на целевой проц, а не на (упаси хосподи) на 486-й, как тогда собирался RHEL. Почему Генту и вызывала такой интересо тогда.
Но Генту и прочие сборки Линукс, включая собственные (я участвовал одно время в разработке и поддержке одной из сборок), — это всё на Xen не жило от слова никак и ни в коем случае.
А пользовать qemu — это или обман клиентов или жуткая неэффективность, тут на выбор, как сие назвать.
Однако, когда я по твоей ссылке (спасибо, кста) увидел цену "аренды" в пересчёте на одноядерный проц с 1700 MHz тактовой (при том, что у меня на столе уже стоял комп с 3.2 GHz), то всё встало на свои места.
Паззл у меня в голове сошёлся — да, таки qemu.
Какой кошмар. )))
У богатых свои причуды.
S>- что запись в shared memory вызывает какие-то дополнительные "прерывания" по сравнению с записью в обычную private память процесса
Разумеется. Каждая запись в shared memory в Windows вызывает прерывания ОС, чтобы пометить ссотв. страницы памяти как "грязные".
Потому что нет такого понятия "просто shared memory" в Windows, есть технология маппинга файлов в память.
И пометка страниц для последующей обязательной синхронизации с диском — это азы азов сей технологии.
Даже если ты не указал конкретный файл для маппинга, то cистема тебе выделит область в system paging file.
Но суть происходящего не изменится.
RTFM!
S>- что Skype for Business использует проприетарный протокол вместо стандартного SIP/RTP
Это ты указал, что используешь Skype for Business.
S>- что-то там про ресайз страниц в SQL Server
И что там? ))
Ну, т.е., в ЭТОМ обсуждении найти мою "чушь" у тебя не получилось.
Итого, голосновность, так и запишем.
V>>Потому что перечислить твою бесконечную чушь мне вовсе не сложно:
V>>- если ISAM — то речь непременно о файловой базе, индексы непременно хранятся отдельно и без транзакций;
S>о да, тут вам повезло — поймали на разнице терминологий.
Если бы ты не пытался "гнобить", я не "поймал бы", заметь.
Просто совсем уж в глаза бросались, прямо скажем, странности рассуждений в сочетании с агрессивностью.
V>>- важна только стоимость транзакций, а то, что железо при этом будет стоить дороже стоимости всего бизнеса заказчика — не важно; ))
S>Это вы, похоже, не понимаете фундаментальной природы вещей. Не бывает таких бизнесов, стоимость которых меньше их оборота. Я вам даже формулы приводил, как первокласснику. Вы продолжаете тупить, и верить в бизнесы, у которых есть потребность в миллион транзакций в минуту, но при этом зарабатывают они на этих транзакциях столько, что не могут себе позволить $50k на железо.
Тем не менее, обычный современный серверный бокс ценой до 2000 зелени справляется с сотней тыс транзакций в секунду (описанной "сложности" их по твоей ссылке).
Вот и прикинь стоимость транзакции за ~5 лет работы этого сервака.
Она выходит на несколько порядков меньше озвученных тобой цифр.
И кто тут первоклассник?
Разделить два числа уже не в состоянии.
V>>- накладные расходы при передаче в другой процесс можно игнорировать по сравнению с "тут устаревший набор представлений о дисках";
S>Ну, вы же так и не опровергли мои аргументы. В ответ — какой-то бред про "прерывания".
Опроверг, дав тебе для примера современные диски и их скорости.
V>>Кстате, не далее месяца назад я поставил себе похожий девайс от обсуждаемого:
V>>https://www.dns-shop.ru/product/855ee22dac8f3330/250-gb-ssd-m2-nakopitel-samsung-960-evo-mz-v6e250bw/
V>>Выдаёт скорости в точности как указано в спецификации.
V>>вот на этой материнке:
V>>https://ru.gecid.com/mboard/gigabyte_z370p_d3/
S>Ну, почему бы не скачать софтинку и не запустить её? Поделитесь результатами — общественность будет вам благодарна.
Дык, я сходу скачал несколько программ для теста диска и погонял их.
Скриншоты прислать?
S>Интересует random mixed read/write, очередь можете любого размера.
Ага, уже mixed read/write?
А соломки не постелить? ))
А чего же не sequential read для очереди длиной свыше сотни?
Неудобно?
Зато SQL-серваку очень удобно на 99% сценариев.
Ну и, главное замечание, что эти "голые скорости" чтения с диска в любом случае получаются уже выше, чем даже в случае расположения файлов базы на RAM-диске, т.е. узким местом современные SSD-диски уже не являются.
Узкое место — сама СУБД.
Об этом и есть всё это обсуждение, если ты не заметил до сих пор.
S>Здравствуйте, vdimas, Вы писали:
V>>Это так называлась библиотека ORM? ))
S>Не "библиотека ORM", а просто ORM. Object-relational mapper.
Но мы обсуждали либы/фреймворки.
S>Там была адская смесь метаданных в коде приложения, метаданных в таблицах в базе, и метаданных в виде собственно объектной модели.
V>>Что, прям абстрактная от конкретных ваших прикладных типов и прямо на Дельфях?
S>Ядро — было абстрактным. На основе этого ядра писались "наши прикладные типы".
S>100% кода — на дельфях.
V>>А это вообще возможно физически? ))
S>Отож.
Ясно, невозможно.
Всё ручками.
Как и все остальные в те года.
V>>Т.е., твоё поучение должно было трансформироваться из упрёка в незнании IDENTITY в упрёк в незнании о наличии такой хрени как батчей, не?
S>А где я говорил о незнании IDENTITY? Я наглядно вижу ваше непонимание, как правильно готовить батчи для MS SQL.
О! Всё-таки батчи!
Ну т.е. ты уже увидел, что если из твоего батча убрать несколько документов, оставив один, то запрос IDENTITY всё-равно нужен.
И даже если взять предположенный тобой раундтрип на клиента, разбивая вставку master/slave на много операций, то IDENTITY после вставки в master нужен даже в этом сценарии. )) Не прошло и пяти постов, как ты сие заметил. А как дышал, как дышал...
V>>Рисовать такой батч на клиенте и отправлять на сервак в те года — я еще ДО этого высмеял такой сценарий, как совершенно нереальный для тех лет.
S>Ну вот, продолжаете тупить.
Продолжаю настаивать, а не тупить.
Потому что не кластер с ценой транзакций 0.1$ за штуку, а обычный комп, с ценой транзакций примерно 0.00001$ за штуку.
S>Вполне себе реальный сценарий. Именно так всё и работало. Ничего военного — подготовили команду, отправили на сервер.
И залипли на 3-10 секунд.
Я б уволил.
S>Вижу, для вас эта простая идея представляет непредставимую сложность.
Да какая там сложность?
Это ж то самое решение в "лоб", от которого мне всю жизнь приходилось уходить.
И не от хорошей жизни приходилось, заметь, а из-за проживания в реальном мире, а не в мире сферических коней в вакууме.
Помнится, как-то несколько лет назад я уже обращал твоё внимание, что ты за все эти годы не удовлетворил ни одного нефункционального требования в обсуждениях.
Ты даешь некий примитивизм, решение в лоб, которое даст любой студент.
А на вопросы "а как же остальные требования?" у тебя всегда одна и та же отмазка — "оно вам не нужно!", и далее ВСЕГДА следует много бла-бла-бла, объясняющее почему человеку "на самом деле" (С) не нужно то, что он спрашивает. Вот такой всегда с тобой сюрр. ))
V>>Ну вот документы каждый по нескольку сотен строк.
V>>А еще и несколько док-тов за раз.
S>Отож. Вы что, правда думаете, что отправить 50 килобайт данных по сети — это что-то невообразимое?
Я не думаю, я знаю, (бо постоянно наблюдал) что это задержки на ровном месте по состоянию на 20+ лет назад.
Поэтому, в популярных промышленных системах никто так не делал, разумеется, т.е. никто не отправлял многокилобайтные батчи на сервак.
Документ отправлялся на сервак построчно или группами строк (в асинхронном UI, которое как раз стало мегапопулярно именно во второй половине 90-х, с развитием клиент-сервера и трехзвенки).
Просто в Дельфи всего этого не было, разумеется.
Дельфи — это как обратная сторона Луны... там жили и работали инопланетяне.
Там, наверно, даже другие физические законы были. ))
V>>В твоём случае надо ожидать ответ от сервака, прежде чем продолжить редактировать в "синхронном" режиме строчки накладной, отправляя на сервак их обновлённые версии.
S>И в чём проблема? Подождать 3 секунды после нажатия на "Save"?
Это если ты один подключённый к серваку, то 3 секунды.
А так-то и десяток секунд аж бегом.
За этот же десяток секунд уже можно обслужить следующего клиента.
Кароч, от клиентского сценария ты малость далёк, я уже обращал на это твоё внимания.
Достаточно того, что ты всю дорогу делаешь акценты на сложности/важности именно серверной части.
Отнюдь, серверная часть никогда не бывает сложной от слова вообще (там есть лишь сложность поддержки, но это побочные эффекты языка SQL и отдельный разговор, почему SQL так радостно переезжает на клиента + LINQ).
В любом случае, именно информационная сложность БД-части до клиентской никогда не дотягивает.
Даже в полноценной трехзвенке, а не в примазываемом к трехзвенке HTTP-сценарии.
Клиент диктует вообще все сценарии работы с серваком, бо ради него (клиента) всё и затевалось.
V>>Ну, реально, вот прямо отсуюда дай мне ссылку, плиз, именно на мою чушь.
S>Ссылки искать среди тысяч ваших сообщений мне неинтересно. Из того, что осталось в памяти:
S>- что EC2 Амазона были обычными серверами, которые надо было заказывать за три дня, и только в 2009 их перевели на виртуализацию
Во-первых, это было не в этом обсуждении, а в другом.
Я проявил незнание того, как обстояли дела конкретно с AWS.
Зато знал, как обстояли дела с виртуализацией вообще, бо я в ней живу — в среднем несколько часов в день с 2001-го года, бо характер работ такой.
Во-вторых, я, в отличие от, признал за собой невладение некоторой информацией.
В третьих, почему я там упирался?
Если бы ты так же плотно имел дела с виртуализацией, как я все последние более 15 лет, то тебе было бы всё кристально ясно и ты бы мне мог указать на суть моих заблуждений, как я регулярно указываю тебе.
А ларчик там просто открывался — на момент 2006-2008-хх лет вменяемой виртуализации в Linux не было.
Она появилась в сыром виде в 2011-м и в более менее нормальном виде вот недавно — в 2013-м.
До этого была технология qemu, т.е. технология полной эмуляции аппаратуры.
Кто помнит самые первые версии VirtualBox, тот должен понимать, о чём речь.
Сравнивать с уже вышедшим полноценным Hyper-V сей кошмар было нельзя.
Это были разные вселенные.
На "той стороне" технологий был еще такой гипервизор Xen.
Одно но — с ним всё было не просто в те года, нужно было патчить исходники ядра Linux и кучи системных сервисов для работы с ним.
Поэтому, на Xen хорошо ложился лишь на такой сценарий, когда поставщик услуг собирает свою пропатченную сборку с самостоятельно собранным из сырцов ядром, основными сетевыми службами, веб-серваком, скриптовым языком и каким-нить MySQL. Вот такой сценарий был мега-популярен — когда тебе дают уже преднастроенную специально собранную под Xen виртуалку, в которой лишь веб-сервак+скрипт+sql+ftp/sftp и шаг вправо-влево банально недоступен.
Но это ж "не оно", верно?
Произвольный бинарный образ на "этом" не запустишь.
А на чём запустишь (на RHEL под AWS), то вдвойне "не оно".
Почему не оно?
Потому что на тот момент была совсем уж сильная зависимость генерируемого кода от опций компилятора, в которых указывалось поколение целевых процессоров.
Для сравнения, собранная Генту на начало 2000-х у меня работала минимум на 30% быстрее чем RHEL. Генту собиралась по-месту на целевой проц, а не на (упаси хосподи) на 486-й, как тогда собирался RHEL. Почему Генту и вызывала такой интересо тогда.
Но Генту и прочие сборки Линукс, включая собственные (я участвовал одно время в разработке и поддержке одной из сборок), — это всё на Xen не жило от слова никак и ни в коем случае.
А пользовать qemu — это или обман клиентов или жуткая неэффективность, тут на выбор, как сие назвать.
Однако, когда я по твоей ссылке (спасибо, кста) увидел цену "аренды" в пересчёте на одноядерный проц с 1700 MHz тактовой (при том, что у меня на столе уже стоял комп с 3.2 GHz), то всё встало на свои места.
Паззл у меня в голове сошёлся — да, таки qemu.
Какой кошмар. )))
У богатых свои причуды.
S>- что запись в shared memory вызывает какие-то дополнительные "прерывания" по сравнению с записью в обычную private память процесса
Разумеется. Каждая запись в shared memory в Windows вызывает прерывания ОС, чтобы пометить ссотв. страницы памяти как "грязные".
Потому что нет такого понятия "просто shared memory" в Windows, есть технология маппинга файлов в память.
И пометка страниц для последующей обязательной синхронизации с диском — это азы азов сей технологии.
Даже если ты не указал конкретный файл для маппинга, то cистема тебе выделит область в system paging file.
Но суть происходящего не изменится.
RTFM!
S>- что Skype for Business использует проприетарный протокол вместо стандартного SIP/RTP
Это ты указал, что используешь Skype for Business.
S>- что-то там про ресайз страниц в SQL Server
И что там? ))
Ну, т.е., в ЭТОМ обсуждении найти мою "чушь" у тебя не получилось.
Итого, голосновность, так и запишем.
V>>Потому что перечислить твою бесконечную чушь мне вовсе не сложно:
V>>- если ISAM — то речь непременно о файловой базе, индексы непременно хранятся отдельно и без транзакций;
S>о да, тут вам повезло — поймали на разнице терминологий.
Если бы ты не пытался "гнобить", я не "поймал бы", заметь.
Просто совсем уж в глаза бросались, прямо скажем, странности рассуждений в сочетании с агрессивностью.
V>>- важна только стоимость транзакций, а то, что железо при этом будет стоить дороже стоимости всего бизнеса заказчика — не важно; ))
S>Это вы, похоже, не понимаете фундаментальной природы вещей. Не бывает таких бизнесов, стоимость которых меньше их оборота. Я вам даже формулы приводил, как первокласснику. Вы продолжаете тупить, и верить в бизнесы, у которых есть потребность в миллион транзакций в минуту, но при этом зарабатывают они на этих транзакциях столько, что не могут себе позволить $50k на железо.
Тем не менее, обычный современный серверный бокс ценой до 2000 зелени справляется с сотней тыс транзакций в секунду (описанной "сложности" их по твоей ссылке).
Вот и прикинь стоимость транзакции за ~5 лет работы этого сервака.
Она выходит на несколько порядков меньше озвученных тобой цифр.
И кто тут первоклассник?
Разделить два числа уже не в состоянии.
V>>- накладные расходы при передаче в другой процесс можно игнорировать по сравнению с "тут устаревший набор представлений о дисках";
S>Ну, вы же так и не опровергли мои аргументы. В ответ — какой-то бред про "прерывания".
Опроверг, дав тебе для примера современные диски и их скорости.
V>>Кстате, не далее месяца назад я поставил себе похожий девайс от обсуждаемого:
V>>https://www.dns-shop.ru/product/855ee22dac8f3330/250-gb-ssd-m2-nakopitel-samsung-960-evo-mz-v6e250bw/
V>>Выдаёт скорости в точности как указано в спецификации.
V>>вот на этой материнке:
V>>https://ru.gecid.com/mboard/gigabyte_z370p_d3/
S>Ну, почему бы не скачать софтинку и не запустить её? Поделитесь результатами — общественность будет вам благодарна.
Дык, я сходу скачал несколько программ для теста диска и погонял их.
Скриншоты прислать?
S>Интересует random mixed read/write, очередь можете любого размера.
Ага, уже mixed read/write?
А соломки не постелить? ))
А чего же не sequential read для очереди длиной свыше сотни?
Неудобно?
Зато SQL-серваку очень удобно на 99% сценариев.
Ну и, главное замечание, что эти "голые скорости" чтения с диска в любом случае получаются уже выше, чем даже в случае расположения файлов базы на RAM-диске, т.е. узким местом современные SSD-диски уже не являются.
Узкое место — сама СУБД.
Об этом и есть всё это обсуждение, если ты не заметил до сих пор.