Здравствуйте, javaque, Вы писали:

J>Интересное решение. Но у меня возникают сомнения в целесобразности:
J>1) теперь при каждой выборки данных еще будет осуществлятся тяжелая операция записи данных на диск
В большинстве случаев — не будет. Данные будут лежать в кэше ОС и сбросятся на диск позже.

Время на запись обычно с лихвой окупается — lighthttpd работает в десятки раз быстрее Tomcat'а на статических данных при сильной загрузке.

J>2) насколько часто данные могут запрашиватся пользоватетелем не понятно, может он их всего один раз запросит а может и по 100 в день
Ну так и удалять наименее используемые файлы — это же кэш.

J>Архитектуры готовы поменять. Главное выработать грамотное решение на века (при постоянно растущем кол-ве посетителей)
С базой данных — это тупик. Думайте про умные распределенное файловое хранилище. Можно прочитать про то, как устроен LiveJournal:
http://highscalability.com/livejournal-architecture

Здравствуйте, javaque, Вы писали:

J>Колеги, возникла следующая трабла.
[skip]
J>В итоге по цепочке клиент<->tomcat<->субд постоянно летает большой объем данных, все усугубляеться большим кол-вом трафа.
J>Кто что может посоветовать? Где здесь узкое место? Если начать кэшировать данные то снизиться нагрузка на СУБД и возрастет на tomcat.
J>А может все такие кэшировать? (oscache и еще как, там вроде какие jsp тэги даже есть) Или глобально что-то надо менять в архитектуре?
С архитектурой проблемы, однако. Большие данные лучше в обычной СУБД не хранить — плохо они для этого приспособлены.

В качестве сравнительно быстрого фикса можно такое решение сделать: после доставания данные кладутся во временный файл в каталоге, куда смотрит Apache (или другой сервер, мне больше lighthttpd нравится), а клиенту отправляется перенаправление на него.

Этот каталог с временными файлами еще может и как кэш работать — так как можно не пересоздавать файл, если он уже и так есть.

Если нужен пофайловый ACL, то имеет смысл написать модуль расширения для своего сервера.

Здравствуйте, javaque, Вы писали:

J>2Cyberax: объясните плиз какую роль играет БД в вашей схеме?? Зачем хранить 2 копии файла (один в бд другой на диске)?
ОДНОЙ копии файла недостаточно в любом случае — повредится ФС на узле, что тогда будете делать? Значит, нужно хранить где-то хотя бы еще одну копию.

Руками механизм репликации писать долго, нудно и ненадежно. Готовых приличных ФС тоже я не знаю.

А вот базы данных с репликаций справляются превосходно — значит и надо их для этого использовать.

Колеги, возникла следующая трабла.
Есть связка tomcat+СУБД
Есть задача отображать посетителям сайта бинарный контент (картинки,музака, видео и тп) и текстовый
Сейчас это реализовано следующим образом

1)jsp-ка, которая:
— посылает GET запрос на ContentServlet (типа дай мне картинки с 100-ой по 500-ю )
— выдирает из request'а данные и отображает пользователю

2) сервлет ContentServlet:
— принимает Get запросы
— дергает метод объекта от спец. класса DAO (объект лежит в сеcсии), типа dao.getPics(100,500)
— кладет полученные данные в request и делает форвард на jsp

3) метод класса DAO:
List getPics(long from, long to){
-получает пул из некого синглтона
-берет из пула Connection
-делает select к СУБД
-закрывает Connection
}

В итоге по цепочке клиент<->tomcat<->субд постоянно летает большой объем данных, все усугубляеться большим кол-вом трафа.
Кто что может посоветовать? Где здесь узкое место? Если начать кэшировать данные то снизиться нагрузка на СУБД и возрастет на tomcat.
А может все такие кэшировать? (oscache и еще как, там вроде какие jsp тэги даже есть) Или глобально что-то надо менять в архитектуре?

Интересное решение. Но у меня возникают сомнения в целесобразности:
1) теперь при каждой выборки данных еще будет осуществлятся тяжелая операция записи данных на диск
2) насколько часто данные могут запрашиватся пользоватетелем не понятно, может он их всего один раз запросит а может и по 100 в день

Архитектуры готовы поменять. Главное выработать грамотное решение на века (при постоянно растущем кол-ве посетителей)

C>В качестве сравнительно быстрого фикса можно такое решение сделать: после доставания данные кладутся во временный файл в каталоге, куда смотрит Apache (или другой сервер, мне больше lighthttpd нравится), а клиенту отправляется перенаправление на него.

C>Этот каталог с временными файлами еще может и как кэш работать — так как можно не пересоздавать файл, если он уже и так есть.

C>С базой данных — это тупик. Думайте про умные распределенное файловое хранилище. Можно прочитать про то, как устроен LiveJournal:

