- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день. Интересует такой вопрос: если в одной БД создано большое число таблиц, например, 100 000, повлияет ли это на производительность системы?
В БД хранится статистика по участникам системы. Каждая таблица хранит инфу по отдельному участнику.
Просто, когда стало много таблиц, скрипт вывода инфо стал в 95% случаев отдавать 504 ошибку. Может, дело и не в таблицах, конечно. Хочу спросить мнение профессионалов.
ЗЫ: Данные разносятся по разным таблицам, т.к. я предположил, что хранение этой информации в одной таблице слишком сильно ее "раздует" - получилось бы несколько миллионов строк.
Совершенно однозначно, что
несколько миллионов строк
большое число таблиц, например, 100 000
Вообще, для нормально спроектированной базы, работающей на хорошем железе, несколько миллионов строк - это абсолютно не страшно:).
Вообще-то, таблицы были придуманы для того, чтобы хранить однотипную информацию.
Т.е. как раз чтобы в одной таблице была информация обо всех участниках в вашем случае.
Для каждой таблицы база данных создаёт как минимум 3 файла и открывает их при обращнии к таблице.
В вашем случае, если осуществляется поиск по всем этим таблицам, то системе нужно будет открыть как минимум 300 000 файлов.
А во всех системах есть лимит на количество открываемых файлов.
И при этом херится использование индексов.
Индексы, кстати, как раз и были придуманы для того, чтобы поиск и выборка по гигабайтной таблице из многих миллионов строк работала шустро.
Каждый раз, когда встречаю таких разработчиков, волосы везде дыбом становятся :)
;7733398']Каждый раз, когда встречаю таких разработчиков, волосы везде дыбом становятся :)
А я наоборот радуюсь, у меня будет больше работы потом по оптимизации этого г_в_а)
П.С.
вы еще разнесите, чтоб каждое поле тоже таблицу) как в SAP R3
Вообще, для нормально спроектированной базы, работающей на хорошем железе, несколько миллионов строк - это абсолютно не страшно:).
Железо - ВДСка с 2.66ГГц и гигом оперативы.
;7733398']Вообще-то, таблицы были придуманы для того, чтобы хранить однотипную информацию.
Т.е. как раз чтобы в одной таблице была информация обо всех участниках в вашем случае.
Для каждой таблицы база данных создаёт как минимум 3 файла и открывает их при обращнии к таблице.
В вашем случае, если осуществляется поиск по всем этим таблицам, то системе нужно будет открыть как минимум 300 000 файлов.
А во всех системах есть лимит на количество открываемых файлов.
И при этом херится использование индексов.
Индексы, кстати, как раз и были придуманы для того, чтобы поиск и выборка по гигабайтной таблице из многих миллионов строк работала шустро.
Каждый раз, когда встречаю таких разработчиков, волосы везде дыбом становятся :)
Вообще, индивидуальные базы хранят инфу и скрипт вывода статистики к ним не обращается. А за совет про индексы - спасибо.
А вот допустим например есть кликандер партнерка, есть таблица в которую заносятся данные о переходах как в таком случае бд организовывать? Представляете сколько за месяц таких строк в таблицу набежит?
А вот допустим например есть кликандер партнерка, есть таблица в которую заносятся данные о переходах как в таком случае бд организовывать? Представляете сколько за месяц таких строк в таблицу набежит?
Чтобы данные за месяц/прошлый месяц/позапрошлый не мешали текущей работе (если кто-то иногда смотрит статистику за прошлые месяцы), то целесообразно сделать одну таблицу "текущий день", из неё раз в сутки перекидывать инфу за прошедший день в архив.
Вообще, всё зависит от объёмов и задач. Гугл-то как-то работает, а у него строк ещё больше :)
Каждая таблица хранит инфу по отдельному участнику.
Жесть, а что мешает в одной таблице хранить?
Жесть, а что мешает в одной таблице хранить?
Индивидуальная таблица хранит не одну строчку, а ежедневную статистику, т.е. набор строк, порядка 100.
Самая свежая статистика хранится в общей таблице, чтобы можно было одним запросом получить все, что нужно. Архивная статистика лежит в индивидуальных таблицах, т.к. она постоянно не требуется.
Сразу вопрос шарящим
Одна таблица, статику в myisam, динамику в innodb - верное ли утверждение ?
Индивидуальная таблица хранит не одну строчку, а ежедневную статистику, т.е. набор строк, порядка 100.
Если связь 1 к 1, то одна таблица юзеров и 1 таблица всех остальных значений.
Если же связь 1 к множеству, то лучше создать 100 таблиц для каждого значения, чтобы при выборке/внесении данных работало пошустрее.
Ежедневно/ежемесячно по крону старую/неиспользуемую статистику выносим в отдельные таблицы архива.
Кроме того правильно настроенные индексы ещё тоже не отменяли.
ЗЫ
Всегда умиляли подобные архитектуры бд, но с другой стороны как уже подметили выше нам больше работы будет по оптимизации подобного бредокода ;)