Изпечатай

[gat3way]

Нещата в случаят далеч не са прости и не виждам как ги правите тези сметки "база с еди си колко клиента и еди си какъв обем ще върви добре на...".

Има огромно значение каква е схемата, къде има индекси и най-вече какви са access pattern-ите. Обемът на базата не е толкова важният въпрос.

Примерно аз търкалям ей тази база:

http://www.gat3way.eu/crack/stats.php

която е бекенд на тази доволно проста и грозна система:

http://www.gat3way.eu/crack/search.php

И заявки определено има (не толкова защото много хора са се засилили да ме запитват за тези хешове, а защото има разни доста по-посещавани сайтове, които като им пратят заявка ходят и я препращат на няколко подобни уеб-базирани системи, като моята например). В крайна сметка натоварването далеч не е голямо, но понякога има някакви пикове.

Това (54GB база) върви на виртуална машина само с 512МБ РАМ, която споделя с apache/php на същата машина и това му е пределно достатъчно. Таблиците са много прости (въпреки че са огромни), има сложен един индекс и проблемът ми е че заради същият индекс, INSERT-ите се влачат безумно много за разлика от SELECT-ите. Всяка заявка през уеб интерфейса се състои в четири SELECT-а и както можете да проверите, това става доста бързо за база с общо близо 500 милиона реда.

Също така убеден съм че при настоящето положение и 10 пъти по-голяма да беше базата (стига да имах място на диска), щеше да се държи почти точно толкова добре колкото сега. Единствено трябва новите данни да ги разбивам в нови таблици, което е ограничение, за което не виждам workaround - главно защото има един момент от който нататък тъпченето на нови полета в таблицата става доволно грозна работа и единственото решение е да се направи нова таблица. Но моето е много прост случай, който въпреки това илюстрира прекрасно колко значение има обема на базата

Сега въпросът е че при мен INSERT-и и UPDATE-и се случват много рядко, следователно нямам проблеми с локвания на таблици, конкурентност и т.н. Така че всичко е въпрос на access pattern-и и организация на таблиците. Тези неща трябва да се вземат предвид и да се премислят добре на първо време. Стотици пъти по-малка база, но с по-сложна схема и достатъчно кофти access pattern-и, може да се държи смазващо по-зле дори на много по-мощен хардуер.

[romeo_ninov]

...
Също така убеден съм че при настоящето положение и 10 пъти по-голяма да беше базата (стига да имах място на диска), щеше да се държи почти точно толкова добре колкото сега. Единствено трябва новите данни да ги разбивам в нови таблици, което е ограничение, за което не виждам workaround - главно защото има един момент от който нататък тъпченето на нови полета в таблицата става доволно грозна работа и единственото решение е да се направи нова таблица. Но моето е много прост случай, който въпреки това илюстрира прекрасно колко значение има обема на базата
....

Това е една от причините големите бази да предлагат опция за партициониране на информацията и разни други трикове с разделените тейбълспейсове за индекси, raw томове и т.н.

[plamen_f]

В същност за мен винаги въпроса е работоспособна ли е базата при дадени параметри - хардуер, ОС, настройки на сървъра на базата данни (конфигуриране) и схема на базата. Тук имаме информация само за:
1. Хардуер;
2. Смътна идея за ОС;

Работоспособност = прага на търпение на потребителите преди да кажат - това се влачи и не става. Иначе разбира се, че колкото голям е диска долу горе толкова може да е и базата и ще я носи и пентиум@700.

Само, че ако на касите има клиенти и всеки артикул ти се влачи по 5 сек, а приключване на транзакция 30, то тогава load average  на касат () започва да расте, опашката от необслужени клиенти респективно също и идва момента когато клиента спира да ти плаща за базата ти и софтуера ти и почва да търси алтернативи.

За това освен всички хардуерни и софтуерни трикове се разчита на подходящ за целта хардуер.

От толкова много изговорени приказки дано е станало ясно, че отговора на въпроса на тази тема е поливариантен а и самата задача е с много параметри.