Делаю небольшую платформу, для работы с Бизнес-объектами, полученных из базы данных. Особенностью платформы является то, что она все объекты загружает только один раз по мере необходимости и сохраняет их в памяти. Впоследствии, если приложению снова нужен тот или иной объект, он уже не подымается из базы, а находится в памяти. Естественно, что есть механизм, который отслеживает изменения объектов. Также это удобно тем, что есть дополнительные механизмы, которые следят, чтобы в системе находился только один экземпляр объекта. Это очень полезно при байдинге. Можно забайдить список бизнес объектов к контролу (а также фильтрованные или сортированные списки к другим контролам) и по мере изменения объектов (даже другими пользователями из других систем) все они автоматически будут обновляться и изменяться во всех списках.

С одной стороны это хорошо. Сначала пользователь просмотрел список студентов, например, и пролистал 100 000 строк в списке. Потом открыл некую форму для выбора студента (для каких-либо целей) и тоже начинает искать в списке нужного студента (если он не пользуется поиском и фильтрами). При втором и последующих разах из базы уже ничего подыматься не будет, все уже будет загружено и, КАК Я ДУМАЮ, объекты будут возвращаться быстрее.

Но с другой стороны, если, например работать с системой 6 часов подряд, то в память может перекочевать довольно солидный кусок БД. Если например база занимает 10 гигабайт, то в памяти может запросто оказаться 6 гигабайт данных. Естественно, большая из них часть будет находиться в свопе. Так вот интересно, в каком случае объекты будут возвращаться быстрее: если возвращать их заново из базы запросом или если система их будет сама искать где-то в свопе на диске?

На самом деле этот подход уже частично реализован. Единственное отличие текущей реализации от вышеописанного заключается в том, что пока нет возможности частично загрузить объекты. При первом обращении, например к объекту «Студент» идет загрузка всех студентов (не важно, Сколько их там – 1000 или 1 000 000) и вся дальнейшая работа происходит из расчета на то, что все студенты уже загружены. Но не такая уж большая проблема докрутить механизм, чтобы можно было загружать объекты одного типа порциями по мере необходимости и потом уже использовать загруженные. Вопрос в том, следует ли дальше развивать такую платформу, насколько она жизненна и на каком классе приложений. Я тестировал текущее реализованный подход на относительно небольшом количестве данных – 10 000 на таблицу при 13-15 таблицах. Работает довольно быстро. На большем количество записей пока не тестировал.
Если на больших базах (свыше 4-ех гигов) такой подход будет неэффективен, то, кто как думает, можно ли его использовать на более маленьких БД (например, если приложение небольшое и не требует большой БД). То есть возможно ли применение на практике этой платформы вообще или идея изначально ошибочна?

Буду благодарен за любые комментарии по поводу подхода, избранного в платформе.

Аноним 761 wrote:
> Буду благодарен за любые комментарии по поводу подхода, избранного в
> платформе.
>
> 27.10.07 17:40: Перенесено модератором из '.NET' — AndrewVK

Ну, ежели dotnet, то в сторону WeakReferences не смотрели?

Звучит очень похоже на memcached

Здравствуйте, <Аноним>, Вы писали:

А> Делаю небольшую платформу, для работы с Бизнес-объектами, полученных из базы данных. Особенностью платформы является то, что она все объекты загружает только один раз по мере необходимости и сохраняет их в памяти. Впоследствии, если приложению снова нужен тот или иной объект, он уже не подымается из базы, а находится в памяти. Естественно, что есть механизм, который отслеживает изменения объектов. Также это удобно тем, что есть дополнительные механизмы, которые следят, чтобы в системе находился только один экземпляр объекта. Это очень полезно при байдинге. Можно забайдить список бизнес объектов к контролу (а также фильтрованные или сортированные списки к другим контролам) и по мере изменения объектов (даже другими пользователями из других систем) все они автоматически будут обновляться и изменяться во всех списках.

Здравствуйте, Аноним, Вы писали:

А> Делаю небольшую платформу, для работы с Бизнес-объектами, полученных из базы данных. Особенностью платформы является то, что она все объекты загружает только один раз по мере необходимости и сохраняет их в памяти. Впоследствии, если приложению снова нужен тот или иной объект, он уже не подымается из базы, а находится в памяти. Естественно, что есть механизм, который отслеживает изменения объектов. Также это удобно тем, что есть дополнительные механизмы, которые следят, чтобы в системе находился только один экземпляр объекта. Это очень полезно при байдинге. Можно забайдить список бизнес объектов к контролу (а также фильтрованные или сортированные списки к другим контролам) и по мере изменения объектов (даже другими пользователями из других систем) все они автоматически будут обновляться и изменяться во всех списках.