Гм, а почему с базой данных — тупик? Разумеется, одна глобальная БД с действительно большим объемом данных не справиться (вернее, слишком дорого будут стоить лицензии со всеми partioning'ами). Но почему в качестве элемента распределенной системы лучше использовать файловую систему, а не БД — мне не очевидно.

Конечно, partioning и методы ребалансинга между отдельными узлами придется делать самому, но хотя бы не будет проблем с организацией HA, да и обновления будет выглядеть проще.
Сравнения производительности работы с файлами и с блобами для приличных БД я никогда не видел, а так как наши тесты БД упирались явно в железо, то не понятно, с чего файловая структура должна быть существенно быстрее, а вот ее поддержка будет не проще.

Впрочем, возможно, я действительно что-то не понимаю, проектов класс LJ делать не приходилось.
Да и вряд ли в данном случае речь идет о проекте с нагрузкой порядка десятков тысяч транзакций в секунду. А тысячи транзакций можно реализовать и через блобы на какой-нибудь DB2 Express C.

Но вот про кэш подумать стоит (про memcached, скорее всего).

Здравствуйте, Дельгядо Филипп, Вы писали:

C>>С базой данных — это тупик. Думайте про умные распределенное файловое хранилище. Можно прочитать про то, как устроен LiveJournal:
ДФ>Гм, а почему с базой данных — тупик? Разумеется, одна глобальная БД с действительно большим объемом данных не справиться (вернее, слишком дорого будут стоить лицензии со всеми partioning'ами). Но почему в качестве элемента распределенной системы лучше использовать файловую систему, а не БД — мне не очевидно.
Потому, что лучше файловой системы для отдачи файлов по сети — пока ничего не придумали.

ДФ>Конечно, partioning и методы ребалансинга между отдельными узлами придется делать самому, но хотя бы не будет проблем с организацией HA, да и обновления будет выглядеть проще.
А теперь подумай — если ты уже сам делаешь partitioning и HA, то почему не сделать еще один шаг и не использовать файловую систему вместо блобов в БД?

Точнее, я бы использовал комбинированую схему — сделал бы центральную БД, где хранятся все блобы (удобно для бэкапа и т.п.) и систему, которая распихивала бы блобы по узлам-серверам. Таким образом, очень легко обеспечить HA — упадет одна нода, так просто перераспределяем ее данные на работающие узлы.

ДФ>Сравнения производительности работы с файлами и с блобами для приличных БД я никогда не видел, а так как наши тесты БД упирались явно в железо, то не понятно, с чего файловая структура должна быть существенно быстрее, а вот ее поддержка будет не проще.
Сравнивал — разница в десятки раз. Lighthttpd забивает стомегабитный канал статическими файлами даже не напрягаясь (уровень загрузки процессора близок к 5%-10% на каком-то P4), тут еще сказывается его асинхронная неблокирующаяся натура. Tomcat/Jetty на таких нагрузках съедает весь процессор.

ДФ>Впрочем, возможно, я действительно что-то не понимаю, проектов класс LJ делать не приходилось.
ДФ>Да и вряд ли в данном случае речь идет о проекте с нагрузкой порядка десятков тысяч транзакций в секунду. А тысячи транзакций можно реализовать и через блобы на какой-нибудь DB2 Express C.
Сотни транзакций в секунду, кстати, на определенных видах приложений получить можно легче легкого даже с небольшим числом клиентов.

ДФ>Но вот про кэш подумать стоит (про memcached, скорее всего).
Memcached лучше всего подходит для сколь-либо динамических данных (типа комментариев в блогах). Для статических данных он только вредить будет.

Здравствуйте, Cyberax, Вы писали:

ДФ>>Сравнения производительности работы с файлами и с блобами для приличных БД я никогда не видел, а так как наши тесты БД упирались явно в железо, то не понятно, с чего файловая структура должна быть существенно быстрее, а вот ее поддержка будет не проще.
C>Сравнивал — разница в десятки раз. Lighthttpd забивает стомегабитный канал статическими файлами даже не напрягаясь (уровень загрузки процессора близок к 5%-10% на каком-то P4), тут еще сказывается его асинхронная неблокирующаяся натура. Tomcat/Jetty на таких нагрузках съедает весь процессор.

Я правильно понял, что единственная причина использования файлов вместо БД — возможность использования lighthttpd для отдачи статического контента?
Т.е. если сделать, например, модуль к тому же lhttpd, который статику забирал бы из БД (а это, насколько я помню, вполне реально) — то смысла в файловой системе уже и не остается.
Просто, если подумать, мощная журналируемая, высокопроизводительная, распределенная файловая система по своей структуре мало отличается от аналогичной БД. Только БД обычно легче обслуживать и можно гибче настраивать.

И, есть ли все-таки сравнения именно файловой системы с БД, а не Tomcat с httpd? Просто очень интересно.


ДФ>>Впрочем, возможно, я действительно что-то не понимаю, проектов класс LJ делать не приходилось.
ДФ>>Да и вряд ли в данном случае речь идет о проекте с нагрузкой порядка десятков тысяч транзакций в секунду. А тысячи транзакций можно реализовать и через блобы на какой-нибудь DB2 Express C.
C>Сотни транзакций в секунду, кстати, на определенных видах приложений получить можно легче легкого даже с небольшим числом клиентов.

Гм. Я обычно считал, что если активный пользователь порождает больше транзакции в секунду — то что-то в системе не так (да и столько получается обычно при поллинге нотификаций).
1000 одновременных активных пользователей — это уже довольно много.

ДФ>>Но вот про кэш подумать стоит (про memcached, скорее всего).
C>Memcached лучше всего подходит для сколь-либо динамических данных (типа комментариев в блогах). Для статических данных он только вредить будет.
Угу. Впрочем, равномерной нагрузки почти никогда не бывает, так что причины использовать большой куш в оперативной памяти есть всегда.

Здравствуйте, Дельгядо Филипп, Вы писали:

C>>Сравнивал — разница в десятки раз. Lighthttpd забивает стомегабитный канал статическими файлами даже не напрягаясь (уровень загрузки процессора близок к 5%-10% на каком-то P4), тут еще сказывается его асинхронная неблокирующаяся натура. Tomcat/Jetty на таких нагрузках съедает весь процессор.
ДФ>Я правильно понял, что единственная причина использования файлов вместо БД — возможность использования lighthttpd для отдачи статического контента?
ДФ>Т.е. если сделать, например, модуль к тому же lhttpd, который статику забирал бы из БД (а это, насколько я помню, вполне реально) — то смысла в файловой системе уже и не остается.
Останется.

Во-первых, сама по себе база намного медленнее простого обращения к файлу.
Во-вторых, lighthttpd/apache жутко сильно оптимизированы для передачи файлов, например, там есть поддержка sendfile (http://tautology.org/software/man/sendfile) — файлы будут уходить в сеть с почти что нулевым оверхедом.
В-третьих, модуль достаточно сложно писать будет — lighty использует асинхронную архитектуру.

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

ДФ>И, есть ли все-таки сравнения именно файловой системы с БД, а не Tomcat с httpd? Просто очень интересно.
Попробовал найти в Инете — не вижу что-то. Можно самому сделать

C>>Сотни транзакций в секунду, кстати, на определенных видах приложений получить можно легче легкого даже с небольшим числом клиентов.
ДФ>Гм. Я обычно считал, что если активный пользователь порождает больше транзакции в секунду — то что-то в системе не так (да и столько получается обычно при поллинге нотификаций).
ДФ>1000 одновременных активных пользователей — это уже довольно много.
Не так уж и много, если у системы есть четко выделенные пиковые часы.

ДФ>>>Но вот про кэш подумать стоит (про memcached, скорее всего).
C>>Memcached лучше всего подходит для сколь-либо динамических данных (типа комментариев в блогах). Для статических данных он только вредить будет.
ДФ>Угу. Впрочем, равномерной нагрузки почти никогда не бывает, так что причины использовать большой куш в оперативной памяти есть всегда.
Дело в том, что из memcached данные нужно передать на нужный хост — а это еще дополнительная загрузка сети. Проще иметь "персистентные кэши".

2Cyberax: Вы могли бы прокомментировать следующих 2 момента в своих постах:

1)"...Точнее, я бы использовал комбинированую схему — сделал бы центральную БД, где хранятся все блобы (удобно для бэкапа и т.п.) и систему, которая распихивала бы блобы по узлам-серверам. Таким образом, очень легко обеспечить HA — упадет одна нода, так просто перераспределяем ее данные на работающие узлы."

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

А может реализовать так: картинки сохраняются сразу на файловую систему (ФС) распределенную по нодам. А в БД хранить только различные атрибуты картинки (какому пользовалю принадлежит, в какой фотоальбом входит и т.п.) и путь до картинки на ФС (сетевой или абсолютный урл). Таким образом DAO, в методе getPics будет возращать не коллекцию бинарников, а колекцию стрингов-УРЛов до картинок

2) "Дело в том, что из memcached данные нужно передать на нужный хост — а это еще дополнительная загрузка сети. Проще иметь "персистентные кэши"."
Что есть "персистентные кэши"? Приведете плиз пару названий соотвеющих либов. Это что-то типа oscache?

Здравствуйте, javaque, Вы писали:

J>2Cyberax: Вы могли бы прокомментировать следующих 2 момента в своих постах:
J>1)"...Точнее, я бы использовал комбинированую схему — сделал бы центральную БД, где хранятся все блобы (удобно для бэкапа и т.п.) и систему, которая распихивала бы блобы по узлам-серверам. Таким образом, очень легко обеспечить HA — упадет одна нода, так просто перераспределяем ее данные на работающие узлы."
J>Правильно ли я вас понял?: вы предлагаете, все же все картинки хранить в БД и при первом обращении к картинке в БД, перед тем как отобразить ее юзеру картинка пишется на диск (на винт одной из нод, определяемой, к примеру, случайным образом ) и затем, уже, с файловой система хттп-сервер отдает контент юзеру.
Примерно так. Точнее, я бы еще оптимизировал — писал бы картинку на диск сразу же при ее загрузке на сервер. В общем, просторов для творчества тут много.

