Есть простейшая база. там 3 таблицы. 2 пустые, а вот третья id - int(10) и url - char(52). У нее так же имеется составной уникальный индекс по 2 полям. По моим скромным познания в mysql int(10) - это 4 байта, а char(52) - 52 байта. То есть вся строка весит 56 байт при любом раскладе? Или я не понимаю? Таким образом 200 000 строк это 11 200 000 байт /1024/1024 = ~10,68 мегабайт Сейчас там 203 269 строк. За каким то при юзание вот этой команды- Код (Text): SELECT table_schema "database_name", sum(data_length+index_length)/1024/1024 "Data Base Size in MB" FROM information_schema.TABLES GROUP BY table_schema размер показан как 32.75 Мб. А у хостера в панели управления он вообще значится 44.34 мб. Как так че за. Объясните плиз.
Индексы, ещё хранение не идеально, есть накладки, хостер может ещё считать всякий мусор, фрагментация, кэш
удаляемые записи не удаляются, пока не пропуржишь спецом более того, файл сам по себе не уменьшается ни при каком раскладе вроде только грохнуть базу или таблицу и восстановить из бэкапа. проблема ещё в том, что мускул по умолчанию хранит все таблицы в одном файле
Об этом я читал, но это ничего не объясняет. Ок я может чем-то забил и немного удалял. Но насколько я знаю хоть вес не меняется, но новые данные туда пишутся пока реальный вес и вес "виртуальный" не совпадет и дальше будут расти. Но база свежая. Я сейчас ее забил на 5,5кк и там столько 100% никогда не было. По расчетам 5,5кк * 56байт /1024 /1024 = ~ 300 мегабайт Но ведь сука хостер пишет 841. Почти 3 раза больше, КАРЛ!!! Ну что это составной уникальный индекс так много весит? Ну я могу понять в 2 раза больше, типа все данные скопировал и отсортировал. Но ведь ПОЧТИ В 3 РАЗА, КАРЛ! Дальше веселей. Вот все стабильно 841. Я добавил простой индекс по id и размер сука увеличился до 1,17 гб то есть примерно на 330мб. Откуда наxуй такая цифра когда даже просто дубль этих отсортированных чисел должен быть примерно 5,5кк * 4 / 1024 /1024 = 20мб. Если это норма, то может кинете ссылку на то как это все образуется и весит. Должны же быть данные/документация как все это происходит. Ведь люди когда закладывают свои сервисы как то считают какое им надо хранилище под базы, если с такой же активностью пользователей у них к концу года будет, например, 10ккк записей в их базе. Или это для всех сюрприз 6лять? Я хочу иметь 1ккк записей. Как мне узнать какой мне объём диска мне надо выбрать на VDS? И может выбрать другую СУБД? Ничего супер сложного у меня нету. Таблицы простые, только данных много и нужны быстрые выборки
Ну я и забил 5.5кк как эксперимент. Результат то меня шокировал нах. По ним мне нужен диск более 200гб, чтобы получить 1ккк записей с пустячковыми данными. цифрой айди и ссылкой (которую я уже сократил без всяких https://) Это смешно просто! Хотя по первым теоритическим прикидкам там и сотни хватило бы за за глаза с запасом.... а для начала бы даже и 10гб (размер хоста), чтобы получить первые данные и понять есть ли вообще смысл продолжать и будет ли интересно. Это даже не выборки если терминологию соблюдать, а так выявление закономерностей, типа общие ссылки у разных айди, например.
Это вообще не расчет, а фикция) Все данные на диске хранятся не непрерывно и 56 байт на диске могут занимать все 64 или даже 128 байт. Обычно происходит поблочная запись и чтение, что ускоряет операции записи / чтения. Уже не раз упоминали индексы, которые могут превосходить объем данных в несколько раз Ко всему прочему СУБД использую массу дополнительных структур данных для эффективного решения определенных задач, которые тоже занимают место. В процессе использования размеры БД будут расти, т-к уже упомянули, что происходит фрагментация данных и остается мусор, плюс СУБД очень любят кэшировать данные и собирать статистическую информацию для более эффективной оптимизации запросов. Это все место на диске. И еще есть масса настроек в СУБД, которая влияет на объем свопа на диске, который тоже занимает место.
Я хз. Я в аxyе с этих таблиц. Пойду лучше грузчиком работать, ну его наxyй. Юзнул такую команду - SHOW TABLE STATUS IN `mybase` и там средняя длина строки 152 (хотя казалось бы изначально 56). Нет я понимаю что там может быть мусор со всякой инфой для внутреннего пользования и т.д. Но в 3 раза больше это чет много. Дальше я делаю OPTIMIZE TABLE `mytable` и к моей радости у хостера размер стал 845 вместо 1,17гб а средняя длина стала 94. Идем еще дельше и я удаляю составной индекс. Ваххх размер 577 и средняя длина - 90. Но тут я в аxyе замечаю, что записей стало на миллион меньше. Куда делось примерно 18% данных? Делаю еще раз OPTIMIZE TABLE `mytable` - примерно полмиллиона появилось, но ~500к в небытие. При этом я вообще не уверен, за сохранность всех данных и за те что вернулись. THE END. Хэппи энда сегодня не будет...
@Познающий php надо либо самому глубже копать как работает mysql или взять консультацию, мало вероятно, что тут кто-то очень точно ответит на такой вопрос. Потому что тут много всего, как настроена ОС, какая ФС, версия БД, настройки БД и т. д.
Есть опыт во многих бд? Может быть в mariaDB или postgres получше с весом базы? Прим это скорость выполнения запросов конечно должна быть не хуже. Дак это все у хостера. Я тоже не знаю. Если это норма такой вес, то это очень печально и не ясно куда податься
Просто найти движок для базы который более экономно хранит записи, та же архивация а mysql должны быть
У postgres гораздо большие возможности по сжатию данных, в т-ч сжатие индексов. Но в нем есть места, которые занимают больше дискового места, например самообучающая система для оптимизатора, которая собирает сотни различных метрик. Здесь нет понятия update записи, на физическом уровне, только вставка, старые данные остаются и с какой-то периодичностью подчищаются вакуумом. P.S. На таком кол-ве записей даже простые запросы могут работать медленно (зависит конечно от специфики запросов). И может потребоваться не то, что хостинг, а даже далеко не рядовой VPS.
@t1grok это все лирика общая. Скажи мне если у тебя есть опыт работы и там и там, будет ли выигрыш в весе на 100кк записей (int(10), varachar(55) обычный индекс по обоим полям) или нет? Вообще 1ккк это перспектива. Сперва надо сделать 100кк чтобы понять насколько перспективна моя идея и иожно ли мало мальки монетезироваться. В любом случае я взялся за это чтобы получше разобраться в базах. А 1ккк это уже считай highload ))) Буду в резюме указывать ) P.S На 5кк нужные мне запросы происходят за вменяемые доли секунды. А вообще есть уже задумки как первый запрос делать большим на перспективу и хранить все в более мелкой таблицы. Нагрузка будет намного меньше и скорость гуд. Правда места надо много будет... а с ним чет самая напряженка. Не хочу с хостинга съезжать =(((
Я работаю как с mysql (и форками в т.ч.) так и postgres и nosql решения. Но никогда не замерял объемы занимаемого места. Не знаю специфики работы вашей системы, но более, чем уверен, что обычный хостинг "не вывезет". И в процессе вы столкнетесь с проблемами посерьезней, чем место на диске, которое кстати у многих провайдеров можно докупить. --- Добавлено --- hilgload измеряется не в количестве, строк в БД если что.. У вас может быть и 1ккккк строк данных и это может быть не hilgload.
Не знаю если честно каких-то критериев highload )) Но будет база 1ккк и будут пользователи которые ее юзают ))) Чем не хайлоад, если многие уже говорят что проблем будет море )) Намного яснее то и не стало. Но хоть марию то вместо mysql в любом случае выгодней ставить на vds или нет? Читал сравнения, вроде одни сплошные плюсы.