То есть изобретаешь свой O/RM?

Возьми исходники того же NHibernate и посмотри как там организованы два уровня кеширования...

А лучше не тратить время на изобретение очередного O/RM, а взять NHibernate и законтрибьютить что-нибудь полезное в него. Куда больше народу спасибо скажут.

Здравствуйте, Ромашка, Вы писали:

Р>Аноним 761 wrote:
>> Буду благодарен за любые комментарии по поводу подхода, избранного в
>> платформе.
>>
>> 27.10.07 17:40: Перенесено модератором из '.NET' — AndrewVK

Р>Ну, ежели dotnet, то в сторону WeakReferences не смотрели?

А причем тут "слабые ссылки". Их конечно можно использовать (и в одной из версий я их юзал, но потом переделал без них). Это уже детали реализации. Мне интересно, насколько жизненный сам подход? Больше всего мне не хочется — это дублировать функционал сервера БД. Сейчас получается, что все объекты хранятся на локальной машине в памяти и в нужное время синхронизируются с БД, но при этом, при выполнении запроса, он выполняется над БД (со всеми фильтрами, сортировками, и.т.д.) и оттуда возвращаются ID-ки нужных объектов. А уже потом ищутся эти объекты на локальной машине, или если они не обнаружены загружаются из базы уже полностью (а не только ID-ки).
Я вот думаю, может стоить фильтровать непосредственно на клиенте, но как-то жестко по-моему.

Аноним 80 wrote:
> Р>Ну, ежели dotnet, то в сторону WeakReferences не смотрели?
>
> А причем тут "слабые ссылки".

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

> оттуда возвращаются ID-ки нужных объектов. А уже потом ищутся эти
> объекты на локальной машине, или если они не обнаружены загружаются из
> базы уже полностью (а не только ID-ки).

Да уж... В чем смысл этого извращения?

> Я вот думаю, может стоить фильтровать непосредственно на клиенте, но
> как-то жестко по-моему.

Да уш... Месье знает толк в извращениях...

Могу подкинуть пару идей. Выбрасываем БД нафиг. При изменении обьекта в
БД броадкастом шпарим по всем клиентам и пересылаем им измененый обьект.

Здравствуйте, Ромашка, Вы писали:

Р>Аноним 80 wrote:
>> Р>Ну, ежели dotnet, то в сторону WeakReferences не смотрели?
>>
>> А причем тут "слабые ссылки".

Р>При том, что все ваши "удобства" как раз реализовываются безболезненно
Р>именно на слабых ссылках.

А можно немного подробнее?

>> оттуда возвращаются ID-ки нужных объектов. А уже потом ищутся эти
>> объекты на локальной машине, или если они не обнаружены загружаются из
>> базы уже полностью (а не только ID-ки).

Р>Да уж... В чем смысл этого извращения?

Смысл по задумке только в том, что данные не будут по 100 раз загружаться из базы. Они загрузятся только 1 раз, а потом все запросы будут возвращать ID-ки нужных объектов (это для того, чтобы все фильтры и сортировки отрабатывали на СУБД). Если есть ID-ки и списки ранее загруженных объектов (они к тому же отсортированы все по Guid-ам, поэтому поиск идет очень быстро), то легко восстановить список запрашиваемых объектов. Если какие-то объекты не загружены, то они загружаются отдельно. По-моему это будет происходить намного быстрее, чем каждый раз по-новой гурзить все данные из базы. Я не прав?

Р>Да уш... Месье знает толк в извращениях...

Ну это еще не самые жесткие моменты в коде . Например, просто ради интереса, что Вы думаете о наличии некой таблицы измененных данных. То есть по сути получается, что каждая операция (добавления/изменения/удаления) сопровождается записью в эту таблицу, где указывается тип объекта и ID добавленного/измененного/удаленного объекта. Соответственно, есть метод, который обновляет все текущие объекты из этой таблицы.
По-моему получается довольно неплохо. Например, какой-нибудь сотрудник изменил дату рожедния физ. лица, а у другого сотрудника уже был загружен список физицеских лиц. И практически перед любым действием "другого" сотрудника (попытается что-то посмотреть, отредактировать, добваить) произойдет обновление из таблицы измененных объектов. Это приведет к тому, что в уже отображенном списке физ. лиц. просто поменяется автоматически дата рождения у измененного физ.лица (и, к тому же, это справедливо для всех списков, которые содержат этот объект). Я по работе сталкивался с несколькими коммерческими системами. Могу сказать, что они не могли похватстаться такой фишкой. Если данные в список были загружены, то они могут быть изменены только при полной перегрузке.

