Здравствуйте, Sinclair, Вы писали:

S>Это было в ответ на "В дотнете же это всё "даётся сверху" без малейшей возможности настроить под себя" и "в отличие от дотнетных дров, нет надобности копировать эти данные".
S>Внезапно, простейшая мысль о том, что "сверху" в дотнете даётся только IDataRecord/IDataReader, а всё остальное — оно идёт "снизу", оказалась для вас неподъёмно сложной.

Похоже ты малость малость заблудился, потерял контекст.
Дрова доступа к БД — это то, что традиционно "даётся сверху", т.е. не разрабатывается направо и налево.
А желательно разрабатывается производителями СУБД.

Для разработчика такие дрова традиционно входят в т.н. "пояс безопасности" кода, т.е. в то, на что в разработке можно принципиально опереться.

Ты же не рассуждаешь, что в операционных системах тоже можно менять код, мол, делайте свой форк, применяйте любимые практики и пользуйтесь?


S>Далее, я открытым текстом с самого начала писал:
S>[q]Воображаем примерно такую штуку:

Кто-то 5 пинг-понгов не мог ответить на простой вопрос — это такой код существует в реальности, или просто умозрительный?
Как писать умозрительный я и сам тут регулярно даю.

Но раз 5 пинг-понгов не было прямого ответа на прямой вопрос, то слабость подобной аргментации ты понимаешь и сам.

Здравствуйте, Ikemefula, Вы писали:

V>>Сделай так, чтобы и другие увидели — давай цитаты.
I>Самое простое, из последнего — твои рассуждения про ТайпСкрипт, про кофе, всё прямо в этом треде.
I>http://rsdn.org/forum/flame.comp/8102709.1

Автор: vdimas
Дата: 29.09.21

I>Вот отсюда ясно, что ты настаиваешь непойми на чем.

Я не вижу конкретных цитат, где я что-то придумал и настаиваю на том, что это факты.
Сливаешься?


I>Теперь про кофе, ржом вместе в голос:
I>Вот твой опыт с туркой:
I>

I>"Вручную сваренный" — это в латунной турке на песке?
I>И где крепость кофе примерно в 10 раз выше традиционной, что к порции кофе подают бокал прохладной воды, бо рези в желудке могут появить даже у абсолютно здорового человека?

I>Трудно понять, где же ты нарвался на такой шмурдяк. Логичнее предположить, что этот аргумент высосан из пальца.

Это классический рецепт в турке, которому, рецепту, уже несколько веков.


I>Вот снова подробности про турку:
I>

I>1. Одна турка способна выдать одну порцию кофе примерно раз в 15-20 минут, а их редко бывает больше одной в таких заведениях.

I>Черепаха-бариста?

Это так и есть.


I>А вот твоя реакция на "свежеобжареный кофе"

Это разъяснение, почему аргумент про "свежеобжареный кофе" — бред.

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


I>Похоже, что ты фантазировал прямо по ходу.

Это был ликбез.


I>Далее, уникальный рецепт заваривания в турке от Vdimas
I>

I>По технологии, кофе в турке доводится до кипения 7-8 раз, т.е. бармен 7-8 раз приподнимает турку над песком,

Это классический рецепт кофе в турке.


I>Вот еще:
I>

I>Де-факто, характерную горечь кофе в турке приобретает уже после первого закипания, но по классическому восточному рецепту уровень горечи доводят в таком кофе до абсурда.

I>Где же ты пил такой шмурдяк?

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

Это как сравнивать МакДональдс с нормальным рестораном какой-нить национальной кухни.
С такими замашками сразу попрошу в сад.


I>Я вот ни разу не нарывался на горький кофе в турке. Ну вот ни разу.

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


I>Далее, сеанс телепатии:
I>

I>Во всех перечисленных тобой заведениях будет ассортимент кофе из автоматов.

I>Здесь, похоже, не помогли ни ссылки, ни фото — vdimas знает лучше

Эспрессо — это кофе из автомата.
Даже если бармен вручную ставит и снимает воронку.


I>Продолжаем про кофе, феерия
I>

I>Порция 150 гр только закипает в первый раз примерно за 7 минут.

I>Видео с Мариной Хюппёнен не помогли, vdimas знает лучше

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

Слова Марины, что если "пена поднялась, то этого достаточно" — тупой развод на ровном месте.
Это развод от поставщиков кофе, устраивающих соревнования, в которых Марина победила.
Но поставщики кофе обитают по другую сторону баррикад от тебя, клиента.
В пылу спора ты умудрился об этом забыть. ))


I>Ты кофе на спиртовке варишь чтоли или на примусе?

Да хоть на чём угодно.
Искуственное ускорение процесса нарушает веками выверенную рецептуру.

Думаешь, туркам сложно перегреть песок или добавить в него соль для лучшей теплопроводности?
Там несложно, но такое кофе выльют бармену в рожу.
Не в переносном смысле, а в прямом.

Здравствуйте, Sinclair, Вы писали:

V>>А что тут нового?
V>>Там как в любом другом наборе ресурсов и очередей к ним.
S>А что мы считаем ресурсом?
S>Если мы делаем классический блокировочник, то у него минимальная гранулярность блокировки — 1 строка.

Зависит от уровня блокировки.
Существуют блокировки таблиц/индексов целиком, страниц и отдельных записей.


S>То есть мы на select — запрос, который сканирует 50% таблицы с миллионом записей, последовательно захватываем и отпускаем 500000 блокировок.

База сама решает, как лучше заблокировать таблицу.
При скане таблицы чаще блокируется вся таблица (но есть хинты, разрешающие не блокировать таблицу при скане, 1C, например, активно их использует при зачитке справочных таблиц).
При скане индекса — индекс целиком.

Различают RO и RW блокировки.

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


S>На пальцах — цикл сканирования выглядит так:
S>

S>foreach(var candidateRow in table.Index1.IndexSeek(predicate.IndexPart))
S>{
S>   lock(GetRowLock(candidateRow))
S>   {
S>     if(predicate.ResidualPart(candidateRow))
S>       yield return selector(candidateRow);
S>   }
S>}
S>

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


V>>Эээ, тормоза на блокировках зависят от частоты конфликтов квадратично.
S>Даже в отсутствие конфликтов блокировки отжирают время.

В отсутствии конфликтов — одна интерлокед-операция на таблицу для скана таблицы.
Считай, бесплатно.


S>Вместо быстрого цикла с телом типа table[rowNumber].Slice(fieldOffset, fieldLength), которое при удаче вообще сворачивается в пару ассемблерных инструкций, у нас на каждой итерации начинается беготня по таблицам блокировок.
S>Интуитивно кажется, что эта беготня имеет примерно тот же порядок стоимости, что и интерпретация выражений вроде GetFieldValue(rowPointer, fieldId).

Выше уже объяснил, почему это не так.


V>>Прикинь, уменьшение времени исполнения заявки в системе из одной машины вдвое равно масштабированию этой машины в кластер на 4 узла.
V>>(это если считать, что сам кластер ничего не стоит с т.з эффективности, т.е. кластер сферический в вакууме)
S>Ну, вот у меня пока такое понимание, что основные задержки обработки "заявки" в современных трёхзвенках — это трипы между апп-сервером и СУБД.

