@AffProg

Добрый день!
Интересует следующее: есть большой посещаемый проект, порядка 20.000.000 хитов в сутки, и нужно организовать статистику того, какой ip-адрес какую страницу посетил. т.е. грубо говоря интересует то, какого типа желательно создать таблицу в MySQL и с какой структурой??? Можно, например, сделать таблицу с двумя полями - ip и page, НО при каждом посещении страницы будет происходит выборка из этой таблице и анализ, и при таком посещении в сутки это минимум 20.000.000 записей!! Как это отразится на работоспособности базы??? (большой объем данных и при каждом заходе выборка и анализ ip)???

0

@xAtom

Если IP хранить в двойном слове числовом типе и поставить проиндексировать его, к тексту применить полнотекстный поиск FULLTEXT, тут без индексов не обойтись если хочешь чтобы была быстрая скорость выборки данных то индекс в помощь, его минус в том что он замедляется операции DML(INSERT, UPDATE, DELETE) так как индекс приходится перестраивать. Тип таблицы подойдёт тебе MyISAM тебе не нужны транзакции тогда зачем InnoDB гонять.

2

@AffProg

Во-первых - спасибо!
Во-вторых - немного уточню. При каждом заходе посетителя на какую-либо страницу будет не только происходить выборка данных, но и вставка, как с помощью INSERT, так и с помощью UPDATE. Т.е. получается, что если использовать полнотекстный поиск, то с выборкой проблем нет, а вот вставка будет страдать. И это при 20.000.000 хитов в сути. Опять же получаются тормоза.
И не легче ли будет хранить ip-адрес так как он есть, только в текстовом поле и не использовать индексы??? :-)

Заранее спасибо!

0

@DenQ

Честно признаться для такого количества хитов, я бы вообще mysql не использовал. И при такой нагрузке на сервер, необходимы транзакции, а MyISAM, тут к чертям(простите) слетит в первый же час работы... Без транзакций не обойтись, InnoDB конечно тут в помощь. Без индексов можно, но за такую работу я бы поставил двойку.
Почитайте вообще о том, что такое индексы и какова суть их применения...

Добавлено через 10 минут
И я бы добавил еще один сервер... и распределил между ними, таблицы по связям...

1

@AffProg

А что посоветуете вместо MySQL???? И сейчас, к сожалению, нет возможности поставить второй сервер! :-( Как тогда быть???

0

@DenQ

Для больших проектов я бы использовал postgresql либо же oracle. Согласен, сложнее, но надежней как минимум.
А как вам быть, подсказать я не могу, мало информации... Но погуглить я всегда могу отправить сам бы так первым делом и сделал.

0

@AffProg

Ясно. Для меня правда приемлемее был бы MySql. Задам ещё один вопрос, параллельно, а если для каждой страницы создать свою таблицу с один лишь полем, где будет хранится один лишь IP-адрес и всё. Конечно наличие нескольких тысяч таблиц для базы это через чур, но ... не упростит ли это немного задачу??? И запрос SELECT выбирающий список тех страниц на которых посетитель ещё не был, выполняющийся при каждом заходе на какую-либо страницу, сильно будет тормозить систему!???

0

@DenQ

pages
id
name
и другие поля

visites
id
id_page
dt_visit
и другие поля

1. Индексация обязательна!
2. Если бд будет быстро расти, а расти она будет очень быстро, советую ненужные(старые записи) из таблицы visites, систематически удалять, предварительно занося их в текстовики, которые потом сжимаем архиватором, и даем имя, времени создания, о5 же таким, желательно в числовом варианте(от начала эпохи unix).
3. Записывать в таблицу, в данном случае лучше транзакционно, тут либо выбираем медленну InnoDB, которая это делает автоматически, либо MyISAM но за счет того что будет делать транзакции, разницы во времени выполнения врядли будут ощутимы... Так что я бы использовал тут InnoDB, беря во внимание человеческий фактор(не каждый владеет качественными познаниями в области транзакций - так что пускай уж лучше все будет в надежных руках разработчиков).

~4. Можно еще сделать проверки на ip адреса, и если входит новый ip, тогда записываем его в таблицу visites, иначе, создаем в таблице ips(таблица ip адресов(типа id, ip)) новую запись с новым ip-адресом. И заменяем все существующие такие ip адреса на соответствующий id этого адреса. Это выгодно в моем случае. Когда я выхожу из под ip адреса провайдера. А у него таких как я тысячи... Вот и посчитайте экономию... то ли ты запишешь до 16 символов в строку, то ли одно число...

Мои советы не есть универсальными и это просто мое мнение исходя из моего опыта конечно же.
Все.

1

@AffProg

Но тогда увеличится количество обращений к базе:
- проверка по таблице ips первый раз зашел данный ip или нет
- замена в visites ip на его id из ips-таблицы
- при втором и последующем заходе находить в ips-таблице соответствующий id и его внесение в visites

Это не увеличит ли нагрузку на базу???

И не проще создать одну таблицу:
pages
ip
page

... и хранить в ней ip-адреса как они есть (000.000.000.000)

0

@DenQ

Не все что проще, оптимальней...
Сортировка методом "пузырька" тоже проще, но едва ли оптимальней, хоть сколько-то.
Думая об индексах, представьте что вы библиотекарь и у вас нету каталогизатора. Представьте как сложно вам будет найти ту или иную книгу, а если еще и книги будут расположены в разброс(а они таки довольно скоро будут разбросаны, при таком подходе), то вполне может оказаться что вы ее вообще не найдете, даже спустя недели(зависит от размеров библиотеки(или бд)).
Создавая индексы, и дополнительные таблицы вы облегчаете и причем очень существенно жизнь и работу серверу... То ли он потратит 0.5 сек(зависит от размера бд) на поиск по "каталогизатору", и выберет сразу нужную "полку"(запись по ID), то ли будет перебирать 10ки миллионов записей, и повезет еще если не придется в каждой записи искать что-то по маске...(подстроку в строке)... ой как повезет...
Теперь вам видна разница и крайняя полезность того что я советую?

1

@AffProg

Спасибо, уяснил. :-)
Мои познания в области баз данных с вашей помощью значительно увеличились!! :-)
Но позвольте задать предыдущий вопрос переформулировав его:
Если всё же использовать таблицу pages с полями ip и page, но поле ip сделать индексным и хранить в этой таблице информацию только за сутки и каждый раз в полночь создавать новую такую же таблицу для начавшихся суток?? Получается что на каждый пройденный день будет своя таблица. Затем, в свободное (удобное) время выгружать такие таблицы (за прошедшие дни) допустим в текстовый файл и уже на локальном компьютере анализировать траффик?!! Меня-то собственно посуточная статистика интересует.

