Как хранить большие объёмы информации?

[virus-07]

Собственно, для меня является очевидным, что, к примеру, если на сайте будут большие объёмы информации, то их надо как-то хранить. Например, статьи. БД для этого не подойдёт. Следует использовать xml?

Если не затруднит, напишите вкратце теорию и практику, хотя бы схематично, хранения и использования информации.

Заранее большое спасибо.

P.S. с этим вопросом яндекс мне не помог. спорить не буду, может мои запросы были кривые.

[arez]

Чем вам БД не угодила? У вас статьи по несколько Тб весят?

[stars]

Что значит большой? больше 5 мегабайт чистого текста статьи? Если да то безусловно консервируете архиватором и делаете на сайте списками архив статей, ибо страницы даже если не касаться проблем с хранение более 5 мб это уже не здорово... Если же меньше то проблем в принципе нету, тут возникает другой вопрос насколько большая таблица будет? У меня вот был средненький сервер и он реально стал лагать когда в базе было за 1.3кк строк с текстами однако и это удалось обойти рядом настроек и в последствии новым сервером...

[rus]

на файлах вполне себе пойдет: http://forum.htmlbook.ru/index.php?showtopic=20525

[arez]

Какие файлы? Вы о чем? Как вы будете индексировать, оптимизировать, делать выборки, править и искать по плоским файлам? Текст нужно хранить в БД (5мб на статью это копейки), современные БД могут обрабатывать колосальные объемы информации, не будет хватать MySQL переходите на Oracle, не хватает одной БД переходите на кластер. Для картинок и видео полно CDN сетей, для начала вам хватит место на бесплатном Google CDN, потом Amazon S3, Akamai, CacheFly etc.

[rus]

Какие файлы? Вы о чем? Как вы будете индексировать, оптимизировать, делать выборки, править и искать по плоским файлам?

точно так же как и в бд. файлы работают быстрее чем mysql... тот же postgresql быстрее будет.

[arez]

точно так же как и в бд. файлы работают быстрее чем mysql... тот же postgresql быстрее будет.

1. Привидите пример индекса по плоскому файлу, а потом пример того как он может быть быстрее индекса реляционной СУБД

2. PostgreSQL это СУБД такая же как и MySQL, быстрее она или нет понятие субъективное. К чему вы её тут привели вообще не понятно. Я тоже много красивых слов знаю и поэтому Cassandra быстрее Oracle а MongoDB так вообще всех порвет.

Edited December 3, 2010 by arez

[rus]

1. Привидите пример индекса по плоскому файлу, а потом пример того как он может быть быстрее индекса реляционной СУБД

2. PostgreSQL это СУБД такая же как и MySQL, быстрее она или нет понятие субъективное. К чему вы её тут привели вообще не понятно. Я тоже много красивых слов знаю и поэтому Cassandra быстрее Oracle а MongoDB так вообще всех порвет.

1) некогда мне тут примерами раскидываться когда люди уже все написали за меня.

2) хоть mysql, хоть postgresql - хранят инфу в файлах.

З.Ы. для данного случая ТС не уточнил на сколько большие объемы инфы будут, для каждого эти понятия разные. а по поводу того что будет быстрее работать, так это еще ведь зависит от того каким подходом ты воспользуешься и какое изначальное тз, ведь при написании запросов их еще можно и оптимизировать, а если еще и кэшированием воспользоваться, так это ж вообще лепота! тут конечно mysql будет рулевым.

Edited December 3, 2010 by rus

[arez]

1) некогда мне тут примерами раскидываться когда люди уже все написали за меня.

"Вывод из сравнения можно сделать такой: без учета времени на открытие файла/соединение с БД, поиск средствами php по данным, находящимся в оперативной памяти, осуществляется в среднем в два раза быстрее, чем средствами MySQL по данным, находящимся в БД."

Ага, только "Без учета и средствами php", еще там тестируется просто поиск. Ну да ладно это все не важно.

2) хоть mysql, хоть postgresql - хранят инфу в файлах.

Ну в общем то хранить больше негде в конечном итоге вопрос лишь заключается в том на сколько ваш алгоритм доступа будет быстрее и универсальние чем тот что уже написан до вас В любом случаи не думаю что автор топика способен написать алгоритм доступа лучше чем это сделали разработчики какой нибудь СУБД.

[tolya100595]

музыкальные файлы я сжимал конвертерами..с 5мб до 131кб..

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

[Vlad]

Что-то сомневаюсь, что так сильно можно ужать музыкальные файлы, в том же mp3 уже сжатие применяется, при сжатии копейки выиграешь разве что. Можно конечно битрейт уменьшить и моно поставить, но это же ё-моё.

[virus-07]

Признаться, не ожидал такой активности. Очень удивлён. В первую очередь хочу поблагодарить всех отписавшихся: спасибо что не поленились расписать что-как.

Вообще не планировал сильно большие объёмы, в пределах 5-10мб. Знания о св-вах бд лишь поверхностные. Не думал, что они подойдут для хранения таких объёмов.

А как обстоит дело с разделением информации на разные БД? В каких случаях имеет смысл заводить несколько баз и сильно ли усложняется процесс обслуживания?

Edited December 3, 2010 by virus-07

[Vlad]

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

[arez]

А как обстоит дело с разделением информации на разные БД? В каких случаях имеет смысл заводить несколько баз и сильно ли усложняется процесс обслуживания?

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

В большинстве случаев вообще не затрагивает вас, что кластер из нескольких БД что одна БД это единый объект, для вашего приложения все прозрачно. Сейчас технологии облачных вычислений позволяют конечному пользователю просто писать приложение и задумываться о его ресурсах только когда деньги в кошельке кончаются.

[virus-07]

Ещё раз большое спасибо. Круто =)