Re: lug-bg: Натоварена база д анни

2005-07-28 Thread Sava Chankov
Aleksandar Valchev wrote:
 Здравейте.
 
 Имам следния проблем. Трябва ми база данни, която да поддържа околко 200-300 
 хиляди заявки на ден. Базата данни ще е доста натоварена и затова мисля, че 
 MySQL(със сигурност) и PostgreSQL няма да свършат работа.
 
 Единственото решение, което се сещам е Oracle, но не ми се иска да прибягвам 
 до платени бази данни и затова го оставям като следващ вариант.
 
 Ще се радвам на всякакъв отговор.

Как се разпределят процентно заявките за писане и четене? Ако клиентите, които
четат, не пишат, би могъл да разпределиш системата master-slave, като четците се
обръщат само към slave сървърите, а данните се обновяват само на master сървъра.

-- 
Sava Chankov Сава Чанков
software developer софтуерен разработчик
http://www.blueboard.biz блуборд


Re: lug-bg: Натоварена база д анни

2005-07-28 Thread Zhasmin Zhelev

Aleksandar Valchev wrote:


Здравейте.

Имам следния проблем. Трябва ми база данни, която да поддържа околко 200-300 
хиляди заявки на ден. Базата данни ще е доста натоварена и затова мисля, че 
MySQL(със сигурност) и PostgreSQL няма да свършат работа.


Единственото решение, което се сещам е Oracle, но не ми се иска да прибягвам 
до платени бази данни и затова го оставям като следващ вариант.


Ще се радвам на всякакъв отговор.

 


Помисли си пак за Postgre-то че ще почне един флейм.


Re: lug-bg: Натоварена база д анни

2005-07-28 Thread Ognyan Bankov

Aleksandar Valchev wrote:


Здравейте.

Имам следния проблем. Трябва ми база данни, която да поддържа околко 200-300 
хиляди заявки на ден. Базата данни ще е доста натоварена и затова мисля, че 
MySQL(със сигурност) и PostgreSQL няма да свършат работа.


Единственото решение, което се сещам е Oracle, но не ми се иска да прибягвам 
до платени бази данни и затова го оставям като следващ вариант.


Ще се радвам на всякакъв отговор.
 

За съжаление 200-300k заявки като за ориентир е доста общо. Много зависи 
от типа на приложението, съотношението read/write, необходимост от 
table/page/row locks и други.
Примерно паспортната система, която въведоха покрай смяната на личните 
документи имаше подобно (и по-голямо) натоварване, но там ставаше дума 
за HP машина за няколко милиона долара с db informix и пак грохваше (в 
интерес на истината заради калпав софтуер най-вече)...
Съвсем друга е историята, разбира се, ако става дума за web сайт с 
преобладаващи прости select-и, липса на нужда от locks, липса на 
периодично стартиращи се процедури и т.н.
Една проста сметка показва 30 заявки за 86400 секунди (24ч) = 3,47 
заявки на секунда средно. Ако това е примерно счетоводна система в която 
се пуснат дори една-две по сложни справки едновременно и/или потегли 
някоя тежка периодична процедура - останалите потребители ще има да 
чакат маса време и на най-добрия 2х x86 процесорен сървър с Oracle...