0

@DenQ

Можете делать и так, если это удовлетворит условию задачи. Но,
1. таблицу я назвал не pages а visites, для этих целей
2. Не нужно создавать каждый раз новую таблицу, разумнее будет при ваших условия(а я их понял именно так), бекапить записи за каждый день в отдельный файл а потом и архивировать его на сервере... а записи за тот день в таблице удалять...
3. Но много ли вам это даст, кроме лишнего нагревания одного места,простите... сделали бы все по уму, согласно 3 нормальным формам и все бы просто летало...

И еще для уменьшения размера бд, я бы советовал давать каждой строке get запроса, id-шник... и просто ставить число, нежели повторять тысячи раз длинную строку размером иногда в сотни символов... а при такой посещаемости это критически важный апгрейд.. я считаю... по крайней мере я бы сделал именно так...
Размеры бд уменьшились бы в перспективе в 10-ки раз, если не в сотни...

ЗЫ. А вообще я вам советую нанять профессионала или эксперта... либо очень умного студента...

1

@AffProg

Это вы о чём??? Я имею ввиду get запросы и id-шники??

0

@sigmov

MySql очень даже подходит. Не слушайте тех кто говорит обратное.

Без индекса работать с миллионами записей просто нереально.
Сложность выборки и обновления обиночной записи без индекса = (n/2), с индексом = log(n,2)
При n = 100 000 000 вашему процессору придется обработать 50 000 000 сравнений, а с индексом лишь 26(!) - думаю разница очевидна.

Типы таблиц - INNODB, форма - компакт

Структура 1й таблицы - 3 поля.
1 - ip(int) (не удивляйтесь в mysql IP->int преобразуется INET_ATON(ip), обратно - INET_NTOA(int)
2 - page_id(int)
3 - count(скол-во )
PK = {IP,page_id}
Index = {page_id}

Структура 2й таблицы - 2 поля
1 - page_id(int) autoincrement
2 - url(varchar(256))
PK = {page_id}
UK = {url}

Вот и вся перемога.

1

@DenQ

А вы с другими СуБД кроме MySQL работали, чтобы заявлять подобное?

Извиняюсь, преувеличил ваши познания в данной области.. думал поймете...

0

@sigmov

А что для того чтобы заявлять что MySql подходит для конкретной задачи нужно обязательно иметь опыт работы с другими СУБД? )))
А тогда для того чтобы утверждать что молотком можно забить гвоздь, достаточно ли опыта обращения с молотком или требуется опыт гвоздезабивания иными инструментами? ))))
Тут же не сравнительный анализ.

1

@DenQ

Вопрос не в том подходит или нет, вопрос в том что подходит лучше... И в моих первых постах я придал этому большой оттенок...
Между прочим мое первое образование столяр, так что не стоит мне рассказывать такое... ))
Молотком можно забить гвоздь, но молотком можно сделать еще много чего другого, но из этого еще не следует что молоток нужно применять всюду где это только возможно. И к тому же молотки бывают разные... Вы долго будете забивать маленьким молотком большой гвоздь... а все потому что им конечно можно забить большой гвоздь, но с это задачей лучше справится другой инструмент...

Еще раз повторюсь, для таких задач MySQL, не самый лучший выбор...
Но это конечно мое, отчасти субъективное, мнение...

1

@AffProg

"Ну, вы блин даёте!..."
Я даже не ожидал, что мой вопрос разовьется в такую дискусию! :-) Но спасибо всё равно!

DenQ - вы так завуалированно написали про get-запросы. Всё ж если можно "расшифруйте" про id-шники ;-)

0

@DenQ

И еще для уменьшения размера базы данных(за счет роста таблицы visites) я бы советовал давать каждой строке get запроса(в данном случае имеется ввиду строка в браузере - это адрес - в этой строке параметры которые читает сервер и в зависимости от них генерирует в ответ страничку)(таких строк может быть очень и очень много, зависит от структуры системы), id-шник(каждой уникальной get строке даем айдишник)... и просто ставить число, нежели повторять тысячи раз длинную строку размером иногда в сотни символов... а при такой посещаемости это критически важный апгрейд.. я считаю... по крайней мере я бы сделал именно так...
Размеры бд уменьшились бы в перспективе в 10-ки раз, если не в сотни...

0

@AffProg

Я так и подумал! Не, здесь это не нужно. С именами файлов никаких параметров не передается.

0