Linux за българи: Форуми

Пентиум 4 двунишков на 3200ГХ и 2ГВ РАМ, с колко голяма база ще може да работи нормално? Базата ще се ползва от складова програма и евентуално някакво сайтче в периспектива.
Идеята е, имам едно ей такова ($2) Дел-че на което ще му сложа 1ТБ ХДД и ще го направя рутер pFsense във виртуална машина, 1 Уиндоус също във виртуалката, файлов сървър и MySQL сървър.
Двоумя се за това, колко да отавя за root дяла в който ще е базата, апачето и евентуалния сайт, а всичко останало за home в което ще са виртуалките и споделените папки.

Освен да си направиш /var партишън колкото ти трябва и в него да пъхнеш БД-то и там другите сървърски работи, за да не съобразяваш с root-a. А пък машината е достатъчно силна.  :)

вариант 1: LVM и преоразмеряваш в движение

вариант 2: 20ГБ /
в останалото 1ТБ- 20ГБ монтираш
var и home

вариант 3: Всичко накуп

Интересува ме само колко голяма база може да управлява с тези хардуерни параметри за тези цели!

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

Тук има няколко поднишки:

1. Пентиума има поддръжка на виртуализация? Ако да - ок - ако не - много внимавай в Уиндоус-а, колко памет ще ползва. Тръгне ли да суапва във виртуалка - жална ти майка плаче..;

2. Колко потребителя конкурентно ще обслужваш в базата данни?

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

4. Какъв в същност е очаквания документооборот (колко продажби, доставки, прехвърляния, поръчки, експедиции на ден се генерират)?

Като си отговориш на тези въпроси (аможе и тук да ги споделиш) може и по-ясно да се отговори!

За pfsense - що не го изнесеш навън на някоя малка кошница?

Интересува ме само колко голяма база може да управлява с тези хардуерни параметри за тези цели!

:D Зависи колко бързаш :D

Днес например на подобна машина колежката в другата стая търкаляше ~7GB firebird база с някой таблици по около 5-6 000 000 записа и една малко над 39 000 000. Обаче за тестове само и пак се беше по изнервила - за продукция с такава база забрави. Но слънцето е право - много зависи от какво и как.

Същата тази база иначе се търкаля безгрижно на 2х5620 ксеони със 16GB RAM и 15к SAS - там около 100 потребителя я разпъват в реално време безгрижно (време за приключване на продажба да речем от средно 5 артикула - между 2 и 7 секунди - в зависимост от интернет връзката);

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

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

Но слънцето е право - много зависи от какво и как.

Все едно слушам жена ми :)  [_]3

Цитат на: VladSun в Oct 05, 2011, 22:10

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

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

jet ти е отговорил вече :)

Тук има няколко поднишки:

1. Пентиума има поддръжка на виртуализация? Ако да - ок - ако не - много внимавай в Уиндоус-а, колко памет ще ползва. Тръгне ли да суапва във виртуалка - жална ти майка плаче..;

2. Колко потребителя конкурентно ще обслужваш в базата данни?

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

4. Какъв в същност е очаквания документооборот (колко продажби, доставки, прехвърляния, поръчки, експедиции на ден се генерират)?

Като си отговориш на тези въпроси (аможе и тук да ги споделиш) може и по-ясно да се отговори!

За pfsense - що не го изнесеш навън на някоя малка кошница?

Базата ще се обслужва от 10-15 юзера и евентоалния сайт. 
Мислих по начин линукс-а да е рутер и всичко останало, но този вариант с pfsense във виртуалка най-много ми харесва.
Вбокса има възможност за съответната виртуалка да извадя шоркът на десктопа, който да го вкарам във стартъпа и при рестартиране на компа да се стартират автоматично съответните в-машини. Машината трябва да се включва и изключва от пауър бутона и с лед включването и, всичко да заработи нормално без монитор.
Трябва, след натискане на бутона да се изключи и след повторно натискане да се включи и всичко да заработи на 6! Първо рутера за да имам достъп до самата машина и после форварднатите портове към съответната машина уиндоус и реалната, а също и форварднатите към апачето.