Р>Могу подкинуть пару идей. Выбрасываем БД нафиг. При изменении обьекта в
Р>БД броадкастом шпарим по всем клиентам и пересылаем им измененый обьект.

Что понимается под броадкастом? БД может сама известить мое приложение, что что-то там изменилось? Как-то давно выяснял этот вопрос — на этом форуме мне сказали, что это нереально. Или имеется ввиду, что должен быть некий сервер приложений, который и будет за это все отвечать? Если это вариант с сервером приложений, то я его откинул уже очень давно, хоть у меня и был прототип такого варианта. Мне не понравилось, что между всеми клиентами с сервером приходилось поддерживать дополнительную связь (я делал через сокеты), чтобы фактичски просто его о чем-то извещать. С таблицей измененных обекътов получается ловчее, по-моему

Здравствуйте, <Аноним>, Вы писали:
А> На самом деле этот подход уже частично реализован. Единственное отличие текущей реализации от вышеописанного заключается в том, что пока нет возможности частично загрузить объекты. При первом обращении, например к объекту «Студент» идет загрузка всех студентов (не важно, Сколько их там – 1000 или 1 000 000) и вся дальнейшая работа происходит из расчета на то, что все студенты уже загружены. Но не такая уж большая проблема докрутить механизм, чтобы можно было загружать объекты одного типа порциями по мере необходимости и потом уже использовать загруженные. Вопрос в том, следует ли дальше развивать такую платформу, насколько она жизненна и на каком классе приложений.
Не стоит. Я принимал участие в реализации этой платформы десять лет назад. Результаты — удручающие.
Основные проблемы:
1. Невыгрузка кэша. Так делать в принципе нельзя. Кэш должен быть ограничен по размеру, иначе его эффективность теряется.
2. Поддержание когерентности кэша. Если у тебя два человека работают над данными, каждый должен видеть актуальную копию. Большой кэш приводит к большим затратам на передачу изменений.

Так что посмотри на существующие ORM решения: всё это реализовано очень давно и не один раз. Во-первых, тебя скорее всего устроит какой-нибудь Hibernate, а во-вторых всегда полезно изучить опыт других в велосипедостроении.

Аноним 761 wrote:
> Р>При том, что все ваши "удобства" как раз реализовываются безболезненно
> Р>именно на слабых ссылках.
>
> А можно немного подробнее?

Проще будьте. Есть обьект, каким-то образом положенный в БД. Есть
запросы, которые возвращают Guid-ы. Берем Guid, лезем в кеш, если обьект
там есть -- тянем из кеша, если нет, то тянем из БД (не забыв положить в
кеш). GB сам следит за использованием обьектов и сам удаляет
неиспользуемые из памяти. То есть шести гигов на локальной машине не
будет, все часто используемые обьекты будут висеть у Вас в памяти. В
принципе, то, что Вы хотели.

> запрашиваемых объектов. Если какие-то объекты не загружены, то они
> загружаются отдельно. По-моему это будет происходить намного быстрее,
> чем каждый раз по-новой гурзить все данные из базы. Я не прав?

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

> Ну это еще не самые жесткие моменты в коде .

Не, я подозревал...

> Например, просто ради
> интереса, что Вы думаете о наличии некой таблицы измененных данных. То
[skip]
> справедливо для всех списков, которые содержат этот объект). Я по работе
> сталкивался с несколькими коммерческими системами. Могу сказать, что они
> не могли похватстаться такой фишкой. Если данные в список были
> загружены, то они могут быть изменены только при полной перегрузке.

Я уже высказывал свою мысль, что месье знает толк в извращениях.

> Что понимается под броадкастом?

Под броадкастом понимается броадкаст. То есть посылка пакета по адресу
255.255.255.255, который будет принят всеми машинами сети (ежели,
конечно, никакой админ их не задавил).

> БД может сама известить мое приложение, что что-то там изменилось?

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

> Как-то давно выяснял этот вопрос — на этом
> форуме мне сказали, что это нереально.

Этот форум (rsdn.db) традиционно не силен в таких вопросах. Я бы, на
Вашем месте, задавал подобные вопросы на sql.ru.

Здравствуйте, Ромашка, Вы писали:

Р>Аноним 761 wrote:
>> Р>При том, что все ваши "удобства" как раз реализовываются безболезненно
>> Р>именно на слабых ссылках.
>>
>> А можно немного подробнее?

Р>Проще будьте. Есть обьект, каким-то образом положенный в БД. Есть
Р>запросы, которые возвращают Guid-ы. Берем Guid, лезем в кеш, если обьект
Р>там есть -- тянем из кеша, если нет, то тянем из БД (не забыв положить в
Р>кеш). GB сам следит за использованием обьектов и сам удаляет
Р>неиспользуемые из памяти. То есть шести гигов на локальной машине не
Р>будет, все часто используемые обьекты будут висеть у Вас в памяти. В
Р>принципе, то, что Вы хотели.

