Здравствуйте, 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
Это достаточно известный и раскрученный проект, что позволяет судить о присутствии добротной внешней нагрузки на сервер.
Полагаю, что там используется СУБД, ведь врядли у начальства есть столько денег(а точнее, желания их платить), чтобы дать зарплату программистам, которые собрали бы этот сервер без использования СУБД.
Так вот, мои мысли по поводу:
Там стоит довольно мощная тачка, чтобы выдержать наплыв посетителей.
Я думаю, что если хорошо продумать и собрать эту же систему без использования промышленной СУБД, то для обслуживания того же потока посетителей хватило бы машины, типа Пентиум_сто_шестьдесятшесть_Мэ_Мэ_Ха с умеренным количеством оперативки. Чего с использованием СУБД добиться не удастся.
Сужу я не из теоретических знаний, а из практического опыта.
или в БД . Пример вообще говоря странный.
. Скорость простых запросов (ака select * from table where id<0 and id >10) практически не зависит от количества записей в таблице, а если id индексированное поле, то вообще фиксирована.
