gifts2017

Распределенные базы данных

Опубликовал Василий Казьмин (awk) в раздел Администрирование - Распределенная БД (УРИБ, УРБД)

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

Распределенные базы данных.

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

Давайте определим общую схему которую будем иметь до организации взаимодействия.

Где:

Цетр — это основная база данных в которой происходит анализ. Она должна содержать все необходимые данные для анализа.

Перифирия1, Перифирия2, Перифирия3 — Базы в которых происходит ввод данных.

Конечно, это все условно. Т. к. и в Центральной базе может происходить ввод информации, и в периферийных базах требуется информация по компании в целом (например, информация о заблокированных клиентах).

Где:

Красный — информация которая должна присутствовать во всех базах и не требующаяся для анализа состояния.

Зеленый — информация которая должна присутствовать во всех базах и требующаяся для анализа.

Желтый — информация которая требуется для анализа, но специфична для каждой базы.

Синий — информация специфичная для каждой базы не требующаяся для анализа.

Теперь можно поговорить о топологии. Топологии:

  1. Кольцо

  2. Звезда

  3. Смешанная топология.

Топология кольцо.

Кроме простоты организации обмена, данная схема, преимуществ не содержит. Хотя и простота организации обмена, то же является спорным преимуществом. Недостатков же напротив, хоть отбавляй.

Топология звезда.

Наверное самая распространенная топология. Из минусов ,только объем трафика проходящего через центральную базу. Плюс ко всему центральная база становится критичным ресурсом.

Смешанная топология.

Из плюсов: отказоустойчивость и снижение нагрузки на центральную базу, но сложность реализации перекрывает все плюсы от данного решения.

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

Классификация обмена.

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

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

  2. Полуавтоматический обмен. Под ним будем подразумевать обмен при котором требуется вмешательство человека. Либо для его инициализации, либо для внесения исправлений которые накапливаются в процессе автообмена (то есть, когда вроде бы все автоматически, но без периодического вмешательства человека обмен встаёт, при отсутствии внештатных ситуаций).

  3. Ручной обмен. Когда для обмена информацией постоянно требуется человек. Даже на этапе перемещения файлов обмена из точки А, в точку Б.

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

  1. Кто в случаи внештатной ситуации должен производить ручной обмен.

  2. Как часто он должен происходить.

  3. Должен ли производящий ручной обмен заниматься другими делами и если должен, то какой приоритет у обмена.

  4. Что делать если недоступен ответственный за ручной обмен.

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

Виды транспорта.

Под транспортом будем понимать протоколы передачи данных, с помощью которых можно передать информацию из точки А в точку Б.

  1. Физический носитель (Флеш-карта, CD-R(CD-RW), HDD и т.д.).

  2. Телефонная линия (модем).

  3. Локальная сеть.

  4. Интернет.

Давайте попробуем определить плюсы и минусы.

Плюсы первого варианта:

  1. Простота реализации.

  2. Практически всегда отказывает последним.

Минусы первого варианта:

  1. Скорость передачи информации.

  2. Цена.

  3. Не позволяет организовать обмен кроме как в ручном режиме.

Плюсы второго варианта:

  1. Цена.

  2. Высокая степень отказоустойчивости.

Минусы второго варианта:

  1. Скорость передачи информации.

  2. Труднодоступность оборудования.

  3. Плохое качество канала передачи.

Плюсы третьего варианта:

  1. Скорость передачи информации.

  2. Простота реализации.

Минусы третьего варианта:

  1. Цена реализации пропорциональна квадрату расстояния.

Плюсы четвертого варианта:

  1. Цена прямо пропорциональна расстоянию от провайдера.

Минусы четвертого варианта:

  1. Информация проходит через неконтролируемую территорию.

  2. Плохая отказоустойчивость.

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

Варианты передачи информации через интернет.

Первые три варианта не рассматриваю, из-за их тривиальности. Так же не будут рассмотрены бесплатные интернет-сервисы. А сводить задачу мы будем к синхронизации двух каталогов. Какие же тут есть варианты?

  1. Электронная почта.

  2. FTP/SFTP/WebDAV.

  3. SOAP/REST (веб сервисы)

  4. VPN (Virtual Private Network).

