Распределенная база данных на основе View

[Владимир Максимов]

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

Создается специальная база данных MS SQL в которой вместо всех, т.е. вообще ВСЕХ таблиц (ну, может за некоторым исключением) создаются VIEW с тем же именем и той же структурой вида

PHP код:

CREATE VIEW dbo.MyTable
AS
SELECT Field1,Field2,DataAreaId,RecId
FROM DataBase1.dbo.MyTable
UNION ALL
SELECT Field1,Field2,DataAreaId,RecId
FROM DataBase2.dbo.MyTable 


Т.е. эта специальная база даных собирает информацию из нескольких баз данных MS SQL. Получаем распределенную базу данных. Понятно, что можно указать в качестве источника и Linked-сервера. Т.е. вообще физически удаленные сервера.

Далее собствено AXAPTA подкладываем в качестве базы данных эту "сводную" базу данных. Т.е. AXAPTA "думает" что обращается к таблице MS SQL, но на физическом уровне обращение идет через View.

Эксперимент проводился на AXAPTA 2.5 SP3 + MS SQL 2005.

ЭТО РАБОТАЕТ! Как на чтение (что ожидаемо), так и на запись (нужны определенные настройки таблиц и дополнительный CONSTRAINT). Пока, разумеется, как тестовый пример на нескольких таблицах.

Также понятно, что при "падении" одной базы "упадет" и эта общая база. Просто View не сможет сделать выборку. Вопрос о другом.


Какие проблемы могут быть собственно в AXAPTA при работе с такой базой?


Конечная цель - получить хранение разных компаний физически в разных базах MS SQL. Но с общими справочниками и возможностью взаимодействия между базами (копирование некоторых данных)

Т.е. предполагается, что в разных базах MS SQL будут данные с разным (не пересекающимся) значением DataAreaId. Виртуализированные таблицы будут хранится в какой-то одной базе (отпадает проблема синхронизации справочников). А вопрос взаимодействия решается штатным ChangeCompany().

[kashperuk]

По теме не скажу ничего, кроме того, что это довольно извратно

Мне вот интересно про запись спросить.
А в какую базу данных вставляется строка при добавлении ее из Аксапты? Врядли View это сама раздупляет

[Владимир Максимов]

Цитата:

Сообщение от kashperuk

Мне вот интересно про запись спросить.
А в какую базу данных вставляется строка при добавлении ее из Аксапты? Врядли View это сама раздупляет

Могу повторить. Мне не жалко. ЭТО РАБОТАЕТ! Специально проверял запись, иначе не имеет смысла связываться. Идет куда надо и как надо. В нужную базу. Видимо, именно сам View и "раздупляет"

[Михаил Андреев]

Цитата:

Сообщение от Владимир Максимов

Могу повторить. Мне не жалко. ЭТО РАБОТАЕТ! Специально проверял запись, иначе не имеет смысла связываться. Идет куда надо и как надо. В нужную базу. Видимо, именно сам View и "раздупляет"

Ничего он не "раздупляет". Просто пишет в ту, из которой запущен SQL оператор.
А почему не стали использовать репликацию? чем не угодила?

[Alexius]

Здесь под View подразумевается Partitioned View, это функционал есть и в MS SQL 2000 и 2005. Partitioned View позволяет создавать представления объединяющие две и более таблиц с одинаковой структурой, расположенные на одном или нескольких физических серверах. При соблюдении определенных условий можно получить обновляемое представление с которым помимо операции SELECT можно выполнять INSERT, UPDATE и DELETE. Partitioned View является предшественником Partitioned Table (MS SQL 2005). Более подробную/техническую информацию можно узнать в BOL и на http://sql.ru.

[Михаил Андреев]

Спасибо за ссылку! Но это нужно для оптимизации работы больших баз данных. Здесь, насколько я понимаю, проблема другая :
Конечная цель - получить хранение разных компаний физически в разных базах MS SQL. Но с общими справочниками и возможностью взаимодействия между базами (копирование некоторых данных)
Не проще ли настроить репликацию? И надёжность выше будет. Или я что-то не догоняю?

[Владимир Максимов]

Цитата:

Сообщение от Михаил Андреев

А почему не стали использовать репликацию? чем не угодила?

Поскольку, как обычно, вопрос скатился к сакраметальному "а зачем это надо", объясняю:

1. Начальник всегда прав

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

2. Размер базы данных перевали за 200 ГБ.

Распределение базы данных позволит более гибко подойти к распределению нагрузки на сервера и выделению места под хранение.

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

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

Как решить эти проблемы через репликацию - не представляю. Или что подразумевается под термином "репликация"? Репликация где? На каком уровне?

На это обсуждения вопроса "Зачем?" считаю закрытым


Народ, по заданному вопросу кто-нибудь может что-то сказать или так и будем "дурью маятся"? Кто-нибудь работал по такой технологии? Или хоть можете сказать какие скрытые проблемы могут возникнуть?

