Затеял сделать собственную систему управления контентом (CMS).
Известные мне — phpwebsite, ezpublish, runuke и т.п. — не очень устраивают из-за громоздкости,
а также из-за того, что документы в них хранятся как записи в БД.
Соответственно, сопровождать их нужно через веб-интерфейс, либо через phpMyAdmin.
И пришла мне в голову затея — делать документы-сырцы, скажем, в HTML.
А движок сайта пусть извлекает из них информацию, помеченную особым образом.
К примеру <title>...</title> — это заголовок, <body>...</body> — это текст, и так далее.
В связи с этим пара вопросов
1) Не изобретаю ли я велосипед?
Можно ли где чего почитать на эту тему?
Существуют ли какие-то готовые CMS на основе html-файлов?
2) Технический вопрос
Как парсить многострочный текст?
удается только если $html не содержит CR|LF.
Пришлось воспользоваться ereg, но в документации сказано, что он медленнее. Кроме того, preg мощнее (или я заблуждаюсь)?
Во всяком случае, если я захотел вытащить все-все-все вхождения (preg_match_all), то с помощью ereg такой фокус не получится.
А разбить HTML на строки и парсить каждую по отдельности — не есть правильно: HTML-редактор может навтыкать переносы куда угодно, например, так:
<body
>.....</body>
особенно это касается <div> | <span>, которые нужно различать по их id|class.
(Оговорюсь сразу: в php я новичок, и возможно, делаю какие-то очевидные глупости. Если да — укажите),
А вообще, поищи тут по форуму preg_replace. Тут давеча много чего обсуждалось про регекспы в PHP. В частности, в некоторых моих сообщениях есть необходимые шаблоны и какое-никакое описание, как выкусить весь контент из body.
Например, в этой ветке: http://www.rsdn.ru/Forum/?mid=233630
Здравствуйте, Кодт, Вы писали:
К>Известные мне — phpwebsite, ezpublish, runuke и т.п. — не очень устраивают из-за громоздкости, К>а также из-за того, что документы в них хранятся как записи в БД.
БД — это хорошо, т.к. быстрее, удобнее в доступе и сопровождении.
К>Соответственно, сопровождать их нужно через веб-интерфейс, либо через phpMyAdmin.
А что плохого в первом?
К>2) Технический вопрос К>Как парсить многострочный текст? К>
rtfm вот тут: http://de.php.net/manual/de/pcre.pattern.modifiers.php
К>(Оговорюсь сразу: в php я новичок, и возможно, делаю какие-то очевидные глупости. Если да — укажите),
имхо тестовый цмс того не стоит. Честно говоря, так и не понял чем плохи "БД цмс"
Первый вариант — не прошел.
Второй — дал лишний элемент в $result.
На самом деле, как уже написал vamp, правильное решение — опция поиска s.
DSD>А вообще, поищи тут по форуму preg_replace. Тут давеча много чего обсуждалось про регекспы в PHP. В частности, в некоторых моих сообщениях есть необходимые шаблоны и какое-никакое описание, как выкусить весь контент из body. DSD>Например, в этой ветке: http://www.rsdn.ru/Forum/?mid=233630
Здравствуйте, Rumata, Вы писали:
К>>Известные мне — phpwebsite, ezpublish, runuke и т.п. — не очень устраивают из-за громоздкости, К>>а также из-за того, что документы в них хранятся как записи в БД. R>БД — это хорошо, т.к. быстрее, удобнее в доступе и сопровождении.
К>>Соответственно, сопровождать их нужно через веб-интерфейс, либо через phpMyAdmin. R>А что плохого в первом?
Чтобы залить статью с форматированием,
я сначала готовлю ее HTML-код в каком-нибудь редакторе (ворд, дримвивер, хомяк),
затем выдираю содержимое между <body>...</body>,
копирую в клипборд,
вставляю в текстовое поле формы публикации,
понеслась душа в рай.
И так — для каждой статьи. А если мне надо что-то поправить?
А файловый цимес выглядит так:
Я имею сайт-черновик (голые статьи без обвески), который сопровождаю тем же дримвивером.
Могу сделать массовую закачку по ftp.
При желании можно сделать автоматическую синхронизацию базы данных (например, чтобы собирать карту сайта, навигацию и новости). А можно и обойтись — просто в том же сайте-черновике держать служебные страницы, которые поправлять руками.
К>>2) Технический вопрос К>>Как парсить многострочный текст? К>>
Здравствуйте, Кодт, Вы писали:
К>На самом деле, как уже написал vamp, правильное решение — опция поиска s.
Не правильное, а одно из правильных
Не делайте себе из этого жесткое правило. Опция s — действительно воспринимает любой текст как одну строку, но она является опциональной, и присутствует не во всех движках регулярных выражений(так же, как и опция m и несколько других). А где присутствует, не всегда работает так, как хотелось бы.
Точно работает в Юникс-перле, вот выяснилось, что и в ПХП тоже... В ActivePerl я встречал какие-то грабли с этой опцией(сейчас уже не помню, что именно она делала не так). В JS RegEx'ах тоже кривость имеется...
Кстати, я бы назвал эту опцию чем-то вроде чит-кода, т.к. она противоречит некоторым правилам регекспов, к примеру нарушается правило, что "."(точка) — это любой символ кроме NewLine(\n).
Кстати, вышеупомянутые глюки были связаны именно с совместным использованием \n в выражении и опции s.
DSD>Точно работает в Юникс-перле, вот выяснилось, что и в ПХП тоже... В ActivePerl я встречал какие-то грабли с этой опцией(сейчас уже не помню, что именно она делала не так).
Постоянно пользуюсь ActiveState Perl, и в том числе поиском с этой опцией. Ни разу не
заметил никаких странностей. Не могли бы Вы привести пример? На случай, чтобы я избегал потенциальных глюков.
DSD>Кстати, я бы назвал эту опцию чем-то вроде чит-кода, т.к. она противоречит некоторым правилам регекспов, к примеру нарушается правило, что "."(точка) — это любой символ кроме NewLine(\n).
Нет. На то она и эта опция — расширять точку на символы перевода строк.
Здравствуйте, DSD, Вы писали:
R>>БД — это хорошо, т.к. быстрее, удобнее в доступе и сопровождении.
DSD>Быстрее??? Сервер БД быстрее, чем файловая система??? Не заблуждайтесь... DSD>А с остальным согласен.
В принципе, это может быть действительно быстрее:
* если одна запись = один файл, то этот файл нужно распарсивать, в то время как в записи уже поля раскиданы.
* если нужно вывести каталог чего-то-там, то выбор будет между SELECT некоторых столбцов из БД и сканированием и распарсиванием файлов в директории.
БД удобнее в доступе и сопровождении?
Тут меня обуревают сомнения. Контроль версий документов, редактирование на локальной машине...
В общем писал я парсер хтмл для пхп и даже написал. Сам тектс для разбора хранится в одной строке (не надо его разбирать построчкам). И работает медленновасто. Но вообще то для таких целей по-моему используют XML, а для него парсер в пхп уже встроен.
Здравствуйте, Ветер, Вы писали:
В>В общем писал я парсер хтмл для пхп и даже написал. Сам тектс для разбора хранится в одной строке (не надо его разбирать построчкам). И работает медленновасто. Но вообще то для таких целей по-моему используют XML, а для него парсер в пхп уже встроен.
Можно, конечно, по-простому XHTML интерпретировать как XML. Но, как я понимаю, в PHP реализован SAX, а мне скорее пригодится DOM.
В>сам парсер валяется www.fareastmotors.ru/parser/index.php
Здравствуйте, Кодт, Вы писали:
R>>>БД — это хорошо, т.к. быстрее, удобнее в доступе и сопровождении.
DSD>>Быстрее??? Сервер БД быстрее, чем файловая система??? Не заблуждайтесь... DSD>>А с остальным согласен.
К>В принципе, это может быть действительно быстрее: К>* если одна запись = один файл, то этот файл нужно распарсивать, в то время как в записи уже поля раскиданы. К>* если нужно вывести каталог чего-то-там, то выбор будет между SELECT некоторых столбцов из БД и сканированием и распарсиванием файлов в директории.
Сколько необходимо ресурсов, чтобы установить соединение с сервером БД?
Сколько кушает сервер БД при парсинге запроса?
---//--- при отборе записей и вытаскивании полей?
---//--- при упаковке и отсылке данных вашему приложению?
Сколько кушает ваше приложение(клиентский API сервера БД) при приеме данных от сервера и преобразование из протокольного потока в удобоваримую для вас структуру?
Сервер БД очень удобен при поиске и выборке данных, когда самому все это лень писать.
Ну и кеширование в нем конечно тоже немалую роль играет в определенных случаях(но не во всех).
Здравствуйте, Кодт, Вы писали:
К>>>Соответственно, сопровождать их нужно через веб-интерфейс, либо через phpMyAdmin.
К>А файловый цимес выглядит так: К>Я имею сайт-черновик (голые статьи без обвески), который сопровождаю тем же дримвивером. К>Могу сделать массовую закачку по ftp. К>При желании можно сделать автоматическую синхронизацию базы данных (например, чтобы собирать карту сайта, навигацию и новости). А можно и обойтись — просто в том же сайте-черновике держать служебные страницы, которые поправлять руками.
Не занимайся фигней. Копай в сторону шаблонов и онлайнового редактора на основе IE. Хороший редактор стоит денег, но есть демки, из которых можно все выцепить. Вот например отсюда — http://www.webedpro.com/ . Если совесть не позволяет — можешь написать сам — все достаточно просто, и описано в МСДН.
R>>имхо тестовый цмс того не стоит. Честно говоря, так и не понял чем плохи "БД цмс" К>Трудоемкостью редактирования материала.
Еще раз : копай в сторону онлайнового редактора.
Здравствуйте, lozzy, Вы писали:
L>Не занимайся фигней. Копай в сторону шаблонов и онлайнового редактора на основе IE. Хороший редактор стоит денег, но есть демки, из которых можно все выцепить. Вот например отсюда — http://www.webedpro.com/ . Если совесть не позволяет — можешь написать сам — все достаточно просто, и описано в МСДН.
Насчет фигни, тут я бы поспорил.
Берем готовый цимес, тот же ruNuke или phpWebsite,
там есть какие-то требования к вводу материалов,
хакаем его вдоль и поперек, чтобы понять, как он устроен,
прикручиваем в нужное место свой собственный редактор (потому что встроенный — это задница),
и, как говорится, "он вокзал ее несколько долгих часов".
Очень мне это улыбается.
R>>>имхо тестовый цмс того не стоит. Честно говоря, так и не понял чем плохи "БД цмс" К>>Трудоемкостью редактирования материала. L>Еще раз : копай в сторону онлайнового редактора.
Нафиг мне это надо? Лучше я сделаю модуль upload+export html в базу данных, а редактировать буду в оффлайне, за чашкой кофэ.
Здравствуйте, Кодт, Вы писали:
К>Насчет фигни, тут я бы поспорил. К>Берем готовый цимес, тот же ruNuke или phpWebsite, К>там есть какие-то требования к вводу материалов, К>хакаем его вдоль и поперек, чтобы понять, как он устроен, К>прикручиваем в нужное место свой собственный редактор (потому что встроенный — это задница), К>и, как говорится, "он вокзал ее несколько долгих часов".
К>Очень мне это улыбается.
А в чем трабл-то ? Не виже совсем. Если сайт простой, то нафига тебе вообще эти нюки надо ?
R>>>>имхо тестовый цмс того не стоит. Честно говоря, так и не понял чем плохи "БД цмс" К>>>Трудоемкостью редактирования материала. L>>Еще раз : копай в сторону онлайнового редактора.
К>Нафиг мне это надо? Лучше я сделаю модуль upload+export html в базу данных, а редактировать буду в оффлайне, за чашкой кофэ.
Ну, если сидишь по часам, тогда оно то самое. А ежели на локалке сервак — сам бог велел онлайн делать.
Здравствуйте, DSD, Вы писали:
R>>>>БД — это хорошо, т.к. быстрее, удобнее в доступе и сопровождении.
DSD>>>Быстрее??? Сервер БД быстрее, чем файловая система??? Не заблуждайтесь... DSD>>>А с остальным согласен.
К>>В принципе, это может быть действительно быстрее: К>>* если одна запись = один файл, то этот файл нужно распарсивать, в то время как в записи уже поля раскиданы. К>>* если нужно вывести каталог чего-то-там, то выбор будет между SELECT некоторых столбцов из БД и сканированием и распарсиванием файлов в директории. DSD>Сколько необходимо ресурсов, чтобы установить соединение с сервером БД? DSD>Сколько кушает сервер БД при парсинге запроса? DSD>---//--- при отборе записей и вытаскивании полей? DSD>---//--- при упаковке и отсылке данных вашему приложению? DSD>Сколько кушает ваше приложение(клиентский API сервера БД) при приеме данных от сервера и преобразование из протокольного потока в удобоваримую для вас структуру?
Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать.
btw по поводу сопровождения: бд сопровождать гораздо удобнее, если есть правильные инструменты для этого.
Здравствуйте, Rumata, Вы писали:
DSD>>Сколько необходимо ресурсов, чтобы установить соединение с сервером БД? DSD>>Сколько кушает сервер БД при парсинге запроса? DSD>>---//--- при отборе записей и вытаскивании полей? DSD>>---//--- при упаковке и отсылке данных вашему приложению? DSD>>Сколько кушает ваше приложение(клиентский API сервера БД) при приеме данных от сервера и преобразование из протокольного потока в удобоваримую для вас структуру?
R>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать.
То есть, по вашему мнению, сервер БД к файловой системе не обращается, так?
Так вот, спешу вас разочаровать, он и к fs обращается, и все вышеперечисленное делает. И как я сказал, чуть снижается ресурсопотребление только за счет некоторого кеширования данных.
Что же касается хранения данных в своем формате и работы с ними, то тут быстродействие большей частью зависит от того, на каком языке вы программируете данное приложение. Ясен пень, что сервера БД пишутся чаще всего на чистом С или С++.
Даже если писать на том же Перле или PHP, многое зависит от того, какие функции использует программист.
К примеру, здесь на форуме многие сами используют и пытаются другим советовать функции типа get_file_contents или что-то вроде того, мол типа такая крутая функция, одним вызовом можно получить любой файл, локальный, сетевой или вообще по URL. Но никто не задумывается, что единственное преимущество этой функции — это ее универсальность, т.е. удобство делать все и в разных ситуациях одним вызовом. Зато при этом в каждом локальном случае эта функция делает туеву хучу разной ненужной работы, как то парсинг аргумента, чтобы получить представление о местоположении файла(локал, сеть, инет), выделение в памяти буффера под содержимое(хотя далеко не всегда нужен весь контент файла), ну и т.п. Плюс ко всему, возможно с локальными файлами она внутри себя работает в текстовом режиме, что в таком случае тоже сказывается на ее производительности.
Ясен пень, тут будут тормоза.
R>btw по поводу сопровождения: бд сопровождать гораздо удобнее, если есть правильные инструменты для этого.
С этим не спорю. Однако иногда и тут бывают грабли. Нет ничего идеального
Исходниками поделюсь я их на сайтик выкину сегодня завтра. Правда я его не полировал особо, т.к. еще не закончил. Парсить то он парсит, даже объектную модель строит, единственный трабл — медленно, поэтому для моих целей малоприменим оказался. Мине надо большие таблицы, да еще и с кривым кодом разбирать, а это занимает более 30 секунд, ну и сервак его выкидывает. Так что эту версию я особо полировать и не стал, а вот слегонца переделывать придется. Как тока выложу, сразу скажу.
Здравствуйте, Rumata, Вы писали:
R>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать.
R>btw по поводу сопровождения: бд сопровождать гораздо удобнее, если есть правильные инструменты для этого.
Здравствуйте, DSD, Вы писали:
R>>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать. DSD>То есть, по вашему мнению, сервер БД к файловой системе не обращается, так? DSD>Так вот, спешу вас разочаровать, он и к fs обращается, и все вышеперечисленное делает. И как я сказал, чуть снижается ресурсопотребление только за счет некоторого кеширования данных. DSD>Что же касается хранения данных в своем формате и работы с ними, то тут быстродействие большей частью зависит от того, на каком языке вы программируете данное приложение. Ясен пень, что сервера БД пишутся чаще всего на чистом С или С++.
Я представляю себе, как работает бд, в т.ч. и MySQL. Тем не менее на собственном опыте почувствовал, что она быстрее (во всяком случае для моих задач), чем файловая система.
Примечание: мои задачи =))) это в основном как раз цмс, форум, в общем поддержка сайта.
R>>btw по поводу сопровождения: бд сопровождать гораздо удобнее, если есть правильные инструменты для этого. DSD>С этим не спорю. Однако иногда и тут бывают грабли. Нет ничего идеального
Ну с этим трудно спорить, но все таки, если есть время, гораздо удобнее написать инструмент, чем потом мучаться с совместимостью с чужими.
Здравствуйте, DSD, Вы писали: DSD>К примеру, здесь на форуме многие сами используют и пытаются другим советовать функции типа get_file_contents или что-то вроде того, мол типа такая крутая функция, одним вызовом можно получить любой файл, локальный, сетевой или вообще по URL. Но никто не задумывается, что единственное преимущество этой функции — это ее универсальность, т.е. удобство делать все и в разных ситуациях одним вызовом. Зато при этом в каждом локальном случае эта функция делает туеву хучу разной ненужной работы, как то парсинг аргумента, чтобы получить представление о местоположении файла(локал, сеть, инет), выделение в памяти буффера под содержимое(хотя далеко не всегда нужен весь контент файла), ну и т.п. Плюс ко всему, возможно с локальными файлами она внутри себя работает в текстовом режиме, что в таком случае тоже сказывается на ее производительности. DSD>Ясен пень, тут будут тормоза.
Уважаемый DSD!
Во-первых, file_get_contents()
Во-вторых, удобство данной функции как раз и заключается в том что она бестрее чем какая либо другая функция/конструкция вычитает файл в строку.
Объясняю, что получится, если идти другим путем.
Т.е., например альтернатива:
/*$filepath - url или путь к файлу (практически все пхп функции которые работают с файлом принимают совершенно
нормально url)*/
$content = "";
$content_strings = file( $filepath);
foreach( $content_strings as $string) {
$content .= $string;
}
Хотя в данном случае куда лучше
$content = join( " ", file( $filepath));
Но я уверен, что найдется достаточное количество и тех, кто напишет именно так как в первом случае.
Если говорить о ПХП то его функции работы с файлами все универсальны в том плане, что могут абсолютно нормально принимать URL как аргумент. И это логично — это ВЕБ программирование. Так что твои доводы пе этому поводу весьма
неубедительны.
Вопрос скорости. Любой ПХП код исполняется медленее, чем нативный. Поэтому логичнее с точки зрения быстродействия использовать встроенную функцию, а не писать такую же свою. Поэтому, если надо вычитать весь контент файла в строку file_get_contents — самый быстрый и удобный способ это сделать.
ЖуК>Во-первых, file_get_contents()
Это не принципиально. Я не пишу на PHP. И в доку не лазил, чтоб посмотреть, как она точно называется. Главное, чтобы все поняли, о чем речь.
ЖуК>Во-вторых, удобство данной функции как раз и заключается в том что она бестрее чем какая либо другая функция/конструкция вычитает файл в строку.
Речь немного не о том, как вычитать файл в строку, а о том, как вообще быстрее работать с файловой системой.
ЖуК>Объясняю, что получится, если идти другим путем. ЖуК>Т.е., например альтернатива: ЖуК>
ЖуК>/*$filepath - url или путь к файлу (практически все пхп функции которые работают с файлом принимают совершенно
ЖуК>нормально url)*/
ЖуК>$content = "";
ЖуК>$content_strings = file( $filepath);
ЖуК>foreach( $content_strings as $string) {
ЖуК> $content .= $string;
ЖуК>}
ЖуК>
ЖуК>Хотя в данном случае куда лучше
ЖуК>
ЖуК>$content = join( " ", file( $filepath));
ЖуК>
ЖуК>Но я уверен, что найдется достаточное количество и тех, кто напишет именно так как в первом случае.
ЖуК>Еще вариант:
ЖуК>
С Вами бесполезно спорить о производительности, пока Вы не будете себе четко представлять разницу между fread и fgets(в частности как они работают внутри, а не только разницу в синтаксисе вызова), между работой с файлами в текстовом и бинарном режимах, пока вы не будете считать память, занимаемую каждой Вашей переменной в программе/скрипте, а так же память и ресурсы, занимаемые разными системными и библиотечными функциями в процессе их работы.
ЖуК>Если говорить о ПХП то его функции работы с файлами все универсальны в том плане, что могут абсолютно нормально принимать URL как аргумент. И это логично — это ВЕБ программирование. Так что твои доводы пе этому поводу весьма ЖуК>неубедительны.
Вот по теме данной ветки как раз лишнюю часть, отвечающую за работу с URL, лучше бы из этих функций выкинуть.
ЖуК>Вопрос скорости. Любой ПХП код исполняется медленее, чем нативный. Поэтому логичнее с точки зрения быстродействия использовать встроенную функцию, а не писать такую же свою. Поэтому, если надо вычитать весь контент файла в строку file_get_contents — самый быстрый и удобный способ это сделать.
ЖуК>В чем я неправ?
Неправы Вы в том, что если нужно вычитать не весь файл, а только его часть, Вы будете применять file_get_contents, вычитывая его в память, а потом делать всякие substr и т.п. С чего я взял, что Вы будете делать именно так? Да вот с этого: http://www.rsdn.ru/Forum/?mid=272955
Здравствуйте, Rumata, Вы писали:
R>Здравствуйте, DSD, Вы писали:
R>>>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать. DSD>>То есть, по вашему мнению, сервер БД к файловой системе не обращается, так? DSD>>Так вот, спешу вас разочаровать, он и к fs обращается, и все вышеперечисленное делает. И как я сказал, чуть снижается ресурсопотребление только за счет некоторого кеширования данных. DSD>>Что же касается хранения данных в своем формате и работы с ними, то тут быстродействие большей частью зависит от того, на каком языке вы программируете данное приложение. Ясен пень, что сервера БД пишутся чаще всего на чистом С или С++. R>Я представляю себе, как работает бд, в т.ч. и MySQL.
Сомневаюсь, судя по Вашим постам.
R>Тем не менее на собственном опыте почувствовал, что она быстрее (во всяком случае для моих задач), чем файловая система. R>Примечание: мои задачи =))) это в основном как раз цмс, форум, в общем поддержка сайта.
Странно, мои подобные задачи стали работать гораздо быстрее, когда я их переписал с варианта на MySQL на вариант с использованием файловой системы и кеша.
Вам не кажется это странным: моя файловая система работает быстрее, чем MySQL, который, в свою очередь, работает быстрее, чем Ваша файловая система?
И еще. Вы действительно почувствовали, что БД работает быстрее, чем FS на своем опыте? То есть Вы пробовали и так, и так, да?
Я к чему это спросил: редко кто делает все на FS, а потом переходит на БД. Большинство сразу пишут на БД, а о FS-вариантах судят только по тому, что слышали от других. Поэтому хочу убедиться, что Вы не один из них и не голословно утверждаете сей факт.
Еще я знаю, что большинство веб-программистов(или веб-мастеров, как их правильнее назвать) на файловой системе данные хранят двумя способами: либо одна запись = один файл, либо в одном файле, но в текстовом, немного похожем на структуру ini-файла. То есть делают удобно для чтения человека, а не машины. И после этого становится понятным, откуда тормоза.
Я же говорю о нормальном бинарном хранилище данных. Записи отдельно, индексы для них отдельно. Хотя бы в таком простом варианте.
Вот именно так в вебе редко кто пишет(типа сложно и неудобно). А стоило бы...
Ведь не функции чтения с диска тормозят. Не их мы сравниваем(кстати, MySQL, как и другие сервера БД, тоже хранит данные на диске).
Здравствуйте, DSD, Вы писали:
DSD>Здравствуйте, Rumata, Вы писали:
R>>Здравствуйте, DSD, Вы писали:
R>>>>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать.
О чём спор ?
Файловая система предназначена для хранения файлов, именно поэтому ей и пользуются для хранения файлов. БД предназначены для хранения данных и в БД хранить данные эффективнее чем в файловой системе, а в файловой системе эффективнее хранить именно файлы.
Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией.
З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными.
Здравствуйте, Andir, Вы писали:
A>О чём спор ? A>Файловая система предназначена для хранения файлов, именно поэтому ей и пользуются для хранения файлов. БД предназначены для хранения данных и в БД хранить данные эффективнее чем в файловой системе, а в файловой системе эффективнее хранить именно файлы. A>Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией.
Кстати, это правда, что в Windows Longhorn файловая система будет на базе данных сделана (где-то слышал )?
Здравствуйте, DSD, Вы писали:
DSD>И еще. Вы действительно почувствовали, что БД работает быстрее, чем FS на своем опыте? То есть Вы пробовали и так, и так, да? DSD>Я к чему это спросил: редко кто делает все на FS, а потом переходит на БД. Большинство сразу пишут на БД, а о FS-вариантах судят только по тому, что слышали от других. Поэтому хочу убедиться, что Вы не один из них и не голословно утверждаете сей факт.
Привожу простой пример, показывающий несостоятелность ФС-варианта:
Допустим у нас 1 запись на 1 файл. Допустим они (данные) хранятся в определенном формате. Допустим надо вывести название, скажем, каждого продукта, который хранится в файле.
Вопрос: насколько быстрее будет выбрать данные из базы нежели открывать каждый файл и выцарапывать оттуда название ?
И таких вариантов — вагон и маленькая тележка.
Вариант с написанием собственного хранилища данных не рассматриваем — ибо это будет написание своей базы, что противоречит начальным условиям задачи.
Я, по первости, тоже думал, что база это нифига не рулез, что надо все на файлах делать. В результате поимел такого гемороя — мама дорогая. Никому не советую. Даже убогий (в плане функциональности) MySQL на порядки выше по удобству работы перед файловой системой.
Здравствуйте, DSD, Вы писали:
ЖуК>>Во-вторых, удобство данной функции как раз и заключается в том что она бестрее чем какая либо другая функция/конструкция вычитает файл в строку. DSD>Речь немного не о том, как вычитать файл в строку, а о том, как вообще быстрее работать с файловой системой.
Нет! Речь как раз о том как быстрее вычитать файл. Я предлагал эту функцию именно для этой цели.
DSD>С Вами бесполезно спорить о производительности, пока Вы не будете себе четко представлять разницу между fread и fgets(в частности как они работают внутри, а не только разницу в синтаксисе вызова), между работой с файлами в текстовом и бинарном режимах, пока вы не будете считать память, занимаемую каждой Вашей переменной в программе/скрипте, а так же память и ресурсы, занимаемые разными системными и библиотечными функциями в процессе их работы.
Я уже начал замечать, что все думают о себе выше чем о других. Ну да бог с ним, я не гордый.
DSD>Этот код работает быстрее всех вышеприведенных:
Даже и не хочется проверять. Но вот работает ли он быстрее file_get_contents() я все-таки проверил. DSD, неужели так трудно понять, что всторенные функции работают быстрее, чем самописные??? Смотри сам — http://scripts.kiev.ua/site/examples/test.php. Именно по-этому я и предлагал использовать file_get_contents()
ЖуК>>Если говорить о ПХП то его функции работы с файлами все универсальны в том плане, что могут абсолютно нормально принимать URL как аргумент. И это логично — это ВЕБ программирование. Так что твои доводы пе этому поводу весьма ЖуК>>неубедительны. DSD>Вот по теме данной ветки как раз лишнюю часть, отвечающую за работу с URL, лучше бы из этих функций выкинуть.
А это уже не в наших силах. Напишите свой ПХП.
ЖуК>>Вопрос скорости. Любой ПХП код исполняется медленее, чем нативный. Поэтому логичнее с точки зрения быстродействия использовать встроенную функцию, а не писать такую же свою. Поэтому, если надо вычитать весь контент файла в строку file_get_contents — самый быстрый и удобный способ это сделать.
ЖуК>>В чем я неправ? DSD>Неправы Вы в том, что если нужно вычитать не весь файл, а только его часть, Вы будете применять file_get_contents, вычитывая его в память, а потом делать всякие substr и т.п. С чего я взял, что Вы будете делать именно так? Да вот с этого: http://www.rsdn.ru/Forum/?mid=272955
Вычитывать весь файл, чтобы узнать только его размер — крайне нецелесообразно.
И по поводу этой ветки. Во-первых, я предложил первое, что пришло в голову. Во-вторых, вопрос заключался в том, чтобы вычитаь размер файла, который находился по какому-то URL. filesize() не принимает параметр, который является URL.
Решение с заголовками, конечно же, более оптимальный вариант в данном случае. Но что касается того, как быстрее ВЫЧИТАТЬ ФАЙЛ В СТРОКУ — file_get_contents — самый быстрый способ.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Andir, Вы писали:
A>>О чём спор ? A>>Файловая система предназначена для хранения файлов, именно поэтому ей и пользуются для хранения файлов. БД предназначены для хранения данных и в БД хранить данные эффективнее чем в файловой системе, а в файловой системе эффективнее хранить именно файлы. A>>Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией.
WF>Кстати, это правда, что в Windows Longhorn файловая система будет на базе данных сделана (где-то слышал )?
Здравствуйте, DSD, Вы писали:
R>>Я представляю себе, как работает бд, в т.ч. и MySQL. DSD>Сомневаюсь, судя по Вашим постам.
Очень жаль. Ничем не могу помочь.
R>>Тем не менее на собственном опыте почувствовал, что она быстрее (во всяком случае для моих задач), чем файловая система. R>>Примечание: мои задачи =))) это в основном как раз цмс, форум, в общем поддержка сайта. DSD>Странно, мои подобные задачи стали работать гораздо быстрее, когда я их переписал с варианта на MySQL на вариант с использованием файловой системы и кеша.
Возможно Вы неудачно проектироали структуру бд.
DSD>Вам не кажется это странным: моя файловая система работает быстрее, чем MySQL, который, в свою очередь, работает быстрее, чем Ваша файловая система?
Кажется.
DSD>И еще. Вы действительно почувствовали, что БД работает быстрее, чем FS на своем опыте? То есть Вы пробовали и так, и так, да?
Да. Быстрее настолько, что при работе через фс пхп иногда вылетал по таймауту. Такая уж задача была.
DSD>Я к чему это спросил: редко кто делает все на FS, а потом переходит на БД. Большинство сразу пишут на БД, а о FS-вариантах судят только по тому, что слышали от других. Поэтому хочу убедиться, что Вы не один из них и не голословно утверждаете сей факт.
К моему несчастью мне далеко не сразу удалось попасть на хостинг с поддержкой бд, поэтому, например, я поначалу долго общался с такой штукой, как ubb, а потом перешел на vbb. Уж поверьте, на основе этих двух форумов я могу сравнить фс и бд.
DSD>Еще я знаю, что большинство веб-программистов(или веб-мастеров, как их правильнее назвать) на файловой системе данные хранят двумя способами: либо одна запись = один файл, либо в одном файле, но в текстовом, немного похожем на структуру ini-файла. То есть делают удобно для чтения человека, а не машины. И после этого становится понятным, откуда тормоза. DSD>Я же говорю о нормальном бинарном хранилище данных. Записи отдельно, индексы для них отдельно. Хотя бы в таком простом варианте.
К сожалению, не понял, Вашу мысль. Не могли бы Вы привести пример вида: в файле a.txt храним то, то и то в формате таком, в файле b.txt ...
DSD>Ведь не функции чтения с диска тормозят. Не их мы сравниваем(кстати, MySQL, как и другие сервера БД, тоже хранит данные на диске).
Повторяю еще раз: я в курсе, где хранит данные mysql.
btw честно говоря, я потерял нить, а что мы сравниваем?
Здравствуйте, ЖуК, Вы писали:
DSD>>Речь немного не о том, как вычитать файл в строку, а о том, как вообще быстрее работать с файловой системой. ЖуК>Нет! Речь как раз о том как быстрее вычитать файл. Я предлагал эту функцию именно для этой цели.
В данной ветке речь как раз о скорости работы с FS.
DSD>>С Вами бесполезно спорить о производительности, пока Вы не будете себе четко представлять разницу между fread и fgets(в частности как они работают внутри, а не только разницу в синтаксисе вызова), между работой с файлами в текстовом и бинарном режимах, пока вы не будете считать память, занимаемую каждой Вашей переменной в программе/скрипте, а так же память и ресурсы, занимаемые разными системными и библиотечными функциями в процессе их работы.
ЖуК>Я уже начал замечать, что все думают о себе выше чем о других. Ну да бог с ним, я не гордый.
Не о себе, а об осведомленности многих "других". О том, что не мешало бы знать, что делают разные, как им кажется, "системные" функции, прежде, чем писать, что быстрее, а что нет....
ЖуК>Даже и не хочется проверять. Но вот работает ли он быстрее file_get_contents() я все-таки проверил. DSD, неужели так трудно понять, что всторенные функции работают быстрее, чем самописные??? Смотри сам — http://scripts.kiev.ua/site/examples/test.php. Именно по-этому я и предлагал использовать file_get_contents()
Когда ты напишешь приложение, работающее с файлом, как с БД, ты поймешь, в чем разница...
И когда ты просто по возвращаемым заголовкам будешь определять размер, ты тоже поймешь, что это быстрее, чем прочитать весь файл...
DSD>>Вот по теме данной ветки как раз лишнюю часть, отвечающую за работу с URL, лучше бы из этих функций выкинуть. ЖуК>А это уже не в наших силах. Напишите свой ПХП.
Вот я на чистом Си и написал. И доволен. Сможете ли Вы так?
ЖуК>И по поводу этой ветки. Во-первых, я предложил первое, что пришло в голову.
Вот и плохо.
ЖуК>Во-вторых, вопрос заключался в том, чтобы вычитаь размер файла, который находился по какому-то URL. filesize() не принимает параметр, который является URL.
Как раз принимает. Но это абсолютно неудачный пример.
ЖуК>Даже и не хочется проверять. Но вот работает ли он быстрее file_get_contents() я все-таки проверил. DSD, неужели так трудно понять, что всторенные функции работают быстрее, чем самописные??? Смотри сам — http://scripts.kiev.ua/site/examples/test.php. Именно по-этому я и предлагал использовать file_get_contents()
Я говорил не о file_get_contents, а о всех "своих" функциях, которые Вы приводили в предыдущем посте.
И еще, Вы постите эту функцию(file_get_contents), совершенно не понимая, как она внутри работает. Единственное, чем Вы аргументируете, это то, что она "системная, и потому быстрее". То есть Вы можете выиграть спор только в тех случаях, где действительно это играет роль. В остальных случаях Вы даже обьяснить не сможете, почему быстрее работает тот или иной код.
Здравствуйте, DSD, Вы писали:
DSD>И еще, Вы постите эту функцию(file_get_contents), совершенно не понимая, как она внутри работает. Единственное, чем Вы аргументируете, это то, что она "системная, и потому быстрее". То есть Вы можете выиграть спор только в тех случаях, где действительно это играет роль. В остальных случаях Вы даже обьяснить не сможете, почему быстрее работает тот или иной код.
Товарищ DSD сомневаться в профессиональных качествах кого-либо на данном форуме запрещено правилами!!!
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, DSD, Вы писали:
DSD>>Здравствуйте, Rumata, Вы писали:
R>>>Здравствуйте, DSD, Вы писали:
R>>>>>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать.
A>О чём спор ? A>Файловая система предназначена для хранения файлов, именно поэтому ей и пользуются для хранения файлов. БД предназначены для хранения данных и в БД хранить данные эффективнее чем в файловой системе, а в файловой системе эффективнее хранить именно файлы. A>Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией.
А БД разве хранит данные не в файловой системе?
A>З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными.
Во-первых, что такое Yukon? Во-вторых, не в файловой системе ли он хранит свои данные?
Здравствуйте, DSD, Вы писали:
A>>Файловая система предназначена для хранения файлов, именно поэтому ей и пользуются для хранения файлов. БД предназначены для хранения данных и в БД хранить данные эффективнее чем в файловой системе, а в файловой системе эффективнее хранить именно файлы. A>>Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией. DSD>А БД разве хранит данные не в файловой системе?
Какая разница где она их хранит, хоть в оперативной памяти, здесь важна сама организация данных, я могу выбирать как представлять те или иные данные. Выделять в сущностях их атрибуты и использовать их. Файловая система не предназначена для хранения данных.
Очевидно, что на выборку 10000 (цифра взята с потолка) сущностей из базы данных и файловой системы и их обработку, времени будет тратится будет больше на файловой системе (парсинг строковых(бинарных и др.) данных хранящихся в файлах, читать один файл БД или 10000 файловой системы и т.д.). Организовать эффективное хранилище данных на файловой системе используя только собственно сами файлы вообще нельзя, минимально нужно будет особым образом размечать данные в файлах — а это уже прототип базы данных.
A>>З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными. DSD>Во-первых, что такое Yukon? Во-вторых, не в файловой системе ли он хранит свои данные? Сюда. У него своя файловая система, заточенная для хранения реляционных данных (на самом деле это даже файловой системой в обычном понимании не является).
www.fag.pisem.net/parser.rar — там две вродебы самы последние версии, все без комментов. Строится простенькая объектная модель. Первая версия сначала читает урл в строку, потом парсит. Вторая пытается это делать по мере чтения. В любом случае модель выходит тока после полного распарсивания. Все таки медленоват стервец получился. А так, вроде багов незамечено. Жду отзывов.
ЖуК>Но что касается того, как быстрее ВЫЧИТАТЬ ФАЙЛ В СТРОКУ — file_get_contents — самый быстрый способ.
Попробовал я твой пример — быстрее fopen — 15 сек., get_contents — 17 сек.
Здравствуйте, Andir, Вы писали:
DSD>>А БД разве хранит данные не в файловой системе?
A>Какая разница где она их хранит, хоть в оперативной памяти, здесь важна сама организация данных, я могу выбирать как представлять те или иные данные. Выделять в сущностях их атрибуты и использовать их. Файловая система не предназначена для хранения данных. A>Очевидно, что на выборку 10000 (цифра взята с потолка) сущностей из базы данных и файловой системы и их обработку, времени будет тратится будет больше на файловой системе (парсинг строковых(бинарных и др.) данных хранящихся в файлах, читать один файл БД или 10000 файловой системы и т.д.). Организовать эффективное хранилище данных на файловой системе используя только собственно сами файлы вообще нельзя, минимально нужно будет особым образом размечать данные в файлах — а это уже прототип базы данных.
Стоп, стоп, стоп! Здесь Вы прицепились уже к самим терминам и конкретике. Речь шла не о разнице между БД и файловой системой как таковой. А шла речь об использовании либо СУБД(читай сторонний сервер БД) либо своего хранилища данных в файле/файлах, т.е. о директивном доступе к БД. А еще точнее, речь шла о скорости доступа к данным в этих двух способах. По крайней мере, я именно это имел ввиду.
Конечно, система клиент-сервер(как в случае с сервером БД) имеет ряд своих преимуществ, как-то: поддержание целостности данных при доступе многих пользователей одновременно, использование прав и ролей для разных пользователей и т.п. Но что касаемо скорости работы сервера БД — он в любом случае, по крайней мере в теории, проигрывает директивному доступу к данным. К примеру, если выдрать из того же MySQL алгоритмы доступа к данным и прикрутить их в свою программу директивно, то скорость работы существенно повысится.
Что же касается мультипользовательского(мультипроцессового) доступа к данным в директивном режиме, то это обычно тоже решаемо.
A>>>З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными. DSD>>Во-первых, что такое Yukon? Во-вторых, не в файловой системе ли он хранит свои данные? A>Сюда. У него своя файловая система, заточенная для хранения реляционных данных (на самом деле это даже файловой системой в обычном понимании не является).
Это тоже не столь важно. К примеру, в InterBase тоже есть своя файловая система для своих же данных. И физически она обычно располагается в обычном файле базы данных.
Я говорил о том, сколько ресурсов обычно тратится на обеспечение режима клиент-сервер со всеми его правилами, правами доступа и т.п., а не о ресурсах, необходимых на саму выборку данных.
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, DSD, Вы писали:
DSD>>И еще, Вы постите эту функцию(file_get_contents), совершенно не понимая, как она внутри работает. Единственное, чем Вы аргументируете, это то, что она "системная, и потому быстрее". То есть Вы можете выиграть спор только в тех случаях, где действительно это играет роль. В остальных случаях Вы даже обьяснить не сможете, почему быстрее работает тот или иной код.
A>Товарищ DSD сомневаться в профессиональных качествах кого-либо на данном форуме запрещено правилами!!!
А я и не сомневаюсь. Я говорю только очевидное.
И обижать я никого не собираюсь. Всего-лишь пытаюсь указать, в какую сторону, по моему мнению, человеку стоит обратить свое внимание.
В свое время я писал на перле приложение, с которым предполагалась одновременная работа нескольких сотен пользователей.
И когда у меня начал тихо виснуть сервер при около 70 онлайн-юзерах, вот тогда-то я и начал задумываться о том, что неплохо
бы узнать, что внутри делает та или иная системная функция. А до этого случая, при разработке слабонагруженных скриптов, мне тоже было все равно, как работать с файлом, в текстовом или бинарном режиме. И тоже было все равно, какие функции использовать для определенного действия, если вставал выбор из двух и более способов это действие выполнить.
A>Уважайте своих оппонентов.
A>Удачи, Andir!
Здравствуйте, King Oleg, Вы писали:
KO>Здравствуйте, ЖуК, Вы писали:
ЖуК>>Но что касается того, как быстрее ВЫЧИТАТЬ ФАЙЛ В СТРОКУ — file_get_contents — самый быстрый способ. KO>Попробовал я твой пример — быстрее fopen — 15 сек., get_contents — 17 сек.
У меня др данные — fopen() от 12 до 15, file_get_contents() — от 11 до 13; Разница минимум 2 сек.
Здравствуйте, ЖуК, Вы писали:
ЖуК>Здравствуйте, King Oleg, Вы писали:
KO>>Здравствуйте, ЖуК, Вы писали:
ЖуК>>>Но что касается того, как быстрее ВЫЧИТАТЬ ФАЙЛ В СТРОКУ — file_get_contents — самый быстрый способ. KO>>Попробовал я твой пример — быстрее fopen — 15 сек., get_contents — 17 сек.
ЖуК>У меня др данные — fopen() от 12 до 15, file_get_contents() — от 11 до 13; Разница минимум 2 сек.
Возможно это зависит от размера читаемого файла. Того самого, который txt-шник...
Вы бы их сравнили, у кого какой размерчик...
Сдается мне, что file_get_contents() будет выигрывать только на мелких файлах.
Здравствуйте, DSD, Вы писали:
A>>>>З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными. DSD>>>Во-первых, что такое Yukon? Во-вторых, не в файловой системе ли он хранит свои данные? A>>Сюда. У него своя файловая система, заточенная для хранения реляционных данных (на самом деле это даже файловой системой в обычном понимании не является). DSD>Это тоже не столь важно. К примеру, в InterBase тоже есть своя файловая система для своих же данных. И физически она обычно располагается в обычном файле базы данных.
Так вот в Yukon своя физическая файловая система называется WinFS и вполне может быть, что следующая операционка майкрософта будет построена на этой системе.
DSD>Я говорил о том, сколько ресурсов обычно тратится на обеспечение режима клиент-сервер со всеми его правилами, правами доступа и т.п., а не о ресурсах, необходимых на саму выборку данных.
Ресурсы тратятся не один к одному на пользователя, а один ко многим пользователям, поэтому некорректное сравнение.
Хватит спорить. Мы с Михаилом тестили один и тот же файл через один и тот же скрипт, но получили прямо-противоположные результаты. Причем разница в скорости < 10% . Вывод — что хотите — то и юзайте. Явного выиграша не дает ни один из методов.
Здравствуйте, Andir, Вы писали:
A>>>Сюда. У него своя файловая система, заточенная для хранения реляционных данных (на самом деле это даже файловой системой в обычном понимании не является). DSD>>Это тоже не столь важно. К примеру, в InterBase тоже есть своя файловая система для своих же данных. И физически она обычно располагается в обычном файле базы данных.
A>Так вот в Yukon своя физическая файловая система называется WinFS и вполне может быть, что следующая операционка майкрософта будет построена на этой системе.
Ну и что из этого должно следовать? Ровным счетом ничего, пока не пощупаем. Да и при чем здесь вообще эта файловая система? Что Вы этим хотели сказать? Или просто, рекламируете?...
DSD>>Я говорил о том, сколько ресурсов обычно тратится на обеспечение режима клиент-сервер со всеми его правилами, правами доступа и т.п., а не о ресурсах, необходимых на саму выборку данных. A>Ресурсы тратятся не один к одному на пользователя, а один ко многим пользователям, поэтому некорректное сравнение.
Здесь тоже мне не совсем понятен смысл довода... Кроме расшаренного кеша(ну и ядра, которое как правило не клиентов обслуживает) ничто не работает, как один ко многим. Практически все остальные функции сервера БД работают один к одному. Для каждого подключенного пользователя обеспечивается поддержка соединения, трансфер данных туда-обратно, парсинг SQL-запросов и выборка результатов. Ну и еще куча мелочей. Даже если все это выполняет один процесс(и даже если один поток), то это совсем не значит один ко многим.
Что же касается той части с расшаренными данными, так это можно сделать(и делают) и без клиент-сервера. Так что непонятно, почему это вдруг сравнение некорректное...
Здравствуйте, DSD, Вы писали:
DSD>Здравствуйте, Andir, Вы писали:
A>>>>Сюда. У него своя файловая система, заточенная для хранения реляционных данных (на самом деле это даже файловой системой в обычном понимании не является). DSD>>>Это тоже не столь важно. К примеру, в InterBase тоже есть своя файловая система для своих же данных. И физически она обычно располагается в обычном файле базы данных. A>>Так вот в Yukon своя физическая файловая система называется WinFS и вполне может быть, что следующая операционка майкрософта будет построена на этой системе. DSD>Ну и что из этого должно следовать? Ровным счетом ничего, пока не пощупаем. Да и при чем здесь вообще эта файловая система? Что Вы этим хотели сказать? Или просто, рекламируете?...
Контекст соизвольте припомнить. У Юкона своя файловая система, заточенная под хранение реляционных данных и поэтому скорость чтения данных с файла в обычной файловой системе и когда данные читаются Юконом вообще несопоставимы. В самом начале я упомянул, что ваши аргументы про то что данные БД хранятся в файлах и поэтому скорость работы с файлом намного больше чем с базой данных, так вот Юкон этот ваш аргумент делает бессмысленным, на что я в самом начале дискуссии и обратил внимание.
DSD>>>Я говорил о том, сколько ресурсов обычно тратится на обеспечение режима клиент-сервер со всеми его правилами, правами доступа и т.п., а не о ресурсах, необходимых на саму выборку данных. A>>Ресурсы тратятся не один к одному на пользователя, а один ко многим пользователям, поэтому некорректное сравнение. DSD>Здесь тоже мне не совсем понятен смысл довода... Кроме расшаренного кеша(ну и ядра, которое как правило не клиентов обслуживает) ничто не работает, как один ко многим. Практически все остальные функции сервера БД работают один к одному.
Это не было доводом, я просто указал на небольшую некорректность высказывания. Про ресурсы — вспоминаем про существование пулов соединений, пулов потоков, кэша данных, кэширования на всех уровнях, прекомпилирования запросов и т.д. Мало того все современные провайдеры данных, обеспечивают кэши ещё более высокого уровня ... Назовите хотя бы один ресурс сервера БД, который нельзя оптимизировать на работу с несколькими пользователями.
DSD>Для каждого подключенного пользователя обеспечивается поддержка соединения, трансфер данных туда-обратно, парсинг SQL-запросов и выборка результатов. Ну и еще куча мелочей. Даже если все это выполняет один процесс(и даже если один поток), то это совсем не значит один ко многим.
Что значит поддержка соединения ?
Трансфер данных не такая дорогостоящая операция, если идёт на локальном компьютере.
Парсинг запросов ... Простые запросы парсятся на фоне обращения к БД просто мгновенно. Сложные запросы ... Прекомпилируются, парсятся и т.д. + обработка = со скоростью заметно большей чем парсинг любого файлового ресурса с такой же целью как и в запросе.
Ни одна из названных вами обеспечиваемых возможностей не является ресурсом сервера БД.
DSD>Что же касается той части с расшаренными данными, так это можно сделать(и делают) и без клиент-сервера. Так что непонятно, почему это вдруг сравнение некорректное...
Ваше утверждение гласило, что работать с файлом быстрее чем с данными БД, так если обеспечивать все возможности современной БД для работы с одним файлом — это уже не реализация собственной СУБД ? И что же тогда будет быстрее ?
Смотрим на фразу ниже. DSD>сколько ресурсов обычно тратится на обеспечение режима клиент-сервер со всеми его правилами, правами доступа и т.п.
Так сколько ресурсов тратится на обеспечение режима клиент-сервер для миллиона пользователей ? Всё ещё непонятно, где некорректное высказывание ?
Здравствуйте, DSD, Вы писали:
DSD>Стоп, стоп, стоп! Здесь Вы прицепились уже к самим терминам и конкретике. Речь шла не о разнице между БД и файловой системой как таковой. А шла речь об использовании либо СУБД(читай сторонний сервер БД) либо своего хранилища данных в файле/файлах, т.е. о директивном доступе к БД. А еще точнее, речь шла о скорости доступа к данным в этих двух способах. По крайней мере, я именно это имел ввиду.
Так Вы можете привести конкретный пример, когда Вы получили выйгрышь в скорости при использовании фс (и как именно это удалось?) по сравнению с бд (какой бд?).
DSD>Конечно, система клиент-сервер(как в случае с сервером БД) имеет ряд своих преимуществ, как-то: поддержание целостности данных при доступе многих пользователей одновременно, использование прав и ролей для разных пользователей и т.п. Но что касаемо скорости работы сервера БД — он в любом случае, по крайней мере в теории, проигрывает директивному доступу к данным. К примеру, если выдрать из того же MySQL алгоритмы доступа к данным и прикрутить их в свою программу директивно, то скорость работы существенно повысится.
Нет. Вы не можете обойтись без сохранения целостности, блокировки, транзакций и т.д. Так или иначе, Вам прийдется решать эти проблемы => Вы просто построите другую реляционную БД. Простите, но я не верю, что Вам в одиночку, в сжатые сроки, удастся сделать что-то, что будет работать лучше, чем 4-ая версия того же MySQL.
Здравствуйте, Rumata, Вы писали:
R>Так Вы можете привести конкретный пример, когда Вы получили выйгрышь в скорости при использовании фс (и как именно это удалось?) по сравнению с бд (какой бд?).
Да, могу. К примеру http://911.ru
Раньше там использовался MySQL. Теперь нет.
Данные пользователей хранятся в файлах. При подключении очередного юзера его данные засасываются в shared memory сегмент(вот вам и кеш, такой же, как у сервера БД). Этот сегмент сам по себе отформатирован как примитивная FS с некоторой индексацией. Используются так же очереди сообщений(SystemV), местами, где необходимо, семафоры. Иногда сокеты(там где затраты на их создание/поддержку оправданы). Дальше описывать не буду. Скажу лишь, что на одной и той же тачке при использовании MySQL удавалось держать около 70 человек одновременно(на этом процессор работал на полную катушку), а без него — около 700 с большим запасом мощности.
DSD>>Конечно, система клиент-сервер(как в случае с сервером БД) имеет ряд своих преимуществ, как-то: поддержание целостности данных при доступе многих пользователей одновременно, использование прав и ролей для разных пользователей и т.п. Но что касаемо скорости работы сервера БД — он в любом случае, по крайней мере в теории, проигрывает директивному доступу к данным. К примеру, если выдрать из того же MySQL алгоритмы доступа к данным и прикрутить их в свою программу директивно, то скорость работы существенно повысится. R>Нет. Вы не можете обойтись без сохранения целостности, блокировки, транзакций и т.д. Так или иначе, Вам прийдется решать эти проблемы => Вы просто построите другую реляционную БД.
Но ведь это уже будет другая БД, не так ли?
Я говорил не против БД вообще, а о том, что использование стандартного сервера БД может вылезти боком во многих местах именно из-за его универсальности. Я против того, чтобы использовать сервера БД там, где в этом нет необходимости.
А все вопросы с целостностью данных вполне решабельны и без использования сервера БД.
R>Простите, но я не верю, что Вам в одиночку, в сжатые сроки, удастся сделать что-то, что будет работать лучше, чем 4-ая версия того же MySQL.
Насчет сжатости сроков — это уже совсем другой вопрос, и обсуждать его нужно не здесь.
4я версия MySQL тоже далеко не подарок. У нас на одном старом проекте он тоже жрет проц при не сложных и не очень частых запросах. Причину данного глюка еще не выявили, но запросы свои несколько раз перепроверили — они действительно простые и не частые.
Как раз подумываем о том, чтобы и в этом проекте отказаться от MySQL.
Здравствуйте, Andir, Вы писали:
DSD>>Ну и что из этого должно следовать? Ровным счетом ничего, пока не пощупаем. Да и при чем здесь вообще эта файловая система? Что Вы этим хотели сказать? Или просто, рекламируете?...
A>Контекст соизвольте припомнить. У Юкона своя файловая система, заточенная под хранение реляционных данных и поэтому скорость чтения данных с файла в обычной файловой системе и когда данные читаются Юконом вообще несопоставимы.
Вопрос-подвох: Несопоставимы в какую сторону?
А что понимать под "обычной" FS?
FAT16/32, WinNT, файловые системы разных Юникс-клонов — они тоже в большинстве своем разные. Yukon — новый, более сложный, вид. Может он и окажется производительнее(кстати вопрос спорный, у Microsoft постоянно увеличение производительности ОС-ей связано так же и с увеличением производительности компа в целом), да и то смотря в чем, ну и что?
A>В самом начале я упомянул, что ваши аргументы про то что данные БД хранятся в файлах и поэтому скорость работы с файлом намного больше чем с базой данных, так вот Юкон этот ваш аргумент делает бессмысленным, на что я в самом начале дискуссии и обратил внимание.
Вот насчет "поэтому"(выделено жирным) Вы мне зубы не заговаривайте. Я этого не говорил. И если Вы так поняли, то поняли неправильно.
И не с "базой данных"(тоже выделено жирным), а с сервером БД! "БД" и "сервер БД" — это разные вещи.
A>>>Ресурсы тратятся не один к одному на пользователя, а один ко многим пользователям, поэтому некорректное сравнение. DSD>>Здесь тоже мне не совсем понятен смысл довода... Кроме расшаренного кеша(ну и ядра, которое как правило не клиентов обслуживает) ничто не работает, как один ко многим. Практически все остальные функции сервера БД работают один к одному. A>Это не было доводом, я просто указал на небольшую некорректность высказывания. Про ресурсы — вспоминаем про существование пулов соединений, пулов потоков, кэша данных, кэширования на всех уровнях, прекомпилирования запросов и т.д. Мало того все современные провайдеры данных, обеспечивают кэши ещё более высокого уровня ... Назовите хотя бы один ресурс сервера БД, который нельзя оптимизировать на работу с несколькими пользователями.
Назовите мне хоть одно из вышеперечисленного, что нельзя так же соптимизировать без использования сервера БД.
DSD>>Для каждого подключенного пользователя обеспечивается поддержка соединения, трансфер данных туда-обратно, парсинг SQL-запросов и выборка результатов. Ну и еще куча мелочей. Даже если все это выполняет один процесс(и даже если один поток), то это совсем не значит один ко многим.
A>Что значит поддержка соединения ?
Открытие socket'а и трансфер данных по нему тоже кушает ресурсы ядра, представьте себе, при чем больше, чем открытый файл и тем более, чем подключение к сегменту shared memory. Вы этого не знали?
Плюс ко всему практически в любой системе существует ограничение на количество одновременно открытых сокетов(как, в прочем и файловых дескрипторов, но с вариантом с shared memory это можно не брать в расчет), и в случае, когда эта машина является еще и веб-сервером с приличной входящей нагрузкой, это имеет тоже важную роль.
A>Трансфер данных не такая дорогостоящая операция, если идёт на локальном компьютере.
Нагрузка ядра(см. выше). Единичный сокет и единичная операция трансфера — не дорогостоящая, а вот когда их много...
A>Парсинг запросов ... Простые запросы парсятся на фоне обращения к БД просто мгновенно. Сложные запросы ... Прекомпилируются, парсятся и т.д. + обработка = со скоростью заметно большей чем парсинг любого файлового ресурса с такой же целью как и в запросе. A>Ни одна из названных вами обеспечиваемых возможностей не является ресурсом сервера БД.
Совершенно верно, это — ресурсы системы, которые сервер БД с успехом кушает за обе щЁки.
DSD>>Что же касается той части с расшаренными данными, так это можно сделать(и делают) и без клиент-сервера. Так что непонятно, почему это вдруг сравнение некорректное...
A>Ваше утверждение гласило, что работать с файлом быстрее чем с данными БД, так если обеспечивать все возможности современной БД для работы с одним файлом — это уже не реализация собственной СУБД ? И что же тогда будет быстрее ?
"Собственная СУБД". И знаете почему? Потому, что в ней все рассчитано для максимально эффективной работы с данным проектом, в "промышленном" сервере БД этого нет. В нем много лишнего за счет его универсальности и унифицированности.
Здесь "Собственная СУБД" — это набор функций и алгоритмов работы с данными именно для этого приложения. В другом приложении будут уже другие алгоритмы...
A>Смотрим на фразу ниже. DSD>>сколько ресурсов обычно тратится на обеспечение режима клиент-сервер со всеми его правилами, правами доступа и т.п. A>Так сколько ресурсов тратится на обеспечение режима клиент-сервер для миллиона пользователей ? Всё ещё непонятно, где некорректное высказывание ?
Не забывайте, что этот миллион пользователей в Вашем варианте цепляется к серверному приложению, которое в свою очередь цепляется к серверу БД, а это — двойная нагрузка.
Почему такая схема, а не напрямую к СУБД? Но мы ведь находимся в форуме "Веб-программирование" .
Простой пример: вам необходимо просто выдать количество подключенных пользователей на данный момент. Вы каждый раз будете делать "select count(*) from ... where ..."? Или проще все-таки это число хранить где-нибудь в shared memory или в том же файле. Оно займет там от 2-х до 4-х байт. А прочитать его гораздо проще и быстрее.
Здравствуйте, DSD, Вы писали:
DSD>А что понимать под "обычной" FS? DSD>FAT16/32, WinNT, файловые системы разных Юникс-клонов — они тоже в большинстве своем разные. Yukon — новый, более сложный, вид. Может он и окажется производительнее(кстати вопрос спорный, у Microsoft постоянно увеличение производительности ОС-ей связано так же и с увеличением производительности компа в целом), да и то смотря в чем, ну и что?
SQL server самая быстрая СУБД на сегодняшний день среди СУБД промышленного масштаба. И не нужно здесь упирать на имя Майкрософт.
Я надеюсь, что всё же объяснять почему система заточенная под хранение реляционных данных быстрее чем любая другая в том числе и файловая мне не придётся ? Иначе в Матчасть.
DSD>Вот насчет "поэтому"(выделено жирным) Вы мне зубы не заговаривайте. Я этого не говорил. И если Вы так поняли, то поняли неправильно. DSD>И не с "базой данных"(тоже выделено жирным), а с сервером БД! "БД" и "сервер БД" — это разные вещи.
Придирки к словам не принимаются. поэтому == один из аргументов, БД == Субд (== — это "имелось ввиду").
DSD>Назовите мне хоть одно из вышеперечисленного, что нельзя так же соптимизировать без использования сервера БД.
Ага и называться это будет всё сервером БД. Я сомневаюсь, что для средней крупности задачи можно сделать всё это эффективнее чем существующие СУБД. Для мелких задач — свою СУБД писать нерационально, но можно, но неоправданно в расходах времени и результатах.
A>>Что значит поддержка соединения ? DSD>Открытие socket'а и трансфер данных по нему тоже кушает ресурсы ядра, представьте себе, при чем больше, чем открытый файл и тем более, чем подключение к сегменту shared memory. Вы этого не знали?
А я-яй. Опять сомневаешься ...
Ты назвал это ресурсом СУБД, такого ресурса я действительно не знаю. Всё это с лихвой покрывает пул соединений ... И вообще это выглядит как именно обращение к частностям ... не нравится тебе соединение через сокеты, пиши свою библиотечку для общения с СУБД, благо почти все современные это дело поддерживают, да и написано давно и много.
DSD>Плюс ко всему практически в любой системе существует ограничение на количество одновременно открытых сокетов(как, в прочем и файловых дескрипторов, но с вариантом с shared memory это можно не брать в расчет), и в случае, когда эта машина является еще и веб-сервером с приличной входящей нагрузкой, это имеет тоже важную роль.
Частности. Для связи с СУБД не обязательно использовать сокеты.
A>>Ни одна из названных вами обеспечиваемых возможностей не является ресурсом сервера БД. DSD>Совершенно верно, это — ресурсы системы, которые сервер БД с успехом кушает за обе щЁки.
Это плохо ? Кто сказал, что всё это делается нерационально ...
A>>Ваше утверждение гласило, что работать с файлом быстрее чем с данными БД, так если обеспечивать все возможности современной БД для работы с одним файлом — это уже не реализация собственной СУБД ? И что же тогда будет быстрее ? DSD>"Собственная СУБД". И знаете почему? Потому, что в ней все рассчитано для максимально эффективной работы с данным проектом, в "промышленном" сервере БД этого нет. В нем много лишнего за счет его универсальности и унифицированности. DSD>Здесь "Собственная СУБД" — это набор функций и алгоритмов работы с данными именно для этого приложения. В другом приложении будут уже другие алгоритмы...
Для необходимости реализации СУБД нужны хорошие основания и достаточно крупный проект, иначе сам проект на фоне реализации СУБД просто теряется.
Набор функций и алгоритмов работы для обеспечения хотя возможностей мелкой СУБД ИМХО я просто не потяну.
DSD>Не забывайте, что этот миллион пользователей в Вашем варианте цепляется к серверному приложению, которое в свою очередь цепляется к серверу БД, а это — двойная нагрузка.
Есть такая идея, которая называется Multi-tier приложения, так вот она утверждает, что никакой двойной нагрузки и в помине не будет. СУБД хранит и обеспечивает целостность данных, слой данных обеспечивает доступ к данным, бизнес-слой обрабатывает данные, презентационный данные отображает.
DSD>Простой пример: вам необходимо просто выдать количество подключенных пользователей на данный момент. Вы каждый раз будете делать "select count(*) from ... where ..."? Или проще все-таки это число хранить где-нибудь в shared memory или в том же файле. Оно займет там от 2-х до 4-х байт. А прочитать его гораздо проще и быстрее.
Для таких случаев и нужен Менеджер данных, который простые и постоянно используемые данные хранит у себя и обеспечивает самый быстрый доступ к данным. Но вот в упор не могу понять смысла хранить эти данные в файле или в БД . Пример вообще говоря странный.
Здравствуйте, DSD, Вы писали:
R>>Так Вы можете привести конкретный пример, когда Вы получили выйгрышь в скорости при использовании фс (и как именно это удалось?) по сравнению с бд (какой бд?). DSD>Да, могу. К примеру http://911.ru DSD>Раньше там использовался MySQL. Теперь нет. DSD>Данные пользователей хранятся в файлах. При подключении очередного юзера его данные засасываются в shared memory сегмент(вот вам и кеш, такой же, как у сервера БД). Этот сегмент сам по себе отформатирован как примитивная FS с некоторой индексацией. Используются так же очереди сообщений(SystemV), местами, где необходимо, семафоры. Иногда сокеты(там где затраты на их создание/поддержку оправданы). Дальше описывать не буду. Скажу лишь, что на одной и той же тачке при использовании MySQL удавалось держать около 70 человек одновременно(на этом процессор работал на полную катушку), а без него — около 700 с большим запасом мощности.
Это действительно страно. Мне бы очень хотелось, как работает combats.ru — неужели MySQL+perl? Если так, то все Вааши доводы бледнеют =))
DSD>А все вопросы с целостностью данных вполне решабельны и без использования сервера БД.
Нда, однако, к примеру, тот запрос, который Вы привели в соседнем посте: DSD>select count(*) from ... where ...
весьма подозрителен — Вы его храните в памяти. Хорошо, а вдруг количество изменится? Прийдется ведь менять значение здесь? Не думаю, что прописывать соответсвующую фуекцию во всех местах, где потенциально возможно изменение этой величины — хорошая мысль. Соответственно, прийдется писать некий объект, который будет СУБД, поддерживающей нужную целостность.
Проблема ведь в чем, если Вам нужна скорость, то без сомнения, Вы сможете для своего проекта разработать способ представления и хранения данных, обеспечивающий эту самую максимальную скорость. Вот только прийдется, скорее всего, отказаться, например, от использования для построения запросов SQL. Кроме того, не будет сохранения уелостности на уровне СУБД, прийдется делать на логическом и т.д. В результате имхо не получится сделать масштабируемое, легко настраиваемое, дружелюбное со стороны программиста приложение.
Re[16]: По поводу производительности и целостности
Здравствуйте, Rumata, Вы писали:
R>Это действительно страно. Мне бы очень хотелось, как работает combats.ru — неужели MySQL+perl? Если так, то все Вааши доводы бледнеют =))
Я им послал запрос на эту тему. Надеюсь, ответят.
DSD>>А все вопросы с целостностью данных вполне решабельны и без использования сервера БД. R>Нда, однако, к примеру, тот запрос, который Вы привели в соседнем посте: DSD>>select count(*) from ... where ... R>весьма подозрителен — Вы его храните в памяти. Хорошо, а вдруг количество изменится? Прийдется ведь менять значение здесь? Не думаю, что прописывать соответсвующую фуекцию во всех местах, где потенциально возможно изменение этой величины — хорошая мысль. Соответственно, прийдется писать некий объект, который будет СУБД, поддерживающей нужную целостность.
А голова программисту зачем? Только чтобы запросики составлять? Ясен пень, когда надо и кем надо, оно меняется. И ясен пень, есть некий обьект в ядре продукта, который поддерживает необходимую целостность.
Для этого есть огромное количество возможностей IPC. А так же правил и постулатов их использования.
R>Проблема ведь в чем, если Вам нужна скорость, то без сомнения, Вы сможете для своего проекта разработать способ представления и хранения данных, обеспечивающий эту самую максимальную скорость. Вот только прийдется, скорее всего, отказаться, например, от использования для построения запросов SQL.
Ну и замечательно.
R>Кроме того, не будет сохранения уелостности на уровне СУБД, прийдется делать на логическом и т.д. В результате имхо не получится сделать масштабируемое, легко настраиваемое, дружелюбное со стороны программиста приложение.
Приложение должно в первую очередь дружить с машиной и пользователем, а не программистом.
Удобства себе программист лолжен обеспечить сам. Отдельно.
Иначе плодятся программеры, которые свои удобства предпочитают быстродействию системы. Результат — веб-сервера, нагруженные как минимум тридцатью процентами бесполезных с точки зрения приложения и конечного пользователя действий.
Здравствуйте, Andir, Вы писали:
A>SQL server самая быстрая СУБД на сегодняшний день среди СУБД промышленного масштаба. И не нужно здесь упирать на имя Майкрософт. A>Я надеюсь, что всё же объяснять почему система заточенная под хранение реляционных данных быстрее чем любая другая в том числе и файловая мне не придётся ? Иначе в Матчасть.
Да при чем здесь заточенная система? Если вы FS в контексте данной ветки рассматриваете, как одна запись=один файл, тогда да. Иначе — Вы просто не понимаете, о чем я Вам говорю.
Любая промышленная СУБД не дает прямого доступа к данным. На любую мелочь извольте дать SQL-запросик, а она уж вам даст ответик, занимаясь при этом всей необходимой кучей обработок запросика и формирования ответика.
DSD>>Вот насчет "поэтому"(выделено жирным) Вы мне зубы не заговаривайте. Я этого не говорил. И если Вы так поняли, то поняли неправильно. DSD>>И не с "базой данных"(тоже выделено жирным), а с сервером БД! "БД" и "сервер БД" — это разные вещи. A>Придирки к словам не принимаются. поэтому == один из аргументов, БД == Субд (== — это "имелось ввиду").
Это не к словам придирки. Сначала Вы упрощаете слова, а потом меняете и суть высказывания. Поэтому давайте оперировать правильными словами и терминами на протяжении всей дискуссии, иначе просто темы начинают плавать, и возникают ошибки в понимании друг друга.
DSD>>Назовите мне хоть одно из вышеперечисленного, что нельзя так же соптимизировать без использования сервера БД. A>Ага и называться это будет всё сервером БД. Я сомневаюсь, что для средней крупности задачи можно сделать всё это эффективнее чем существующие СУБД.
Еще как можно! Во многих случаях с точностью до наоборот Это я к тому, что чем больше база(здесь: таблица), тем тормознутее работают даже простые запросы. См. ниже примеры.
A>Для мелких задач — свою СУБД писать нерационально, но можно, но неоправданно в расходах времени и результатах.
A>>>Что значит поддержка соединения ? DSD>>Открытие socket'а и трансфер данных по нему тоже кушает ресурсы ядра, представьте себе, при чем больше, чем открытый файл и тем более, чем подключение к сегменту shared memory. Вы этого не знали? A>А я-яй. Опять сомневаешься ... A>Ты назвал это ресурсом СУБД, такого ресурса я действительно не знаю.
Здесь "ресурс" — имелись ввиду не "данные", а ресурсы машины, которые кушает именно СУБД.
A>Всё это с лихвой покрывает пул соединений ...
Да дался тебе этот пул. Что такое пул соединений? Чем 100 соединений в пуле отдичаются от 100 соединений не в пуле? Только тем, что в пуле они более удобно организованы, но это по-прежнему 100 соединений, в одно они от этого не сливаются.
Пулы потоков — тоже не панацея. Их давно применяют везде, где это удобно и оптимально(тот же Apache), и применять их можно как в СУБД, так и без нее.
Так что давайте забудем о неспецифичной оптимизации — она рулит в обоих случаях. Если и говорить, то об оптимизации, которая присутствует в одном варианте(с СУБД или без), и принципиально невозможна в другом.
A>И вообще это выглядит как именно обращение к частностям ... не нравится тебе соединение через сокеты, пиши свою библиотечку для общения с СУБД, благо почти все современные это дело поддерживают, да и написано давно и много. DSD>>Плюс ко всему практически в любой системе существует ограничение на количество одновременно открытых сокетов(как, в прочем и файловых дескрипторов, но с вариантом с shared memory это можно не брать в расчет), и в случае, когда эта машина является еще и веб-сервером с приличной входящей нагрузкой, это имеет тоже важную роль. A>Частности. Для связи с СУБД не обязательно использовать сокеты.
Сокеты — почти стандарт де-факто у промышленных СУБД. Даже если общаться с ней более рациональным путем, это соптимизирует только канал передачи данных. А ведь еще остается куча мест, где тоже не мешало бы упростить. Да, в общем-то, суть не в том, чтобы переделывать сервера БД. По мне — все там нормально. Суть в другом — не все нужно пихать в СУБД, а только необходимое.
A>>>Ни одна из названных вами обеспечиваемых возможностей не является ресурсом сервера БД. DSD>>Совершенно верно, это — ресурсы системы, которые сервер БД с успехом кушает за обе щЁки. A>Это плохо ? Кто сказал, что всё это делается нерационально ...
Рационально с точки зрения работы самой СУБД, но не конечного продукта(читай приложения).
A>>>Ваше утверждение гласило, что работать с файлом быстрее чем с данными БД, так если обеспечивать все возможности современной БД для работы с одним файлом — это уже не реализация собственной СУБД ? И что же тогда будет быстрее ? DSD>>"Собственная СУБД". И знаете почему? Потому, что в ней все рассчитано для максимально эффективной работы с данным проектом, в "промышленном" сервере БД этого нет. В нем много лишнего за счет его универсальности и унифицированности. DSD>>Здесь "Собственная СУБД" — это набор функций и алгоритмов работы с данными именно для этого приложения. В другом приложении будут уже другие алгоритмы...
A>Для необходимости реализации СУБД нужны хорошие основания и достаточно крупный проект, иначе сам проект на фоне реализации СУБД просто теряется.
Согласен. Я не говорю о простейших веб-скриптиках.
A>Набор функций и алгоритмов работы для обеспечения хотя бы возможностей мелкой СУБД ИМХО я просто не потяну.
Не обязательно писать мелкую СУБД. Можно просто продумать, что должно храниться в СУБД, а что — нет. Это кстати — вариант-компромисс.
DSD>>Не забывайте, что этот миллион пользователей в Вашем варианте цепляется к серверному приложению, которое в свою очередь цепляется к серверу БД, а это — двойная нагрузка. A>Есть такая идея, которая называется Multi-tier приложения, так вот она утверждает, что никакой двойной нагрузки и в помине не будет. СУБД хранит и обеспечивает целостность данных, слой данных обеспечивает доступ к данным, бизнес-слой обрабатывает данные, презентационный данные отображает.
Это я знаю.
Каждый из этих слоев, как правило, представляет данные в своем формате, максимально удобном и оптимальном для данного слоя. Поэтому существуют "прослойки", конвертирующие данные из одного формата в другой и трансферрящие их между этими слоями. Вот если избавиться от таких прослоек и максимально сблизить слои — работать будет намного быстрее. Но в промышленных СУБД от них избавиться невозможно принципиально, потому что потеряется универсальность сервера. А в практически каждом частном случае(в неуниверсальном варианте) это сделать было бы вполне можно и желательно. Вот тут-то собака и зарыта.
DSD>>Простой пример: вам необходимо просто выдать количество подключенных пользователей на данный момент. Вы каждый раз будете делать "select count(*) from ... where ..."? Или проще все-таки это число хранить где-нибудь в shared memory или в том же файле. Оно займет там от 2-х до 4-х байт. А прочитать его гораздо проще и быстрее. A>Для таких случаев и нужен Менеджер данных, который простые и постоянно используемые данные хранит у себя и обеспечивает самый быстрый доступ к данным. Но вот в упор не могу понять смысла хранить эти данные в файле или в БД . Пример вообще говоря странный.
Я тебе(ничего, что я на ты перешел? ) приведу другой, более сложный пример:
Представь себе чат. Обычный html-чат, коих в интернете немало. Базовый набор функций.
Как выглядят в сервере БД сообщения? Как правило — одной таблицей.
Чтобы выбрать и показать пользователю 20 последних, например в MySQL, делаем "select * from messages order by id(или time) last 20". И это MySQL поддерживает директиву last. Другие сервера могут и не иметь аналогов, и тогда приходится либо усложнять запрос, либо выгребать(fetch) только первые
20, установив order в desc. Можно, конечно, пойти и другим путем — завести отдельную таблицу для "активных" сообщений, и отдельную — для архива. Но большого выигрыша это не даст, т.к. породит почти такие же проблемы, связанные с перемещением устаревших сообщений в архив, или, как минимум, вставку нового сообщения в обе таблицы с удалением устаревших из таблицы активных.
В любом случае стоит глубже провести "разбор полетов":
вставка записи в таблицу: создание нового id, если есть такое автоинкрементное поле(а оно очевидно должно быть). Это поле скорее всего является первичным ключом, а значит, что нужно переписать индекс как минимум для этого поля.
удаление записи: тоже грабли с переиндексацией.
перемещение записей: выборка необходимых по условию, вставка в destination таблицу со всеми вытекающими, удаление из source таблицы со всеми вытекающими.
Так вот, на каждый показ сообщений проходит минимум запрос с сортировками, отбором нужных из результата и т.п. Можно извратиться и создать запрос, который даст именно 20 последних записей, но, как правило, если сервер не поддерживает директиву last или аналогичную, то это будет запрос из разряда "сложных", а это — нагрузка. В общем, это уже не так важно на фоне остальных проблем.
Я доступно изьясняюсь, опуская разжевывание очевидных тормозов?
То есть, ты можешь себе представить, чем занимается сервер, выгребая такой запрос? И ты можешь представить себе несколько пользователей, сидящих в чате одновременно, и браузер каждого из них с периодичностью скажем в 15 секунд шлет на сервер запрос на предмет последних 20-ти сообщений?
Думаю, представить себе можешь...
Теперь вариант "на FS". Опишу простенький, без оптимизаций и наворотов.
Создаем 2 файла. Один — тела сообщений, назовем его "blob-файл". Второй — "индекс-файл".
Индекс-файл состоит из заголовков фиксированной длины, скажем, 16 байт:
0-3 — unsigned long: id пользователя, отправившего сообщение(owner)
4-7 — char(4): что-нибудь еще, может, флаги сообщения, тип сообщения, другие данные...
8-11 — unsigned long: оффсет тела сообщения в blob-файле в байтах.
12-15 — unsigned long: длина сообщения в байтах.
За id самого сообщения можно взять его порядковый номер в файле — в данной задаче это вполне можно сделать.
Итак, выборка последних 20-ти сообщений:
Открываем индекс-файл.
Вычисляем по его размеру общее количество сообщений: размер_файла/16. К примеру, размер файла=1121968 байт, значит в нем 1121968/16=70123 сообщений.
Отнимаем 20 и получаем номер первого нужного нам сообщения: 70123-20=70103.
Вычисляем адрес первого нужного нам сообщения: 70103*16=1121648.
Передвигаем указатель данных файла на это место. В Си это к примеру функция lseek().
Читаем либо 20*16=320 байт, либо до конца файла — кому как нравится. Я бы выбрал первый вариант, как более безопасный(могли уже вставиться новые сообщения).
Закрываем файл.
Открываем blob-файл.
По адресам в прочитанных заголовках читаем тела сообщений.
Закрываем файл.
Вставка нового сообщения:
Открываем blob-файл.
Вычисляем и запоминаем его размер до записи.
Добавляем в конец файла тело сообщения(lseek()+write(), либо просто write(), если открыли на добавление в конец).
Закрываем файл.
Открываем индекс-файл.
Добавляем в конец файла заголовок сообщения, в котором указываем запомненный выше размер blob-файла до записи в качестве оффсета тела сообщения.
Закрываем файл.
Рассмотрим немного усовершенствованный вариант, в котором будем выгребать не последние 20 сообщений, а только новые, если они были.
Здесь(на форуме) уже когда-то обсуждался такой вариант, когда браузер помнит все сообщения и в запросах серверу пересылает только id последнего: http://www.rsdn.ru/Forum/?mid=170199
В варианте на FS достаточно просто проверить размер индекс-файла и вычислить количество сообщений, разделив на размер заголовка(16). Если id, присланный браузером, меньше, открываем файлы и читаем новые сообщения методом, аналогичным описанному выше. Если нет — ничего не открываем и не читаем
Теперь представь самостоятельно действия с СУБД в таком же случае
И еще один минус СУБД — размер БД этих сообщений будет НАМНОГО больше, чем размер файлов в моем варианте. Проверено. Почему — думаю, обьяснять не надо.
Это будет работать быстро всегда. И независимо от общего количества сообщений и размеров файлов(для СУБД же чем больше записей, тем больше тормозов). И всегда будет доступен архив чата(или к примеру, доски сообщений(форума)).
Я здесь не касался каких-либо вопросов, связанных с обеспечением многопользовательской работы с этими файлами. Но разруливается это очень просто. Очевидно, писать в файл должен один какой-нибудь выделенный для этого процесс с необходимыми flock'ами и т.п. Читать — в режиме "только-для чтения" может кто угодно.
Так же я не касался вопросов какой-либо оптимизации. Например, файлы можно читать с использованием кеширования и разных smart-функций, что существенно повышает быстродействие. Ну и т.п.
На подобном принципе собран чат в ICQ-системе на http://911.ru
Просмотр его архива без логина в систему доступен здесь: http://911.ru/c_arc
Сам чат пока находится в "застое", т.е. развитие его планируется в будущем, а сейчас болтается только давно и "на коленке" написанная базовая версия.
Я мог бы привести и другие примеры, но ломает это все расписывать.
Например, система, в которой какой-либо промышленный автомат дампит данные о своей работе, или вообще что-либо, дампящее данные.
Эти данные гораздо удобнее и быстрее укладывать в файл последовательно, чем загонять в СУБД.
Как правило, сложные операции с такими данными нужны очень редко, например, отчет о работе за месяц/неделю/день.
Для этого отчета можно создать простенькую тулзу, которая загоняет из этих файлов данные в СУБД, и потом уж можешь мучать Базу Данных своими сложными запросами и буквально ставить ее "раком"(сленг ), сколько душе угодно.
Еще раз повторю: я не против использования разных промышленных СУБД. Но я за то, чтобы использовать их только в тех местах, где это имеет смысл. Например, в том же чате, удобно хранить в СУБД базовую информацию о пользователях. Гораздо удобнее использовать мощности СУБД для поиска записи с этой инфой по имени пользователя, скажем, для логина в систему. Меня бы напрягло делать на файлах текстовый поиск Тем более, если инфу об открытых сессиях хранить отдельно, и реальный логин требуется только при входе пользователя в систему, а не при каждом запросе.
Оно же в работе: http://911.ru/whois
Такую штуку собрать на СУБД с приемлемой скоростью работы невозможно принципиально.
Одно дело — сервер FTP, в котором инфа об IP нужна только при подключении пользователя(то есть, относительно редко).
Другое дело — HTTP, в котором эта инфа нужна при каждом запросе и большой входящей нагрузке(то есть, часто).
Все, больше писать не буду.
Надеюсь, я таки дал правильное направление хода ваших мыслей, если вы не поняли, о чем я писал и что имел ввиду в своих предыдущих постах...
Здравствуйте, DSD, Вы писали:
DSD>Да при чем здесь заточенная система? Если вы FS в контексте данной ветки рассматриваете, как одна запись=один файл, тогда да. Иначе — Вы просто не понимаете, о чем я Вам говорю.
Представь себе пожалуйста, что такое заточенная файловая система под хранение реляционных данных ... Мне это представляется минимум как что к любой реляционной записи можно обратится по нескольким индексам и не производить никакого поиска. При реализации этого на файловой системе обычного образца неизменно происходят издержки на поиск этой таблицы, а затем на поиски записи.
DSD>Любая промышленная СУБД не дает прямого доступа к данным. На любую мелочь извольте дать SQL-запросик, а она уж вам даст ответик, занимаясь при этом всей необходимой кучей обработок запросика и формирования ответика.
На фоне интеллектуальной обработки запросов (прекомпиляция, план исполнения и т.д.) обработка "запросика" — это самая простейшая операция. Почему ты упорно продолжаешь считать, что запрос первой строчки в файле и запрос первой записи в таблице в СУБД — по временных затратам различаются чуть ли не на порядки.
A>>Ага и называться это будет всё сервером БД. Я сомневаюсь, что для средней крупности задачи можно сделать всё это эффективнее чем существующие СУБД. DSD>Еще как можно! Во многих случаях с точностью до наоборот Это я к тому, что чем больше база(здесь: таблица), тем тормознутее работают даже простые запросы. См. ниже примеры.
Не хочу даже комментировать . Скорость простых запросов (ака select * from table where id<0 and id >10) практически не зависит от количества записей в таблице, а если id индексированное поле, то вообще фиксирована.
A>>Ты назвал это ресурсом СУБД, такого ресурса я действительно не знаю. DSD>Здесь "ресурс" — имелись ввиду не "данные", а ресурсы машины, которые кушает именно СУБД.
Поддержка соединения — это не ресурс !!! СУБД, машины и т.д. Не надо доказывать что дедушка Ленин всё ещё жив .
A>>Всё это с лихвой покрывает пул соединений ... DSD>Да дался тебе этот пул. Что такое пул соединений? Чем 100 соединений в пуле отдичаются от 100 соединений не в пуле? Только тем, что в пуле они более удобно организованы, но это по-прежнему 100 соединений, в одно они от этого не сливаются.
Ты представляешь себе, что такое пул соединений? Это значит, что на создание 100 соединений не тратится времени, они уже созданы, а значит как твой аргумент против СУБД не катит.
DSD>Пулы потоков — тоже не панацея. Их давно применяют везде, где это удобно и оптимально(тот же Apache), и применять их можно как в СУБД, так и без нее.
Сам настаивал, что СУБД их сильно много тратит времени на их создание, я теб говорю, что применяют Пул, а значит времени не тратится вообще ... ты начинаешь говорить, что они и так везед используются ... Где логика ?
DSD>Так что давайте забудем о неспецифичной оптимизации — она рулит в обоих случаях. Если и говорить, то об оптимизации, которая присутствует в одном варианте(с СУБД или без), и принципиально невозможна в другом.
Стоп, стоп а куда же тогда все твои аргументы подевались? Вначале ты настаиваешь, что СУБД тратит кучу времени и ресурсов на обработку одного запроса, потом оказывается, что практически ничего не тратится (по крайней мере из названных тобой), потому что всё легко оптимизируется и давно уже соптимизировано ...
Если уж говоришь, что с данными в файлах быстрее работать, то уж обоснуй ... а если для этого ещё при этом придётся сверху навернуть все возможности современной СУБД (читай пушкой по воробьям), а при этом ещё и существенного прироста ты не получишь ... , ты уж не обессудь если я скажу что твой вариант никуда не годится.
DSD>Сокеты — почти стандарт де-факто у промышленных СУБД. Даже если общаться с ней более рациональным путем, это соптимизирует только канал передачи данных. А ведь еще остается куча мест, где тоже не мешало бы упростить. Да, в общем-то, суть не в том, чтобы переделывать сервера БД. По мне — все там нормально. Суть в другом — не все нужно пихать в СУБД, а только необходимое.
Аргумент просто отпадный ... Почему-то все СУБД которые я видел позволяют обращаться к себе через что угодно и никак к сокетам не привязаны ... А никто и не говорит, что туда всё нужно пихать, но данные безусловно удобнее хранить в БД (я надеюсь тут никаких доказательств не надо ?).
A>>Это плохо ? Кто сказал, что всё это делается нерационально ... DSD>Рационально с точки зрения работы самой СУБД, но не конечного продукта(читай приложения).
Наоборот. Я вообще не понимаю, зачем СУБД работать рационально для самой себя ... Это что-то из оперы побольше себе памяти отгрести и процессор весь занять, чтобы ещё больше занять памяти и ещё больше процессора ... ИМХО чушь.
A>>Для необходимости реализации СУБД нужны хорошие основания и достаточно крупный проект, иначе сам проект на фоне реализации СУБД просто теряется. DSD>Согласен. Я не говорю о простейших веб-скриптиках.
Веб-приложение с реализацией собственной СУБД ... Ну-ну ... Кстати о собственных СУБД, лично я настроженно очень отношусь к таким вещам, и если слышу что в продукте для хранения данных реализована своя СУБД, я должен буду услышать ну очень веские основания для оправдания такого поведения ...
Я даже пример знаю ... Есть такая CMS (Content Management System) Zope, достаточно популярная как за рубежом, так и в России ... Они тоже по началу организовали собственную СУБД ... но очень быстро разочаровались в этом деле и наклепали провайдеры данных для самых распространённых СУБД и теперь вопрос зачем им своя СУБД ставит тех (кто занимается распространением и тех. поддержкой) в полное замешательство ... И заметьте это не маленький проект и разрабатывают эту систему довольно профессиональные программисты.
A>>Набор функций и алгоритмов работы для обеспечения хотя бы возможностей мелкой СУБД ИМХО я просто не потяну. DSD>Не обязательно писать мелкую СУБД. Можно просто продумать, что должно храниться в СУБД, а что — нет. Это кстати — вариант-компромисс.
Это называется проектированием.
DSD>Каждый из этих слоев, как правило, представляет данные в своем формате, максимально удобном и оптимальном для данного слоя. Поэтому существуют "прослойки", конвертирующие данные из одного формата в другой и трансферрящие их между этими слоями.
Откуда ты это взял? Прослойки появляются при неправильном проектировании. Данные между слоями должны ходить в одном формате иначе это просто бред какой-то, а не многозвенка.
DSD>Вот если избавиться от таких прослоек и максимально сблизить слои — работать будет намного быстрее. Но в промышленных СУБД от них избавиться невозможно принципиально, потому что потеряется универсальность сервера. А в практически каждом частном случае(в неуниверсальном варианте) это сделать было бы вполне можно и желательно. Вот тут-то собака и зарыта.
В СУБД нет никаких слоёв. Слои строятся в вашем приложении и СУБД может входить в один из слоёв называемых DB-layer.
DSD>Я тебе(ничего, что я на ты перешел? )
Так удобнее.
DSD>приведу другой, более сложный пример:
Ок.
DSD>Представь себе чат. Обычный html-чат, коих в интернете немало. Базовый набор функций.
DSD>Как выглядят в сервере БД сообщения? Как правило — одной таблицей.
Я прямо сейчас вижу этот изврат, что каждое сообщение пользователя сразу же пишется в БД ...
Пример плохого проектирования системы никак не может доказать преимущества FS. При таком вот проектировании системы, СУБД действительно будет тормозом.
Я не буду делать "разбор полётов", но это очень некорректный пример, я могу привести кучу вариантов, когда при точно таких же изначальных условиях система с использованием СУБД будет работать быстрее вот такой системы на FS. Могу только ещё раз упомянуть "Менеджер данных".
DSD>На подобном принципе собран чат в ICQ-системе на http://911.ru DSD>Просмотр его архива без логина в систему доступен здесь: http://911.ru/c_arc DSD>Сам чат пока находится в "застое", т.е. развитие его планируется в будущем, а сейчас болтается только давно и "на коленке" написанная базовая версия.
Плохого ничего сказать не могу . Смотрел, некоторые идеи довольно оригинальны ...
DSD>Я мог бы привести и другие примеры, но ломает это все расписывать. DSD>Например, система, в которой какой-либо промышленный автомат дампит данные о своей работе, или вообще что-либо, дампящее данные. DSD>Эти данные гораздо удобнее и быстрее укладывать в файл последовательно, чем загонять в СУБД.
Оно же в работе: http://911.ru/whois DSD>Такую штуку собрать на СУБД с приемлемой скоростью работы невозможно принципиально.
Очень сильно сомневаюсь. По-моему всё с точностью наоборот. По крайней мере никаких ограничений на "приемлемую скорость работы" я не вижу.
DSD>Все, больше писать не буду.
Здравствуйте, DSD, Вы писали:
R>>Это действительно страно. Мне бы очень хотелось, как работает combats.ru — неужели MySQL+perl? Если так, то все Вааши доводы бледнеют =)) DSD>Я им послал запрос на эту тему. Надеюсь, ответят.
Это было бы здорово!
DSD>>>А все вопросы с целостностью данных вполне решабельны и без использования сервера БД. R>>Нда, однако, к примеру, тот запрос, который Вы привели в соседнем посте: DSD>>>select count(*) from ... where ... R>>весьма подозрителен — Вы его храните в памяти. Хорошо, а вдруг количество изменится? Прийдется ведь менять значение здесь? Не думаю, что прописывать соответсвующую фуекцию во всех местах, где потенциально возможно изменение этой величины — хорошая мысль. Соответственно, прийдется писать некий объект, который будет СУБД, поддерживающей нужную целостность. DSD>А голова программисту зачем? Только чтобы запросики составлять? Ясен пень, когда надо и кем надо, оно меняется. И ясен пень, есть некий обьект в ядре продукта, который поддерживает необходимую целостность.
R>>Проблема ведь в чем, если Вам нужна скорость, то без сомнения, Вы сможете для своего проекта разработать способ представления и хранения данных, обеспечивающий эту самую максимальную скорость. Вот только прийдется, скорее всего, отказаться, например, от использования для построения запросов SQL. DSD>Ну и замечательно.
R>>Кроме того, не будет сохранения уелостности на уровне СУБД, прийдется делать на логическом и т.д. В результате имхо не получится сделать масштабируемое, легко настраиваемое, дружелюбное со стороны программиста приложение. DSD>Приложение должно в первую очередь дружить с машиной и пользователем, а не программистом. DSD>Удобства себе программист лолжен обеспечить сам. Отдельно.
Ну тогда надо писать на асме =)) DSD>Иначе плодятся программеры, которые свои удобства предпочитают быстродействию системы. Результат — веб-сервера, нагруженные как минимум тридцатью процентами бесполезных с точки зрения приложения и конечного пользователя действий.
Бывает и такое.
М-м-м. Вы меня не совсем правильно поняли. Я пытаюсь сказать, что преимущество БД перед ФС (у которой при правильной организации скорость возможно действительно чуть-чуть возрастет (но именно чуть-чуть — см. пост Андира)) в том, что БД (при правильном проектировании) хранит данные, а Вы в файловой системе — представление данных. Часто используемое — да. Обеспечивающее небольшой прирост производительности — да. Но за все надо платить. В результате потом труднее будет добавлять функциональность, переходя от версии 1.7б к версии 2.0. Возникнут проблемы с форматом данных, когда Вам вдруг понадобится добавить еще одно поле. Рухнет вся производительность, если прйдется выводить/обрабатывать другое представление данных. Ну и т.д.
Надеюсь на этот раз я яснее выразил свою мысль.
Re[18]: По поводу производительности и целостности
Здравствуйте, Rumata, Вы писали:
DSD>>Удобства себе программист лолжен обеспечить сам. Отдельно. R>Ну тогда надо писать на асме =))
Тогда уж лучше скажите — сразу на машинном коде, ведь компилятор — тоже "удобство для программиста".
Где-то в юморе кажись, проскакивала клава всего с тремя кнопками: "0", "1" и "Done". самое оно.
DSD>>Иначе плодятся программеры, которые свои удобства предпочитают быстродействию системы. Результат — веб-сервера, нагруженные как минимум тридцатью процентами бесполезных с точки зрения приложения и конечного пользователя действий. R>Бывает и такое.
Слишком часто. Настолько часто, что "нашу родину спасут только массовые расстрелы" (с) Goblin, LOTR2.
R>М-м-м. Вы меня не совсем правильно поняли. Я пытаюсь сказать, что преимущество БД перед ФС (у которой при правильной организации скорость возможно действительно чуть-чуть возрастет (но именно чуть-чуть — см. пост Андира))
Для меня Андир пока что: собеседник и оппонент в некоторых довольно интересных спорах и дискуссиях, но он еще не перешел в разряд "Фигурновых, Страуструпов и пр.", так что моё ИМХО — Андир тут весьма заблуждается, и следовательно не стоит мне его утверждения приводить, как откровение Божье. Лучше сами что-то докажите, чем теоретизировать на голом месте и мнениях других. Надеюсь, не слишком резко загнул?
R>в том, что БД (при правильном проектировании) хранит данные, а Вы в файловой системе — представление данных.
Хм... Я понял Вашу точку зрения. В таком случае в конечном итоге БД тоже хранит представление данных. Ужас, не так ли?
Еще вопрос, чем именно Вы отличаете эти два понятия? Что такое данные и что такое их представление по-вашему?
R>Часто используемое — да. Обеспечивающее небольшой прирост производительности — да. Но за все надо платить. В результате потом труднее будет добавлять функциональность, переходя от версии 1.7б к версии 2.0.
Это должно быть продумано на этапе проектирования, а не ценой производительности поддерживать эту возможность во время реальной работы приложения.
R>Возникнут проблемы с форматом данных, когда Вам вдруг понадобится добавить еще одно поле.
Ой, господь с Вами — да это же легко
Я тут уже намекал, что многие программисты патологически боятся бинарных данных в неHUMANREADABLE виде, потому как снаружи это кажется все очень сложным, неудобным и т.п.
Вы часом не из их числа?
R>Рухнет вся производительность, если прйдется выводить/обрабатывать другое представление данных. Ну и т.д.
Нужно будет — переберу формат. И времени это у меня займет много меньше, чем Вы себе представляете.
R>Надеюсь на этот раз я яснее выразил свою мысль.
Ни капли, сорри за сарказм
Здравствуйте, Rumata, Вы писали:
DSD>>Странно, мои подобные задачи стали работать гораздо быстрее, когда я их переписал с варианта на MySQL на вариант с использованием файловой системы и кеша. R>Возможно Вы неудачно проектироали структуру бд.
Кхм... Пора мне в монастырь, похоже, уходить..
Спроектируй, а? Тогда поверю.
DSD>>И еще. Вы действительно почувствовали, что БД работает быстрее, чем FS на своем опыте? То есть Вы пробовали и так, и так, да? R>Да. Быстрее настолько, что при работе через фс пхп иногда вылетал по таймауту. Такая уж задача была.
Отвечу Вашей же фразой: Возможно Вы неудачно проектироали структуру бд в FS.
А серьезно — не зная условий задачи и способа, которым Вы ее реализовывали, мне трудно судить о чем-либо...
DSD>>Я к чему это спросил: редко кто делает все на FS, а потом переходит на БД. Большинство сразу пишут на БД, а о FS-вариантах судят только по тому, что слышали от других. Поэтому хочу убедиться, что Вы не один из них и не голословно утверждаете сей факт. R>К моему несчастью мне далеко не сразу удалось попасть на хостинг с поддержкой бд, поэтому, например, я поначалу долго общался с такой штукой, как ubb, а потом перешел на vbb. Уж поверьте, на основе этих двух форумов я могу сравнить фс и бд.
Когда-то я писал на перле систему терминалов для АРМ. БД я делал в DBF-формате. Использовал правда для работы с ней чужой модуль, но написанный на чистом перле(в смысле — без всяких Си-шных либ). И все просто летало. Фактически это и есть прямая работа с FS.
Если же Вы писали, основываясь на текстовом формате данных или бинарном, но без оптимизаций для поиска записей, то тут и спорить нечего, почему оно тормозило. Ну, конечно же, плюс еще тот факт, что Вы работаете на ПХП, а MySQL писан на Сях. Это, конечно, тоже очень весомый аргумент, хоть и второстепенный по контексту данной дискуссии.
DSD>>Еще я знаю, что большинство веб-программистов(или веб-мастеров, как их правильнее назвать) на файловой системе данные хранят двумя способами: либо одна запись = один файл, либо в одном файле, но в текстовом, немного похожем на структуру ini-файла. То есть делают удобно для чтения человека, а не машины. И после этого становится понятным, откуда тормоза. DSD>>Я же говорю о нормальном бинарном хранилище данных. Записи отдельно, индексы для них отдельно. Хотя бы в таком простом варианте. R>К сожалению, не понял, Вашу мысль. Не могли бы Вы привести пример вида: в файле a.txt храним то, то и то в формате таком, в файле b.txt ...
Кажется, я выше дал понять, что никаких .txt быть не может Только бинарный формат, как минимум, с индексацией записей.
Возможно, именно из-за этого у нас с Вами и были разногласия, хотя про неприемлемость текстовых файлов я упомянул еще в начале этого флейма.
А примеры я приводил в ответвлении дискуссии с Андир'ом. Смотрите там.
DSD>>Ведь не функции чтения с диска тормозят. Не их мы сравниваем(кстати, MySQL, как и другие сервера БД, тоже хранит данные на диске). R>Повторяю еще раз: я в курсе, где хранит данные mysql. R>btw честно говоря, я потерял нить, а что мы сравниваем?
В общем случае мы сравниваем варианты проектирования(и реализации, конечно же) с использованием СУБД и без.
Здравствуйте, lozzy, Вы писали:
L>Привожу простой пример, показывающий несостоятелность ФС-варианта: L>Допустим у нас 1 запись на 1 файл.
Я уже сказал, что это — неприемлемый вариант. И действительно тормозной до жути.
L>Допустим они (данные) хранятся в определенном формате. Допустим надо вывести название, скажем, каждого продукта, который хранится в файле. L>Вопрос: насколько быстрее будет выбрать данные из базы нежели открывать каждый файл и выцарапывать оттуда название ? L>И таких вариантов — вагон и маленькая тележка.
См. выше...
L>Вариант с написанием собственного хранилища данных не рассматриваем — ибо это будет написание своей базы, что противоречит начальным условиям задачи.
Как раз именно этот вариант мы и рассматриваем. В условии задачи такого противоречия не было!!!! Читайте с самого корня, с первых сообщений по теме, заданной Кодтом. И потом — это не есть написание своей СУБД. Это есть отказ от использования промышленной СУБД в пользу прямого доступа к данным. В пользу наиболее оптимального планирования с максимальной производительностью, а не с максимальной, в большинстве случаев лишней, универсальностью.
L>Я, по первости, тоже думал, что база это нифига не рулез, что надо все на файлах делать. В результате поимел такого гемороя — мама дорогая. Никому не советую.
Ну почему вы все при словах "файловая система" сразу воспринимаете это как "одна запись=один файл", а?!! Сколько я могу обьяснять, что это не то, о чем я говорил?
L>Даже убогий (в плане функциональности) MySQL на порядки выше по удобству работы перед файловой системой.
Кстати, нифига он не убогий. В нем достаточно функциональности для того, чтобы на нем строить даже сложные проекты. Главное — знать как комбинировать имеющиеся функции, чтобы не наломать дров.
Здравствуйте, Andir, Вы писали:
A>Представь себе пожалуйста, что такое заточенная файловая система под хранение реляционных данных ... Мне это представляется минимум как что к любой реляционной записи можно обратится по нескольким индексам и не производить никакого поиска. При реализации этого на файловой системе обычного образца неизменно происходят издержки на поиск этой таблицы, а затем на поиски записи.
Сама идея, конечно интересная. Это в случае, если файловая система будет вся представлена одной таблицей. Но насчет того, что по индексу не производится никакого поиска — вы ошибаетесь. Индексирование всего лишь облегчает поиск(иногда очень сильно), но совершенно не убирает его на нет. Это, по крайней мере, касаемо понятия "индекс", принятого в СУБД. Альтернатива — понятие "индекс" применительно к простым массивам. Там да.
DSD>>Любая промышленная СУБД не дает прямого доступа к данным. На любую мелочь извольте дать SQL-запросик, а она уж вам даст ответик, занимаясь при этом всей необходимой кучей обработок запросика и формирования ответика. A>На фоне интеллектуальной обработки запросов (прекомпиляция, план исполнения и т.д.) обработка "запросика" — это самая простейшая операция.
Простейшая с точки зрения самой СУБД. План исполнения тоже парсится и интерпретируется исполнительным механизмом.
A>Почему ты упорно продолжаешь считать, что запрос первой строчки в файле и запрос первой записи в таблице в СУБД — по временных затратам различаются чуть ли не на порядки.
А они действительно различаются. И чем больше нагрузка, тем больше это заметно. Возьмите и протестируйте сами. Только я уточню — не первой строчки в файле, а первой записи. Для получения строчки из файла тоже нужно попотеть — искать символ завершения строки.
A>>>Ага и называться это будет всё сервером БД. Я сомневаюсь, что для средней крупности задачи можно сделать всё это эффективнее чем существующие СУБД. DSD>>Еще как можно! Во многих случаях с точностью до наоборот Это я к тому, что чем больше база(здесь: таблица), тем тормознутее работают даже простые запросы. См. ниже примеры. A>Не хочу даже комментировать . Скорость простых запросов (ака select * from table where id<0 and id >10) практически не зависит от количества записей в таблице, а если id индексированное поле, то вообще фиксирована.
Представь таблицу, в которой записи идут в строгом порядке поля id: 1, 2, 3, 4, 5. Но с пробелами, т.е. некоторые записи, например, были удалены.
Тебе нужны 20 последних записей. В SQL-выражении select при выборке ты не можешь управлять(рулить) физическими номерами записей, только полем id.
Допустим, в таблице всего было 200 записей(Max(ID)=201). 10 было удалено в произвольных местах. Предположим, 3 удаленных записи попали в нужную тебе последнюю двадцатку, т.е. фактически тебе нужны записи с id<=201 and id >=178. Но как ты это поймешь? Придется делать либо сложный запрос, либо серию простых, либо запрос с опцией сортировки(здесь ненужные тормоза) по убыванию id и последующем fetch первых 20-ти записей(кушаем ресурсы для остальных 170 неот'fetch'енных), после чего их уже в приложении нужно сделать reverse(еще одни тормоза), чтоб они в конечном итоге шли по возрастанию id.
И сразу все начинает зависеть Неужто не заметно, где тормозит? Неужто ты слепо веришь, что это будет работать с такой же скоростью, чем мной предложенный вариант в примере с чатом(чат — это абстрактный пример, первым пришедший в голову)?
A>>>Ты назвал это ресурсом СУБД, такого ресурса я действительно не знаю. DSD>>Здесь "ресурс" — имелись ввиду не "данные", а ресурсы машины, которые кушает именно СУБД. A>Поддержка соединения — это не ресурс !!! СУБД, машины и т.д.
Ресурс диска — его доступная емкость.
Ресурс памяти — ее доступная емкость.
Ресурс процессора — доступная работа, которую он может выполнить(100% — текущая загрузка).
Нажми в WinNT/2000/XP Ctrl+Shift+Esc и на второй закладке полюбуйся, какое приложение какие ресурсы съедает.
В Unix набери top и полюбуйся тем же...
Я именно это имел ввиду под термином "ресурс".
A>Не надо доказывать что дедушка Ленин всё ещё жив .
Он будет вечно жить в наших сердцах
A>Ты представляешь себе, что такое пул соединений?
Не только представляю, я их создаю даже очень часто.
Сам-то представляешь?
A>Это значит, что на создание 100 соединений не тратится времени, они уже созданы, а значит как твой аргумент против СУБД не катит.
Уже созданы с одним открытым концом. Пока мое приложение не изьявит желание подключиться к серверу БД, это нельзя назвать установленным соединением.
После чего, в случае с TCP производятся всякие handshake и т.п. Вступает в работу TCP-подсистема, контролирующая порядок пакетов, накапливающая раньше времени пришедшие пакеты и т.д., в общем обеспечивающая работу TCP-канала.
Так что ты говорил о том, что соединения уже созданы? Кем, когда и нафига так рано?
DSD>>Пулы потоков — тоже не панацея. Их давно применяют везде, где это удобно и оптимально(тот же Apache), и применять их можно как в СУБД, так и без нее. A>Сам настаивал, что СУБД их сильно много тратит времени на их создание, я теб говорю, что применяют Пул, а значит времени не тратится вообще ... ты начинаешь говорить, что они и так везед используются ... Где логика ?
На пулы не тратится времени? Ты где это вычитал? В том же Apache создается пул процессов. Начально создается при старте сервера. В целях избежания мемори-ликов каждый процесс в пуле должен завершить свою работу, отработав установленное в конфиге количество запросов. На его место создается новый процесс. Это позволяет существенно экономить время, но это не значит, что времени не тратится вообще. Это так же не значит, что при каждом запросе не тратится время на переинициализацию переменных процесса для номального принятия нового запроса. Там слишком много аспектов. И было бы глупо с твоей стороны не принимать их во внимание. Ведь то, о чем ты говоришь, является идеальным пулом, а таких, к сожалению, не бывает(существуют только в теории). Не мешай теорию с практикой. Это очень разные вещи.
DSD>>Так что давайте забудем о неспецифичной оптимизации — она рулит в обоих случаях. Если и говорить, то об оптимизации, которая присутствует в одном варианте(с СУБД или без), и принципиально невозможна в другом.
A>Стоп, стоп а куда же тогда все твои аргументы подевались? Вначале ты настаиваешь, что СУБД тратит кучу времени и ресурсов на обработку одного запроса, потом оказывается, что практически ничего не тратится (по крайней мере из названных тобой), потому что всё легко оптимизируется и давно уже соптимизировано ...
Давай разберем запрос. приходит запрос в виде строки SQL. На стороне сервера он компилируется в более четкие бинарные инструкции. Далее по нему проходит оптимизатор. Он выкидывает все лишнее и создает окончательный план запроса, который тоже является совокупностью инструкций, предположительно в бинарном виде — так проще будет парсить исполняющему механизму. Далее на этот план нападает этот самый исполняющий механизм, который, читая план по инструкциям, вызывает внутри себя соответствующие функции, отвечающие за исполнение этих инструкций. Тройной парсинг налицо(Да.ДА! Именно парсинг. Только работающий быстрее, потому что не надо искать длинные инструкции типа ["select"=6 байт] и не надо проверять синтаксические и логические ошибки — их проверяет компилятор на первом этапе). Эти инструкции — не машинный код. Машинный код эти инструкции читает, вызывая при этом цепочку сравнений и разных действий, чтобы запустить на исполнение соответствующую инструкции подпрограмму. И эта цепочка порой может быть достаточно длинной. Это все занимает процессорное время. Если же я, скажем на Си, пишу свою программу, работающую с данными, то в каждом конкретном случае я заранее описываю алгоритм, по которому данные будут читаться из хранилища. У меня это, может быть, займет несколько больше времени при проектировании, чем у программиста, использующего СУБД, но это компенсируется гораздо меньшими потерями производительности при работе скомпилированного приложения. И никакого лишнего парсинга нет. Выполняется прямо то, что предписано практически машинными инструкциями, выше — только ядро системы и его API. Это гораздо оптимальней.
Вся эта разница незаметна при выполнении одного запроса(и так быстро, и эдак), но она становится заметна под нагрузкой, когда одновременно выполняется туева хуча запросов.
Далее, можно много говорить о механизмах транзакций. Это очень хорошая и полезная штука, НО ТОЛЬКО ТАМ, ГДЕ ОНА НУЖНА. В остальных же случаях — это тормоз.
Приведу пример: возьмем схемку одновременной записи данных (в одно и то же место) двумя процессами. В моей схеме, как я и говорил, должен быть только один процесс, реально пишущий данные в хранилище(иначе будет бардак. Здесь без схемы клиент-сервер тоже не обойтись). Назовем его процесс-сервер.
Два процесса, хотящих прямо сейчас записать данные, должны дать этому процессу-серверу инструкции на запись. Он принимает одной охапкой несколько инструкций от разных процессов, в т.ч. и от этих двух.
Он сливает эти инструкции вместе(merge), чтобы все возможные обновления записей произвести за один проход(оптимизация). Естесственно, он их сливает с учетом очередности поступления инструкций. То есть из двух инструкций на обновление одного и того же поля в одной и той же записи выиграет последняя пришедшая, т.к. при последовательном выполнении она один хрен в конечном итоге перепишет содержимое поля. Предыдущие инструкции можно выкинуть, т.к. нет смысла делать изменения, которые перепишутся наиболее поздней из них.
Это — одна из простейших схем механизма транзакций без какой-либо изоляции и возможности отката(то есть, это не полноценные транзакции, но похожесть есть).
В большинстве проектов большего и не нужно.
Однако в промышленной СУБД такое невозможно в силу ее универсальности.
Во-первых, возможность отката(rollback) навязывается сервером(и очень правильно навязывается с его точки зрения), а это значит, что кушаются ресурсы на поддержку либо промежуточных результатов, либо довольно хитроумно сделанной истории изменения записей(кое-где здесь применяют понятие журнала).
Во-вторых, оптимизатор не может себе позволить спланировать вышеописанный процесс максимально эффективным образом. Хотя бы потому, что он должен поддерживать универсальность и гибкость БД, а значит, может быть ситуация, при которой так сливать операции изменений просто нельзя. Ведь СУБД не знает о конкретных особенностях именно данного проекта, что в нем можно, а что нельзя делать без ущерба для данных и схем работы проекта.
Об изолированных транзакциях и их скорости совместной работы я вообще молчу...
A>Если уж говоришь, что с данными в файлах быстрее работать, то уж обоснуй ... а если для этого ещё при этом придётся сверху навернуть все возможности современной СУБД (читай пушкой по воробьям), а при этом ещё и существенного прироста ты не получишь ... , ты уж не обессудь если я скажу что твой вариант никуда не годится.
См. выше. Только что обосновал.
DSD>>Сокеты — почти стандарт де-факто у промышленных СУБД. Даже если общаться с ней более рациональным путем, это соптимизирует только канал передачи данных. А ведь еще остается куча мест, где тоже не мешало бы упростить. Да, в общем-то, суть не в том, чтобы переделывать сервера БД. По мне — все там нормально. Суть в другом — не все нужно пихать в СУБД, а только необходимое.
A>Аргумент просто отпадный ... Почему-то все СУБД которые я видел позволяют обращаться к себе через что угодно
Например, через что?
A>и никак к сокетам не привязаны ... А никто и не говорит, что туда всё нужно пихать, но данные безусловно удобнее хранить в БД (я надеюсь тут никаких доказательств не надо ?).
Надо. В XML тоже много чего удобно хранить, но для машины это — геморрой с обработкой. Это — HUMANREADABLE формат, и удобство здесь только с точки зрения человека, который будет смотреть на данные в чистом виде.
Для человека удобнее и просто unsigned long число хранить в виде текста, а не, скажем, 4-х байт. А для машины же это — с точностью до наоборот.
A>>>Это плохо ? Кто сказал, что всё это делается нерационально ... DSD>>Рационально с точки зрения работы самой СУБД, но не конечного продукта(читай приложения). A>Наоборот. Я вообще не понимаю, зачем СУБД работать рационально для самой себя ...
Не для самой себя, а для концепции СУБД. Таблицы, записи, сущности, стандарты... A>Это что-то из оперы побольше себе памяти отгрести и процессор весь занять, чтобы ещё больше занять памяти и ещё больше процессора ... ИМХО чушь.
Действительно, чушь Нет, это из другой оперы, с увертюрами.
A>Веб-приложение с реализацией собственной СУБД ... Ну-ну ... Кстати о собственных СУБД, лично я настроженно очень отношусь к таким вещам, и если слышу что в продукте для хранения данных реализована своя СУБД, я должен буду услышать ну очень веские основания для оправдания такого поведения ... A>Я даже пример знаю ... Есть такая CMS (Content Management System) Zope, достаточно популярная как за рубежом, так и в России ... Они тоже по началу организовали собственную СУБД ... но очень быстро разочаровались в этом деле и наклепали провайдеры данных для самых распространённых СУБД и теперь вопрос зачем им своя СУБД ставит тех (кто занимается распространением и тех. поддержкой) в полное замешательство ... И заметьте это не маленький проект и разрабатывают эту систему довольно профессиональные программисты.
У Zope сама концепция проекта требует универсальное хранилище данных. И нет никакой разницы, какую СУБД использовать. Тут все понятно. Каждый выбирает ту СУБД, которая наиболее ему подходит.
Я говорю о несколько других проектах, подобных той же ICQ. Там нет смысла использовать промышленную СУБД — она даст больше геморроя, чем пользы.
Такая уж особенность у проекта.
A>>>Набор функций и алгоритмов работы для обеспечения хотя бы возможностей мелкой СУБД ИМХО я просто не потяну. DSD>>Не обязательно писать мелкую СУБД. Можно просто продумать, что должно храниться в СУБД, а что — нет. Это кстати — вариант-компромисс. A>Это называется проектированием.
Да. Но не совсем. К примеру, если человек не умеет хранить и обрабатывать данные никак, кроме как в СУБД, врядли он на этапе проектирования будет задумываться о чем-либо, кроме как о СУБД в качестве хранилища данных. К сожалению, такова действительность.
DSD>>Каждый из этих слоев, как правило, представляет данные в своем формате, максимально удобном и оптимальном для данного слоя. Поэтому существуют "прослойки", конвертирующие данные из одного формата в другой и трансферрящие их между этими слоями. A>Откуда ты это взял? Прослойки появляются при неправильном проектировании. Данные между слоями должны ходить в одном формате иначе это просто бред какой-то, а не многозвенка.
Данные физически не могут ходить в одном формате. Вы в своем приложении работаете с данными совсем не в том формате, в каком работает с ними СУБД внутри себя. Более того, как правило, Вы даже не знаете ее внутреннего формата данных.
DSD>>Вот если избавиться от таких прослоек и максимально сблизить слои — работать будет намного быстрее. Но в промышленных СУБД от них избавиться невозможно принципиально, потому что потеряется универсальность сервера. А в практически каждом частном случае(в неуниверсальном варианте) это сделать было бы вполне можно и желательно. Вот тут-то собака и зарыта. A>В СУБД нет никаких слоёв. Слои строятся в вашем приложении и СУБД может входить в один из слоёв называемых DB-layer.
В СУБД есть слои. Практически с теми же названиями. СУБД — сама по себе является законченным приложением со всеми этими слоями. А вы ее же используете в качестве одного из слоев в своем приложении.
DSD>>Как выглядят в сервере БД сообщения? Как правило — одной таблицей. A>Я прямо сейчас вижу этот изврат, что каждое сообщение пользователя сразу же пишется в БД ...
Для большинства так называемых "веб-программистов" это не изврат, а действительность. Большинство, к сожалению, именно так и делают.
Некоторые делают на текстовых файлах и работают исключительно с текстовыми строками, что тоже само по себе — тормоз еще тот, пожалуй, даже хуже, чем СУБД.
A>Пример плохого проектирования системы никак не может доказать преимущества FS. При таком вот проектировании системы, СУБД действительно будет тормозом. A>Я не буду делать "разбор полётов", но это очень некорректный пример, я могу привести кучу вариантов, когда при точно таких же изначальных условиях система с использованием СУБД будет работать быстрее вот такой системы на FS. Могу только ещё раз упомянуть "Менеджер данных".
Приведи. Очень любопытственно.
A>Плохого ничего сказать не могу . Смотрел, некоторые идеи довольно оригинальны ...
Спасибо на добром слове
DSD>>Я мог бы привести и другие примеры, но ломает это все расписывать. DSD>>Например, система, в которой какой-либо промышленный автомат дампит данные о своей работе, или вообще что-либо, дампящее данные. DSD>>Эти данные гораздо удобнее и быстрее укладывать в файл последовательно, чем загонять в СУБД. A>Здесь вообще непонятно, какая разница куда дампятся данные, автомату на это вообще говоря должно быть наплевать.
Автомату — да, ему пофиг. Но системе, принимающей эти данные — нет. Она может не успевать их укладывать.
DSD>>Информация к размышлению: http://rsdn.ru/Forum/Message.aspx?mid=163575&only=1
Оно же в работе: http://911.ru/whois DSD>>Такую штуку собрать на СУБД с приемлемой скоростью работы невозможно принципиально. A>Очень сильно сомневаюсь. По-моему всё с точностью наоборот. По крайней мере никаких ограничений на "приемлемую скорость работы" я не вижу.
А ты попробуй Я-то напробовался уже
Еще в качестве примера хочу привести какой-нибудь интернет-магазин.
Например http://www.ozon.ru
Это достаточно известный и раскрученный проект, что позволяет судить о присутствии добротной внешней нагрузки на сервер.
Полагаю, что там используется СУБД, ведь врядли у начальства есть столько денег(а точнее, желания их платить), чтобы дать зарплату программистам, которые собрали бы этот сервер без использования СУБД.
Так вот, мои мысли по поводу:
Там стоит довольно мощная тачка, чтобы выдержать наплыв посетителей.
Я думаю, что если хорошо продумать и собрать эту же систему без использования промышленной СУБД, то для обслуживания того же потока посетителей хватило бы машины, типа Пентиум_сто_шестьдесятшесть_Мэ_Мэ_Ха с умеренным количеством оперативки. Чего с использованием СУБД добиться не удастся.
Сужу я не из теоретических знаний, а из практического опыта.
--
DSD
Re[19]: По поводу производительности и целостности
Здравствуйте, 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
Это конечно оффтоп и флейм, но вот людям делать нечего! : )
Перекуём баги на фичи!
выглядит так:
)?
или в БД . Пример вообще говоря странный.
. Скорость простых запросов (ака select * from table where id<0 and id >10) практически не зависит от количества записей в таблице, а если id индексированное поле, то вообще фиксирована.
, так что снимаю этот аргумент.