П.С. Аз си споделям идеята, но въпроса ми за това колко голяма база би могла да се управлява с този хардуер като MySQL сървър остава май на заден план!

П.С 2. От горните отговори, май 10ГБ са достатъчни!

Машинката ще се справи с MySQL база от около 10G и 10-ина потребителя ако:
- Linux дистрибуцията ти е без графична среда(или с много лека такава)
- VirtualBox е в headless мод (можеш лесно да напишеш стартиращи скриптове за виртуалните машини и без стартиран X)
- както каза plamen_f ако сложиш pfSense на някоя стара кошница а не го виртуализираш. (Изобщо идеята за виртуализация на рутер, на който разчиташ не е много добра при така натоварена машина и с такива параметри въпреки, че е блазнеща  :))
На Debian с 3G RAM имам работещ VirtualBox с 1 виртуална машина Windows 2008r2 и MySQL база от около 12G  в която се рови през WEB интерфейс от локална мрежа от около 15-20 потребителя(неедновременно обаче).

Я всички, който казвате "около 10GB" да Ви питам как го изчислихте това? Май говорите само на изуст.

Аз не казах ;)

Човек, няма начин да определиш размера на (всички) базата в GB, която ще "върви" на дадена машина.
Например, ако базата е силно денормализирана, малко на браой таблици и връзки между тях (подготвена за репорти и анализ), то тогава най-вероятно ще можеш да обработваш бързо повече информация. Ако обаче базата е нормализирана с голям брой таблици и връзки между тях, то тогава нещата стоят по съвсем различен начин. Да не говорим за конкурентност на връзките, LOCK и т.н.

Упс!

Нормализираните бази винаги са по-бързи от денормализираните. Защо иначе ще се прави нормализация?

Тук по-важното е как е направено индексирането. Ние имаме опит с огромни бази от данни, 11G база работи на нетбук с Microinvest Склад Pro и сървъра се справя сносно. Единствено е зле при Sub-Select заявките, но това си е от самия сървър и липсата на памет за кеширане на междинните резултати.

Нормализираните бази винаги са по-бързи от денормализираните. Защо иначе ще се прави нормализация?

Не бих казал, че винаги е така ... Понякога е нужно да се направи денормализация за целите на анализ - най-често срещания пример е "последно състояние". Пример за който се сещам в момента (и е възможно да се прави със субселект) е състояние (сегмент) на "call" в callcenter - в опашката, поет от оператор, пренасочен от оператор и т.н. При една силно нормализирана база данни би трябвало да се пазят само записи (many-to-many, Call<->State) по отношение на състояние + дата/час. Но този начин на работа прави заявките за анализ (репорти) доста бавнички - има търсене на запис с най-голяма стойност на дата/час колоната. Най-простото решение е да се добави колона "последно състояние" към Call таблицата, което си е чиста проба денормализация.

Говоря за нещо такова:
http://en.wikipedia.org/wiki/Data_warehouse#Normalized_versus_dimensional_approach_for_storage_of_data

Сега да погледнем същото от страна на многозадачност и многопотребителност. При многопотребителност кой точно прави "актуалното състояние"? Охлюв, Костенурка, Орел и Гепард ни носят по една бира. Всеки променя моментното състояние и претендира то да е актуалното. Охлювът е донесъл бирата първи, но актуалната бележка е на бара. Дали той ще е в състояние да отрази реалното състояние?

Много благодарство на всички, започвам да цепя 30ГВ - /, 1ГБ - SWAP и останалото /home

Нещо не можах да разбера какво точно показваш. Би ли опитал да се използваш моя пример?

//off