Начнем с конца. Вариант организации VPN, я считаю, самым простым и дешевым, так-как для его организации требуется то, что должно быть у каждой организации подключенной к сети интернет. А именно это качественный брандмауэр. Цены на брандмауэр могу привести только свои, так-как другие не сравнивал. Это либо порядка 3 000 рублей за D-Link, либо 2 500 рублей за настройку брандмауэра и подключение точки к интернет плюс стоимость компьютера (вполне подойдет Pentium III 500 256 ОЗУ ~ 1 000 рублей). Как минус — это необходимость настройки каждой точки присутствуя физически.

Вариант с SOAP, для настройки обмена, является, наверное, самым дорогим из вариантов. Хотя я его и реализовывал, но затруднюсь ответить на вопрос о том за сколько бы я его реализовал. Скорее мой ответ был бы 1 500 рублей (за установку системы) плюс 1 500 рублей (за установку и настройку web сервера) плюс 750 рублей в час за разработку программы обмена плюс стоимость компьютера под эти цели (примерно от 15 000 до 300 000 рублей в зависимости от нагрузки). Из преимуществ можно отметить минимальные задержки перед началом передачи данных.

Из варианта номер два я бы выделил только SFTP. Так как При равной с FTP вариантом стоимостью, имеет перед FTP, два неоспоримых преимущества. Первое это данные не передаются в открытом виде (шифруются), а второе реализовать его очень просто. Вариант с WebDAV имеет право на жизнь, но встречается редко и скорее является экзотикой. Цены для первых двух вариантов это 3 000 рублей за настройку плюс компьютер (примерно 7 000 рублей, хотя при малой нагрузке можно и удешевить).

Электронная почта — это один из сложнейших вопросов администрирования. Ее настройка требует высокой квалификации специалиста, так как тут нет шаблонов. Так что цена этого варианта может превысить стоимость веб сервисов. Но в отличии от веб-сервисов эта цена более-менее предсказуема (6 000-12 000 рублей за настройку почтового сервера плюс компьютер от 1 000 до 180 000 рублей в зависимости от нагрузки). Имеет смысл если электронная почта или уже есть, или планируется.

Я специально не стал рассматривать другие варианты, так как рассмотренных вполне достаточно, для организации транспортировки.

Заключение.

Как-то неожиданно, скажете вы? Да, но все вопросы для расчета вариантов реализаций мы рассмотрели. Осталось выбрать приемлемый по цене и функционалу, и нанять специалистов для реализации (как вариант реализовать самому сэкономив/заработав деньги).

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Евгений Ильяшенков (ЗАК) 20.01.10 17:51
Как то странно расписаны плюсы и минусы топологий ... в вики и то лучше описание топологий идет ;)
2. 321 (fikuz@mail.ru) 20.01.10 18:25
Думаю, что Вам, для начала, не мешало бы определиться. Все таки "Перифирия" или "Периферия"? После этого все остальное покажется банальностью :-)
3. mastakw (mastakw) 20.01.10 19:15
Нет самого главного - механизма реализации обмена применительно к тематике сайта.
Выбор механизма значит важнее !!!
4. Василий Казьмин (awk) 20.01.10 19:26
(3) Выбор механизма это самое важное.. Не сделав этого, нельзя ничего реализовать. Системы разработанные "на глазок" - работают крайне плохо. По крайней мере мне не известна ни одна такая система, работающая в автоматическом режиме. А реализаций получается слишком много, что бы уложить их в рамки одной статьи. А применительно к 1С это пережевано и не один раз. Но 1С это только верхняя часть айсберга.
5. Василий Казьмин (awk) 20.01.10 19:30
(2) Спасибо, но ни слова Периферия1, ни Перефирия1 в словаре нет. Остальное учту на будущее.
6. Василий Казьмин (awk) 20.01.10 19:36
(1) ТОПОЛО'ГИЯ, и, мн. нет, ж. [от греч. topos — место и logos — учение] (мат.).
Часть геометрии, исследующая качественные свойства фигур (т. е. не зависящие от таких понятий, как длина, величина углов, прямолинейность и т. п.). Странно - потому что речь идет о построении принципа обмена, а не сети.
7. mastakw (mastakw) 20.01.10 20:15
(4) Так ка собственно тема о 1С - именно разные ограничения механизмов недают реализовывать разные топологии и накладывают дополнительные плюсы/минусы.
Если тема получит продолжение - то да.
Иначе это просто ниочем. 1С штука предметная.
8. Валентин Терёхин (Valet) 20.01.10 22:39
Заголовок не соответствует содержанию.
О распределенных базах меньше чем в ЖКК.
А механизмы обмена применительно к распределенным базам не раскрыты.
Если убрать про топологию и заголовок, то о том, что здесь рассказывается про распределенные базы никто не догадается.
Общие фразы ни о чем, большинство из которых спорны.
Минус:Информация проходит через неконтролируемую территорию

