Одна база vs несколько баз.

← →
Заказчик (2011-09-05 19:26) [0]

Вопрос возник.
Есть несколько организаций, связанных документооборотом. Исполнитель говорит «Давайте каждой организации поднимем свою базу данных, свой сервер приложений. И между базами организуем меведомственный обмен. Правда, все их сложим на одном сервере в виртуальных машинах.» Одним из основных пунктов мотивации такого решения «Быстрее работает. Если делать 10 запросов к 10-ти базам, в каждой из которых 100 записей и 10% ресурса сервера, то это быстрее, чем делать 10 запросов к одной базе, в которой 1000 записей и 100% ресурса сервера». СУБД — PostgreSQL.
Собственно вопросы:
1) Как отговорить от такого кривого решения (разделение баз по организационному признаку)?
2) Неужели так быстрее? (на практике, почти каждый документ присутствует в двух трех базах и при многобазовом подходе будет повторяться)

← →
xayam © (2011-09-05 19:35) [1]

> 1) Как отговорить от такого кривого решения (разделение баз по организационному признаку)?

XSLT/XML объясни им что такое :) Может поймут.
Если нет, то нужно писать лекцию о стремлении целого к независимости от частей...

> 2) Неужели так быстрее? (на практике, почти каждый документ
> присутствует в двух трех базах и при многобазовом подходе
> будет повторяться)

ты извини, но 1000 записей это везде быстро будет и не показатель, показатель когда 1000000 и больше записей.

← →
Заказчик (2011-09-05 19:37) [2]

> XSLT/XML объясни им что такое :) Может поймут.

Может книжка какая есть или статья? А то аргумент "таких монстров не строят" меня добивает. ((

> ты извини, но 1000 записей это везде быстро будет и не показатель,
> показатель когда 1000000 и больше записей.

Хорошо... 10 млн и 1 млн. Порядок примерно такой.

← →
Slider007 © (2011-09-05 19:42) [3]

У нас на предприятии (мясное производство) стоят термокамеры для варки колбасы. С термокамерами идет комп с ПО, работающим с MS SQL Server. Я когда в первый раз увидел, чуть не офигел - примерно раз в неделю ПО создает новую базу на сервере и работает с ней. Т.е. каждый месяц +4 базы :).
Оборудование и ПО закуплено в Германии за бешеное бабло.

← →
xayam © (2011-09-05 19:50) [4]

> Заказчик (05.09.11 19:37) [2]
> Может книжка какая есть или статья?

может и есть, надо искать. Тебе же чисто техническая видно не подойдёт.

> А то аргумент "таких монстров не строят" меня добивает

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

← →
xayam © (2011-09-05 19:56) [5]

> Хорошо... 10 млн и 1 млн. Порядок примерно такой.

это в самой большой таблице 10 млн записей?
это ещё терпимо должно быть, хотя смотря какие запросы.
Но если больше записей то нужен оракл наверное уже.

← →
Заказчик (2011-09-05 19:57) [6]

> У нас на предприятии (мясное производство) стоят термокамеры
> для варки колбасы. С термокамерами идет комп с ПО, работающим
> с MS SQL Server. Я когда в первый раз увидел, чуть не офигел
> - примерно раз в неделю ПО создает новую базу на сервере
> и работает с ней. Т.е. каждый месяц +4 базы :).
> Оборудование и ПО закуплено в Германии за бешеное бабло.
>

Наверное, старые данные не нужны. Документооборот - иное дело. Архив то по любому будет создаваться отдельно и выгружаться.

> может и есть, надо искать. Тебе же чисто техническая видно
> не подойдёт.
Подойдет. Выводы бы понятные были.

> Насколько серьёзны эти организации каждая в отдельности
> друг без друга?
> Если зависимость между ними действительно очень большая
> и они не собираются от неё избавляться, то возможно общая
> инфор. среда только упростит дело и раздельно городить действительно
> не нужно. Но если позже кто-то "передумает" то переделывать
> видно придётся всё очень сильно.
Раздельные юридические лица. По поводу "передумать" не совсем понятно. "Передумать" не могут.