J>Имхо сложно как то. Допустим надо будет определять впервый раз мы обращаемся к картинке или уже обращались (на ведь надо знать есть такая картинка или нет на файловой системе), для этого надо будет завести поле в таблице или проверять существование соответсвующего файла напрямую.
БД с этим справляется прекрасно — у нас всего-лишь простой поиск. Файл проверять не надо, мы клиенту просто выдаем ссылку на изображение вида http://node31.blah.com/blah/image123412341234.jpg, если мы уже знаем, что такой файл там есть, или отдаем файл нужной ноде, а потом возвращаем ссылку.

J>А может реализовать так: картинки сохраняются сразу на файловую систему (ФС) распределенную по нодам. А в БД хранить только различные атрибуты картинки (какому пользовалю принадлежит, в какой фотоальбом входит и т.п.) и путь до картинки на ФС (сетевой или абсолютный урл). Таким образом DAO, в методе getPics будет возращать не коллекцию бинарников, а колекцию стрингов-УРЛов до картинок
Распределенные ФС не очень хорошо масштабируются, говорю по опыту работы с OCFS2. Кроме того, нужно еще обеспечить high availability и резервирование данных. Это все сильно проще делать с одной центральной базой данных.

J>2) "Дело в том, что из memcached данные нужно передать на нужный хост — а это еще дополнительная загрузка сети. Проще иметь "персистентные кэши"."
J> Что есть "персистентные кэши"? Приведете плиз пару названий соотвеющих либов. Это что-то типа oscache?
Я имею в виду, что файловая система будет играть роль кэша.

