О программирование

[Jooz]

PS - портал большой 40.000 уников в день прогноз
Стоит задача без всякий nginx выдавить максимум с сервака в 4-GhzX2 4G Озу. Вопрос именно в том что больше сожрет ресурсы сервера однолинейный запрос к одной таблице которая содержит большей объем инфы, кэширование на уровне php и обработка на уровне php. или много линейный запрос к нескольким таблицам. Опыт на портале в 10.000 уников показал что таблица в 50 столбцов и кеширование на уровне php справляются нормуль. Теперь задача заранее предугадать поведение желаза с посещаемость 40-100К уников. Ну естественно хостов нужно помножить на 10 миниму. т.е. 1Млн запросов в день это пиковая прогнозируемая нагрузка на MySQL - т.е. без телепатии тут не куда, в этом и заключается разработка БД.

[Sasa]

Сообщение от LIGHT

Ну как же я сказал таблица будет дико большое 1Млн записей это минимум дальше в верх, база основная значит каждый вызов странички вызывает таблицу. Вызовов в час более 10.000 дальше вверх.
Какие еще параметры тут можно добавить.
Естественно нужно с запасом на будущее X100

1) было сказано 100тыс строк и до 1млн, а это вовсе не 100млн - другая оценка
а значит тем актуальнее вопрос про СУБД,
я бы начал посматривать на "коммерческие"

2) 10000 в час? что такое вызов?

3) запас х100 мне каежтся это перебор, даже для космоса

[Sasa]

Сообщение от LIGHT

PS - портал большой 40.000 уников в день прогноз
Стоит задача без всякий nginx выдавить максимум с сервака в 4-GhzX2 4G Озу. Вопрос именно в том что больше сожрет ресурсы сервера однолинейный запрос к одной таблице которая содержит большей объем инфы, кэширование на уровне php и обработка на уровне php. или много линейный запрос к нескольким таблицам. Опыт на портале в 10.000 уников показал что таблица в 50 столбцов и кеширование на уровне php справляются нормуль. Теперь задача заранее предугадать поведение желаза с посещаемость 40-100К уников. Ну естественно хостов нужно помножить на 10 миниму. т.е. 1Млн запросов в день это пиковая прогнозируемая нагрузка на MySQL - т.е. без телепатии тут не куда, в этом и заключается разработка БД.

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

[Alex007]

Искренне советую обсудить это на специфических форумах. Я не возьму грех на душу.

А еще лучше: нанять профи по проектированию больших БД. Есть такие. Возможно БД имеет смысл разбить на несколько. А то есть реальный риск попасть на очень серьезные бабки. Идея кеширования при таких объемах мне кажется несколько сомнительной.

[vvvvv]

Сообщение от LIGHT

сейчас проект замутил где очень много данных который по логике лучше хранить в одной таблице из-за чего она разрослась столбцами

Не надо пользоваться логикой. Надо пользоваться теорией нормализации баз данных.

[Jooz]

Сообщение от vvvvv

Не надо пользоваться логикой. Надо пользоваться теорией нормализации баз данных.

Совсем флудовый ответ, без обид

Тут речь не про опыт и нормализацию, а про то что есть ТЗ, есть бюджет, дальше нужно решение, что будет производительней из указанных мною вариантов.
PS - если память не изменяет вопрос я так и сформулировал. Получил ответы на уровне гипотез, что говорит что отвечавшие люди не работали с базой при указанных нагрузках. По комерчиским версий, не спорю, выход мог бы быть, только есть опять же ТЗ. Моя бы воля ушел бы в сторону Domino или Oracre, на худой конец MSql но от меня это не зависит. У меня бубен в руках, и задача правильно нашаманить.
В общем вот решение:
1. Хранение в одной таблице на производительность не скажется т.к. запрос лимитирован X,Y поиск по индексу, можно хоть миллиард срок, для MySQL это не проблема из оф. документации
Для оптимизации и ускорения работы на больших оборотах буду использовать кэширование средствами самого MySQL и делать линейную обработку кеша опять же из оф. руководства.

2) 10000 в час? что такое вызов?

Обращение к таблице (SELECT,INSERT,...)

3) запас х100 мне каежтся это перебор, даже для космоса

Вам кажется заходим на SE форум и смотрим юзеров онлайн, сколько постов за час лепят, сколько просматривают догадаться не сложно, долго думаем над подобным (сейчас: 757 (321 пользователей, 210 гостей, 226 роботов)). Знаю еще ряд примеров с подобными и в разы большими нагрузками, но к сожалению с админами не знаком, было бы интересно узнать например (n n m . r u) у них походу кластер но он чисто нагрузку на железо делит правда в пики бывает nginx рубит, а база не падает.

[vvvvv]

Сообщение от LIGHT

нужно решение, что будет производительней из указанных мною вариантов.

Почему Вы решили, что "Ваши варианты" оптимальны? Рассмотрите ситуацию несколько шире. Уберите лишнюю избыточность данных из базы и количество столбцов в Вашей "основной таблице" резко уменьшится.

[muxa]

Сообщение от LIGHT

Закралась в голове мысля....

Сейчас проектирую базенку, в основной таблице набирается под 60 колонок. При этом объем хранимых в ней данных планируется в пределах 100.000 - 1.000.000 строк, индексы и прочее вроде продумано, вопрос в том, что может стои разбить таблицу на пару мелких?
Но смущает то что тогда возрастет число подзапросов и соответственно процессорное время. Как быть не пойму... В самой таблице данные мелкие, типа INT Enum есть 1 поле TEXT.
Может у кого был опыт шевелить базы (таблицы) с большим числом колонок? Что производительней: 2 таблицы с 30 колонками, но линкующимеся по ключу или 1 с 60.

Не с того конца подход

Миллион записей даёт основание предполагать что проект располагается на собственном хостинге. То есть вопрос производительности это вопрос двух-трёх сотен баксов на камень и память.

Главный вопро который должен стоять - управляемость проекта.

Как часто нужно будет заводить новые столбцы, в каком виде они будут использоваться, как часто будет меняться логика проекта.

Программист стоит всяко дороже процессора.

[Sasa]

Сообщение от LIGHT

Получил ответы на уровне гипотез, что говорит что отвечавшие люди не работали с базой при указанных нагрузках.

если посмотреть внимательно, вам стараются ненавязчиво, чтото посоветовать (высказывают точку зрения) ничего не зная ни про данные ни про логику ни пр.

мы не можем сделать оптимальный выбор не имея полного представления о задаче


а вообще, если есть подобный готовый проект с меньшим кол-вом данных и меньшей нагрузкой - надо увеличить данные и прогнать нагрузочные тесты и сразу вылезет все плохое

[Sasa]

Сообщение от LIGHT

2) 10000 в час? что такое вызов?
Обращение к таблице (SELECT,INSERT,...)

а сколько сейчас система держит запросов в секунду?
(та аналогичная что есть)