Банковские структуры, почему то не боятся работать через интернет.
9. Василий Казьмин (awk) 21.01.10 08:56
(7) Могу поспорить, что 1С может создавать файлы для обмена. Так что любой обмен сводится к транспортировке этих файлов. Самый простой пример - это функции ЗначениеВФайл() и ЗначениеИзФайла().
(8)
1. Статья - это примерно 10% заголовка (я с вами согласен надо другой придумать).
2. Убирать не надо, а то ведь и не догадаются :)
3. Причем здесь страх? Минус этот не очевиден, но есть. Во первых вы не контролируете доступность - следовательно не можете её гарантировать. Во вторых вы не контролируете защиту информации.
4. Вы почитайте что гарантирует банк. Он не гарантирует, что с вашего счета не уйдут деньги. Он гарантирует, что вашим счетом может управлять только человек - владеющий некой идентификационной информацией.
10. mastakw (mastakw) 21.01.10 09:08
Рассматривать организацию распределения баз без рассмотрения методов и свойств - не полезно.
Так как эти методы и свойства накладывают кучу ограничений.
11. Василий Казьмин (awk) 21.01.10 09:54
(10) Укажите ограничение и я его обойду (вероятность 90%)..
12. mastakw (mastakw) 21.01.10 13:20
(11)
применение только УРБД и схема кольцо
13. Василий Казьмин (awk) 21.01.10 13:54
(12) Применение только УРБД - это не ограничение методов и свойств 1С 7.7 (я угадал версию?). Это административное ограничение.
14. Василий Казьмин (awk) 21.01.10 14:01
(12) http://www.pb.ru/ru/manager/po/
3. Обмен данными в любом направлении

"Менеджер" совершает обмен вне системы "центральная база-периферия", в которой любая информация для достижения адресата должна проходить "центральную базу" (топология обмена - "звезда"). Все участники равноправны и могут совершать обмен по любым направлениям (топологию обмена пользователь настраивает сам). При обмене данными между разными подразделениями фирмы или между фирмами-партнерами эта возможность будет оценена по достоинству.
15. mastakw (mastakw) 21.01.10 14:06
(13)
Административное - это потому что через меню администрирование ? :)
Это ограничение встроенной методики.

Считаю что рассматривать топологии без методик и средств реализации - неполезно !
16. mastakw (mastakw) 21.01.10 14:09
17. Василий Казьмин (awk) 21.01.10 15:05
(15)(16)
1.
АДМИНИСТРАТИ'ВНЫЙ, ая, ое (офиц.).
1. Прил. к администрация. А. отдел исполкома. Административные органы. || Относящийся к системе управления, к органам администрации. Административная единица. А. центр. 2. Производимый распоряжением органов исполнительной власти. Административное взыскание. Выселение в административном порядке. 3. Необходимый для администратора, администраторский. Административные способности.