← →
xayam © (2011-09-05 20:01) [7]

> Подойдет. Выводы бы понятные были.

Имхо, упор вообще лучше сделать не на техническую часть, а например на поддержку такой разделённости... Каждой своего отдельного админа выделять? Это выльется в копеечку нефиговую в конечном итоге.

← →
Заказчик (2011-09-05 20:08) [8]

>
> Имхо, упор вообще лучше сделать не на техническую часть,
> а например на поддержку такой разделённости... Каждой своего
> отдельного админа выделять? Это выльется в копеечку нефиговую
> в конечном итоге.

Зачем... "один админ следит за двумя-тремя десятками баз на одном мега-сервере"

← →
Anatoly Podgoretsky © (2011-09-05 20:12) [9]

> Slider007 © (05.09.11 19:42) [3]
> У нас на предприятии (мясное производство) стоят термокамеры
> для варки колбасы. С термокамерами идет комп с ПО, работающим
> с MS SQL Server. Я когда в первый раз увидел, чуть не офигел
> - примерно раз в неделю ПО создает новую базу на сервере
> и работает с ней. Т.е. каждый месяц +4 базы :).
> Оборудование и ПО закуплено в Германии за бешеное бабло.
>

Это нормально, когда редакция Express или MSDE.
Файрвол вообще несколько баз создает каждый день. и удаляет, физически по одной, самой старой в день. Ничего плохого в этом нет. Ресурсы эффективно используются, ни диск не перегружается, ни лимит на размер базы.

← →
Anatoly Podgoretsky © (2011-09-05 20:14) [10]

> xayam © (05.09.11 19:56) [5]

Чего же ты так не любишь других производителей, Оракл не единственный кто может работать с петабайтными базами.

← →
xayam © (2011-09-05 20:14) [11]

> Зачем... "один админ следит за двумя-тремя десятками баз на одном мега-сервере"

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

← →
Anatoly Podgoretsky © (2011-09-05 20:15) [12]

> Каждой своего отдельного админа выделять

Да отдельного админа, но на 50-100 серверов.

← →
Anatoly Podgoretsky © (2011-09-05 20:17) [13]

Обычный, основной способ маштабирования, это разносить базы по разным машинам, а на одной по разным файловым группам.

← →
Заказчик (2011-09-05 20:20) [14]

> Обычный, основной способ маштабирования, это разносить базы
> по разным машинам, а на одной по разным файловым группам.

А чем негожа в данном случае репликация, если так уж исполнитель боится за мощности?
Объем, по грубым подсчетам, составил около 10 Тб. Возможности использовать такие хранилища есть.

← →
xayam © (2011-09-05 20:20) [15]

> Обычный, основной способ маштабирования

а чего тут масштабировать? Если 10 млн максимум, остальное архив...

← →
xayam © (2011-09-05 20:22) [16]

> Объем, по грубым подсчетам, составил около 10 Тб

чего-то до фига. [15] сорри есть что масштабировать

← →
Заказчик (2011-09-05 20:24) [17]

> чего-то до фига. [15] сорри есть что масштабировать

Файлы (основной объем) можно и не в БД писать а на диск. Не принципиально.

← →
xayam © (2011-09-05 20:31) [18]

> Заказчик (05.09.11 20:24) [17]
> Файлы (основной объем) можно и не в БД писать а на диск. Не принципиально.

так а база сколько объем примерно?

> А чем негожа в данном случае репликация, если так уж исполнитель
> боится за мощности?

