Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Не сочти за издевательство, но NT — это DAC В чистом виде он не очень походит для веб-приложения, т.к. в этом случае (дискреционного доступа), владелец информации (тот, кто ее создал или получил во владение, если имел на это право) получает безграничный контроль над этой информацией. Но ACL'и, которые обсуждались на тимовском форуме — это как раз оттуда, да.
Владельцев мы не рассматривали. В нашем случае достаточно чтобы права могли менять админы. Нам важен именно аналог ACL. То есть некоторая хрень которая позволит быстро понять доступны для некоторого пользователя некоторые данные или нет.
KV>Я сейчас подбиваю выжимку из всего, что обсуждалось в 2007 и в этом форуме и в тимовском... Там же тогда и опишу возможный вариант контроля доступа.
ОК
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Тут скорее нужна помощь IT и АВК. Хотя они могут снова переругаться.
Вот именно. Так что не и, а или.
И лично я предпочту IT'а.
VD>1. Если текста нет, то создается новая метазапись о нем и БЛОБ в БД или файл на диске. Мы так и не пришли к единому мнению что лучше. VD>2. Если текст есть, то нужно сделать diff этого текста и его новой версии и записать в БД новую версию и этот диф. По диф-у и тексту нужно иметь возможность получить предыдущую версию. В конечном итоге у нас должна храниться последняя версия целиком и набор дифов для всех изменений. На первых порах можно просто хранить все версии.
Тут ИМХО нужно делать так:
В базе нужно хранить только имена блобов.
Имя блобу дается исключительно на основе его содержимого.
SHA-256 ИМХО более чем достаточен чтобы обеспечить уникальность на практически любых объемах.
Содержимое блоба должно начинаться с флагов. Варианты которые сразу приходят на ум:
1)Блоб
2)Сжатый блоб
3)Патч
4)Сжатый патч
Как блобы хранить нужно подумать.
Тут полно вариантов.
1)Таже база где лежит метаинформация.
Этот вариант мне совсем не нравится. Ибо нагружать основную базу которая занимается кучей всяких кучерявых джойнов не дело.
2)Отдельная база для блобов.
Это лучше. Но всеравно одна база вызывает сомнения.
3)Файловая система и иерархией каталогов. Думаю два уровня по 3 шеснадцатиричных цифры будут в самый раз.
Очень хороший, проверенный временем и кучей дико нагруженных проектов вариант.
Но нам нужно атомарное обновление блобов. Тут с этим придется повозиться.
4)Куча мелких баз для блобов. Возможно использование какой ни будь встраиваемой СУБД типа SQLite. Думаю 3-4 цифры от хеша в качестве имени будут в самый раз.
Этот вариант ИМХО лучше всех ибо проблему с обновлением уже решил автор БД.
Также кучу мелких баз можно по одной упаковывать практически не создавая нагрузки.
Кстати использование хешей для имени блобов решает еще одну задачу: А именно делает кеширование тривиальным. Ибо однажды обработанный блоб можно закешировать навсегда.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>3)Файловая система и иерархией каталогов. Думаю два уровня по 3 шеснадцатиричных цифры будут в самый раз. WH>Очень хороший, проверенный временем и кучей дико нагруженных проектов вариант. WH>Но нам нужно атомарное обновление блобов. Тут с этим придется повозиться.
Атомарность обновления можно сделать путем запихивания запросов на редактирование в очередь. Все равно как такового параллельного редактирования по сути не будет.
WH>4)Куча мелких баз для блобов. Возможно использование какой ни будь встраиваемой СУБД типа SQLite. Думаю 3-4 цифры от хеша в качестве имени будут в самый раз. WH>Этот вариант ИМХО лучше всех ибо проблему с обновлением уже решил автор БД. WH>Также кучу мелких баз можно по одной упаковывать практически не создавая нагрузки.
Тут сразу нужно думать о бэкапе данных. Как ты представляешь себе бэкап кучи мелких БД? Да и зачем тогда куча то?
WH>Кстати использование хешей для имени блобов решает еще одну задачу: А именно делает кеширование тривиальным. Ибо однажды обработанный блоб можно закешировать навсегда.
А кому он нужен то? Нужны конечные версии страниц.
Вообще, идея с файлами мне нравится больше не смотря на проблему с ароматностью обновления. И именно в виду ее практичности. Скопировать каталог проще нежели кучу БД. При этом бэкап может иди в фоне и даже осуществляться средствами синхронизации (ОС или сторонними).
Так что рассматривать нужно два варианта. Одна БД для блобов или файлы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Это ролевой контроль доступа и принудительный контроль доступа — различные модели реализации такого контроля. Ролевой доступ (RBAC) — это то, что используется в текущем движке, все полномочия пользователя определяются исключительно его принадлежностью к какой-либо роли (аноним, юзер, модератор, админ, тимер и т.п.). В случае принудительного доступа (MAC), все объекты и субъекты контроля доступа снабжаются метками безопасности, в которых указана их принадлежность к тому или иному классу конфиденциальности и категориям классификации. Когда субъект пытается получить доступ к объекту, их метки сравниваются и на основе этого принимается решение о предоставлении доступа. MAC — единственная модель, безопасность которой может быть доказана математически.
KV>Собственно пока, из того что я успел прочитать, я сделал вывод, что вы пытались интуитивно реализовать подобие MAC.
Скорее мы пытались интуитивно использовать обе модели. С одной стороны нам нужно разделение прав доступа к ресурсам (видимо это MAC), с другой разделение прав доступа к определённым действиям (это роли). Обе модели реализуются по разному и практически не пересекаются. Если для ролей есть вполне приличная поддержка со стороны ASP.NET, то для управления доступом к ресурсам нужно придумывать свою схему и здесь важна в первую очередь производительность. А учитывая, что у нас почти 4 миллиона сообщений и около 100 тысяч пользователей в базе, то в лоб такая задача плохо решается.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Тут скорее нужна помощь IT и АВК. Хотя они могут снова переругаться.
Мы уже давно научились с АВК не ругаться.
VD>2. Если текст есть, то нужно сделать diff этого текста и его новой версии и записать в БД новую версию и этот диф. По диф-у и тексту нужно иметь возможность получить предыдущую версию. В конечном итоге у нас должна храниться последняя версия целиком и набор дифов для всех изменений. На первых порах можно просто хранить все версии.
Зачем городить этот огород? Почему бы тупо не сохранять предыдущую версию целиком?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
KV>>Не сочти за издевательство, но NT — это DAC В чистом виде он не очень походит для веб-приложения, т.к. в этом случае (дискреционного доступа), владелец информации (тот, кто ее создал или получил во владение, если имел на это право) получает безграничный контроль над этой информацией. Но ACL'и, которые обсуждались на тимовском форуме — это как раз оттуда, да.
VD>Владельцев мы не рассматривали. В нашем случае достаточно чтобы права могли менять админы. Нам важен именно аналог ACL. То есть некоторая хрень которая позволит быстро понять доступны для некоторого пользователя некоторые данные или нет.
Вообще-то рассматривали. Список ролей был такой: Custom, Everyone, User, Owner, Self.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
VD>>2. Если текст есть, то нужно сделать diff этого текста и его новой версии и записать в БД новую версию и этот диф. По диф-у и тексту нужно иметь возможность получить предыдущую версию. В конечном итоге у нас должна храниться последняя версия целиком и набор дифов для всех изменений. На первых порах можно просто хранить все версии.
IT>Зачем городить этот огород? Почему бы тупо не сохранять предыдущую версию целиком?
Чтобы не хранить лишних данных. Если вдруг страницы начнут реально редактирвоать, то информация может не хило размножиться.
В прочем, я ниже писал, что в превом приближении можно просто дублировать.
В любом случае для вики-функциональности нужно уметь вделять изменения и сливать изменения от разных авторов. То есть, один фиг diff делать нужно уметь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Зачем городить этот огород? Почему бы тупо не сохранять предыдущую версию целиком?
VD>Чтобы не хранить лишних данных. Если вдруг страницы начнут реально редактирвоать, то информация может не хило размножиться.
Может для экономии места тогда лучше зиповать сообщения?
VD>В прочем, я ниже писал, что в превом приближении можно просто дублировать. VD>В любом случае для вики-функциональности нужно уметь вделять изменения и сливать изменения от разных авторов. То есть, один фиг diff делать нужно уметь.
Если мы замахнёмся на всю возможную вики-функциональность, то не закончим этот проект никогда.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Может для экономии места тогда лучше зиповать сообщения?
Одно другому не мешает. Только вот зиповать по одному сообщению — это не эффективно. Зиповать хорошо бы прямо темы (или каталоги).
Ну, и естественно делать это лучше только для старых тем, которые не поднимались довольно давно.
Мои эксперементы с офлайн-генератором показывают, что если брать только темы которые опднимались в течении года, то выходит всегда около 700 метров. В прочем, твое автозакрытие тем, видимо изменит эту статистику.
IT>Если мы замахнёмся на всю возможную вики-функциональность, то не закончим этот проект никогда.
Всю не все, а людям нужно видеть изменения внесенные автором. Думаю, что алгоритм diff-а можно надыбать в интернетах.
Ну, и конечно же можно отложить это дело до лучших времен. Но помнить о такой необходимости надо по любому.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Если мы замахнёмся на всю возможную вики-функциональность, то не закончим этот проект никогда. VD>Всю не все, а людям нужно видеть изменения внесенные автором. Думаю, что алгоритм diff-а можно надыбать в интернетах.
Реализация диффа на немерле есть у меня Работает довольно шустро, но и есть что заоптимизировать. Поддерживаются двоичный и построчный-текстовый диффы, можно прикрутить любой другой формат, реализовав нужный интерфейс. Сейчас он гвоздями прибит к коду, в котором используется... Могу отцепить в отдельную сущность и куда-нибудь выложить.
Здравствуйте, IT, Вы писали:
VD>>Владельцев мы не рассматривали. В нашем случае достаточно чтобы права могли менять админы. Нам важен именно аналог ACL. То есть некоторая хрень которая позволит быстро понять доступны для некоторого пользователя некоторые данные или нет.
IT>Вообще-то рассматривали. Список ролей был такой: Custom, Everyone, User, Owner, Self.
А протоколы рассмотрений где-нибудь остались? В обсуждениях на тимовском форуме я этого не нашел
Здравствуйте, VladD2, Вы писали:
VD>Атомарность обновления можно сделать путем запихивания запросов на редактирование в очередь. Все равно как такового параллельного редактирования по сути не будет.
Этого не достаточно.
Данная схема не защищает от выключения машина в момент записи в файл.
VD>Тут сразу нужно думать о бэкапе данных. Как ты представляешь себе бэкап кучи мелких БД?
А что из себя представляет БД SQLite? Правильно один фаил.
VD>Да и зачем тогда куча то?
Чтобы не мешали друг другу пра паралельном доступе.
Стандартный паттерн при разработке высоконагруженных систем.
Кстати по хорошему схему основной БД нужно продумывать с учетом возможности разбить ее на несколько кусков.
VD>А кому он нужен то? Нужны конечные версии страниц.
Так после обработки блоба конечная страница и получается.
VD>Вообще, идея с файлами мне нравится больше не смотря на проблему с ароматностью обновления. И именно в виду ее практичности. Скопировать каталог проще нежели кучу БД. При этом бэкап может иди в фоне и даже осуществляться средствами синхронизации (ОС или сторонними).
А тут без разници.
Ибо тебе в обоих случаях придется позаботиться о том чтобы процесс бекапа не подрался с процессом записи.
ЗЫ Я этими вещами занимался в яндексе так что знаю не по наслышке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>Атомарность обновления можно сделать путем запихивания запросов на редактирование в очередь. Все равно как такового параллельного редактирования по сути не будет. WH>Этого не достаточно. WH>Данная схема не защищает от выключения машина в момент записи в файл.
Вот эта штука спасает отцов русской демакратии. Доступна начиная с Win2008Server и Висты. Подробности здесь.
VD>>Тут сразу нужно думать о бэкапе данных. Как ты представляешь себе бэкап кучи мелких БД? WH>А что из себя представляет БД SQLite? Правильно один фаил.
Дык и SQL-севренная БД — это один файл. Но бакапить их все же сложнее. Да и срезу не ясно зечем нам левые СУБД на сервере, если и так есть MS SQL Server.
Так что выбор только из MS SQL Server или файлами. Отдельная СУБД тоже не особо нужна. Достаточно хранить данные в отдельной таблице. Если что можно их средствами SQL-сервера вынести в отдельную файловую группу.
VD>>Да и зачем тогда куча то? WH>Чтобы не мешали друг другу пра паралельном доступе.
SQL лучше решит эту проблему. Ну, а еще лучше файловая система. Параллельный доступ на чтение — это фигня. Запись у нас будет в основном на добавление. Редактирование будет очень редким явлением. Это нужно учитывать.
WH>Стандартный паттерн при разработке высоконагруженных систем. WH>Кстати по хорошему схему основной БД нужно продумывать с учетом возможности разбить ее на несколько кусков.
Для этого у SQL-сервер есть свои механизмы. Тут скорее нужно учитывать специфику работы. Ведь в основном данные читаются, а не правятся. Сейчас БД фактически лежит в оперативке, что обеспечивает очень высокую скорость работы.
VD>>Вообще, идея с файлами мне нравится больше не смотря на проблему с ароматностью обновления. И именно в виду ее практичности. Скопировать каталог проще нежели кучу БД. При этом бэкап может иди в фоне и даже осуществляться средствами синхронизации (ОС или сторонними). WH>А тут без разници. WH>Ибо тебе в обоих случаях придется позаботиться о том чтобы процесс бекапа не подрался с процессом записи.
На то есть блокировки (и транзакции). Так что это не проблема. А вот, дополнительные вкусности, вроде возможности архивации старых файлов прямо средствами ОС очень даже радуют.
WH>ЗЫ Я этими вещами занимался в яндексе так что знаю не по наслышке.
Тут все не лаптем щи хлебают. Но думать нужно не только о производительности. Это многофакторная задча. Простота бэкапа тоже очень важна.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Реализация диффа на немерле есть у меня Работает довольно шустро, но и есть что заоптимизировать. Поддерживаются двоичный и построчный-текстовый диффы, можно прикрутить любой другой формат, реализовав нужный интерфейс. Сейчас он гвоздями прибит к коду, в котором используется... Могу отцепить в отдельную сущность и куда-нибудь выложить.
Ну, что-то есть и у нас (на шарпе правда). Но то бинарный диф. Тут важно прикрутить его к структуре вики. Ведь там еще вормат есть. Его видимо надо как-то отдельно обрабатывать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В чистом виде он не очень походит для веб-приложения, т.к. в этом случае (дискреционного доступа), владелец информации (тот, кто ее создал или получил во владение, если имел на это право) получает безграничный контроль над этой информацией. Но ACL'и, которые обсуждались на тимовском форуме — это как раз оттуда, да.
Если нам не помогут, то мы тоже никого не пощадим.
Работает довольно шустро, но и есть что заоптимизировать. Поддерживаются двоичный и построчный-текстовый диффы, можно прикрутить любой другой формат, реализовав нужный интерфейс. Сейчас он гвоздями прибит к коду, в котором используется... Могу отцепить в отдельную сущность и куда-нибудь выложить.