Да.
И особенно забавен тот факт, что намного раньше масштабируют сервер приложений, а не СУБД, к которой множество узлов кластера сервера приложений обращаются конкурентно.
Разве такое положение вещей не наводит на необходимые мысли?


S>Компиляция — штука хорошая, но её эффект заранее трудно оценить именно потому, что не получается сделать из плана запроса код, сравнимыый с каноническим while(p*++=q*++);.

План запроса в любом случае оперирует готовыми предкомпилёнными "кубиками".
Речь о грануляции этих "кубиков".


S>Ну, вот мне сначала казалось, что компиляция даст офигенный буст к производительности DBMS. А сейчас я вижу некоторые ограничения, которые на первый взгляд будут замедлять исполнение кода примерно на десятичный порядок по сравнению с компилируемым кодом, который шарашит по "голым" данным, без оглядки на isolation и durability.

Это всё сводится к очередям заявок СМО.
Пока мест не существует другого механизма для описания происходящего.


S>Это сильно ухудшает производительность сканирования — вместо тупого обращения по смещению pageNo*pageSize, нужно лезть в bufferManager.getPage(pageNo), который даже на happy path добавляет лишнюю косвенность.

Косвенность на страницу и косвенность на поле — немного разные вещи.
Косвенность на страницу "размазывается" на стоимость обработки многих хранящихся на странице записей.


S>Поэтому MMF будут уместны только для mostly-read key-value storage, где как правило 1 транзакция == 1 изменение, а чтения доминируют над записями.

Мой подход в первейшую очередь отталкивается от того, что трафик чтения серьезно превалирует над трафиком записи, бо в случае записи в базу компиляция всего и вся в суровый нейти не даст порядка прироста производительности. Просто при записи чаще всего происходит обязательное сначала чтение-поиск (в т.ч. при проверке целостности уникальных индексов/ключей), это надо держать в голове. ))


V>>На своей заднице испробовал когда-то, да еще на тормознутой технике конца 90-х — начала нулевых, когда любые эффекты были ну уж слишком хорошо заметны.
S>Вот это как раз странно. Потому что при наличии уместных индексов, уменьшение рабочего объёма в N раз сокращает время операции на константу ~ log(N).

А общую эффективность в многопользовательской среде поднимает в квадрат раз от этой константы.

И эта, в суррогатых ключах тех же справочных данных и при нормальной статистике обращение к записи стоит O(log(N)) только при очень большом N, а на практике там пару ветвлений, а затем тупо смещение на странице индекса. Мы же недавно обсуждали B+ деревья, так вот, листья "знают", последовательный индекс в них или нет — на то она и статистика в индексе, что ведёт учёт "островков" данных.

Т.е., "законный" O(log(N)) будет при отсутствии всякой статистики.


S>Можно ли из полученных результатов делать какие-то выводы про производительность выполнения SQL кода в режиме интерпретации vs в режиме компиляции?
S>Нет, нельзя. Ну, то есть понятно, что медленнее от компиляции код уже не станет. А вот насколько он станет быстрее — это вопрос.

"Самописные" базы показывали ускорение на пару порядков еще в первой половине 90-х.
Такие базы писались для неконкурентного чтения-записи, обслуживались заведомо предкомпилённым кодом, т.е. АПИ такой базы давало заранее известный набор обслуживаемых запросов.

Я тщательно крутил одну из тогдашних бухгалтерий на DOS (текстовое "оконное" приложение) с собственным неконкурентным компиллируемым движком БД — с тогдашними СУБД на той технике сравнивать было бесполезно. Эта бухгалтерия была входу в нашем городе примерно до 95-96-х годов (вот этот человек автор, тогда 30+ ему было: https://companies.rbc.ru/id/1149204047024-ooo-irbis/, считался гением IT в нашем городе, занимался нацчными исследованиями в области IT, пока не ушел из ВУЗ-а), в общем, оно было востребовано пока 1С не начала пожирать всех, да и вообще, пока Windows окончательно не вытеснила DOS.


S>Сколько будет стоить компиляция — тоже вопрос, от которого зависит ответ на более интересный вопрос "при каких условиях динамическая компиляция выиграет у интерпретации".

Тут согласен, но это опять умозрительное на далёкое будущее.
Пока мест JIT-компиляция работает не на таком уровне, а движки баз данных не генерят код, пригодный для JIT.


S>Похожий вопрос — "при каких условиях статическая компиляция выиграет у динамической".

Это если в наличии есть динамическая компиляция.

Здравствуйте, vdimas, Вы писали:

V>В том же C# не могу, даже при небольшом изменении в одном месте часто приходит наворачивать круги по всему проекту.

Непонятно. Зачем?

V>"Изменение" имеется ввиду не рефакторинг, бо рефакторинг — это изменение кода без изменения функциональности.

Без видимого изменения функциональности. С точки зрения кода это не имеет значения.

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>В том же C# не могу, даже при небольшом изменении в одном месте часто приходит наворачивать круги по всему проекту.
НС>Непонятно. Зачем?

Что зачем?
Тебе то же самое приходится делать при внесении ломающих компилябельность изменений.

Здравствуйте, vdimas, Вы писали:

V>>>В том же C# не могу, даже при небольшом изменении в одном месте часто приходит наворачивать круги по всему проекту.
НС>>Непонятно. Зачем?
V>Что зачем?

Наворачивать круги по проекту.

V>Тебе то же самое приходится делать при внесении ломающих компилябельность изменений.

Нет.

Здравствуйте, Sinclair, Вы писали:

НС>>Поэтому кеширование для таких файлов отключается.
S>Нет. Так никто не делает.

А почему собственно?
Представим себе, что мы посылаем асинхронные запросы, для каждого из которых требуем нотификации успешного завершения только когда байтики, грубо говоря, сформировали соответствующие сдвиги атомов и электронов. А потом, получив подтверждение записи WAL, пишем изменённые страницы на диск.
Чем плохо?

S>>>В MMF мы не можем этого гарантировать.

НС>>Так не надо лог в MMF писать, о чем и речь.
S>Это как раз понятно. Лог пишется в режиме stream: добавляем всегда в конец. Но отсутствие кэширования (== flush на каждый write) гарантированно убъёт производительность при модификациях.
S>Представьте себе выполнение операции update employee set salary = salary * 1.05 where region = @region.
S>То, что вы предлагаете, означает выполнение flush лога N раз для N записей, попавших под предикат.
S>Это — очень плохое решение, т.к.
S>- на HDD мы получим ограничение быстродействия в ~100 изменений в секунду, т.е. транзакция, трогающая всего лишь 1000 записей, будет выполняться не меньше 10 секунд.
S>- на SSD мы получим многократные перезаписи одной и той же страницы, очень быстро изнашивая диск.

Хм. Это какая СУБД так делает? Я скорее предположил бы что-то типа такого (уточнить по уровню изоляции):
1. Последовательно, или ускоренно по индексу, читаем все записи, ставя лок на запись на каждую подпадающую под условие. Тут можно разгонять упреждающее чтение для скорости.
2. Записываем в WAL изменённые строки для каждой подпавшей под условие; это можно сгруппировать. Ждём подтверждения записи.
3. По команде commit — запускаем (лучше одновременно) запись изменённых версий строк во все соответствующие блоки. СУБД должна сгруппировать эти действия по своим блокам, а диск — обеспечить соответствующее упорядочение и группировку по своим блокам. Ждём завершения всех записей. Одновременность подачи позволяет диску максимально оптимизировать операции.
4. В WAL фиксируем завершение транзакции (ждём подтверждения записи и тогда отдаём ok на commit).

Что тут не так и что может давать какие-то ограничения?

S>- на SSD мы получим многократные перезаписи одной и той же страницы, очень быстро изнашивая диск.

Какой именно страницы и в какой это СУБД такое происходит?
Имеется в виду секция WAL? Почему СУБД не может сгруппировать пачку записей для WAL в пределах одной транзакции?

НС>>Так что тут если какое то буферизирование при записи в лог и делать, то только чисто программное, на уровне прикладного кода.
S>По большому счёту, нам всё равно, как устроена буферизация при записи в лог. Там главное — возможность сделать честный flush() в нужный приложению момент.

flush() в таком виде нужен только для оптимизации синхронных операций записи. Асинхронным он даже вреден (точнее, вредно кэширование, которым он управляет — поэтому для асинхронных операций он бессмысленен).
Но пусть вы даже работаете синхронными операциями. При необходимости обеспечить строгую последовательность действий: запись операции в WAL — модификация таблиц — завершение транзакции записью в WAL, что запись состоялась, значит, что должен быть логический барьер
1) все записи действий в WAL идут до всех записей в таблицу;
2) все записи в таблицу идут до финализации в WAL,