2. Куда простите встроенной? Язык 1С то же встроен (если мы об одном и том же месте) и причем включен во все поставки (в отличии от УРБД).
3. Топология обмена как раз и предполагает абстрагирование от методик и средств реализации. Рассмотрение методик и реализаций противоречит определению топологии.
4. Я прекрасно знаю оба инструмента. И что, что УРБД не МОД? От этого на западе солнце встанет?
5. Я понимаю, что еще Ленин использовал метод опровержения позиции оппонента, гиперболизацией его слов, до абсурда. Но при этом он не выподал из контекста разговора. Так что мы говорили об ограничениях 1С (7), а не об ограничениях знаний программистов 1С или желаний (распоряжений) каких-либо субъектов.
18. mastakw (mastakw) 21.01.10 20:22
(17)
"..Я прекрасно знаю оба инструмента. И что, что УРБД не МОД.."
вот об этом стоит.
а разбирать двигатель через выхлопную трубу - не стоит.
19. Василий Казьмин (awk) 22.01.10 09:14
(18) Может тогда и репликацию средствами MSSQL рассмотреть? Я её то же реализовывал. А еще "Конвертация данных" есть, и т.д. И тема станет бесконечной. Просто мы смотрим с разных позиций. Я с точки зрения менеджера, а вы с точки зрения программиста. Я не говорю, что не правильна ваша точка зрения. Просто, она неприемлема на первоначальном этапе проектирования. Изначально надо ответить на вопрос, "Для чего делать?", потом на вопрос "Что делать?", а вопрос "Как делать?" - должен появляться последним. На вопрос "Как" нельзя ответить, пока мы не знаем "Что надо", а вопрос "Что надо?" с предпосылкой "что бы было" - бессмысленный.
20. mastakw (mastakw) 22.01.10 11:44
(19)
"Может тогда и репликацию средствами MSSQL рассмотреть" - именно, и будет вам плюсище от пользователей.
Я подозреваю, что плюсы/минусы вы основываете как раз на знании разных механизмов обмена, их возможностях и недостатках. И неподготовленному человеку (а как раз на них сориентирована статья) невозможно понять почему это именно так - как утверждаете вы.
Методически правельнее рассмотреть механизмы, а потом вернуться к топологии, и лиш затем начать проэктирование. Иначе - врыв мозга :)
21. ddis (rebuzx) 27.01.10 09:45
Странная статья!
И причем тут топологии!
Структура УРБД может быть такова, что ни одна топология под неё не подлезет. Например когда Периферия может быть ещё и центром для других периферий, а те в свою очередь центрами для других. И при этом везде свои ограничения передачи данных. Тут уже квадратиками и разноцветными кружочками не отделаешься.
Ну, а каким образом вам передавать файлы обмена (FTP, SMTP и т.д.) это уже технический вопрос.
Не советую начинающим разобрать эту статью!!!
22. ddis (rebuzx) 27.01.10 09:46
Странная статья!
И причем тут топологии!
Структура УРБД может быть такова, что ни одна топология под неё не подлезет. Например когда Периферия может быть ещё и центром для других периферий, а те в свою очередь центрами для других. И при этом везде свои ограничения передачи данных. Тут уже квадратиками и разноцветными кружочками не отделаешься.
Ну, а каким образом вам передавать файлы обмена (FTP, SMTP и т.д.) это уже технический вопрос.
Не советую начинающим разобирать эту статью!!!
23. ddis (rebuzx) 27.01.10 09:46
Странная статья!
И причем тут топологии!
Структура УРБД может быть такова, что ни одна топология под неё не подлезет. Например когда Периферия может быть ещё и центром для других периферий, а те в свою очередь центрами для других. И при этом везде свои ограничения передачи данных. Тут уже квадратиками и разноцветными кружочками не отделаешься.
Ну, а каким образом вам передавать файлы обмена (FTP, SMTP и т.д.) это уже технический вопрос.
Не советую начинающим разбирать эту статью!!!
24. ddis (rebuzx) 27.01.10 09:48
СОРИ ЗА ПОВТОРЕНИЯ!!! :oops:
25. Василий Казьмин (awk) 27.01.10 11:53
(23)
1. УРБД (если мы применяем это выражение к 1С) - имеет четкое определение. И оно не реализует то, о чем вы говорите.
2. Топология, которую вы описали имеет ряд названий (гирлянда, снежинка, дерево). Данные топологии являются лишь частным случаем смешанной топологии.
3. Квадратики и кружочки - это всего-навсего способ графического отображения информации. И рисовать их придется ОБЯЗАТЕЛЬНО (если вы будете делать что-то серьезное). Я сам ненавидел блок-схемы, пока не начал писать код за деньги.
3. Про то как передавать файлы, надо думать до того как их плодить. Пример: Вы делаете выгрузку в xml (планы обмена, КД и т.д.). Теперь давайте передадим эти файлы. И тут оказывается (гипотетически, но реально), что вы в месте где недоступен высокоскоростной канал связи. А xml - это формат, который не экономит на объемах (у меня генерировались файлы, размером более 100 Мб). Теоретически можно оптимизировать... И тут вы встаете перед делемой. Либо, сказать заказчику, что обмен нереален, либо переписывать все заново. В обоих случаях вам придется иметь неприятный разговор с заказчиком. При описании транспортов вначале (в том числе их технических характеристик), вы можете сгладить разговор и за оба варианта получить деньги. Если вы это вначале не предусмотрели - то рискуете не получить денег за работу (я бы не заплатил).
26. Василий Казьмин (awk) 27.01.10 11:56
(22) Топологии при том, что начинается разработка именно с них. А точнее подбора топологии, под задачи заказчика.
27. ddis (rebuzx) 27.01.10 12:27
(25) Каша!
1. УРБД как её не определяй и есть УРБД и рисовать вы её будете в точном соответсвии со структурой удалённых филиалов (организаций, подразделений). И она не определяется топологией (звезда снежинка и т.д.), она оределеяется структурой предприятия (организации, подразделения), а там может получиться структура любой сложности! Не нужно УРБД, сравнивать с локальными сетями, где круг топологий чётко определён.
2. Согласен блок-схема обязательна. (Вот только как вы её назовёте "Структура УРБД на предприятии N составлена по топологии СНЕЖИНКА") :D
4. А тут ничего ненадо думать и плодить ничего не надо. Вопрос только в том, как срочно необходим обмен данными? Если нет интернета, то есть CD + экспресс почта или обычная Почта России. Если вообще ничего нет, то здравый смысл сразу Вам подскажет нужен ли там УРБД.
И вообще, разговор об УРБД заходит только после полного обследования предприятия, бизнес процессов, его структуры. На этот момент Вы уже будете знать где что есть, а где нету.
28. Василий Казьмин (awk) 27.01.10 17:03
(27)
1. УРБД - это (в контексте 1С) компонента для седьмой версии.
2. Если честно, то какая разница что между чем и как связано... Сеть она и есть сеть... Неважно что это за сеть... Это и есть смысл топологии...
3. Как назвать - это вопрос маркетинга...
4. Полное обследование??? Обследовать можно бесконечно (особенно когда это делают как рекомендует 1С)... Мне больше нравится подход SAP/R3 (все что вам нужно есть в SAP/R3, чего там нет вам не нужно). Я не говорю что обследовать не надо, но в 90% случаев все бизнес-процессы стандартны. Когда говорят, о бизнес-процессах специфичных для фирмы, в 90% случаев это:
50% стандартные бизнес-процессы которые изобрели заново
25% это бизнес-процессы которые позволяют воровать у хозяев.
25% неправильные бизнес-процессы, созданные по незнанию предметной области.
5. Здравый смысл не всегда есть у заказчика. Какой здравый смысл оправдает воровство 5000$ при обороте 50 000$ в месяц (пиратское ПО)? Или покупку ПО просто потому, что оно есть у всех?
30. Ирли Бёрд (EarlyBird) 02.06.12 06:30
Уже больше двух лет прошло с момента публикации, а автор до сих пор не удосужился исправить грамматическую ошибку на рисунках.
О каком плюсе тут можно говорить?

Это просто ё...аный стыд!
Лень и нежелание реагировать на конструктивную критику - автору позор.

Автор! Батенька!
ПерифЕрия.


ПерифЕрия!


ПерифЕрия!
31. Василий Казьмин (awk) 03.06.12 00:06
(30) EarlyBird,
Лень и нежелание реагировать на конструктивную критику - автору позор.
Позор, позор. Ну дык - минусуй. -5 статья снята с публикации. Я сейчас то же минус влеплю... Чьерт... Сайт не дал... Говорит я автор статьи...
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа