netwind: ну, например, vbulletin хранит опции голосования в таблице poll подобным способом.
если захочется какую-то нестандартную статистику подсчитать, вероятно придется прибегнуть к подобным вычислениям.
могу придумать 2 варианта
1) непонимание SQL
2) они не применяют SQL для этих данных, обрабатывают данные на PHP, что, обычно, не очень верно
табличка pool вида pool_id, option_num, vote_count
и все становится не просто, а очень просто
SELECT vote_count FROM pool WHERE pool_id = 1 AND option_num = 5;
netwind: если файлы конвертировать в бд не как есть, а нормализируя базу, то объем может получиться меньше.
В принципе наверное можно такую базу придумать. На практике индексы занимают объем больший чем собственно данные. Не забывайте также о введении новых сущностей как суррогатные первичные ключи или появление в физической модели новых таблиц напр для описания связи много-ко-многим. Не забываем о лог-файлах также
Ну и конечно никто не проводит полную нормализацию, иначе сильные тормоза
iopiop добавил 18.12.2011 в 09:34
StarDust:
Идейка, скажем так, на уровне студента первого курса, без обид.
ну что вы так.. TC как раз подошел к идее держать метаданные отдельно, вон уже и структурка выделяется потихоньку
Для поиска по метаданным строим индекс. Вот по индексу уже и будем бродить.
Это уже будет второй этап, когда ТС поймет что линейный поиск - это глупо
у меня на работе БД шесть гиг, причем только цифирьки разные, т.е. по вашей структуре только поля типа 1, 3, 4.
самая большая (из сотни где-то) таблица - 2 млн записей.
и да, это в мире БД это считается небольшой, ничем не примечательной базой.
структура у ТС дерьмо. хранить метаданные вместе данными - зачем? зачем перечитывать постоянно кучу ненужной иннформации? должен быть один файл, в котором поля 1,3,4, а собственно файлы должны лежать либо все по отдельности рядом, либо в одном большом файле (уж не знаю по какой причине). в последнем случае в метафайле добавляется поле в котором записана позиция файла и, для удобства, его длина.
а чтобы поиск быстрый был, нужно к метафайлу индекс построить, какое-нибудь двоичное дерево (быстрее еще ничего не придумали), чтобы не последовательно все читать.
и в результате получаем все ту же базу данных. с одной только разницей что в текущих БД уже все это давно сделано, протестировано и сильно заоптимизировано как на скорость, так и на потребление памяти.
ТС-у - почитать как писался ибей. он тоже сначала был на пхп+файлы. когда количество аукционов достигло 50К, он просто заткнулся. пришлось срочно прикручивать БД. Либо помедитировать на тему "почему фейсбук построен вокруг MySQL, а не на чистых файлах"
и да, не нужно изобретать очередной велосипед
iopiop добавил 17.12.2011 в 22:24
SeVlad: Ты не поверишь - именно по этой причине и были придуманы БД. В БД данные занимают на порядок меньше места.
это как, БД их сжимает, что ли? ;-)
на самом деле все с точностью до наоборот, т.к. структура БД очень рыхлая + куча индексов, которые обычно занимают места больше чем собственно данные. Все в угоду скорости.
Не только при листинге, любая групповая операция из шелла (типа удаление по маске или установка прав и прочая) будет тормозить и пожирать память сильно потому что сначала строится список всех файлов и только потом к нему применяются действия.
Глубокую вложенность тоже делать не стОит т.к. открытие каждого каталога = открытие файла, т.е. если у вас вложенность 10 уровней то для чтения одного файла на самом деле ОС будет делать 11 операций открытия-чтения-закрытия файла
здесь нужен не индекс по name, а составной индекс по всем трём столбцам. Но на всякий случай EXPLAIN лучше сделать для гарантии.
сомневаюсь я что такой индекс тут поможет чем-то.
если бы было WHERE group = 1 AND newsnum = 0 - тогда да.
Arskillord, ну раз поисковый трафик у меня не пропадет, может мне и не нужен вас сервис?
скорее всего пропадет, т.к. сайт будет пессимизирован из-за черного SEO
iopiop, скорее 2. если не согласен - можешь купить и написать им багрепорт.
а название пункта голосования как достать?
табличка pool вида pool_id, option_num, option_name, vote_count
me покупать чтобы багрепорт сделать ? 😮
ну, например, vbulletin хранит опции голосования в таблице poll подобным способом.
если захочется какую-то нестандартную статистику подсчитать, вероятно придется прибегнуть к подобным вычислениям.
могу придумать 2 варианта
1) непонимание SQL
2) они не применяют SQL для этих данных, обрабатывают данные на PHP, что, обычно, не очень верно
табличка pool вида pool_id, option_num, vote_count
и все становится не просто, а очень просто
но товарищи выше правильно сказали - какое-то извращение у вас в архитектуре, не sql-ное это дело, стринги разбирать.
говорят один язык освоишь , все остальные пойдут как по маслу..Правду говорит...
Стоит выучить php, а потом уже будешь только так щелкать все.
Неправду говорят. У асемблера, ООП-языка, SQL и функционального языка общее только одно - программы пишутся латиницей. Да и то не всегда.
если файлы конвертировать в бд не как есть, а нормализируя базу, то объем может получиться меньше.
В принципе наверное можно такую базу придумать. На практике индексы занимают объем больший чем собственно данные. Не забывайте также о введении новых сущностей как суррогатные первичные ключи или появление в физической модели новых таблиц напр для описания связи много-ко-многим. Не забываем о лог-файлах также
Ну и конечно никто не проводит полную нормализацию, иначе сильные тормоза
iopiop добавил 18.12.2011 в 09:34
Идейка, скажем так, на уровне студента первого курса, без обид.
ну что вы так.. TC как раз подошел к идее держать метаданные отдельно, вон уже и структурка выделяется потихоньку
Для поиска по метаданным строим индекс. Вот по индексу уже и будем бродить.
Это уже будет второй этап, когда ТС поймет что линейный поиск - это глупо
А дальше, глядишь, и до БД дойдет ☝
у меня на работе БД шесть гиг, причем только цифирьки разные, т.е. по вашей структуре только поля типа 1, 3, 4.
самая большая (из сотни где-то) таблица - 2 млн записей.
и да, это в мире БД это считается небольшой, ничем не примечательной базой.
структура у ТС дерьмо. хранить метаданные вместе данными - зачем? зачем перечитывать постоянно кучу ненужной иннформации? должен быть один файл, в котором поля 1,3,4, а собственно файлы должны лежать либо все по отдельности рядом, либо в одном большом файле (уж не знаю по какой причине). в последнем случае в метафайле добавляется поле в котором записана позиция файла и, для удобства, его длина.
а чтобы поиск быстрый был, нужно к метафайлу индекс построить, какое-нибудь двоичное дерево (быстрее еще ничего не придумали), чтобы не последовательно все читать.
и в результате получаем все ту же базу данных. с одной только разницей что в текущих БД уже все это давно сделано, протестировано и сильно заоптимизировано как на скорость, так и на потребление памяти.
ТС-у - почитать как писался ибей. он тоже сначала был на пхп+файлы. когда количество аукционов достигло 50К, он просто заткнулся. пришлось срочно прикручивать БД. Либо помедитировать на тему "почему фейсбук построен вокруг MySQL, а не на чистых файлах"
и да, не нужно изобретать очередной велосипед
iopiop добавил 17.12.2011 в 22:24
Ты не поверишь - именно по этой причине и были придуманы БД. В БД данные занимают на порядок меньше места.
это как, БД их сжимает, что ли? ;-)
на самом деле все с точностью до наоборот, т.к. структура БД очень рыхлая + куча индексов, которые обычно занимают места больше чем собственно данные. Все в угоду скорости.
mod_mem_cache в апаче не используется?
Спасибо. Прояснилось.
Вот еще нахабрил:
http://habrahabr.ru/qa/5574/
http://habrahabr.ru/qa/1196/
И тут интересная мысль, что тормоза начинаются при листинге.
Не только при листинге, любая групповая операция из шелла (типа удаление по маске или установка прав и прочая) будет тормозить и пожирать память сильно потому что сначала строится список всех файлов и только потом к нему применяются действия.
Здесь обсуждалось /ru/forum/665621
Глубокую вложенность тоже делать не стОит т.к. открытие каждого каталога = открытие файла, т.е. если у вас вложенность 10 уровней то для чтения одного файла на самом деле ОС будет делать 11 операций открытия-чтения-закрытия файла