и если вы не хотите терять производительность на слишком частом дёргании flush() — придётся синхронизировать его между соседними транзакциями. Вы уверены, что вам это нужно?

S>2. Открыть файл c флагами FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH. Тогда можно делать просто FileStream.Flush().
S>Подчеркну: в обоих случаях мы делаем Flush лога на на каждое изменение, а только на каждый commit transaction. То есть транзакция, которая трогает 1000 записей, будет выполняться ~10ms (если выбранный размер буфера достаточен для того, чтобы избежать промежуточных сбросов в процессе исполнения).

НС>>И, в любом случае, MMF для файла лога бессмысленен и бесполезен, там все равно запись и чтение строго последовательные.
S>Речь идёт про MMF для файла данных.

Неудобно, потому что нельзя инициировать независимо пачку операций на одну транзакцию. Разве что одна окажется одним связным куском, тогда может быть msync() (или что там в Windows) на кусок и ядро будет параллелить операции (если может).

Здравствуйте, vdimas, Вы писали:
V>Зависит от уровня блокировки.
V>Существуют блокировки таблиц/индексов целиком, страниц и отдельных записей.

V>Учитывая, что виды блокировок и их гранулярность находятся в строгой иерархии, я немного не понимаю суть твоих вопросов.
V>Что ты хочешь узнать?
Узнать — ничего. Вот этот вот ликбез, про гранулярность блокировок, который вы мне рассказываете, я преподаю. Вы, кстати, забыли про Update Lock и про Intent блокировки.

Вопрос — в том, как обеспечить быстродействие в реальных задачах, особенно когда планировщик заранее не знает, сколько строк попадёт под предикат.
Превентивный захват блокировок уровня таблицы/индекса сильно снизит concurrency, особенно на многопроцессорных машинах.

S>>На пальцах — цикл сканирования выглядит так:
S>>

S>>foreach(var candidateRow in table.Index1.IndexSeek(predicate.IndexPart))
S>>{
S>>   lock(GetRowLock(candidateRow))
S>>   {
S>>     if(predicate.ResidualPart(candidateRow))
S>>       yield return selector(candidateRow);
S>>   }
S>>}
S>>

V>Так ты ACID не обеспечишь, т.к. после отпускания строки ранее не попавшие под условие строки, т.е. уже отброшенные, могут начать подходить под условие в результате конкурентных изменений. Такое поведение, повторюсь, навязывается специальными хинтами.
Такое поведение соответствует уровню блокировки read committed. Если хочется repeatable read — то придётся удерживать локи до конца транзакции.
В данном контексте это непринципиально.

V>В отсутствии конфликтов — одна интерлокед-операция на таблицу для скана таблицы.
V>Считай, бесплатно.
Хм. Я пока не понимаю, как этого можно добиться. Что такое "отсутствие конфликтов"? Открытие базы в монопольном режиме? Так в нём вообще блокировки не нужны.
А если база открыта в немонопольном режиме, то гарантировать отсутствие конкурентных изменений невозможно.

Представим себе, что у нас есть несколько активных транзакций, которые захватили Row-Lock на какие-то строки нашей таблицы.
Вот у нас начинается scan этой таблицы в ещё одной транзакции. Вы, если я правильно понял, предлагаете захватить table lock. Как это будет сделано?
Сдаётся мне, что одной интерлокед-операцией обойтись не удастся.
В общем, тут у меня некоторый пробел — я не вижу способа сделать захват блокировок шибко эффективным.

V>Разве такое положение вещей не наводит на необходимые мысли?
Наводит. Я в направлении этих мыслей работаю.

V>План запроса в любом случае оперирует готовыми предкомпилёнными "кубиками".
V>Речь о грануляции этих "кубиков".
Ну, в существующих СУБД план запроса оперирует интерпретацией выражений. В "кубик" вставляется некоторый код, который подходит только для одного конкретного плана конкретного запроса.
Как собрать эффективный план из предкомпилированных кусков — большой вопрос.

S>>Это сильно ухудшает производительность сканирования — вместо тупого обращения по смещению pageNo*pageSize, нужно лезть в bufferManager.getPage(pageNo), который даже на happy path добавляет лишнюю косвенность.

V>Косвенность на страницу и косвенность на поле — немного разные вещи.
V>Косвенность на страницу "размазывается" на стоимость обработки многих хранящихся на странице записей.
Возможно. Надо смотреть. Опять же — сильно зависит от типов данных и ширины таблиц. Узкие таблицы с арифметикой — да, всё ок. Широкие таблицы с текстом — там для сборки одной записи может потребоваться прыгать по страницам.

V>Мой подход в первейшую очередь отталкивается от того, что трафик чтения серьезно превалирует над трафиком записи, бо в случае записи в базу компиляция всего и вся в суровый нейти не даст порядка прироста производительности. Просто при записи чаще всего происходит обязательное сначала чтение-поиск (в т.ч. при проверке целостности уникальных индексов/ключей), это надо держать в голове. ))
Эмм, то есть ваш подход полезен только для определённого профиля задач.

V>А общую эффективность в многопользовательской среде поднимает в квадрат раз от этой константы.
Не совсем так Константа же вычитается, а не делит время.

