Огромная база данных растущая очень быстро! Оптимизация

fizot

Новичок
Огромная база данных растущая очень быстро! Оптимизация

Вообщем в базу(MySQL) ежедневно добавляются по несколько тысяч записей, а планируется по 10к. и в последствии по 100к. Что-то вроде каунтера.
Интересуют записи только за сегодняшний день, а предыдущие больше для статистики и сравнения. То есть я думаю так:
1) Завести две базы
а) Первая база актуальна за сегодня, то есть если приходит юзверь, то мы проверяем был ли он сегодня и добавляем в сегодняшнюю базу, как уника или не уника
б) Вторая база для архива и просмотра архивов
2) Делать в кроне ежедневный бэкап базы и складывать в виде файла с именем (01.01.2006) в диру архивов
3) Перед админом появится интерфейс:
а) Посмотреть статсу за сегодня(работаем исключительно с первой БД)
б) Если админ хочет посмотреть более рание архивы, то выкидываем ему интерфейс, где просто выведен список файлов из архивной директории (преобразованы имена файлов в красивочитаемый вид+отсортированы) и админ выбирает за какие дни он хочет посмотреть статистику
4) После того, как админ выбрал дни статы, они загружаются во вторую базу для работы с архивными записями(!!!) и вот тут возникают вопросы:
1) А рацианален ли такой подход, а быстро ли будет подниматься бэкап???
2) Может вы что-то другое присоветуете ?
3) Если такой подход рацианален и единственен, то уже интересует конкретица. То есть в каком виде складывать и какие классы для этого лучше заюзать?
 

Tor

Новичок
бред

partitioning тебе нужен
а память\место стоят копейки
 

fizot

Новичок
Автор оригинала: Tor
бред

partitioning тебе нужен
а память\место стоят копейки
Честно говоря, раньше просто не возникало подобных задач и такой объем трафа
Что такое partitioning ???
А память и место тут не причем. Я имел ввиду, что при базе в 100...00000 будет трудно проверить, уникальный ли это посетитель и был ли он сегодня или нет.
 

hermit_refined

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

Mikle Heavy

Новичок
Была подобная задача. Нашли следующее решение:
Данные полученные более трех месяцев назад группирующим запросом отправлялись в другую таблицу (архив), а из рабочей соответственно удалялись. Нам нужна была детализация за 100 суток, а более древние данные нужны были только для того, чтобы видеть динамику изменений. Соответственно мы удаляли избыточность, группировали и архив был меньше рабочих данных до 30-50 раз.

Может и вам такое подойдет. Все зависит от постановки задачи.
 

Tor

Новичок
Что такое partitioning ???
гугл поломался?

А память и место тут не причем
а что ты пытаешься съекономить, проводя какие-то пассы с файлами?

при базе в 100...00000 будет трудно проверить, уникальный ли это посетитель
что значит трудно?
если медленно, то так и надо писать
причем перед этим проверить, насколько медленно, что бы не прослыть "воинствующим идиотом" на форуме
 

jonjonson

Охренеть
Если есть старые данные и они нужны формально, то есть запросы определены, то храните результат этих запросов, а данные похерьте. Либо устраивайте warehouse на более менее серьёзной БД. MySQL для web - это одно, а статистические выборки - это другое.

В любом случае, например интернет провайдеры, осуществляют агрегацию данных через определённый период.
 

fizot

Новичок
Автор оригинала: Tor
гугл поломался?


а что ты пытаешься съекономить, проводя какие-то пассы с файлами?


что значит трудно?
если медленно, то так и надо писать
причем перед этим проверить, насколько медленно, что бы не прослыть "воинствующим идиотом" на форуме
Экономить впринципе ничего не надо.
Да точно! медленно. Очень медленно, юзер тратит заметное время только на счетчик.
А ЧТО КОНКРЕТНО Скажите по моим мыслям в топикстарте ?
 

denver

?>Скриптер
jonjonson
Либо устраивайте warehouse на более менее серьёзной БД.
А какие ты советуешь? Кинь плиз продвинутые ссылки по выбору СУБД для warehouse. Если таковых нет, буду признателен если своими словами расскажешь.
 

Mikle Heavy

Новичок
Для крупного коммерческого проектя я бы посоветовал Oracle.

Аргументы:
- Отличное масштабирование, кеширование запросов, развитый процедурный язык PLSQL

- Поддержка большинства серверных платформ

- Это один из лидеров отрасли и крупная стабильная корпорация - поддержка и свежие версии обеспечены.

- Гибкая тарифная политика при покупке лицензии

Ну и т.д.

Антиаргументы
- Дорого

- Очень дорого

- Необходимо обладать глубокими знаниями в этой области
 

Tor

Новичок
это что за пиарщик на форуме завелся
приходи, когда маркетинговые фразы заменятся в мозге на технические аргументы
 

AmdY

Пью пиво
Команда форума
Антиаргументы - нафик платить если есть бесплатные mysql и postgres
 
Сверху