Т.е. целый год данный факт хостера не беспокоил, а сейчас вдруг это стало неприемлемо. © s_lek
Этот факт беспокоил хостера довольно давно (еще с 2006 года), но так как в MySQL нет механизма ограничения объема баз данных пришлось его разрабатывать. Сейчас же мотивацией разработки автоматизирования ограничения стало то, что работа с такими базами приводит к снижению производительности серверов.
Я размер БД уменьшить не могу, так как это приведет к частичной утрате функциональности моего сайта. © s_lek
Суть виртуального хостинга в том, что некоторое количество пользователей используют совместно один сервер, некоторые чуть больше, некоторые меньше, но в целом если у одного пользователя на порядок больше потребностей в ресурсах сервера, то он будет создавать проблемы другим пользователям и тут одна из обязанностей хостинг провайдера - быть арбитром и не допускать таких ситуаций. Было бы странно от хостинг провайдера в качестве аргумента на вопрос "Почему все тупит?" слышать: "Все ок, вы просто на сервере находитесь с крупным интернет порталом и он потребляет под себя 90% ресурсов, а вам ничего не остается :)". С другой стороны выделять под клиента целый сервер по цене виртуального хостинга - тоже не совсем правильно. Так вот к чему я это - есть ситуации, когда у пользователей в базу пишутся какие-то логи и разрослись они до невероятных размеров, в таком случае нужно чистить и уменьшать базу, а если в базе полезная информация, то возможно сайт уже вырос с виртуального хостинга, как когда-то google вырос с одного сервера?
Почему бы, вместо введения ограничений, не разработать тарифный план с адекватной ценой для сайтов, которым необходим размер БД более 2 Гб? © s_lek
Направляя трудовые ресурсы на обеспечение потребностей 1% пользователей мы рискуем потерять 99%. У нас раз в неделю какой-то клиент просит под него сделать какую-то фичу, для того, что б этому клиенту было удобно, что б он не переплатил лишних X грн в год. И мы в начале этим занимались пока не поняли, что это приносит только вред нам и нашим клиентам. Ведь в это же время программисты и сотрудники могли бы сделать функцию, которая бы сделала счастливее больший процент пользователей. И поэтому мы сейчас анализируем, насколько массовым будет счастье при разработке нового функционала. Если функция нужна 1-10 клиентам из сотни тысяч, то она не стоит внедрения.
Ведь есть же тарифные планы с различным дисковым пространством, есть возможность докупить дисковое пространство, почему нет возможности докупить увеличение базы данных? © s_lek
Одна из причин это то, что бекапы баз данных создаются не так как создаются бекапы аккаунтов. Бекапить таблицу в несколько гигабайт, которая постоянно меняется это не одно и то же что бекапить файл (будь то образ диска или тысяча мелких файлов).
PS. Надеюсь вы отнесетесь с пониманием к нашей точке зрения. Она не отражает никакого особого отношения к Вашей проблеме, а лишь частично описывает проблематику внедрения некоторых функций. Для того, что б полностью раскрыть ее суть и дать понять причины понадобится не один час.
PSS. Для сравнения могу привести пример общественного транспорта: можно ездить самому, но нельзя перевезти в автобусе/трамвае/электричке шкаф, если он превышает максимально допустимые размеры указанные в правилах (даже если в дверь влазит) и нельзя купить билет, который бы это позволил. Если найдете ответ почему так нельзя, вы поймете почему на виртуальном хостинге нельзя размещать слишком большие БД.