[Михаил Андреев]

Цитата:

Сообщение от Владимир Максимов

Поскольку, как обычно, вопрос скатился к сакраметальному "а зачем это надо", объясняю:

1. Начальник всегда прав

Принято

Цитата:

Сообщение от Владимир Максимов

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

Тоже понятно

Цитата:

Сообщение от Владимир Максимов

2. Размер базы данных перевали за 200 ГБ.

Распределение базы данных позволит более гибко подойти к распределению нагрузки на сервера и выделению места под хранение.

Вопросов нет. Однозначно. Хотя, 200 ГБ это не терабайты.

Цитата:

Сообщение от Владимир Максимов

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

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

Как решить эти проблемы через репликацию - не представляю. Или что подразумевается под термином "репликация"? Репликация где? На каком уровне?


На это обсуждения вопроса "Зачем?" считаю закрытым

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

Цитата:

Сообщение от Владимир Максимов

Народ, по заданному вопросу кто-нибудь может что-то сказать или так и будем "дурью маятся"? Кто-нибудь работал по такой технологии? Или хоть можете сказать какие скрытые проблемы могут возникнуть?

На мой взгляд, решение теоретически работоспособно - Аксапта реально работает через запросы, и что там не таблицы, а какие-то конгломераты, ей сугубо фиолетово.
Но как будут решаться такие проблемы, как блокировка на время обработки транзакции в "тяжёлых операциях" (закрытие склада, например) или одновременная блокировка одной таблицы пользователями из разных баз, даже предположить не могу. Да и объём трудозатрат по настройке и поддержания таких баз....

[petr]

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

[Владимир Максимов]

Цитата:

Сообщение от petr

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

Это вопрос из разряда организационных. Решается не программными, а организационными средствами.

Хотя, можно и программным - влезть в код синхронизации (Application.dbSynchronize) и перехватить процесс модификации структуры через прямое обращение к базе. В теории - решаемая проблема.

[egorych]

А выполнение запросов на linked серверах Вас не пугает? На маленьких объемах это приемлемо а на больших?

[Михаил Андреев]

Цитата:

Сообщение от egorych

А выполнение запросов на linked серверах Вас не пугает? На маленьких объемах это приемлемо а на больших?

Дело даже не в больших объёмах. Как обеспечить не толщину канала (её обычно нарастить можно), а время отклика. Допустим, открываем форму Складские проводки. Таблица InventTrans местная, а таблица InventTable - на другом сервере... И... Сколько времени она будет открываться?
Это форма для примера. Но в ряде случаев делается десяток, а то и сотня запросов (всякие методы find, например). И всё это через какой-то канал, несколько серверов, в другую базу...
И для ВСЕХ таблиц!
А таких методов, которые выискивают одну запись в таблице, вагон, -ведь авторы аксапты не предполагали такое её использование.

[Владимир Максимов]

Цитата:

Сообщение от egorych

А выполнение запросов на linked серверах Вас не пугает? На маленьких объемах это приемлемо а на больших?

Вопрос опять не по теме, но тем не менее...

Вкратце: Нет. Не пугает. Хотя, конечно, практика покажет.

План запросов показывает, что MS SQL работает достаточно интелектуально. Торможение, конечно, есть. По грубым оценкам, в случае объединения данных с разных Linked-серверов - в несколько раз. Возможно, на порядок. Но здесь есть предмет для оптимизации. Хотя опять же вне заданного вопроса.

[Vadik]

Цитата:

Сообщение от Владимир Максимов

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

Безопасность - от кого?
От пользователей? Есть домены
От администраторов? Бесполезно, у них доступ будет всегда
Непонятненько (с)

Цитата:

Размер базы данных перевали за 200 ГБ.

Весь сыр-бор из-за экономии на СХД объемом менее 1 Тб? Это несерьезно (с)

Цитата:

Распределение базы данных позволит более гибко подойти к распределению нагрузки на сервера и выделению места под хранение.

И освоить бюджет на железо и лицензии для ОС и СУБД

Цитата:

На это обсуждения вопроса "Зачем?" считаю закрытым

Т.е. решение Вы уже приняли.. Тогда чего Вы хотите от общественности? Подтверждения того, что Ваша реализация - оптимальная?

Цитата:

Народ, по заданному вопросу кто-нибудь может что-то сказать или так и будем "дурью маятся"?

У Вас будут проблемы
а) с производительностью (странно, правда?)
б) трудоемкость сопровождения этого зоопарка вырастет ОЧЕНЬ сильно (одно лишь добавление поля в таблицу будет целым ритуалом, плюс обязательные проблемы с синхронизацией)
в) целостность данных в случае чего восстанавливать будет непросто (у Вас же есть какой-то обмен между разными компаниями)
Этого достаточно?

Цитата:

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