V>Т.е., "законный" O(log(N)) будет при отсутствии всякой статистики.
Не, статистика не поможет вам выехать из O(log(N)). Она работает не так. Точнее, есть один тип индексов, построенный на знании об "островках" данных, но его придумали вот только пару лет тому, и ни в одной СУБД пока промышленно он не применяется. А о применении такой статистики, как вы говорите, в B/B+/B* деревьях я никогда не слышал.
Ъто интересно, если работает — пришлите ссылку на описание подхода.

V>"Самописные" базы показывали ускорение на пару порядков еще в первой половине 90-х.
V>Такие базы писались для неконкурентного чтения-записи, обслуживались заведомо предкомпилённым кодом, т.е. АПИ такой базы давало заранее известный набор обслуживаемых запросов.
Совершенно верно. А ещё они клали болт на fault tolerance и ограничения целостности. Так-то кто угодно может.
Понятно, что даже банальное чтение несжатого .csv из файла положит на лопатки любую СУБД.

V>Я тщательно крутил одну из тогдашних бухгалтерий на DOS (текстовое "оконное" приложение) с собственным неконкурентным компиллируемым движком БД — с тогдашними СУБД на той технике сравнивать было бесполезно. Эта бухгалтерия была входу в нашем городе примерно до 95-96-х годов (вот этот человек автор, тогда 30+ ему было: https://companies.rbc.ru/id/1149204047024-ooo-irbis/, считался гением IT в нашем городе, занимался нацчными исследованиями в области IT, пока не ушел из ВУЗ-а), в общем, оно было востребовано пока 1С не начала пожирать всех, да и вообще, пока Windows окончательно не вытеснила DOS.
Кто из них — Абрамов или Пустовойтенко?
А так-то — плох тот программист, который не писал свою бухгалтерию на DOS.

V>Пока мест JIT-компиляция работает не на таком уровне, а движки баз данных не генерят код, пригодный для JIT.
Генерят. Можно посмотреть на MemSQL с одного конца, и на Natively Compiled Stored Procedures в SQL Server — с другого.

Здравствуйте, netch80, Вы писали:
N>А почему собственно?
N>Представим себе, что мы посылаем асинхронные запросы, для каждого из которых требуем нотификации успешного завершения только когда байтики, грубо говоря, сформировали соответствующие сдвиги атомов и электронов. А потом, получив подтверждение записи WAL, пишем изменённые страницы на диск.
N>Чем плохо?
Так и делается.


N>Хм. Это какая СУБД так делает?
Более-менее все.
N>Я скорее предположил бы что-то типа такого (уточнить по уровню изоляции):
N>1. Последовательно, или ускоренно по индексу, читаем все записи, ставя лок на запись на каждую подпадающую под условие. Тут можно разгонять упреждающее чтение для скорости.
Что такое "читаем"? Вы имеете в виду "делаем копию в специальную временную область памяти, видимую только текущей транзакции"?
Как вы предполагаете разгонять упреждающее чтение для MMF? Читать в отдельном потоке по одному инту из тех страниц, которые нам скоро потребуются?
N>2. Записываем в WAL изменённые строки для каждой подпавшей под условие; это можно сгруппировать. Ждём подтверждения записи.
Не очень понятно, что такое "сгруппировать". Вы имеете в виду, что после фазы 1 мы отдельно запустим цикл по тем данным, которые мы скопировали во временный буфер, и создадим ещё один буфер, с новыми версиями этих записей?
А потом запишем эти записи в лог? И всё это — только ради того, чтобы не использовать встроенное в любой stream кэширование?
N>3. По команде commit — запускаем (лучше одновременно) запись изменённых версий строк во все соответствующие блоки. СУБД должна сгруппировать эти действия по своим блокам, а диск — обеспечить соответствующее упорядочение и группировку по своим блокам. Ждём завершения всех записей. Одновременность подачи позволяет диску максимально оптимизировать операции.
Не очень понятно, как вы "одновременно" сделаете запись изменённых версий в MMF файл. Ну, то есть это, конечно, можно делать в несколько потоков, но и только.
N>4. В WAL фиксируем завершение транзакции (ждём подтверждения записи и тогда отдаём ok на commit).
N>Что тут не так и что может давать какие-то ограничения?
В основном тут не так с эффективностью использования памяти. Получается, что мы не используем преимущества MMF напрямую, а строим поверх него свой набор буферов.
В принципе, так делать можно, но у нас тогда кэш СУБД начинает конкурировать за память с кэшем ФС. Поскольку все записи у нас делаются "вручную", можно просто убрать MMF совсем и в момент записи изменений просто сбрасывать страницы в обычный файл.

S>>- на SSD мы получим многократные перезаписи одной и той же страницы, очень быстро изнашивая диск.
N>Какой именно страницы и в какой это СУБД такое происходит?
N>Имеется в виду секция WAL? Почему СУБД не может сгруппировать пачку записей для WAL в пределах одной транзакции?
Отвечу с конца: группировка данных перед записью в файл называется буферизацией. Да, именно секция WAL и имеется в виду. Нет, никакая СУБД так не делает — по причинам, которые я изложил.
Записи WAL пишутся в лог по мере поступления, перемежаясь с записями от параллельно выполняемых транзакций. Буфер на всю транзакцию может оказаться неприемлемо большим при большом объёме вносимых изменений.

N>flush() в таком виде нужен только для оптимизации синхронных операций записи. Асинхронным он даже вреден (точнее, вредно кэширование, которым он управляет — поэтому для асинхронных операций он бессмысленен).
N>Но пусть вы даже работаете синхронными операциями. При необходимости обеспечить строгую последовательность действий: запись операции в WAL — модификация таблиц — завершение транзакции записью в WAL, что запись состоялась, значит, что должен быть логический барьер
N>1) все записи действий в WAL идут до всех записей в таблицу;
N>2) все записи в таблицу идут до финализации в WAL,
Второй барьер не нужен. Важен только первый. Запись в лог делать асинхронной смысла нет: всё равно мы должны в конце транзакции обеспечить синхронный flush, т.к. пока мы не получили от диска подтверждения записи лога, коммит подтверждать нельзя.

N>и если вы не хотите терять производительность на слишком частом дёргании flush() — придётся синхронизировать его между соседними транзакциями. Вы уверены, что вам это нужно?
В общепринятой схеме flush делается 1 раз на транзакцию, и синхронизации обращения к логу не слишком мешают — гранулярность записей обычно достаточно невелика (есть исключения при операциях заливки BLOB).

S>>2. Открыть файл c флагами FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH. Тогда можно делать просто FileStream.Flush().
S>>Подчеркну: в обоих случаях мы делаем Flush лога на на каждое изменение, а только на каждый commit transaction. То есть транзакция, которая трогает 1000 записей, будет выполняться ~10ms (если выбранный размер буфера достаточен для того, чтобы избежать промежуточных сбросов в процессе исполнения).


N>Неудобно, потому что нельзя инициировать независимо пачку операций на одну транзакцию.
Непонятно, что такое "инициировать независимо пачку операций на одну транзакцию" и зачем это может быть надо. В логе записи вполне себе зависимы, и идут в одном направлении. Синхронная запись в таких случаях — то, что доктор прописал.

Здравствуйте, vdimas, Вы писали:

[skip]

