Веду проект серверного приложения, обменивающегося данными с множеством различных клиентов и хранящем эти данные в собственном хранилище. Проект написан на С++ под Win, в виде хранилища используется storage (через интерфейсы IStorage, IStream). Приложение работает под большими нагрузками, данные обновляются раз в 200 мс, объем данных большой. Сейчас занимаюсь перепроектированием хранилища, поставлена задача сделать его максимально надежным, но не в ущерб производительности системы. Т.о. подзадачи две:
1. Защитить данные от внешних повреждений (сбой оборудования, сбой ОС).
Вижу решение в подсчете для каждой таблице данных CRC (она храниться как поток данных), сохранением его в хранилище, и при зачитывании данных из таблице, сравнении сохраненного CRC с текущем. В случае несовпадения CRC — восстановление БД из бекапа.
2. Защитить данные от внутренних ошибок (например порче данных из за ошибок типа переполнения буфера, прохода по памяти или просто пришедших некорректных данных от клиентов).
Конечно, проверки на эти ошибки уже существуют, но они раскиданы по всему коду Сервера и при внесении новых изменений очень легко что-либо упустить. Мне здесь видится 2 решения: 1) Создать класс таблицы (возможно шаблонный класс), к-рый при изменении данных проверял бы их на валидность (в зависимости от конкретной таблице). Тогда все проверки будут находиться в одном месте и их проще будет сопровождать. Наверняка существует уже готовый паттерн реализующий эту задачу, посоветуйте если кто сталкивался! 2) Запустить фоновый поток который будет верифицировать измененные данные. При таком решении процесс проверки данных будет меньше нагружать систему, но будет ли он успевать проверять все данные
Еще нужно придумать как быстро делать бекапы по время работы Сервера БД... но это пока менее приоритетная задача.
Что думаете по этому поводу? И, пожалуйста, посоветуйте сайты/форумы/статьи/книги описывающие архитектуры Сервера БД, паттерны применяемые в этой области и решающие описанные задачи! Хочется сперва изучить опыт др людей, чтоб заново не изобретать велосипед. В области проектирования (не реализации, а именно проектирования) я пока слаб, нужно учить матчасть, но подходящих источников информации пока найти не могу
Здравствуйте, KRA,
KRA>Где-то встречал обсуждение косяков этого доклада, жаль, линк не сохранил. Автор доклада сам признал, что есть ошибки.
Ошибки везде есть ... "где-то слышал, что то видел, кто сказал что есть ошибки " что за детский сад, давайте конкретно, а то слышал звон да не знаешь, где он.
Здравствуйте, Stormblast, Вы писали:
S>этот человек реально может помочь
Спасибо за наводку
Написал ему письмо с описанием ситуации, жду ценного совета или указания направления куда копать Надеюсь у Якова найдется время ответить...
Коллеги, спасибо, конечно, что не забываете старика, но я в упомянутом докладе рассказываю о решении, которое работает поверх стандартной базы данных. Зачем в данном случае вместо стандартной базы применяется что-то самописное — я не понимаю. Если существующее самописное хранилище по каким-то причинам сейчас не устраивает, то с вероятностью 99% его нужно просто заменить на что-то стандартное.
Давать советы по архитектуре, имея на входе требования вроде "максимально надежным, но не в ущерб производительности системы", — это, по-моему, полная безответственность.
Если я ещё не ответил на поставленный вопрос, то было бы конструктивно изложить грамотные требования к системе: какие данные, какой объём, с какой частотой какие операции с ними делаются, какие требования к надёжности. Начинать лучше с описания задач конкретных пользователей.
Спасибо за ответ, но он мне совершенно ничем не помог
ЯС>Зачем в данном случае вместо стандартной базы применяется что-то самописное — я не понимаю. Если существующее самописное хранилище по каким-то причинам сейчас не устраивает, то с вероятностью 99% его нужно просто заменить на что-то стандартное.
Значит у нас и получается тот самый 1% И основной довод это экономическая не целесообразность перехода к чему-то стандартному, слишком большие трудозатраты в переписывании системы. Существующее хранилище устраивает, но выдвинули требования к повышенной надежности системы и в первую очередь от внешних сбоев.
ЯС>Давать советы по архитектуре, имея на входе требования вроде "максимально надежным, но не в ущерб производительности системы", — это, по-моему, полная безответственность.
Согласен что приведенное требование слушком размыто и в итоге будет принят компромисс между надежностью и производительностью) Но ниже я дал более четкие задачи которые нужно решить:
1. Защитить данные от внешних повреждений (сбой оборудования, сбой ОС).
2. Защитить данные от внутренних ошибок (например порче данных из за ошибок типа переполнения буфера, прохода по памяти или просто пришедших некорректных данных от клиентов).
И привел возможные варианты решения.
ЯС>Если я ещё не ответил на поставленный вопрос, то было бы конструктивно изложить грамотные требования к системе: какие данные, какой объём, с какой частотой какие операции с ними делаются, какие требования к надёжности. Начинать лучше с описания задач конкретных пользователей.
Я не собираюсь полностью перепроектировать всю систему исходя из "задач конкретных пользователей", это просто не в моей компетенции. Аналитикой, разработкой требований к системе занимаются другие люди. Мне просто нужно предложить варианты решения 2х поставленных задач и объяснить плюсы и минусы этих вариантов. Показать при каком решении мы теряем в производительности системы, при каком мы жертвуем надежностью.
Итог:
Помощь от сообщества RSDN мне нужна в 2х направлениях:
1. Посоветуйте какие-либо источники информации по теме "Архитектура Сервера БД".
2. Если встречались с подобными задачами, прокомментируйте мои решения или предложите свои.
Здравствуйте, Овощ, Вы писали:
О>Конкретно по архитектуре сервера БД есть классическая книжка: О>Гектор Гарсиа-Молина, Джеффри Ульман, Дженнифер Уидом О>Системы баз данных. Полный курс.
Спасибо. У тебя в электронном виде нет книжки или может ссылочку, плиз...
А то с оф сайт издательства "Диалектика" предлагают скачать электронный вариант за 170р, и деньги просят за ПОИСК книги http://www.dialektika.com/buy-ebooks.php?isbn=5-8459-0384-X
Ну я понимаю еще деньги за авторство, но за поиск Как будто они со стремянко на книжных полках ее искать кинуться))
Здравствуйте, yuske, Вы писали:
Y>Приложение работает под большими нагрузками, данные обновляются раз в 200 мс, объем данных большой.
А большие нагрузки — это какие? Сколько транзакций в секунду, сколько выборок, объем данных, параллельность?
Y>Что думаете по этому поводу? И, пожалуйста, посоветуйте сайты/форумы/статьи/книги описывающие архитектуры Сервера БД
Можно начать с книг про архитектуру БД (раз уж, по сути, сами пишете БД — то можно посмотреть, как это делают другие).
Про Оракл можно почитать у Тома Кейта. Про DB2 — поискать какой-нибудь redbook на сайте ibm на подходящую тему.
Да, указанная выше схема распределеннных асинхронных задач, теоретически, реализуема не только поверх БД — блокировки можно сделать и на файловой системе, например. Просто у нас с Яшей задача стояла сделать самый дешевый механизм на существующих БД.
Здравствуйте, yuske, Вы писали: Y>Спасибо. У тебя в электронном виде нет книжки или может ссылочку, плиз... Y>А то с оф сайт издательства "Диалектика" предлагают скачать электронный вариант за 170р, и деньги просят за ПОИСК книги
Как интересно. Официальный сайт "Вильямс" предлагает всё то же самое. Y>http://www.dialektika.com/buy-ebooks.php?isbn=5-8459-0384-X Y>Ну я понимаю еще деньги за авторство, но за поиск Как будто они со стремянко на книжных полках ее искать кинуться))
Нет, поиск они делают бесплатно. Они деньги просят за книгу. Я заказал на выходных (в связи с появлением у меня PRS-505), жду ответа.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
" что за детский сад, давайте конкретно, а то слышал звон да не знаешь, где он. 
И основной довод это экономическая не целесообразность перехода к чему-то стандартному, слишком большие трудозатраты в переписывании системы. Существующее хранилище устраивает, но выдвинули требования к повышенной надежности системы и в первую очередь от внешних сбоев.
Как будто они со стремянко на книжных полках ее искать кинуться))