Есть хорошая книжка, но по MySQL: Бэрон Шварц MySQL Оптимизация производительности 2-е издание ISBN 978-5-93286-153-0
Много интересного и на тему репликации в том числе. Но пока на практике не применял :(

← →
Kerk © (2011-09-05 20:36) [19]

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

← →
Заказчик (2011-09-05 20:43) [20]

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

Вот может методика какая есть или статья. Что "да... базы разделяют если сеть плохая (в этом случае репликация) или объем данных большой (в этом случае можно функциональное разделение, одни таблицы на один сервер, другие - на другой) или скорости не хватает (опять же репликация)". Причины разделять организационно не вижу. Тем более, что данные достаточно сильно пересекаются.

← →
xayam © (2011-09-05 20:46) [21]

← →
Anatoly Podgoretsky © (2011-09-05 20:46) [22]

> Заказчик (05.09.2011 20:20:14) [14]

По сути это не большая база, только в наших маштабах она такой кажется.
Хранилище - дисковая стойка, на несколько сотен винчестеров, и грамотное
разбиение по шпинделям и группам.
Если база - компьютер, то есть вероятность поместить всю или часть в память,
а если несколько баз то уже придется делиться.
Вообще если хочешь более квалифицированое обсуждение, то подпишись на форум
MS SQL Server на сайте sql.ru

← →
Anatoly Podgoretsky © (2011-09-05 20:49) [23]

> Kerk (05.09.2011 20:36:19) [19]

При этом на виртуальных серверах.
Лапшу вешают.

← →
Ega23 © (2011-09-05 20:54) [24]

Постгрес - хорошая СУБД, мощная. Поднимайте одну базу на одном сервере и не парьтесь.

← →
Заказчик (2011-09-05 20:54) [25]

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

База - именно база. В каждой базе копия справочников. Для каждой базы поднимается своя копия сервера приложений (web-доступ). При обмене документами между базами и там и там хранится тело документа. И вообще городится отдельный огород для обмена между базами.

> Вообще если хочешь более квалифицированое обсуждение, то
> подпишись на форум
> MS SQL Server на сайте sql.ru
http://www.sql.ru/forum/actualthread.aspx?tid=878300&pg=-1
СУБД PostgreSQL

← →
Anatoly Podgoretsky © (2011-09-05 21:03) [26]

Ну поищи там же PostgreSQL
Все таки специализированый форум лучше чем специализированая трепаловка

← →
xayam © (2011-09-05 21:05) [27]

> лучше чем специализированая трепаловка

++
:)

← →
Sergey Masloff (2011-09-05 21:22) [28]

Anatoly Podgoretsky © (05.09.11 20:14) [10]
>Чего же ты так не любишь других производителей, Оракл не единственный >кто может работать с петабайтными базами.
Единственный из них у которых в РФ нормальный саппорт и нормальное коммьюнити
;-)

Но что-то мне кажется что по сабжу и постгрес и MS SQL и еще десяток вполне справятся с задачей

← →
Заказчик (2011-09-05 21:28) [29]

А что по поводу утверждения

> Если делать 10 запросов к 10-ти базам,
> в каждой из которых 1 млн записей и 10% ресурса сервера,
> то оно работать будет быстрее, чем делать 10 запросов к одной базе, в которой
> 10 млн записей и 100% ресурса сервера

Мне одному кажется, что это - не так?

Что такое 10% ресурсов сервера в базе ?

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

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

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

Так ведь физический сервер у них один все-равно.

> Так ведь физический сервер у них один все-равно.

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

> Игорь Шевченко © (05.09.11 23:58) [32]

Боюсь, overhead от N-го количества ОС и СУБД на одном сервере сожрет всю теоретическую выгоду.

Kerk © (06.09.11 00:12) [33]

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

> Anatoly Podgoretsky © (05.09.11 20:14) [10]
> Чего же ты так не любишь других производителей, Оракл не
> единственный кто может работать с петабайтными базами.

я оракл "не люблю", поскольку не знаю.
Но они с некоторых пор имеют отношение к MySQL, посему...

← →
Заказчик (2011-09-06 06:15) [36]

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

А что подразумевается под координатором? Координатор виртуальных ОС?

> [34] Игорь Шевченко © (06.09.11 00:16)

> Зачем-то делают виртуальные серверы.

проще разделять ресурсы только и всего. чтобы конкретно взятому пользователю можно было выделить 500 MHz CPU и 256 Mb ОЗУ.

> xayam (06.09.2011 00:27:35) [35]

Не знаешь, а советуешь.

> Eraser (06.09.2011 06:28:37) [37]

При том с одним ядром и очень медленный диск.

Одна база vs несколько баз. Найти похожие ветки