Привет всем, вопрос такой существует ли придельная "нагрузка" "лимит" одновременных обращений или еще что-то подобное у mysql, и еще вопрос, допустим у нас есть портал на нем зарегистрировано более 3 миллионов человек, каждый чел имеет свои записи ведет общение и прочее, как разумнее поступить использовать одну базу данных или не сколько каждую под определённое количество людей?
Предполагается, что база будет не просто большой, а ну очень большой, понятно что разумно построенная база оптимизированная с ключами и партиционированием, предполагает бес проблемную работу с базой, но дело в том что если взять за пример работу платных магазинов, то можно сказать, что даже хорошо продуманная база начинает тормозить на том же каталоге запчастей для автомобилей. Теоретически то же партицирование предполагает тот же эффект что и разнос базы на несколько баз -дробление на логические части, но все-таки что скажут мастера?
И еще вопрос допустим у нас есть портал на него ежесекундно совершается огромное количество обращений, может быть логичнее было бы разнести сервис в том числе и базы на несколько независимых серверов, а данные от юзера получать и выдать путем сборки данных с этих серверов одним сервером, т.е. работает цепочка - сервер для хранения, записи и передачи инфы(хранилище) -> общий сервак(получает и распределяет инфу по сервакам хранилищам)-> юзер
Прошу отнестись без юмора вопрос очень острый?

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

_____________
ввв.парсер.рф - онлайн система проверки позиций Вашего сайта в поисковиках. Для форумчан 100 рублей на счет.

соучастник

Ваш вопрос действительно очень глобален. Тут нужно производить целое исследование. Бесплатно никто таким заниматься не будет.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

T1grOK, вы тоже считаете, что книги пишут идиоты для идиотов?


_____________
Стимулятор ~yoomoney - 41001303250491

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

Наиболее полезным в данном вопросе оказалось видео от разработчиков mail.ru о решении ряда проблем с хранением огромного пласта данных.

Из описанных книг я вынес для себя полезную информацию именно поэтом я и задаю подобный вопрос.

Valick, я одного не могу понять зачем вы тратите свое и чужое время для написания подобного рода комментов? самоутверждаетесь? льстите своему самолюбию? если вы не знаете или не хотите ответить на вопрос проходите стороной! Здесь не требуются показательные порки, почему каждый раз когда задаешь вопрос приходиться проходить через насмешки от людей вроде вас? предполагается что на форуме сидят специалисты которые имеют опыт с высоко нагруженными приложениями, а значит они должны иметь общее представление о подобного рода задачах. Не ужели на форуме нет специалиста, который работал с нагрузкой в милион юзеров и который не может дать хотя бы общие рекомендации?

Ну а если абстрагироваться, то пожалуйста:
1. оптимизация обращений к бд - реорганизация запросов с целью понижения нагрузки на сервер, при необходимости денормализация, кеширование, и так в цикле это и еще много всего.
2. упомянутый partitioning

Предлагаю глянуть на эту проблему с еще одной стороны, откуда смотрят далеко не все.

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

Вопрос надо по-другому ставить, наверное. Если при создании БД была заложена масштабируемость (партиции/репликации), то тогда дальше всё будет относительно просто. Если же изначально была сделана только одна большая таблица и потом "вдруг" решили сделать хотя бы партиции, прямо при "живой" БД, которая активно используется... То вот тут будет большой гимор. Я лично это проходил

Так что еще раз повторю: сначала надо сделать правильную архитектуру БД, позволяющую ее в дальнейшем модифицировать. И одновременно вести статистику нагрузки, чтобы своевременно принимать решения об изменениях. Например, надо ли будет добавить еще парочку серверов через месяцок, а не тогда, когда существующие серверы уже загнутся.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

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

т.е. я хочу сказать что действительно может состояться такая ситуация когда одной бд будет не хватать и нагрузку нужно разносить на несколько?

Может.

и в таком случае как разумнее планировать приложение с учетом не скольких серваков или нескольких баз mysql?