2Cyberax: объясните плиз какую роль играет БД в вашей схеме?? Зачем хранить 2 копии файла (один в бд другой на диске)?


C>Примерно так. Точнее, я бы еще оптимизировал — писал бы картинку на диск сразу же при ее загрузке на сервер. В общем, просторов для творчества тут много.

Так значит БД нужна сугубо для бэкапа. Ну картинки пользователей — это не банковские счета, если пропадет немного файлов я думаю никто не умрет (имхо, это уже не проблема жава программера — пусть админы по ночам бэкапят фс на нодах); тем более что при такой схеме просады в перформенсе при добавлении картинки и вообще усложение архитектуры. Значит со схемой я определился — БД буду использовать для установления соответсвия "путь до картинки<->многочисленные атрибуты картинки". Спасибо вам за подсказку с lighthttpd

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, javaque, Вы писали:

J>>2Cyberax: объясните плиз какую роль играет БД в вашей схеме?? Зачем хранить 2 копии файла (один в бд другой на диске)?
C>ОДНОЙ копии файла недостаточно в любом случае — повредится ФС на узле, что тогда будете делать? Значит, нужно хранить где-то хотя бы еще одну копию.

C>Руками механизм репликации писать долго, нудно и ненадежно. Готовых приличных ФС тоже я не знаю.

C>А вот базы данных с репликаций справляются превосходно — значит и надо их для этого использовать.

Здравствуйте, javaque, Вы писали:

J>Так значит БД нужна сугубо для бэкапа. Ну картинки пользователей — это не банковские счета, если пропадет немного файлов я думаю никто не умрет (имхо, это уже не проблема жава программера — пусть админы по ночам бэкапят фс на нодах);
Я бы не стал пользоваться сервисом, на котором иногда пропадают картинки. Кроме того, если планируется делать реально масштабируемую архитектуру с десятками узлов, то бэкап уже делается далеко не так просто, а падение узла становится достаточно рядовым событием.

J>тем более что при такой схеме просады в перформенсе при добавлении картинки и вообще усложение архитектуры. Значит со схемой я определился — БД буду использовать для установления соответсвия "путь до картинки<->многочисленные атрибуты картинки". Спасибо вам за подсказку с lighthttpd
Пожалуйста.

Здравствуйте, Cyberax, Вы писали:

C>Во-первых, сама по себе база намного медленнее простого обращения к файлу.

Гм, а откуда взялось это утверждение? Я вчера несколько часов искал информацию в инете. Единственное сравнение — это MS SQL 2000(про которой хорошо известно, что с blobами он работает плохо) и NTFS — выяснилось, что для блобов до мегабайта база данных просто быстрее, для файлов большего размера NTFS быстрее примерно на треть. Следует отметить, что реально БД начала проигрывать только после нескольких модификаций одного файла, для стратегии (insert/select) разницы по скорости не наблюдалось. Но такой тест все равно не показателен, конечно.

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


