Здравствуйте, DSD, Вы писали:
DSD>>>Удобства себе программист лолжен обеспечить сам. Отдельно. R>>Ну тогда надо писать на асме =)) DSD>Тогда уж лучше скажите — сразу на машинном коде, ведь компилятор — тоже "удобство для программиста". DSD>Где-то в юморе кажись, проскакивала клава всего с тремя кнопками: "0", "1" и "Done". самое оно.
Ну дык по Вашей логике так и получается — это ведь действительно быстрее будет. Да и машинные коды тут не причем — ассемблер все равно в них один в один переводится.
R>>М-м-м. Вы меня не совсем правильно поняли. Я пытаюсь сказать, что преимущество БД перед ФС (у которой при правильной организации скорость возможно действительно чуть-чуть возрастет (но именно чуть-чуть — см. пост Андира)) DSD>Для меня Андир пока что: собеседник и оппонент в некоторых довольно интересных спорах и дискуссиях, но он еще не перешел в разряд "Фигурновых, Страуструпов и пр.", так что моё ИМХО — Андир тут весьма заблуждается, и следовательно не стоит мне его утверждения приводить, как откровение Божье. Лучше сами что-то докажите, чем теоретизировать на голом месте и мнениях других. Надеюсь, не слишком резко загнул?
Я имел в виду не мнение Андира, а его пример =)
R>>в том, что БД (при правильном проектировании) хранит данные, а Вы в файловой системе — представление данных. DSD>Хм... Я понял Вашу точку зрения. В таком случае в конечном итоге БД тоже хранит представление данных. Ужас, не так ли? DSD>Еще вопрос, чем именно Вы отличаете эти два понятия? Что такое данные и что такое их представление по-вашему?
Я понимаю, что вообще говоря это одно и тоже =))
Я имел в виду, что в Вашем случае вы используете некий частный случай представления данных, вполне возможно не нормализованный и т.д. Это повышает производительность для одни операций и понижает для других.
R>>Часто используемое — да. Обеспечивающее небольшой прирост производительности — да. Но за все надо платить. В результате потом труднее будет добавлять функциональность, переходя от версии 1.7б к версии 2.0. DSD>Это должно быть продумано на этапе проектирования, а не ценой производительности поддерживать эту возможность во время реальной работы приложения.
Э-э-э ну Вы загнули, на этапе проектировнаия. Это нереально! На этапе проектирования нужно заложить возможность расширения, а не предполагать это расширение. Кто же знал на этапе проектирования, что в ICQ2002b пояится возможность хранить список контактов на стороне сервера?..
R>>Рухнет вся производительность, если прйдется выводить/обрабатывать другое представление данных. Ну и т.д. DSD>Нужно будет — переберу формат. И времени это у меня займет много меньше, чем Вы себе представляете.
Это как, переберете формат??? У вас уже к этому времени будет эн-цать скриптов, которые работают с текущим форматом ...
Ваш способ повышает производительность за счет времни жизни программиста =)) имхо это не оправдано в условиях веб-проектов. Хотя, конечно, леший его знает.
Здравствуйте, DSD, Вы писали:
DSD>>>Странно, мои подобные задачи стали работать гораздо быстрее, когда я их переписал с варианта на MySQL на вариант с использованием файловой системы и кеша. R>>Возможно Вы неудачно проектироали структуру бд. DSD>Кхм... Пора мне в монастырь, похоже, уходить.. DSD>Спроектируй, а? Тогда поверю.
Ну у меня все впереди =))
DSD>>>И еще. Вы действительно почувствовали, что БД работает быстрее, чем FS на своем опыте? То есть Вы пробовали и так, и так, да? R>>Да. Быстрее настолько, что при работе через фс пхп иногда вылетал по таймауту. Такая уж задача была. DSD>Отвечу Вашей же фразой: Возможно Вы неудачно проектироали структуру бд в FS. DSD>А серьезно — не зная условий задачи и способа, которым Вы ее реализовывали, мне трудно судить о чем-либо...
В тот момент, когда я писал первоначальный пост, я еще не уловил всю глубину Вашей идеи , так что снимаю этот аргумент.
DSD>В общем случае мы сравниваем варианты проектирования(и реализации, конечно же) с использованием СУБД и без.
А что тут сравнивать? И так понятно, что под конкретную задачу Ваша ФС будет работать быстрее. Особенно, если ее написать на асме ...
СУБД для того и нужна, чтобы облегчить людям жизнь ... так же, как, например, перл и пхп, хотя писать можно и на с++ и это будет быстрее работать.
[skip]
Лень пока отвечать на всё предыдущее, занят я немного .
DSD>Еще в качестве примера хочу привести какой-нибудь интернет-магазин. DSD>Например http://www.ozon.ru DSD>Это достаточно известный и раскрученный проект, что позволяет судить о присутствии добротной внешней нагрузки на сервер. DSD>Полагаю, что там используется СУБД, ведь врядли у начальства есть столько денег(а точнее, желания их платить), чтобы дать зарплату программистам, которые собрали бы этот сервер без использования СУБД.
Вот здесь я знаю, там стоит CMS Dynasite. А здесь описание платформы динасайта.
DSD>Так вот, мои мысли по поводу: DSD>Там стоит довольно мощная тачка, чтобы выдержать наплыв посетителей.
Полностью прав.
DSD>Я думаю, что если хорошо продумать и собрать эту же систему без использования промышленной СУБД, то для обслуживания того же потока посетителей хватило бы машины, типа Пентиум_сто_шестьдесятшесть_Мэ_Мэ_Ха с умеренным количеством оперативки. Чего с использованием СУБД добиться не удастся.
Там никто этим не занимался, просто купили сразу систему, которой и нужна не слабая выделенная тачка.
DSD>Сужу я не из теоретических знаний, а из практического опыта.
Ну мне наверно практического опыта не хватает, но время пока есть ...
С Уважением, Andir!
Re[20]: По поводу производительности и целостности
Здравствуйте, Rumata, Вы писали:
R>Ну дык по Вашей логике так и получается — это ведь действительно быстрее будет. Да и машинные коды тут не причем — ассемблер все равно в них один в один переводится.
Закроем эту тему в связи с ее большим отношением к юмору, чем к нашему флейму.
R>Я имел в виду не мнение Андира, а его пример =)
Ну, значит по моему ИМХУ — вы оба заблуждаетесь
DSD>>Еще вопрос, чем именно Вы отличаете эти два понятия? Что такое данные и что такое их представление по-вашему? R>Я понимаю, что вообще говоря это одно и тоже =)) R>Я имел в виду, что в Вашем случае вы используете некий частный случай представления данных, вполне возможно не нормализованный и т.д. Это повышает производительность для одни операций и понижает для других.
Ну естесственно. И моя задача — повысить для тех операций, которые будут использоваться, но так, чтобы понижение производительности относилось к неиспользуемым
R>>>Часто используемое — да. Обеспечивающее небольшой прирост производительности — да. Но за все надо платить. В результате потом труднее будет добавлять функциональность, переходя от версии 1.7б к версии 2.0. DSD>>Это должно быть продумано на этапе проектирования, а не ценой производительности поддерживать эту возможность во время реальной работы приложения. R>Э-э-э ну Вы загнули, на этапе проектировнаия. Это нереально! На этапе проектирования нужно заложить возможность расширения, а не предполагать это расширение. Кто же знал на этапе проектирования, что в ICQ2002b пояится возможность хранить список контактов на стороне сервера?..
А Вы думаете, что в ICQ используется промышленная или самописная, но полноценная СУБД?
Или Вы думаете, что добавить функциональность или поле не в СУБД — это так сложно?
Или Вы думаете, что они так долго это делали, потому что это сложно реализовать?
в последних двух вопросах ответ "да" — ошибочен. Для второго вопроса для облегчения работ можно написать тулзу, а что касается третьего вопроса — им нужно было продумать, какие обьемы данных займут эти контакты. Ведь их где-то нужно хранить. А у AOL винты тоже не резиновые Нужно потратить кучу денег на устройства хранения данных, и это при том, что ICQ — бесплатна и в принципе убыточна. Эта тема где-то обсуждалась в инете самой AOL.
Насчет первого не уверен, т.к. у меня нет этой информации и следовательно, наверняка я знать не могу, но думаю, что ответ — тоже "нет".
R>>>Рухнет вся производительность, если прйдется выводить/обрабатывать другое представление данных. Ну и т.д. DSD>>Нужно будет — переберу формат. И времени это у меня займет много меньше, чем Вы себе представляете. R>Это как, переберете формат??? У вас уже к этому времени будет эн-цать скриптов, которые работают с текущим форматом ...
Ну, кстати, не скриптов... Я предпочитаю писать на Си — скорость все-таки А если пишу не на Сях, значит скорость мне не важна и следовательно, можно поюзать и СУБД
Расширить формат — раз плюнуть. Тоже мне проблема... Длину записи для каждого формата, а так же оффсеты и длины полей я храню отдельно в константах. То есть изменить их можно за один раз в одном месте исходника(точнее в заголовочных файлах).
А если приходится глобально и серьезно менять формат хранения данных(т.е. менять почти все) — дык и в СУБД это гемор для программиста.
R>Ваш способ повышает производительность за счет времни жизни программиста =)) имхо это не оправдано в условиях веб-проектов. Хотя, конечно, леший его знает.
Насчет лешего не уверен, но я — знаю Естесственно, я страдаю патологической ленью, как и большинство программистов. И естесственно я всегда все планирую так, чтобы по возможности максимально облегчить себе жизнь в дальнейшем.
Здравствуйте, Rumata, Вы писали:
DSD>>Спроектируй, а? Тогда поверю. R>Ну у меня все впереди =))
Согласен
R>СУБД для того и нужна, чтобы облегчить людям жизнь ... так же, как, например, перл и пхп, хотя писать можно и на с++ и это будет быстрее работать.
Дык ёлы-палы, а кто говорит об отказе от СУБД вообще? Я говорю, что нужно уметь и так и эдак, и совмещать оба метода там, где это выгоднее.
Я просто сетовал на то, что большинство современных веб-программеров(и не только веб) умеют хранить данные только в СУБД(и немножко — в текстовых файлах). И когда от них требуется, чтобы приложение работало быстрее, они не задумываясь идут трясти начальство на более крутые тачки. Мысль понятна? Продолжать не нужно?
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, DSD, Вы писали:
A>[skip] A>Лень пока отвечать на всё предыдущее, занят я немного .
не вопрос
A>Вот здесь я знаю, там стоит CMS Dynasite. А здесь описание платформы динасайта.
Слышал о такой.
DSD>>Я думаю, что если хорошо продумать и собрать эту же систему без использования промышленной СУБД, то для обслуживания того же потока посетителей хватило бы машины, типа Пентиум_сто_шестьдесятшесть_Мэ_Мэ_Ха с умеренным количеством оперативки. Чего с использованием СУБД добиться не удастся. A>Там никто этим не занимался, просто купили сразу систему, которой и нужна не слабая выделенная тачка.
Это вполне естесственно, и я их за это не сужу. В данном случае затраты не так велики и производительность будет приемлемая.
Это был пример почти с потолка.
Просто бывают другие проекты или части проектов, в которых ох как стоило бы полностью или частично отказаться от СУБД. И в первую очередь из-за производительности. Читай здесь последний абзац: http://rsdn.ru/Forum/Message.aspx?mid=296824&only=1
DSD>>Сужу я не из теоретических знаний, а из практического опыта. A>Ну мне наверно практического опыта не хватает, но время пока есть ...
Наверно Хотя базы ты, я вижу, знаешь неплохо
Только ты их очевидно хорошо знаешь снаружи, а я — больше изнутри — пришлось ковырять при разработке своих проектов
Мне пришло на ум такое сравнение (люблю аналогии )
Допустим, убийца выбирает оружие из трех вариантов:
1. Ложка (очень больно. говорят)
2. Кухонный нож (есть гарантия, менты не прицепятся)
3. Сделать нож самому или заказать под конкртного человека (стремно и много мороки).
Собственно, я бы выбрал хороший кухонный нож. Это быстрее (его выбрать). Не надо никого боятся при покупки. Не надо боятся своих ошибок. Всегда получишь сервис. Конечно, я понимаю, что не всякий нож может убить любого человека — но можно выбрать подходящий в магазине.
Конечно, я не профессионал в деле про убийства.
Так вот. Ложка — это для любителей поизвращится (текстовые БД). Сделать свой нож — по-моему, тоже извращение, если это не оправдывается ТЗ (своя БД). А Кухонный нож — именно та середина (существующие БД).
А теперь о птичках.
Когда были все записи (правда, в текстовом виде) записаны в файл (на строку шло порядка 400 байт, 8 полей) то когда уже все это достигло 300 тыс — было решено перенести это на БД (MS SQL). Скорость выборки в многопользовательском режиме (веб-сайт, порядка пару обращений в сек) увеличилась в 13 (!) раз. Я знал, что увеличится в несколько раз, но от силы раз в 5.
Причины тому:
1. Блокировки. В текстовом файле когда один пользователь пишет — файл нужно блокировать ЦЕЛИКОМ. В базе же можно блокировать одну запись, в то время другие пользователи смогут обращаться к остальным записям.
2. Индексирование (а не перерывание всего файла в поисках нужной информации. В текстовом иначе нельзя)
3. Кеширование
Если же использовать бинарные файлы, то нам нужно:
1. блокировки (в различных вариантах, от записи до всего файла)
2. язык запросов для эффективного поиска
3. индексирование
4. желательно еще и ограничения, связи
смотрим, что мы получили с бинарного файла? не БД ли уже это?
хотя не совсем БД. Она не клиент-серверная. В том же MS SQL все вышеперечисленные механизмы реализованы в серверной части БД, у нас же в самой программе. Очень смахивает на DAO с Access'ом — есть mdb-файл и остальная вся часть реализуется в пользовательской программе с помощью DAO. И почему-то по производительности это сильно уступало серверным БД и от этого давно отказались...
ЗЫ. Конечно, я не могу не согласиться, что для одного запроса в минуту бинарный файл будет эффективнее
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, DSD, Вы писали:
DSD>>Возможно это зависит от размера читаемого файла. Того самого, который txt-шник...
А>Вы пример смотрели? Там файл размером 260К, причем zip
264K
DSD>>Сдается мне, что file_get_contents() будет выигрывать только на мелких файлах.
А>И он выигрывает
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, DSD, Вы писали:
DSD>>Возможно это зависит от размера читаемого файла. Того самого, который txt-шник...
А>Вы пример смотрели? Там файл размером 260К, причем zip
DSD>>Сдается мне, что file_get_contents() будет выигрывать только на мелких файлах.
А>И он выигрывает
а если файл размером в десятки или сотни мегабайт? как, например число пи до нного знака после запятой. или геофизические данные?
Здравствуйте, Ветер, Вы писали:
В>В общем писал я парсер хтмл для пхп и даже написал. Сам тектс для разбора хранится в одной строке (не надо его разбирать построчкам). И работает медленновасто. Но вообще то для таких целей по-моему используют XML, а для него парсер в пхп уже встроен.
В>сам парсер валяется www.fareastmotors.ru/parser/index.php
В PHP PEAR есть SAX парсер (их там целых два), позволяющий ппарсить неправильные XML-файлы (типа HTML).
Там также есть Code colorer, можно на них взглянуть
Здравствуйте, Andir, Вы писали:
A>Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией.
кэш уже обработанных файлов...
A>З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными.
веб-приложение с использованием Yukon, вы гурман, товарищ Andir... )
Здравствуйте, Mamut, Вы писали:
M>FCK Editor. Обещают поддержку и Мозиллы.
Супер!
А я недавно ещё один видел, в Постнюке.
Вот пример его работы (вне постнюка) http://www.latinotek.com/script/
Здравствуйте, anonymous, Вы писали:
A>>Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией.
A>кэш уже обработанных файлов...
И? Кэш обработанных файлов стоит закинуть в БД? В иерархическую или реляционную?
A>>З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными.
A>веб-приложение с использованием Yukon, вы гурман, товарищ Andir... )
Ещё какой ...
Собственно в чём проблема? Новая версия Sql сервера не является чем-то типа Космического аэродрома типа Байконур, а web-приложения бывают не такие и слабенькие, что для них сгодится и файловая система ... Тонкие клиенты нонче не редкость.
P.S. Старая уже дискуссия, сейчас бы доводы уже немного выросли в цене
Здравствуйте, Кодт, Вы писали:
M>>FCK Editor. Обещают поддержку и Мозиллы. К>Супер! К>А я недавно ещё один видел, в Постнюке. К>Вот пример его работы (вне постнюка) http://www.latinotek.com/script/
Здравствуйте, Andir, Вы писали:
A>>>Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией. A>>кэш уже обработанных файлов... A>И? Кэш обработанных файлов стоит закинуть в БД? В иерархическую или реляционную?
извиняюсь... я невнимательно прочёл твой пост...
A>>>З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными. A>>веб-приложение с использованием Yukon, вы гурман, товарищ Andir... ) A>Ещё какой ... A>Собственно в чём проблема? Новая версия Sql сервера не является чем-то типа Космического аэродрома типа Байконур, а web-приложения бывают не такие и слабенькие, что для них сгодится и файловая система ... Тонкие клиенты нонче не редкость.
да собственно мы речь то ведём о той системе, которую собрался строить Кодт... думаю с Yukon'ом ему совсем не по пути...
A>P.S. Старая уже дискуссия, сейчас бы доводы уже немного выросли в цене
Здравствуйте, lozzy, Вы писали:
L>Привожу простой пример, показывающий несостоятелность ФС-варианта: L>Допустим у нас 1 запись на 1 файл. Допустим они (данные) хранятся в определенном формате. Допустим надо вывести название, скажем, каждого продукта, который хранится в файле. L>Вопрос: насколько быстрее будет выбрать данные из базы нежели открывать каждый файл и выцарапывать оттуда название ?
можно просто создать файл со всеми названиями продукта — своеобразный индекс...
L>И таких вариантов — вагон и маленькая тележка.
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, Кодт, Вы писали:
M>>>FCK Editor. Обещают поддержку и Мозиллы. К>>Супер! К>>А я недавно ещё один видел, в Постнюке. К>>Вот пример его работы (вне постнюка) http://www.latinotek.com/script/
A>HTMLArea
Это конечно оффтоп и флейм, но вот людям делать нечего! : )
, так что снимаю этот аргумент.
Перекуём баги на фичи!