V>Во-вторых, в тесты ты не заглядывал.
V>Сравни с тестами linq2db, включая предыдущие две инкарнации, начиная с RDF.

V>Тестирование поделия по ссылке еще не начиналось от слова вообще, поэтому я и поставил вопрос как поставил — необходимо написать тонну тестов с 0-ля.
V>Потому что в отличие от тебя, я в имеющиеся "тесты" заглядывал.
V>Их нет.

Давай так, мы в linq2db тестируем MySqlConnector давно, и это охренительный провайдер. Были косяки, которые они исправили практически мгновенно. Вся наша куча тестов от него в восторге, а вот оракловская поделка просто достала https://github.com/linq2db/linq2db/issues/3145

Ты также забываешь что оракловский недоносок не поддерживает асинки от слова вообще.

Здравствуйте, Danchik, Вы писали:

D>Давай так, мы в linq2db тестируем MySqlConnector давно, и это охренительный провайдер. Были косяки, которые они исправили практически мгновенно.

ЧТД, независимое тестирование выявило косяки.
Еще кому-то требуется объяснять мотив моих рассуждений?
Т.е. даже в случае, если бы не выявило косяки?


D>Вся наша куча тестов от него в восторге

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

Опять же, в рамках тестирования linq2db тестируется не сам провадер, а работоспособность ORM- и LINQ-мапперов под него, верно?
Даже не заглядывая в сами тесты в linq2db ставлю на то, что они написаны из предположения заведомой работоспособности драйвера (любого из используемых в матрице тестов), т.е. целевые юниты тестирования не те, о которых сейчас речь.


D>оракловская поделка просто достала https://github.com/linq2db/linq2db/issues/3145

Я в середине нулевых использовал ODBC-драйвер для подключения к MySQL, потому что найденный мною в сети банально не работал.
Всех подробностей не помню, ес-но, но из основного:
— коннекшены вели себя нестабильно — периодически самопроизвольно закрывались, если к серверу было открыто несколько коннешенов одновременно из разных потоков;
— регулярно плевался исключениями по необъяснимым причинам;
— заметно тормозил, иногда резко нагружал CPU на ровном месте.

Сейчас подумалось, что вероятнее всего это именно тот драйвер, но тогда это не оракловая поделка, а опенсорсная изначально под крылом MySQL AB.
Sun и затем Оракл купили всё это дерьмо уже в нагрузку.
И оба сосредоточены больше на джаве, чем на дотнете, что может объяснять существущее положение вещей.

В отличие от, сценарий подключения через встроенный в дотнет ODBC-драйвер с использованием нейтивного ODBC-драйвера, установленного в поставке с MySQL, работал без нареканий.

Кстате, посмотрел, в оракловой доке этот сценарий тоже описывается:
https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-examples-programming-net-csharp.html


D>Ты также забываешь что оракловский недоносок не поддерживает асинки от слова вообще.

Я об этом вообще не рассуждал.
Речь была о несоответствии объёма наличествующих тестов степени важности подобных элементов инфраструктуры.

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

    private async ValueTask<int> SendReplyAsyncAwaited(ValueTask<int> task)
    {
        try
        {
            return await task.ConfigureAwait(false);
        }
        catch (Exception ex)
        {
            SetFailed(ex);
            throw;
        }
    }

Они превращают достаточно легковесный GC-free ValueTask, обеспечиваемый вылизанным кодом метода ValueTask<int> Socket.SendAsync(Memory<byte>, ...) в AsyncStateMachineBox, который реализует IValueTaskSource, т.е. подменяет уже имеющийся более-менее "статический" экземпляр IValueTaskSource (тот экземпляр создан однажды и закеширован в Socket) на создаваемый каждый раз ненужный класс-оболочку.

            // AsyncStateMachineBox looks like a small type, but it actually is not because
            // it will have a copy of all the slots from its parent. It will add another hundred(s) bytes
            // per each async method in CoreRT / ProjectN binaries without adding much value. Avoid
            // generating this extra code until a better solution is implemented.
            var box = new AsyncStateMachineBox<TStateMachine>();

Какие-то тошнотики-олигофрены...

Т.е. чуваки продекларировали, что сделают всем хорошо асинхронщину, но сами в асинхронщине не шарят.
Картина маслом, оно же рука-лицо.

А да, следом они превращают ValueTask в Task зачем-то, т.е. дополнительно заворачивают эту обертку еще в похожую обертку, только GC-классов уже побольше, включая сам тяжеловесный Task.

Ладно, всё, задолбали всеми этими примерами нескончаемого нубства, живущего в "популярном донетном коде".
Неважно, в официальном или левом, типа MySqlConnector.
Уже не смешно.

Сцуко, чем глубже в вопрос погружаешься, тем больше косяков режет глаз.

Здравствуйте, Sinclair, Вы писали:

V>>https://github.com/mysql-net/MySqlConnector/tree/master/tests/MySqlConnector.Tests
S>Во-первых, нет. Ну блин научитесь уже открывать ссылки, которые вам присылают.

Научись давать аннотации к ссылкам.


S>Не, давайте лучше сравним с тестами того коннектора, который вы готовы выбрать, отвечая за это банкротством. Мы же выбираем не между MySqlConnector и Linq2db, а между MySqlConnector и Connector/NET.

Не мы, а ты, с неудачной аналогией linq2db на аж драйвер доступа к СУБД.
Да еще в скотской манере, за которую я всё еще в упор не вижу извинений.

Здравствуйте, Sinclair, Вы писали:

S>Не, не ответили. Вы пишете про то, как вы хотите, чтобы всё было. А по факту официальный драйвер запросто умеет возвращать бред при определённых сочетаниях фактического и запрошенного типов. Как раз тот тип багов, который вы тут на строчку выше приводили как самый страшный.
S>Или вот https://bugs.mysql.com/bug.php?id=91754 — нормас, да? Можно до седых волос дойти, пытаясь найти, кто попортил данные в базе.
S>Но вас же это не смущает — миллионы мух не могут ошибаться.

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

Блин, ну не помню я таких косяков в нейтивных дровах БД.
Даже в махровых 90-х.
Думаешь, трава была реально зеленее тогда? ))
Или причина, таки, несколько в другом?


V>>Я находил баги и в майкрософтном ADO.Net драйвере к MS SQL.
V>>В дотнет Core тоже найдено и зарепорчено несколько багов.
S>Ну, вот видите! Внезапно оказалось, что баги в драйвере — отнюдь не катастрофа, не разорение компании. Нашли, заворкэраундили, зарепортили в гитхаб.

Это потому что баг был, кстате, тоже связан с бинарным полем, и, к счастью, задетектился бинарным же парсером содержимого этого поля на стороне уже нашего кода.
Иначе фиг бы обнаружили до продакшена, ес-но.
В более обычных сценариях подобные баги не детектятся — пришло что-то из базы левое и пришло, так прямо и используется.


V>>А ты в этом плане никто и звать тебя никак.
S>Ну, как же тут на личности-то не перейти.

Чья б корова мычала.


V>>Ничего тебя не смущает?
V>>Приведение sealed this к интерфейсу.
V>>В голове у авторов мусор вместо человеческих мозгов.
S>Может быть. А может быть — просто артефакты процесса разработки.