Что-то не совсем вкуриваю как это отличается орт моего способа. У меня есть такой вот словарь

Dictionary<Type,SortedList<Guid,BuisinessObject>>

Аналогично в моем способе (не в текущем, а если докрутить пэйджинг, о котором я писал). Запрашиваются объекты. Сначала возвращаются их ID-ки (порциями по 50 штук, если например запрашивается список из 1 000 000 сотрудников. То есть сначала отобржаем 50 штук, потом если пользователь прокрутил список вниз отображаем следующие 50 штук, и.т.д.) Потом по типу возвращается из этого словаря сортированный список уже загруженных бизнес объектов. Проходимся по вернувшимся ID-кам, если находим в списке (поиск происходит быстро, потому что список отсортирован по Guid-ам, и по сути используется бинарный поиск), то все OK, иначе запихиваем в другой список (NotFoundedObjects). Потом одним запросом подымаем из базы все объекты с ID-ками из NotFoundedObjects (SELECT ... FROM ... WHERE ID == NotFoundedObjects[0] OR ID == NotFoundedObjects[1] ID == NotFoundedObjects[2] ... . Конечно же, это в цикле ).
Единственное, что мне не понятно, как автоматически будет происходить удаление объектов? Объясните пожалуйста немного подробнее. Если использовать словарь, который я выше привел, то он как раз таки до 6 гигов и вырастет со временем (а может и больше). Что такое GB? Если использовать WeakReference, то если я не ошибаюсь, они позволяют определить одну жесткую ссылку и кучу слабых? То есть я могу в словарь(см. выше) добавить слабые ссылки, а в списки, где он реально используется — сильную. И тогда согласен, когда я список закрою, то GC соберет объект, слабая ссылка на который харнится в словоре (но тут не понятно, что будет со слабой сылкой на этот объект. Автоматически удалится из списка или же там будет null?). Но проблема в том, что списков может быть много. То есть нужно несколько сильных ссылок и одна слабая.

>> запрашиваемых объектов. Если какие-то объекты не загружены, то они
>> загружаются отдельно. По-моему это будет происходить намного быстрее,
>> чем каждый раз по-новой гурзить все данные из базы. Я не прав?

Р>Не правы. Не забывайте, что Вам еще нужно следить за обьектами, которые
Р>у Вас в памяти. Прочитать обьект один раз из БД легче, чем
Р>синхронизировать 100 обьектов с БД.

Че-то я запутался. Здесь Вы по-моему противоречите сами себе. Сначала Вы говорите, что нужно хранить ссылки в кэше (в прошлом абзаце), а теперь, что быстрее будет объекты заново из базы подымать

>> Ну это еще не самые жесткие моменты в коде .

Р>Не, я подозревал...

>> Например, просто ради
>> интереса, что Вы думаете о наличии некой таблицы измененных данных. То
Р>[skip]
>> справедливо для всех списков, которые содержат этот объект). Я по работе
>> сталкивался с несколькими коммерческими системами. Могу сказать, что они
>> не могли похватстаться такой фишкой. Если данные в список были
>> загружены, то они могут быть изменены только при полной перегрузке.

Р>Я уже высказывал свою мысль, что месье знает толк в извращениях.

А какие есть еще варианты безболезненного обновления? (если не рассматривать сервер приложений) То есть нужен некий метод на клиенте, который мог бы просто и быстро обновить все объекты. Если явно в БД не хранить что изменилось, то по-моему остается только одно — перечитывать все уже загруженные объекты. Но это не жизненно

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

S>Здравствуйте, <Аноним>, Вы писали:
А>> На самом деле этот подход уже частично реализован. Единственное отличие текущей реализации от вышеописанного заключается в том, что пока нет возможности частично загрузить объекты. При первом обращении, например к объекту «Студент» идет загрузка всех студентов (не важно, Сколько их там – 1000 или 1 000 000) и вся дальнейшая работа происходит из расчета на то, что все студенты уже загружены. Но не такая уж большая проблема докрутить механизм, чтобы можно было загружать объекты одного типа порциями по мере необходимости и потом уже использовать загруженные. Вопрос в том, следует ли дальше развивать такую платформу, насколько она жизненна и на каком классе приложений.
S>Не стоит. Я принимал участие в реализации этой платформы десять лет назад. Результаты — удручающие.
S>Основные проблемы:
S>1. Невыгрузка кэша. Так делать в принципе нельзя. Кэш должен быть ограничен по размеру, иначе его эффективность теряется.

