|
|
|
В дополнение к вопросу: Что лучше:одна "гиганская" бд или много "маленьких"
|
|||
|---|---|---|---|
|
#18+
Приложение разрабатывается общее для всех регионов. Есть РЕГИОНЫ, в которых есть ОРГАНИЗАЦИИ Например: 1. в регионе Пермь есть организация "Контора Василия Пупкина", и там же есть организация "Пермский подрядчик конторы Василия Пупкина" 2. в регионе Москва есть та же организация "Контора Василия Пупкина", и там же есть организация "Московский подрядчик конторы Василия Пупкина" Следует ли создавать в каждом регионе в Перми и Москве по одному серверу с одинаковыми по структуре таблицами БД? или Следует создать только один сервер в Москве и использовать общую базу данных с таблицами из которых остальные регионы будут брать необходимую информацию? Или, если использовать 1-й вариант следует все же подумать о том что когда-то вдруг станет так, что объекты таблицы "Пермского подрядчика конторы Василия Пупкина" вдруг станут нужны для обработки заказчика и подрядчика в Москве и наоборот => придется придумывать дополнительную связь между двумя базами данных... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 13:43 |
|
||
|
В дополнение к вопросу: Что лучше:одна "гиганская" бд или много "маленьких"
|
|||
|---|---|---|---|
|
#18+
akkolo-kakkolo , единый сервер хорош для поддержание "уникальности" элементов. Но может проиграть по производительности "раздельному" количеству серверов. А так же напрямую зависит от качества каналов связи... Т.ч. смотри сам... Потянет один сервер твои надобности? Иначе придется как-то решать проблему "уникальности" элементов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 14:14 |
|
||
|
В дополнение к вопросу: Что лучше:одна "гиганская" бд или много "маленьких"
|
|||
|---|---|---|---|
|
#18+
krvsa akkolo-kakkolo , единый сервер хорош для поддержание "уникальности" элементов. Но может проиграть по производительности "раздельному" количеству серверов. А так же напрямую зависит от качества каналов связи... Т.ч. смотри сам... Потянет один сервер твои надобности? Иначе придется как-то решать проблему "уникальности" элементов... +1 akkolo-kakkolo, смотри, что для твоего проекта больший риск: 1) не обеспечить требуемую производительность сервера + доступность и пропускную способность каналов связи (организационно-инфраструктурная проблема); Допустим, сервак помощнее взять может и не проблема. А вот какая у вас возможность влиять на каналы связи?... 2) не обеспечить уникальность (качество данных в системе). "Проблему уникальности" всегда приходится решать, даже на одном сервере (одной РСУБД). Она просто усложняется при наличии нескольких серверов, но эти проблемы решаются головой, организационными мерами и программным обеспечением. И главное: на текущий момент технологии репликации давно позволяют иметь несколько серверов, на при этом иметь на них "уникальные" значения (с очень небольшими задержками при синхронизации :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 14:35 |
|
||
|
В дополнение к вопросу: Что лучше:одна "гиганская" бд или много "маленьких"
|
|||
|---|---|---|---|
|
#18+
akkolo-kakkolo, Для начала ставьте 1 сервер. Потом по мере нагрузки будете лепить кластер. Собственно никаких проблем я невижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 15:02 |
|
||
|
В дополнение к вопросу: Что лучше:одна "гиганская" бд или много "маленьких"
|
|||
|---|---|---|---|
|
#18+
Злой БобрДля начала ставьте 1 сервер. Потом по мере нагрузки будете лепить кластер. Получится как тут http://proektkonsalt.ru/stati-pritchi-istorii/istorii-bayki/proekt-genezis/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 15:04 |
|
||
|
В дополнение к вопросу: Что лучше:одна "гиганская" бд или много "маленьких"
|
|||
|---|---|---|---|
|
#18+
[quot АнатоЛой]krvsa akkolo-kakkolo , на текущий момент технологии репликации давно позволяют иметь несколько серверов, на при этом иметь на них "уникальные" значения (с очень небольшими задержками при синхронизации :). То есть, если я правильно понял: 1. Два синхронизированных сервера 2. На каждом одна и та же полная копия БД со всеми данными (или на первом только своя копия + копия уникальных индексов 2-го, а на втором 1-го?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 15:04 |
|
||
|
В дополнение к вопросу: Что лучше:одна "гиганская" бд или много "маленьких"
|
|||
|---|---|---|---|
|
#18+
akkolo-kakkolo, Репликация возможна как между всеми серверами (вариант 1), так и выборочно (вариант 2). Все зависит от конкретной задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 15:13 |
|
||
|
В дополнение к вопросу: Что лучше:одна "гиганская" бд или много "маленьких"
|
|||
|---|---|---|---|
|
#18+
Злой Бобрakkolo-kakkolo, Репликация возможна как между всеми серверами (вариант 1), так и выборочно (вариант 2). Все зависит от конкретной задачи. + серверов не только 2 :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 18:58 |
|
||
|
В дополнение к вопросу: Что лучше:одна "гиганская" бд или много "маленьких"
|
|||
|---|---|---|---|
|
#18+
Основной сервер + реплицированные. Собственно, филиалы работают только с репликами. Далее, копия данных должна быть полная, но если сделать партиционирование по регионам, то и скорость обработки должна неплохо увеличиться. Делать много мелких БД - это соблазнительная, но плохая с точки зрения поддержки идея. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2013, 12:40 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38476621&tid=1541055]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
24ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 115ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...