Ага, любые косяки — артефакты процесса разработки.
Только это такие косяки, которые видны невооружённым взглядом.
И что я должен думать про косяки другого класса — когда надо круги по десяткам экранов кода наворачивать, раскручивая полёт фантазии авторов, если у них массовые косяки в очевидных вещах?

Рядом очередной пример очевидного косяка:
http://www.rsdn.org/forum/flame.comp/8105378.1

А всего-то на очередные пару миллиметров в код погрузился. ))
Что помешало сделать аналогичный хелпер без async-await метода через банальное ContinueWith да еще тоже с закешированным для данного экземпляра Session соотв. Action?
(они дополнительно сохраняют исключение, и то там еще стоит внимательней посмотреть — а требуется ли копирование-запоминание экземпляра исключения, которое и так доступно?),

Кароч, я ж не вчера родился и проходил это всё уже бесконечное кол-во раз.
Если кач-во кода сходу г-но, то чем глубже погружаешься, чем г-но явственнее, лепёхи увесистее.

Обратного не было ни разу, да и не существует в природе факторов, которые обспечили бы обратный механизм. ))


V>>И особенно когда этих дэбилов представляют в духе "полюбуйтесь на наших передовиков!".
V>>Если передовики такие, какие ж остальные?
S>Код остальных можно посмотреть в оракловом коннекторе.

При том, что качественного кода тоже хватает — тот же linq2db и местная же либа rsdn-утилит (не помню точное название).
Всё вполне по-взрослому (кроме использования SemaphoreSlim, который оверинжиниред для сценария, где он использовался, т.е. и опять и снова, это такой уж какой есть инфраструктурный доступный изкаробки код).

Всё говорит лишь о нескончаемой демагогии — о нон-стоп попытках подмены тезиса, я ведь никогда не утверждал, что на дотнете нельзя писать качественный код (в рамках любого актуального состояния этой технологии).

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

Сцуко, если я от хрен его знает скольки многолетней собственной либы конверсии строк и там же парсинга/рендеринга банальных чисел смог отказаться только с выходом 5-го дотнета (и то еще не отказался, т.к. мы поставляем прямо сейчас еще под 5-й и под 3-й .Net Core, но мысленно уже попрощался), т.е. где речь о самых что ни на есть базовых вещах... О чём тут можно рассуждать?..

С высоты птичьего полёта дотнет выглядит нелюбимым ребенком, которым занимались все годы по остаточному принципу.
И рыпаешься ты со своей демагогией именно против этого факта, защитничек хренов.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>>>В том же C# не могу, даже при небольшом изменении в одном месте часто приходит наворачивать круги по всему проекту.
НС>>>Непонятно. Зачем?
V>>Что зачем?
НС>Наворачивать круги по проекту.

Где ломающие изменения себя проявляют.


V>>Тебе то же самое приходится делать при внесении ломающих компилябельность изменений.
НС>Нет.

А что? ))

Здравствуйте, Ikemefula, Вы писали:

I>Ты кофе на спиртовке варишь чтоли или на примусе?

Да, вдогонку.
Съезди хотя бы раз в Стамбул, поброди по барам/кофейням.
Обрати внимание, что чаша с песком там обычно довольно-таки большая, я бы дал площадь в среднем вдвое больше обычных наших.

Я так думаю, что это опять же историческое — еще не так давно песок под кофе грели на дровянной мини-печке.
А печь не способна на манер электричества или газа давать постоянную мощность нагрева.
Банально подбросил дровеняку — мощность нагрева сначала резко падает, потом постепенно увеличивается.

Песок в этом смысле служит еще инерционной массой для уменьшения колебания температуры.

Опять же, когда в чаше с песком независимо готовят несколько порций, то чем больше объём песка, тем меньше влияние опущенной новой холодной турки в песок на "соседей".

Здравствуйте, vdimas, Вы писали:

НС>>>>Непонятно. Зачем?
V>>>Что зачем?
НС>>Наворачивать круги по проекту.
V>Где ломающие изменения себя проявляют.

Все равно не понимаю что ты имеешь в виду.

Здравствуйте, vdimas, Вы писали:

V>Да пофик.
V>Покуда в TS можно куда угодно протащить какой угодно тип, вопреки аннотациям типа или через ошибку аннотации типа — это не имеет особого значения.

Покажи пример.

V>Т.е., ответственность всё еще лежит на человеке, а не на инструменте.

Ровно то же самое в проектах на С/С++, — когда люди злоупотребляют приведением типа указателя, reinterpret cast и тд.

В тайпскрипте достаточно минимальных правил — запретить implicit any, это на уровне компилятора, и ограничить приведение к any на уровне команды, делается через code review.

I>> — автору не хватает тайпингов, а имеющиеся добавляют проблем. Проблема решена.
V>Не решена.

Покажи пример.

I>> — типы добавляют проблем. Проблема решена.

V>Не решена.

Покажи пример.

Здравствуйте, vdimas, Вы писали:

I>>Теперь про кофе, ржом вместе в голос:
I>>Вот твой опыт с туркой:
I>>

I>>"Вручную сваренный" — это в латунной турке на песке?
I>>И где крепость кофе примерно в 10 раз выше традиционной, что к порции кофе подают бокал прохладной воды, бо рези в желудке могут появить даже у абсолютно здорового человека?

I>>Трудно понять, где же ты нарвался на такой шмурдяк. Логичнее предположить, что этот аргумент высосан из пальца.

V>Это классический рецепт в турке, которому, рецепту, уже несколько веков.

Неоткуда там взяться "в 10 раз выше", если не следовать твоим "кипятить полчаса 7-8 раз". Ни разу не было недомогания после турки. Даже когда у меня был гастрит, никакой рези не возникало.

I>>Вот снова подробности про турку:
I>>

I>>1. Одна турка способна выдать одну порцию кофе примерно раз в 15-20 минут, а их редко бывает больше одной в таких заведениях.

I>>Черепаха-бариста?

V>Это так и есть.

На самом деле — не больше 5 минут.

I>>А вот твоя реакция на "свежеобжареный кофе"
V>Это разъяснение, почему аргумент про "свежеобжареный кофе" — бред.

Вероятно, ты не в курсе, что это значит.

V>Несвежеобжаренного кофе, считай, не существует в кофейнях.

Наоборот. Полно мест, где кофе обжарен неизвестно когда. Например, огромные пакеты с кофе типа Лаваццы, стоят месяцами и даже годами. Типичный пример — автоматы в ресторанах, отелях, те самые вокзалы, которые ты упомянул и тд. Типичная палитра такого кофе — пустой, песочный вкус, в лучшем случае, в худшем — кисло-горький, с таким же послевкусием.

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

Можешь изыскать в Москве, скажем, такой https://theweldercatherine.ru/

V>Но при этом зерна не обжаривают с 0-ля, а разогревают или совсем чуток дообжаривают уже обжаренные, такова практика.

Так делали в 90х, когда плохое зерно давало никакой вкус — пачку перед засыпкой в кофемолку прогревали на сковороде.
Сейчас так делают для тех самых зерен, которые месяцами валяются на полках.

