Делать двиг на бд или файлах?

А кстати вот это мне очень интересно с практической точки зрения. Есть примеры реализации? Что имеется в виду под "типичным поведением ботов" и причем тут структура сайта? Проясни мысль, не понял. Если данные для формирования страниц берутся из разных таблиц, то как разработчик может их расположить на диске определенным образом? Кластерные индексы, насколько я был в курсе до сегодняшнего дня, упорядочивают данные в таблицах, но таблицы друг относительно друга никак не упорядочиваются. Также, кластерный индекс будет достаточно сильно сказываться на скорости изменения данных и давать выигрыш только при чтении. И к тому же я был уверен, что линуксовая файловая система по производительности не сильно теряет от фрагментации файлов на диске, поэтому тут можно говорить исключительно о роли движка СУБД как о кэширующем в памяти данные с диска механизме (чего у неё не отнять, конечно).

stealthy добавил 26.10.2009 в 15:46

bearman, нет, Perl. А какая разница на чем писать? Алгоритмы работы с данными реализуются везде одинаково. Сразу уточню, что мы реализовали некоторый специализированный движок, заточенный под нужды именно веб-приложений. По мере удаления о целевого назначения движок будет терять в эффективности, хотя у нас он стоит как отдельный блок в антиспам системе, например.

понятно. спасибо за ответы.

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

Linux настолько крут, что именем своим преодолевает физическое ограничение на время позиционирования головок при фрагментации файлов ☝

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

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

Единственно, что всё это может быть полезно для sapёров или для дорвейщиков, так как структура сайтов у них задана и известна заранее да и боты обходят сайт по одним и тем же траекториям, начиная с корня сайта. Кроме того, их сайты больше посещают боты, а не люди. И этих ботов реально много.

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

Да, Вы можете сделать схожий финт средствами файловой системы Linux. Например, собрав через Google Analitics статистику посещаемости и разместив самые посещаемые 10-30 страниц в одной папке. При этом придётся постоянно перетаскивать всякие новости из "папки для топовых сраниц" в папку с обычными новостями. Но нужно ли так извращаться? Может стоит потратить время на более интересные занятия, а таблицы просто поставить на автоматическую еженочную сортировку по числу посещений?

Слава Шевцов, классно! 2:0 я считаю в сторону славы =)))

Слава, во-первых я никого не называл дураками. И мне совершенно непонятен тон, который ты выбрал для ответов в этом топике. Ты какую цель преследуешь? Доказать что файловых СУБД не бывает? Что они так плохи что ими нельзя пользоваться в принципе? Что ты разбираешься в предмете, а я, к примеру, - нет?

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

Если я что-то спросил - значит мне интересно услышать ответ. Если я спросил решалась ли подобная задача на практике - мне это интересно. А если мне вместо ответа советуют что-то там пойти почитать, не зная моего уровня и того чем я владею, или придумывать теоретические обоснования моей неправоты - меня дискуссия интересовать перестает моментально. Умный? Не понтуйся. Поделись знаниями, тебе скажут спасибо. Мне лично не жалко поделиться своим опытом, потому что 99% людей никогда сами тех вещей что я проходил не попробуют. Пусть учатся, сравнивают и делают обоснованные выводы, вместо того чтобы мыслить холиварными штампами. Когда-нибудь я смогу с ними пообщаться и чему-то у них научиться.

Ты там про профессионализм и крайние суждения заикался? Бревно из глаза помочь вытащить?

Системы на файлах имеют право на жизнь в рамках поставленной ТС задачи и справляться с задачей будут ничуть не хуже, у меня есть для этого результаты многолетнего использования систем на файлах и с СУБД. И то какие у них есть преимущества и недостатки я прекрасно знаю. Идеальных во всем решений не бывает. В данном случае, если брать задачу ТС - с ней справится что файловая система, что СУБДшная. Вопрос в тонкостях и деталях реализации системы. А что не сделает CMS - тривиально делается вспомогательными админскими средствами. Все остальные измышления меня более не интересуют. Позвольте откланяться.

bearman, целовать нужно ниже.

stealthy, ты забавен. раз уж ты выбрал обращение на "ты".

Вах, вах, вах, наверно при чтение с БАЗЫ обращений к диску нет, данные не фрагментированы, в файлах ничего не хранится и все так радужно и красиво.

+1 :) DBA наверное тоже дураки придумали?)))

Уважаемые, данный спор просто бессмысленный, т.к. конечный выбор зависит от задач.

в РСУБД есть реляционные (реляционная алгебра) и распределенные вычисления, например если будет реплицированна на несколько серверов, то вся система будет работать стабильно и выдерживать большие нагрузки

есть некоторые алгоритмы которые позволяют делать некоторые операции даже быстрее чем РСУБД (и даже на много быстрее, например релевантности не было на innodb, если я не ошибаюсь) ...

но как будет на практике никто не знает...

====

еще веб сервер будет статику отдавать на много быстрее чем динамику, смотря какой контент, подобная тема где-то была, например, сайт opennet.ru сделан на файлах, статьи на файлах

Я отвечу лишь на эту часть. На остальную - нет желания, ибо она непринципиальная.

Я считаю, что Вы разбираетесь в предмете, что Вы - профессионал в области файловых БД. Но мне кажется (я могу ошибаться), что как и у многих увлечённых своим продуктом предпринимателей, Вы видите возможности своей системы и значительно хуже видите возможности систем, выполняющих аналогичные функции - промышленных СУБД. И лишь в этой части было то моё высказывание. Кроме того, я создал для поисковика специализированную СУБД, хранящуюся в памяти с копией на диске, и представляю, на что у Вас могло уйти пять лет разработки. Я преклоняюсь перед такой настойчивостью в достижении целей.

А цель моих постов простая - дать людям возможность в простой форме вникнуть в проблему написания своих БД или использования сторонних не промышленных. Пусть увидят тонкости, не парятся и пользуются правильными готовыми решениями - MySQL, PostgreSQL, memcached. Да, они могут заказать или написать свою СУБД и получить соответствующий геморой. Но в итоге, по статистике, всё равно заменят всё написанное на какую-нибудь MySQL.

В этом и была суть постов. При этом, повторюсь, у меня нет никакого сомнения в Вашей компетенции в части создания софта и умения оптимизировать свой софт под высокие нагрузки.