Сега да погледнем същото от страна на многозадачност и многопотребителност. При многопотребителност кой точно прави "актуалното състояние"? Охлюв, Костенурка, Орел и Гепард ни носят по една бира. Всеки променя моментното състояние и претендира то да е актуалното. Охлювът е донесъл бирата първи, но актуалната бележка е на бара. Дали той ще е в състояние да отрази реалното състояние?

Не е ли малко рано за бири?

http://en.wikipedia.org/wiki/Denormalization

In computing, denormalization is the process of attempting to optimise the read performance of a database by adding redundant data or by grouping data.[1][2] In some cases, denormalisation helps cover up the inefficiencies inherent in relational database software. A relational normalised database imposes a heavy access load over physical storage of data even if it is well tuned for high performance.

Можем да спорим до безкрайност. Тъй като аз самия доста съм проектирал бази работещи с високо натоварване, досега нормализираните са били винаги по-ефективни.

Нормализацията не е лек за всичко ;) (y)

Нормализацията не е лек за всичко ;) (y)

Жив пример за това са: twitter, faceboog, digg.com

Ама той backinblack вече го купи и метна да цепи диска и да инсталира. Ама то 5 GB, 10 GB, нормализации - свърши вече, машината е избрана и купена. Дано да си свърши работата и да е доволен колегата.

Можем да спорим до безкрайност. Тъй като аз самия доста съм проектирал бази работещи с високо натоварване, досега нормализираните са били винаги по-ефективни.

Не споря  - изказвам мнение  [_]3

Със сигурност не мога да твърдя, че съм работил кой знае колко с много големи бази данни. Реално, може бе 2-3 пъти. В единия случай беше за callcenter с около 120'000 записа на ден (100 агента "пишещи" и към 20 teamleader-и/supervisori-и четящи) само за обажданията. Това ми е и най-голямата база май - Postgre SQL :)

В началото, дизайнът на ДБ винаги го правя в най-нормализиран вариант. След това, ако се появят проблеми може и да има някаква денормализация или изнасяне на "offline" view-та за преглед в не реално време.

Въпроса ми бе риторичен, че нямам никакъв опит с mysql, а за лични цели нямам и нужда от него, но въпросното компютърче и диск съм ги купил с друга цел, но искам да пробвам дали ще има пазар при мен в провинцията за едно такова мултифункционално устроиство предварително нагласено и след това само бастър копче - работи и бастър копче - не работи, без монитор, евентуални донастройки с webmin, xrdp или vnc и евентоалните потенциални клиенти да го ползват за рутер, файлов сървър, евентоално база данни сървър за микроинвест склад про или уарехаус с не повече от 10-15 клиентски машинки, евентуално камерки за видеонблюдение да са на него и някакво просто сайтче да си хостне, щото така и така ще е постоянно включен.
На мен лично ми трябва само рутера и ако ще си събирам рутер само за себе си, съвсем друга ще е машинката.
10ГБ база данни на складова програма, това е дейноста на фирма за повече от 5 години! Предостатъчно е! Въпроса ми беше дали ще може да работи нормално самия хардуер с такава база в периспектива?  В периспектива, и рутера и виртуалния уиндоус винаги могат да се изнесат на други машини и да се мислят други конфигурации.

Ще работи. Точно за Microinvest Склад Pro са ни наблюденията на голямата база, достатъчно добре нормализирана. За да имате бързодействие увеличете следните настройки на сървъра:
а) Големината на Key Buffer;
б) Паметта за Temp таблиците;
в) Количеството памет за Query Cache.

Тези 3 параметъра могат да накарат сървъра да лети, при нашата програма таблиците са малко и еднотипни, затова силно се поддават на оптимизация.

Само да добавя, че при големи ДБ идеята да се пускат още услуги на машината не е добра. Стигне ли се до swapping ... жална ти майка :)

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

Има огромно значение каква е схемата, къде има индекси и най-вече какви са 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-и, може да се държи смазващо по-зле дори на много по-мощен хардуер.

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

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

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

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

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

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

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

 [_]3