I>>Похоже, что ты фантазировал прямо по ходу.
V>Это был ликбез.

А ты, упорный

I>>Далее, уникальный рецепт заваривания в турке от Vdimas
I>>

I>>По технологии, кофе в турке доводится до кипения 7-8 раз, т.е. бармен 7-8 раз приподнимает турку над песком,

V>Это классический рецепт кофе в турке.

Такое я видел только на кухне да по пьяне. В кофейнях турку снимают в тот момент, когда пенка подымается до верху.

I>>Вот еще:
I>>

I>>Де-факто, характерную горечь кофе в турке приобретает уже после первого закипания, но по классическому восточному рецепту уровень горечи доводят в таком кофе до абсурда.

I>>Где же ты пил такой шмурдяк?

V>В традиционных кофейных странах и у нас, когда заказываешь кофе по-восточному в нормальных кофейнях

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

I>>Я вот ни разу не нарывался на горький кофе в турке. Ну вот ни разу.
V>При том что горечь появляется уже после первого поднятия пены.

У меня горечь в кофе указывает на шмурдяк. Второй раз я туда не пойду.

I>>Здесь, похоже, не помогли ни ссылки, ни фото — vdimas знает лучше

V>Эспрессо — это кофе из автомата.
V>Даже если бармен вручную ставит и снимает воронку.

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

I>>Видео с Мариной Хюппёнен не помогли, vdimas знает лучше

V>Да, я знаю лучше.

Её кофе я пробовал, и там никакой горечи, при том, что вкус насыщеный. А вот у тебя "нормальная кофейня" это "горечь до абсурда"
Похоже, ты лучше знаешь как варить "шмурдяк", только почему то называешь это кофиём.

V>Слова Марины, что если "пена поднялась, то этого достаточно" — тупой развод на ровном месте.

Её то не надо доводить горечь до абсурда. И никому, кроме тебя, это тоже не нужно.

Здравствуйте, Ikemefula, Вы писали:

I>Неоткуда там взяться "в 10 раз выше", если не следовать твоим "кипятить полчаса 7-8 раз".

Откуда ты взял "кипятить пол-часа"?


I>>>Черепаха-бариста?
V>>Это так и есть.
I>На самом деле — не больше 5 минут.

Развод.
Перегретый песок, турку закапывают глубоко, подсыпают в песок соль и т.д.


I>>>А вот твоя реакция на "свежеобжареный кофе"
V>>Это разъяснение, почему аргумент про "свежеобжареный кофе" — бред.
I>Вероятно, ты не в курсе, что это значит.

Вероятно, ты уже не знаешь что из пальца насосать.


V>>Несвежеобжаренного кофе, считай, не существует в кофейнях.
I>Наоборот. Полно мест, где кофе обжарен неизвестно когда.

Может у вас и полно, ХЗ.
Но вообще это невероятный сценарий, чтобы администраторы точки закупали зерна на несколько месяцев вперед.
А главное — смысл?
Поставщики кофе всегда под боком, сами делают доставку по точкам, какие проблемы?


I>Типичный пример — автоматы в ресторанах, отелях, те самые вокзалы, которые ты упомянул и тд.

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


I>Типичная палитра такого кофе — пустой, песочный вкус, в лучшем случае, в худшем — кисло-горький, с таким же послевкусием.

Бла-бла-бла.
Это наверно совсем совсем б/у оборудование? ))

Современные автоматы дают вполне обычный эспрессо, который не уступает оному из автомата в специализированной кофейне.
Там банально те же запчасти используются, как в современных т.н. "суперавтоматах".
А не суперавтоматов даже для специализированных для кофеен у ведущих поставщиков уже не осталось (кроме многорожковых вариантов), ссылки я тебе приводил.

И да, не современных автоматов у нас, например, и не бывает, бо живут эти автоматы не слишком долго.
И б/у автоматы у нас тоже давно никто не покупает, бо смысла нет, т.к. соотношение стоимости ремонта/обслуживания и остальных затрат на содержание автомата в РФ малость другое, чем в РБ, т.е. б/у банально не выгодно.
Такие как у вас сейчас времена прошли в РФ уже давно.


I>В отличие от этого свежеобжареный это как правило от местного обжарщика, которы привозит заказ "с сегодня на завтра". И такой кофе обжарен самое худшее, это в прошлом месяце.

Зная тебя, ты обычно не можешь "проехать" ту инфу, которой вот только овладел в процессе обсуждения.
И теперь снова и снова пытаешься показать, что ты это "и так знал".

Расслабься уже.
Как я тебя понял — уже пояснил.
Даже если ты до этого был не в курсе про временные рамки "свежеобжаренности" — да похер, проехали.


I>Можешь изыскать в Москве, скажем, такой https://theweldercatherine.ru/

Контакты:

Фактический адрес: 111141 г. Москва, ул. Плеханова дом 17, помещение П

Опять что-то попутал?
Бывает...


V>>Но при этом зерна не обжаривают с 0-ля, а разогревают или совсем чуток дообжаривают уже обжаренные, такова практика.
I>Так делали в 90х

Так и у вас будут делать лет через 5-7, когда дорастёте.
Когда в кофейни будут ломиться не потому что экзотика и еще не перепробовали стотыщ сортов и рефептов кофе, а когда просто нет идеи, куда бы зайти-посидеть.
Т.е. рост кривой популярности кофеен должен войти в насыщение.
Судя по твоим впечатлениям — у вас до насыщения еще далеко. ))
Я помню подобный период у нас примерно в 13-14-е года последний раз.


I>когда плохое зерно давало никакой вкус — пачку перед засыпкой в кофемолку прогревали на сковороде.

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


I>Сейчас так делают для тех самых зерен, которые месяцами валяются на полках.

Бгг, дообжарка делает их еще хуже.


I>В кофейнях турку снимают в тот момент, когда пенка подымается до верху.

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


I>>>Вот еще:
I>>>Де-факто, характерную горечь кофе в турке приобретает уже после первого закипания, но по классическому восточному рецепту уровень горечи доводят в таком кофе до абсурда.
I>>>Где же ты пил такой шмурдяк?
V>>В традиционных кофейных странах и у нас, когда заказываешь кофе по-восточному в нормальных кофейнях
I>Не совсем понятно как уживаются вместе "горечь до абсурда" и "нормальная кофейня"

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

"Быстро" сваренный кофе мелкого помола несильно будет отличаться по вкусу от эспрессо, разве что привкус неосевшего осадка добавляет "изюминки", но это шмурдяк и есть.
Тогда уж лучше через френч-пресс.

Вот всё что я тебе рассказывал и показывал про коническую форму турки и её глубину закапывания — оно служит для удержания осадка в районе дна.
И это в любом случае не работает с помолом в пыль.
И время заваривания напрямую зависит от размера фракции помола, ес-но.
В трёх соснах заблудился, смотрю? ))


I>Похоже, в твоём разумении нормальные кофейни это те, что шмурдяк готовят.

Аборигенов на краю цивилизации тоже можно приучить к какому угодно "кофе", потом дать им сваренный по другому рецепту и он будет рвать на себе рубаху "это неправильный кофе!!!111".
Вот суть нашего спора.