Ну да, я вот как раз этого и опосаюсь и это основная причина моего поста. То есть получается, наступит некий размер БД, когда будет быстрее заново вернуть объекты из БД, чем искать их в памяти (большая часть которой находится в свопе на диске). Правильно понял? Ну тут вроде на соседней ветки подсказывают, что можно автоматически удалять из списков неиспользуемые объекты. Наверное, если грамотно сделать, то это решит проблему.

S>2. Поддержание когерентности кэша. Если у тебя два человека работают над данными, каждый должен видеть актуальную копию. Большой кэш приводит к большим затратам на передачу изменений.

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

S>Так что посмотри на существующие ORM решения: всё это реализовано очень давно и не один раз. Во-первых, тебя скорее всего устроит какой-нибудь Hibernate, а во-вторых всегда полезно изучить опыт других в велосипедостроении.

С Hibernate работал. Впечатления самые ужасные. Он всю работы перекладывает на БД. Он сам отрабатывает быстро, но генерит запросы по 50 !!!!!! строк. И сервер БД потом реально напрягается. Тетстировали на 100 000 записях (у таблицы ссылок через ForeignKey в районе 20). Работает ужасно. Даже с пэйджингом грузится все очень медленно . Первая версия моего подхода на 100 000 записях грузилась 25 секунд (грузилось все, без пэйджинга, зато потом все работало довольно быстро). Конечно же я не думаю, что мой подход лучше , но Hibernate по-моему очень наворочен всякими не нужными вещами. Я же пишу мини-платформу под конкретные цели.

Здравствуйте, <Аноним>, Вы писали:
А> Ну да, я вот как раз этого и опосаюсь и это основная причина моего поста. То есть получается, наступит некий размер БД, когда будет быстрее заново вернуть объекты из БД, чем искать их в памяти (большая часть которой находится в свопе на диске). Правильно понял? Ну тут вроде на соседней ветки подсказывают, что можно автоматически удалять из списков неиспользуемые объекты. Наверное, если грамотно сделать, то это решит проблему.
Самая сложность грамотного изготовления — понять, какие объекты больше не нужны.

S>>2. Поддержание когерентности кэша. Если у тебя два человека работают над данными, каждый должен видеть актуальную копию. Большой кэш приводит к большим затратам на передачу изменений.

А> Ну если изменений очень много, то может быть, но как показывает практика в системах типа workflow не так уж много изменений. Думаю, что с синхронизацие как раз проблем быть не должно. Актуальная копия гарантирована
Еще раз поясняю: ровно то, что вы изобретаете, мы писали в 1997-1998 годах. В принципе, приложение заработало, но я второй раз так делать не буду. Основываясь на личном негативном опыте.

А> С Hibernate работал. Впечатления самые ужасные. Он всю работы перекладывает на БД.
И правильно делает.
А>Он сам отрабатывает быстро, но генерит запросы по 50 !!!!!! строк. И сервер БД потом реально напрягается.
Значит, выбрали неудачную структуру данных.
А>Тетстировали на 100 000 записях (у таблицы ссылок через ForeignKey в районе 20). Работает ужасно. Даже с пэйджингом грузится все очень медленно . Первая версия моего подхода на 100 000 записях грузилась 25 секунд (грузилось все, без пэйджинга, зато потом все работало довольно быстро).
Это означает, что join в БД работали неэффективно. Как правило, это симптом неправильной расстановки индексов.
А>Конечно же я не думаю, что мой подход лучше , но Hibernate по-моему очень наворочен всякими не нужными вещами. Я же пишу мини-платформу под конкретные цели.
Хорошо спроектированное приложение поверх БД + Hibernate будет работать намного лучше чем то, что вы напишете. Я этих мини-платформ в своей карьере навидался. Результаты примерно такие:
— у 100% этих решений наличествуют баги, которые трудно вычистить малыми силами. В итоге работать реально страшно — то и дело теряются изменения, данные вступают в конфликт, или нарушается ссылочная целостность.
— приемлемая производительность достигается только на одном-двух тестовых примерах. Чуть другая постановка задачи, или там скажем рост масштаба в 10 раз — все, копец, приплыли.


Нужно напрячься и понять, что Hibernate и прочие "взрослые" ORM начинали точно так же, как и вы. Только на них потрачено в тысячи раз больше времени, поэтому их качество несравненно выше. И вообще уметь осваивать чужие решения ничуть не менее полезно, чем изобретать свои.

Здравствуйте, <Аноним>, Вы писали:

