Здравствуйте, IT, Вы писали:
IT>Т.е. это просто структурка?
Да. Объектом я ее совершенно некорректно "обозвал". Погорячился.
IT>Вот это тоже интересно, как организовать кешь в данном примере.
Есть результат некоторого запроса, его вобщем-то можно где-то держать
при желании (точнее при необходимости (точнее, если это поможет в увеличении
производительности)). Другое дело, что инвалидироваться кэш подобных
структурок будет очень быстро — при добавлении/удалении любого сообщения,
так что кэшировать их — себе дороже, не пересчитывать же их в памяти .
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, kreek, Вы писали:
K>>Только вот как явно задекларировать эти случаи. Имхо, подходит только для метаданных, для реальных бизнес объектов очень тяжело поддерживать кэш.
ГВ>Что ты имеешь ввиду под "задекларировать" и "поддерживать"?
Под первым: В настройках системы указывать о необходимости кэширования экземпляров конкретного типа или сервер со своим супер интелектуальным механизмом сам будет определять какие именно сущности надо кэшировать (причем тип безразличен, допустим все наследники от базового BusinessObject)?
Под вторым проблема, описанная ниже.
K>>А если будет несколько серверов приложений, и не как элементы кластера, а как полноценные сервера (допустим на каждую географическую точку по серверу), то, что, ГВ>при изменении кэшируемого объекта в одном — оповещать другие?
ГВ>Можно и так, если очень хочется. Хотя лучше, наверное, пользоваться репликацией.
Я забыл сказать, что БД у них одна!!! Или такое не практикуется, с одной базой и несколько серверов приложений?
Представляю чем может закончиться такого рода оповещения, если серверов эдак 15.
K>>А одним селектом для всей группы обойтись нельзя? И притом insert/update в пакетном режиме невозможен, все равно каждый раз процедуру вызывать придется.
ГВ>Зато insert/update возможны в фоновом режиме.
Не вижу связи.
K>>Под пулом, наверное, подразумеваешь объекты не заполненные данными?
ГВ>Не совсем. Под пулом я подразумеваю наборы неиспользуемых объектов.
Здравствуйте, kreek, Вы писали:
K>Под первым: В настройках системы указывать о необходимости кэширования экземпляров конкретного типа или сервер со своим супер интелектуальным механизмом сам будет определять какие именно сущности надо кэшировать (причем тип безразличен, допустим все наследники от базового BusinessObject)?
Все так, только не в настройках системы, а в настройках конкретного приложения.
ГВ>>Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий. От неё потянутся "хвосты" на мэппинг. Другая задача — перезагрузка объектов "на лету" (понадобится для случая сервера, работающего в режиме 24x7).
IT>stateless, только stateless.
Вот тут много говорилось об объектных моделях.
А как народ относится к message-based системам?
Т.е. все взаимодействие происходит при помощи сообщений.
Но здесь сообщение — это не вызов метода объекта.
Это скорее некий документ определенной структуры.
И есть набор классов — менеджеров, которые знают, как обрабатываеть определенные типы сообщений.
Эти классы stateless.
Здравствуйте, DMVB, Вы писали:
DMV>А как народ относится к message-based системам?
Хорошо относится. В том, что мне приходилось "строить", похожие схемы использовались
для того, чтобы определять последовательность действий над разными объектами со стороны
"классов-менеджеров".
Удобна такая схема в том числе тем, что всегда можно просто перестроить "потоки"
объектов (т.е. сформировать связи между обработчиками) меняя описание схемы,
расположенной, например, в той же базе данных.
Сюда же можно навернуть разные приоритеты, очереди, фильтры и т.п.
Как бы продолжая свою тему и пытаясь все-таки определится с вопросом "Начем и как писать трехзвенку" — хочу предложить Вам господа (особенно тем кто принимал самое активное участие в обсуждении — (псхпп IT, AndrewVK, ГВ) высказать свое мнение о статьях находящихся по адресу : http://russian.joelonsoftware.com/index.html. Вернее не сколько о статьях, сколько о ваших утверждениях ранее высказанных в этом топике, и о том как они пересекаются с мнением автора статей.
Здравствуйте, mvg_first, Вы писали:
MF>http://russian.joelonsoftware.com/index.html. Вернее не сколько о статьях, сколько о ваших утверждениях ранее высказанных в этом топике, и о том как они пересекаются с мнением автора статей.
Вы построили восхитительный замок, но слегка облажались где-то в районе фундамента. Вместо бетонных блоков там оказался какой-то мусор. Дворец выглядит замечательно, только ванна иногда отъезжает в сторону, и непонятно, почему.
Если вы не ведёте огонь, враг ведёт огонь по вам, вынуждая вас залечь.
И это:
Люди начинают волноваться по поводу .NET и решают полностью переделать архитектуру под .NET, потому что они думают, что они вынуждены это сделать. Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия(выделено мной — ГВ.) для того чтобы они могли двигаться вперёд, а вы нет.
И остальные рассуждения тоже неплОхи.
MF>ТОЛЬКО ПОЖАЛУЙСТА поймите меня правильно, я не хочу в обсуждении этого топика разжечь очередную "священную войну".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да, её и не будет, не переживай.
ГВ>Почитай ещё Программистский камень.
Да я ее еще год назад выкачал, но никак приступить немогу — нехватка времени
Здравствуйте, kreek, Вы писали:
ГВ>>Что ты имеешь ввиду под "задекларировать" и "поддерживать"?
K>Под первым: В настройках системы указывать о необходимости кэширования экземпляров конкретного типа или сервер со своим супер интелектуальным механизмом сам будет определять какие именно сущности надо кэшировать (причем тип безразличен, допустим все наследники от базового BusinessObject)?
Угу, именно, что "или сервер...", поскольку по идее кэшировать нужно все persistable-сущности. А основная проблема — не что кэшировать, а как кэшировать.
Пользователь (администратор) должен только управлять параметрами кэширования. Конкретная структура параметров зависит от того, что именно можно регулировать в твоём кэше — min время удержания, объём кэша, max количество зарезервированных экземпляров одно типа и т.п. Исходная информация для администратора — статистика, собираемая App-сервером.
K>Под вторым проблема, описанная ниже.
K>>>А если будет несколько серверов приложений, и не как элементы кластера, а как полноценные сервера (допустим на каждую географическую точку по серверу), то, что, ГВ>>при изменении кэшируемого объекта в одном — оповещать другие?
ГВ>>Можно и так, если очень хочется. Хотя лучше, наверное, пользоваться репликацией.
K>Я забыл сказать, что БД у них одна!!! Или такое не практикуется, с одной базой и несколько серверов приложений? K>Представляю чем может закончиться такого рода оповещения, если серверов эдак 15.
Такая организация нецелесообразна сама по себе. Данные могут быть в одной БД, но тогда удалённым пользователям не нужны App-серверы на их машинах, а нужны тонкие клиенты. Зачем становиться с ног на голову?
K>>>А одним селектом для всей группы обойтись нельзя? И притом insert/update в пакетном режиме невозможен, все равно каждый раз процедуру вызывать придется.
ГВ>>Зато insert/update возможны в фоновом режиме.
K>Не вижу связи.
Связь очень простая — по крайней мере update (при грамотном кешировании и синхронизации) может быть выполнен несколько раз в памяти ни разу не попав при этом в БД. Вернее — попадёт только результат последнего update. Такая схема накладывает, конечно, определённые требования, например, на питание узлов с App-серверами, но позволяет в некоторых случаях избежать проведения серии update-ов одних и тех же записей в БД. Точно также insert может быть "перехвачен" последующим delete-ом вовсе не достигнув при этом БД.
Во-вторых, можно передать серверу группу заданий на обновление одним сеансом, что позволит сэкономить на некотором оверхэде, привносимым тем же ADO.
Хотя на самом деле в реальных условиях время, затрачиваемое на модификации БД существенно меньше всяческих select-ов.
K>>>Под пулом, наверное, подразумеваешь объекты не заполненные данными?
ГВ>>Не совсем. Под пулом я подразумеваю наборы неиспользуемых объектов.
K>Тогда это кэш. Правильно понял?
Нет, не совсем. Кэш (Cache) — это обобщённое название программного (в нашем случае) механизма, выполняющего буферизацию данных. Цель кэширования (и кэша) — снижние издержек на обращения к БД. Пул (Pool) — это один из способов организации хранения неиспользуемых, но уже сконструированных объектов (например, под которые уже выделена память операцией new). Очередь (Queue) — это способ упорядочения доступа в частности, к пулу объектов. Вот и всё. Смешивать понятия здесь не совсем правомерно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Угу, именно, что "или сервер...", поскольку по идее кэшировать нужно все persistable-сущности.
Тут идея простая
1) Stateless — пул
2) Stateful — не трогать
3) Entity — кеш с контролем уникальности
ГВ>Хотя на самом деле в реальных условиях время, затрачиваемое на модификации БД существенно меньше всяческих select-ов.
А если еще вспомнить что очень часто нужна еще связь по данным со старыми системами то получается что запись лучше не кешировать, а писать сразу. Единственное что здесь нужно — дать возможность групповых операций. Т.е. перед началом модификации вызываем BeginUpdate, все изменения фиксируются в контексте, но в базу не пишутся, а по EndUpdate они скопом сваливаются в базу. Но здесь уже нужна поддержка транзакций именно со стороны сервера приложений. Т.е. при изменении внутри группового апдейта какого либо объекта нужно его сериализовать в специальный лог, а при исключении все изменения откатывать.
ГВ>>>Можно и так, если очень хочется. Хотя лучше, наверное, пользоваться репликацией.
K>>Я забыл сказать, что БД у них одна!!! Или такое не практикуется, с одной базой и несколько серверов приложений? K>>Представляю чем может закончиться такого рода оповещения, если серверов эдак 15.
ГВ>Такая организация нецелесообразна сама по себе. Данные могут быть в одной БД, но тогда удалённым пользователям не нужны App-серверы на их машинах, а нужны тонкие клиенты. Зачем становиться с ног на голову?
???
Ничего не понимаю.
Зачем вообще ПОЛЬЗОВАТЕЛЯМ НА ИХ МАШИНАХ App-сервера?
Разве кто-то предлагал такое?
Здравствуйте, DMVB, Вы писали:
ГВ>>>>Можно и так, если очень хочется. Хотя лучше, наверное, пользоваться репликацией.
K>>>Я забыл сказать, что БД у них одна!!! Или такое не практикуется, с одной базой и несколько серверов приложений? K>>>Представляю чем может закончиться такого рода оповещения, если серверов эдак 15. ГВ>>Такая организация нецелесообразна сама по себе. Данные могут быть в одной БД, но тогда удалённым пользователям не нужны App-серверы на их машинах, а нужны тонкие клиенты. Зачем становиться с ног на голову?
DMV>??? DMV>Ничего не понимаю. DMV>Зачем вообще ПОЛЬЗОВАТЕЛЯМ НА ИХ МАШИНАХ App-сервера? DMV>Разве кто-то предлагал такое?
Kreek как раз и предлагал. ИМХО, удалять App-сервер от БД имеет смысл только ради приближения его к пользователям, но приближать в этом случае нужно и базу данных тоже (см. ниже). А если не приближать ничего, то пользователям нужны тонкие клиенты.
А зачем держать 15 удалённых App-серверов, если узел с базой данных один? Если они кэшируют бОльшую часть обращений к БД, то мы получаем почти что реплицируемые БД (только хуже). А если ещё учесть, что в удалённых точках они всё равно будут останавливаться чаще, чем центральный (сбои по питанию, выключение в конце рабочего дня и проч.), то мы только перегрузим центральный сервер запросами кэшируемых данных, которые будут не то что репликациями, а фактически — дублированием базы. Тут уж лучше репликацияами заниматься.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Тут идея простая AVK>1) Stateless — пул AVK>2) Stateful — не трогать AVK>3) Entity — кеш с контролем уникальности
Тоже вариант. Весь прикол как раз в организации кэширования Entity.
ГВ>>Хотя на самом деле в реальных условиях время, затрачиваемое на модификации БД существенно меньше всяческих select-ов.
AVK>А если еще вспомнить что очень часто нужна еще связь по данным со старыми системами то получается что запись лучше не кешировать, а писать сразу.
Вот уж что да, то есть! Особенно если нужно ещё обеспечить эксплуатацию старой системы одновременно с новой, то...
AVK>Единственное что здесь нужно — дать возможность групповых операций. Т.е. перед началом модификации вызываем BeginUpdate, все изменения фиксируются в контексте, но в базу не пишутся, а по EndUpdate они скопом сваливаются в базу. Но здесь уже нужна поддержка транзакций именно со стороны сервера приложений. Т.е. при изменении внутри группового апдейта какого либо объекта нужно его сериализовать в специальный лог, а при исключении все изменения откатывать.
В принципе согласен. Добавлю только (для mvg_first), что лог в данном случае — это только промежуточное хранилище состояний объектов. В принципе, можно и другой механизм придумать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Тоже вариант. Весь прикол как раз в организации кэширования Entity.
Ну так о том и речь. Но если отказаться от постоянного кеширования по записи то проблем особых нет, а GC позволит кешу работать совместно с его механизмами.
ГВ>В принципе согласен. Добавлю только (для mvg_first), что лог в данном случае — это только промежуточное хранилище состояний объектов. В принципе, можно и другой механизм придумать.
Ну чаще всего в общем то все таки transaction log используют.
Как я понимаю, особенно возбуждающим тебе показался последний абзац.
Всё это вещи, которые заставляют думать о байтах, и они оказывают влияние на архитектурные и стратегические решения, которые мы принимаем. Я придерживаюсь мнения, что студенты, начинающие изучать программирование, должны начинать с начала, использовать C и подниматься вверх от процессора. Мне противно, как часто программа обучения строится на посылке, что Java представляет собой хороший язык для того, чтобы начинать программировать, потому что это так "просто" и не нужно отвлекаться на эти скучные детали про строки и выделение памяти, и сразу можно изучить кульные ООП-штучки которые помогут сделать ваши большие программы так восхитительно модульными. Это педагогический провал. Поколения выпускников снисходят на нас, раскидывая алгоритмы маляра Шлемиэля налево и направо, даже не понимая этого, поскольку у них нет представления о том, что строки на нижнем уровне сложны, даже если из их перлового скрипта этого не видно. Если хочешь научить кого-то хорошо, надо начинать с основ. Как в Karate Kid. Wax On, Wax Off. Wax On, Wax Off. Повторять три недели. После этого Снести Башню Другому Пацану несложно.
Всё правильно, целиком и полностью поддерживаю. Учить в институте надо C++ и байты, и становиться в этом гуру именно там. А на работе нужно применять Java, ну на худой конец .NET , и выдавать на гора рабочий код.
MF>Вторая, добавляет надежд на то что то что я затеваю имеет реальный шанс на выживание — http://russian.joelonsoftware.com/Articles/FireAndMotion.html
Есть такое дело. У меня в конторе даже по серьёзному назревает шуточный проект, называемый "Interruption Management System"
MF>ТОЛЬКО ПОЖАЛУЙСТА поймите меня правильно, я не хочу в обсуждении этого топика разжечь очередную "священную войну".
Надо было написать "Не поймите меня правильно!"
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Мне особенно понравилось вот это:
Вы построили восхитительный замок, но слегка облажались где-то в районе фундамента. Вместо бетонных блоков там оказался какой-то мусор. Дворец выглядит замечательно, только ванна иногда отъезжает в сторону, и непонятно, почему.
Художественно
ГВ>А здесь вот это:
Если вы не ведёте огонь, враг ведёт огонь по вам, вынуждая вас залечь.
Жизненно
ГВ>И это:
Люди начинают волноваться по поводу .NET и решают полностью переделать архитектуру под .NET, потому что они думают, что они вынуждены это сделать. Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия(выделено мной — ГВ.) для того чтобы они могли двигаться вперёд, а вы нет.
Да, чувствуется, что жизнь мужика потрепала и он поправу возглавляет колонну идущих на х.., простите, в даль, и орущих Микрасофт — масдай, при этом используя единственно доступный аргумент — спакуха, пацаны, я знаю, я там работал
BTW, на самом деле, действительно интересно, где он не сошёлся со своими менеджерами? Ведь как бы там абстрактно не говорили об MS, там всё же работают люди, которые собственно и принимают решения типа Сан козлы, Спольски свободен, .NETу быть.
ГВ>И остальные рассуждения тоже неплОхи.
Ну да, в том же ключе
MF>>ТОЛЬКО ПОЖАЛУЙСТА поймите меня правильно, я не хочу в обсуждении этого топика разжечь очередную "священную войну".
ГВ>Да, её и не будет, не переживай.
NO WAY NEVER
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А основная проблема — не что кэшировать, а как кэшировать.
Очень верное замечание. Я бы ещё добавил — где кешировать.
ГВ>Пользователь (администратор) должен только управлять параметрами кэширования. Конкретная структура параметров зависит от того, что именно можно регулировать в твоём кэше — min время удержания, объём кэша, max количество зарезервированных экземпляров одно типа и т.п. Исходная информация для администратора — статистика, собираемая App-сервером.
Кроме развитых средств кешировния тут нужны ещё и развитые средства статистики, мониторинга и администрировния. И всё в одном флаконе.
ГВ>Такая организация нецелесообразна сама по себе. Данные могут быть в одной БД, но тогда удалённым пользователям не нужны App-серверы на их машинах, а нужны тонкие клиенты. Зачем становиться с ног на голову?
Правильно, давайте не будем о репликации, как об обслютном мировом зле
ГВ>Связь очень простая — по крайней мере update (при грамотном кешировании и синхронизации) может быть выполнен несколько раз в памяти ни разу не попав при этом в БД. Вернее — попадёт только результат последнего update. Такая схема накладывает, конечно, определённые требования, например, на питание узлов с App-серверами, но позволяет в некоторых случаях избежать проведения серии update-ов одних и тех же записей в БД. Точно также insert может быть "перехвачен" последующим delete-ом вовсе не достигнув при этом БД.
MS SQL Server team отдыхает. Нет ничего проще, чем написать свой апп-сервер, который как бык овцу покрывает все возможности любого SQL сервера
ГВ>Во-вторых, можно передать серверу группу заданий на обновление одним сеансом, что позволит сэкономить на некотором оверхэде, привносимым тем же ADO.
ГВ>Хотя на самом деле в реальных условиях время, затрачиваемое на модификации БД существенно меньше всяческих select-ов.
А вот это совершенно правильное утверждение.
ГВ>Нет, не совсем. Кэш (Cache) — это обобщённое название программного (в нашем случае) механизма, выполняющего буферизацию данных. Цель кэширования (и кэша) — снижние издержек на обращения к БД. Пул (Pool) — это один из способов организации хранения неиспользуемых, но уже сконструированных объектов (например, под которые уже выделена память операцией new). Очередь (Queue) — это способ упорядочения доступа в частности, к пулу объектов. Вот и всё. Смешивать понятия здесь не совсем правомерно.
Кеши бывают разные. Иногда диаметрально противоположные.
С одной стороны, при изменении данных наиболее эффективно организовать кеш поближе к базе данных. А лучше прямо в ней самой, в крайнем случае в специально организованном для этого слое. При этом чем меньше известно об этих данных, тем лучше. Наилучшим примером является кеш самих серверов, соревноваться с которым по эффективности врядли может любой самый навороченный сервер приложений.
С другой стороны, MS SQL Server Team опять отдыхает, когда в дело вступает MSIE со своим кешем HTML страниц на клиенте. В данном случае данные уже не просто считаны из хранилища, но уже и преобразованы в потребный для клиента вид, считаны с сервера, распарсены и в любой момент готовы к потреблению.
Т.е. чем более кеш предполагает абстакцию, тем ближе он должен распологаться к хранилищу. Кеширование же уже ранее подготовленных данных, тем эффективнее, чем оно ближе к клиенту.
Истина, как обычно где-то... не то чтобы по середине, а скорее всего в разных, порой совершенно непредсказуемых местах
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Кроме развитых средств кешировния тут нужны ещё и развитые средства статистики, мониторинга и администрировния. И всё в одном флаконе.
Абсолютно верное замечание, именно поэтому, в частности, рискованно закладываться на механизмы сбора статистики, предусмотренные в той или ной базовой ОС.
ГВ>>Такая организация нецелесообразна сама по себе. Данные могут быть в одной БД, но тогда удалённым пользователям не нужны App-серверы на их машинах, а нужны тонкие клиенты. Зачем становиться с ног на голову?
IT>Правильно, давайте не будем о репликации, как об обслютном мировом зле
Кто говорил, что это АМЗ? Тело в студию!
IT>MS SQL Server team отдыхает. Нет ничего проще, чем написать свой апп-сервер, который как бык овцу покрывает все возможности любого SQL сервера
Небольшое замечание "по существу". Бык покрывает коров (иногда — священных), овец же покрывают бараны, а App-серверы так вообще бывают бывают разными. IT, прости мне мою иронию.
IT>Т.е. чем более кеш предполагает абстакцию, тем ближе он должен распологаться к хранилищу. Кеширование же уже ранее подготовленных данных, тем эффективнее, чем оно ближе к клиенту.
Что значит "абстракция" и "подготовка данных"? Абстракция чего? Подготовка данных для чего?
IT>Истина, как обычно где-то... не то чтобы по середине, а скорее всего в разных, порой совершенно непредсказуемых местах
Вот уж, с чем согласен, так согласен.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
IT>Да, чувствуется, что жизнь мужика потрепала и он поправу возглавляет колонну идущих на х.., простите, в даль, и орущих Микрасофт — масдай, при этом используя единственно доступный аргумент — спакуха, пацаны, я знаю, я там работал
Какой штиль! А всего-то — человек посмел адекватно оценить действия MS.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
.
Хотя лучше, наверное, пользоваться репликацией.
Если они кэшируют бОльшую часть обращений к БД, то мы получаем почти что реплицируемые БД (только хуже). А если ещё учесть, что в удалённых точках они всё равно будут останавливаться чаще, чем центральный (сбои по питанию, выключение в конце рабочего дня и проч.), то мы только перегрузим центральный сервер запросами кэшируемых данных, которые будут не то что репликациями, а фактически — дублированием базы. Тут уж лучше репликацияами заниматься. 
, и выдавать на гора рабочий код.
Если нам не помогут, то мы тоже никого не пощадим.
NEVER
IT, прости мне мою иронию. 
