Новая тема   Ответить

 photomuza
Такой вариант: хранить контент постов не в БД, а в отдельных файлах и вставлять примерно такой функцией - [include file="/wp-content/posts/ID_post"]

Размер контента постов (то что вставляется в админке) около 4 кБ, при реогранизации - около 200-400 Байт, сейчас скачал файл .sql с сотней постов (без реогранизации) - 1,9 мБ. Блог планируется с 1К и более постами. Посещаемость сейчас около 1К планируется разгон до 5-10К и более, но в принципе по нагрузке на БД все равно по идее разницы нет, т.к. использую кэширование. А вот по размеру БД - есть ли смысл в такой реорганизации, какое-нибудь преимущество или по барабану?

 Airsnake
Учитывая размер блока современных файловых систем - по барабану. Даже не по барабану, а бесполезная хуйня, купи лучше винт на 1-2 терабайта, если места не хватает.

 photomuza
Да место на винте не причем я вообще прикидываю. Например ограничений нет на размер файла .sql?

Но править посты скопом удобней вообще-то в одном файле .sql нежели скачивать кучу постовых файлов, тем более если они не в одной папке лежать будут. Наверное таки преиимущества нет, надо оставить как есть.

 x123p
База MySQL? Если да то она нормально и быстро работает с 1-2 Млн записей в таблице. Выше вполне вероятно немного подтюнить придёться. И учитывая что базы данных выборки умеют кешировать то прироста большого не будет по производительности. Поставь лучше плагин кеширования Super Cache и тогда вообще во многих случаях к базе даже обращений не будет во время загрузок страниц, получиться что-то типа того что ты придумал, но не так топорно, а продуманно. Сам плагин написан одним из разработчиков WP и мне кажеться ему можно доверять.

 Airsnake
photomuza писал:
Зависит от файловой системы и ОС, но обычно на 2 терабайта можешь рассчитывать

 photomuza
Угу, понял, всем сенкс. Super Cache стоит, супер!