Я не работал. Проблем, лежащих на поверхности, столько, что скорее всего не буду и другим не советую. Вы методику, разработанную для VLDB, с соответствующим уровнем затрат, пытаетесь натянуть на задачу весьма среднего уровня (причем приложение этому будет всячески сопротивляться).

А все почему? Потому что аналитик, уровень технической подготовки которого неизвестен, навязывает решение техническим специалистам

Удачи. Она Вам потребуется

[Lazy_Tiger]

Ребята, 200Гб базка всего то... повод заниматься оптимизацией и ежедневно присматривать за ней есть. НО... такой изврат мутить - никакого резона. Данная схема не является рекомендованной, более того, когда я ее показал сотрудникам MS - они выпучили глаза и покрутили пальцем у виска.
Попробовал на одной из своих баз, не особо крупной, всего чуть более 130гб. Падение производительности - 1-2 порядка на элементарных запросах.
Вообщем вместо второго (третьего и далее) сервера бд поставьте нормальную дисковую подсистему и не морочьте голову. рекомендую IBM DS4700/DS4800 - их производительности для такой задачи более чем достаточно

и от кого защищаетесь и чем такое решение поможет мне тоже жутко интересно

[gl00mie]

Цитата:

Сообщение от Владимир Максимов

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

Цитата:

Сообщение от Lazy_Tiger

от кого защищаетесь и чем такое решение поможет мне тоже жутко интересно

Именно что. Очень грустно видеть, когда люди, которые "мышей не ловят" в той или иной тематике, пытаются предлагать какие-то там варианты технических решений непонятно чего. «Паранойя - профессиональное заболевание специалистов по безопасности, но, любители могут в этой области зайти гораздо дальше» (с) эпиграф к FAQ'у старой фидошной эхи ru.crypt. Если ваш аналитик э... обеспокоен вопросами защиты информации, то пусть и решает эти вопросы соответственно: первым делом путь распишет вероятные сценарии НСД (несанкционированного доступа) и модели нарушителя, а уже потом подгоняет технические решения, если у него есть подобающая на то квалификация. Человек боится, что кто-то получит доступ к финансовым отчетам по группе компаний? Ну так может пользователи пишут свои пароли на стикерах, расклеенных по периметру монитора, и какой-нить внедренный "водитель" (или еще кто) уже давно в пакетном режиме генерит нужные отчеты и сливает, куда надо, делая вид, что в обеденный перерыв за компом он просто раскладывает пасьянсы...
Сугубо из личного опыта: есть средства криптографической защиты, работающие прозрачно для приложений на уровне фильтров файловой системы. Они позволяют на лету надежно шифровать данные как на дисковых носителях, так и на всяких там стриммерах, и если сервер или резервную копию "унесут", то увидят лишь мусор. Но опять же надо хорошо проработать модель нарушителя, а то попадется какая-нить "паршивая овца", и все усилия пойдут прахом...

[Ned]

Хоть и жёстко человеку ответили, но правильно. Присоединяюсь. Вопросы масштабирования решаются аппаратными средствами. Можете сделать отдельный отчётный сервер. Писать транзакции одного типа в две разные базы смысла не имеет.

По поводу защиты данных gl00mie сказал исчёрпывающе - пусть ваш аналитик сделает список угроз и выписывайте предложения по защите напротив угроз.

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

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

[Владимир Максимов]

В общем, ответ большинства был ожидаемым. Как обычно, большинство вопроса вообще не прочитали. Поскольку, многие так и не поняли о чем же идет речь, повторю вопрос еще раз:

Если вместо таблиц MS SQL "подсунуть" AXAPTA View - какие будут последствия и возможные проблемы со стороны AXAPTA.

Я и сам могу написать большой трактат, что так делать нельзя, не стоит, не рекомендуется и т.д. и т.п. Но! Если Вам нечего сказать по существу вопроса, зачем Вы вообще что-то отвечаете? Чтобы разговор поддержать?

Я не спрашиваю, какие есть альтернативы. Я спрашиваю, какие будут проблемы. Неужели так трудно понять о чем спрашивают-то?

(...удалил пример, когда это "надо", поскольку не относится к сути вопроса...)

Если Вы по такой схеме не работали, откуда такая уверенность, что так делать нельзя? Просто потому, что лично для Вас это кажется непривычным?

Цитата:

Сообщение от Vadik

Проблем, лежащих на поверхности, столько, что скорее всего не буду и другим не советую.

Перечислите их, пожалуйста. Если возможно, без комментариев. Меня интересуют проблемы именно со стороны AXAPTA.

Цитата:

Сообщение от Lazy_Tiger

Попробовал на одной из своих баз, не особо крупной, всего чуть более 130гб. Падение производительности - 1-2 порядка на элементарных запросах.

О каких запросах идет речь? Можно пример? Кроме падения производительности, какие еще были проблемы?

[egorych]

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

[Михаил Андреев]

Цитата:

Сообщение от egorych

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

А там тем более будет "по барабану", так как "её" таблицы и индексы никакого отношения к данным иметь не будут