C>Во-вторых, lighthttpd/apache жутко сильно оптимизированы для передачи файлов, например, там есть поддержка sendfile (http://tautology.org/software/man/sendfile) — файлы будут уходить в сеть с почти что нулевым оверхедом.
C>В-третьих, модуль достаточно сложно писать будет — lighty использует асинхронную архитектуру.

Т.е. проблема не в БД, а в способе доступа к ним в веб-сервере? Мгм, надо будет узнать у знакомы linux-программистов, насколько сложно будет сделать "файловую систему" поверх БД — заточенную на очень простые операции (т.е. только на отдачу данных). Насколько я понимаю, это достаточно простая задача .


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

Целостность данных нам проверять нужно — что бы не отдавать пользователю битые файлы. Да и восстановление после сбоев системы тоже нужна на уровне ФС, иначе придется проверять целостность по данным из БД, что дорого. Так что без журналируемости обойтись сложно.
А распределенность нужна для разумного использования ресурсов, без нее придется гнать файлы через сеть или иметь существенно больше lhhtpd серверов, чем реально требуется нагрузкой. Впрочем, тут уже нужно смотреть профиль использования, какой объем хранения приходится на один сервер и т.п.

ДФ>>И, есть ли все-таки сравнения именно файловой системы с БД, а не Tomcat с httpd? Просто очень интересно.
C>Попробовал найти в Инете — не вижу что-то. Можно самому сделать

А попробуй. Мы тестировали — получили фактическое равенство. DB2 vs. ext2,кажется. (Точнее говоря, мы проверяли, дошли ли до предела по настройке базы путем сравнения полученной производительности с операциями с файлами.).
Вообще, у IBM есть специальная, очень недешевая система для хранения больших файлов, как раз заточенная для отдачи данных потребителям, но и там серьезное преимущество перед БД появляется только в специфических задачах.

ДФ>>Угу. Впрочем, равномерной нагрузки почти никогда не бывает, так что причины использовать большой куш в оперативной памяти есть всегда.
C>Дело в том, что из memcached данные нужно передать на нужный хост — а это еще дополнительная загрузка сети. Проще иметь "персистентные кэши".

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

Здравствуйте, Дельгядо Филипп, Вы писали:

C>>Во-первых, сама по себе база намного медленнее простого обращения к файлу.
ДФ>Гм, а откуда взялось это утверждение? Я вчера несколько часов искал информацию в инете. Единственное сравнение — это MS SQL 2000(про которой хорошо известно, что с blobами он работает плохо) и NTFS — выяснилось, что для блобов до мегабайта база данных просто быстрее, для файлов большего размера NTFS быстрее примерно на треть. Следует отметить, что реально БД начала проигрывать только после нескольких модификаций одного файла, для стратегии (insert/select) разницы по скорости не наблюдалось. Но такой тест все равно не показателен, конечно.
Забудь NTFS — это черепаха. Я как-то делал тесты, она медленнее Reiser4/Reiser3 в Линуксе в десятки раз на некоторых use-case'ах: http://www.rsdn.ru/Forum/?mid=1710544

Автор: Cyberax
Дата: 02.03.06

ДФ>В нескольких статьях, посвященных именно сравнению ФС и базам данных, утверждение "что база медленнее простого обращения к файлу" прямо называется мифом. Если подумать, то становится понятно, что реальные действия СУБД при вытаскивании блоба, в среднем, точно такие же, как и в файловой системе.
Даже близко не такие же. С sendfile в lighthttpd мы прямо можем страницы из файлового кэша отдавать в сеть, без всяких посредников (в теории даже без лишних копирований).

В случае обращения к диску — файловая система скорее всего будет тоже быстрее.

ДФ>Т.е. проблема не в БД, а в способе доступа к ним в веб-сервере? Мгм, надо будет узнать у знакомы linux-программистов, насколько сложно будет сделать "файловую систему" поверх БД — заточенную на очень простые операции (т.е. только на отдачу данных). Насколько я понимаю, это достаточно простая задача .
Не имеет смысла. И будет тормозить, вдобавок.

ДФ>Целостность данных нам проверять нужно — что бы не отдавать пользователю битые файлы. Да и восстановление после сбоев системы тоже нужна на уровне ФС, иначе придется проверять целостность по данным из БД, что дорого. Так что без журналируемости обойтись сложно.
Я имею в виду, что нам нет смысла держать сложные журналы и прочие навороты. В случае ошибки — сносим все нафиг с узла и грузим заново. Тем более, что на больших кластерах разбираться с проблемами каждой конкретной машины будет себе дороже.

ДФ>А распределенность нужна для разумного использования ресурсов, без нее придется гнать файлы через сеть или иметь существенно больше lhhtpd серверов, чем реально требуется нагрузкой. Впрочем, тут уже нужно смотреть профиль использования, какой объем хранения приходится на один сервер и т.п.
То есть "больше"? Lighthttpd работает по штуке на хост — обычно достаточно одного рабочего потока (который одновременно может обрабатывать тысячи соединений), чтобы полностью забить весь канал. Так что оверхед от lighty — даже не рассматривается как совершенно смехотворный.

C>>Попробовал найти в Инете — не вижу что-то. Можно самому сделать
ДФ>А попробуй. Мы тестировали — получили фактическое равенство. DB2 vs. ext2,кажется. (Точнее говоря, мы проверяли, дошли ли до предела по настройке базы путем сравнения полученной производительности с операциями с файлами.).
ДФ>Вообще, у IBM есть специальная, очень недешевая система для хранения больших файлов, как раз заточенная для отдачи данных потребителям, но и там серьезное преимущество перед БД появляется только в специфических задачах.
Оно, скорее всего, на SANы заточено, а там немного другие условия и деньги. В частности, SANы умирают без высокоскоростных каналов с малым временем отклика (типа fibrechannel/infiniband), что стоит весьма крупные бабки.

ДФ>>>Угу. Впрочем, равномерной нагрузки почти никогда не бывает, так что причины использовать большой куш в оперативной памяти есть всегда.
C>>Дело в том, что из memcached данные нужно передать на нужный хост — а это еще дополнительная загрузка сети. Проще иметь "персистентные кэши".
ДФ>И давно у нас дисковая система стала более быстрой и масштабируемой, нежели сеть?
Да, уже давно. Диски дают sustained transfer rate где-то в 80 мегабайт в секунду, т.е. около 480 мегабит.

ДФ>Во всех известных мне проектах узкое место — это как раз диски, что бы сеть загрузить серьезно нужно что-то уж совсем экзотическое. Да и расшить узкие места сети обычно чуть проще.
С бинарными файлами — никаких проблем. Только так затыкается от лишних копирований.

Почему я говорю — у нас в системе сейчас как раз именно такая проблема. Сканы документов и большие PDF-ки лежат в базе данных в блобах. Из-за этого в начале рабочего дня, когда все пользователи одновременно начинают работу, у системы начинаются большие проблемы. Сейчас в стадии тестирования как раз ускорялка на основе lighty — с ним нагрузка в десятки раз меньше.

C>Забудь NTFS — это черепаха. Я как-то делал тесты, она медленнее Reiser4/Reiser3 в Линуксе в десятки раз на некоторых use-case'ах: http://www.rsdn.ru/Forum/?mid=1710544

Автор: Cyberax
Дата: 02.03.06

Ага, похоже на то. Спасибо за ссылку (и оригинальное исследование). Когда будет возможность загрузить админа несущественными делами — поиграюсь в сравнение БД и той же reiser4 на работе с блобами — по крайней мере на вводе-выводе.

ДФ>>Если подумать, то становится понятно, что реальные действия СУБД при вытаскивании блоба, в среднем, точно такие же, как и в файловой системе.
C>Даже близко не такие же. С sendfile в lighthttpd мы прямо можем страницы из файлового кэша отдавать в сеть, без всяких посредников (в теории даже без лишних копирований).
C>В случае обращения к диску — файловая система скорее всего будет тоже быстрее.

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

А тут, в общем, что БД, что ФС делают одно и то-же — ищут метаданные (файла или блоба), а потом оптимальным способом загружают нужные страницы с диска (или дисков). Метаданные, скорее всего, в оперативной памяти. Страницы расположены физически так, что бы их можно было считать максимально быстро.
Вот я и пытаюсь понять, где в подобной схеме может существенно выиграть ФС.

Правда интерес потихоньку переходит уже в теорию, на практике есть очень немного задач, где это актуально (т.е. где нужно хранить большие данные, но не передавать их по сети наружу

ДФ>>Т.е. проблема не в БД, а в способе доступа к ним в веб-сервере? Мгм, надо будет узнать у знакомы linux-программистов, насколько сложно будет сделать "файловую систему" поверх БД — заточенную на очень простые операции (т.е. только на отдачу данных). Насколько я понимаю, это достаточно простая задача .
C>Не имеет смысла. И будет тормозить, вдобавок.
Ну, смысл то как раз виден — если тормозить на "дисковых" операциях не будет. А почему должно тормозить — не очевидно (см. выше).
Основная тонкость, как я понимаю, избежать хранения блоба целиком на промежуточных этапах.

C>Я имею в виду, что нам нет смысла держать сложные журналы и прочие навороты. В случае ошибки — сносим все нафиг с узла и грузим заново. Тем более, что на больших кластерах разбираться с проблемами каждой конкретной машины будет себе дороже.
Гм, это очень дорого — залить все по новой. Разве что иметь дубли всех узлов в ФС — для HA (просто наличие копии в БД HA не обеспечивает). Можно еще в случае сбоя ходить не в ФС, а в БД, пока все данные в ФС не появятся. Т.е. использование ФС как классический ненадежный кэш).

ДФ>>А распределенность нужна для разумного использования ресурсов, без нее придется гнать файлы через сеть или иметь существенно больше lhhtpd серверов, чем реально требуется нагрузкой. Впрочем, тут уже нужно смотреть профиль использования, какой объем хранения приходится на один сервер и т.п.
C>То есть "больше"? Lighthttpd работает по штуке на хост — обычно достаточно одного рабочего потока (который одновременно может обрабатывать тысячи соединений), чтобы полностью забить весь канал. Так что оверхед от lighty — даже не рассматривается как совершенно смехотворный.

Ага. Т.е. предполагается, что с одного хоста (ну, например, в пару ТБ) будет постоянный поток около 100Mb, т.е. избирательность 1 к 20000?
Высоковато, мне кажется, но пусть будет. А лишние lhttpd все равно не помешают, если поток будет даже раз в десять меньше — только лучше, хоть какой-то запас по нагрузке. А то нагрузка в подобных ресурсах очень неравномерна, как я понимаю.
Кстати, а как вообще делать балансировку по нагрузке? Дублированием самых "популярных" файлов на нескольких серверах с случайным доступом?

C>Да, уже давно. Диски дают sustained transfer rate где-то в 80 мегабайт в секунду, т.е. около 480 мегабит.
Угу, я глупость сказал. Те же сетевые дисковые системы не даром требуют существенно более быстрых соединений, нежели 1Gb.
Кстати, 80MB — это как минимум 640 мегабит

C>Почему я говорю — у нас в системе сейчас как раз именно такая проблема. Сканы документов и большие PDF-ки лежат в базе данных в блобах. Из-за этого в начале рабочего дня, когда все пользователи одновременно начинают работу, у системы начинаются большие проблемы. Сейчас в стадии тестирования как раз ускорялка на основе lighty — с ним нагрузка в десятки раз меньше.

Гм, это в интранете? Ну, я бы использовал решения на уровне БД (например, поставил бы еще парочку серверов на той же БД). Но рядом виднее.

Здравствуйте, Дельгядо Филипп, Вы писали:

C>>Забудь NTFS — это черепаха. Я как-то делал тесты, она медленнее Reiser4/Reiser3 в Линуксе в десятки раз на некоторых use-case'ах: http://www.rsdn.ru/Forum/?mid=1710544

Автор: Cyberax
Дата: 02.03.06

ДФ>Ага, похоже на то. Спасибо за ссылку (и оригинальное исследование). Когда будет возможность загрузить админа несущественными делами — поиграюсь в сравнение БД и той же reiser4 на работе с блобами — по крайней мере на вводе-выводе.
Ага, будет интересно.

C>>В случае обращения к диску — файловая система скорее всего будет тоже быстрее.
ДФ>Гм, вообще, если поискать, то для больших БД тоже можно найти способ отдавать блобы прямо с диска в сеть. Правда, мгм, это не секьюрно, да и производительность никто не мерил.
Ни разу не видел такой возможности.

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

Ну и ФС очень сильно оптимизирована на прямой поиск по имени — это ее основная задача. Ну и еще отсутствует оверхед на транзакционность, блокировки и т.п.

ДФ>>>Т.е. проблема не в БД, а в способе доступа к ним в веб-сервере? Мгм, надо будет узнать у знакомы linux-программистов, насколько сложно будет сделать "файловую систему" поверх БД — заточенную на очень простые операции (т.е. только на отдачу данных). Насколько я понимаю, это достаточно простая задача .
C>>Не имеет смысла. И будет тормозить, вдобавок.
ДФ>Ну, смысл то как раз виден — если тормозить на "дисковых" операциях не будет. А почему должно тормозить — не очевидно (см. выше).
Если на дисковых операциях тормозить не будет — то тогда почему бы не использовать ФС?

ДФ>Основная тонкость, как я понимаю, избежать хранения блоба целиком на промежуточных этапах.
Это, на самом деле, не такая уж проблема — временно хранить его вполне можно. Zero-copy в lighty — это скорее просто приятное дополнение.

C>>Я имею в виду, что нам нет смысла держать сложные журналы и прочие навороты. В случае ошибки — сносим все нафиг с узла и грузим заново. Тем более, что на больших кластерах разбираться с проблемами каждой конкретной машины будет себе дороже.
ДФ>Гм, это очень дорого — залить все по новой. Разве что иметь дубли всех узлов в ФС — для HA (просто наличие копии в БД HA не обеспечивает). Можно еще в случае сбоя ходить не в ФС, а в БД, пока все данные в ФС не появятся. Т.е. использование ФС как классический ненадежный кэш).
Ну да, это я и предлагаю — ФС должна работать в качестве кэша. Тогда HA обеспечиваем за счет того, что при смерти какой-нибудь ноды мы будем делать fallback на базу данных — это будет достаточно редкое событие, так что потерей производительности тут можно пренебречь.

