|
Тема
|
 голяма база данни ...
|
|
| Автор |
todor68O828 (непознат
) |
| Публикувано | 17.08.10 09:36 |
|
|
Във връзка със измененията на ЗЕС /закон за електронните съобщения/
доставчиците на интернет трябва да записват сесиите
Та въпроса ми е дали MySQL ще се справи с такава база данни.
На ден по 100 000 000 flow records при среден трафик 100Мбит/с
или 1155 записа в секунда.
информацията трябва да се пази 360 дни.
Един flow record е следната структура:
<P ID="edit"><FONT class="small"><EM>Редактирано от todor68O828 на 17.08.10 09:40.</EM></FONT></P>Редактирано от todor68O828 на 17.08.10 09:41.
|
|
|
Тема
|
Re: голяма база данни ...
[re: todor68O828]
|
|
| Автор |
wiz (змей) |
| Публикувано | 17.08.10 09:58 |
|
|
този въпрос е за
MySQL Technical Support
MySQL Technical Support Services provide direct access to our expert Support Engineers who are ready to assist you in the development, deployment, and management of MySQL applications.
сигурно може да се измисли и някое решение с компресия и без sql...Редактирано от wiz на 17.08.10 10:01.
|
|
|
Тема
|
Re: голяма база данни ...
[re: wiz]
|
|
| Автор |
todor68O828 (непознат
) |
| Публикувано | 17.08.10 10:04 |
|
|
Аз и сега имам решение но не е базирано на database
Просто с flow-tools се четат файловете и от там се правят справките.
Интересно ми е това как може да се прехвърли върху database.
Какви ще са недостатъците ...
Базата си е голяма както и да се погледне.
|
|
|
Тема
|
Re: голяма база данни ...
[re: todor68O828]
|
|
| Автор |
wiz (змей) |
| Публикувано | 17.08.10 10:27 |
|
|
варианти сигурно има много всеки със собствени особености ... едва ли някои в този форум ще се хване да ги гледа подробно, виж в другата тема че масово се пише без да се мисли...
no pain, no gain
|
|
|
Тема
|
Re: голяма база данни ...
[re: todor68O828]
|
|
| Автор |
wqw (АзСъмЖив) |
| Публикувано | 17.08.10 15:07 |
|
|
Мне.
Ще е порядъци по-скъпо решение от file-based аналога.
|
|
|
Тема
|
Re: голяма база данни ...
[re: wqw]
|
|
| Автор |
wiz (змей) |
| Публикувано | 17.08.10 18:51 |
|
|
хем не (сигурно Мне значи не) хем може ама е по-скъпо?
дали може да искат за този слуай да се поддържат възможносттите които предлага sql: повече видове заявки? така варианта с file-based не е добър избор
отделно ако се попадне на удачен начин за компресия може да се окаже по цена близо до file-based варианта...
no pain, no gain
|
|
|
Тема
|
 Re: голяма база данни ...
[re: wiz]
|
|
| Автор |
wqw (АзСъмЖив) |
| Публикувано | 18.08.10 12:59 |
|
|
Говорим за 36 милиарда записвания, без да включвам индексите! Но това ли ще пускат справките!? Единствените "справки" който могат да получат са raw записи с филтър по критерии (client IP, date range). Тук не може да става дума за JOIN-ове или GROUP BY и въобще SQL.
Ако им трябват агрегати, трябва ден по ден да си ги прекалкулират и тях евентуално да пазят в DBMS, но от това да дойдат най-много 10^6 записа примерно.
Just my $.02 worth
|
|
|
Тема
|
Re: голяма база данни ...
[re: wqw]
|
|
| Автор |
wiz (змей) |
| Публикувано | 18.08.10 15:30 |
|
|
ами помисли малко, ако попаднат на подходяща компресия 36 милиарда записвания може да намалеят на порядъци като размер в байтове и да става дума за SQL...Редактирано от wiz на 18.08.10 15:54.
|
|
|
Тема
|
примерна сметка
[re: wqw]
|
|
| Автор |
wiz (змей) |
| Публикувано | 18.08.10 16:32 |
|
|
ето примерна сметка правена на бързо
100 000 000 записа Х 70 байта = 6,5 GB
360 дни Х 6,5 GB = 2346 GB на година
ако добавим и overhead за бд-то -> 3-4 TB
тва са 2 диска по 2000GB които струват по 500 лв всеки
както са писали тук на Solaris 9/10 може да се справи с до 16TB
така цената излизае от порядъка на няколко хил лв което не би трябвало да е проблем за такава организация...Редактирано от wiz на 18.08.10 16:33.
|
|
|
Тема
|
Re: примерна сметка
[re: wiz]
|
|
| Автор |
Mixy (@#$%^) |
| Публикувано | 18.08.10 21:25 |
|
|
Проблема не e в съхранението, а по-скоро в достъпа и обработката на информацията.
Mixy
|
|