А> С Hibernate работал. Впечатления самые ужасные. Он всю работы перекладывает на БД. Он сам отрабатывает быстро, но генерит запросы по 50 !!!!!! строк. И сервер БД потом реально напрягается. Тетстировали на 100 000 записях (у таблицы ссылок через ForeignKey в районе 20). Работает ужасно. Даже с пэйджингом грузится все очень медленно . Первая версия моего подхода на 100 000 записях грузилась 25 секунд (грузилось все, без пэйджинга, зато потом все работало довольно быстро). Конечно же я не думаю, что мой подход лучше , но Hibernate по-моему очень наворочен всякими не нужными вещами. Я же пишу мини-платформу под конкретные цели.

Не умеете вы его готовить.

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

S>Здравствуйте, <Аноним>, Вы писали:
А>> Ну да, я вот как раз этого и опосаюсь и это основная причина моего поста. То есть получается, наступит некий размер БД, когда будет быстрее заново вернуть объекты из БД, чем искать их в памяти (большая часть которой находится в свопе на диске). Правильно понял? Ну тут вроде на соседней ветки подсказывают, что можно автоматически удалять из списков неиспользуемые объекты. Наверное, если грамотно сделать, то это решит проблему.
S>Самая сложность грамотного изготовления — понять, какие объекты больше не нужны.

S>>>2. Поддержание когерентности кэша. Если у тебя два человека работают над данными, каждый должен видеть актуальную копию. Большой кэш приводит к большим затратам на передачу изменений.

А>> Ну если изменений очень много, то может быть, но как показывает практика в системах типа workflow не так уж много изменений. Думаю, что с синхронизацие как раз проблем быть не должно. Актуальная копия гарантирована
S>Еще раз поясняю: ровно то, что вы изобретаете, мы писали в 1997-1998 годах. В принципе, приложение заработало, но я второй раз так делать не буду. Основываясь на личном негативном опыте.

А>> С Hibernate работал. Впечатления самые ужасные. Он всю работы перекладывает на БД.
S>И правильно делает.
А>>Он сам отрабатывает быстро, но генерит запросы по 50 !!!!!! строк. И сервер БД потом реально напрягается.
S>Значит, выбрали неудачную структуру данных.
А>>Тетстировали на 100 000 записях (у таблицы ссылок через ForeignKey в районе 20). Работает ужасно. Даже с пэйджингом грузится все очень медленно . Первая версия моего подхода на 100 000 записях грузилась 25 секунд (грузилось все, без пэйджинга, зато потом все работало довольно быстро).
S>Это означает, что join в БД работали неэффективно. Как правило, это симптом неправильной расстановки индексов.
А>>Конечно же я не думаю, что мой подход лучше , но Hibernate по-моему очень наворочен всякими не нужными вещами. Я же пишу мини-платформу под конкретные цели.
S>Хорошо спроектированное приложение поверх БД + Hibernate будет работать намного лучше чем то, что вы напишете. Я этих мини-платформ в своей карьере навидался. Результаты примерно такие:
S>- у 100% этих решений наличествуют баги, которые трудно вычистить малыми силами. В итоге работать реально страшно — то и дело теряются изменения, данные вступают в конфликт, или нарушается ссылочная целостность.
S>- приемлемая производительность достигается только на одном-двух тестовых примерах. Чуть другая постановка задачи, или там скажем рост масштаба в 10 раз — все, копец, приплыли.


S>Нужно напрячься и понять, что Hibernate и прочие "взрослые" ORM начинали точно так же, как и вы. Только на них потрачено в тысячи раз больше времени, поэтому их качество несравненно выше. И вообще уметь осваивать чужие решения ничуть не менее полезно, чем изобретать свои.

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

Здравствуйте, Аноним, Вы писали:

А> Буду благодарен за любые комментарии по поводу подхода, избранного в платформе.

Тоже принимал участие в похожем проекте и тоже все окончилось плачевно. Но я действительно получил опыт и было интересно По поводу архитектуры, я бы сразу отказался от автоматической синхронизации объектов, так как в многопользовательской среде принципиально невозможно всегда иметь свежие копии. Соответственно, если при разработке полагаться на то, что кэш сам все разрулит, то можно поиметь массу трудноуловимых багов при реальном использовании системы. Поэтому у каждого объекта должна быть возможность получить свежее состояние с сервера явным вызовом типа Refresh. И соответственно при записи изменений в базу надо проверять актуальность объекта (например по таймстампу) и откатывать транзакцию с автоматической выгрузкой всех измененных объектов из кэша. Ну либо должен быть явный метод блокирования объекта в базе — но это естественно только внутри транзакции. Еще можно сделать, чтобы все запросы к базе возвращали список идентификаторов объектов в виде коллекции, потом, при попытке использовать объект из коллекции читается не только сам этот объект, но и его соседи постранично. Из кэша можно выкидывать любые объекты, но если на объект есть ссылка из какой-нибудь активной коллекции, то он имеет приоритет. Ну и так далее, извращаться можно до бесконечности

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