C>>То есть "больше"? Lighthttpd работает по штуке на хост — обычно достаточно одного рабочего потока (который одновременно может обрабатывать тысячи соединений), чтобы полностью забить весь канал. Так что оверхед от lighty — даже не рассматривается как совершенно смехотворный.
ДФ>Ага. Т.е. предполагается, что с одного хоста (ну, например, в пару ТБ) будет постоянный поток около 100Mb, т.е. избирательность 1 к 20000?
Что такое "избирательность" в данном случае?

ДФ>Высоковато, мне кажется, но пусть будет. А лишние lhttpd все равно не помешают, если поток будет даже раз в десять меньше — только лучше, хоть какой-то запас по нагрузке. А то нагрузка в подобных ресурсах очень неравномерна, как я понимаю.
Lighty сделан на асинхронной неблокирующейся архитектуре — он масштабируется почти как O(1) для числа соединений. Что, собственно, и делает его очень популярным.

ДФ>Кстати, а как вообще делать балансировку по нагрузке? Дублированием самых "популярных" файлов на нескольких серверах с случайным доступом?
Ага. Тут еще файловая система тоже рулит — ОС будет кэшировать наиболее частоиспользуемые файлы в оперативной памяти. Тем более, что в Линуксе политику кэширования можно очень тонко настроить.

