Слишком радикально - это джава. Когда у вас платформа - Линукс, nginx, mongrel, memcached, гораздо веселее работать с Си или плюсами, без всяких параллельных вселенных типа Джавы.
Есть еще Merb, альтернатива rails actionpack, который в базовом варианте работает на 20-30% быстрее рельсы, а в связке с evented mongrel и в многопоточном режиме может дать прирост и о 100% (многое зависит от логики приложения, нагруженности базы и стратегии кеширования).
Для дотнета есть языки получше, чем PHP. Зачем такие извращения? Или, "на пхп уже есть готовый проект"? Тогда непонятно, зачем съезжать с линукса. Впрочем, пхп, дотнет, винда порождают больше вопросов, чем дают ответов, что с них взять...
Почти все мак-юзеры пользуются Адиумом, которому все равно, в какой IM-сети работать. Я добавляю контакты из аськи и джаббера и не парюсь по поводу различий.
Хотя, различия иногда случаются:
1) В аську не пролезает несколько кодпейджев (в ней, или в клиентах, utf-8, как я понял, не поддерживается).
2) В аську не пролезают достаточно длинные тексты, которые пролезают в гугловый джаббер.
Но самое главное — всем моим друзьям не нужно перелезать с аськи, чтобы мне было удобно. История сообщений прекрасно ищется на локальной машине, чем я довольно часто пользуюсь.
Мораль: ставьте вместо гтока универсальные клиенты и не парьте людям мозг. Пусть с чем хотят, с тем и работают.
Почему же, верю. Только в виндоусе я так и не смог насладиться автоапдейтом: он вешал машину и приходилось его килять, а затем совсем выключать, чтобы история не повторялась. Так было с несколькими десктопными машинами и ноутбуком. Все бы ничего, но если ваше рабочее окружение — флеш, фотошоп, браузер с мануалами, текстовые редакторы и открытые подключения к серверам по ssh, жалко все это перезапускать.
В Mac OS X обновление работает так: выскакивает окошко со списком софта, который можно обновить. Под каждым обновлением написано что изменилось, с пунктов, которые вы не хотите ставить, можно снять галочку. У тех пунктов, из-за которых нужен ребут, стоит специальный значок - можно сразу решить, хотите ли прерывать работу и из-за чего.
Иногда нужен простой поиск, но стандартные средства MySQL или другой БД не подходят по причине нагрузок. Это не парадокс: нагрузки даны огромные, а поиск достаточно сделать простой (пока не выросли до размеров яндекса, скажем). И нужно что-то сочинить самим.
Я об этом и говорил: http://www.habrahabr.ru/blog/webdev/2495…
Для ненагруженных сайтов like %text% все равно не быстрый (посетителей может быть мало, а документов — много), так что все-таки нужна отдельная таблица слов. Есть куча библиотек, которые это делают, но можно и руками, если библиотека не гибкая. Не самая большая забота.
А созвучность ищется у стеммированных слов? По-моему, будет высокая погрешность. Стоит хранить отдельно исходные слова во всех формах с саундексом, со ссылкой на стеммированное слово. Если не нашли стем, ищем оригинал среди оригиналов по саундексу. Таблица будет раз в 5-10 больше таблицы стемов, но зато и использоваться будет раз в 10 реже.
И еще: текущая реализация с inner join не масштабируется. Память может закончиться при преодолении критического значения количества документов и слов. Нужно делать отдельный запрос за номерами слов (и так его придется делать чтобы проверить на опечатки), затем делать запрос в таблицу соответствий (words_documents). А затем, по полученным первым N номерам вытащить документы. Такой алгоритм хорошо распараллеливается, если дробить таблицу соответствий по номеру документа на N частей, раскладывать на N машин и делать к ним N параллельных запросов (map-reduce). В пхп с потоками все плохо, поэтому можно взять Руби или еще какой нормальный язык. Затем, боттлнеком станет таблица документов, которую нужно будет тупо реплицировать.
Reduce-часть поиска: слияние результатов от N машин с сортировкой по релевантности. Цикл, которые это делает имеет длину M*N, где M - максимальное количество результатов (M=20 на страницу, например). Если машин десять, то цикл — 200 шагов (просто сравнение значений релевантности). И делается после ответа от всех баз - неприятно, особенно, если язык Руби не очень быстрый для такой задачи. Хотя цикл, в общем-то, не большой: у меня выполняется порядка 0,2 мс (ненагруженный Core 2 Duo, Mac OS X). Но и его можно ускорить, если объединять данные по мере их поступления (пользуясь тем, что базы отвечают неодновременно). Если из 10 машин уже есть результаты от 2 из них, то их можно объединить и потом объединять 9, а не 10 потоков. Если удастся объединить все результаты до ответа последней базы, то тормозящий цикл будет 2*M, т.е. около 40 шагов. В 5 раз короче - 0,04 мс.
Не вижу разницы между содержимым сайта вендора и моим сайтом, если содержимое подписано. Непонятно, зачем хранить vendors[h] = [url, url, ...]. Мы же говорим о простом кэше. Нужно реализовать всего два действия: чтение и запись.
1) Чтение: берем контрольную сумму и используем как ключ (подсчет КС не производим, скачивание ни откуда не делаем). Если данных не нашлось, см. пункт 2.
2) Запись: скачиваем указанный в src файл, считаем КС, сравниваем с предоставленной КС. Если совпало — сохраняем в кэш с ключем - как раз этой КС ("глобальный кэш"). Если не совпало — кладем в кэш с ключем - собственным УРЛ "vasya.ru/lib.js" ("локальный кэш").
Вот и всё.
Контрольную сумму мы можем посчитать сами, а можем взять с сайта вендора. Только зачем браузеру ходить на сайт вендора? Там всегда одна и та же информация будет лежать (версия-то фиксированная). Если мы смухлюем в контрольной сумме, то просто прочитаем чей-то чужой публичный скрипт или, если такого не будет, получим скрипт с нашего сервера (но он не будет доступен другим сайтам).
Т.е. по существу, нужно хранить у вендора только контрольную сумму, а грузить с текущего сайта. Идея более чем здравая: не будет проблем с трафиком у вендора.
Получается вот что: контрольная сумма служит ключом в ассоциативном массиве "кэш браузера" и сайты, использующие одну контрольную сумму, используют общие кэшированные данные.
Тогда не нужно указывать сайт вендора — только контрольную сумму (ведь в vendor URI все равно неизменные данные). Если сравнение сумм не прошло, то файл кешируется не в глобальном кэше, а только для данного сайта. И все выглядит довольно шоколадно.
Если скрипт будет грузиться с /lib, а кэшироваться как vendor.com/lib, и так выдаваться всем остальным сайтам — это называется "дыра в безопасности".
Атрибут vendor как раз указывает на конкретную версию софта и является уникальным URL. Локальная копия нужна, если вендор недоступен. Но она кэшируется только для одного сайта.
Я читаю внимательно, поэтому верхний регистр использовать не обязательно. Последним абзацем вы подтвердили, что ничего не понимаете в архитектуре распределенных систем. Когда вы прекратите писать чушь и захотите действительно просветиться, дайте знать.
Остановимся на том, что ваше предложение до конца четко не описано и вы, судя по всему, не понимаете, о чем идет речь. Перечисление красивых слов "google gears", "manifest", "Hosting", "никаких гвоздей" — это не предложение, а что-то типа политических высказываний.
Спросите krasin — она поняла.
// общение с анонимами-виртуалами нужно сворачивать...
Согласен на 100%. А вот если сравнивать гибкость написания Си-экстеншенов для пхп и руби, то первый просасывает по всем статьям.
Тем не менее, я был бы очень даже не против, если на динамическом языке можно будет писать обход бинарных деревьев, без приклеивания Си.
Хотя, различия иногда случаются:
1) В аську не пролезает несколько кодпейджев (в ней, или в клиентах, utf-8, как я понял, не поддерживается).
2) В аську не пролезают достаточно длинные тексты, которые пролезают в гугловый джаббер.
Но самое главное — всем моим друзьям не нужно перелезать с аськи, чтобы мне было удобно. История сообщений прекрасно ищется на локальной машине, чем я довольно часто пользуюсь.
Мораль: ставьте вместо гтока универсальные клиенты и не парьте людям мозг. Пусть с чем хотят, с тем и работают.
Я об этом и говорил: http://www.habrahabr.ru/blog/webdev/2495…
Для ненагруженных сайтов like %text% все равно не быстрый (посетителей может быть мало, а документов — много), так что все-таки нужна отдельная таблица слов. Есть куча библиотек, которые это делают, но можно и руками, если библиотека не гибкая. Не самая большая забота.
И еще: текущая реализация с inner join не масштабируется. Память может закончиться при преодолении критического значения количества документов и слов. Нужно делать отдельный запрос за номерами слов (и так его придется делать чтобы проверить на опечатки), затем делать запрос в таблицу соответствий (words_documents). А затем, по полученным первым N номерам вытащить документы. Такой алгоритм хорошо распараллеливается, если дробить таблицу соответствий по номеру документа на N частей, раскладывать на N машин и делать к ним N параллельных запросов (map-reduce). В пхп с потоками все плохо, поэтому можно взять Руби или еще какой нормальный язык. Затем, боттлнеком станет таблица документов, которую нужно будет тупо реплицировать.
Reduce-часть поиска: слияние результатов от N машин с сортировкой по релевантности. Цикл, которые это делает имеет длину M*N, где M - максимальное количество результатов (M=20 на страницу, например). Если машин десять, то цикл — 200 шагов (просто сравнение значений релевантности). И делается после ответа от всех баз - неприятно, особенно, если язык Руби не очень быстрый для такой задачи. Хотя цикл, в общем-то, не большой: у меня выполняется порядка 0,2 мс (ненагруженный Core 2 Duo, Mac OS X). Но и его можно ускорить, если объединять данные по мере их поступления (пользуясь тем, что базы отвечают неодновременно). Если из 10 машин уже есть результаты от 2 из них, то их можно объединить и потом объединять 9, а не 10 потоков. Если удастся объединить все результаты до ответа последней базы, то тормозящий цикл будет 2*M, т.е. около 40 шагов. В 5 раз короче - 0,04 мс.
1) Чтение: берем контрольную сумму и используем как ключ (подсчет КС не производим, скачивание ни откуда не делаем). Если данных не нашлось, см. пункт 2.
2) Запись: скачиваем указанный в src файл, считаем КС, сравниваем с предоставленной КС. Если совпало — сохраняем в кэш с ключем - как раз этой КС ("глобальный кэш"). Если не совпало — кладем в кэш с ключем - собственным УРЛ "vasya.ru/lib.js" ("локальный кэш").
Вот и всё.
Получается вот что: контрольная сумма служит ключом в ассоциативном массиве "кэш браузера" и сайты, использующие одну контрольную сумму, используют общие кэшированные данные.
Тогда не нужно указывать сайт вендора — только контрольную сумму (ведь в vendor URI все равно неизменные данные). Если сравнение сумм не прошло, то файл кешируется не в глобальном кэше, а только для данного сайта. И все выглядит довольно шоколадно.
Атрибут vendor как раз указывает на конкретную версию софта и является уникальным URL. Локальная копия нужна, если вендор недоступен. Но она кэшируется только для одного сайта.
Спросите krasin — она поняла.
// общение с анонимами-виртуалами нужно сворачивать...