COF>Здравствуйте, Аноним, Вы писали:

А>> Буду благодарен за любые комментарии по поводу подхода, избранного в платформе.

COF>Тоже принимал участие в похожем проекте и тоже все окончилось плачевно. Но я действительно получил опыт и было интересно По поводу архитектуры, я бы сразу отказался от автоматической синхронизации объектов, так как в многопользовательской среде принципиально невозможно всегда иметь свежие копии.

Смотря что понимать под свежими объектами. В моем случае на момент выполнения любого действия — добавлять объект, изменять его, удалять на клиент 100% будет самая последняя версия объектов, который записаны в базе (даже если будет 1000 пользователей). Единственно чего не будет — это введенных какими-нибудь пользователями данных в формы редактирования, на которых не нажали кнопку "Применить".

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

Например каких?

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

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

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

1. Запрашивается таблица изменения объектов. Возвращаются только реально изменившиеся объекты, при этом все списки, которые содержат один или несколько обновившихся объектов автоматически обновятся. Грубо говоря — у Вас открыт список сотрудников орагнизации и Вы видите сотрудника "Иванов Иван Иванович", для которого стоит дата рождения 1.01.1900. Потом, на другой форме Вы нажимаете на кнопку "Добавить документ", после чего открывается форма для добавления документа. А до того как Вы нажали на кнопку кто-то из 1000-чи сотрудников понял, что нагнал и исправил дату рождения сотрудника на "15.07.1980". И Вы, даже специально не запрашивая дату рождения сотрудника (работаете вообще в другой форме с другим типом объекта) уже видите в списке (который ни разу не становился активным) что дата стоит правильная. И при чем это все работает одинаково хорошо для объектов со сложными взаимосвязями.
Просто ради интереса вот такой вот вопрос. У меня опыта не много и работал я только с 2-мя крупными коммерческими системами. Так вот, в них не было такой фишки. Пока список с объектами не будет полностью перезагружен, изменений не будет видно. Это по-моему ведет куда к большим проблемам. В системе может быть список, который постоянно висит (список с документами) и куча народу с ним работает, а его нужно постоянно перегружать, чтобы увидеть что там изменилось (в одном проекте, с которым работал, это нужно было делать вручную). По факту может получиться что документ удалили 2 часа назад, а через 2 часа его кто-то попытается отредактировать. Так вот собственно и вопрос: Вы встречали системы, которые позволяют поддерживать реально актуальные данные? Примерно по какой архитектуре они были построены?

2. Делаются изменения.

3. В таблицу изменений заносятся типы и ID-ки изменившихся объектов и код операции.

4. Снова запрашивается таблица изменений и она обновляет все действия именно в той последовательности, в которой они были совершены. В том числе она загружает Ваши только что сделанные изменения. То есть общий устоявшийся подход такой: Вы работате с копиями объектов, измененные значения которых заносятся в базу, если нет никаких проблем и конфликтов. А уже обновление даже собственных изменений происходит вместе со всеми остальными. Поэтому и гарантируется что у всех 1000 сотрудников в один момент времени, не важно с чем они работают будут одни и те же данные.

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

Какие могут быть проблемы из выше Вами описанных? Видите ли какие-нибудь проблемные места в описанном подходе?

Здравствуйте, Аноним, Вы писали:

А> Какие могут быть проблемы из выше Вами описанных? Видите ли какие-нибудь проблемные места в описанном подходе?

Вот, например, список содержит всех родившихся после 01.01.1980; параллельно кто-то меняет дату рождения для одной записи с 01.01.1900 на 15.07.1980, как будет обработана данная ситуация?

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

COF>Здравствуйте, Аноним, Вы писали:

А>> Какие могут быть проблемы из выше Вами описанных? Видите ли какие-нибудь проблемные места в описанном подходе?

COF>Вот, например, список содержит всех родившихся после 01.01.1980; параллельно кто-то меняет дату рождения для одной записи с 01.01.1900 на 15.07.1980, как будет обработана данная ситуация?

Да, эту ситуацию я тоже продумывал, но механизм пока не реализован. Она, кстати относится не только к фильтру, но и к сортировкам (если список был отсортирован по дате, а кто-то изменил объект из списка).