C>>Да, уже давно. Диски дают sustained transfer rate где-то в 80 мегабайт в секунду, т.е. около 480 мегабит.
ДФ>Угу, я глупость сказал. Те же сетевые дисковые системы не даром требуют существенно более быстрых соединений, нежели 1Gb.
ДФ>Кстати, 80MB — это как минимум 640 мегабит
Ну плохо у меня с арифметикой

C>>Почему я говорю — у нас в системе сейчас как раз именно такая проблема. Сканы документов и большие PDF-ки лежат в базе данных в блобах. Из-за этого в начале рабочего дня, когда все пользователи одновременно начинают работу, у системы начинаются большие проблемы. Сейчас в стадии тестирования как раз ускорялка на основе lighty — с ним нагрузка в десятки раз меньше.
ДФ>Гм, это в интранете? Ну, я бы использовал решения на уровне БД (например, поставил бы еще парочку серверов на той же БД). Но рядом виднее.
Это Интернет, но со скоростью 155 мегабит до местного exchange-узла (и где-то около 50Мбит после него).

Здравствуйте, Cyberax, Вы писали:

ДФ>>Ага, похоже на то. Спасибо за ссылку (и оригинальное исследование). Когда будет возможность загрузить админа несущественными делами — поиграюсь в сравнение БД и той же reiser4 на работе с блобами — по крайней мере на вводе-выводе.
C>Ага, будет интересно.
Скоро не жди