V>>Эспрессо — это кофе из автомата.
V>>Даже если бармен вручную ставит и снимает воронку.
I>Автомат делает все шаги самостоятельно

Поэтому не ошибается.


I>А обычно бариста контролирует и помол, и тамперовку, и выдерживает время пролива.

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


V>>Да, я знаю лучше.
I>Её кофе я пробовал, и там никакой горечи, при том, что вкус насыщеный.

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


I>А вот у тебя "нормальная кофейня" это "горечь до абсурда"

Это мои субъективные ощущения от классического кофе по-восточному.
К которому большой стакан воду внагрузку дают.
Марина почему-то такой стакан внагрузку не даёт.
Значит, это рецепт для турок в точках быстрого питания.

Т.е., берётся классический антураж заваривания в турке, сверху накладывается неумолимая "экономическая целесообразность" — получи насосанный из пальца новый рецепт, подаваемый с умным видом за старый.
Европейцы, чо! ))


I>Похоже, ты лучше знаешь как варить "шмурдяк", только почему то называешь это кофиём.

Аборигены продолжают рвать на себе рубаху.

Вас тупо разводят.
Банально насильно "приучают" к тем рецептам кофе, которые выгодны поставщикам.

Здравствуйте, vdimas, Вы писали:

I>>Неоткуда там взяться "в 10 раз выше", если не следовать твоим "кипятить полчаса 7-8 раз".

V>Откуда ты взял "кипятить пол-часа"?

Это насмешка.

V>Развод.
V>Перегретый песок, турку закапывают глубоко, подсыпают в песок соль и т.д.

Тебе пора на чемпионат.

V>>>Несвежеобжаренного кофе, считай, не существует в кофейнях.
I>>Наоборот. Полно мест, где кофе обжарен неизвестно когда.

V>Может у вас и полно, ХЗ.

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

V>Но вообще это невероятный сценарий, чтобы администраторы точки закупали зерна на несколько месяцев вперед.
V>А главное — смысл?

Падяшэуле.

V>Поставщики кофе всегда под боком, сами делают доставку по точкам, какие проблемы?

Такая логистика, если кофе не местный. Лаваццы и к ним приравненые в норме лежат на полках месяцами у тех самых поставщиков.

А вот у местных обжарщиков ни разу не видел лежалого кофе, больше 2х месяцев.

I>>Типичный пример — автоматы в ресторанах, отелях, те самые вокзалы, которые ты упомянул и тд.

V>Бгг...
V>Такие автоматы заправляют порой несколько раз в сутки, бо содержимое лотков быстро заканчивается.

Вероятно, это ваша специфика. У нас эти автоматы почти исчезли,


I>>Типичная палитра такого кофе — пустой, песочный вкус, в лучшем случае, в худшем — кисло-горький, с таким же послевкусием.

V>Бла-бла-бла.
V>Это наверно совсем совсем б/у оборудование? ))

Там, где кофе лежалый, на оборудование денег нет. Очевидно же — раз лежит и выдыхается, значит трафик близок к нулю.

Оно и ясно — за углом варят свежий.

V>Современные автоматы дают вполне обычный эспрессо, который не уступает оному из автомата в специализированной кофейне.

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

V>И да, не современных автоматов у нас, например, и не бывает, бо живут эти автоматы не слишком долго.

Вот тебе и объяснение, почему они уступили место эспрессо-машине с выделеным баристой. Автомат не выдерживает большой трафик. Забивается, засоряется, закисает, трудно чистить, помол трудно настроить. В итоге кофе уже через пару месяцев превращается в шмурдяк.

В норме в кофейнях помол подстраивается регулярно. С автоматом это невозможный номер — это просто некому делать. Звать обслугу на каждый пакет никто не будет.

V>Зная тебя, ты обычно не можешь "проехать" ту инфу, которой вот только овладел в процессе обсуждения.
V>И теперь снова и снова пытаешься показать, что ты это "и так знал".

Похоже, ты про себя пишешь. Я кофе пью уже лет двадцать из них 7 это считай один только эспрессо.

V>Расслабься уже.
V>Как я тебя понял — уже пояснил.

Элементарно — по себе судишь.


I>>Можешь изыскать в Москве, скажем, такой https://theweldercatherine.ru/

V>Контакты:
V>

V>Фактический адрес: 111141 г. Москва, ул. Плеханова дом 17, помещение П

V>Опять что-то попутал?
V>Бывает...

Похоже, такой специалист как ты, не в курсе про Сварщицу Екатерину

I>>Так делали в 90х

V>В кофейнях быстрого обслуживания, про которые ты говоришь, никакой доожарки или разогреве при клиенте никогда не будет.
V>Это ты сейчас из пальца объяснения насасываешь.

Это же ты про разогрев вещаешь, забыл?

I>>Сейчас так делают для тех самых зерен, которые месяцами валяются на полках.

V>Бгг, дообжарка делает их еще хуже.

Не дообжарка, а разогрев. Это способ оживить дохло е зерно.

V>Значит используют кофе мелкого помола, других вариантов нет.

Именно — турка это самый мелкий помол.

V>Это классическая "точка быстрого питания", значит пьешь кофе с гущей. ))

В турке это норма, гуща прямо в чашке. Когда помол мелкий, оседает хорошо, и не подымается.

I>>Не совсем понятно как уживаются вместе "горечь до абсурда" и "нормальная кофейня"

V>Я ж про свой вкус говорю.
V>А я не особый любитель кофе, разве что под настроение.

То есть, пишешь абы что, не владея вопросом. ЧТД.

V>"Быстро" сваренный кофе мелкого помола несильно будет отличаться по вкусу от эспрессо, разве что привкус неосевшего осадка добавляет "изюминки", но это шмурдяк и есть

Наоборот — нисколько не похож на эспрессо. А вот шмурдяк из автомата похож на шмурдяк из турки
О чем и речь — ты все время про шмурдяк пишешь.

I>>Автомат делает все шаги самостоятельно

V>Поэтому не ошибается.

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


V>Поэтому ошибается.
V>А кол-во воды и соотв. время её прохождения всё-равно автомат сам контоллирует, даже если рожок ручной.

Ога. Пролив в большинстве случаев выключается вручную.


V>Т.е. программа точно так же задаётся нажатием кнопок.


Ты ухитряешься во всех вопросах кофе ошибаться на 180 градусов.

I>>Её кофе я пробовал, и там никакой горечи, при том, что вкус насыщеный.

V>Но я такой заведомо пить не буду после первого же глотка.

Да я понял про твой выбор. У меня такое проходит по графе "шмурдяк"

I>>А вот у тебя "нормальная кофейня" это "горечь до абсурда"

V>Это мои субъективные ощущения от классического кофе по-восточному.
V>К которому большой стакан воду внагрузку дают.
V>Марина почему-то такой стакан внагрузку не даёт.

А теперь мы выяснили, что ты видео не смотрел.
То есть, высасываешь прямо ищ пальца по ходу беседы.
Браво — ты таки сам себя раскрыл, уже дважды в одном сообщении