Самый простой способ разрулить эту сиуацию, это перезагрузка списка. Это будет не так напряжно, учитывая, что все объекты уже загружены (так как список был отображен). Также нужно учитывать что есть механизм пэйнджинга, поэтому если даже на клиенте был загружен список с 1000 строк (пользователь долго скролил вниз), то после такой операции обновления, в списке останется только 40-50 строк (минимальный размер загружаемых данных), при этом текущий видимый (или видимый выделенный) по центру объект там так и останется (хотя вариантов тут несколько, можно восстанавливать все выделенные).

Но я рассматриваю перезагрузку списка как самый крайний ваниат. Пока я пробую обновлять только изменившиеся объекты.

С фильтрами как раз особых вариантов нету. Думаю, что бессмысленно реализовывать фильтрацию еще и на клиенте(все-таки в СУБД богатый функционал на этот счет), поэтому вариант только один — сделать метод (в менеджере объектов), который по ID-ке объекта определит, удовлетворяет ли он фильтрам или нет (естественно через запрос к базе). Я думаю, что это будет совсем ненапряжно и на производительность практически не повляет.

Вот с сортировками действительно сложнее. Если не реализовывать сортировку еще и на клиенте (на серваке она, как и фильтрация, по-любому должна быть, иначе не будет работать пэйджинг), то наверное обойдется это довольно дорого в плане производительности. В таком случае придется запрашивать список ID-ек, чтобы определить порядок, в котором они должны быть, а потом как-то смердживать. Но что-то мне подсказывает что это мало жизненно. Поэтому, думаю, пока остановлюсь на варианте с сортировкой на клиенте. Думаю, что методы сравнения SQL2005 и методы сравнения c# для всех простых типов данных работают одинаково

Вобщем, думаю, сделаю пока такой вариант, потом протестирую на больших объемах данных и малых скоростях соединения с СУБД. Но, реально, думаю, что нет особых проблем нормально это сделать . Самый такой нехороший момент — это именно в том, как определить когда нужно освобождать ненужные объекты. Возможно мне помогут WeakReference (как мне подсказали в соседней ветке). Благо, пишу все на .NET-те . А вот Вы вроде писали это дело по c++. Можешь в общих чератх рассказать как решали проблему с освобождением объектов?

Здравствуйте, <Аноним>, Вы писали:

А> Просто ради интереса вот такой вот вопрос. У меня опыта не много и работал я только с 2-мя крупными коммерческими системами. Так вот, в них не было такой фишки. Пока список с объектами не будет полностью перезагружен, изменений не будет видно. Это по-моему ведет куда к большим проблемам. В системе может быть список, который постоянно висит (список с документами) и куча народу с ним работает, а его нужно постоянно перегружать, чтобы увидеть что там изменилось (в одном проекте, с которым работал, это нужно было делать вручную). По факту может получиться что документ удалили 2 часа назад, а через 2 часа его кто-то попытается отредактировать. Так вот собственно и вопрос: Вы встречали системы, которые позволяют поддерживать реально актуальные данные? Примерно по какой архитектуре они были построены?

Я же говорю: мы делали ровно такую систему. Проблема — в том, что рассылка изменений всем клиентам стоит очень дорого.
Усугублялась эта проблема тем, что кэш не очищался — в итоге в памяти клиента висели десятки тысяч объектов, которые нужно было обновлять при изменениях с других клиентов.

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

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

S>Здравствуйте, <Аноним>, Вы писали:

А>> Просто ради интереса вот такой вот вопрос. У меня опыта не много и работал я только с 2-мя крупными коммерческими системами. Так вот, в них не было такой фишки. Пока список с объектами не будет полностью перезагружен, изменений не будет видно. Это по-моему ведет куда к большим проблемам. В системе может быть список, который постоянно висит (список с документами) и куча народу с ним работает, а его нужно постоянно перегружать, чтобы увидеть что там изменилось (в одном проекте, с которым работал, это нужно было делать вручную). По факту может получиться что документ удалили 2 часа назад, а через 2 часа его кто-то попытается отредактировать. Так вот собственно и вопрос: Вы встречали системы, которые позволяют поддерживать реально актуальные данные? Примерно по какой архитектуре они были построены?

S>Я же говорю: мы делали ровно такую систему. Проблема — в том, что рассылка изменений всем клиентам стоит очень дорого.
S>Усугублялась эта проблема тем, что кэш не очищался — в итоге в памяти клиента висели десятки тысяч объектов, которые нужно было обновлять при изменениях с других клиентов.

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

А как думаешь, если сделать нормальную очистку кэша: всегда удалять все объекты, на которые больше никто не ссылается, и соответственно, обновлять только те объкты, которые реально требуются (то есть, если у пользователя нет ни одного объекта типа "Employee", то и не загружать изменения, связанные с этим типом. Или, если изменяемый объект не попадает под фильтры, то аналогично.) жизненно будет использовать на больших проектах такой подход?