ДФ>>Гм, вообще, если поискать, то для больших БД тоже можно найти способ отдавать блобы прямо с диска в сеть. Правда, мгм, это не секьюрно, да и производительность никто не мерил.
C>Ни разу не видел такой возможности.
Просто ими не пользуются. Свой web-сервер сейчас во всех больших БД есть, в том числе и с возможностью в get/post-запросах указывать sql-query.
Я это смотрел еще для MSSQL-2000, но это было давно, да и тонкости я не смотрел.
Интересно, что на этот счет есть в Oracle.

ДФ>>Вот я и пытаюсь понять, где в подобной схеме может существенно выиграть ФС.
C>Для ФС не нужно разбирать запросы, строить планы исполнения и т.п. Кроме того, если нужной страницы нет в кэше БД — то тогда ее надо считать с диска, а это тоже требует обращения к файловой системе.
Гм, не совсем так. Для БД разбирать запросы и строить планы исполнения тоже не нужно — достаточно сделать это один раз, потом взять из кэша.
А чтение с диска к файловой системе отношения, в общем, не имеет — обычно работают или на raw, или вообще на специальной файловой системе, адаптированной под конкретную БД.

C>Ну и ФС очень сильно оптимизирована на прямой поиск по имени — это ее основная задача. Ну и еще отсутствует оверхед на транзакционность, блокировки и т.п.
Ну, БД тоже очень и очень заточены на поиск по индексу. Собственно, и там и там явно некие B-tree, что же еще.
Расходы на транзакции и блокировки, во-первых, очень небольшие, а во-вторых, легко отключаемые А если задача требует нормальных блокировок, то тут и ФС или делает то же самое, или уже непригодна к использованию.



ДФ>>Основная тонкость, как я понимаю, избежать хранения блоба целиком на промежуточных этапах.
C>Это, на самом деле, не такая уж проблема — временно хранить его вполне можно. Zero-copy в lighty — это скорее просто приятное дополнение.
Не, это как раз проблема, подозреваю.
Один сценарий: забрать блок от СУБД, отдать его в канал. И совсем другой — выкачать целиком блоб, положить в память, оттуда по кусочкам отдавать в канал. Второй сценарий требует существенно больше ресурсов и дает гораздо худший responsetime.

C>>>То есть "больше"? Lighthttpd работает по штуке на хост — обычно достаточно одного рабочего потока (который одновременно может обрабатывать тысячи соединений), чтобы полностью забить весь канал. Так что оверхед от lighty — даже не рассматривается как совершенно смехотворный.
ДФ>>Ага. Т.е. предполагается, что с одного хоста (ну, например, в пару ТБ) будет постоянный поток около 100Mb, т.е. избирательность 1 к 20000?
C>Что такое "избирательность" в данном случае?
Не знаю, как этот параметр официально называется: насколько востребованы публичные ресурсы. В данном случае, для "сайта с картинками" это значит, что в среднем каждый момент времени кто-то вытягивает одну картинку из каждых 20 000 размещенных на сайте.


ДФ>>Высоковато, мне кажется, но пусть будет. А лишние lhttpd все равно не помешают, если поток будет даже раз в десять меньше — только лучше, хоть какой-то запас по нагрузке. А то нагрузка в подобных ресурсах очень неравномерна, как я понимаю.
C>Lighty сделан на асинхронной неблокирующейся архитектуре — он масштабируется почти как O(1) для числа соединений. Что, собственно, и делает его очень популярным.
Я не про нагрузку на веб-сервер, я про нагрузку на отдельный сервер, в первую очередь на канал и диски.


ДФ>>Кстати, а как вообще делать балансировку по нагрузке? Дублированием самых "популярных" файлов на нескольких серверах с случайным доступом?
C>Ага. Тут еще файловая система тоже рулит — ОС будет кэшировать наиболее частоиспользуемые файлы в оперативной памяти. Тем более, что в Линуксе политику кэширования можно очень тонко настроить.

Не, мы же уже дошли до того, что узкое место — это сеть, т.е. кэширование внутри "сервера" ничему не поможет, дисковая система и так быстрее сети.
А уж если есть запас по сетевым ресурсам — то можно и правильней memcached поставить. Или виртуальные диски поднять.
Дисковые кэши — это достаточно очевидная вещь....

ДФ>>Кстати, 80MB — это как минимум 640 мегабит
>>Ну плохо у меня с арифметикой
Кстати, из этого следует, что обычный гигабит забивает уже пара средних винтов? Странно, что это обычно не наблюдается.
Или, все-таки, в реальных задачах поток сильно меньше?


C>>>Почему я говорю — у нас в системе сейчас как раз именно такая проблема. Сканы документов и большие PDF-ки лежат в базе данных в блобах. Из-за этого в начале рабочего дня, когда все пользователи одновременно начинают работу, у системы начинаются большие проблемы. Сейчас в стадии тестирования как раз ускорялка на основе lighty — с ним нагрузка в десятки раз меньше.

ДФ>>Гм, это в интранете? Ну, я бы использовал решения на уровне БД (например, поставил бы еще парочку серверов на той же БД). Но рядом виднее.
C>Это Интернет, но со скоростью 155 мегабит до местного exchange-узла (и где-то около 50Мбит после него).
Странно, по идее, уж с такой скоростью можно и из БД отдавать данные. Ты уверен, что узкое место — вход в канал, а не сам канал.
И что lighty именно скорость увеличил, а не responsetime уменьшил?
Какая БД?